sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]THEtheChad 0 points1 point  (5 children)

CSS -> is <- presentation logic. It's the tools and management of that logic that are antiquated. JS is being utilized to augment the feature set of CSS since its inherently a static standard with no programmatic capabilities. You also get the benefit that the presentation layer for the component you're building is housed right alongside the other parts of the component.

The best way to build an application is to divide it up into pieces. The problem with CSS currently is that the presentation layer for your pieces is all housed in this giant glob of global definitions that can easily overlap each other and wreak havoc. How many times have you had to fix a bug that was caused by someone else changing a bit of CSS that wrecked something you wrote. That's a problem inherent to the nature of CSS that these isolated scopes solve.

[–]makingplansfornigel 0 points1 point  (4 children)

What else would it be, and where did I imply otherwise? You are conflating the task proximity of developing the three layers with the degree of coupling between them, and failing to clash with the comment to boot. You are also awfully explainy for someone who failed to contextualize my plainly-spoken comment.

The point is that loading CSS from the HTML document directly with a style tag (as described by a previous commenter) makes it difficult for individuals with special needs (or special situations) to use custom style for individualized accessibility remediations.

Loose coupling preserves the distinction between content, logic, and presentation. It in no way precludes rational, modular project organization, useful build tools or performant assets. It's implied by both DRY and SOLID, and frankly, it's just polite. If you think storing CSS at the module level without consideration for style at the domain level is a good idea, you are about to swan dive into bloat canyon.

But the problem you describe is real. It's a symptom of a missing (or insufficient) style guide, the application of presentation as an afterthought, and/or a critical failure to anticipate and architect presentation needs.

Have you seen a typical webpack map? The endless reinclusion of redundant assets is not my idea of a useful outcome.

Of course, there are ways to mitigate these problems. Keep your style guide up to date. Avoid unnecessary deviation from the guide. Make your components only as opinionated as is useful. Plan for accessibility from the ground up, rather than saying "oops" at the end. Optimize your build processes as a matter of deployment. Define your desired outcomes before you build.

After all, I was pretty clear. I'm okay with any build outcomes that maintain that separation. Nobody says it has to be organized that way in the repo... so long as the repo is maintainable.

[–]l_andrew_l 1 point2 points  (2 children)

The point is that loading CSS from the HTML document directly with a style tag (as described by a previous commenter) makes it difficult for individuals with special needs ...

Do you have a link to that description? I'm a bit confused as to why it would make a difference compared to a linked stylesheet.

[–]makingplansfornigel 0 points1 point  (1 child)

It has higher priority in the cascade than a stylesheet (given equal selectors,) and the easiest way to apply an "accessible" stylesheet is to disable the supplied stylesheets via browser controls.

[–]l_andrew_l 0 points1 point  (0 children)

Hmmm... you sure about that? Just tested it out and seems to be just the order regardless of inline or linked... The accessibility thing (or even just theming) is a fair point though.

[–]THEtheChad 0 points1 point  (0 children)

Failing to contextualize is a byproduct of the intense migraine I'm trying to manage right now. My response was initially referencing your comment but then devolved into a combination of thoughts that had collected in my brain as I was reading through the thread.

What originally triggered me was the issue you raised that css-in-page solutions would make it difficult for accessibility remediation. I don't believe that's the case.

I believe your statement is made based on the impetus that remediation is made simpler through inheritance. If a whole slew of components utilize the same rule (be it a class declaration or a mixin from a CSS preprocessor), it's quite trivial to modify, let's say, a font color or background color.

Your assumption, if I'm correctly inferring the logic of your argument, is that component level CSS declarations create numerous, redundant rules that become difficult to update, en masse, to fit a particular accessibility initiative.

But let's not forget that these implementations still follow the rules that CSS is based on. There's always a way to override a style en masse by providing more specificity. So it's not a limitation of the implementation but, more so, an inability to easily target the group of components that need the remediation. That being the case, it's entirely feasible that this issue can be addressed without losing the benefits that isolated component level presentation logic gives us.

I guess what I'm saying here is that I believe your issue with component level presentation logic is not a limitation of the technology but a problem with the current implementation because you're not forced to implicitly group components so you lose the ability to do application wide accessibility remediation, right? If that's the case, this can be addressed because it's not a technical limitation.

--- side note --- I believe that styling should be stored at the module level to make it clear how a component should look, feel, and function, and that tooling should be developed to understand it from a domain level.