[whatwg] Various attributes

Ian Hickson ian at hixie.ch
Wed Jun 16 09:55:01 PDT 2004

On Sun, 13 Jun 2004, Jim Ley wrote:
> maxlength - what happens when maxlength is shorter than the minimum
> length required to express the document type (e.g. type="tel"
> maxlength="1") should the form never be submitted, should this
> restriction be ignored, or should all restrictions be ignored, or what?

It won't be submittable with a value. I've added a note to that effect.

> Why require the ^ and $ in the regexp, what's the point in the restriction?

They are not required; they are implied. The reason is that otherwise
authors would almost always have to add them, which would be the source of
much confusion.

For example:


...would match anything with a dash with two or more characters on each
side, instead of matching only two characters, a dash, two characters,
which is what it would match according to Web Forms 2.

> Overriding title to include the expected format as well as the normal
> accessibility uses is incompatible (because the resulting "... could cause
> the UA to display an alert such as:" will likely not make sense with the
> relevant normal use of title in it.

Let me know if the new text is better.

> Why doesn't the required attribute apply to check-box's (use case"do you
> agree to the terms and conditions?")

If a checkbox is required, there is no point having a checkbox. For "do
you agree" type checkboxes, the server should handle the "don't agree"
case, IMHO.

> form attribute:
> "A form attribute that specifies an ID that occurs multiple times in a
> document should select the same form as would be selected by the
> getElementById() method for that ID ([DOM3CORE])"
> DOM3 core says:
> "If more than one element has an ID attribute with that value, what is
> returned is undefined. "
> I'm not sure of the point of referencing another spec simply to say the
> behaviour is undefined, why not say it straight?  Or are you trying to say
> something else?

getElementById's behaviour is undefined, but whatever the UA does with
gEBI, that's what the form attribute should do. That's what the text is

> autocomplete:  the MUST restriction on off not pre-filling is too
> restrictive, what is the motivation of this?

Banks require this of UAs anyway. IE and Mozilla implemented this years
ago. WF2 is just documenting implemented behaviour.

> SHOULD is more appropriate.

SHOULD makes no sense. If they don't follow the attribute, they clearly
don't support it. The entire point of the attribute is to ensure that the
UA never record the data.

> autofocus - this is incompatible with basically accessibility

Why? It can be done now with JS, surely a declarative solution is better?

> "In the following snippet, the text field would be focussed when the
> document was loaded."  please define "document was loaded" does this mean
> the onload event fired for the document root element, or does it mean the
> input element was rendered - in which case does two autofocussed elements
> mean a cascade as each is rendered?

It's an example, hence non-normative, hence the text is just trying to
explain it not define it. The text above defines strictly how it is

> None of this is acceptable to me, a preferred approach would be what is
> often implemented by more competent scripters - that of "if onload no
> form elements have been modified, and there's the ability to set focus
> then focus is set to an element in the form, I would like this to go
> further such that no keys had been pressed or other elements given focus
> etc. that is normally beyond even the reasonable scope.

Yeah, that makes sense. Added a clause to take care of that and made it a
SHOULD for you.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list