[whatwg] WF2 part 1-3

[Håkon Wium Lie]

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
language.

 > 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
 > specifications.

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:

  <p>
    <label>
     Quantity:
     <input name="count" type="number" min="0" max="99" value="1" />
    </label>
  </p>


 > 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.

Why not?

 > 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
 > zero.

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:

 00:00:15.20
 00:00:15.21
 00:00:15.22
 ..
 00:00:16.00
 00:00:16.01
 ..
 00:01:00.00
 ..

 > 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
 > zero.

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.)

Remove parenthesis

 > 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.

I suggest: 

  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
similar sentences.


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.

I suggest:

 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
 > behaviour.

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 (&#xFEFF;) 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 index="1">
   <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
  HTML forms.


 > 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
              Håkon Wium Lie                          CTO °þe®ª
howcome at opera.com                  http://people.opera.com/howcome