[whatwg] WF2 part 1-3

On Tue, 3 Aug 2004, [iso-8859-1] H?kon Wium Lie wrote:
>> 
>>  (although not necessarily structured XML submission).
> 
> I suggest: structured -> arbitrary

I agree that "structured" is the wrong word, but arbitrary is a bit strong 
-- it's not arbitrary in XForms, it's derived from the instance model. (In 
fact, it is a serialisation of the instance model.)

How about "arbitrarily structured"?


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

Nah, XForms is a _lot_ more declarative than WF2.

I changed it to:

  <p>Many of the less-used features that XForms supports using
  declarative syntax are, in this specification, handled by using
  scripting. Some new interfaces are introduced to simplify some of
  the more tedious tasks.</p>


>> 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 :)?

No, but then I don't expect there to be any WF2-compliant UAs either, per 
my reading of the specs. ;-)

It really makes no sense _not_ to require conformance to those other 
specs, since WF2 is just extensions to those specs and can't stand alone.


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

Fixed.


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

I've emphasised the word "Documents"; I don't know what else I can do.


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

HTML4 already requires this; I'm just loosening up the requirement a bit 
-- if one of the ancestors already conveys the block-level semantic, then 
you don't need it again.


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

Isn't it? It's a self-contained block of text, the smallest such unit of 
text that can be considered an independent block. Isn't that a paragraph?

What else would you call it?


>> 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"?

I like the current names because they convey an important difference -- 
"datetime" is a date and time, but "datetime-local" is explicitly a local 
date and time. If we called them "datetime-utc" and "datetime" 
respectively, I think you would have authors think that "datetime-utc" was 
just a thing for rare cases that wouldn't affect them, and they'd end up 
never using it, even when it was more appropriate.


>> This type is used most frequently for dates in European industry.
> 
> editorial: "European industry" -> "Europe". 

I haven't seen ISO weeks used anywhere except in European industry. Could 
you give an example of non-industry use? (Anything in business counts as 
"industry", IMHO, although I wouldn't be against changing the spec to 
say "European business".)


> BTW, my emacs call week numbers "ISO date".

Yes, they are ISO standard week numbers.


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

It wouldn't show UTC, in all likelyhood; it would show the local time 
zone.

The spec requires both that timezone-enabled types make it clear that 
there is a timezone and that timezone-ignorant types make it clear that 
there is no timezone. One way to do this would be for the UA to show the 
timezone in one and not the other.


>> rogue user agents
> 
> Editorial: "non-conforming user agents"

The paragraph was specifically referring to malicious users, so I think 
"rogue" in this context is actually correct.


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

Because it could be intentional, for example when a script is changing the 
min and max attributes, it could pass through a stage where max is lower 
than min, quite legitimately.

Also there doesn't seem to be any advantage to making it non-conformant. 
It's not something DTDs can catch anyway.


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

I added this paragraph to the terminology section:

| Form controls are valid when they comply to their constraints, and 
| invalid when they don't. This is distinct from whether form controls are 
| successful, which relates to whether they will be submitted.

The term successful is already defined, and the definition is linked to 
almost every time the term is used. The term conformant has its own 
section ("conformance requirement").

Is that paragraph enough, or do you think more needs to be done to explain 
these concepts?


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

No, I'm saying that the default step is "60" (seconds), and that the step 
starts at the "min" value.

Added a paragraph to clarify this.


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

To get this effect, you would say step="0.01".


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

Since no negative sign appears in that definition, no. But I've clarified 
it since all the other paragraphs in that section were clear already.


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

Fixed.


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

That has no conformance criteria, and doesn't say exactly how the list 
should be obtained.


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

Ok.


>>  (This data is not made available to the page DOM.)
> 
> Remove parenthesis

Done.


>> The UA could hove used a rotary control,
> 
> spelling: hove -> have

Fixed.


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

I don't, particularily. This was added based on a request from several 
accessibility experts on behalf of screen reader implementors.


>> 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"?

No.


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

Done.


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

Fixed the other similar sentences to be notes too.


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

There are two conformance criterita that I want to convey:

 1. for type="pattern", authors should include a title=""
 2. for type="pattern", title="" must describe the pattern

Striking the second sentence removes one of those. I'm open to suggestions 
on other phrasings that would convey both conformance requirements, 
though.


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

Fixed.


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

Hah. That would explain our troubles with complying to that part of the 
spec, at least...


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

Which part did you find too informal?


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

The hypothetical case this is trying to work around is the one where the 
page is generated dynamically but the ID used is static, and the data in 
the attribute is at least partially under the control of the user.

For example, if a title attribute in a template called "orders" included 
user data such as the name of the user's empire in a strategy game, then 
if the user happened to call his empire "[the] [orders] [empire]" then the 
title attribute would end up getting replaced by "the 2 empire" "the 3 
empire" etc.


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

Interesting idea.

The advantage of using repeat-* is that we won't ever clash with any other 
elements' attributes. "index", for example, could easily have clashed with 
something (although I don't think it does at the moment).

I also like the fact that "repeat" being used for both templates and 
repetition blocks means you can't have an element that is both:

   <tr index="1" repeat="1">

Also, the current attributes have already been implemented, and changing 
them yet again might therefore annoy some people. :-)

But your proposal is quite a lot simpler to the authors, which is a big 
advantage. What do people think?


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

Changed to:

  <p>Repetition templates can also be nested. The concept of hierarchy
  is expected to be represented in the names, as it is manually-created
  repeating forms, as in:</p>

...but other suggestions are welcome. Its the fact that there is no 
difference between existing, hand-rolled script-driven forms and the ones 
in WF2 which is important.


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

Who said it must not be a valid index?


>> (although of course this may be further overriden by the stylesheet)
> 
> Editorial: drop "of course"

Fixed.


> The repeat model is complex. Could we make is slightly simple by 
> dropping the repeat-template attribute?

It used to be a lot simpler. Then MarkS and others came along and made all 
these requests to make it "useful in the real world" or something... ;-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 22 August 2004 12:26:00 UTC