opened
isiahmeadows
username_0
I personally find it a little unintuitive that `contenteditable` doesn't accept `"contenteditable"` as an alias for `"true"` to support the HTML5 shorthand, especially when the empty string also is one. I find `"false"` to be relatively uncommon, since usually, it's not common to include non-editable children within a `contenteditable` region.

And apparently, [it's](https://web.archive.org/web/20160402053734/http://www.tutorialspoint.com/html/html_attributes_reference.htm) [been](https://stackoverflow.com/questions/8775782/setting-false-value-vs-removing-an-attribute) [tripping](https://stackoverflow.com/questions/9201471/how-to-add-boolean-attribute-using-javascript) [up](https://stackoverflow.com/questions/27662410/html-5-toggling-the-contenteditable-attribute-with-javascript) [many](https://stackoverflow.com/questions/33356151/javascript-boolean-true-turns-false-false-does-not-turn-true) [people](https://github.com/kangax/html-minifier/issues/63#issuecomment-18634984), since it's a ternary where one of the three is exceptionally rare in practice.
Is there a particular reason why `contenteditable` shouldn't accept the shorthand?
issue
created
tabatkins
username_1
I suspect this is the mistaken assumption that boolean attributes expand to have their name as their value?  @username_0, this doesn't happen; `<div foo>` "expands" to `<div foo="">`.

(This misapprehension derives from the *original* explanation for boolean attributes, which is that SGML allowed you to omit the attribute **name** if the value was enumerated and unique among all enumerated attributes allowed on the element, and a number of attributes had a value with the same name as the attribute to help support that.)
comment
closed
isiahmeadows
username_0
issue
created
isiahmeadows
username_0
@domenic I was referring to `foo` in `<div foo>`.

@username_1 Never mind then...that also explains why I had that misconception.
comment