Can I use HTML5 data-* attributes as boolean attributes? [duplicate]

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>

Turkestan

Answer 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");

Hammered

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? – Turkestan

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. – Hammered

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

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

Yeah hasAttribute is the way. Thanks a ton. – Turkestan

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. – Commorancy

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

Answer 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.

Commorancy

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. – Hyrup

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). – Turkestan

@Hyrup 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. – Commorancy

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

@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 – Waxy