[whatwg] [html5] Pre-Last Call Comments

[Giovanni Campagna]

A few comments, as requested by Ian Hickson.

- End of 2.2.1, a typo: JavsScript instead of Javascript

- From section 2.4.2 I don't understand if boolean attributes with
invalid values represent "true" or "false". In addition, I don't
understand if an empty value is false (as in XHTML1.0) or true (as in
HTML4, because of the minimized syntax).
>From my experience, I expect that the empty string (which is
equivalent to not specify the attribute at all) is false, and any
other value is true.

- In 2.4.3 I don't see the point of all the digression about
contentEditable, since it is noted that it doesn't work like that. I
would leave the note to just "Note: The empty string can be one of the
keywords" or "Note: The empty string can a valid keyword"

- In 2.4.4.3 (and maybe in other places) I would prefer [A|E]BNF
instead of the prose description of a floating point number. I'm also
not sure that the normative algorithm is needed.
I've also searched IEEE, IETF, ECMA, ISO and ANSI for another
normative version of the syntax and processing, but I've found none.
If you think that it is important to have it specified completely, you
may submit an ID, so future technologies won't need to rewrite it
again.

- The second paragraph in 2.4.5.6 is hard to understand because the
verb is at the end. I would rewrite as "A week-year with a number *yr*
has 53 weeks if corresponds to a year *yr* in the proleptic Gregorian
calendar that has a Thursday as its first day (January 1st), or if
*yr* where *yr* is a number divisible by 400, or a number divisible by
4 but not by 100. In all other cases it has 52 weeks"
Also, don't rely on styles alone, use different words for identifiers
and prose. This includes also the Note following, where no styles are
applied and it is difficult to understand that "year year" is not a
typo but rather is the year numbered "year".

- Can't be simply referenced CSS3 Color in 2.4.6?
This way, implementors could have body[bgcolor] { background-color:
attr(bgcolor,color,white); } in the default CSS instead of using HTML5
specific rules.

- In 2.4.9 a valid hash reference must be equal to an ID, name is
supported only for backward compatibility.

- No comments for the URL part (except that Web Addresses is different
in processing, and the proposed IRI-bis draft makes it unnecessary)

- Section 2.6 is superfluous: handling of application cache is
specified in the appropriate section, handling of HTTP requests and
caches is defined in RFC2616, handling of cookie is defined in the
appropriate RFC (I don't remember the number), handling of about:blank
is in the proposed about-uri-scheme ID.
In addition, serialized queue-based handling of resources should not
be mandated by the HTML5 specification (can't UAs be multi-threaded?)

- Rewriting 2.6.1 without the HTTP word is definitely better. Browsers
are not required to support HTTP, AFAIK. You can write "a GET method"
(because GET is anyway an English word), "a response code" (most
protocols have response codes) and "metadata" (instead of headers,
that SMTP, POP, FTP don't support)

- 2.6.2 should be implied by the HTTP-over-TLS RFC

- In section 2.7.1, in sentence "Extensions must not be used for
determining resource types for resources fetched over HTTP.", do you
mean "File extensions", like .txt or .png, or "User agent extensions"
(additions to the algorithm)?

- Still in section 2.7.1, why the algorithm is a violation of RFC2616?
Because it is case insensitive? Because it allows spaces? Because it
does not imply ISO-8859-1 if no charset is explicit? Because it does
not imply ASCII for text/* mime types?

- Why don't you add "<?xml" to the sniffing table?

- In section 2.8, "x-x-big5" is not a different encoding than "big5",
it rather seems an alias (and as such should be submitted to IANA)

- Later in the same section, I don't understand why you don't support
those encodings, if the encoding declaration is explicit in the
protocol layer or is allowed by a different specification. For
example, XML allows EBDIC based encodings. In addition, I don't
understand why supporting UTF-32 or EBDIC means a change to the
algorithm, that are defined in terms of Unicode code points (very
similar to UTF-32 characters)

- In section 2.9.1, I completely don't understand the part about DOM
attributes of type HTMLElement, especially the subpart about setting.

- In section 2.9.5, instead of define DOMStringMap only for
EcmaScript, use explicit indexing operation in the IDL, add them the
[NameGetter] / [NameSetter] / [NameDeleter] attributes, and add a
[NoIndexingOperation] to the whole interface.

- In section 2.9.6 you discourage use of hasFeature. Firstly, if an
implementation says true and it is not compliant, it is not a spec
bug, it is an implementation bug. Secondly, to allow implementation
granularity, you could define more features (for example HTML 5.0,
XHTML 5.0, HTMLCanvas2D 5.0, HTMLSection 5.0, HTMLDatagrid 5.0,
HTMLMediaObject 5.0 etc.)

- In section 3.2.1, seems that interfaces other than Document and
HTMLDocument should be exposed by the object only if different
namespaces are found in the document. This is not true: SVG UAs for
example must always expose the SVGDocument interface on Document.

- document.lastModified should return null or the empty string if the
last modification date is not known (what if the document was really
last modified on January 1st 1970?)

- Parsing is outside the scope of section 3.2.3 and I don't understand
why CSS1Compat vs BackCompat if the quirks are limited to parsing

- On setting document.charset, if the specified charset is not
supported it should be treated as non registered.

- Why do we have both document.charset and document.characterSet?

- In section 3.2.4, about title in the author-only text, remember that
Document always implements SVGDocument and HTMLDocument.

- What on earth does "incumbent" mean? (about document.body)

- Is it necessary to have that mess of property indexing on
HTMLDocument (that, by the way, may be implemented along with other
language specific interfaces)? Just drop them at all: existing browser
will continue to implement it, but new browser won't, and neither new
sites will use it.

- Named elements is defined twice: once before the algorithm, and once after

- In section 3.3.3.7, instead of defining the syntax of style
attributes, reference <http://www.w3.org/TR/css-style-attr>

- In section 4.2.5.3, a document may have a default language even if
it doesn't have a content-language http-equiv, if it has a
Content-Language HTTP header.

- Section 4.2.7 should be completely delegated to CSSOM

- Noscript should be allowed in XML, just without the complexity (and
simply treated as display:none if scripting is enabled)

- And is a grammar mistake in "These juicy, green apples and make a
great filling for
  apple pies" (the example in 4.4.2)

- I completely cannot understand 4.4.10.2

- I would like to disagree with the man who disagreed with the other
man who disagreed with Ian Hickson (who said that things that are
impossible just take longer) (section about <q>)

- I don't think it is of any use to link a BBC article in 4.6.20

- Section 4.8.3 still refers to the Window Object specification, which
I think has been superseded by HTML5

- classid is not a conforming attribute for object, and yet it is used
in the algorithm to find a plugin. AFAIK, classid is only used by IE
(along with COM) so I don't think it is a problem to drop it
completely.

(skipping video and canvas)

- in HTMLFormElement, the function item should accept an integer, not
a DOMString (because it is an IndexGetter) Same in HTMLSelectElement

- In section 4.10.4, the table about which attributes applies to the
various input types overflows in Opera 9.64 (1280x768 being the
resolution, 12pt the font size) and it is very hard to read

- In 4.10.4.1.5 I expect that neither the user is able to see the password

- In 4.10.4.2.8 an "A" is missing in the part number example

I read all up to and including section 4. I think I will take a break
for now. The spec is incredibly long, but having an author only mode
definitely helps (anyway the review is for the whole spec, not just
the green parts).

I hope that this will help someone

Giovanni