Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Sun, 11 Mar 2007, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. find replacements for * link rev We removed rev= because it was only used correctly for one thing (rev=made) and was misused a _lot_, and the number of people using rel=author was comparable (I forget the exact numbers). * a name This was removed purely to simplify the language. * empty a elements Those are legal now. * hr size * img align * table align * table width * td align Those should all be removed anyway to improve your content/style separation, which would aid with maintenance. (I'm assuming here that you'd want to transition the document only if it was a document in active development, in which case maintenance is relevant. If maintenance is not relevant, there's no reason to transition the document.) * review whether I use any so-called predefined classes and if, whether I use them correctly, or find out how to replace them These are gone now. * review whether I am MicroformatsOK according to the latest Wiki pages HTML5 doesn't require this any more than HTML4 now. * review whether my img elements are really some piece of text with some alternate graphical representation This you should do anyway for accessibility reasons. * review whether my images are all the exact size given in the height and width attributes This you should do anyway to obtain quality results. and so on, whereas switching to XHTML would simply be a matter of running HTML Tidy on all the files and lowercasing the selectors in the style sheets? It's a lot of work if I just want to add my favourite HTML5 feature to the page. Well, that's what you get for using a Transitional markup language without intending to transition. :-) Note that moving to XHTML 1.1 would require many of the same changes, since it also omits the Transitional features. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Removing @rev is harmful for Lynx because that is how it decides who the author is. At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current document if the author of the document has specified ownership. (Note to authors: if you want to assign the ownership to your document, you need to add into HEAD section a LINK element with appropriate value for REV attribute. Two values are recognized: owner and made (these are case insensitive). For example, HEAD ... LINK REV=made HREF=mailto:[EMAIL PROTECTED] ... HEAD (Attn. lynx-dev: that should be a closing tag!). (http://lynx.isc.org/lynx2.8.6/lynx2-8-6/lynx_help/Lynx_users_guide.html#Mai l) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, May 13, 2008 11:38 AM To: Bjoern Hoehrmann Cc: L. David Baron; [EMAIL PROTECTED] Subject: Re: [whatwg] Configure Apache to send the right MIME type for XHTML On Sun, 11 Mar 2007, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. find replacements for * link rev We removed rev= because it was only used correctly for one thing (rev=made) and was misused a _lot_, and the number of people using rel=author was comparable (I forget the exact numbers).
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Tue, 13 May 2008, Křištof Želechovski wrote: Removing @rev is harmful for Lynx because that is how it decides who the author is. At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current document if the author of the document has specified ownership. (Note to authors: if you want to assign the ownership to your document, you need to add into HEAD section a LINK element with appropriate value for REV attribute. Two values are recognized: owner and made (these are case insensitive). For example, HEAD ... LINK REV=made HREF=mailto:[EMAIL PROTECTED] Removing rev= from the spec doesn't preclude Lynx still supporting it for legacy documents, and for new documents, rel=author is preferred and is trivially supportable given support for rev=made, so I don't think this is a particularly convincing argument. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
* L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. find replacements for * link rev * a name * empty a elements * hr size * img align * table align * table width * td align and then * review whether I use any so-called predefined classes and if, whether I use them correctly, or find out how to replace them * review whether I am MicroformatsOK according to the latest Wiki pages * review whether my img elements are really some piece of text with some alternate graphical representation * review whether my images are all the exact size given in the height and width attributes and so on, whereas switching to XHTML would simply be a matter of running HTML Tidy on all the files and lowercasing the selectors in the style sheets? It's a lot of work if I just want to add my favourite HTML5 feature to the page. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Sunday 2007-03-11 18:26 +0100, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. The distinction here is that all of these are either removed features or correctness of document semantics, and therefore don't affect implementation behavior. An implementation that implements both HTML4 and HTML5 will handle all of them, and therefore authors can transition gradually between the two (although they'll technically not be conformant to either while doing so, and many may well stay in that state permanently). (The value of having these things as changes in HTML5 comes from authors who use conformance checkers that will tell them to avoid these bad practices, not from implementations behaving differently.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpl5KXWWV5cH.pgp Description: PGP signature
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
* Leons Petrazickis wrote: Though Michael's homepage is invalid, it remains well-formed. Michael is arguing for the inhert value of XML well-formedness, not validity. The tool you've used to determine that does not work correctly. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Thu, 08 Mar 2007 05:04:20 +0100, Michael Day [EMAIL PROTECTED] wrote: One downside of using HTML is that errors in the document can cause odd behaviour and can be harder to track down than errors in XML/XHTML. Using an HTML4 validator or HTML5 conformance checker to ensure that the document won't trigger error recovery is always a good idea. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Benjamin Hawkes-Lewis skrev: When I talked to WebKit developers about this, it seemed they considered their support for real XHTML less reliable than their support for HTML at that point. So while Safari's Accept header may be suboptimal, there's nothing terribly wrong with interpreting it the same as IE and serving it HTML instead. Which means that if I sniff for Safari I will continue to send text/html even when that browser has solved its problems with application/xhtml+xml I see this whole discussion as an exact equivalent of object detection vz. browser sniffing in JavaScript. I also think it is getting rather off topic You know (X)HTML 5! Lars Gunther
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Mar 7, 2007, at 7:09 AM, Michael(tm) Smith wrote: ... Amen. It's really amusing to see people continuing to trot out matter-of-fact statements dismissing XHTML. Those statements seem to fall into two basic types that can be paraphrased as either: - The only people who author documents in XHTML are naive developers/designers who do it just because they have been mislead into thinking that it's the cool/right thing to do. - The only people who user/serve-up XHTML are pedants who are out of touch with browser/implementation realities. It seems to me that those who make such statements either: - are unaware of any useful things that can be done with documents other than just displaying them in browsers -- or about how having those as well-formed XML can potentially make it easier to process them - have an agenda that makes them (consciously or unconsciously) want to dissuade others from using XHTML/XML (and XSLT, etc.) and to instead use alternatives (whatever alternatives they happen to personally be promoting) Or they realize that even those who (1) know what they're doing and (2) care, still get things wrong: http://validator.w3.org/check?uri=http%3A//people.w3.org/mike/ -ryan PS - my homepage is invalid, too: http://validator.w3.org/check? uri=http%3A//theryanking.com/blog/
[whatwg] Configure Apache to send the right MIME type for XHTML
Readers of this list may get a kick out of my latest developerWorks article: Configure Apache to send the right MIME type for XHTML http://www-128.ibm.com/developerworks/xml/library/x-tipapachexhtml/ As this list has flamed about repeatedly, XHTML documents are supposed to be tagged as application/xhtml+xml when sent over HTTP. However Internet Explorer doesn't like that and won't display such a document. This article explains how to hack the problem by tagging a document as text/html for IE (and Lynx) and application/xhtml+xml for everyone else. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Alexey Feldgendler wrote: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Documents on the web aren't just about browsers, and certainly not just about IE. There are many interesting things you can do with XHTML documents you can't do with non-well-formed HTML documents. Personally I'm most enamored of using XSLT to process them. However, the biggest benefit for most developers is likely to be the simpler, cleaner, more reliable DOM you get with a well-formed document. If you can go to valid strict XHTML, the benefits get even larger. If your primary experience with HTML is displaying it in a browser, this may not be apparent; but for those of us who have to write code to process this stuff well-formedness and simplicity are major advantages. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Mar 7, 2007, at 9:12 AM, Elliotte Harold wrote: Alexey Feldgendler wrote: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Documents on the web aren't just about browsers, and certainly not just about IE. There are many interesting things you can do with XHTML documents you can't do with non-well-formed HTML documents. Or export them to PDF via PrinceXML, for example. The ability to mark up content once but publish it twice, in a usable, attractive format both for the web and for print, gives XHTML tremendous practical value for web publishers. It isn't just theoretical or fashionable anymore. _ David Walbert LEARN NC, UNC-Chapel Hill [EMAIL PROTECTED]
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Elliotte Harold [EMAIL PROTECTED], 2007-03-07 09:12 -0500: Alexey Feldgendler wrote: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Documents on the web aren't just about browsers, and certainly not just about IE. There are many interesting things you can do with XHTML documents you can't do with non-well-formed HTML documents. Personally I'm most enamored of using XSLT to process them. However, the biggest benefit for most developers is likely to be the simpler, cleaner, more reliable DOM you get with a well-formed document. If you can go to valid strict XHTML, the benefits get even larger. If your primary experience with HTML is displaying it in a browser, this may not be apparent; but for those of us who have to write code to process this stuff well-formedness and simplicity are major advantages. Amen. It's really amusing to see people continuing to trot out matter-of-fact statements dismissing XHTML. Those statements seem to fall into two basic types that can be paraphrased as either: - The only people who author documents in XHTML are naive developers/designers who do it just because they have been mislead into thinking that it's the cool/right thing to do. - The only people who user/serve-up XHTML are pedants who are out of touch with browser/implementation realities. It seems to me that those who make such statements either: - are unaware of any useful things that can be done with documents other than just displaying them in browsers -- or about how having those as well-formed XML can potentially make it easier to process them - have an agenda that makes them (consciously or unconsciously) want to dissuade others from using XHTML/XML (and XSLT, etc.) and to instead use alternatives (whatever alternatives they happen to personally be promoting) I don't think anybody can find fault with developers who speak from experience and say they don't personally use/serve-up XHTML because for their specific needs they see no value in doing so. But that's a whole different thing than making matter-of-fact blanket/wholesale dismissals of XHTML -- statements that imply that no other sane/hip developer could potentially find value in use of XHTML. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Alexey Feldgendler schrieb: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Why would a P inside LI be illegal in HTML? Best regards, Julian
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 13:27:23 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: http://www-128.ibm.com/developerworks/xml/library/x-tipapachexhtml/ This seems worse than http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html which was written long ago. However, that article also has some flaws in not taking into account q values properly. Subsequent articles appeared on the web that have addressed this problem. The solution from your article might give trouble for search engines, for instance. Then of course there are some interoperability issues with XHTML and entities that haven't really been sorted out yet... Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Anne van Kesteren wrote: Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. Personally I'm happy just sending XHTML as text/html and letting the browsers and other tools do what they like with it. I don't hold to the belief that the MIME type is holy writ from GOD that clients must not modify for their convenience under penalty of hellfire and damnation. Nonetheless, some people do seem to believe that so this article offers them a reasonable alternative. If one were conspiratorially minded, one might begin to wonder whether any reasonable alternative will be accepted, or if a lot of the arguments and claims are really designed merely to eliminate XHTML from consideration by making it too inconvenient for practical development. The insistence on sending XHTML as application/xhtml+xml is pretty pedantic, and without a lot of practical benefit. It's strange to see such a picky point being made by the same people who aren't all that interested in the much more useful standard of well-formedness. It's also strange that these are the same folks who are bending over backwards to maintain compatibility with older browsers in every area except this one little HTTP header field. Indeed, if one were of a suspicious turn of mind, one might think the insistence on sending XHTML as application/xhtml+xml were nothing but a strategy to make XHTML so practically inconvenient that no one would consider it. But I don't have such a suspicious mind, so I'm sure it's all honest disagreement. :-) -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Anne van Kesteren wrote: This seems worse than http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html which was written long ago. However, that article also has some flaws in not taking into account q values properly. Subsequent articles appeared on the web that have addressed this problem. The solution from your article might give trouble for search engines, for instance. How so? Then of course there are some interoperability issues with XHTML and entities that haven't really been sorted out yet... Such as? -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Anne van Kesteren wrote: Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. HTML is the exchange format only when there's a human in the loop. HTML is really only suited for exchanging certain basic kinds of narrative documents for eventual display to people, who will do the heavy labor of interpreting them. However, there's a lot more than that on the Web, and those use cases aren't really served by HTML at all, not even XHTML. I suspect my definition of the web may be broader than yours, and that may be why we disagree. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Elliotte Harold wrote: Indeed, if one were of a suspicious turn of mind, one might think the insistence on sending XHTML as application/xhtml+xml were nothing but a strategy to make XHTML so practically inconvenient that no one would consider it. I think I don't understand. The difficulty with XHTML has never been about setting the correct MIME type -- this is relatively trivial if you have access to any sort of server configuration. The issue has always been with the fact that browsers process application/xhtml+xml as XML and, sadly, the error handling requirements of XML make it unsuited for the web. Therefore it is undesirable for all but a statistically insignificant fraction of authors to actually make the configuration change. Hopefully we will be able to come up with some solution that combines the supposed benefits of XHTML (principally the ability to embed mathematics and vector graphics*) with the workable error handling model of HTML. *We already have the ability to process HTML documents with an XML toolchain by virtue of the HTML5 parsing/treebuilding algorithm. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:13:42 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Indeed, if one were of a suspicious turn of mind, one might think the insistence on sending XHTML as application/xhtml+xml were nothing but a strategy to make XHTML so practically inconvenient that no one would consider it. But I don't have such a suspicious mind, so I'm sure it's all honest disagreement. :-) You can just give your files an XML MIME type (.xml extension). That will work fine in most browsers. XHTML also works fine with the text/html MIME type (.htm extension), but then it won't be parsed as XML by your typical web browser. This shouldn't be new information though... If you're after the fact that browsers don't sniff for XML in text/html that's because the old HTML WG said so (there's a pointer somewhere out there) and changing that now is impossible given how many authors got XML as text/html completely wrong. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:14:04 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: This seems worse than http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html which was written long ago. However, that article also has some flaws in not taking into account q values properly. Subsequent articles appeared on the web that have addressed this problem. The solution from your article might give trouble for search engines, for instance. How so? Well, your article advocates sniffing specific user agents where the one written by Mark Pilgrim uses the Accept: header which was actually designed for this... Google, for one, is known for not supporting XHTML really well. Then of course there are some interoperability issues with XHTML and entities that haven't really been sorted out yet... Such as? Well, since browsers have non-validating XML parsers you actually can't use entities, but then you can because they have some build in knowledge for certain DOCTYPEs... However, this is not guaranteed to be cross browser. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 16:14:40 +0100, Julian Reschke [EMAIL PROTECTED] wrote: Interesting, but not of much use. If an author really wants to support MSIE, she needs to not only ensure that MSIE tries to render the document at all by setting its MIME type to text/html, but also to not use anything XHTML-specific that isn't possible in HTML, e.g. p inside li, or inline SVG. And if one isn't going to use these features anyway, there is no reason to prefer XHTML over HTML other than following the fashion. Why would a P inside LI be illegal in HTML? My fault. Should actually read: ul inside p. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cem%3E%3Cp%3EX -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Anne van Kesteren wrote: How so? Well, your article advocates sniffing specific user agents where the one written by Mark Pilgrim uses the Accept: header which was actually designed for this... Google, for one, is known for not supporting XHTML really well. I'm not doing content negotiation here. There's one representation available. It is XHTML. We can send that to most browsers and they'll deal reasonably. Two I know of have problems (IE and Lynx) so we lie to them and tell them it's text/html. I am curious what problems Google has with XHTML. Then they deal. Then of course there are some interoperability issues with XHTML and entities that haven't really been sorted out yet... Such as? Well, since browsers have non-validating XML parsers you actually can't use entities, but then you can because they have some build in knowledge for certain DOCTYPEs... However, this is not guaranteed to be cross browser. What browsers can't handle this? Theoretically, it is completely spec compliant for a browser to notice PUBLIC identifier in the DOCTYPE, use that to resolve entities or do whatever else it needs to do with that DTD, and never actually load the file at the SYSTEM ID. You absolutely can use all defined entities that are available in XHTML 1/HTML 4. Practically, that's exactly what happens in every browser I've tested, but there might be one I've missed somewhere. If you meant that you can't define new entities, then that's essentially correct. That's also true of HTML of course. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:20:29 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. HTML is the exchange format only when there's a human in the loop. HTML is really only suited for exchanging certain basic kinds of narrative documents for eventual display to people, who will do the heavy labor of interpreting them. However, there's a lot more than that on the Web, and those use cases aren't really served by HTML at all, not even XHTML. I agree that XHTML really covers more use cases than HTML because XHTML is a richer language (can represent a wider set of DOM trees). But because your article is about serving XHTML in an MSIE-compatible way, the requirement of compatibility with MSIE effectively bars the author from fulfilling those extra use cases. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Thursday 2007-03-08 00:09 +0900, Michael(tm) Smith wrote: It's really amusing to see people continuing to trot out matter-of-fact statements dismissing XHTML. Those statements seem to fall into two basic types that can be paraphrased as either: My dismissal doesn't fall into either of those types. My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). For example: * The W3C XHTML Working Group insists that all the HTML-specific statements in CSS don't apply to XHTML (and got the CSS working group to put this into the CSS specs). This means that an author converting HTML to XHTML doesn't need to just convert the syntax used in their markup (including case of tags), they may also need to make significant redesigns to their CSS to avoid depending on the HTML-specific rules in CSS. * When namespace APIs were added in DOM Level 2, the W3C DOM Working Group insisted that HTML (which has no concept of namespaces) be reflected into those APIs as though it were a series of elements in no namespace. This is different from the way XHTML is reflected, which means that in many cases it is significantly harder than it should be to write a script that works with both XHTML and HTML (which is necessary for site-wide scripts when one is starting to use XHTML on a site, especially if the use case for switching to XHTML is compound documents, where there might be elements called a that aren't HTML a elements). Fortunately the WHATWG HTML5 spec reverses this bad decision. Almost all of the claimed advantages of XHTML come from its XML-ness, so why keep adding more incompatibility just for purity's sake? My dismissal of XHTML is that if those designing standards that are not yet widely adopted (compared to HTML) keep making it harder and harder to transition, they'll prevent that transition from ever occurring. And if that transition is never going to occur on a large scale, why worry about it? -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpEGHw5cO4FD.pgp Description: PGP signature
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Alexey Feldgendler wrote: If you are going to write XHTML documents whose DOM is not representable in HTML, then your documents won't be compatible with MSIE, and you won't need the described MIME type trick. OTOH, if you are going to restrict yourself to XHTML documents whose DOM is representable in HTML, then you might as well use HTML. It has been said many times here that virtually every single advantage that XHTML has over HTML4 is now also inherent to HTML5 (predictable DOM, processing with XSLT, etc). Neither is really my point. The problem with malformed HTML is that it has an inconsistent DOM. You get different DOMs in different browsers and tools. Making a document well-formed XHTML gives you a consistent, reproducible, predictable DOM. If you go one step further and make the document valid strict XHTML, the DOM gets even simpler and cleaner. Many nodes are pruned from the tree. This makes it easier still to manage. It's not about whether we can represent a DOM in HTML or not. It's about consistency and simplicity. I'm not the first to point this out by any means, but I don't think it's been as widely recognized as it should. I suspect that's because many developers working with HTML aren't really using the DOM at all. They're hacking the text with IDs, document.write, innerHTML, and other tricks that don't really pay attention to the tree structure of the document they're working on. That may be a chicken-and-egg problem: as long as the document is malformed even figuring out what the tree is is nearly impossible and not cross-browser. With HTML 5 parsers (which we don't have yet) the DOM of malformed documents may yet become predictable, but it won't ever be obvious. And it may well not be consistent across browsers unless Microsoft jumps on board. By contrast, valid strict XHTML (probably transitional too) has a reasonably consistent tree structure in all browsers today. Once you achieve well-formedness you can begin looking at the document in a new way. You get access to powerful tools like XPath and XSLT that you didn't have before. You can start doing more than merely tossing the page at a browser for rendering. And you don't have to wait for an HTML 5 parser to do it either. You can do it today with a large tool chain. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 19:14:25 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Neither is really my point. The problem with malformed HTML is that it has an inconsistent DOM. You get different DOMs in different browsers and tools. Making a document well-formed XHTML gives you a consistent, reproducible, predictable DOM. Making a document conformant HTML gives you a consistent, reproducible, predictable DOM. Even more: a non-conformant document, when parsed with a HTML5 parser, also gives a predictable DOM. With HTML 5 parsers (which we don't have yet) the DOM of malformed documents may yet become predictable, but it won't ever be obvious. And it may well not be consistent across browsers unless Microsoft jumps on board. By contrast, valid strict XHTML (probably transitional too) has a reasonably consistent tree structure in all browsers today. The DOM of valid HTML documents is predictable and consistent across browsers today. Once you achieve well-formedness you can begin looking at the document in a new way. You get access to powerful tools like XPath and XSLT that you didn't have before. You can start doing more than merely tossing the page at a browser for rendering. And you don't have to wait for an HTML 5 parser to do it either. You can do it today with a large tool chain. You can use XPath and XSLT on a DOM tree obtained by parsing HTML, can't you? If your HTML is valid, you don't even have to wait for an HTML5 parser -- a variety of HTML4 parsers is available today. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Henri Sivonen wrote: TagSoup exists today. Yes, and I use it. However it constantly surprises people in the markup it generates, as hanging out for a day or two on the tagsoup-friends mailing list will show. That's not it's fault. There's just no one obvious way to fix all the broken markup that's out there. TagSoup picks one approach. HTML 5 picks another. Both will surprise people a lot of the time. At the parser level that can't be helped. However at the document level it can be helped. When the document author takes the care to generate a well-formed document, they are rarely surprised by the resulting tree the parser builds. The tree is explicit in the markup. Explicit markup is more obvious and less surprising than the implicit fill-in both TagSoup and HTML 5 do. Hmm, that brings up another question. Does the HTML 5 fixup algorithm ever change the *tree* for a well-formed (but invalid) document? For instance, if it finds an li element that is a child of a p, what would it do? Either ignoring the li/li tags, skipping the li element completely, or filling in a ul element would all change the tree. I suspect it does one of these three things (or something similar like filling in an ol element) but without opening the spec or writing a sample program, I can't tell you which. By contrast with a real XML parser, I can tell you what's going to happen without cracking open the spec. HTML5, TagSoup, and XML parse trees are all deterministic and thus predictable; but only the XML tree is *obvious*. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 20:04:08 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Yes, and I use it. However it constantly surprises people in the markup it generates, as hanging out for a day or two on the tagsoup-friends mailing list will show. That's not it's fault. There's just no one obvious way to fix all the broken markup that's out there. TagSoup picks one approach. HTML 5 picks another. Both will surprise people a lot of the time. At the parser level that can't be helped. However at the document level it can be helped. When the document author takes the care to generate a well-formed document, they are rarely surprised by the resulting tree the parser builds. The tree is explicit in the markup. Explicit markup is more obvious and less surprising than the implicit fill-in both TagSoup and HTML 5 do. There's nothing surprising in the DOM that TagSoup generates when parsing a valid HTML4 document. Hmm, that brings up another question. Does the HTML 5 fixup algorithm ever change the *tree* for a well-formed (but invalid) document? There is no notion of well-formedness for HTML. A document is simply either conformant to HTML5 or not. For instance, if it finds an li element that is a child of a p, what would it do? Either ignoring the li/li tags, skipping the li element completely, or filling in a ul element would all change the tree. That would be a non-conformant document. According to HTML5, such document will be parsed into a tree which, when serialized, would result in text different from the text of the original (non-conformant) document. I suspect it does one of these three things (or something similar like filling in an ol element) but without opening the spec or writing a sample program, I can't tell you which. By contrast with a real XML parser, I can tell you what's going to happen without cracking open the spec. HTML5, TagSoup, and XML parse trees are all deterministic and thus predictable; but only the XML tree is *obvious*. HTML5 unambiguously defines what should happen. To summarize: 1. Parsers in today's browsers generate predictable DOM for valid HTML4 documents. 2. A conformant HTML5 parser generates predictable DOM for both conformant and non-conformant HTML5 documents. Also, the result of parsing a valid HTML4 document with a today's browser, as well as the result of parsing a conformant HTML5 document with a conformant HTML5 parser, are both predictable and obvious (i.e. it doesn't require actually performing the complex HTML5 parsing alorithm in your mind to predict the resulting DOM). So, if you stick to valid HTML4 (or, in the future, conformant HTML5), you'll get both predictable and obvious results. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On 7 Mar 2007, at 17:07, Anne van Kesteren wrote: If you're after the fact that browsers don't sniff for XML in text/ html that's because the old HTML WG said so (there's a pointer somewhere out there) and changing that now is impossible given how many authors got XML as text/html completely wrong. http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html – that's the post Anne is referring to (I know of no other time that the HTML WG have said anything on this issue). - Geoffrey Sneddon
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 17:46:43 -, Elliotte Harold [EMAIL PROTECTED] wrote: How so? Well, your article advocates sniffing specific user agents where the one written by Mark Pilgrim uses the Accept: header which was actually designed for this... Google, for one, is known for not supporting XHTML really well. I'm not doing content negotiation here. From HTTP point of view you are. There's one representation available. It is XHTML. We can send that to most browsers and they'll deal reasonably. Two I know of have problems (IE and Lynx) so we lie to them and tell them it's text/html. Use of Accept does not require you to return completly different representations, you can use it just like you used User-Agent. However Accept contains exactly the information you're trying to (and failing to) derive from User-Agent header. I am curious what problems Google has with XHTML. Then they deal. Last time I checked they were marking XHTML documents as Unknown format. Since Google certainly has engineers aware and capable of fixing this problem, Google must be ignoring XHTML deliberately. I suspect they support only what works for their customers and XHTML in XML mode doesn't work for vast majority of them. User-agent sniffing is a bad practice - it's inaccurate, hurts minority browsers and is not forward-compatible. Please change your method to use Accept header, so it won't be affecting any HTML-only user-agents (web is more than a handful of desktop browsers). Accept method will even work for MSIE and Lynx when/if they start supporting XHTML. Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. -- regards, Kornel Lesiński
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Mar 7, 2007, at 8:13 AM, Elliotte Harold wrote: Anne van Kesteren wrote: Personally I'd just give everyone HTML unless they specifically ask for XML and even then those tools should be capable of handling HTML imo. After all, it's the exchange format of the web. Personally I'm happy just sending XHTML as text/html and letting the browsers and other tools do what they like with it. I don't hold to the belief that the MIME type is holy writ from GOD that clients must not modify for their convenience under penalty of hellfire and damnation. Nonetheless, some people do seem to believe that so this article offers them a reasonable alternative. If one were conspiratorially minded, one might begin to wonder whether any reasonable alternative will be accepted, or if a lot of the arguments and claims are really designed merely to eliminate XHTML from consideration by making it too inconvenient for practical development. The insistence on sending XHTML as application/xhtml+xml is pretty pedantic, and without a lot of practical benefit. It's strange to see such a picky point being made by the same people who aren't all that interested in the much more useful standard of well-formedness. It's also strange that these are the same folks who are bending over backwards to maintain compatibility with older browsers in every area except this one little HTTP header field. Indeed, if one were of a suspicious turn of mind, one might think the insistence on sending XHTML as application/xhtml+xml were nothing but a strategy to make XHTML so practically inconvenient that no one would consider it. But I don't have such a suspicious mind, so I'm sure it's all honest disagreement. :-) HTML5 will make it easier to make valid HTML/XHTML hybrid documents by legalizing certain XML-specific constructs in HTML and defining their behavior in a compatible way. You'll be able to avlidate your document as both HTML and XHTML, though there still may be some risks of different behavior. So I think it's unfair to accuse this particular group of not wanting to solve the problem. Regards, Maciej
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 22:11:15 +0100, Kornel Lesinski [EMAIL PROTECTED] wrote: User-agent sniffing is a bad practice - it's inaccurate, hurts minority browsers and is not forward-compatible. Please change your method to use Accept header, so it won't be affecting any HTML-only user-agents (web is more than a handful of desktop browsers). Accept method will even work for MSIE and Lynx when/if they start supporting XHTML. Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Wed, 07 Mar 2007 23:52:08 -, Alexey Feldgendler [EMAIL PROTECTED] wrote: Even your regular expressions for User-Agent aren't doing exactly what you intended, because mod_rewrite does not anchor patterns. While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. And Googlebot claims to accept application/*. Despite that Accept header can resolve this issue. XHTML browsers include full application/xhtml+xml MIME type, so you can avoid false positives if you ignore wildcard matches in negotiation. While it's not perfect, I think it's still better than using User-Agent for the same purpose. -- regards, Kornel Lesiński
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Alexey Feldgendler wrote: While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. That's not really true. See: http://lists.w3.org/Archives/Public/www-html/2006Nov/0044.html and http://lists.w3.org/Archives/Public/www-html/2006Nov/0050.html -- Benjamin Hawkes-Lewis
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Benjamin Hawkes-Lewis wrote: Alexey Feldgendler wrote: While I totally agree that browser sniffing isn't a way to go, I must say that Accept headers cannot be used to resolve this because MSIE claims to support */* in the Accept header that it sends. That's not really true. See: http://lists.w3.org/Archives/Public/www-html/2006Nov/0044.html and http://lists.w3.org/Archives/Public/www-html/2006Nov/0050.html Problem is safari will handle application/xhtml+xml but seems to be sending */* so the claim that we should only send application/xhtml+xml to browsers that explicitly request that type is problematic. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Elliotte Harold wrote: Problem is safari will handle application/xhtml+xml but seems to be sending */* so the claim that we should only send application/xhtml+xml to browsers that explicitly request that type is problematic. When I talked to WebKit developers about this, it seemed they considered their support for real XHTML less reliable than their support for HTML at that point. So while Safari's Accept header may be suboptimal, there's nothing terribly wrong with interpreting it the same as IE and serving it HTML instead. -- Benjamin Hawkes-Lewis
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Hi David, Or export them to PDF via PrinceXML, for example. The ability to mark up content once but publish it twice, in a usable, attractive format both for the web and for print, gives XHTML tremendous practical value for web publishers. It isn't just theoretical or fashionable anymore. While I agree that XHTML is indeed great, Prince also supports regular HTML documents, too. This can be convenient when grabbing content off the web that you need to print, or reusing your existing HTML content. One downside of using HTML is that errors in the document can cause odd behaviour and can be harder to track down than errors in XML/XHTML. Best regards, Michael -- Print XML with Prince! http://www.princexml.com
