Can I use HTML5 data-* attributes as boolean attributes?

Question

I want to use a custom boolean attribute to mark an element's contents as editable. I'm aware of the data-* attributes, but wasn't sure if they require a value. I don't need data-is_editable="false", as the lack of the attribute would be equivalent. I only care if it's "true" (if the attribute exists). I know I can use other attributes like class but I don't want to as it seems slightly inappropriate (correct me if I'm wrong about that).

Here's the resource I'm reading, maybe it's the wrong document or I've overlooked the information I'm looking for: http://www.w3.org/html/wg/drafts/html/master/dom.html#custom-data-attribute

So for example, is this legal and valid?

<div data-editable data-draggable> My content </div>

Solution 1

The example you show is valid. (Just like using disabled or checked in a form. Only xHTML force the presence of a value)

Although, the value returned is not a boolean. When you query this resource, you'll get an empty string for any empty data-* attributes.

Like so:

 domNode.dataset.draggable; // log ""
 domNode.dataset.notAdded; // log null

So, you just have to check it:

var isDraggable = (domNode.dataset.draggable != null)

Edit

Stupid to haven't tell it before. But, you can just check if the attribute exist if you want a boolean:

domNode.hasAttribute("data-draggable");

Solution 2

It passes the W3.org validator, which is a good sign.

Javascript's dataset and jQuery's data functions seem to know the difference between the attribute there or missing - but the value is an empty string when it's there, and either undefined or null when it's not. To avoid confusion, I don't think I'd use that personally - I'd probably instead opt for <div data-editable="1"></div> instead.

Comments

[Wesley Murch]

Thanks for the insight. Only thing is, domNode.dataset.draggable != null returns true when the attribute doesn't exist. Seems better (although awkward) to check if it equals an empty string. Right?

[Katana314]

The problem with that is the same as the problem with <input disabled="true"/> - it's a misnomer that implies you could do 'disabled="false"'. I'd say as long as an empty string evaluates to true in Javascript, it's fine to use.

[Wesley Murch]

Wow I didn't even realize there was W3C HTML5 validation... Seems legit then, but it doesn't treat the attributes as boolean (which is fine, and makes sense).

[Simon Boudrias]

Which browser are you checking? If the attribute don't exist on the lement, the code higher will return false. I putted type cohersion check == because this will match both null and undefined. It should return null, but I preferred to check for both just in case.

[Wesley Murch]

Oh now wait, dude you're right. Sometimes my mind is easily flustered by boolean logic like isTrue = isFalse !== true.

[Simon Boudrias]

Hey, just edited with hasAttribute which is the logical method to use if you want to get a boolean.

[Wesley Murch]

Yeah hasAttribute is the way. Thanks a ton.

[Joe Enos]

@Katana314 Agreed specifically on "disabled" - that's a weird one. However, javascript treats the empty string as a "falsy" value, so I'd be careful with that one. Simon's answer of hasAttribute seems to be the better way though, and eliminates this confusion.

[Wesley Murch]

Funny thing is, I ended up realizing a potential use for the value: <div data-editable="/admin/edit/node/35">

[Joe Enos]

Is this future-proof? I know that attributes and properties are kind of interchangeable most of the time, and browsers and libraries seem pretty forgiving, but they are different things (jQuery made a big deal out of this awhile back). Is it safe to assume that applying a data value will always add the appropriate attribute? I would think so, but it might be worth looking into to make sure this doesn't bite back in a few years.

[user]

Actually it is undefined, not null, so it's better to make check as domNode.dataset.draggable !== undefined

[nicodemus13]

@Katana314: data-* attributes are custom values, not part of HTML tags (such as input), so, personally, I don't see they should have to follow the same semantics. I'd argue the opposite, explicitly setting true and false and handling them explicitly (in data-*) attributes is much clearer than having to remember that the presence of a negative-concept attribute indicates that something isn't the case