[whatwg] Web Forms 2.0 - Comments on sections 1 and 2
ian at hixie.ch
Thu Jun 10 11:46:23 PDT 2004
On Mon, 7 Jun 2004, Laurens Holst wrote:
> Input precision attribute
> I think this should also apply to the 'time' type (and perhaps others).
> It would basically be nice to be able to say 'whole hours only'.
"Whole hours only" is an integer. Just use that. :-)
> (for that matter, isn't 'expdate' just a date with lower precision?)
It's a lot easier to have a type for such a common control than to have to
have to give two attributes including a precesion.
> 'range' type
> Well, what about... er... 'analog'... 'slider'... *thinks hard* no,
> that's about all I can come up with.
Yeah, if anyone can come up with a better name than "range" I'm all ears.
> The pattern attribute
> The problem is obviously that title serves a clear purpose right now and
> is fairly unrestrictive; I think using title for this would make people
> (unconsciously) 'abuse' it, because they do perhaps not realize there
> are special 'restrictions' tied to its use here. I don't think title
> fits using it in an error message very well (unless all major UA's will
> actually display it in the error message -you say 'may', after all-, but
> then there's also such a thing as context which could differ).
> OTOH, it *is* really the proper attribute to provide extra information
> in typically a tooltip. IMHO, title is ok. It will probably be abused,
> but the most popular UA's actually using it in their error messages (as
> opposed to some not using it) should help, and writing good title
> attribute texts need a manual anyway.
I'm not sure if you're saying that I should change the spec or not! :-)
I liked the idea of using title="" rather than a new attribute, because
then it would benefit legacy users too -- on browsers with no support for
pattern="", you still get the tooltip saying what the pattern should be.
> I also think that maybe you should leave adding the 'The expected format
> is:' string to the page author (inside the title element). This would
> remove all context problems among browsers using different phrasing for
> that, and don't forget there is also a language factor to keep in mind.
> "Het verwachte formaat: A digit followed by three uppercase letters."
> when using the Dutch translation of my favorite browser does look a bit
> weird. Also, take a look at this string... In high school (or maybe it
> was basic school) I learned that after a : colon you shouldn't start
> with a capital.
Fair point. Fixed.
> Maybe get it out of the error message entirely, and use something
> automated which translates the regular expression to plain English? ;p
Uh huh. :-P
> required attribute applies to all controls except radio buttons
> What about radio buttons in sets where none of the buttons are marked as
> checked? I really think this should apply to those as well.
The problem is, which control do you put it on?
> autofocus... true???
> I think it's weird that you are specifically recommending to use <input
> autofocus="true">, while you there is no such remark at <input required>
> (or <input required="required"> for xhtml). For that matter, <input
> autocomplete="off"> is also not very consistent. These are all booleans.
> I think they should therefore also 'work' the same. I can understand
> this not the case for autocomplete because of legacy support, but the
> other two...
Well, checked="checked" is for back compat, and autocomplete="off" is for
People complained about having to write required="required" in XHTML,
which is why I made it autofocus="true" instead of autofocus="autofocus".
Which do people prefer?
I've changed to to autofocus="autofocus" for now, although autofocus=""
(or "true") would also work with the current definition.
> By the way, it says "The following must not cause the autofocus
> attribute to be set: <input autofocus>"... Why not? That is exactly how
> other booleans such as checked and required work in HTML, and (unless
> I'm totally wrong about this) they appear to the HTML processor as if it
> were XML with 'attribute="attribute"', right? That's why XHTML needs you
> to write attributes without value like that.
It was not allowed because actually
...is shorthand for
...despite what you might guess. So according to the previous definition,
...would have been equivalent to
Now, however, that the value is the same as the attribute name, the value
can be omitted.
> The help attribute
> I clearly see a use for this in combination with CSS3 attribute
> selectors, :hover, :after and generated content (kay twould be a bit of
> a complex selector, but heh :) those are the fun ones).
I don't really see that it would be that useful even in those cases. You
want a whole URI for would effectively just be a big clumsy tooltip?
> Also, I see no reference whatsoever to a supposed 'hint' attribute on
> form controls in HTML 4.01. Maybe I am blind, but it probably just isn't
> there, so the note doesn't really make sense.
You misread it. The XForms "hint" attribute is "title" in HTML.
> Finally, "to show that it would be trivial to add to HTML as well"
> doesn't really express a very good reason to add the attribute. If that
> were the only reason, to show off, then it might as well not be there.
Exactly. I'm still thinking it should be removed.
Thanks for the comments!
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg