Git Product home page Git Product logo

Comments (14)

snyamathi avatar snyamathi commented on July 17, 2024 1

I don't remember the issue with descendent selectors and namespaces. What was the problem?

<html id="atomic" class="foo">
  <body class="bar">
    <div class="foo_M(0) bar_P(0)">Hello World</div>
  </body>
</html>

We don't know where the namespace is relative to the parent in a descendent selector. It may be on the same element as the namespace - or not.

from atomizer.

src-code avatar src-code commented on July 17, 2024 1

@thierryk What if instead of doing a double-class on the selector, we just add an attribute selector that'll always match like [class]? (Doesn't address your concern about increasing specificity though, but would be shorter and might gzip better too?)

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

To be honest, the best would be to split the rules in 2 different files (one including MQ rules only) and find a way to stitch/group/combine those files based on that grouping (making sure the insertions of these files are done so the stylesheets that include the MQ come last).

I'm sure this would be too complicated to implement but it'd be the only way to make sure nothing breaks and works as intended/expected (while not introducing a new specificity context).

Bumping the specificity of the MQ rules may create conflicts in some cases but devs could also "exploit" this as a mean to bump their styling without having to use !important.

In any case, I think we could go with a "cheaper" bump (in term of specificity and bytes) by simply relying on a type selector. For example:

/* specificity is 0,0,1,0 */
.C\(white\) {
  color: white;
}

@media(min-width:1px) {
  /* specificity is 0,0,1,1 */
  html .C\(red\)--sm {
    color: red;
  }
}

I believe that using html is pretty safe in that context.

This can cause issues when multiple Atomic CSS stylesheets need to be combined on the page dynamically where the whole of the CSS can not be known in advance, for example through lazy-loading of modules from multiple servers.

I think this specificity bump for the MQ should be an option in the config as I'm sure not too many people out there have that same need...

from atomizer.

src-code avatar src-code commented on July 17, 2024

@thierryk

Bumping the specificity of the MQ rules may create conflicts in some cases but devs could also "exploit" this as a mean to bump their styling without having to use !important.

Interesting thought!

In any case, I think we could go with a "cheaper" bump (in term of specificity and bytes) by simply relying on a type selector.

Only problem I see with using html is that it'll get complicated if a namespace is also being used (similar to the problem we had with descendent selectors and namespaces.)

I think this specificity bump for the MQ should be an option in the config as I'm sure not too many people out there have that same need...

Yeah, that's what I'm planning, definitely wouldn't do this by default.

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

@src-code

If a namespace is used on html (i.e. #atomic) then the selector in MQs would be something like html#atomic .C\(red\)--sm.

Only problem I see with using html is that it'll get complicated if a namespace is also being used (similar to the problem we had with descendent selectors and namespaces.)

I don't remember the issue with descendent selectors and namespaces. What was the problem?

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

Thanks! I remember now writing "Why are "descendant classes" not relying on the namespace?" in the FAQ. :)

In that case, I think !importantmay be the best option for this too, because:

  • it does not create a new "specificity context"
  • it should gzip better than doubling classes

As a side note, the main problem I see with this open issue is the fact that we are shipping stylesheets with redundant rules (i.e. .C\(white\) {color:white;}). Even though we came up with "Atomic CSS" to remove redundancy/bloat from our stylesheets and "may be" offer better caching in the process...

@src-code

Yeah, that's what I'm planning, definitely wouldn't do this by default.

Sorry, I'd missed this:

atomizer -c config.json index.html -n  \#atomic --bump-mq

from atomizer.

src-code avatar src-code commented on July 17, 2024

@thierryk

As a side note, the main problem I see with this open issue is the fact that we are shipping stylesheets with redundant rules (i.e. .C(white) {color:white;}). Even though we came up with "Atomic CSS" to remove redundancy/bloat from our stylesheets and "may be" offer better caching in the process...

Generally speaking, in my particular use cases we are not shipping redundant rules in Atomic stylesheets - the problem is when you are shipping multiple stylesheets, which may not come from the same source. There's nothing we can do to remove redundancy in that case.

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

There's nothing we can do to remove redundancy in that case.

Did anybody try to tackle the problem? Do we know about the frequency of redundant rules? Is it significant enough so it is worth investigating? If we were talking about a file made of multiple stylesheet I'd say gzip would minimize the issue but here all files are gzipped on their own so I'd think it's not as much "optimized".

Thinking out loud here:

What about creating an ACSS stylesheet that would group the most common used classes found across the board? Then Atomizer could ignore classes in components from here and there that are already part of that master stylesheet. And that master stylesheet would be cached (across properties too) as the rules it includes would not change. Does that make sense?

from atomizer.

src-code avatar src-code commented on July 17, 2024

Did anybody try to tackle the problem? Do we know about the frequency of redundant rules? Is it significant enough so it is worth investigating?

Yes, it's been investigated and quantified on our end, and we've found it's worth pursuing. Can't go into details about the use cases, but it's definitely sufficient to rely on gzip, or maintaining a master stylesheet I'm afraid.

from atomizer.

src-code avatar src-code commented on July 17, 2024

I've opened a PR with the [class] approach, and will let developers decide if they want a spec bump or a !important (or both!) for their use cases. Let me know if you have concerns about this!

#385

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

@src-code

Very nice!
[class] increases the weight of the rule without creating a new "specificity context" and without the need for !important either.

But I'd argue that there is no need to offer bumping the MQs via !important.
After all, this issue is about addressing a problem related to the cascade (rules of same specificity coming in the "wrong" order) and the added specificity (0,0,2,0 versus 0,0,1,0) takes care of this issue.

from atomizer.

src-code avatar src-code commented on July 17, 2024

@thierryk My original thinking too was that !important might not be necessary, but thought it might be worth giving developers options in case there was a valid reason you'd want to override specificity like that in some scenario. I don't believe there is a valid reason for it if you're only trying to override another Atomic style, unless maybe you were trying to match/override a descendent selector (0,2,0) with a non-descendent MQ and weren't using a namespace (which would eliminate the !important from the descendent thus making the two styles equal in weight.) But not sure why you'd want to override a descendent with a non-descendent MQ in normal practice.

I suppose then the main reason you might rely on !important in an MQ would be to override non-Atomic styles, but in that case you've got other problems that probably shouldn't be solved by Atomic...

from atomizer.

src-code avatar src-code commented on July 17, 2024

Closing this in favor of the PR. Thanks all!

from atomizer.

thierryk avatar thierryk commented on July 17, 2024

@src-code I agree with everything you said here. But let's also remember that authors can also use ! (i.e. C(teal)!) in the rare case they would need to overwrite some rules.

from atomizer.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.