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

[David Hyatt]

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 
modern toolkits.

dave

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