, and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Sat Feb 10 04:01:04 2007 From: webmaster at keryx.se (Keryx Web) Date: Sat, 10 Feb 2007 13:01:04 +0100 Subject: [HTML5] Best practice cheat sheet Message-ID: <45CDB400.20607@keryx.se> Hello! I work as a teacher (but do some development as well on the side). For the benefit of myself and my students i have strted to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) it is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. Many thanks. Lars Gunther P.S: I include an example of feedback i've already has got, in the form of my answer to Alexey Feldgendler: Alexey Feldgendler wrote: > 1. <body>, <title>, and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment-0001.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Sat Feb 10 04:01:04 2007 From: webmaster at keryx.se (Keryx Web) Date: Sat, 10 Feb 2007 13:01:04 +0100 Subject: [HTML5] Best practice cheat sheet Message-ID: <45CDB400.20607@keryx.se> Hello! I work as a teacher (but do some development as well on the side). For the benefit of myself and my students i have strted to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) it is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. Many thanks. Lars Gunther P.S: I include an example of feedback i've already has got, in the form of my answer to Alexey Feldgendler: Alexey Feldgendler wrote: > 1. <body>, <title>, and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment-0002.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/

From webmaster at keryx.se Sat Feb 10 04:01:04 2007 From: webmaster at keryx.se (Keryx Web) Date: Sat, 10 Feb 2007 13:01:04 +0100 Subject: [HTML5] Best practice cheat sheet Message-ID: <45CDB400.20607@keryx.se> Hello! I work as a teacher (but do some development as well on the side). For the benefit of myself and my students i have strted to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) it is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. Many thanks. Lars Gunther P.S: I include an example of feedback i've already has got, in the form of my answer to Alexey Feldgendler: Alexey Feldgendler wrote: > 1. , , and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Sat Feb 10 04:01:04 2007 From: webmaster at keryx.se (Keryx Web) Date: Sat, 10 Feb 2007 13:01:04 +0100 Subject: [HTML5] Best practice cheat sheet Message-ID: <45CDB400.20607@keryx.se> Hello! I work as a teacher (but do some development as well on the side). For the benefit of myself and my students i have strted to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) it is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. Many thanks. Lars Gunther P.S: I include an example of feedback i've already has got, in the form of my answer to Alexey Feldgendler: Alexey Feldgendler wrote: > 1. <body>, <title>, and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment-0001.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Sat Feb 10 04:01:04 2007 From: webmaster at keryx.se (Keryx Web) Date: Sat, 10 Feb 2007 13:01:04 +0100 Subject: [HTML5] Best practice cheat sheet Message-ID: <45CDB400.20607@keryx.se> Hello! I work as a teacher (but do some development as well on the side). For the benefit of myself and my students i have strted to put together a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as reference, to provide a historical perspective and some preparation for the future. Unlike other cheat sheets the emphasis is not on syntax, but on proper usage. Any feedback on my work is greatly appreciated. The cheat sheet is available (during development) at: http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) it is primarily intended for print, but when it reaches 1.0 status, I will probably make an HTML version as well. Many thanks. Lars Gunther P.S: I include an example of feedback i've already has got, in the form of my answer to Alexey Feldgendler: Alexey Feldgendler wrote: > 1. <body>, <title>, and <link> have semantic meaning. Added > 2. <script>: probably it's worth noting that scripts can only do document.write() in HTML, not in XHTML. Yes, and innerHTML does not work reliably as well. However, there are few good uses fo a beginner in JS to use document.write() at all. Unobtrusive techniques are recommended. I'll leave the rest to Google. > 3. I think <dialog> should belong with other list elements. > Perhaps, technically it belongs there. When i teach it's useful to explain exdactly what "semantics" is. > 4. <span> is inline. Very big OOOPS! (Accidentally deleted) > 5. <br> has a semantic meaning: it breaks lines wherever line breaking conveys meaning, e.g. in poetry. So it's not only an option for WYSIWYG. > I am very slow in introducing the semantic meaning of <br> as it often gives my students an "out". "But it's semantic, I may use it!" I'll leave it in parenthesis. > 6. ?Smallprint in HTML5? is the semantic meaning of <small>, not <sub>. > Once again, oooops! > 7. ?May be only option for WYSIWYG? should not only apply to <b> and <i>, but also to <tt>, <font>, <u>, <s>/<strike>. > Maybe - I believe that good WYSIWYG editors should stop enabling easy of bad code! I have introduced the thought, with <br>, <b> and <i>, since that's where the need is greatest. One should never use the <u> element - since underlined text should be reserved for links. WYSIWYG editors should not allow underlined text that's not a link, without strong words of caution! > 8. I believe unstyled tables have visible borders, haven't they? Yes. > > 9. Don't unstyled <thead> and <tfoot> repeat on each page of printed media? I'm not sure about this. I have never tested it either. it seems to be suggested by the spec, but left to the vendor to implement: http://css-discuss.incutio.com/?page=PrintingTables I'll leave this discussion from my "cheat sheet" as it is very hard to condense into one or two lines. "Sometimes repeated on each page when printed" mystifies more than it clarifies. > 10. Because <event-source> is invisible, it's not block. > Removed. > 11. <noembed> and <map> are invisible. Fixed! > > 12. <frameset> is normal. > Fixed! > 13. I believe ruby annotation elements have unstyled appearance. > So do I, but I have no idea what it looks like. I have never tried them. Many thanks Lars Gunther From zcorpan at gmail.com Sat Feb 10 07:30:49 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sat, 10 Feb 2007 16:30:49 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CDB400.20607@keryx.se> References: <45CDB400.20607@keryx.se> Message-ID: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Hi, On Sat, 10 Feb 2007 13:01:04 +0100, Keryx Web <webmaster at keryx.se> wrote: > I work as a teacher (but do some development as well on the side). > > For the benefit of myself and my students i have strted to put together > a cheat sheet of (X)HTML elements. Although only HTML 4.01 strict, XHTML > 1.0 strict and XHMTL 1.1 Mobile are recommended to my students for use > today, I include all of HTML 3.2, 4.01/X1.0 transitional/frameset, some > XHTML 2.0 and all of (X)(HTML 5 as well as some proprietary elements as > reference, to provide a historical perspective and some preparation for > the future. > > Unlike other cheat sheets the emphasis is not on syntax, but on proper > usage. Any feedback on my work is greatly appreciated. > > The cheat sheet is available (during development) at: > http://keryx.se/wasp/html_elements_beta.pdf > http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc) > > it is primarily intended for print, but when it reaches 1.0 status, I > will probably make an HTML version as well. <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. (<font> is only allowed for WYSIWYG tools, not for authors.) The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). <tfooter> should be <tfoot>. <wbr> isn't a soft hyphen, it's a "soft line break". Framesets will not be in (X)HTML5 AFAIK. According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. Nice work! Regards, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 02:49:27 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 11:49:27 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CEF4B7.70701@keryx.se> Simon Pieters wrote: > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in (X)HTML5. > Framesets will not be in (X)HTML5 AFAIK. > I thought <noembed> was allowed in the HTML serialization. As for the rest, are they "not in" as a decided fact, or "not in" as in "not documented yet". The draft actually mentions a lot of "not in" tags like <marquee> and even <spacer>, but has no specific list that says what is recommended, what is allowed and what is totally forbidden. At times it is ambiguous. I saw Ian saying on the what-wg list that he will take time in the future to "document" frames. If they get "documented", are they in or out? (This is why I gave them a question mark - looking like "yet to be written" in Wingdings) On the list I asked why document-write should be documented, and Ian asked that it is in use today, therefore it will be documented. But will it be recommended? 99 % of the uses for document.write() are bad practice and the last percent is for workarounds of MSIE bugs or not yet implemented features. And yes, I do use http://simon.html5.org/html5-elements I am confused about how definitive that list is though. > (<font> is only allowed for WYSIWYG tools, not for authors.) > Added. But what if a CMS uses something like TinyMCE or XStandard. If that WYSIWYG interface is badly written it may produce <font> tags. The author of the CMS has broken the rule, but the page author has not... I've added a new symbol ("s" in wingdings being a black diamond) meaning "sometimes available, depending upon serialization or other factors.) > The XML declaration and CDATA sections are not allowed in HTML5 (but they are allowed in XHTML5). Technically though they are allowed in HTML 3.2 and HTML4, since the former is just a processing instruction in SGML and CDATA sections are also allowed in SGML (not that they are generally supported in HTML UAs though). > The new symbol used. Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's allowed since it's officially an "application of SGML"? > <tfooter> should be <tfoot>. > I thought that was fixed. It has reappeared due to bad version control by me. Thanks! > <wbr> isn't a soft hyphen, it's a "soft line break". > Oops! I have never used it. Now I know something I did not before! > According to the latest WD of XHTML2, the <h1> to <h6> elements are present: http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-structural.html#sec_8.5. Once again, I thought that was fixed. I must get my version control under control! But they have appeared and disappeared in the spec a lot of times - haven't they! > <xmp>, <listing> and <plaintext> are deprecated in HTML 3.2. > Fixed > <label>, <fieldset>, <legend>, <optgroup>, <button> and <noscript> are not in HTML 3.2. > Correct you are. Slarvig ?r jag! <noscript> did not even bother checking. I just took that one for granted. Many thanks! Updated version uploaded. Lars Gunther From zcorpan at gmail.com Sun Feb 11 03:49:23 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Sun, 11 Feb 2007 12:49:23 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <45CEF4B7.70701@keryx.se> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> Message-ID: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Hi, On Sun, 11 Feb 2007 11:49:27 +0100, Keryx Web <webmaster at keryx.se> wrote: > Simon Pieters wrote: > > <acronym>, <h>, <big>, <center>, <u> and <noembed> are not in > (X)HTML5. > > Framesets will not be in (X)HTML5 AFAIK. > > > > I thought <noembed> was allowed in the HTML serialization. As for the > rest, are they "not in" as a decided fact, or "not in" as in "not > documented yet". It is a draft so anything can change, but if it's not in the spec at this time then it probably won't be. The only thing I've heard Hixie say probably being added is target="". (There have been suggestions to use <u> instead of <m> also.) > The draft actually mentions a lot of "not in" tags like <marquee> and > even <spacer>, but has no specific list that says what is recommended, > what is allowed and what is totally forbidden. At times it is ambiguous. > > I saw Ian saying on the what-wg list that he will take time in the > future to "document" frames. If they get "documented", are they in or > out? (This is why I gave them a question mark - looking like "yet to be > written" in Wingdings) "Authors must only use elements in the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts." -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 Simply put, any element that is not defined in the spec is disallowed. Even if an element is documented for UAs (to foster interoperability) it may not be allowed for authors to use (e.g. <frameset>, <isindex>). UA conformance requirements and authoring conformance requirements are separate. > On the list I asked why document-write should be documented, and Ian > asked that it is in use today, therefore it will be documented. But will > it be recommended? 99 % of the uses for document.write() are bad > practice and the last percent is for workarounds of MSIE bugs or not yet > implemented features. I don't see it being recommended nor discouraged by the spec. Should it be discouraged? > And yes, I do use http://simon.html5.org/html5-elements I am confused > about how definitive that list is though. Oh, it's not normative at all. I think it is correct though. :-) > > (<font> is only allowed for WYSIWYG tools, not for authors.) > > > > Added. > > But what if a CMS uses something like TinyMCE or XStandard. If that > WYSIWYG interface is badly written it may produce <font> tags. The > author of the CMS has broken the rule, but the page author has not... So then the authoring tool is non-conforming. > I've added a new symbol ("s" in wingdings being a black diamond) meaning > "sometimes available, depending upon serialization or other factors.) > > > > The XML declaration and CDATA sections are not allowed in HTML5 (but > they are allowed in XHTML5). Technically though they are allowed in HTML > 3.2 and HTML4, since the former is just a processing instruction in SGML > and CDATA sections are also allowed in SGML (not that they are generally > supported in HTML UAs though). > > > > The new symbol used. > > Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA > mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's > allowed since it's officially an "application of SGML"? HTML4 "recommend[s] that authors avoid using all of these features", but technically all SGMLisms are allowed. http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > [...] Cheers, -- Simon Pieters From webmaster at keryx.se Sun Feb 11 06:42:33 2007 From: webmaster at keryx.se (Keryx Web) Date: Sun, 11 Feb 2007 15:42:33 +0100 Subject: [HTML5] Best practice cheat sheet In-Reply-To: <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> References: <45CDB400.20607@keryx.se> <op.tnjhdnir7a8kvn@hp-a0a83fcd39d2> <45CEF4B7.70701@keryx.se> <op.tnk1slxc7a8kvn@hp-a0a83fcd39d2> Message-ID: <45CF2B59.3070509@keryx.se> >> I thought <noembed> was allowed in the HTML serialization. As for the >> rest, are they "not in" as a decided fact, or "not in" as in "not >> documented yet". > > It is a draft so anything can change, but if it's not in the spec at > this time then it probably won't be. The only thing I've heard Hixie say > probably being added is target="". (There have been suggestions to use > <u> instead of <m> also.) > Yes, I saw that and tried to argue against it. >> The draft actually mentions a lot of "not in" tags like <marquee> and >> even <spacer>, but has no specific list that says what is recommended, >> what is allowed and what is totally forbidden. At times it is ambiguous. >> >> I saw Ian saying on the what-wg list that he will take time in the >> future to "document" frames. If they get "documented", are they in or >> out? (This is why I gave them a question mark - looking like "yet to be >> written" in Wingdings) > > "Authors must only use elements in the HTML namespace in the contexts > where they are allowed, as defined for each element. For XML compound > documents, these contexts could be inside elements from other > namespaces, if those elements are defined as providing the relevant > contexts." > -- http://www.whatwg.org/specs/web-apps/current-work/#structure0 OK. A nice little list would help, though. >> On the list I asked why document-write should be documented, and Ian >> asked that it is in use today, therefore it will be documented. But will >> it be recommended? 99 % of the uses for document.write() are bad >> practice and the last percent is for workarounds of MSIE bugs or not yet >> implemented features. > > I don't see it being recommended nor discouraged by the spec. Should it > be discouraged? I consider it bad practice. >> And yes, I do use http://simon.html5.org/html5-elements I am confused >> about how definitive that list is though. > > Oh, it's not normative at all. I think it is correct though. :-) > And convenient. >> Surely only CDATA is allowed in HTML 3.2 and 4 - right? Is CDATA >> mentioned in the HTML 3.2 or 4.01 spec, or do you just infer that it's >> allowed since it's officially an "application of SGML"? > > HTML4 "recommend[s] that authors avoid using all of these features", but > technically all SGMLisms are allowed. > http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.3 > I used my symbol for "deprecated" (D in Wingdings = Thumbs down) and I've added the word "discouraged" to the explanatory notes. Lars Gunther P.S. Is there a counter for this list? It would be fun to see how many that might be listening in on this discussion. From webmaster at keryx.se Mon Feb 19 11:48:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 20:48:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things Message-ID: <45D9FF28.5070102@keryx.se> Hello again! Just to see how much my current practices differ from (X)HTML 5 I did a little test on my own page: http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se Some errors are understandable, but some are not: Line 9: "Element base from namespace http://www.w3.org/1999/xhtml not allowed in this context." When is it allowed, if not in the head element? Line 42: "Text not allowed here" and "Element a from namespace http://www.w3.org/1999/xhtml not allowed in this context." This is the faltering text: <div id="uRhere"> Du ?r h?r: keryx/startsidan. <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> Sidans menysektion: </div> A div may have text and inline content or block level elements, but not both, according to the spec? Am I wrong or is H Sivonens validator broken? Some more questions? Accesskeys - Gone for good? Javascript in <a href="javascript...."> (Yes I know it is bad practice. I was lazy.) - Gone for good? Many thanks! Lars Gunther From hsivonen at iki.fi Mon Feb 19 12:54:39 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 19 Feb 2007 22:54:39 +0200 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45D9FF28.5070102@keryx.se> References: <45D9FF28.5070102@keryx.se> Message-ID: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> On Feb 19, 2007, at 21:48, Keryx Web wrote: > Just to see how much my current practices differ from (X)HTML 5 I > did a little test on my own page: > > http://hsivonen.iki.fi/validator/html5/?doc=http%3A%2F%2Fkeryx.se > > Some errors are understandable, but some are not: > > Line 9: "Element base from namespace http://www.w3.org/1999/xhtml > not allowed in this context." When is it allowed, if not in the > head element? Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > Line 42: "Text not allowed here" and "Element a from namespace > http://www.w3.org/1999/xhtml not allowed in this context." > > This is the faltering text: > <div id="uRhere"> > Du ?r h?r: keryx/startsidan. > <a href="#maincontent">Hoppa till huvudinneh?llet (h)</a> > Sidans menysektion: > </div> > > A div may have text and inline content or block level elements, but > not both, according to the spec? Am I wrong or is H Sivonens > validator broken? I don't keep the validator in sync with the spec on a daily basis, so it is constantly more or less broken. Currently, I am writing *about* the software, so work *on* the software is suspended temporarily. Besides, I am hoping that <font> just goes away before I get around to expending the implementation effort. :-) When I last revised <div>, Hixie had made it block only. Since this is a high-visibility issue, I have made an unscheduled change and reverted it to bimorphic. I didn't add the new scoped <style> stuff, yet, though. > Accesskeys - Gone for good? Not in the spec yet. > Javascript in <a href="javascript...."> (Yes I know it is bad > practice. I was lazy.) - Gone for good? No. They aren't real URIs so they fail. I need to make a special case for them. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From webmaster at keryx.se Mon Feb 19 14:58:21 2007 From: webmaster at keryx.se (Keryx Web) Date: Mon, 19 Feb 2007 23:58:21 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> Message-ID: <45DA2B8D.7010305@keryx.se> Kitos Henri! Henri Sivonen wrote: > Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > OK, is xml:base in any way supported by the browsers of today. Any tests anywhere? > I didn't add the new scoped <style> stuff, yet, though. Once again, any browser that supports this today? Lars Gunther P.S. Henri, are you on the help list, or do I need to continue to specify your address separately? BTW, completely off topic: Henri, I remember reading (I think it was on Bugzilla) that you made a "note to self" to implement incremental rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? From lachlan.hunt at lachy.id.au Tue Feb 20 01:32:22 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 20 Feb 2007 20:32:22 +1100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DA2B8D.7010305@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> Message-ID: <45DAC026.8000400@lachy.id.au> Keryx Web wrote: > Henri Sivonen wrote: >> Your document is served as XHTML. <base> is not allowed in XHTML5 at all. > > OK, is xml:base in any way supported by the browsers of today. Any tests > anywhere? Yes. At least Mozilla, Opera and Safari do. >> I didn't add the new scoped <style> stuff, yet, though. > > Once again, any browser that supports this today? No, that's only a very recent addition to the draft. > BTW, completely off topic: Henri, I remember reading (I think it was on > Bugzilla) that you made a "note to self" to implement incremental > rendering of XHTML pages in Gecko. Am I wrong? If not, any news on this? Bug 18333 has been fixed. http://bugzilla.mozilla.org/show_bug.cgi?id=18333 -- Lachlan Hunt http://lachy.id.au/ From webmaster at keryx.se Tue Feb 20 02:20:56 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 11:20:56 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DAC026.8000400@lachy.id.au> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> Message-ID: <45DACB88.1080704@keryx.se> Lachlan Hunt wrote: >>> I didn't add the new scoped <style> stuff, yet, though. >> >> Once again, any browser that supports this today? > > No, that's only a very recent addition to the draft. > From 2002 it seems, but slow moving. > Bug 18333 has been fixed. > http://bugzilla.mozilla.org/show_bug.cgi?id=18333 > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. Now Presto, Webkit and KHTML need to implement it as well! Lars Gunther From hasather at gmail.com Tue Feb 20 03:17:32 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:17:32 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <45DACB88.1080704@keryx.se> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> Message-ID: <op.tn1obij9p8frts@puppy2> On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > Lachlan Hunt wrote: >> >> Bug 18333 has been fixed. >> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >> > > Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. > Now Presto, Webkit and KHTML need to implement it as well! Presto, at least, support incremental rendering. Not sure about others. -- David H?s?ther From hasather at gmail.com Tue Feb 20 03:31:29 2007 From: hasather at gmail.com (=?utf-8?Q?David_H=C3=A5s=C3=A4ther?=) Date: Tue, 20 Feb 2007 12:31:29 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1obij9p8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> Message-ID: <op.tn1oyrcsp8frts@puppy2> On Tue, 20 Feb 2007 12:17:32 +0100, David H?s?ther <hasather at gmail.com> wrote: > On Tue, 20 Feb 2007 11:20:56 +0100, Keryx Web <webmaster at keryx.se> wrote: > >> Lachlan Hunt wrote: >>> >>> Bug 18333 has been fixed. >>> http://bugzilla.mozilla.org/show_bug.cgi?id=18333 >>> >> >> Checked in 2007-01-30! Yay, we will see this in Firefox 3.0, I suppose. >> Now Presto, Webkit and KHTML need to implement it as well! > > Presto, at least, support incremental rendering. Not sure about others. KHTML seems to support it too. Tested Konqueror 3.5.5 on this: <http://www.damowmow.com/playground/bugs/18333/> -- David H?s?ther From webmaster at keryx.se Tue Feb 20 04:32:45 2007 From: webmaster at keryx.se (Keryx Web) Date: Tue, 20 Feb 2007 13:32:45 +0100 Subject: [HTML5] H Sivonens conformance checker says strange things In-Reply-To: <op.tn1oyrcsp8frts@puppy2> References: <45D9FF28.5070102@keryx.se> <0B45A725-4E11-43B2-902E-33C0210B329B@iki.fi> <45DA2B8D.7010305@keryx.se> <45DAC026.8000400@lachy.id.au> <45DACB88.1080704@keryx.se> <op.tn1obij9p8frts@puppy2> <op.tn1oyrcsp8frts@puppy2> Message-ID: <45DAEA6D.7040702@keryx.se> David H?s?ther wrote: >> Presto, at least, support incremental rendering. Not sure about others. > > KHTML seems to support it too. Tested Konqueror 3.5.5 on this: > <http://www.damowmow.com/playground/bugs/18333/> > OK. It as KHTML and Webkit share a lot of code, I'd imagine Safari either already supports this, or is not far from doing it. The "incremental loading is not supported" argument against XHTML is therefore on it's way to become a thing of the past. Does anyone know since what version Opera and Konqueror started to support this? Lars Gunther From zcorpan at gmail.com Wed Feb 21 16:56:17 2007 From: zcorpan at gmail.com (Simon Pieters) Date: Thu, 22 Feb 2007 01:56:17 +0100 Subject: [HTML5] Layout Problem: Floating Elements with different heights breaks the flow. In-Reply-To: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> References: <142e5f5b0702210958s38d1c851ma5040a95e7f14eba@mail.gmail.com> Message-ID: <op.tn4kv3o57a8kvn@hp-a0a83fcd39d2> (Sent to the help mailing list instead.) On Wed, 21 Feb 2007 18:58:17 +0100, Shlomi Asaf <neoswf at gmail.com> wrote: > Hi > i have a "table" like layout. > here is a live example: > http://www.webcssdesign.34sp.com/me/floatingDivs.htm > > all the floating divs has the same height. i haven't written the height > in > the css- the content is the same. > all the titles are one line height. > but what happens when one title is longer? the layout breaks and the > lower > float element looks for his position in a the next empty space - after > the > high element. This is because floats weren't actually intended for page layout. The main intended use was to float an image to the left or the right and let the text flow around the image. See e.g. http://dbaron.org/log/2005-12#e20051228a > how can i solve this problem? You could use display:table, but IE doesn't support that yet. Otherwise if scrollbars are acceptable then you could specify a max-height (in ems) and use overflow:auto. > [...] -- Simon Pieters From hsivonen at iki.fi Thu Feb 22 06:08:53 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Thu, 22 Feb 2007 16:08:53 +0200 Subject: [HTML5] The worst conformance checker error messages Message-ID: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> This is a question to those who have tried http://hsivonen.iki.fi/validator/html5/ I know that the most confusing error messages relate to the content model of <div> (and bimorphic content models in general). Other than that, what are the worst error messages you have faced? -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From lachlan.hunt at lachy.id.au Thu Feb 22 06:19:25 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Fri, 23 Feb 2007 01:19:25 +1100 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> References: <3AE54C65-5667-4CD5-B780-09222F89C6DF@iki.fi> Message-ID: <45DDA66D.90409@lachy.id.au> Henri Sivonen wrote: > This is a question to those who have tried > http://hsivonen.iki.fi/validator/html5/ > > what are the worst error messages you have faced? The most annoying thing about the validator is that it doesn't show fragments of the invalid code. I have to find the line and column number in the file before I can even figure out what the mistake is. Error messages become less confusing when read in the context of the specific section of code (though better messages always help). -- Lachlan Hunt http://lachy.id.au/ From sean at elementary-group.com Thu Feb 22 11:36:19 2007 From: sean at elementary-group.com (Sean Fraser) Date: Thu, 22 Feb 2007 11:36:19 -0800 Subject: [HTML5] The worst conformance checker error messages Message-ID: <57981.1172172979@elementary-group.com> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20070222/ba583713/attachment-0002.html> From jens.meiert at erde3.com Tue Feb 27 00:54:15 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 09:54:15 +0100 Subject: [HTML5] [html] Elements within "title"? Message-ID: <20070227085415.317650@gmx.net> Dear HTML Working Group(s), I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? Is there a general problem with adding semantics to that element's content [2], or is that "just" due to historical reasons? Thanks, Jens. [1] http://lists.w3.org/Archives/Public/www-html/2005Oct/0017.html [2] http://meiert.com/en/blog/20070226/html-semantics-of-title-element-content/ -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Tue Feb 27 01:48:43 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Tue, 27 Feb 2007 20:48:43 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <45E3FE7B.5070902@lachy.id.au> Jens Meiert wrote: > I once again [1] need to ask why the "title" element must not contain > other elements, although this might be quite desirable for certain > elements (like "abbr", for example)? For compatibility reasons in HTML, title cannot contain elements because of the way it is parsed. It would be possible to do so in XHTML, but then that would be another incompatibility between the 2 languages and there is also limited usefulness in doing so anyway, since many of the use cases for title are plain text. e.g. the window's title bar, bookmarks, search results, etc. -- Lachlan Hunt http://lachy.id.au/ From jens.meiert at erde3.com Tue Feb 27 01:57:59 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 10:57:59 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E3FE7B.5070902@lachy.id.au> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> Message-ID: <20070227095759.317660@gmx.net> > > why the "title" element must not contain other elements, > > For compatibility reasons in HTML, title cannot contain elements because > of the way it is parsed. It would be possible to do so in XHTML, but > then that would be another incompatibility between the 2 languages and > there is also limited usefulness in doing so anyway, since many of the > use cases for title are plain text. e.g. the window's title bar, > bookmarks, search results, etc. Well, but can't they just be ignored anyway? I understand that enabling other elements within "title" raises compatibility issues, but it can't be that hard to ignore them under certain circumstances, or is it? -- Jens Meiert http://meiert.com/en/ From hsivonen at iki.fi Tue Feb 27 06:22:23 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 16:22:23 +0200 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> Message-ID: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: > On Tue, 27 Feb 2007, Lachlan Hunt wrote: > >> For compatibility reasons in HTML, title cannot contain elements >> because of the way it is parsed. > > Compatibility with what? With the existing practice. > I guess you are thinking in terms of WHAT WG only, taking existing > browsers as something that HTML needs to be compatible with. It is not only in terms of WHATWG. It is in terms of market reality. > Logically speaking, you are saying that the <title> element cannot > contain elements because it has #PCDATA content, i.e. because it > cannot contain elements. It is true that changing this _could_ > break pages on some existing browsers. More to the point, it *would* break things. >> It would be possible to do so in XHTML, but then that would be >> another incompatibility between the 2 languages > > They are already completely incompatible, except in the trickery > sense that you can masquerade XHTML 1.0 so that it will be eaten by > existing browsers as the tag soup HTML that they can process. I think he meant the serializability of conforming XHTML document trees as HTML. > The real issue is whether the proposed extension would have too > serious drawbacks on current browsers that (probably) parse the > <title> content in a straightforward manner For reference, this is "RCDATA" in the HTML5 parsing algorithm. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Feb 27 07:37:31 2007 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 27 Feb 2007 17:37:31 +0200 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <57981.1172172979@elementary-group.com> References: <57981.1172172979@elementary-group.com> Message-ID: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Thanks to those who replied. I am positively surprised that the complaints did not involve the substance of messages emitted by RELAX NG validation engine at all. This means that the problems are fixable without hacking the validation engine, which in nice. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From CaptainN at unFocus.com Tue Feb 27 07:45:49 2007 From: CaptainN at unFocus.com (Kevin Newman) Date: Tue, 27 Feb 2007 10:45:49 -0500 Subject: [HTML5] The worst conformance checker error messages In-Reply-To: <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> References: <57981.1172172979@elementary-group.com> <2E580A58-2AA4-4228-8DB8-828E0AF09BF1@iki.fi> Message-ID: <45E4522D.4040307@unFocus.com> Henri Sivonen wrote: > Thanks to those who replied. > > I am positively surprised that the complaints did not involve the > substance of messages emitted by RELAX NG validation engine at all. > This means that the problems are fixable without hacking the > validation engine, which in nice. > > The only problem I've had with it is the vague error descriptions. For example, it says I can't use div tags in a lot of places, and provides a link to the top of some xhtml standards spec document, but doesn't actually explain why I can't use a div there (inside an li element for example). It'd be great if it could just tell you why something should not be used in a certain context. It would make the tool double as a kind of an HTML5 educational tool. Thanks, Kevin N. From _ at whats-your.name Tue Feb 27 09:47:55 2007 From: _ at whats-your.name (carmen) Date: Tue, 27 Feb 2007 12:47:55 -0500 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227085415.317650@gmx.net> References: <20070227085415.317650@gmx.net> Message-ID: <20070227174755.GA9894@replic.net> On Tue Feb 27, 2007 at 09:54:15AM +0100, Jens Meiert wrote: > Dear HTML Working Group(s), > > > I once again [1] need to ask why the "title" element must not contain other elements, although this might be quite desirable for certain elements (like "abbr", for example)? i doubt most, if any user-agents can fully render HTML in their title-bars anyways, if youre talking about <title> in <head> as for <title> elements within the <body>, i definitely use HTML within them, but put the un-marked-up version of the (typically http://purl.org/dc/elements/1.1/title) data in the content field of the tag in compliance with RDFa for easier parsing and edit-roundtripping.. From jens.meiert at erde3.com Tue Feb 27 10:40:16 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Tue, 27 Feb 2007 19:40:16 +0100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227174755.GA9894@replic.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> Message-ID: <20070227184016.268510@gmx.net> > > I once again [1] need to ask why the "title" element must not contain > > other elements, > > i doubt most, if any user-agents can fully render HTML in their title- > bars anyways, if youre talking about <title> in <head> It's not about /rendering/ at all (and you won't - or shouldn't, respectively - notice any difference concerning the appearance). It's solely about adding semantics to the "title" element's content. -- Jens Meiert http://meiert.com/en/ From jens.meiert at erde3.com Wed Feb 28 05:14:54 2007 From: jens.meiert at erde3.com (Jens Meiert) Date: Wed, 28 Feb 2007 14:14:54 +0100 Subject: [HTML5] German translation of "HTML vs. XHTML" Message-ID: <20070228131454.157660@gmx.net> FYI, the German translation of "HTML vs. XHTML" ([1], though the Wiki seems to stay unavailable ...), as fetched on February 12: http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ [1] http://wiki.whatwg.org/wiki/HTML_vs._XHTML -- Jens Meiert http://meiert.com/en/ From lachlan.hunt at lachy.id.au Wed Feb 28 05:58:06 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 00:58:06 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> Message-ID: <45E58A6E.2070409@lachy.id.au> Henri Sivonen wrote: > On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >> The real issue is whether the proposed extension would have too >> serious drawbacks on current browsers that (probably) parse the >> <title> content in a straightforward manner > > For reference, this is "RCDATA" in the HTML5 parsing algorithm. It should be noted that the definition of RCDATA in HTML5 is not quite the same as that in SGML (HTML 5 does not use SGML syntax), it's just similar to it. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:14:03 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:14:03 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <20070227184016.268510@gmx.net> References: <20070227085415.317650@gmx.net> <20070227174755.GA9894@replic.net> <20070227184016.268510@gmx.net> Message-ID: <45E58E2B.5020809@lachy.id.au> Jens Meiert wrote: > It's not about /rendering/ at all (and you won't - or shouldn't, > respectively - notice any difference concerning the appearance). It's > solely about adding semantics to the "title" element's content. What's the specific use case and what benefit does it provide? -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 06:56:35 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 01:56:35 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <45E4435B.6060806@Rhul.Ac.Uk> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <45E4435B.6060806@Rhul.Ac.Uk> Message-ID: <45E59823.3020408@lachy.id.au> Philip Taylor (Webmaster) wrote: > Henri Sivonen wrote: >> On Feb 27, 2007, at 13:44, Jukka K. Korpela wrote: >>> They are already completely incompatible, except in the trickery >>> sense that you can masquerade XHTML 1.0 so that it will be eaten by >>> existing browsers as the tag soup HTML that they can process. >> >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Whereas I think he meant the serving of XHTML 1.0 as HTML, > yet requiring browsers to /ignore/ the HTML semantics of > (e.g.) <META ... /> and to continue parsing further content > as HEAD matter, even though the "/>" has terminated the HEAD region. No, Henri was right. I did mean the serialisability. It may have been clearer if I'd said "that would be another incompatibility between the 2 [syntaxes or serialisations]" instead. In HTML5, HTML and XHTML are just different serialisations of the same language. However, for reasons mostly related to parsing, there are some differences in what can be represented in each. e.g. Namespaces in XHTML, but not in HTML; and <noscript> in HTML, but not in XHTML. -- Lachlan Hunt http://lachy.id.au/ From lachlan.hunt at lachy.id.au Wed Feb 28 07:20:44 2007 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Thu, 01 Mar 2007 02:20:44 +1100 Subject: [HTML5] [html] Elements within "title"? In-Reply-To: <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> References: <20070227085415.317650@gmx.net> <45E3FE7B.5070902@lachy.id.au> <Pine.GSO.4.64.0702271325580.5105@hopeatilhi.cs.tut.fi> <433C4B7E-A113-4A5B-8354-D39F352C265D@iki.fi> <Pine.GSO.4.64.0702271627580.4057@hopeatilhi.cs.tut.fi> Message-ID: <45E59DCC.4080304@lachy.id.au> Jukka K. Korpela wrote: > > On Tue, 27 Feb 2007, Henri Sivonen wrote: > >>> Compatibility with what? >> >> With the existing practice. > > Well, any change means _some_ deviation from the existing practice. You > seem to imply that any future version of HTML has to be suitable for > existing browsers. In practice, browsers will parse HTML5 exactly the same as they will parse legacy HTML pages (excluding some minor parsing differences in quirks mode). The HTML5 parsing algorithm has been written with that in mind. > While that has roughly been the idea when HTML has > been extended, it has never been very systematic. For example, when > tables were added a long ago, they weren't compatible in the sense that > non-table browsers would render them in any reasonably way (though there > were some tricks to get a somewhat reasonable rendering). HTML5 also introduces new elements that aren't fully compatible, like table when it was introduced, but adding new features is different from changing and breaking existing ones. > My question was whether that would be the case. I still don't see how, > though I'm not saying that allowing normal inline content in <title> > cannot seriously break anything. It's still an open question. There are legacy documents on the web that include markup significant characters like < and >. Changing the parsing to handle them as markup would break such pages simply because it is different from what browsers do today, and what authors rely on. >> I think he meant the serializability of conforming XHTML document >> trees as HTML. > > Perhaps, but that really amounts to feeding XHTML, written with some > special restrictions, to tag soup processors. XHTML is as serial as HTML. No, that's not right at all. In HTML5, the HTML serialisation must be served as text/html and the XHTML serialisation must be served as XML. But when either is parsed, the DOM (or other model) is still created with the elements in the XHTML namespace (though that is a change from existing browser behaviour). -- Lachlan Hunt http://lachy.id.au/