[whatwg] Suggestions and questions for Web Forms 2.0, 2004-12-26

[Ian Hickson]

On Sat, 8 Jan 2005, Matthew Thomas wrote:
> On 8 Jan, 2005, at 3:47 AM, Ian Hickson wrote:
> > > >
> > > > 2.3. Changes to existing controls
> > > > ...
> > > > Specifically, the form, legend, select, and optgroup elements may now be
> > > > empty.
> > > 
> > > 8.  *   "However, with the exception of the form element, authors
> > >         should avoid allowing any of these elements to be both empty
> > >         and visible for any noticable period, as it is likely to
> > >         confuse users."
> > 
> > Fair point.
> 
> Thanks. Now, "likely to confuse > users" --> "likely to confuse users". (And
> get yourself an e-mail client with a smarter Copy function.;-)

Oops. Fixed. My mail client is Pine running on a remote server using SSH. 
It has no copy function, I just copy-and-paste out of my terminal client 
into another terminal client running ssh showing Emacs running on a remote 
server...


> > The reason for both is the same -- it would mean changing how HTML 
> > content is parsed in ways that could affect existing content. I don't 
> > see how to concisely explain this in a useful manner before 2.18. Do 
> > you have any suggestions?
> 
> Something like:
> *   "The form element is therefore allowed in the head element of XHTML
>     documents, although only when the form element is empty. (This does
>     not apply to HTML, where a <code><form></code> tag has always
>     implied the end of any unclosed <code>head</code> element and the
>     beginning of the <code>body</code>.)"
> *   "Similarly, form elements in XHTML may now be nested (this does not
>     apply to HTML, where a <code><form></code> tag has always
>     implied the end of any unclosed <code>form</code> element)."

Good good. Taken. (With minor adjustments to the second.)


> > > > 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 (but not both).
> > > 
> > > 10. Why the exception of <div>?
> > 
> > The idea here is to allow certain cases that were disallowed in HTML4,
> > despite being semantically adequate. The <div> element, however, doesn't add
> > any semantics, and so doesn't make the case semantically adequate.
> 
> Semantically adequate for what? This will cause people to use semantic
> elements inappropriately (most likely, use <p></p> for something that isn't a
> paragraph), weakening the overall meaningfulness of the elements (for example,
> making a word processor's paragraph count return incorrect results). As Jim
> Ley said earlier
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-
> January/002798.html>, HTML elements cover Web-document semantics rather than
> application semantics, so the probability of HTML containing a non-<div>
> element appropriate for the meaning of any given form is near zero.

I don't really understand what you are asking for. This clause _loosens_ 
an HTML4 restriction; it allows markup that was previously invalid.

Could you give an example of what this allows that would be bad? I'm 
confused.


> > > > Authors are recommended to always have one radio button selected.
> > > > Having no radio buttons selected, or more than one in a group
> > > > selected, is considered very poor UI.
> > > 
> > > 11. Why mention "or more than one in a group selected"? UAs don't even
> > >     allow that (at least, not in standard HTML), so there's no point
> > >     raising the possibility.
> > 
> > As far as I can tell, this isn't true.
> 
> More than one in a group selected is not allowed (only the last is selected)
> in Internet Explorer 6 for Windows (and therefore presumably other
> Trident-based browsers), Internet Explorer 5.2 for Mac (and therefore
> presumably also MSN for Mac), Firefox 1.0 (and therefore presumably other
> Gecko-based browsers), Safari 1.2.4 (and therefore presumably other
> KHTML-based browsers), Opera 7.0 for Windows, and Opera 5.0 for Mac. What
> browser are you using that allows it?

Huh. Indeed. Good catch! I wonder how I had found the opposite to be true.

Fixed.


> > 2.5. Extensions to existing  attributes
> > > > ...
> > > >     UAs must now support the accesskey attribute on select elements.
> > > ...
> > >     Second, this removes the ability of a UA implementor to implement
> > >     type-ahead find as a more reliable (since some authors will
> > >     specify accesskeys and some won't) and quicker (especially if the
> > >     number of items in the menu is large) way of selecting an item
> > >     with the keyboard.
> > 
> > I don't understand how.
> 
> If they implemented type-ahead find for <select>, it would be dangerous to
> also implement accesskey for <select>, as typing letters would occasionally do
> something both momentous and unexpected -- activating an item instead of
> highlighting a possibly-different item.

Wouldn't that depend on exactly how accesskey is implemented? i.e. the UA 
can be written in such a way that this does not occur.


> > > 20. I dread the thought of any author reading the spec (or reading a
> > >     tutorial written by someone who has read the spec, etc) and
> > >     thinking that "The expected format is:" should be standard text
> > >     for their title=s!
> > >     *   "The expected format is:" --> "A part number is"
> > 
> > Fixed.
> 
> Thanks, but is the ":" really necessary? It makes the message look
> unnecessarily artificial (as if assembled by a computer program).

I used your text verbatim. :-)

Colon removed.


