jareware / css-architecture Goto Github PK

I have a page, it can go to view mode or edit mode. Each components inside the page may look a little bit different in two modes.

What is the best practices to pass in the view/edit mode information to each components? Global is easy but it is leaking the information.

Much of your approach is the same as my own, documented at http://ecss.io and in book form 'Enduring CSS'.

Might be good to have a 'Further reading' section to reference other works talking about the same problems and similar solutions? E.g. links to SMACSS, BEM and any other methodologies you have been influenced by. Just a thought. :)

First of all, nice article! I agree with most of it, only that "Always prefer classes" is not obviously always a good practice. This is mostly due to the bad performance of class based selectors.

Regarding CSS, the rendering time of ID-based selectors compared to class-based selectors is < -5% in modern browsers, so quite insignificant. However, in JavaScript (especially using selector engines of libraries like jQuery), the performance difference of using $('#my-element') vs. $('.my-element') is massive. And since this article mostly affects large-scale applications, the browser rendering time should not be neglected.

Additionally to that, there are other things to consider, for example, IDs have a higher priority over classes. So if your element has an ID and a class, the styles of the ID will override the styles of the class. If you'd use two classes instead, it would depend on the specified order of the classes which is pretty bad. Finally, it is easier to understand a layout that uses classes and IDs, simply because you don't have to check if an element may be used multiple times or not.

The major downside of using IDs is of course, like already correctly mentioned in the article, that one must not use IDs like id="box", all IDs must be namespaced like id="myapp-mymodule-box".

Howdy!

Great post! Really thoughtful, lots of nice ideas.

I'm wondering how you handle global styles? Normalize as one example, or other truly global styles that you might want all over the place.

Thanks!

Thanks for this article in a time when I'm dusting off my CSS again. As I'm reading I can see that Vue (my recent framework choice) solves much of the points you raise. For instance, the Vue single file components work like the shadow DOM out of the box. Here are some relevant Vue links, I'd be interested in your take on Vue's approach.

http://rc.vuejs.org/guide/single-file-components.html
http://rc.vuejs.org/guide/class-and-style.html

Hey Jarno, great docs and tips!
You're one of the few guys who mention inheritance, kudos to you :)

fwiw we implemented a styles encapsulation feature in suitcss preprocessor that tries to solve this issue by making inheritance opt-in and predictable i.e. you have to specifically set inherited properties to inhert like font-size: inherit.

The idea doesn't require a preprocessor but obviously with one you can automate the process.

I just wanted to mention it, up to you if you want to include a paragraph about this.

Hey,

Thank you for this great article, I've translated it into Chinese, here is the link: http://www.jianshu.com/p/acb4b9d8ff4f

Some people (like myself) may find it incredibly difficult to search for styles when concatenation is done like this:

.myapp-Header {
  background: black;
  color: white;

  &-link {
    color: blue;
  }

  &-signup {
    border: 1px solid gray;
  }
}

Isn't it better to be able to just grab a style from the dev tools and search for it directly?

Notice you had for each component a MD file to doc how to use the CSS. Can you give an example of what you put in there?

• https://css-tricks.com/8-simple-rules-robust-scalable-css-architecture/
• https://www.reddit.com/r/web_design/comments/5a0flr/8_simple_rules_for_a_robust_scalable_css/
• https://www.reddit.com/r/css/comments/5a0fjt/8_simple_rules_for_a_robust_scalable_css/

One of the guidelines, regarding which properties a parent component can alter and which it cannot, implicitly assumes box-sizing: border-box:

properties related to positioning and dimensions (e.g. position, margin, display, width, float, z-index etc) are OK

In particular, width and margin may be unsafe to alter (or at least have unexpected effects) unless the element has box-sizing: border-box.

I wouldn't recommend anything other than box-sizing: border-box these days, but it's still something that can trip people up, especially if they're not using a global reset/normalize.

hi,
mentioning your post:

If you're familiar with the Web Components spec, think of this as getting the style isolation benefits of the Shadow DOM without having to care about browser support (or whether or not the spec ever gets serious traction).

the support/traction of Shadow DOM (especially V1) you are reffering to it's very much an opinion rather than a fact :)

http://caniuse.com/#feat=shadowdomv1
https://blogs.windows.com/msedgedev/2016/02/03/2016-platform-priorities/#pjjDg6AZfqjC9Zc0.97

Chrome supports it (mobile too), latest Safari supports it (mobile too), Firefox and Edge are developing this feature... so it doesn't seem so out of sight.

It would be fair enough if you add this links to give correct informations to readers or specify that is just your personal opinion.

thanks for the great article!

Thanks for the article, we will definitely discuss it with my colleagues!

As an enhancement I would add bits about working with layout. Sizes, positioning, modern approaches (flex, for example). Often times I see people defining absolute heights and widths:

.my-div {
  width: 145px;
  height: 120px;
}

But from where do this magical numbers coming from? Would they hold up on a 4K display? What happens if an other <div>'s size is changed? You end up fixing one and seeing two others break.

(I would really appreciate if anyone has a link to how you should approach and architect placement, sizes, proportions in a large UI).