Re: [whatwg] href attribute
On Sat, 10 Mar 2007 02:28:32 +0100, Billy Wong [EMAIL PROTECTED] wrote: Indeed. IMO, global |href| gives nothing but more confusion. If we want to have hyperlinks on block-level elements, it is simpler just let a and/or other inline elements be legal to wrap block-level elements. Yup. If I recall correctly parsing-wise it's possible to let a contain block level elements. That's being considered now to cater for those use cases. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Le Sat, 10 Mar 2007 00:46:15 +0200, Alexey Feldgendler [EMAIL PROTECTED] a écrit: On Fri, 09 Mar 2007 21:53:09 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: This is a plain simple yet brilliant idea. Thanks. :) I'm sad there aren't more replies to this wonderful idea, though! :-P There would be replies if your idea was incomplete or controversial, but actually it seems like everyone agrees. What worries me is whether there is a chance that Microsoft actually does what's suggested (and whether someone in Microsoft who is in position to influence this decision actually finds out about this idea and gets convinced). I did follow this discussion since the first email. I saw that the idea is very well welcomed. Alexey, actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? How will tutorials look: 1. For quirks mode use no DOCTYPE. 2. For standards mode use one of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/TR/REC-html40/strict.dtd; ... 3. For super-duper standards mode use the following DOCTYPE: !DOCTYPE html My point is: we either want it, or not, what we have today called as standards mode is also buggy (each browser has its own set of rendering bugs). If IE adds the third level of rendering, then we have yet another DOCTYPE switch. Microsoft needs to make the improvements in the current standards mode - as they did now with IE 7. They need to continue this. Adding a new DOCTYPE switch is not a solution to Microsoft's problem. However, if this proposal makes it into IE.next, it wouldn't be a problem (since it triggers standards mode in the other browsers, and it's fairly safe to use). -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 11:16 AM, Mihai Sucan wrote: Le Sat, 10 Mar 2007 00:46:15 +0200, Alexey Feldgendler [EMAIL PROTECTED] a écrit: On Fri, 09 Mar 2007 21:53:09 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: This is a plain simple yet brilliant idea. Thanks. :) I'm sad there aren't more replies to this wonderful idea, though! :-P There would be replies if your idea was incomplete or controversial, but actually it seems like everyone agrees. What worries me is whether there is a chance that Microsoft actually does what's suggested (and whether someone in Microsoft who is in position to influence this decision actually finds out about this idea and gets convinced). I did follow this discussion since the first email. I saw that the idea is very well welcomed. Alexey, actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? How will tutorials look: 1. For quirks mode use no DOCTYPE. 2. For standards mode use one of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/ TR/REC-html40/strict.dtd ... 3. For super-duper standards mode use the following DOCTYPE: !DOCTYPE html My point is: we either want it, or not, what we have today called as standards mode is also buggy (each browser has its own set of rendering bugs). If IE adds the third level of rendering, then we have yet another DOCTYPE switch. Microsoft needs to make the improvements in the current standards mode - as they did now with IE 7. They need to continue this. indeed Adding a new DOCTYPE switch is not a solution to Microsoft's problem. As far as I understand it, the new DOCTYPE switch is meant to 'tell' to browser the document follows the HTML5 specification. HTML5 is set up to be backwards compatible with HTML4 documents. The opposite does not hold. There must be at least one new DOCTYPE to 'tell' the browser HTML5 is being served. !DOCTYPE html seems to be a suitable candidate. This doctype can be used by vendors to proxy the content to the right rendering engine. Vendors can either rebuild a new engine from scratch, or improve specific parts of their rendering engine. However, if this proposal makes it into IE.next, it wouldn't be a problem (since it triggers standards mode in the other browsers, and it's fairly safe to use). -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Alexey Feldgendler wrote: There would be replies if your idea was incomplete or controversial, but actually it seems like everyone agrees. What worries me is whether there is a chance that Microsoft actually does what's suggested (and whether someone in Microsoft who is in position to influence this decision actually finds out about this idea and gets convinced). So, has anyone mailed Molly H? Isn't she supposed to work with standards compliance issues within MS? Personally I think the best route to go for MS is to fix all bugs and make Standards Compliance Mode truly compliant. And perhaps mimic FFox and have an almost compliance mode for transitional doctypes, behaving the same way as FFox of course when they see one. Let's not give MS an excuse to keep behaving badly with HTML 4.01 and XHTML 1! Lars Gunther
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Sat, 10 Mar 2007 11:16:09 +0100, Mihai Sucan [EMAIL PROTECTED] wrote: Alexey, actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? How will tutorials look: 1. For quirks mode use no DOCTYPE. 2. For standards mode use one of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/TR/REC-html40/strict.dtd; 3. For super-duper standards mode use the following DOCTYPE: !DOCTYPE html The tutorials will just say Use !DOCTYPE html. My point is: we either want it, or not, what we have today called as standards mode is also buggy (each browser has its own set of rendering bugs). If IE adds the third level of rendering, then we have yet another DOCTYPE switch. Microsoft needs to make the improvements in the current standards mode - as they did now with IE 7. They need to continue this. The reason why modes other than the best standards mode exist is that a significant number of existing documents are written while keeping the non-standard browser behavior in mind, and it's unacceptable to change the rendering of those documents dramatically. Actually, the best standards mode available is the only right mode to work in. The other modes are only supported for backward compatibility with existing documents. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Le Sat, 10 Mar 2007 14:27:32 +0200, Alexey Feldgendler [EMAIL PROTECTED] a écrit: On Sat, 10 Mar 2007 11:16:09 +0100, Mihai Sucan [EMAIL PROTECTED] wrote: Alexey, actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? How will tutorials look: 1. For quirks mode use no DOCTYPE. 2. For standards mode use one of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/TR/REC-html40/strict.dtd; 3. For super-duper standards mode use the following DOCTYPE: !DOCTYPE html The tutorials will just say Use !DOCTYPE html. Those are the tutorials for beginners. I was talking about advanced tutorials, for developers who want to know gory details. My point is: we either want it, or not, what we have today called as standards mode is also buggy (each browser has its own set of rendering bugs). If IE adds the third level of rendering, then we have yet another DOCTYPE switch. Microsoft needs to make the improvements in the current standards mode - as they did now with IE 7. They need to continue this. The reason why modes other than the best standards mode exist is that a significant number of existing documents are written while keeping the non-standard browser behavior in mind, and it's unacceptable to change the rendering of those documents dramatically. Actually, the best standards mode available is the only right mode to work in. The other modes are only supported for backward compatibility with existing documents. Right, and we already have one. It's the one we trigger right now with both of the following DOCTYPEs: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN http://www.w3.org/TR/REC-html40/strict.dtd; !DOCTYPE html It's called standards mode for a reason. All the browsers fix and improve their standards mode rendering. Here's how I see things (there are many details, which I probably forgot about right now): (leaving aside the Netscape legacy) 1. There's IE with quirks render mode: ugly, damaged, really bad rendering. 2. There are other browsers (Opera, Geckos, WebKits) which also have quirks rendering mode, mimmicking and reverse-engineering quirks mode from IE. 3. There's standards mode in IE which is a tad better currently, compared to its quirks mode. 4. There's standards mode in the other browsers as well, which is far ahead compared to IE standards mode. 5. The other browsers, having little market share, have the liberty of improving their standards mode rendering, without annoying many users. Their users are more aware of the problems, why sites break, etc. 6. There are millions of pages relying on broken quirks mode rendering from IE (and legacy Netscape 4). 7. There's a new wave of modern/cool/awesome sites (including mine) relying on broken standards mode rendering in IE 6 and IE 7 (I still dislike it's rendering). 8. If Microsoft improves standards support in IE.next, in standards mode, it breaks existing modern sites. So, this proposal sounds like why not make this DOCTYPE switch to an even stricter standards rendering mode in IE.next? then we can improve IE without breaking existing sites. What this means, is that people will create even more modern sites, which will use this new DOCTYPE and the improved rendering engine (which will never be perfect). It's going to be a loop: newer sites will rely on the newer rendering mode. So, with each new version of IE (released every 5-10 years), we will have a new DOCTYPE, and a new rendering mode? Instead of using this DOCTYPE switch, I was even thinking of conditional comments, DOM document property, etc. Yet, other methods only add complications. If Microsoft considers adding a new rendering mode as a must, such that it will not break many sites, then this DOCTYPE is an elegant solution. History will repeat itself, no matter how elegant the solution might be. Probably I don't really like this proposal very much only because it's a solution for *this* very moment, forgetting the fact that rendering bugs, and sites that rely on the bugs, will exist forever (a constant problem). -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Alexey Feldgendler wrote: The tutorials will just say Use !DOCTYPE html. What are those of us who wish to use XML tools on our documents supposed to use? We will need a real DTD at some point, to declare the entities if nothing else. We will not be able to use !DOCTYPE html. Possibly this could be two-fold. E.g there could be both !DOCTYPE html and something like !DOCTYPE html PUBLIC -//WhatWG//DTD XHTML 5.0//EN /DTD/xhtml5.dtd I know some browser-centric folks here just hate DTDs and schemas of any kind; but we will need them, even if the browsers don't. We will create and use them, even if there's no normative DTD in the spec. One thing that's struck me in working with the spec over the last few days is just how hard it is to follow the various content models, and how much simpler most of them would be to read if they were described in a RELAX NG schema or a DTD. -- 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] Using the HTML5 DOCTYPE as a new quirksmode switch
On 10 Mar 2007, at 13:43, Elliotte Harold wrote: Alexey Feldgendler wrote: The tutorials will just say Use !DOCTYPE html. What are those of us who wish to use XML tools on our documents supposed to use? We will need a real DTD at some point, to declare the entities if nothing else. We will not be able to use !DOCTYPE html. Then you're still relying on the UA reading the DTD, which it doesn't have to. What use is a DTD if it doesn't need to be read and has no nominative value? - Geoffrey Sneddon
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Sat, 10 Mar 2007 14:43:44 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Alexey Feldgendler wrote: The tutorials will just say Use !DOCTYPE html. What are those of us who wish to use XML tools on our documents supposed to use? We will need a real DTD at some point, to declare the entities if nothing else. We will not be able to use !DOCTYPE html. !DOCTYPE html is for text/html, not for XML. For XML you could either drop the doctype altogether, or, if you really want to point to a DTD, you could just use the system identifier (the public identifier won't do anyone any good), or you could use the internal subset. Why would you need to declare entities, though? -- Simon Pieters
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Geoffrey Sneddon wrote: Then you're still relying on the UA reading the DTD, which it doesn't have to. What use is a DTD if it doesn't need to be read and has no nominative value? It's my user agent and it will read the DTD. One more time: It's not just browsers out there! Browsers that don't want to read the DTD don't have to, but DTDs will be essential for parsing XHTML5 with generic XML tools such as libxml and Xerces. -- 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] Using the HTML5 DOCTYPE as a new quirksmode switch
Simon Pieters wrote: Why would you need to declare entities, though? If you don't define entities, then the parser can't resolve them. This is for entities such as copy; and trade;. There are only five entities that XML parsers recognize out of the box without a DTD: amp;, lt;, gt;, apos;, and quot;. -- 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] Using the HTML5 DOCTYPE as a new quirksmode switch
Le Sat, 10 Mar 2007 12:39:46 +0200, Jorgen Horstink [EMAIL PROTECTED] a écrit: On Mar 10, 2007, at 11:16 AM, Mihai Sucan wrote: Adding a new DOCTYPE switch is not a solution to Microsoft's problem. As far as I understand it, the new DOCTYPE switch is meant to 'tell' to browser the document follows the HTML5 specification. HTML5 is set up to be backwards compatible with HTML4 documents. The opposite does not hold. There must be at least one new DOCTYPE to 'tell' the browser HTML5 is being served. !DOCTYPE html seems to be a suitable candidate. This doctype can be used by vendors to proxy the content to the right rendering engine. Vendors can either rebuild a new engine from scratch, or improve specific parts of their rendering engine. I believe this is wrong. This DOCTYPE is *not* meant to 'tell'/inform/advertise the document as HTML5. It's definitely not the case, see the FAQ [1]. For one, HTML5 is a specification defining new features, and redefining parsing, breaking the SGML and XML rules. All the error recovery, and all the parsing rules are picked so that an implementation of HTML 5 will properly support HTML 4 as used today on the majority of web sites. Backwards compatibility is the key. Of course, it's utopic to believe that a specification can be written to accomodate 100% of all the web pages found. Yet, HTML 5 does provide parsing algorithms that work on the majority of code found on the web. There's no way to advertise the document as HTML 5, and it's certainly not the purpose of the specification to do so. (If I am wrong, an expert should correct me.) [1] http://blog.whatwg.org/faq/#doctype -- http://www.robodesign.ro ROBO Design - We bring you the future
[whatwg] Thesis draft about HTML5 conformance checking
The reason why I haven't updated the software at http:// hsivonen.iki.fi/validator/html5/ lately is that I have been writing about it. The draft of my master's thesis is available for commenting at: http://hsivonen.iki.fi/thesis/ I'd appreciate comments on the draft. However, I won't be able to respond to comments next week. I'll continue polishing the thesis the week after next. I have a couple of specific questions: * Besides perhaps IRC logs, is there any less ephemeral reference about the WHATWG members being able to impeach and replace the editor? * What would be a good reference for the design policy of Web Forms 2.0 regarding implementability on top of IE6? Is http:// lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003818.html the best reference? (These are stuff I think I know but I don't know where these things are said. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 15:43, Elliotte Harold wrote: Alexey Feldgendler wrote: The tutorials will just say Use !DOCTYPE html. What are those of us who wish to use XML tools on our documents supposed to use? !DOCTYPE html if you are using XML tools with an HTML5 parser. No doctype if you are using XHTML5 and targeting an XML parser. We will need a real DTD at some point, to declare the entities if nothing else. Straight UTF-8 should be used for interchange on the XML side. !DOCTYPE html PUBLIC -//WhatWG//DTD XHTML 5.0//EN /DTD/xhtml5.dtd Browsers won't read arbitrary DTDs by system ID. OTOH, if you want to activate the hacks for enabling XHTML 1.0 entities, you need to use an XHTML 1.0 public ID. A new previously unknown public ID won't work. I know some browser-centric folks here just hate DTDs and schemas of any kind; but we will need them, even if the browsers don't. For Web content, browsers matter and the reality is that DTDs don't work. We will create and use them, even if there's no normative DTD in the spec. The spec doesn't need to say anything normative about private (non- Web) use. If it is between you and your own entity resolver, using a DTD with an identifier of your choice is fine. However, before serving documents on the Web, you'd need to parse and reserialize so that the serialization that is sent to the public network does not have DTD dependencies. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On 3/10/07, Mihai Sucan [EMAIL PROTECTED] wrote: actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? From http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940fr=, I got that the standard doctypes we have now that trigger standards mode in IE are a problem. It seems that even in standards mode, people expect some quirky behavior and MS wants to retain the quirkyness even in standards mode. If they continue to fix standards mode, they'll break way too many sites. It seems that they are searching for a way to trigger a real standards mode without retaining any of those quirks and without messing with normal standards mode. !DOCTYPE html, could be used by IE to trigger a standards mode minus any quirks. In short, IE's standards mode is not really a standards mode. It's just a less quirky quirks mode. They want a way to move on with following standards without affecting the current standards mode. So, IE would have quirks mode, standards mode and a strict standards mode. As for other browsers that still retain a few IE compatibilities in standards mode, when they see !DOCTYPE html, that might be their chance to ditch any behavior that was just added in to be compatible with IE. (but that depends) But, mainly, it'd be a tool for MS to move on. For other browsers, just keep the bug fixing coming. That's what I got out of the video. -- burnout426
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Le Sat, 10 Mar 2007 22:21:11 +0200, Shadow2531 [EMAIL PROTECTED] a écrit: On 3/10/07, Mihai Sucan [EMAIL PROTECTED] wrote: actually I'm skeptical about this. First impression I had reading the first post was hey, do we need yet another switch?. What's super-duper standards mode after all? From http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940fr=, I got that the standard doctypes we have now that trigger standards mode in IE are a problem. It seems that even in standards mode, people expect some quirky behavior and MS wants to retain the quirkyness even in standards mode. If they continue to fix standards mode, they'll break way too many sites. Precisely! That's what I said: the standards mode in IE is rather quirky. However, I do *not* buy it: I don't believe they'll magically come up with IE.next having a strict standards mode which is up-to-par with the standards mode in, say, Opera. Even if they do, don't think the standards mode in Opera/Gecko/whatever is perfect either. They all have quirks. But ... because we are talking about IE, we will again end up having sites relying on the strict standards mode, and again Microsoft would break way too many sites if they change the rendering in this new mode. It's an endless loop. (see one of my previous replies to this thread) That's what I got out of the video. That's correct. I did understand relatively the same. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On 3/10/07, Mihai Sucan [EMAIL PROTECTED] wrote: Le Sat, 10 Mar 2007 22:21:11 +0200, Shadow2531 [EMAIL PROTECTED] It seems that even in standards mode, people expect some quirky behavior and MS wants to retain the quirkyness even in standards mode. If they continue to fix standards mode, they'll break way too many sites. Precisely! That's what I said: the standards mode in IE is rather quirky. However, I do *not* buy it: I don't believe they'll magically come up with IE.next having a strict standards mode which is up-to-par with the standards mode in, say, Opera. Even if they do, don't think the standards mode in Opera/Gecko/whatever is perfect either. They all have quirks. But ... because we are talking about IE, we will again end up having sites relying on the strict standards mode, and again Microsoft would break way too many sites if they change the rendering in this new mode. It's an endless loop. (see one of my previous replies to this thread) That's what I got out of the video. That's correct. I did understand relatively the same. You make a good point. It could very well be an endless loop and there's no guarantee (or even past evidience to show) that IE's new standards mode would be up to par. I guess at the least, it shows the desperate need to do something about IE. -- burnout426
Re: [whatwg] Thesis draft about HTML5 conformance checking
Henri, Here are few remarks In RELAX NG Datatyping Why is there no mention to DTLL of the DSDL ? For sake of completeness In Schematron You should mention that XML Schema 1.1 which is still a WD try to add assertion too Liam Quin (with only one n) [[ common.inner.strict-inline = ( text ) ]] appear twice in the html file Regards, Xmlizer On 3/10/07, Henri Sivonen [EMAIL PROTECTED] wrote: The reason why I haven't updated the software at http:// hsivonen.iki.fi/validator/html5/ lately is that I have been writing about it. The draft of my master's thesis is available for commenting at: http://hsivonen.iki.fi/thesis/ I'd appreciate comments on the draft. However, I won't be able to respond to comments next week. I'll continue polishing the thesis the week after next. I have a couple of specific questions: * Besides perhaps IRC logs, is there any less ephemeral reference about the WHATWG members being able to impeach and replace the editor? * What would be a good reference for the design policy of Web Forms 2.0 regarding implementability on top of IE6? Is http:// lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003818.html the best reference? (These are stuff I think I know but I don't know where these things are said. :-) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] href attribute
- Original Message - From: Anne van Kesteren [EMAIL PROTECTED] To: Billy Wong [EMAIL PROTECTED] Cc: WHATWG [EMAIL PROTECTED] Sent: Saturday, March 10, 2007 12:32 AM Subject: Re: [whatwg] href attribute On Sat, 10 Mar 2007 02:28:32 +0100, Billy Wong [EMAIL PROTECTED] wrote: Indeed. IMO, global |href| gives nothing but more confusion. If we want to have hyperlinks on block-level elements, it is simpler just let a and/or other inline elements be legal to wrap block-level elements. Yup. If I recall correctly parsing-wise it's possible to let a contain block level elements. That's being considered now to cater for those use cases. Anne, but what about this: ul ali/li/a /ul it is not about a itself. It should also be a mechanism for the container similar to CSS's display-model attribute for the container of a. But this is out of influence of HTML per se. Back to basics: A hyperlink is a relationship between two anchors, called the head and the tail of the hyperlink[DEXTER]. [1] Any element is allowed to be a tail of the hyperlink: The id attribute may be used to create an anchor at the start tag of any element (including the A element). [2] But I do not understand why we have such a limitation for the head of the hyperlink. There are multiple semantically correct cases when block elements like li, option, address , img etc. *are* hyperlinks. But designers are forced to use weird tricks to fight with inline nature of as. Andrew Fedontiouk. http://terrainformatica.com [1] http://www.ietf.org/rfc/rfc1866.txt [2] http://www.w3.org/TR/html401/struct/links.html#h-12.2.3
Re: [whatwg] Thesis draft about HTML5 conformance checking
On Saturday 2007-03-10 23:41 +0100, mozer wrote: Liam Quin (with only one n) No, Liam Quin [1] and Liam Quinn [2] are two different Canadian members of the Web standards community, and should not be confused with each other. The latter was responsible for the WDG HTML Validator, so Henri's spelling is correct. -David [1] http://www.w3.org/People/Quin/ [2] http://htmlhelp.com/~liam/ -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpVDa5ExYuRi.pgp Description: PGP signature
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 8:38 AM, Mihai Sucan wrote: There's no way to advertise the document as HTML 5, and it's certainly not the purpose of the specification to do so. This is a problem. It is especially a problem now that the W3C is working on their version of HTML 5. When I asked Ian Hickson how WHATWG would handle divergence in the W3C spec [1], he said he intended to make every effort to keep the two in sync. [2] While I appreciate his effort and I fully believe that he will do his best, we are dealing with a body (i.e. the W3C) who have a history of stubbornness and unwillingness to work with important members of the community. [3] The future is still undecided, but I don't think it is a good idea to operate under the assumption that the W3C will copy and paste the entire WHATWG HTML 5 spec. Even if DTDs are non-normative and antiquated in the HTML 5 spec, it at least provides some method for authors to indicate their intentions. If my intention was to write a document conforming to HTML 3.2, I can use the HTML 3.2 DTD to tell anyone in the future that I was using a certain set of elements. If browsers pay no attention to DTDs, as WHATWG has said time and again, browsers must be rendering the latest and greatest markup. If in 50 years, the i element has been out of use for 40 years, and browsers stop rendering that element and validators throw errors on that element, the document still conforms to the DTD. It's not the author's fault that the document doesn't perform the way it intended. Ideally, the browser should care about DTDs. The WHATWG HTML 5 spec provides no way to specify what version / fork of HTML the author intended to use. Even if browsers don't pay attention, I think it is a shame that there is no way to specify (if for nothing else, to future-proof documents). I blogged about this in more detail. [4] It seems the WHATWG is staunchly against DTDs, even if it has an appropriate use (e.g. emails in this thread talking about XML entities). I've mulled over this awhile. Since DTDs aren't normative in browsers, perhaps a link element with a rel=specification and an href=http://www.whatwg.org/specs/web-apps/ current-work/ (for example) would be a new way to say, this is the specification I used to create this document. It is easier to remember than the DOCTYPE DTDs on pervious versions of HTML, and it is much more human-readable than DTDs. It addresses my concerns, and doesn't use DTDs. Now, I don't know if it can be used as a quirksmode switch. The DOCTYPE seems like an ideal place to run the switch. The problem will be if the W3C (or some other as yet unformed working group that decides to fork HTML) doesn't implement a DTD-less DOCTYPE. If the switch is the WHATWG HTML5 DOCTYPE, documents authored under W3C HTML 5 spec will not render in super-standard mode. Browsers will have to have multiple super-standards modes switches depending on what version of HTML5 the author uses. IE asking a working group to provide some new way to specify standards mode doesn't make sense. That is an implementation problem that they need to figure out. It isn't our job to write their software. WHATWG doesn't need to bloat the spec for them. The IE team needs to be creative and find a solution to their problem. We're already using headers to swap between HTML and XHTML (since we still call both .html files). Headers are for telling user agents how to deal with content. It seems like sending a header X- STANDARDS-MODE: HTML5; (or WHATWG-HTML5 if W3C's HTML 5 is significantly different) or setting an http-equiv meta tag to tell IE to use their super-standards mode is cleaner and more desirable as it doesn't bloat the spec, and should be more than enough for them. If their standards mode for HTML5 has flaws and they need a NEW switch, it can be changed to X-STANDARDS-MODE: HTML6; or whatever the latest version of HTML is. This can be set across an entire server in a few seconds via config files if needed, or set on a single folder via .htaccess files. If headers are used, that also doesn't bloat the file if is is saved on someone's HDD. [1] http://blog.whatwg.org/w3c-restarts-html-effort#comment-2020 [2] http://blog.whatwg.org/w3c-restarts-html-effort#comment-2022 [3] http://meyerweb.com/eric/thoughts/2006/08/14/angry-indeed/ [4] http://robertdot.org/2007/03/08/html-5-whatwg-versus-w3c.html
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Forgot to change the name in my account settings from WHATWG to Robert Brodrecht. Fixed for future reference. Sorry for any confusion.
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Matthew Ratzloff wrote: Relying on headers is a good way to get people to ignore that part of the specification. Web designers don't want to worry about headers and .htaccess files. It has to be syntactic. I think expecting the mass of web designers to worry about doctypes isn't much less optimistic than expecting them to worry about headers. Web designs frequently break quite seriously because web authors think that documents sent over the wire are defined entirely within the document text itself. e.g. Web authors often seem to imagine a charset defined in meta is determinative, and end up serving gibberish. Like it or not, effective web delivery depends on correct HTTP headers. -- Benjamin Hawkes-Lewis
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
- Original Message - From: Benjamin Hawkes-Lewis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 10, 2007 4:53 PM Subject: Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch Matthew Ratzloff wrote: Relying on headers is a good way to get people to ignore that part of the specification. Web designers don't want to worry about headers and .htaccess files. It has to be syntactic. I think expecting the mass of web designers to worry about doctypes isn't much less optimistic than expecting them to worry about headers. Web designs frequently break quite seriously because web authors think that documents sent over the wire are defined entirely within the document text itself. e.g. Web authors often seem to imagine a charset defined in meta is determinative, and end up serving gibberish. Like it or not, effective web delivery depends on correct HTTP headers. Opposite statement is correct too: Web authors often seem to imagine a charset defined in HTTP headers is determinative, and end up serving gibberish There are many cases when sequence of bytes with some markup is the only thing that is available. Think about partial content updates, ajax (or ahjacs?) kind of scenarios. And yet: web server configuration of headers is not always available. Public virtual site hosts is a good example. And more: Server adminestering and content creation are different roles/activities. As a rule different people handle these tasks. Requiring both of them to be involved in proces of creation of valid content will decrease probability that result will be valid. It is better if markup itself will be descriptive enough. BTW: why not to use html5.../html5 envelope instead of html? html is an optional element in HTML so old browsers will switch to quirks mode for the html5 content. And html5 UAs will know what to do with it. So this html5 element is pretty backward compatible solution. Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] href attribute
Andrew Fedoniouk wrote: Back to basics: A hyperlink is a relationship between two anchors, called the head and the tail of the hyperlink[DEXTER]. [1] This is not a definition of the a element. In fact, a is defined as a anchor, not a hyperlink. By contrast, the |href| attribute specifies the location of a Web resource. Thus, using |href| for hyperlinks on other elements is an alteration of the attribute's semantics, because the element you put them on doesn't have the semantics of a source anchor. Any element is allowed to be a tail of the hyperlink: The id attribute may be used to create an anchor at the start tag of any element (including the A element). [2] While one could argue that the |id| element give anchor semantics to an element, it is clear that in this context the text implicitly refers to the semantics of a DESTINATION anchor, not a source anchor. Even if you were to ignore this context, it would mean that using |href| as a global attribute would ALWAYS require you to include an |id| attribute on the element. But I do not understand why we have such a limitation for the head of the hyperlink. The definition of a as inline is the only limitation in HTML I'm aware of. Everything else is a CSS issue, and we should generally avoid making fundamental alterations to HTML purely to achieve presentational ends. There are multiple semantically correct cases when block elements like li, option, address , img etc. *are* hyperlinks. Actually, by the definition you quoted, they're not hyperlinks and can never be hyperlinks because a hyperlink is a relationship. In HTML 4.01, they can't even be source anchors. The HTML 4.01 version of |href| doesn't have the semantics to make them source anchors even if you made the attribute global. So let's be clear that what you're talking about is making every element semantically an a element. In other words, every element would automatically be a source anchor. Thus, you have taken semantics that were explicitly represented by an element and made them implicit and invisible in the markup. This is a poor way of dealing with semantics that are at the very heart of the World Wide Web, and I would certainly not call it semantically correct. But designers are forced to use weird tricks to fight with inline nature of as. That issue can be addressed without getting rid of a, by either allowing a to contain block-levels, or by creating a new block-level container with equivalent semantics.
Re: [whatwg] href attribute
On 10/03/2007 02:28, Billy Wong wrote: On 3/6/07, Matthew Raymond [EMAIL PROTECTED] wrote: To me, the only advantage of a global |href| is that you can use it on block-level elements, and I don't see why a block-level version of a couldn't fill the same use case. Indeed. IMO, global |href| gives nothing but more confusion. If we want to have hyperlinks on block-level elements, it is simpler just let a and/or other inline elements be legal to wrap block-level elements. No, it gives more than that : if |href| becomes global, the usage of |a| will decrease and that's a good thing. |a| is a bad element because it serves as source AND target of links, because it's not multivalued, and I have 5 or six other very good reasons in mind. Anything we can do to prepare a future - in the long term - deprecation of |a| is a good thing for the future of HTML. /Daniel
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 4:37 PM, Matthew Ratzloff wrote: The seem to serve the purpose. If there are two HTML 5 specifications, browser makers can come together to decide which one to support by default when no DOCTYPE is present. Developers who would prefer the alternate standard could use the appropriate DOCTYPE. Browsers render in quirksmode by default. That's been established. At this point WHATWG has already rejected DTDs in DOCTYPE and seems pretty set on not including it. I myself would rather have some type of versioning (DTD or otherwise) in the DOCTYPE. All I've heard from WHATWG is that they don't really even like the DOCTYPE. If browsers didn't use DOCTYPE as the standards mode switch, DOCTYPE probably wouldn't even be in WHATWG's HTML 5. If there is no versioning system, there is no way to specify an alternate standard. I'm sure most people have heard the saying Choose your battles. Fighting for DTDs or some other type of versioning in the DOCTYPE in WHATWG's spec is not a fight that can be won as far as I can tell. Having some method to tell people what spec an author is using can be won. -- Robert http://robertdot.org
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 5:24 PM, Andrew Fedoniouk wrote: And yet: web server configuration of headers is not always available. Public virtual site hosts is a good example. And more: Server adminestering and content creation are different roles/ activities. As a rule different people handle these tasks. Requiring both of them to be involved in proces of creation of valid content will decrease probability that result will be valid. People seem to have looked over the part where I suggested it could be either a header or *an http-equiv meta tag.* The meta tag cuts out the backend developer / server admin. Furthermore, if you have a need and your host or backend developer is not willing to honor that request, you are hiring the wrong people and you should find someone else who will do what you need. This isn't a major undertaking to add this header. There shouldn't be an instance where a professional web designer can't come up with a way to add a header to a request (either via global config, an .htaccess, or via a server-side scripting command). If I am wrong about that statement, REAL XHTML was doomed to fail from the day it required a content-type other than text/html. -- Robert http://robertdot.org
Re: [whatwg] href attribute
- Original Message - From: Matthew Raymond [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED] Cc: WHATWG [EMAIL PROTECTED] Sent: Saturday, March 10, 2007 7:17 PM Subject: Re: [whatwg] href attribute Andrew Fedoniouk wrote: Back to basics: A hyperlink is a relationship between two anchors, called the head and the tail of the hyperlink[DEXTER]. [1] This is not a definition of the a element. In fact, a is defined as a anchor, not a hyperlink. I think hyperlink is better in any sense than anchor as a designation of this entity. By contrast, the |href| attribute specifies the location of a Web resource. Thus, using |href| for hyperlinks on other elements is an alteration of the attribute's semantics, because the element you put them on doesn't have the semantics of a source anchor. Any element is allowed to be a tail of the hyperlink: The id attribute may be used to create an anchor at the start tag of any element (including the A element). [2] While one could argue that the |id| element give anchor semantics to an element, it is clear that in this context the text implicitly refers to the semantics of a DESTINATION anchor, not a source anchor. Even if you were to ignore this context, it would mean that using |href| as a global attribute would ALWAYS require you to include an |id| attribute on the element. But I do not understand why we have such a limitation for the head of the hyperlink. The definition of a as inline is the only limitation in HTML I'm aware of. Everything else is a CSS issue, and we should generally avoid making fundamental alterations to HTML purely to achieve presentational ends. There are multiple semantically correct cases when block elements like li, option, address , img etc. *are* hyperlinks. Actually, by the definition you quoted, they're not hyperlinks and can never be hyperlinks because a hyperlink is a relationship. In HTML 4.01, they can't even be source anchors. The HTML 4.01 version of |href| doesn't have the semantics to make them source anchors even if you made the attribute global. So let's be clear that what you're talking about is making every element semantically an a element. In other words, every element would automatically be a source anchor. Thus, you have taken semantics that were explicitly represented by an element and made them implicit and invisible in the markup. This is a poor way of dealing with semantics that are at the very heart of the World Wide Web, and I would certainly not call it semantically correct. But designers are forced to use weird tricks to fight with inline nature of as. That issue can be addressed without getting rid of a, by either allowing a to contain block-levels, or by creating a new block-level container with equivalent semantics. I beleive that you and me have different interpretation of the term 'semantic'. For my semantic any HTML element that has href attribute is not anyhow different from the a element with href. If I see li href=... I recognize that this is a list item that leads somewhere. Exactly (and even better) as lia href=../a/li For different tools it also does not matter what to use: getElementsBySelector(:link) or getElementsBySelector(a:link) or getElementsBySelector([href]) or whatever. In any case not all a's are hyperlinks so for your meaning of semantic they should also not be automatically hyperlinks (or anchors if you wish). I am pretty sure that existence of 'href' attribute is what creates semantic meaning of a for you. So why a cannot be b href or c href? Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] href attribute
On 11/03/2007 05:59, Andrew Fedoniouk wrote: In any case not all a's are hyperlinks so for your meaning of semantic they should also not be automatically hyperlinks (or anchors if you wish). I am pretty sure that existence of 'href' attribute is what creates semantic meaning of a for you. So why a cannot be b href or c href? Let me also play the devil (I love it) : a feature is not trashable only because it comes from XHTML 2.0 :-) Here, a global href is a really cool idea, we should have done it in HTML 4 but we were too blind to see. /Daniel
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
I don't care about DTD, but DOCTYPE is established, so it seems strange to trash it in favor of something new when the benefit is questionable (as far as I can tell). It is also evident to me that there needs to be some kind of versioning--consistent rendering shouldn't be a moving target. If DTD is out, bring back the deprecated version attribute that it replaced. Assuming there is only one version of HTML 5.0, the following would work: html version=5.0 mode=strict encoding=UTF-8 lang=en-US ... /html All attributes optional, obviously. -Matt Browsers render in quirksmode by default. That's been established. At this point WHATWG has already rejected DTDs in DOCTYPE and seems pretty set on not including it. I myself would rather have some type of versioning (DTD or otherwise) in the DOCTYPE. All I've heard from WHATWG is that they don't really even like the DOCTYPE. If browsers didn't use DOCTYPE as the standards mode switch, DOCTYPE probably wouldn't even be in WHATWG's HTML 5. If there is no versioning system, there is no way to specify an alternate standard. I'm sure most people have heard the saying Choose your battles. Fighting for DTDs or some other type of versioning in the DOCTYPE in WHATWG's spec is not a fight that can be won as far as I can tell. Having some method to tell people what spec an author is using can be won.
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Mar 10, 2007, at 9:40 PM, Matthew Ratzloff wrote: I don't care about DTD, but DOCTYPE is established, so it seems strange to trash it in favor of something new when the benefit is questionable (as far as I can tell). I don't think anyone wants to trash the DOCTYPE in light of the current landscape. The problem is that the IE team wants ANOTHER switch to turn on Super-Standards Mode. If DTD is out, bring back the deprecated version attribute that it replaced. Assuming there is only one version of HTML 5.0, the following would work: html version=5.0 mode=strict encoding=UTF-8 lang=en-US ... /html All attributes optional, obviously. That's a great idea. That solves not only the versioning system, but could solve the IE Super-Standards Mode switch (though I don't think the mode attribute needs to be there... no one wants to specifically render in quirksmode, I'd think). Again, my worry is that W3C doesn't implement it. My header idea would go above W3C's and WHATWG's heads. That means that it doesn't have to be in any published spec (and it shouldn't be, IMO). It's just something to tell IE how to treat the content (the same way we tell browsers to render as XML, charsets, caching, etc). There is really no reason it needs to be in any specification. However, if we can solve the missing versioning problem, it could be dual purpose (assuming W3C implements it in their recommendation). -- Robert http://robertdot.org
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
- Original Message - From: Robert Brodrecht To: Andrew Fedoniouk Cc: [EMAIL PROTECTED] Sent: Saturday, March 10, 2007 8:36 PM Subject: Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch On Mar 10, 2007, at 5:24 PM, Andrew Fedoniouk wrote: And yet: web server configuration of headers is not always available. Public virtual site hosts is a good example. And more: Server adminestering and content creation are different roles/activities. As a rule different people handle these tasks. Requiring both of them to be involved in proces of creation of valid content will decrease probability that result will be valid. People seem to have looked over the part where I suggested it could be either a header or *an http-equiv meta tag.* The meta tag cuts out the backend developer / server admin. Furthermore, if you have a need and your host or backend developer is not willing to honor that request, you are hiring the wrong people and you should find someone else who will do what you need. I love advices of hiring other people when they are accompanied by money orders. :) This isn't a major undertaking to add this header. There shouldn't be an instance where a professional web designer can't come up with a way to add a header to a request (either via global config, an .htaccess, or via a server-side scripting command). If I am wrong about that statement, REAL XHTML was doomed to fail from the day it required a content-type other than text/html. I think your point of view is valid somehow but a bit idealistic. Is valid because it is better for UA to know up front what it needs to parse : HTML, XHTML, SVG, etc. It is idealistic because, say, if you will put following in your .htaccess: AddType foo/bar .html it will do nothing on your site (you can try). This setting is managed by httpd.conf of the whole Apache server (if I recall this correctly). (and ForceType may not work at all on servers of your type) Trust me there are many practical needs where self descriptive document is highly desirable. Think about this: All UAs will correctly present file some.png even it contains jpeg bits. Even if server reports image/x-png content-type for it. It is very old tradition in software design - all file formats contain identification of the content type in some form - usually first 256 bytes is enough to determine type. So why html should be an exception of this rule? Andrew Fedoniouk. http://terrainformatica.com
