[whatwg] WF2 part 1-3
Håkon Wium Lie
howcome at opera.com
Tue Aug 3 16:21:06 PDT 2004
I've spent some time reading through WF2 (as per 22 July 2004) and my
comments for parts 1-3 follow below. As it stands, the specification
is an impressive piece of work and I think it will become a
cornerstone of the web. I apologize if my issues have been discussed
at length on this list in the past.
> (although not necessarily structured XML submission).
I suggest: structured -> arbitrary
> The majority of the features that XForms supports using declarative
> syntax are, in this specification, handled by using scripting.
I disagree. Most features are described declaratively in both
specifications. WF2 may resort to scripting in a few places where
XForms remain declarative, but on the whole WF2 is also a declarative
> Compliant UAs must implement all the requirements of those
> specifications to claim compliance to this one.
Is this requirement a bit too ambitious? Are there any compliant HTML4
implementation out there (as per Ian Hickson's reading of the specs :)?
> Implementations may optionally implement only one of HTML4 and XHTML1.1.
I misunderstood the above sentence. By folding it into the previous
paragraph it will be better understood.
> Note: Documents that use the new features described in this
> specification cannot be strictly conforming XHTML or HTML4
> documents, since they contain features not defined in those
Right. I understand the distinction between conforming documents and
conforming UAs, but I fear the above will appear inconsistent compared
to the requirements on "compliant UAs" above.
> The children of a form element must be block-level elements, unless
> one of the ancestors of the form element is a td, th, li, dd, or
> block-level element other than div, in which case either
> block-level or inline-level content is allowed.
Why do they need to be block-level?
I don't like the <p> tags in the examples; this is not a paragraph:
<input name="count" type="number" min="0" max="99" value="1" />
> with the time zone set to UTC
I see the need for a UTC-based value, but expect the "local" variety
to be more used. How about calling them "datetime" and "datetime-UTC"?
> This type is used most frequently for dates in European industry.
editorial: "European industry" -> "Europe".
BTW, my emacs call week numbers "ISO date".
> UAs should make it clear to the user that the time does not carry
> any time zone information.
Again, I would reverse it: it's easier to communicate that something
is UTC (by showing those three letters) than to say that a time "does
not carry any time zone information".
> rogue user agents
Editorial: "non-conforming user agents"
> A field with a max less than its min can never be satisfied and
> thus must block a form from being submitted. This does not make the
> document non-conformant.
> For the control to be valid, the control's value must be an
> integral number of steps from the min value, or, if there is no min
> attribute, the max value, or if there is neither attribute, from
I may be confused by some key terms: valid vs. conformant vs.
successful. May I suggest a short definition up front somewhere?
> For the following control, the allowed values are fifteen seconds
> and two tenths of a second past the minute, any minute of the day,
> i.e. 00:00:15.2, 00:01:15.2, 00:02:15.2 ... 23:59:15.2:
> <input type="time" min="00:00:15.20" name="t">
Really? You are saying that each value fragment (hour, minute, second,
second fragment) is evaluated independently? Wouldn't it be more
useful to consider the value as one where 'min="00:00:15.20"' means
that all these values are allowed:
> For date controls, the value is in days, weeks, or months, for the
> date, week, and month types respectively. The format is an integer;
> one or more digits 0-9 interpreted as base ten.
Are negative values allowed? I would think not, and this should be noted.
> For numeric controls (number and range), the format is the number
> format described above, except that the value must be greater than
Editorial: a bit more context would be helpful here. I suggest: "...
the format of the step attribute is the number ..."
> When a control has a list attribute, the list of author-specified
> autocompletion values shall be given by the list of elements that
> would be found by first calling getElementById() ...
This is the start of a difficult description. Why not just say that
"The value of the list attribute is the ID of a datalist element which
contains a list of author-specified autocompletion values".
If this is too simple and the complex description is necessary, I
suggest softening it by stating that the list attribute "points to" a
list of values, rather than "specify a list of values"
> (This data is not made available to the page DOM.)
> The UA could hove used a rotary control,
spelling: hove -> have
> User agents may use this list to suggest to users the relevant
> parts of the document with which the user should interact to change
> the value.
How do you envision the suggestion to appear? Semantic relationships
are useful for many purposes, but the poor programmer left to
implement the specification needs a few suggestions.
> The min and max attributes apply to file upload controls and
> specify (as positive integers) how many files must be attached for
> the control to be valid.
Did you mean "successful" instead of "valid"?
> In this way, the accept attribute may be used to specify that the
> server is expecting an image, a sound clip, a video, etc, without
> specifying the exact list of types.
In this way, the accept attribute may be used to specify that the
server is expecting (say) images or sound clips, without specifying
the exact list of types.
> In HTML4, this attribute only applied to the text and password types.
The above text is marked up as a note, which is inconsistent with other
Compare these two:
> Authors should include a description of the pattern in the title attribute.
> When a control has a pattern attribute, the title attribute, if
> used, must describe the pattern.
They are saying slightly different things in slightly different ways.
I suggest keeping the first and striking the second.
> In this example, each row contains one form, even though without
> this attribute it would not be possible to have more than one form
> per table if any of them spanned cells.
In this example, each row contains one form. Without the "form"
attribute, it would not be possible to have more than one form per
table if any of them spanned cells.
> User agent implementors may curse authors who violate these rules,
> and may persecute them to the full extent allowed by applicable
> international law.
> UA implementors should divine appropriate behaviour by reverse
> engineering existing products and attempting to emulate their
Strike divine. Remember, browsers are monolithic dinosaurs with whom
no divine being would ever associate.
> ...except that then the names would all be the same -- all rows
> would be "row0", so there would be no clear way of distinguishing
> which "quantity" went with which "product" except by the order in
> which they were submitted.
This is a non-normative part of the spec, but I suggest making the
language slightly more formal.
> Note: To prevent an attribute from being processed in this way, put
> a non-breaking zero-width space character (﻿) at the start
> of the attribute. When the template is cloned, that character will
> be removed, but any other text in the attribute will be left alone.
> This could be useful if you have no control over the rest of the
> contents in the attribute, e.g. if it is user configurable text.
Why do we need this (arguably ugly hack) when the page author is free
to select a value for the ID attribute? Surely, it must be possible to
find a unique name? And, if curly brackets appear around a undefined
name no processing will occur, right?
> <tr repeat="1">
> <tr id="order" repeat="template" repeat-start="3">
I don't like the name of the repeat-* attributes. I suggest these names instead:
<tr id="order" repeat="3">
The "repeat" attribute indicates that the element is a template. In
HTML, the syntax can further be shortened:
<tr id="order" repeat>
repeat-min and repeat-max remain unchanged.
> Repetition templates can also be nested. The concept of hierarchy
> is expected to be represented in the names, as it is today in
> hand-rolled repeating forms, as in:
Editorial: Avoid "hand-rolled", this can confuse non-native speakers. I suggest:
Repetition templates can also be nested. The concept of hierarchy is
expected to be represented in the names, as in today's repeating
> Prefilled rows can contain any content; it need not match the
> template. In order to be considered a part of the repetition model,
> however, the row must have a repeat attribute with a numeric value.
> That value can be any integer. (For example, you could use "-1" as
> the value of all prefilled rows.)
I don't understand why it must not be a valid index.
> (although of course this may be further overriden by the stylesheet)
Editorial: drop "of course"
The repeat model is complex. Could we make is slightly simple by
dropping the repeat-template attribute?
Håkon Wium Lie CTO °þe®ª
howcome at opera.com http://people.opera.com/howcome
More information about the whatwg