- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 21 Jan 2005 12:36:34 +0000 (UTC)
On Thu, 20 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. > > I am asking: "semantically adequate" for what? For conveying the context of the form controls. > In that case, I am asking: why the exception of <div>? Because <div> doesn't add anything to the context. > 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. The last two points are the same. All it would do is make the spec simpler (removing three words, hardly a huge simplification) and make it slightly easier to write tools to catch errors, at the cost of reducing the number of errors that would be caught. > 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). Could you show me the markup of a case where this exception would be harmful? > > 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 show an example? > > 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. Ok, then can you give an example of what this encourages that would be bad? Because I'm quite seriously not seeing it. Most of the time, form controls should have a <p>, <li>, or <dd> ancestor. I don't think I've ever seen a case where this would not be true, in fact. Of course, it might be that you and I disagree on the definition of <p>: http://whatwg.org/specs/web-apps/current-work/#the-p > > > > 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. I honestly have no idea what you mean here. When is Enter part of a type-ahead-activate action? The whole point of type-ahead find is that you don't need to hit Enter, no? > > 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(). Well, yeah, scripts can always do stuff. > > > > > 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? Because the line from your proposal didn't take it into account. > > 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. I doubt it. (And <area> is not exactly reliably implemented.) > > > > 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. It is also a _massive_ undertaking. Tell you what. Implement (or have someone implement) type="move", demonstrate that it can be done as reliably as type="move-up" and "move-down", demonstrate that it isn't a problem for small devices, and then I'll be happy to include it in the draft. Given the experience I have with convincing people to implement things that I thought were "simple", I do not feel confident that type="move" would be implemented usefully. I'd love to be proved wrong. But I'm not gambling the entire repetition section on it. > 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)? SVG and WF2 are completely independent. It just happens that they will be implemented at the same time in several UAs, and so their interaction needs to be sanely defined. > 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? I was talking of native implementations, not IE or plugins. > 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? Because in the implementations I most care about, I will end up having to test how they interact, and I can see from here that it will (a) not be implemented right and (b) will remain buggy for years, unlike the massively simpler idea of simply having a button. I love the idea of type="move". It's the kind of thing I would love to put in WF3. But it's simply not realistic to expect WF2 implementors to spend the time it would require to make that feature work correctly. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 21 January 2005 04:36:34 UTC