Sun, 2006-02-05 11:12
I've been playing around with a PHP content negotiation script for a site and when the new page was served as XHTML 1.1 and application/xhtml+xml (instead of 1.0 and text/html), the background image I had attached to the body suddenly started and stopped about 10px from the top & bottom of the page.
So I moved the background image to the html element and it was fine again.
So what would've been the cause of the difference?
Sun, 2006-02-05 11:44
#1
application/xhtml+xml and the HTML & body elements
In xhtml, <html> is just an element, as is <body>. It will lead to surprising results. I shall leave it to the more technical minded to be more specific. Simply giving the two different bg colors while leaving all other properties undefined will give you some idea.
cheers,
gary
Sun, 2006-02-05 12:14
#2
application/xhtml+xml and the HTML & body elements
Had you set margin and padding to 0 on the body?
That space will have come from the browser default styling, e.g. FF ...
html, div, map, dt, isindex {
display: block;
}
body {
display: block;
margin: 8px;
}
<snip>
/* hidden elements */
area, base, basefont, head, meta, script, style, title,
noembed, noscript, param {
display: none;
}
fwiw, you don't have to go to xhtml1.1 to serve documents as application/xhtml+xml. Take a look at kk5st's pages and follow how he's done it (that's what I did 
). Also the "<?xml" processing instruction isn't a mandatory requirement for either XHTML1.0 or XHTML1.1 - as long as you use utf8 or utf16.
Sun, 2006-02-05 12:30
#3
application/xhtml+xml and the HTML & body elements
Chris..S wrote:
Had you set margin and padding to 0 on the body?
No, I'd used the * to zero it for everything.
As for 1.1 v 1.0, I've tried it out on a couple of sites as 1.1 so far and it seems fine.
As for the charset, when I tried changing to utf-8 for the first site I tried I got a validator error about some character at position 11,111 and it couldn't continue the process. :? So I went back to iso-8859-1.
Are there particular advantages/disadvantages to one method over the other? All the content negotiation articles I've come across have included the XML prologue (and iso-8859-1).
Sun, 2006-02-05 13:39
#4
application/xhtml+xml and the HTML & body elements
I think there is advantages in using utf-8. Its capable of representing just about any character/glyph you can think of. Which means if your site happens to need to serve up some korean or viking or whatever there is no extra thought or configuration required.
For utf-8, at least in Apache's case, you need to fix up your httpd.conf and php.ini to remove the common out of box iso-8859-1 setting.
Sun, 2006-02-05 14:14
#5
application/xhtml+xml and the HTML & body elements
This thread and making the earlier post caused me to review my settings again.
I discovered that although I had set the page up correctly as application/xhtml+xml, the webserver was still serving it as text/html, as per the response header information in FF. A quick investigation and I had a page served properly as xhtml+xml (application/xhtml+xml example). Only IE really can't handle it. Apparently there is a work around, but I couldn't get it to work. An alternative is to server the document as application/xml which IE does seem to be able to cope with (application/xml example)
Sun, 2006-02-05 14:51
#6
application/xhtml+xml and the HTML & body elements
And all to what avail I was playing around with a content negotiation script for fun , interesting but unless your using the extensibility fairly pointless.
If your going to use 1.1 - and as Chris says you can serve 1.0 as application/xhtml+xml- then you really have to sort the character set as it must be served as utf-8/16 not iso-8859.
One thing I did find though with the layout was that with body html zeroed and a fixed graphic on the body, a wrapper with a top margin to push it away from the top of the viewport I ended up with graphic and wrapper pushed away top and bottom.
The html element does exist as it's own distinct element separate from body I had just collapsed the wrapper through body to the html element; 1px padding on the body sorted things.
Out of interest the script I took was from the keystone website but I modified it as I didn't like the fact that it didn't place a meta character set if the page was served as html and left the cdata sections in place for style tags.
It's a funny old life reading this post I started revisiting my script and noticed a little anomaly which in trying to fix up kept crashing my editor loosing all my tabbed work pages 
What helps is not to look at the end of an xml prolog declaration and assume it's a closing php tag, especially when ones text editor confuses you by syntax highlighting it as php.
Some days it's like trying to drag ones mind through a tar pit :roll:
Hugo.
Sun, 2006-02-05 19:04
#7
application/xhtml+xml and the HTML & body elements
Tyssen wrote:
Look at the server response header. Most servers use Latin-1 or ASCII as the default setting. You will need to specify utf-8, as you must for xhtml+xml. Your .htaccess file can do that. If you upload utf-8 to the server and it delivers Latin-1, all the characters >0xff will not be in proper entity form, eg., &emdash; or ’. The reverse is always ok. If you upload ASCII with entities, and serve as utf-8, it always works ok. As for the charset, when I tried changing to utf-8 for the first site I tried I got a validator error about some character at position 11,111 and it couldn't continue the process. Confused So I went back to iso-8859-1.
cheers,
gary
Sun, 2006-02-05 19:19
#8
application/xhtml+xml and the HTML & body elements
:? Or if your using a php content negotiation script then set the server response mime type and character set using the php headers function
after having quizzed the http accept header for preferred type that way you're able to switch back and fourth, although the argument would run that it's better to be using utf-8 regardless
Hugo.
Sun, 2006-02-05 19:55
#9
application/xhtml+xml and the HTML & body elements
Is switching useful?
You also need to have the capability to convert your output data into the chosen charset. Ok, that's trivial if your data is ascii, but once you require any other character outside ascii (e.g. £ â¬) you are going to have to ensure you detect and convert it appropriately. Is that really worth it?
All modern browsers support utf-8 and have done for some time. iso-8859-1 seems to be laziness on the part of software package configurers. Especially as for North America there would be almost no danger in making the change - iso-8859 and utf-8 are both supersets of ascii.
kk5st, in your .htaccess file do you use ... ?
addDefaultCharset off
Sun, 2006-02-05 21:48
#10
application/xhtml+xml and the HTML & body elements
Quote:
On my local net, the server has that in httpd.access.
kk5st, in your .htaccess file do you use ... ?
addDefaultCharset off
On my freebie host, I haveAddDefaultCharset utf-8in the root directory .htaccess file.
I also haveAddType application/xhtml+xml .xhtml .xhtin their respective files so that a document identified as xhtml by the extension will be served as application/xhtml+xml.
For clients, where it is always text/html, I tend to give them Latin-1 unless utf-8 is explicitly ok'd. (I have forgot, at times, to change Emacs from utf-8 to ASCII. 
)
cheers,
gary
Sun, 2006-02-05 22:27
#11
application/xhtml+xml and the HTML & body elements
A little addendum:
Quote:
Not laziness, but standards. I can't recall the location of the recommendations at the moment, but loosely translated, when the character set is unspecified, html shall default to Latin-1 (iso-8859-1)[1], and an xml document (including xhtml of the proper MIME type) shall default to utf-8 [2] All modern browsers support utf-8 and have done for some time. iso-8859-1 seems to be laziness on the part of software package configurers.
cheers,
gary
[1] Found'em! See rfc2616 sect 3.7.1
[2] For xml, Appendix F Autodetection of Character Encodings (Non-Normative)
Sun, 2006-02-05 22:53
#12
application/xhtml+xml and the HTML & body elements
Hugo wrote:
And all to what avail
I decided to look into it a bit more after reading a thread on Sitepoint where Tommy Olsson (Autistic Cuckoo) was bemoaning the fact that so many sites proclaim to be XHTML when they actually aren't. I can your point about it being fairly pointless, but I can also see the other side where if you're going to use an XHTML DTD, you should really be following the W3C's guidelines as well (rather than the 'may' that using 1.0 with text/html falls under).
I had another go using the utf-8 charset and managed to work out what the validator was telling me - it wasn't line 11,111, it was lines 11 and 111 that had an illegal character. Unfortunately, when using utf-8, the validator warnings aren't nearly as precise as to what the nature of the problem is.
Sun, 2006-02-05 23:13
#13
application/xhtml+xml and the HTML & body elements
'May' is perfectly acceptable as things stand, I've read many things on this , too many, all seem to get the arguments slightly wrong there is an acceptable method of delivering xhtml as text/html as long as one knows the conditions that must be met, but the real point is that unless one is making use of the eXtensible nature of xhtml it shouldn't be used at all , the fact is that too many people think there is something to be gained from using xhtml, there isn't, whether it's served as text/html or application/xhtml+xml.
Html strict is every bit as valid still and in honesty the correct dtd to write html to.
Chris laziness is not the issue as Gary pointed out also for a time there were problems to found with using utf-8
I think you may be over thinking things my reference to switching was to output headers to send iso-8859 for html or utf-8 for xhtml, I used it and it works ok.
Hugo.