Re: [whatwg] article: do we really need this?
At 08:22 + UTC, on 2007-03-06, Benjamin Hawkes-Lewis wrote: Sander Tekelenburg wrote: [...] [http://webrepair.org/02strategy/02certification/01requirements.php#req20] Well, that makes some sense for block elements, but less for inline elements. Agreed. [...] it would be good to think of a how to systematize resilient identifiers so that content can be added and deleted without a) running out of identifiers or b) fragments being misindentified. Good point. But for an automated web publishing system it shouldn't be that hard to ensure generating new IDs -- not reusing old ones. http://webrepair.org/02strategy/02certification/01requirements.php#req20 updated to accordingly. Btw, browser authors could contribute to adoption of such a practice by making it easy for users to find such IDs. One implementation might be to, through the contextual menu, place a link with fragment identifier to that specific section on the clipboard. FWIW, HyperTextuality extension does this Excelent! :) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Opera, repeats, remove, move-up, and move-down
On Tue, 06 Mar 2007 22:00:31 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Is this just an Opera limitation for the time being or am I missing something? It appears to be both a bug in Opera and a bug in your code... For some reason we don't ignore the template= attribute on the remove / move-up / move-down controls (thanks Simon for the bug report!). div id=observation repeat=template repeat-start=5 labelSpecies: input type=text name=species[observation].name value= / /label labelCount: input type=number min='1' value= name=species[observation].number / /label button type=remove template=observationDelete/button button type=move-up template=observationMove Up/button button type=move-down template=observationMove Down/button /div divbutton type=add template=observationAdd Species/button/div -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[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
[whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
(I sent this to the list already, but I think it didn't appear because I sent it with the wrong e-mail address.) I'm not sure if it has been discussed earlier, but after seeing Chris Wilson's talk on «Browser Wars Episode II: Attack of the DOMs»[1] I think it's pretty obvious that Internet Explorer needs a new switch of some sort, to be allowed to implement and fix the DOM, JavaScript, CSS1-3 etc. without breaking backward compatibility. At least that's what Chris Wilson says. And I agree. Internet Explorer needs a new switch. So I thought, what about using: !DOCTYPE html as the new switch? If HTML5 will be ratified into a stable standard document, perhaps in the W3C, it should be a viable target for the Internet Explorer team although they are not actively participating in the development of the standard. And as such, the HTML5 DOCTYPE can be used as a new switch to allow for an even stricter and more correct implementation of CSS, HTML and so on. There has been some discussion about using MIME types (e.g. 'application/xhtml+xml') as a new switch (I distantly recall it going on at annevankesteren.no, but I can't find it at the moment), but since it's very unlikely that Internet Explorer will support that for a long time, and since HTML5 is backward compatible with HTML4, the HTML5 DOCTYPE might be a much better option. So, what do you think? ___ [1] http://video.yahoo.com/video/play?oid=dc16aa88896b39b6rurl=video.yahoo.com -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
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] W3C restarts HTML effort
Ian Hickson wrote: The W3C today publicly announced that they are restarting an HTML specification effort. http://www.w3.org/2007/03/html-pressrelease This is great news and a clear validation of the WHATWG effort, which has been leading the maintenance and development of HTML since 2004. I'd like to congratulate everyone who has been involved in the WHATWG work, this really confirms that we have been doing good work. Surprisingly, the W3C never actually contacted the WHATWG during the chartering process. However, the WHATWG model has clearly had some influence on the creation of this group, and the charter says that the W3C will try to actively pursue convergence with WHATWG: http://www.w3.org/2007/03/HTML-WG-charter.html#conformance Hopefully they will get in contact soon. In the meantime, apparently anyone can actually join the W3C effort. http://www.w3.org/2004/01/pp-impl/40318/instructions The instructions to join the group are as follows: 1. Fill in the Public Access Request Form; in the Reason field, put: To apply for participation in the HTML Working Group as an Invited Expert. http://cgi.w3.org/MemberAccess/Public 2. When you get a reply back, you should have a username and password. Fill in the W3C Invited Expert Application form. http://www.w3.org/2002/09/wbs/1/ieapp/ 3. E-mail Dan Connolly and Karl Dubost ([EMAIL PROTECTED], [EMAIL PROTECTED]) asking for approval. 4. When you get a reply back, fill in the Joining the HTML Working Group form. http://www.w3.org/2004/01/pp-impl/40318/join I would encourage everyone interested in working with the HTML working group to go through these steps as soon as possible, so that you will be a member of the group before the work starts. I have also posted a WHATWG blog entry with this information: http://blog.whatwg.org/w3c-restarts-html-effort Cheers, The charter page also notes The HTML Working Group also welcomes participation from non-Members. This may take the form of questions and comments on the mailing list or IRC channel, for which there is no formal requirement, or technical submissions for consideration, for which the participant must agree to Royalty-Free licensing under the W3C Patent Policy. -- http://www.w3.org/2007/03/HTML-WG-charter.html#participation ...also This group primarily conducts its technical work on a Public mailing list. In other words, there's a participation level below full WG membership, but acknowledged in the charter. It may suit some folk here. Great to have the WG discussions in the public record too. Easier to find, easier to link to, etc. This is a very healthy level of openness. Good for W3C, good for the Web... cheers, Dan
Re: [whatwg] W3C restarts HTML effort
On Wed, 7 Mar 2007, Dan Brickley wrote: [http://www.w3.org/2007/03/HTML-WG-charter.html#participation] In other words, there's a participation level below full WG membership, but acknowledged in the charter. It may suit some folk here. Actually you currently can't join the list without going through the working group membership process. But yes, it is refreshing to see the W3C adopt an approach so much more open than most previous W3C working groups. -- 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
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] Using the HTML5 DOCTYPE as a new quirksmode switch
On Wed, 07 Mar 2007 21:47:34 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: There has been some discussion about using MIME types (e.g. 'application/xhtml+xml') as a new switch (I distantly recall it going on at annevankesteren.no, but I can't find it at the moment), but since it's very unlikely that Internet Explorer will support that for a long time, and since HTML5 is backward compatible with HTML4, the HTML5 DOCTYPE might be a much better option. Yeah, I suppose that could work. FYI: my site is still .nl: http://annevankesteren.nl/2004/06/standard-compliant-ie -- 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 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] Using the HTML5 DOCTYPE as a new quirksmode switch
On Wed, 07 Mar 2007 21:47:34 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: I'm not sure if it has been discussed earlier, but after seeing Chris Wilson's talk on «Browser Wars Episode II: Attack of the DOMs»[1] I think it's pretty obvious that Internet Explorer needs a new switch of some sort, to be allowed to implement and fix the DOM, JavaScript, CSS1-3 etc. without breaking backward compatibility. At least that's what Chris Wilson says. And I agree. Internet Explorer needs a new switch. So I thought, what about using: !DOCTYPE html as the new switch? This is a plain simple yet brilliant idea. Other browsers can also use !DOCTYPE html as an indication to stop applying certain hacks which make them diverge from standards in favor of interoperability with IE. -- 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] article: do we really need this?
Matthew Raymond wrote: Would section role=article do? Well, first of all, what would it do that a predefined class name wouldn't, since from a markup point of view, the only difference is the name of the attribute? Not much. section class=article is perfectly fine. My mind just happened to be in another spec at the moment where there were roles and not classes, so I happened to mention role where I probanly should have said class. It's not really a question of whether article makes sense. The question is whether it makes *enough* sense. There are arguments for it, but they're very weak. I do not see a community crying out for this. I don't think it's going to help anybody all that much, and I'm afraid it's going to end up like address: a poorly understood, rarely used element that's misused more often than it's used properly. It just doesn't feel like it justifies the space in the spec it takes up. :-( I suspect I could ask the same question of a few other elements as well. time and meter come to mind. They at least don't have any obvious equivalents already in the spec, and are obvious enough they perhaps won't be frequently misused; but do authors actually need these? Will they use them? -- 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] article: do we really need this?
Elliotte Harold wrote: Not much. section class=article is perfectly fine. My mind just happened to be in another spec at the moment where there were roles and not classes, so I happened to mention role where I [probably] should have said class. I don't really care for predefined classes. Classes strike me as being an extension mechanism to HTML, so it makes little sense to me to have their custom semantics enshrined in a specification. It's not really a question of whether article makes sense. The question is whether it makes *enough* sense. There are arguments for it, but they're very weak. I do not see a community crying out for this. Well, I for one have use div class=content for essentially the same thing all the time, so it'd be nice to have for me at least. I don't think it's going to help anybody all that much, and I'm afraid it's going to end up like address: a poorly understood, rarely used element that's misused more often than it's used properly. I can think of only one way it might be abused: | In the Time Magazine article articleIt is the Bunny!/article... However, considering how little other inline elements of that kind are used, I doubt this will be a problem. I suspect I could ask the same question of a few other elements as well. time and meter come to mind. They at least don't have any obvious equivalents already in the spec, and are obvious enough they perhaps won't be frequently misused; but do authors actually need these? Will they use them? I think time has a good use case. (Full Disclosure: time is based on similar earlier concepts I developed.) Meter has use cases, but I don't know how strong they are. I think article has at least as strong a use case as address, but I agree that's not saying much.
Re: [whatwg] W3C restarts HTML effort
Le 8 mars 2007 à 11:12, timeless a écrit : At this point, it asks: Please supply below the name and a URI for your employer (if any). If employed, please indicate the intentions of your employer regarding joining W3C as a Member. * My employer intends to join. (Indicate below time frame for joining) * My employer might be persuaded to join. (Give contact information for a decision-maker below.) * My employer does not intend to join. (Indicate below why not.) * I am either self-employed or unemployed. * My employer is a W3C Host (Indicate below the name of the W3C Host). Additional information: And I can't figure out how one would answer it. There are two sections in http://www.w3.org/2004/01/pp-impl/40318/ instructions 1. If you *work* for or represent a W3C Member organization http://cgi.w3.org/MemberAccess/ http://www.w3.org/2004/01/pp-impl/40318/join 2. If you *do not work* for a W3C Member organization http://cgi.w3.org/MemberAccess/Public (around 2 days before you can go to next step) http://www.w3.org/2002/09/wbs/1/ieapp/ -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
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
Re: [whatwg] article: do we really need this?
Elliotte Harold wrote: Not much. section class=article is perfectly fine. My mind just happened to be in another spec at the moment where there were roles and not classes, so I happened to mention role where I probanly should have said class. IMHO, predefined classes do not belong in HTML5. The class attribute is already defined as user-defined, and it should remain that way to avoid conflicts. It's not really a question of whether article makes sense. The question is whether it makes *enough* sense. There are arguments for it, but they're very weak. I do not see a community crying out for this. I don't think it's going to help anybody all that much, and I'm afraid it's going to end up like address: a poorly understood, rarely used element that's misused more often than it's used properly. address is a poorly understood, rarely-used element because it's poorly-named. It represents the intersection of contactinfo and attribution, which is neither particularly useful nor particularly related to its name. I suspect I could ask the same question of a few other elements as well. time and meter come to mind. They at least don't have any obvious equivalents already in the spec, and are obvious enough they perhaps won't be frequently misused; but do authors actually need these? Will they use them? The meter concept is widely used already (think reviews and ratings). As long as meter provides the necessary stylistic flexibility, it should be a useful addition to HTML5. If it doesn't, though, or if it makes styling more difficult than current methods, then it won't be used much. Dates are very often marked-up specially.[1] There's even a microformat design pattern developed to embed ISO representations of the date without compromising its readability: http://microformats.org/wiki/datetime-design-pattern The time element is much more appropriate for this than abbr. [1] http://code.google.com/webstats/2005-12/classes.html ~fantasai
[whatwg] call for participation: W3C HTML Working Group
Hi, W3C chartered a new HTML Working Group today. http://www.w3.org/html/wg/ http://www.w3.org/2007/03/HTML-WG-charter In recognition of the WHAT WG requirements gathering, design, testing, and review efforts, and on the advice of various W3C member organizations, the W3C HTML Working Group is chartered to actively pursue convergence with WHATWG, encouraging open participation within the bounds of the W3C patent policy and available resources. So please do consider participating. Administration of the W3C patent policy does involve a bit of administrative overhead; I hope you'll agree that it's worthwhile, in the interest of the goal of assuring that Recommendations produced under this policy can be implemented on a Royalty-Free (RF) basis. Ian Hixie wrote a good summary of the steps for joining the Working Group. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/009887.html http://blog.whatwg.org/w3c-restarts-html-effort I see that several people are several steps into that process. I hope I can tend to those presently. I'm traveling this week, so I hope you'll excuse a bit of a delay. Ian also notes that Surprisingly, the W3C never actually contacted the WHATWG during the chartering process. Oops. I hope you'll excuse that too. Getting this working group chartered was a very involved process, and I suppose I dropped a few balls along the way. I hope not too many. I look forward to working on HTML with you. p.s. I am copying [EMAIL PROTECTED]; note that if you reply all, you'll be greeted by the W3C archive approval anti-spam robots, unless you have already been through that ritual. http://www.w3.org/2002/09/aa/ -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Re: [whatwg] call for participation: W3C HTML Working Group
On Wed, 7 Mar 2007, Dan Connolly wrote: W3C chartered a new HTML Working Group today. http://www.w3.org/html/wg/ http://www.w3.org/2007/03/HTML-WG-charter On behalf of the rest of the WHATWG community, I'd like to congratulate the W3C for starting this work. In recognition of the WHAT WG requirements gathering, design, testing, and review efforts, and on the advice of various W3C member organizations, the W3C HTML Working Group is chartered to actively pursue convergence with WHATWG, encouraging open participation within the bounds of the W3C patent policy and available resources. So please do consider participating. Similarly, I would encourage you and other members of the W3C HTML working group to participate in the WHATWG effort. In fact, I would say that one very effective way to persue convergence between the two efforts would be to have at least the chairmen of the HTML working group participating in the WHATWG, and the spokesman of the WHATWG participating in the HTMLWG. This would show our respective members that the two groups do intend to cooperate in good faith. To show our commitment to this effort, as the WHATWG spokesman, I have started the process of joining the HTML working group. Participating in the WHATWG effort is a relatively simple process; I would recommend joining the [EMAIL PROTECTED] mailing list, and starting by sending any comments you may have on our current proposals. http://www.whatwg.org/mailing-list#specs http://www.whatwg.org/specs/web-apps/current-work/ I look forward to working on HTML with you. Indeed! On behalf of the WHATWG, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
