Feedback

[geelen]

Reproducing an email exchange with @necolas, after sending him http://glenmaddern.com/articles/introducing-am-css, because I think this is a nice use of attribute selectors with class-based components

Looks cool. I've played around with something similar:

<tag class="Component is-state" ui-prop="value">
  <tag class="Component-private">

For example:

<tag class="Nav is-open" ui-size="large" ui-color="blue">
  <tag class="Nav-item is-selected" ui-name="Home">

Because it works with a component API quite easily. Also have it working with classes (just needs a helper to act as a class map, like in React), so not yet decided on which one we'll use.

Good luck

Interested why you didn't go with something like ui-state="selected" instead of class="is-selected" though?

Because ui-* was reserved for the component API, and state isn't a direct configuration option. The "private" sub tree of the component probably shouldn't have any ui-* attributes within it.

Here's a demo of the context for that (I was trying to hack flightjs to work as a ui component framework, but gave up on it): http://codepen.io/necolas/pen/Djbpr

[maxw3st]

It may be easier to read the code if the background for the red code is a light ivory, instead of pink.

[maxw3st]

The concept seems familiar to me because it resembles a class and its attributes in Java. And you are overriding &/or adding to the styling of a base element. The syntax seems a good way to keep it concise and allow for the little hierarchy being built. Anything that lets you define a class that can have child (or sibling) classes, with properties which in turn can have values, is a good thing for CSS.

[giuseppeg]

He is experimenting with a way to have component props in the markup to be consumed by Flight components (JavaScript). I don't see how this relates to CSS.

[necolas]

I don't see how this relates to CSS.

.Component[ui-prop="value"] { /* css */ }

[giuseppeg]

@necolas uhm I thought you meant to use those props in replacement of data-* attributes to hold ui-components specific data (see ui-usedId). Also you mention the "private" ui-* attrs free sub tree thing. I might have misunderstood that though.

[rakeshrach]

The benefit of @necolas' proposal is the clear differentiation between class and other attributes, whereas it's unclear what the role of class would be in the AM approach (which I still admire as whole). A few guidelines on this would help.

[krzksz]

Hey! I've been looking for some BEM alternatives and found amCSS an awesome idea but I have one concern: performance.

Background Me and my team work on big e-commerce websites that usually contain 3k-5k HTML elements and similar number of CSS selectors, but those numbers can and up being 10k high. Working in e-commerce market already means that we have to support mobile as best as we can, as well as some older browsers like IE8. Those user agents can have slower selector parsing and we can't afford to make user waiting for too long.

Research I've found some tests of various CSS selectors and attributes seem to be one of the slowest attributes in opposition to classes which are amongst fastest. he only problem is that I am unable to find any up to date researches and articles of how big is the actual impact on the entire page loading time.

Using CSS Test Creator I made class test and attribute test, although after couple of runs their times are similar, the attribute one hangs my browser for a while when refreshing. There is also another test which shows 3x worse performance for 1000 elements and 1000 selectors.

Question Since you may have already done some projects using amCSS, do you have any experiences regarding performance regression in opposite to BEM and if so, is it really noticeable?

[krzksz]

Ok, so I came up with a possible solution for a bigger websites where attribute selector could be a problem. The idea is to use classes as something that could be described as namespace. Namespaces would be optional, just like in programming languages, and serve a purpose of rapidly finding desired elements so the name should be appropriate.

The idea is to add module name as a class to every element which(from what I have tested) allows browsers to match those mixed selectors as fast as sole classes. E.g.:

<div class="Grid" am-Grid>
    <div class="Grid" am-Grid-Row></div>
</div>

.Grid[am-Grid] {
    display: flex;
}
.Grid[am-Grid-Row] {
    ...
}

Classes stay semantic and optional, performance gets better: win-win. I wrote some SASS mixins which also use is-* convention similar to Polymer's to help authoring amCSS code.

[viT-1]

@krzksz How about performance in modern browsers today?