On Tue, 10 Mar 2015, at 22:44, Jonas Sicking wrote:
> On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
> >
> > On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote:
> >> I think I'd prefer to define "on" and "off" as defined values unless
> >> there is very little usage of them. We can certainly mark them as
> >> deprecated, but unless their usage is negligible, it seems better to
> >> document their behavior than to try to change all existing content not
> >> to use it.
> >>
> >> Especially since it'll also make the .autocapitalize JS property
> >> behave less surprising "on"/"off" is used.
> >
> > "off" is defined. The "Non-conforming" note means that the attribute
> > reflection will behave like this:
> > ```js
> > input.autocapitalize = 'off';
> > input.autocapitalize === 'none'; // true
> > ```
> 
> Right. My point is that this is unnecessarily confusing. Just like
> 
> input.autocapitalize = 'on';
> input.autocapitalize === 'sentences'; // true
> 
> is unnecessarily confusing.

How is that different from
```js
input.type = 'foo';
input.type === 'text'; // true
```
Unless we expect that doing |input.autocapitalize = 'on'| is common use
case. Which I think isn't.

> Just like leaving mention of "on" out of documentation and specs would
> be confusing for authors that are looking at other people's code and
> learning from it (which is one of the great powers of the web
> platform).

The specification should definitely mention "on" in a non-normative
section. The same way it should mention "off" as an allowed but
deprecated value.

I will have to double-check that but I wonder if the IDL attribute isn't
always returning undefined on Safari iOS. At least, I wasn't able to use
it last time I checked. Would that solve your concerns?

-- Mounir

Reply via email to