A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[IDEA] Making some HTML APIs more intuitive

trusktr
2016-03-31

For example, it is intuitive to do this:

<input type="text" disabled="false" />

and to someone’s dismay, it won’t be disabled.

New people to JavaScript often learn with jQuery. If we have

<input type="text" disabled="true" />

the form will start as disabled (yay!). The new user might be tempted to do

$('input').attr('disabled', 'false')

Things like that should work (though it doesn’t). It would make HTML better (easier to learn).

Proposal: if the value of a disabled, checked, etc, property is anything other than "false", make it behave as true, otherwise make it behave a false, not relying strictly on the existence of the property. These types of changes to HTML would make HTML more friendly.

AshleyScirra
2016-03-31

This is a non-backwards-compatible change, so then ultimately will end up breaking some existing websites (even more subtle changes can have surprisingly far-reaching effects, especially if a popular framework relies on it). All backwards-incompatible changes have to be weighed up against the benefit they bring. I’m not sure you will get much traction with browser vendors if you are proposing breaking changes only to make things a bit more friendly.

MT
2016-04-01

It could (but not necessarily would) make sense if designed this way from scratch. But not now that the specific attribute is supported by all browsers for many years.

And actually, once we have switched from XHTML back to HTML(5), boolean attributes became again quite cool in terms of that they provide a clean, nonredundant way to turn on something on code level. I really like the ability to specify:

<input name="example" required autofocus />

instead of something unreasonably longer like:

<input name="example" required="true" autofocus="true" />

As for your jQuery example, I believe that result of any development should be (and usually is) tested anyway. And if something does not work, it’s probably time to read some docs and, in particular, figure out what are differences between HTML attributes and DOM properties.

P. S. Suddenly realized the topic could be an April fools’ joke. %)

trusktr
2016-04-06

In this proposal, you’d be able to do

<!-- nice and short -->
<input name="example" required autofocus />

<!-- would behave the same as -->
<input name="example" required="true" autofocus="true" />

<!-- and this -->
<input name="example" />

<!-- would behave the same as -->
<input name="example" required="false" autofocus="false" />

It could (but not necessarily would) make sense if designed this way from scratch

True indeed. That’s the only problem with the web. All other frameworks deprecate or break API if they want. Too bad the web isn’t so flexible in that regard. It makes it harder to improve things.

Side note: It seems web APIs are breakable, f.e. things on MDN with a thumbs-down icon.

MT
2016-04-06

We already have a true / false mechanism in HTML: if an element has specific boolean attribute, this means true, while if the attribute is absent, this means false. This is already intuitive enough while elegant on code level (and works for many-many years since earliest versions of HTML created long before HTML5).

For the purpose of XML conformedness, XHTML allows to write required="" or required="required".