The title was chosen in the trend of a weblog entry from Mark Perlgrim: everything considered harmful. I do not think the X-Philes should be considered harmful, but when others point you to things you didn't thought (know) about you wished they were "considered harmful". Of course the 21 X-Philes are not the only pages who are send as application/xhtml+xml and are valid XHTML (I'm aware this could be different in the future for these pages or even now they could be invalid, but for this post they all are), but these are the ones that are listed.
NOTE: The following is not a rant against the X-Philes list made by Evan Goer. This is intended to inform everyone about the problems and hopefully some of the comments will bring answers to those problems.
Now will it happen that I have a reader who send me an e-mail with a link in it to a W3C page and yes, only one X-Philes page, aagh.net, remains valid (I will not start about other things from the specification like abbreviations, 'cause then nobody would be correct).
I got this e-mail from Michael and although I know I am invalid and it's not possible for me to fix it right now I thank him for sending this, 'cause everyone should now it. It is about the xml-stylesheet processing instruction, which I mentioned last time when I had a item about styling XML. It comes out that this PI is required if you send you page as application/xml (which is a superset of application/xhtml+xml):
Authors SHOULD explicitly identify the XHTML namespace through the namespace declaration when they serve an XHTML Family document as
application/xmlto facilitate the chance for reliable processing. The XML stylesheet PI SHOULD be used to associate style sheets.
And a little below that there is a second thing which we all should now (especially the X-Philes), the meta http-equiv statement is invalid and should not be used. I even saw a X-Phile page with the content-type within that statement set to text/html, how can it be more wrong? The W3C says:
Therefore, while it is STRONGLY RECOMMENDED to specify an explicit charset parameter through a higher-level protocol, authors SHOULD include the XML declaration (e.g:
<?xml version="1.0" encoding="EUC-JP"?>). Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served asapplication/xml(andapplication/xhtml+xmlas well for that matter).
So lets all start thinking how to solve these (little?) problems.
I even saw a X-Phile page with the content-type within that statement set to
text/html, how can it be more wrong?
Whoops. My fault entirely. It was there as legacy code, fixed on my local copy of the site months ago. I just forgot to upload it. It's fixed now.
As for the style sheet issue, I'm leaving it as a normal stylsheet declaration for now. I'm in the middle of doing a major redesign and, until it's done, there's no point in changing this. (Also the "SHOULD" rather than "MUST" buys me some time).
So lets all start thinking how to solve these (little?) problems.
Telling people about them directly is a good start...
A solution for the xml-stylesheet problem can be to add an id attribute to your <style> tag and reference that in the xml-stylesheet instruction.
Use an @import(url) statement in de <style> (some of us do that already, to hide the styles for older browsers).
(Referencing Style Elements when serving as XML)
For the encoding 'problem': why is it a problem to add a charset declaration to the HTTP Content-Type header?
And also adding the xml declaration (with encoding) to your documents seems to be no problem (everyone's doing that already).
Anne, when posting this message (and a previous one), the next screen was not well-formed XML (it went wrong at the URL's in my post I think, didn't check source though). And since you serve your documents as application/xhtml+xml, Mozilla can't parse it.
A lot of people might try to repost, repost, and repost a comment when seeing an error message after submitting ;)
Let me see if I understand the issues you raise.
1) If you use application/xml (which is, not a "superset" of application/xhtml+xml), you SHOULD declare your stylesheets as <?xml-stylesheet href="mystyle.css" type="text/css"?>
That makes perfect sense, as this is the generic way to link to a stylesheet in a generic XML document (which is what application/xml means). Specific dialects of XML (like, 'frinstance, XHTML) may have more specialized mechanisms for linking to a stylesheet and, as long as you identify those dialects by setting the correct MIME type, there's nothing wrong with using the more specialized mechanism.
2)The http-equiv declaration is bogus and SHOULD NOT be used.
Is it bogus just for setting the content-type and charset, or are all such declarations bogus? (My blog has a <meta http-equiv="Refresh" content="1800" /> statement to refresh the page once an hour. I will happily ditch it if that's not legit. Setting a refresh rate, no matter how low, runs afoul of WAI-AA.)
3)There SHOULD be a <?xml version="1.0" encoding="iso-8859-1"?> statement to set the charset.
This is obvious.
Is it bogus just for setting the content-type and charset, or are all such declarations bogus? (My blog has a
<meta http-equiv="Refresh" content="1800" />statement to refresh the page once an hour.
I think you could remove the meta tag and add the Refresh as a HTTP Response header?
I sometimes only use a http-equiv for the annoying 'image toolbar' IE6 shows:
<meta http-equiv="imagetoolbar" content="no" />
I guess I could add this as a HTTP header too (if IE still sees it then), you can add additional header fields even if you make them up yourself (unrecognized fields should be ignored says the HTTP/1.1 specification).
A lot of people might try to repost, repost, and repost a comment when seeing an error message after submitting ;)
I know, that's exactly what happened yesterday. The authors of this weblog system agreed with me to send the admin pages as application/xhtml+xml by default. The problem is that this is still beta and there are bugs in it.
For the encoding 'problem': why is it a problem to add a charset declaration to the HTTP Content-Type header?
It should not be done through the meta element. That's just evil See the post for details.
Is it bogus just for setting the content-type and charset, or are all such declarations bogus?
No they are not. I should have been more specific (I hope people do read comments). But the one you show here as an example is not a really nice one, actually more nasty.
It is by the way recommended ([link]) that you do specify the charset with a http-equiv meta-tag (and of course an XML declaration) if you are unable to add the correct HTTP header tags.
So I don't think the http-equiv method is obsolete entirely... but this is still not clear to me (I can't find much in the specs and W3C list archives).
For XHTML, as opposed to any other form of XML, I think the relevant specification. here is "Section 3.2. application/xhtml+xml" on this page:
Here it says:
When serving an XHTML document with this [i.e.,
application/xhtml+xml] media type, authors SHOULD include the XML stylesheet processing instruction [XMLstyle] to associate style sheets.
... and here [XMLstyle] is the ref. Anne already gave.
But, as has already been pointed out, it is SHOULD not MUST. And in real-world terms, I guess the more important question is: "Would doing otherwise cause a problem for any UAs?"
In any event, I can't comment, as I don't serve my own pages, and so they go as text/html to all UAs. :-)
@Martijn, I was not talking about XHTML1.0 in that way . I was posting about XHTML1.0/1.1 served as application/xhtml+xml, which is different from serving it as text/html where you are refering to.
Two data points:
<style> element to the content model of <head>. I don't see anything which deprecates that usage.
<link rel="stylesheet" ...> and the <?xml-stylesheet ... ?> methods for linking to stylesheets (each stylesheet is referenced twice).
I can only presume that that's what the W3C suggests we do...
But - according to Firebird - they're serving that page as text/html, and in that case <link rel ...> would be OK.
But does it matter, in any case?
The whole picture seems confused. This site: Juicy Studio.
has this in the head:
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=ISO-8859-1" />
... but Firebird says it's getting text/html, so I guess the server isn't set up to deliver what the meta-tags imply.
Would doing otherwise cause a problem for any UAs?'
I serve application/xhtml+xml to the following:
I've just switched to using the stylesheet PI for those UAs. No problems in Firebird or Opera 7, and the CSS validator still finds them.
For those who are setting the Content-Type the 'right way,' i.e with .htaccess, this might be awkward to implement. If, like me, you're setting headers via a script, then it's trivial.
Would doing otherwise cause a problem for any UAs?
I assume you reply to my first post (second post of this conversation)? Yes, only using a xml-stylesheet PI will not work in older browsers and IE (but you knew this already).
For those who are setting the Content-Type the 'right way,' i.e with .htaccess, this might be awkward to implement. If, like me, you're setting headers via a script, then it's trivial.
I do both, and the second case is indeed a reason I made the suggestion. Conditionaly serving a certain Content-Type is one thing (and can be implemented by a quick hack as far as I'm concerned), but further differences in your documents for different browsers can become a real problem (and should always be tried to avoid).
But as pointed out by Jacques (comment 10), the W3C uses both methods of linking stylesheets in one document, without the 'reference by ID' I suggested, so I guess it is just fine to do it like they do.
Ah, I see I misinterpreted your post Sean (because you quoted Micheal and put my name in front of it) ;) That post has been mod edited, thats why the name isn't there anymore.
Sorry Martijn, Michael :-).
I've come across a couple of slight problems. First, Firebird doesn't want to save linked CSS, images, JS, etc. of any sort from a file server as application/xhtml+xml. Second, Opera won't grab the stylesheets or the images that they reference with just the PIs.
...or at least, such is my experience. There may be something else affecting this.
I once made an XML file with an XSLT sheet and IE6 handles it fine: landbouwbedrijven.xml
Hi all,
The whole picture seems confused. This site: Juicy Studio, has this in the head:
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=ISO-8859-1" />
Unfortunately, I'm at the mercy of my host. You can't set the content type with meta tags, it needs to be set in the HTTP header. My host removes the content type I set in the HTTP headers, and in fact doesn't return a content type at all. In the absence of a content type, it's treated as text/html. If I had more control over the server, I would serve text/html and a DOCTYPE of Strict XHTML1.0 to user agents that didn't understand application/xhtml+xml, and application/xhtml+xml and a DOCTYPE of XHTML1.1 to user agents that did.
Setting a content type of application/xhtml+xml with a meta tag was just my way of expressing that I wish I could serve that content type. Unfruitful (not juicy :) )
I think the recommendations of the W3C take this into account, which is why the wording is ambiguous. They want developers to serve XHTML1.1 as application/xhtml+xml, but appreciate that many developers are at the mercy of their hosts.
When I can afford it, I'll be serving the correct content type depending on the ability of the user agent.
Strict HTML 1.0 should be Strict XHTML 1.0 - sorry. I'm also not sure how you quote someone, hence the [quote] thingy. I hope I haven't offended anyone :)