AM – Attribute Modules for CSS • Hacker News Board

Re: AM – Attribute Modules for CSS

#21

Post by geelen » Fri, Sep 05, 2014, 4:04 PM UTC

shadowmint wrote: post #20

Looks like tal:attributes to me. That was a terrible idea before, and its a terrible idea now. Honestly, what problem is this actually solving ? You have .foo, .foo--bar, .foo--extra, and you're concerned the style tags are what... not pretty enough? Too hard to visually parse? Too complex when you're building a large css framework? I really don't understand the problem. ...but having worked with tal, I can hands dow…

Well, the problem with having foo and foo--bar but not both is that contextual overrides become a problem. Having both of them solves that but clutters things up.

This is a technique to better express your styling intent through markup. Instead of you have - two namespaces instead of one.

Re: AM – Attribute Modules for CSS

#22

Post by shadowmint » Fri, Sep 05, 2014, 4:10 PM UTC

geelen wrote: post #21

shadowmint wrote: post #20

Looks like tal:attributes to me. That was a terrible idea before, and its a terrible idea now. Honestly, what problem is this actually solving ? You have .foo, .foo--bar, .foo--extra, and you're concerned the style tags are what... not pretty enough? Too hard to visually parse? Too complex when you're building a large css framework? I really don't understand the problem. ...but having worked with tal, I can hands dow…

Well, the problem with having foo and foo--bar but not both is that contextual overrides become a problem. Having both of them solves that but clutters things up. This is a technique to better express your styling intent through markup. Instead of you have - two namespaces instead of one.

So its to avoid human readable visual clutter?

...by having obscure custom attributes?

That seems extremely close to having size="big" and color="red" from html4.

How is this not just going back to a known bad design pattern?

Re: AM – Attribute Modules for CSS

#23

Post by u124556 » Fri, Sep 05, 2014, 4:22 PM UTC

What's the problem with `class="btn large rounded"` and then in css:

    .btn {}
    .btn.large {}
    .btn.rounded {}
    .btn.large.rounded {}

Re: AM – Attribute Modules for CSS

#24

Post by hliyan » Fri, Sep 05, 2014, 4:32 PM UTC

u124556 wrote: post #23

What's the problem with `class="btn large rounded"` and then in css: .btn {} .btn.large {} .btn.rounded {} .btn.large.rounded {}

Or rely on semantic classes?

Re: AM – Attribute Modules for CSS

#25

Post by morley » Fri, Sep 05, 2014, 4:36 PM UTC

u124556 wrote: post #23

What's the problem with `class="btn large rounded"` and then in css: .btn {} .btn.large {} .btn.rounded {} .btn.large.rounded {}

I think they're trying to telegraph that "large" is describing a state specific to buttons.

Re: AM – Attribute Modules for CSS

#26

Post by kbenson » Fri, Sep 05, 2014, 4:38 PM UTC

masklinn wrote: post #9

huskyr wrote: post #2

This looks a promising approach to the chaos that is writing reusable and maintainable CSS. I wonder about performance though, especially on mobile. Will this perform as good as regular class-written CSS, even if you have >2000 loc CSS files?

Not a chance, browsers can optimise lookup for ids and classes (or even elements by name) because they have spec-defined semantics, and they can be preprocessed based on those semantics (e.g. used to key maps). Custom attributes have arbitrary semantics, so they can't be fit into such a static structure. Technically nothing prevents browsers from inferring specific behaviors from the way a custom attribute is used, a…

I imagine if it is optimized, using data attributes will be the most likely route. There's probably already benefits (and thus it may already be done) to cache which elements have specific data attributes set. Combining that with a lazy indexing of values of matching attribute selector rules on elements with matching data elements on first match may yield non-horrible performance.

Re: AM – Attribute Modules for CSS

#27

Post by bsimpson » Fri, Sep 05, 2014, 4:55 PM UTC

u124556 wrote: post #23

What's the problem with `class="btn large rounded"` and then in css: .btn {} .btn.large {} .btn.rounded {} .btn.large.rounded {}

I've heard people complain about this approach because if you tried to refactor, someone could have written class = "large rounded btn" in one place and "btn rounded large" in another, making finding all the variations more cumbersome.

That doesn't mean it's a bad approach, but that is one concern I've heard about it.

Re: AM – Attribute Modules for CSS

#28

Post by masklinn » Fri, Sep 05, 2014, 5:00 PM UTC

shadowmint wrote: post #22

geelen wrote: post #21

Earlier quoted context omitted.

Well, the problem with having foo and foo--bar but not both is that contextual overrides become a problem. Having both of them solves that but clutters things up. This is a technique to better express your styling intent through markup. Instead of you have - two namespaces instead of one.

So its to avoid human readable visual clutter? ...by having obscure custom attributes? That seems extremely close to having size="big" and color="red" from html4. How is this not just going back to a known bad design pattern?

Not to be insulting but… are you unable to read text? Because the problem (which has nothing to do with visual clutter and has to do with modularity and contextual overrides) is explained from the third section "Contextual overrides".

Re: AM – Attribute Modules for CSS

#29

Post by masklinn » Fri, Sep 05, 2014, 5:02 PM UTC

kbenson wrote: post #26

masklinn wrote: post #9

Earlier quoted context omitted.

Not a chance, browsers can optimise lookup for ids and classes (or even elements by name) because they have spec-defined semantics, and they can be preprocessed based on those semantics (e.g. used to key maps). Custom attributes have arbitrary semantics, so they can't be fit into such a static structure. Technically nothing prevents browsers from inferring specific behaviors from the way a custom attribute is used, a…

I imagine if it is optimized, using data attributes will be the most likely route. There's probably already benefits (and thus it may already be done) to cache which elements have specific data attributes set. Combining that with a lazy indexing of values of matching attribute selector rules on elements with matching data elements on first match may yield non-horrible performance.

Using data attributes is even less likely to ever be optimised as data attributes exist specifically to store browser-opaque programmatic content.

Re: AM – Attribute Modules for CSS

#30

Post by kbenson » Fri, Sep 05, 2014, 5:22 PM UTC

masklinn wrote: post #29

kbenson wrote: post #26

Earlier quoted context omitted.

I imagine if it is optimized, using data attributes will be the most likely route. There's probably already benefits (and thus it may already be done) to cache which elements have specific data attributes set. Combining that with a lazy indexing of values of matching attribute selector rules on elements with matching data elements on first match may yield non-horrible performance.

Using data attributes is even less likely to ever be optimised as data attributes exist specifically to store browser-opaque programmatic content.

I imagine data attributes are already optimized in some respects (probably not as selectors though), since their intended usage is slightly different than other attributes. I only contend that if any type of attributes are likely to receive special treatment in the future (besides those already designated as so, such as id and class), data attributes may be a likely candidate. Then again, due to the lack of constraint on the value of the data tags, that would make future optimizations much harder (which may have been your point).

Maybe just using class-* as a namespace would be best, both from a point of clearly identifying intent and not conflicting with any current valid html attributes (AFAIK).