> > > > The value of the attribute, if set, should be autofocus.
> > > 
> > > 28. "autofocus" here is linked to the attribute definition, which is
> > >     wrong, because you are referring here to the value rather than to
> > >     the attribute itself.
> > 
> > Over-enthusiastic cross-referencing by the postprocessor I mentioned.
> > Fixed.
> 
> Another I missed: "Setting the DOM attribute to true sets the content
> attribute to the value _autofocus_."

Fixed.


> > > >     For textarea elements containing tags in HTML
> > > >     The tags should be parsed as character data, but entities and
> > > >     comments should be recognised and handled correctly. (This
> > > >     doesn't apply to XHTML.)
> > > 
> > > 34. Why not?
> > 
> > Because we can't change XML parsing rules.
> 
> So, "(This doesn't apply to XHTML because it would contravene XML parsing
> rules.)"

That works.


> > > 38. *   "an attribute" --> "a name or id attribute"
> > 
> > No, it really is any attribute.
> 
> What's the use case for performing such processing on a non-name/id attribute?

There's an example of using this with value="" in:

   http://www.whatwg.org/demos/repeat-01/


> > > 40. If the template is inserted before the block in which the button
> > >     is found, then the button itself (like the rest of its block) will
> > >     (in left-to-right text) move downward and/or rightward. This
> > >     usually won't matter mousewise, because a newly-created add button
> > >     usually will appear exactly where the just-clicked one was; but it
> > >     will still look odd in those environments where buttons are
> > >     focusable -- because focus will appear to have jumped, as a result
> > >     of a click, to something that is nevertheless not under the
> > >     cursor. If adding several blocks consecutively, there may be more
> > >     annoying effects for accessibility aids, since the mouse is
> > >     repeatedly encountering newly-created buttons with identical text,
> > >     rather than continuously hovering over the same button.
> > > 
> > >     Therefore, it would be better for the template to be inserted
> > >     after the block instead.
> > 
> > Then you have no way of inserting something at the top.
> 
> But right now you have no way of inserting something at the bottom!

Yes you do, a type="add" outside of repetition blocks.


> Perhaps for this reason, in all real-world examples I know of where each 
> repetition block has its own add and remove buttons, the add button adds 
> a row after the current one rather than before it. These examples are 
> the Smart Playlist dialog in iTunes, the Find window in the Mac OS X 
> Finder, the Rule editor in Apple Mail, and the Advanced Junk settings 
> dialog also in Apple Mail. (The accessibility reason given above doesn't 
> apply to these cases quite so much, since -- as I mentioned earlier -- 
> Full Keyboard Access is off by default in OS X.)

Hmm, interesting point.

Ok, "add" now adds after the current row. Now the only way to insert at 
the top of a set of repetition blocks is to add a blank row and move it to 
the top.


> > > 42. I propose that "move"
> > > <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-
> > > August/001634.html> be introduced now, instead of "move-up" and
> > > "move-down".
> > 
> > I'm sorry, but "move" is simply WAY too complicated. A real implementation
> > would want to do cool things like sliding elements in and out of the way as
> > you drag the other element above it,
> 
> Are iTunes and the Windows Start menu not "real implementations" of
> rearrangable items, then?

Fair point.


> > would need to support both keyboard- and mouse- driven interaction,
> 
> That's why I said: "And on platforms (or in accessibility situations) where
> focusing it was appropriate, it could be focused so a row could be moved up or
> down with the arrow keys."

Right. More complexity.


> > would need to implement all kinds of funky things in the rendering 
> > engine (e.g. how to handle a drag when the elements in question are in 
> > a 0.5 opacity block rotated 47 degrees
> 
> Implementation complexity circa 2005: use a dragging-in-progress cursor.

That doesn't solve the problem of working out where the drop is going to 
go. It's not trivial, and it's a real problem.


> > and passed through three SVG filters),
> 
> Perhaps I'm misunderstanding, but is native SVG support a requirement 
> for implementing Web Forms 2? If so, that should be noted in the spec. 
> If not, why will it be any great catastrophe that the SVG plug-in 
> produced by Bill McCoy's colleagues at Adobe doesn't support Web Forms 2 
> in its embedded HTML either?

The browsers that are looking at implementing Web Forms 2 are already 
implementing SVG.


> > I agree it's a good idea. I disagree that it is simple.
> 
> With respect, you did a particularly poor job of making it seem complex.

I'm not trying to "make it seem complex". It _is_ complex. WF2 is going to 
be hard enough to implement without requiring implementors to find 
solutions to the problems I listed and trying to implement what you 
described. The move-up and move-down buttons can be implemented in a few 
hours if not less. The "move" idea, while orders of magnitude better, 
would take days, if not weeks.


> > > > D. Requirements for declaring interoperability
> > > 
> > > 54. The sections listed in this section should be hyperlinked.
> > 
> > Yeah, that would be nice.
> 
> So, er, why not do it? :-)

Because at the time my hands were hurting and setting up links is a 
typing-intensive process.

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