[whatwg] Web Forms 2.0 - Comments on sections 1 and 2

[Ian Hickson]

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

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

   <foo bar>

...is shorthand for

   <foo something="bar">

...not

   <foo bar="bar">

...despite what you might guess. So according to the previous definition,

   <input true>

...would have been equivalent to

   <input autocomplete="true">

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.   `._.-(,_..'--(,_..'`-.;.'