[whatwg] Web Forms 2.0 - Comments on sections 1 and 2
hyatt at apple.com
Thu Jun 10 13:32:08 PDT 2004
Please do not change the type from range. This is a common term for
slider controls, and you can find the same term used in all sorts of
On Jun 10, 2004, at 11:46 AM, Ian Hickson wrote:
>> '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
>> The pattern attribute
>> The problem is obviously that title serves a clear purpose right now
>> is fairly unrestrictive; I think using title for this would make
>> (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
>> actually display it in the error message -you say 'may', after all-,
>> 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
>> 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
> pattern="", you still get the tooltip saying what the pattern should
>> I also think that maybe you should leave adding the 'The expected
>> is:' string to the page author (inside the title element). This would
>> remove all context problems among browsers using different phrasing
>> that, and don't forget there is also a language factor to keep in
>> "Het verwachte formaat: A digit followed by three uppercase letters."
>> when using the Dutch translation of my favorite browser does look a
>> 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
>> 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
>> autofocus="true">, while you there is no such remark at <input
>> (or <input required="required"> for xhtml). For that matter, <input
>> autocomplete="off"> is also not very consistent. These are all
>> 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
> back compat.
> People complained about having to write required="required" in XHTML,
> which is why I made it autofocus="true" instead of
> 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
>> 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
>> were XML with 'attribute="attribute"', right? That's why XHTML needs
>> to write attributes without value like that.
> It was not allowed because actually
> <foo bar>
> ...is shorthand for
> <foo something="bar">
> <foo bar="bar">
> ...despite what you might guess. So according to the previous
> <input true>
> ...would have been equivalent to
> <input autocomplete="true">
> Now, however, that the value is the same as the attribute name, the
> 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
>> 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.
> 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
>> 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
>> 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 )\._.,--....,'``.
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._
> Things that are impossible just take longer.
More information about the whatwg