- From: David Hyatt <hyatt@apple.com>
- Date: Thu, 10 Jun 2004 13:32:08 -0700
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. > `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 June 2004 13:32:08 UTC