- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Sat, 8 Jan 2005 23:12:40 +1300
On 8 Jan, 2005, at 3:47 AM, Ian Hickson wrote:
> ...
> Thanks again for your detailed and substantial comments.
Thanks for the changes.
> ...
>>> 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.;-)
>>> Also, as controls no longer need to be contained within their form
>>> element to be associated with it, authors may prefer to declare their
>>> forms in advance, at the top of their documents. 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.)
>>>
>>> Similarly, form elements in XHTML may now be nested (this does not
>>> apply to HTML).
>>
>> 9. Why don't these apply to HTML? The explanation of the former is
>> buried waaaay down in a parenthesis in section 2.18. There doesn't
>> seem to be an explanation of the latter at all. It would be nice
>> if these were explained more promptly.
>
> 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)."
>>> 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.
>>> 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?
> ...
> 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.
> ...
> Presumably the new wording solves this.
Yes, thanks.
> ...
>> 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).
> ...
>>> 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_."
> ...
> <p>The <code>rows</code> and <code>cols</code> attributes of the
> <code>textarea</code> element are no longer required attributes.
> When unspecified, CSS-compliant browsers should lay the element out
> as specified by CSS, and non-CSS UAs may use UA-specific defaults,
> such as, for visual UAs, using the available width on the page and a
> height suitable for the device.</p>
Good, thanks.
> ...
>>> 2.15. Extensions to file upload controls
> ...
>> 32. Ehhhh. Why not just allow the value "any", as is done for step=?
>
> Because it would only make sense for file uploads and I didn't want the
> added complexity just for this one edge case. (Let's face it, there'll
> always be a maximum here.)
Fair enough.
> ...
>> 33. "Web logging"? Some old-fashioned newspapers refer to them as "Web
>> logs", but they're much more commonly "Weblogs". (See also
>>
>> <http://en.wikipedia.org/w/index.php?
>> title=Talk%3AWeblog&diff=1399541&oldid=1283187>.)
>
> They're most commonly referred to as "blogs". "Weblog" seems weird to
> me.
"Blog" is a May 1999 abbreviation of "Weblog".
<http://peterme.com/archives/00000205.html>
>>> 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.)"
> ...
>> 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?
> ...
>> 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!
Wanting that is far more likely than wanting to add to the top. ("Oh,
I've run out of room for all the stuff I want to enter; I'll just add a
few more rows.")
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.)
> ...
>> 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?
> 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."
> 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. Implementation complexity circa 2006: use a
dragging-in-progress cursor, plus a dotted outline of the element's
extent. Implementation complexity circa 2007: start thinking about
maybe doing something like compositing a semi-transparent copy of the
item for dragging. Y'know, if your UA programmers really have nothing
better to do.
> 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?
> and so forth.
>
> 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. Nothing you just described is a requirement for an adequate
implementation, except for keyboard access, and implementing that would
be exactly as easy as implementing keyboard access for move-up and
move-down.
> ...
>>> 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? :-)
> ...
>> 56. The raw URIs in the JavaScript 1.3 reference, the RFC references,
>> and the XBL reference should all be hyperlinked.
>
> The links already point to them. It would be silly to have the same
> link twice, and would just look busy.
> ...
I thought you were already having the same link twice for most of the
references, but now I see the distinction is between static and latest
versions. Oops.
--
Matthew Thomas
http://mpt.net.nz/
Received on Saturday, 8 January 2005 02:12:40 UTC