We all know (I hope we do) that a XML document differs from a HTML document. Less people know that styling for a XML document is different from styling a basic web page. If I talk about a XML document this can be a XML document (a document that is not XHTML) or a XHTML document.
Currently there are only eighteen websites who are completely valid XHTML:
They are also known under the name X-Philes and are listed at the website of Evan Goer (it doesn't matter he uses HTML, it's all about the list). They may al be using the correct XHTML, but I think a couple of websites of that lists rely on a Mozilla bug (actually everyone who's using XML (XHTML) could have this problem, but since they sent it as text/html they get a quirky Mozilla I think (at least for the CSS)). So lets check it out, how many rely on this Mozilla bug: using application/xhtml+xml, the background of body fills entire viewport.
Two sites were currently "under construction", nine passed the test (including me :)) and seven failed this test, they styled the body element. For now it works, but who now what the future will bring...
If you are using XHTML, make sure you do it right. If you are still using XHTML 1.0 there may be no need to use the correct MIME-type at the moment, but I will help you to style the root element instead of the body element. Since IE doesn't understand it correctly, I made this really easy to implant hack:
html,body{
background: /* styles */ ;
}
html>body{ /* make sure there are no spaces within this selector */
background:none;
}
If IE6 is in standard compliant mode you may have noticed that the MS CSS extensions only work when you style the root element. If you haven't noticed (you could still use IE5.0 or 5.5 for browser testing) you should use the type selector html and body.
All this styling the root element made me thinking. If you style the root element and you linking to an external style sheet in the head element... isn't that incorrect? No apparently it is not, since my XHTML and my CSS (well that part) perfectly validate. But there are options: Associating Style Sheets with XML documents Version 1.0. It looks good, better then the solution we are using now, but the support may be low. I think I rather use my current method since it's well tested and still correct XHTML (though the xml-stylesheet processing instruction may be more logical and semantically).
Currently there are only eighteen websites who are completely valid XHTML
That seems a little presumptuous. As Jacques said, there's no guarantee that they're totally valid, and there's certainly no guarantee that every valid site is listed there.
Anyway. You have a point about styling the root element, but I think the special case for HTML (body is 'magical', not html) should be extended to XHTML. Nothing in head is meant to be displayed in the viewport, so why should its container element have any bearing on what goes on in the viewport? Surely HTML UAs are accepting a document, using the head for metadata and things that don't belong in the viewport, and the body for everything that does.
Think of it like an RSS feed. If you were able to style elements for use in an aggregator, you'd want to style content:encoded or xhtml:body, not item, rss, or rdf:RDF.
No, that's not right. The <body> element doesn't fill the viewport. Try it and see! Give the <body> a border, some margins, ...
OK?
Now, what happens in HTML is that the background of the <body> is propagated up to the root element which does fill the viewport.
This behaviour does not make sense in an arbitrary XML document. The only common feature of every XML document is that it has a root element and it makes perfect sense that the root element is taken to fill the viewport. It is a peculiarity of XHTML that it has a <body> element which is the unique displayable child element of the root element.
You could make up a special rule for styling XHTML (and only XHTML documents) that the background (but not other style attributes) of this element gets propagated up to the root element.
But that's kinda illogical and kludgy. If you want to style the whole viewport, style the root element, just as you would for any other XML document.
My whole site was checked I believe, but you are indeed right that this is different for the other people who are listed.
There should be no space for IE5.0/Windows, which will apply the rule if there are any.
(Thanks for the fix, Anne.)
This isn't 'any other' XML document. I know it is for the purposes of CSS--hence saying 'should' rather than 'is'--but that's not right.
Take away the DOCTYPE from an XHTML document, and send it to a browser as application/xml. As long as it's in the correct namespace (if it wasn't, it wouldn't be XHTML), both Opera and Firebird will know what to do with it. The html element is a wrapper for the head and the body, the viewport and the other stuff irrespectively.
There already are special rules for XHTML, borrowed over from HTML. As it is, body is nothing more than a one-time div.
What "special rules" are there for CSS styling XHTML documents, as opposed to CSS styling any other XML document? I'm not aware of any.
CSS doesn't know what kind of document it is styling. It could be styling an HTML document; it could be styling an XML document.
You say (and this is an arguable position) that XHTML should be treated like HTML, rather than as a particular case of XML. The W3C disagrees (and so do I).
I think this is an important philosophical distinction, that underlies a lot of the discussion and debate about XHTML. The W3C keeps saying XHTML is XML. Most web designers would prefer to believe that XHTML is just a fancy new version of HTML.
Since we've got a somewhat captive audience here, I'd like to point out a thread I noticed on www-style the past few days that's a little disturbing.
Essentially, moving beyond XHTML to custom XML DTDs is an accessibility problem; XHTML elements are known in advance, so user style sheets are possible.
Custom XML isn't. User style sheets would have to become site-specific, and that's more or less unreasonable.
Food for thought.
Sounds to me like this particular (set of) issue(s) might better be dealt with using client-side XSLT, rather than making CSS drastically more complicated:
"What would be needed is a rule that says (globally or for the elements that match a given selector, or set of selectors) 'if property P has value X, then use the initial value for P instead, and set property Q to value Y'. (This would involve primitive programming, in a sense, and would take CSS a little closer to a programming language."
But the more basic problem with custom XML DTDs impacts not just accessibility, but simple usability. You have to have *some* assurance that User-Agents support this XML dialect. (Look at my MathML pages in IE.)
If the browser supports that XML dialect, it is not unreasonable to have a user stylesheet which supports it too. It doesn't really matter whether the dialect is pure XHTML or XHTML+MathML or XHTML+fooML+barML.
Anyway, most of this is pretty theoretical, since virtually no one has ventured beyond vanilla XHTML, and there are still serious accessibility problems with the stuff that is out there.
I'm a bit late to this discussion... but just for the record, Jacques is right. I only check three secondary pages, and I don't monitor any of the sites going forward. So I can't guarantee that any given X-Philes site is 100% valid, nor can I guarantee that it will remain valid in the future.
You say (and this is an arguable position) that XHTML should be treated like HTML, rather than as a particular case of XML. The W3C disagrees (and so do I).
I don't necessarily disagree, but if a browser restricts the viewport to the body element, then it seems more consistent to me to make that element the one to style.
As far as I'm aware no-one will expect any other type of XML document to have an arbitary non-root element fill the viewport in CSS, but they will expect HTML's body to do so, because the browser knows what to do with that. The special rules aren't for the CSS, they're for what the browser's doing with the markup in the first place.
I'll agree to disagree, though. I know where you're coming from and you know where I'm coming from; we just look at it in a different way.
A custom XML format can be formatted sans hypertext by capable browsers. For example, the browser doesn't need to know what RSS is, but it's got XML and a stylesheet PI, so it can go forward: http://mar.anomy.net/pubxml....
How does client-side XSLT help in that case? I'm having a hard time getting my head around that, unless everything is devolved to spans and divs (or some other elements that don't clash with HTML). I suppose it would be a start at least, but then you have the problem of converting the original CSS to match the new element names.
Sean,
Why should we make an exception for XHTML? It is XML and why shouldn't it be styled that way? If you make it different for XHTML as opposed to "normal" XML it is getting more difficult and that is not what we want.
The rules to style and to markup your page should be general, understandable and easy. There shouldn't be an exception, 'cause this is XHTML which comes from HTML. It should be the same for every XML document. And since XHTML == XML we should style it that way. No matter what XHTML took from HTML.
I hope the above is understandable English, since I'm not that good at it (you should have noticed ;)).
Good points Jacques; I get the impression the poster was more worried about custom data-driven DTDs than those that require specialized rendering, eg. MathML and SVG.
But very much theoretical, and something I'm sure the appropriate working groups are on top of.
Like I said: see what your browser does with an XHTML document, sans DOCTYPE, properly namespaced, sent as application/xml. Is that generic XML, or has your browser made an exception for it?
[..] a browser restricts the viewport to the
bodyelement [..]
But that's just not true ;)
Like Jacques suggested, give your <body> a border, you'll see it doesn't always fit the entire viewport. You could also add this to your css:
head,title { display: block; }
You'll see the <head> element can be part of the viewport ;)
Anne: forgive me, I don't really get your note on the child selector (>) in the original entry. You say there shouldn't be a space because IE5.0/Win will apply the rule (and because it won't render the styles applied to <html> it won't render your background at all, or so I assume).
I don't have IE5.0/Win here to test this (IE6.0/Win has no problem with or without spaces), but I do see spaces around the child selector in your weblog style sheet. I'm confused and not sure I understand you correctly :)
I think Sean is under the misconception that the <body> fills the viewport. It doesn't in HTML and it doesn't in XHTML.
That's not why the background of <body> is applied to the entire viewport.
As to Anne's "no spaces" rule, I think the point is that you don't want IE 5.0/Win to apply the rule. You want it to apply the background to <body>.
Anne claims that IE 5.0/Win will apply the rule if you use the selector "html > body" but not if you use "html>body". I haven't tested this assertion, but it is crucial to this hack working as intended.
'no spaces': Yes, that's exactly what I understood from Anne's entry, but I was confused since he doesn't follow his own advice:
Ahem. You're both right about HTML: I did what I should have done and actually checked the CSS specificatiom. Apologies for the waste of time.
(Still think there's a case for body filling the viewport, though.)
Yes my style sheets are full of horror :). They get updated this week I think, when Arthur got the images for the new design ready.
Jacques is completely right by the way in explaining the "IE5 rule".
Out of curiousity, which of the X-Philes sites failed the test?
I use background on the root (html) and body. Can't remember why it was necessary to do it on both, but it was. Would this "fail" me?
Not in the test, but number twenty would have failed the test: style sheet sidesh0w.
Your solution is correct. However it could give problems if you are using background images with patterns for example. Not now, since Mozilla has still a bug. It is "saver" when you use this piece of CSS:
html>body{background:none;}
I use background on the root (
html) andbody. Can't remember why it was necessary to do it on both, but it was. Would this "fail" me?
The way the criteria are currently defined, no.