- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 22 Aug 2004 19:37:19 +0000 (UTC)
On Wed, 4 Aug 2004, fantasai wrote: > > > > > > For the following control, the allowed values are fifteen seconds > > > and two tenths of a second past the minute, any minute of the day, > > > i.e. 00:00:15.2, 00:01:15.2, 00:02:15.2 ... 23:59:15.2: > > > > > > <input type="time" min="00:00:15.20" name="t"> > > > > Really? You are saying that each value fragment (hour, minute, second, > > second fragment) is evaluated independently? Wouldn't it be more > > useful to consider the value as one where 'min="00:00:15.20"' means > > [that all times after 00:00:15.20 are valid]? > > I agree with this. I don't understand what exactly it is that you are agreeing to. > > > When a control has a list attribute, the list of author-specified > > > autocompletion values shall be given by the list of elements that > > > would be found by first calling getElementById() ... > > > > This is the start of a difficult description. Why not just say that > > "The value of the list attribute is the ID of a datalist element which > > contains a list of author-specified autocompletion values". > > > > If this is too simple and the complex description is necessary, I > > suggest softening it by stating that the list attribute "points to" a > > list of values, rather than "specify a list of values" > > The complex description is necessary, but may not need to be quite so > algorithmic. > > The list attribute of a form control can be used to specify the ID of a > datalist element that contains a list of author-specified autocompletion > values. If the attribute is present and gives the ID of an (X)HTML datalist > element in the document, then the UA must compile the autocompletion list > for the form control from all of the datalist's non-disabled descendant > (X)HTML option elements, using either the value of each option's 'value' > attribute (if present) or, (if not present) the concatenation of its textual > contents as an autocompletion value. If, however, the autocompletion value > is the empty string or is not a valid value for the control's type, then > that value must instead be ignored. The UA may use an option's label > attribute to annotate the corresponding autocompletion value in its > interface. > > [Insert any error-handling confusion here.] I prefer the current version. It's clearer, IMHO. (It's not the same as the text that the above was intended to replace.) > There's a lot of complex and twisty text in the spec to get around the > namespace juggling. I think it should all be defined (and thereby > confined) in a section at the beginning so it doesn't convolute already > complex sentences throughout the spec. Something like > > In this specification, an (X)HTML element is one which is > - a regular element in an HTML document > - an element in the XHTML namespace (http...) > An (X)HTML attribute is one which is > - a regular attribute in an HTML document > - a local attribute of an element in the XHTML namespace (http...) > - an attribute in the XHTML namespace on an XML element not in the > XHTML namespace That's much to generic. It would end up making a lot of attributes apply to all elements when that is emphatically not what we want. Only a small number of attributes should be global (in the namespaces-in- xml sense). I'd rather deal with these on a case-by-case basis. In WF3 (and maybe in WA1), we could consider writing some generic text of this kind for all the global attributes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 22 August 2004 12:37:19 UTC