Re: HTML5 Recommendation document review comments

our mails crossed - thanks for your response.

you may want to put some of your points in the individual bugs.

Aryeh Gregor wrote:
> On Sat, Jan 2, 2010 at 8:54 PM, Don Brutzman <brutzman@nps.edu> wrote:
>  > Didn't see any document metadata via <meta> tags inside the
>  > document itself.
> 
> If by "inside the document itself" you mean "inside the <body>", I
> don't think this is allowed unless the itemprop attribute is set, is
> it?  There are examples in the microdata section:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html

actually no, not inside that document body, but rather the <head>
section of the HTML5 document source itself

>  > Could also add a <link> entry providing a document icon, which is
>  > helpful in tabbed browsers.
> 
> Isn't this what rel="icon" does?

yes

> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-icon
> 
> It doesn't specify what UI the icon is to be used for, but HTML5
> doesn't usually try to specify UI.

again, this one wasn't trying to change the prose of the recommendation,
rather a note about the HTML5 document source itself

>  > About 2 dozen minor Tidy warnings shown by Mozilla that could be
>  > cleaned up.
> 
> Are you sure that Tidy understands HTML5?

latest announced version of Tidy is June 2008, so answer appears
to be no   http://tidy.sourceforge.net

 > The spec is written in
> HTML5, which has different syntax from earlier HTML standards.

OK.  but the reported problems are pretty pedestrian and not really
HTML5 specific.  here they are, will add them to bug 8587.

Result: 0 errors / 33 warnings

line 25721 column 32 - Warning: missing </caption> before <p>
line 25722 column 6 - Warning: <p> isn't allowed in <table> elements
line 25721 column 4 - Info: <table> previously mentioned
line 25723 column 6 - Warning: <p> isn't allowed in <table> elements
line 25721 column 4 - Info: <table> previously mentioned
line 25727 column 5 - Warning: discarding unexpected </caption>
line 49962 column 4 - Warning: nested emphasis <kbd>
line 49965 column 4 - Warning: nested emphasis <kbd>
line 50727 column 3 - Warning: nested emphasis <kbd>
line 218 column 11 - Warning: <link> inserting "type" attribute
line 218 column 349 - Warning: <link> inserting "type" attribute
line 218 column 728 - Warning: <script> inserting "type" attribute
line 20403 column 52 - Warning: trimming empty <p>
line 20415 column 46 - Warning: trimming empty <p>
line 25427 column 4 - Warning: trimming empty <dd>
line 25432 column 4 - Warning: trimming empty <dd>
line 25437 column 4 - Warning: trimming empty <dd>
line 25445 column 4 - Warning: trimming empty <dd>
line 25450 column 4 - Warning: trimming empty <dd>
line 25455 column 4 - Warning: trimming empty <dd>
line 25463 column 4 - Warning: trimming empty <dd>
line 25468 column 4 - Warning: trimming empty <dd>
line 25473 column 4 - Warning: trimming empty <dd>
line 25478 column 4 - Warning: trimming empty <dd>
line 25483 column 4 - Warning: trimming empty <dd>
line 25488 column 4 - Warning: trimming empty <dd>
line 25495 column 4 - Warning: trimming empty <dd>
line 25502 column 4 - Warning: trimming empty <dd>
line 25721 column 32 - Warning: trimming empty <caption>
line 25833 column 4 - Warning: trimming empty <dd>
line 25840 column 4 - Warning: trimming empty <dd>
line 25847 column 4 - Warning: trimming empty <dd>
line 25987 column 4 - Warning: trimming empty <dd>
line 26020 column 4 - Warning: trimming empty <dd>
line 61589 column 472 - Warning: trimming empty <span>
Info: Doctype given is "-//W3C//DTD HTML 4.01 Transitional//EN"
Info: Document content looks like HTML 4.01 Transitional

>  > Further, an empty string isn't
>  > allowed as an enumeration value in XML Schema
>  > enumeration lists, so it is not clear how to
>  > represent it in such a context.
> 
> I'm pretty sure compatibility with XML Schema is not a design goal of
> HTML5.

agreed.  wasn't trying to impose schema, simply pointing out that defining
an empty string can be difficult, and so both intent and application of the
paragraph seems unclear.

 > There's already a validator that can validate far more than
 > XML Schema can, though: http://html5.validator.nu

cool.  i gingerly tried to feed it the 72,253-line HTML5 document but got

 IO Error: Resource size exceeds limit.
 There were errors. (Tried in the XHTML mode.)
 Total execution time 1017 milliseconds.

meanwhile the W3C validator at http://validator.w3.org gave 6 errors:

Line 218, Column 735: required attribute "TYPE" not specified

Line 25722, Column 8: document type does not allow element "P" here; missing one 
of "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag

Line 25723, Column 8: document type does not allow element "P" here; missing one 
of "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag

Line 27375, Column 10: document type does not allow element "TFOOT" here; 
assuming missing "TABLE" start-tag

Line 27379, Column 10: end tag for "TABLE" which is not finished

Line 72252, Column 4: end tag for "TABLE" omitted, but its declaration does not 
permit this

added as new bug
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8608

>  > states
>  >        Element.tagName and Node.nodeName
>  >        These attributes must return element names converted to
>  >        ASCII _uppercase_, regardless of the case with which they
>  >        were created.
>  >
>  > and then
>  >        The canonical form of HTML markup is all-lowercase;
>  >
>  > also in section 3.3 APIs in HTML documents
>  >        when looking at HTML elements, the argument must first be
>  >        converted to ASCII lowercase
>  >
>  > This seems inconsistent.  Should the first _uppercase_ instead be 
> lowercase?
> 
> I don't think so.  I get the behavior described in the spec, which I
> assume is required for historical reasons:
> 
> data:text/html,<!doctype
> html><script>alert(document.createElement('br').tagName);</script>

ok if you say so, i really don't know...

inserting an explanation for the apparent inconsistency (if uppercase
is indeed correct in this context) might be a good way to resolve the bug.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br           brutzman@nps.edu
Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA  work +1.831.656.2149
X3D, virtual worlds, underwater robots, XMSF  http://web.nps.navy.mil/~brutzman

Received on Monday, 4 January 2010 00:15:13 UTC