- From: Sam Ruby <rubys@us.ibm.com>
- Date: Mon, 20 Aug 2007 16:57:54 -0400
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org WG" <public-html@w3.org>
Note:snippets from three separate emails on the same thread. Ian Hickson wrote: > On Mon, 20 Aug 2007, Sam Ruby wrote: >>> So while it may be valuable to have a way to say "this is really the >>> content type, please don't sniff", your example does not make a very >>> strong case for it, since browsers are in their rights to do custom >>> rendering of any XML content type based on the namespaces used in the >>> contents. >> If I changed my content type to text/plain, would that change your >> answer? I would gladly change my Content-type to text/plain if only I >> could get browsers to respect that. Gladly. But they don't. > > For what it's worth, I strongly agree with you that (for security reasons > if nothing else!) you should never have text/plain documents that only use > non-<control> characters sniffed and treated like HTML, RSS, or Atom. > Those documents should be treated as text/plain. > > At the moment, the spec backs that up. Unfortunately, while you and I are on the same side, I can "pull an Ian" here, and provide plenty of counter examples. [1] :-( > The problem is that integrates very tightly with the way that browsing > contexts work, and integrates tightly with how session history work, both > of which are tightly integrated with how the Window object works, which > itself is tightly integrated with event dispatch and parsing. It's also > directly related to the section on hyperlinks, which is directly related > to <a>, <link> and <area>. Amusingly these types of things is precisely why I named my site the way I did. :-) > So I would add a fifth condition: (5) the parameter is chosen such that > browser vendors cannot ever get a competitive advantage by not supporting > it or by supporting it incompletely. Unfortunately, based on the quick list I gathered below, there is a competitive advantage to be gained by ignoring the spec as it currently stands. Furthermore, the abstract way in which you have framed the problem means that it applies to pretty much every feature and addition that is present in HTML5 that isn't supported in IE6. Finally, that competitive advantage thing can work both ways. In a field not too distant from the one that we are discussing, I've seen cases where enough vendors have grown to support Atom specific features simply because if the did not, they would be at a competitive disadvantage. All theory aside, My read is that if we simply picked something like ";important" to append to the content type and if IE8 supported it, and if a few of us actually deployed content that behaved better if it were honored, and publicized the fact that we did so, there would not be an issue. - Sam Ruby [1] here's a few feeds that are served as text/plain, but would sniff as feeds. A few might be generated by the same software, but from a quick pass, it appears that the bulk are generated by separate and unique codebases: http://hellern.homelinux.org/feed.rss http://jewczuk.net/blog/blog.rss http://paranoid.net.ua/news.rss http://pelloud.ovh.org/pelloud.rss http://primo.anti-emo.org/podcasttest.rss http://raystedman.org/messages.rss http://softwaresummit.com/coloradosoftwaresummit.atom http://upwebdesign.com/fashionsite2.rss http://users.rcn.com/mmathews.dnai/feed.rss http://www.amazingwondersoftheworld.com/wowRSS2.rss http://www.armencomp.com/tradelog/trader_tax_topics.rss http://www.asstr.org/~sub01/updates.rss http://www.bitec.de/bitec.rss http://www.centerforrationaldebate.com/rss/rational.rss http://www.digitalarte.co.uk/news-and-updates.rss http://www.edalty.com/DaltonSystems/rss/index.rss http://www.efectovirtual.com/efectovirtual.rss http://www.goascendant.com/testrss.rss http://www.kikogolf.com/features.rss http://www.martinjspeed.com/rssfeed.rss http://www.musicfrombrazil.com.br/mfb-pt.rss http://www.resiper.net/paginas/misitio.rss http://www.roda-schule.de/news.rss http://www.seojorge.com.br/rss/comicFeeds.rss http://www.soullip.com/soullip.rss http://www.stephen-kiernan.com/Site/feed/articlefeed.rss http://www.toyzetc.com/podketeer/xml/rss.xml http://www.trywatersedge.com/testrssfeed.rss http://www.tyffanie.com/rss/tyffanie.rss http://caamanquehue.cl/phpnews/caa.rss http://www.madcowdisease.org/madcow.rss http://nitrogen.guj.de/test/HD2.rss http://astoryaweek.com/story_a_week_podcast_jp.rss http://beigebrigade.co.nz/loop/byc/bycfeed.rss http://hjem.tele2adsl.dk/aanaes/feed.rss http://topfotologs.com/rss/fotologs_superiores_hoy.rss http://www.alexhenley.com/alex.rss http://www.cmediscovery.com/podcasts/cmepodcasts.rss http://www.comp.nus.edu.sg/%7Edaifei/PluginDT/rss/feed.rss http://www.ebooksatoz.com/newsletters/newsfeed.rss http://www.ezstreetasphalt.com/news/pothole-repair-news.rss http://www.ihsa.org/ihsa-scorezone.rss http://www.infotile.com.au/RSS/infotile.rss http://www.revistadircom.com.ar/adm/reporte.rss http://www.sutrodigital.com/test1.xml http://cs.uns.edu.ar/~ldm/rss/novedades.rss
Received on Monday, 20 August 2007 20:58:10 UTC