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ć <[email protected]> wrote: > On Wed, Aug 11, 2010 at 17:26, Alex Kahn <[email protected]> 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. -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
