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

[Matthew Thomas]

On 19 Jan, 2005, at 7:46 AM, Ian Hickson wrote:
>
> On Sat, 8 Jan 2005, Matthew Thomas wrote:
> ...
>>>>> 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.

I am asking: "semantically adequate" for what? I suspect that question  
doesn't have a good answer, since there are not HTML elements (block or  
otherwise) encompassing the purposes of forms. (I suppose the form on  
<http://quotationspage.com/contribute.php>, if inline, could be  
surrounded by <blockquote> -- but even that would be stretching it, and  
doing so would have zero benefit for the Web anyway.)

In that case, I am asking: why the exception of <div>? I suspect that  
question doesn't have a good answer either.

In that case, I am asking *for* the exception of <div> to be removed.  
This would make the spec simpler, easier to implement, and (though you  
may not care about this point) easier to write error-checking tools  
for. Last but not least, it would decrease the probability that authors  
would misuse semantic block elements, in exchange for a near-zero  
increase in people using <div> when they should be using something else  
(since, as I said, the something-elses encompassing the purposes of  
forms don't exist in HTML anyway).

> This clause _loosens_ an HTML4 restriction; it allows markup that was  
> previously invalid.

It loosens the restriction in such a way as to leave a slanted playing  
field. There is now a situation where non-<div> block elements are  
allowed but <div> is not. That will encourage people to use non-<div>  
elements when they are not appropriate.

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

I doubt that. The point is not what it allows, but what it encourages.

> ...
>>> 2.5. Extensions to existing  attributes
>>>>> ...
>>>>>     UAs must now support the accesskey attribute on select  
>>>>> elements.
> ...
>> 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.

That would count for little when pressing Enter has become an  
instinctive part of peoples' type-ahead-activate action.

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

Or to use addRepetitionBlockByIndex().

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

Then what was the point of mentioning opacity?

> It's not trivial, and it's a real problem.

Which is why I provided a complete solution for it (with diagrams,  
even) in my original message.  
(<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004- 
December/002780.html>, item 42.) It's not trivial, but it's an order of  
magnitude less complex than (for example) HTML 3.2's <area> element.

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

Which, in amusing contrast, is an order of magnitude *more* complex  
than HTML 3.2's <area> element.

So is the eventual Internet Explorer 6 implementation of Web Forms 2  
supposed to include a complete, non-plug-in implementation of SVG  
(constructed from nothing but HTCs and a rusty coathanger)? If not,  
back to my previous question: Why will it be any great catastrophe that  
<input type="move">, like the whole of the rest of Web Forms 2, is not  
supported in the embedded HTML of a plug-in implementation of SVG? And  
if it will not be any great catastrophe, then why are you raising the  
prospect of SVG filters applied to draggable items (and why did you  
mention opacity earlier), if not in an attempt to make <input  
type="move"> seem more complex than it is?

> ...
>> With respect, you did a particularly poor job of making it seem  
>> complex.
>
> I'm not trying to "make it seem complex".
> ...

-- 
Matthew Thomas
http://mpt.net.nz/