[whatwg] Web Forms 2.0 Feedback

[Ian Hickson]

On Sun, 29 Aug 2004, Csaba Gabor wrote:
>
> First, I'd like to thank you for your response.  It's rare that I 
> encounter anyone that can even appreciate these points.  And your 
> succinct direct addressing of the issues is also appreciated.

My pleasure.


> You've (implied or) asked for clarification on a few issues (points 1, 
> 2, 4, 5, 8), hence my response (interspersed on those points.

Thanks!


> In addition, there's one other point that I'd mention even though it 
> doesn't have to do with forms (but at least I'll get it off my chest).  
> That is, that I'd like to see a height specifiable in terms of number of 
> lines of text.  It's always struck me as strange that this isn't 
> standard.  For example, I might want all my TD elements to display at 
> most two lines of text.  I could try to set this in terms of em but if 
> there is a font change (or a size change in opera, say), I am sunk.  
> It's such a natural unit - why isn't it this part of the CSS standard?

You can, to some degree, do this using the "em" unit, as in:

   height: 2em;

The problem is that what you really want is a unit dependent on the 
line height, and the line height can change based on what is on the line, 
which makes this quite complicated.

However, I shall forward your request to the CSS working group. It's not 
the first time people have asked for this.


> > This sounds like what you are really requesting is a way for setting the 
> > coordinate when you call click(), so you would do, e.g.:
> > 
> >    image.click(2, 5);
> > 
> > Is that right? If so, that seems relatively simple to add.
> 
> Perfect:
> arbitraryHTMLElement.click(xLocalObjectOffset, yLocalObjectOffset)
> one issue: I would think that the elemtent's onClick should be run.
> Does this conflict with any current behaviour?

We'd probably have to do whatever it is that currently happens with the 
click() method -- which I believe doesn't trigger the event handler.

What was your use case for wanting the event handler to trigger?


> > > But as long as <input type=button/... is still around, why not give 
> > > it an access key property and allow a letter on it to be underlined?
> > 
> > That is already possible.
> 
> I must have missed something.  I know it's possible to put in an
> accessKey.  But how is it possible to underline a character on an
> input button such as
> <input type=submit value="Click me">
> ?

The general consensus is that if any underlining happens, it should be at 
the discretion of the browser, not the author. This is quite a complicated 
issue though, due to keyboards being different on different devices, etc.

We're still looking at exactly how to address access keys in general.


> > > 5.  One thing that bothers me is that there are so many ways to plop 
> > > a submit button on a page.  You could make a link with an image, an 
> > > <input type=submit onClick=...> element, an <input type=submit> 
> > > element, a <button type=submit>, <button type=button onClick=...>, 
> > > <input type=image ...>, <img ...>, image map, and probably I've left 
> > > several out.  This smacks of bloat.
> > 
> > There are pages that use each of those, so we can't really remove any 
> > of them.
>
> I'm not asking for removal (now).  I'm asking for deprecation, making 
> for cleaner pages in the future.  For example, <font> is allowed, but 
> deprecated.  Eventually it may go away.

<font> was deprecated because it was actually bad for the Web, for various 
reasons. Deprecating it means that it shouldn't be used, but, in the real 
world, browsers will always support it. There's just too much content that 
uses it, and that content isn't going anywhere -- it'll be with us for 
decades to come.

With the ways of submitting that you mention, though, they each have valid 
use cases, so I don't really see how we can deprecated any of them.


> > > I'd suggest combining type=image with type=button, submit, ... and 
> > > start depracating.  You could have a special src=submit/button/reset 
> > > value You could have <button type=image src='...'>alternate 
> > > text</button> Anyway, you understand my point: cull.
> > 
> > I don't really understand what is wrong with the variety?
> 
> OK, this is philosophy, but it may have its place.
> 
> Variety is great at the "end user" level where it amounts to art or 
> experimentation.  When it comes to standards, however, variety generally 
> indicates inefficiency (or bloat).  If there is more than one way to do 
> something, one of those ways should be more efficient.  If, on the other 
> hand, the different approaches are approximately the same, then it's 
> usually a good indication that there is either an inefficiency in the 
> design or inefficiency in (externally) dealing with it (this latter is 
> why these standards are being recommended, no?).

Well, granted, but browsers will be forced to support these features 
anyway, so removing them from the specs just means the browsers will have 
to guess how they work instead of just being able to follow the standards.


> The inefficiency will be that without a move toward clarification and 
> simplification, the bloat of the old model will be around to haunt us 
> for a LONG, LONG time.  That's why I recommend the notion of deprecating 
> those variants that are not necessary such as (<input type=image...>) 
> and (<input type=submit...>) and (<input type=button...>) and (<input 
> type=reset...>).

It's true that <input type="submit|button|reset"> is redundant with the 
<button> types of the same name, but it is not really bloat. The code 
required to implement both is quite trivial, they are generally just 
implemented in terms of the other.

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