- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 10 Jun 2004 18:46:23 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 June 2004 11:46:23 UTC