- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 26 Feb 2013 07:45:11 +0000
- To: "www-tag@w3.org List" <www-tag@w3.org>
On 25 Feb 2013, at 17:08, Robin Berjon <robin@w3.org> wrote: > On 25/02/2013 17:40 , John Kemp wrote: >> The reason that text/plain vs. text/html comes up so often is that it is >> a very clear description of one problem with sniffing - that the author >> intended the representation to be displayed as text without HTML >> interpretation. > > I'd be less charitable. I think that this example keeps coming up because proponents of authoritative metadata cannot think of any other example :) I think the reason that this comes up is that HTML is the one of the only formats that (a) you can sensibly view as some other format and (b) would otherwise be handled differently by a browser. Other formats that would fall into the same category would be SVG, MathML and XML with an associated stylesheet. I guess iCal too, given that's likely to open up in a calendar app otherwise. >> Although I agree that metadata sent from the server is less >> authoritative than one would hope, I do not agree that a user-agent can >> even accurately represent the wishes of the user in this case, let alone >> comply with them. > > Well, there's <plaintext> for that if you're sure that that's what you want. For all the other cases it would seem that View Source can work. The one example I came across recently where a big site is purposefully using Content-Type: text/plain is github. Look at: https://raw.github.com/darobin/respec/develop/tests/SpecRunner.html for example. I'm sure that they could have implemented this differently, though I can't think of a way that would both avoid the security issues of serving arbitrary user-provided HTML out of the github.com domain and make it easy for people to download individual files without editing them. You can't use <plaintext> for that, right? data: URLs maybe? I do agree with the general principle of keeping metadata as close to the content that it's about as possible, so that it can travel around with the content. What's not clear to me at the moment are answers to the questions: 1. What is the alternative? 2. How could we transition to that alternative? 3. What should the TAG do to enable that transition to happen? Jeni -- Jeni Tennison http://www.jenitennison.com/
Received on Tuesday, 26 February 2013 08:32:14 UTC