Re: Proposal for "Cascading Attribute Sheets" - like CSS, but for attributes!

On Wed, Aug 22, 2012 at 9:20 AM, Bronislav Klučka
<Bronislav.Klucka@bauglir.com> wrote:
> On 22.8.2012 1:13, Tab Atkins Jr. wrote:
>> Actually, the two should be identical, because CAS is applied as a
>> mutation observer, rather than synchronously.  As long as those
>> statements appear in the same microtask, they'll have the same
>> behavior regardless of order (CAS will always get to override them).
>
> Which does not correspond to CSS behavior and may be cofusing, any changes
> would require something like
>
> var div = createMyDiv();
> parentNode.appendChild(div);
> setTimeout(function(div) {div.className = 'foo';}, 0, div);
>
> that's weird.

Why do you think that's required?  All it would do is clobber the
class attribute in case CAS had set it to something else.  Setting a
class via CAS doesn't seem like a great idea in the first place.  If
you really do want to, you can just get CAS to either not clobber the
attribute (if I address the "add to the existing value" use-case that
I've outlined on my blog <http://www.xanthir.com/blog/b4K_0>) or else
just exclude .foo elements from getting their class clobbered with a
":not(.foo)" in the selector.


> How about this: element is created with all attributes marked as clean, any
> settings (input.value = 5; input.setAttribute('value', 5); delete
> input.value; input.removeAttribute('value')) would mark such property as
> dirty, and inserting new element into DOM would trigger task, that would set
> up all properties based on DOM document's CAS except dirty ones. In such
> case, no ambiguity would occure.
>
> Browsers are able to do it for CSS, should be able to do it for CAS

Browsers are able to do it for CSS with a lot of complexity.
Complexity sometimes translates to "powerful and awesome", but always
translates to "slower".  In this case, I don't think the large helping
of additional complexity is worth the minor benefit.

~TJ

Received on Wednesday, 22 August 2012 16:29:35 UTC