Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Modules

glenmaddern.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: CSS Modules

#51

Post by userbinator »

yari_ashi_zero wrote: post #42

HTML is for hypertext documents, and CSS an organ of the same organism called 'HTML/CSS'. It's made for text documents, and applying it to the implementation of GUI-centric applications has always been an ugly hack. For awhile (90s to 00s AJAX) it was necessary, and now the whole professional ecosystem has built up tremendous inertia over the millions of accumulated people/hours of perfecting this 'competency'/hack.…

There is already a very compact 2D vector-oriented format with its own scripting language: SWF. You don't even need to use Adobe's implementation - there are alternative Flash Players and authoring tools out there.

Re: CSS Modules

#52

Post by pearjuice »

Am I the only one who scrolled up and down a few times just to verify the background was changing its color and it wasn't a bug in f.lux which kicked in way too early for sunset?

Re: CSS Modules

#53

Post by sepokroce »

kaoD wrote: post #30
rdsubhas wrote: post #19

Earlier quoted context omitted.

Not sure why you're getting downvoted. Problems with CSS at Scale are very real (as mentioned in the slide). But this is a super complicated solution. Its like one of the head-over-heels approaches in JoelOnSoftware blogs. Surely there has to be a simpler way. Its good that the authors are trying. But just look at the picture on this article captioned "This is how intensely we’ve been thinking about CSS". That's wher…

> Not sure why you're getting downvoted. Because it doesn't contribute anything but nonconstructive criticism. > Good solutions present themselves and fit naturally. Complex problems require complex solutions. Also, what's so complex and non-fitting about this solution? Explaining that (and your alternative solution) would be much better than simply criticizing as you and GP did. > Surely there has to be a simpler wa…

> Because it doesn't contribute anything but nonconstructive criticism.

No, it's just an opinion and a comment on the sensationalistic article (sub)title.

Re: CSS Modules

#54

Post by prezjordan »

Kequc wrote: post #45

It feels to me that this conversation is quite old I'm finding myself not convinced by the examples put forward in the article. It looks like a lot of unnecessary complexity. You can have a lot of success by simply picking a common css convention. .mybutton /* all styles for Normal */ .mybutton.disabled /* overrides for Disabled */ .mybutton.error /* overrides for Error */ .mybutton.in-progress /* overrides for In Pr…

Now what if you wanted to bring in another button - a very similar one - with slightly different styles?

Re: CSS Modules

#55

Post by Kequc »

prezjordan wrote: post #54
Kequc wrote: post #45

It feels to me that this conversation is quite old I'm finding myself not convinced by the examples put forward in the article. It looks like a lot of unnecessary complexity. You can have a lot of success by simply picking a common css convention. .mybutton /* all styles for Normal */ .mybutton.disabled /* overrides for Disabled */ .mybutton.error /* overrides for Error */ .mybutton.in-progress /* overrides for In Pr…

Now what if you wanted to bring in another button - a very similar one - with slightly different styles?

You extend the styles now you perhaps have:

  .mybutton
    /* all styles for Normal */
  .mybutton.skewed
    /* overrides for Skewed */
  .mybutton.disabled
    /* overrides for Disabled */

  class="mybutton skewed disabled"
The suggestion in the OP would be that each one of those classes contain all of the styles for the button. That isn't necessary. Plus it requires, what I count, a minimum of two additional language abstractions in order to do it.

Re: CSS Modules

#56

Post by rimantas »

rdsubhas wrote: post #19
sepokroce wrote: post #4

Surely not the future.

Not sure why you're getting downvoted. Problems with CSS at Scale are very real (as mentioned in the slide). But this is a super complicated solution. Its like one of the head-over-heels approaches in JoelOnSoftware blogs. Surely there has to be a simpler way. Its good that the authors are trying. But just look at the picture on this article captioned "This is how intensely we’ve been thinking about CSS". That's wher…

There is a simpler way. Even for large projects there is no need for the amount of CSS they usually have. It just takes some discipline and planning, alas that's often replaced by abdominations like BEM.

Re: CSS Modules

#57

Post by arxpoetica »

egze wrote: post #26

The advantage of BEM naming is that it takes 0 effort to find your style definitions in code. .Button--disabled copied in the browser, will find exactly 1 definition in the project. .components_submit_button__normal__abc5436 will not find you anything.

THIS. Living in a world of abnormally gross class names like `components_submit_button__normal__abc5436` sounds downright painful, UGH.

Re: CSS Modules

#58

Post by lojack »

egze wrote: post #37
dantillberg wrote: post #34

Earlier quoted context omitted.

But on the flipside, in the latter case, you don't even need to grep for it -- "components_submit_button__normal__abc5436" reads as "components_{filename}_{classname}...", so you know right away to go look in "submit_button.(css|less|etc)" for ".normal {...".

This is certainly a less convenient approach. You always need to parse the class name in your head to open the correct file.

As a counter argument, when grepping files you still need to parse the output in order to open the correct file.

And, yes I understand that you can have grep output a path name and pass that directly in as an argument to your text editor. Similarly, it'd be relatively trivial to write a bash function that'd parse the class name and find the correct file to open.

Something like:

    function lookupcss() {
        find . | grep $(expr "$1" : '\(.*\)__.*' | sed 's/_/.*/g')".*\.css$";
    }

Re: CSS Modules

#59

Post by patrikh »

chinchang wrote: post #47

This seems like too much abstraction (magic) of things. Plus those auto generated classes really look odd and would make debugging difficult.

Webpack allows you to change the format through its loader configuration. Perhaps, this could get implemented to CSS Modules too, if it’s not already.

loaders: [

  ...
  {
    test: /\.css$/,
    loader: 'css?localIdentName=[name]__[local]___[hash:base64:5]'
  }
]

Re: CSS Modules

#60

Post by bobwaycott »

martin-adams wrote: post #48
lo_fye wrote: post #46

"The composes keyword says that .normal includes all the styles from .common" -- great, except you have the meaning of the word reversed. In the context above it actually means ".normal is part of .common", which is clearly not the intent. If you wanted it to mean that ".normal includes all the styles from .common" then .normal should be "composedOf: common"

Correct. Would the word 'comprises' be more appropriate?

I stumbled upon the Github issue and then found the HN reference. I commented with some additional thoughts and keyword options. I don't think 'comprises' would be the best choice here; it has quite a stricter meaning than 'includes' and its synonyms.
Post reply on HN