HTML5 data-attributes need to handle booleans differently from regular attributes

[Alex Kahn]

Hi,

I'm using the new HTML5 data-attributes feature in Haml 3. I'm using
it with a method that returns true or false and I'm experiencing some
unexpected results. When the data-attribute is true, the attribute
appears in my markup but has no value. When the method returns false,
the attribute doesn't appear in the markup at all. (Same for nil,
actually.)

This makes sense for cases like %input{:selected => true} resulting in
<input selected>, but in my data-attributes I need an actual true and
an actual false. I'm not sure how nil should be handled.

Do folks agree? Should true and false be expressed explicitly as
values for HTML5 data-attributes? Patch with failing tests:
http://github.com/akahn/haml/commit/f8fae6569a75b9782decee53511f7fa335dab69f

Cheers,
Alex

[Alex Kahn]

And here's a fix. Thoughts?

http://github.com/akahn/haml/commit/1aa67b14cc80b6748c99ed1f8c6c02d25fe15440

Alex

> values for HTML5 data-attributes? Patch with failing tests:http://github.com/akahn/haml/commit/f8fae6569a75b9782decee53511f7fa33...
>
> Cheers,
> Alex

[gf3]

Looks handy to me, I like!

On Aug 11, 11:26 am, Alex Kahn <alexanderk...@gmail.com> wrote:
> And here's a fix. Thoughts?
>

> http://github.com/akahn/haml/commit/1aa67b14cc80b6748c99ed1f8c6c02d25...

[Mislav Marohnić]

On Wed, Aug 11, 2010 at 17:26, Alex Kahn <alexan...@gmail.com> wrote:

> Do folks agree? Should true and false be expressed explicitly as

> values for HTML5 data-attributes?

Well, I don't see why an element couldn't just be written like <img src="..." data-foo>.

The presence of "data-foo" attribute means true, its absence means false. It's all about how you use these attributes—you define their semantics themselves depending on your needs.

You don't gain much by forcing yourself to use "true" vs. "false" as values. This is how you would check for truth in both cases with JavaScript:

    element.getAttribute('data-foo') != null

    // with values:

    element.getAttribute('data-foo') == "true"

And in CSS:

    img[data-foo]

    /* with values: */

    img[data-foo="true"]

The only use-case for having attribute values is when you need to differentiate between 3 states: true, false, or nil (absence of the attribute). This is rare, and you can achieve it without the patch by casting boolean to string:

    %img{ :data => { :foo => obj.predicate?.to_s } }

So you see, we already have the ability to have "true" and "false" as values—your patch is only removing the ability to have attributes without values.

[Nathan Weizenbaum]

I'm inclined to agree with Mislav here. If data-* attributes are valid without values, I see no reason to have different behavior for them.

--
You received this message because you are subscribed to the Google Groups "Haml" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to haml+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml?hl=en.

[Alex Kahn]

Thanks for the feedback, Mislav and Nathan. Now that I see how easy it
is to check for a value to be not null, I agree, these attributes
shouldn't have special handling. Maybe my brain is a bit too wired for
how jQuery.fn.attr behaves. ;)

Cheers,
Alex


On Aug 12, 6:34 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote: