4 ms·

Doing separated CSS/JS does not imply in automatic breaking of LoB. You just need to come up with CSS and JS that are not _specific_, but _layered_ instead, wh

Doing separated CSS/JS does not imply in automatic breaking of LoB. You just need to come up with CSS and JS that are not _specific_, but _layered_ instead, which is hard. Bad: .one-specific-button-from-the-nav-bar { color: blue; } <input class="one-specific-button-from-the-nav-bar"/> Good (only this button): <input style="color: blue"/> Better (all buttons on nav are the same): nav form button { color: blue; } What if I want two kinds of buttons on the navigation bar? Then you have two options: - Abandon the idea. Do something simpler. - Come up with a generic CSS rule for it. For this idea to work, _you have to accept limitations_, which means you cannot design whatever looks you want, or make pixel-perfect layouts, etc. You have to work within some constraints.

recursivedoubts 1y ago
yeah, this is a tricky area for us LoB enthusiasts: tailwinds is an example of LoB, but also I think sometimes it devolves into inlining implementation[1]. My gut reaction is to want a well named CSS class on the element instead, which feels like the equivalend of defining a function elswhere, but calling it on the element in question, thereby preserving LoB (to an extent) On the other hand, I know a lot of very smart folks who like the tailwinds approach, and I do acknowledge the difficultly of naming CSS classes, that the function metaphor breaks down due to the fact that CSS classes have non-encapsulated effects on child elements, etc. Interesting case to think about. [1] - https://htmx.org/essays/locality-of-behaviour/#surfacing-behaviour-vs-inlining-implementation https://htmx.org/essays/locality-of-behaviour/#surfacing-beh...
- alganet 1y ago
  tailwind bad
pphysch 1y ago
There's a middle ground which is having an optional <style> block in the page template, this allows you to express local style differences without going crazy with style attributes. And they are easy to refactor into a global style sheet if needed.
- alganet 1y ago
  I think the web platform is really simple, easy to understand and great. A. Your content is a document. A semantic HTML document, boring, mostly made of text. B. You can make the document alter parts of itself with JS. You don't mess with appearance here, just change the boring document content. C. You can make the document look good by applying some styles to semantic HTML tags. If you respect them, you get both LoB and SoC neatly arranged into meaningful layers. -- Tailwind-like stuff breaks semantic HTML. Classes like ".flex-7" are about style, not the text. CSS classes should be stuff like ".introduction" or ".cooking-ingredients". It makes documents otherwise simple to read into a mess. Now there's appearance concerns hidden in between the content. It's bad. -- All good rules come with great exceptions. In this case, stuff like Google Maps. You can't really represent it as a document. But that's rare on the web. Somehow, people were convinced to use those "frameworks for rare use cases" to make simple documents, forms, etc. -- Local <style> tags fall into this category of exceptions. Sometimes you need some extra style for a content that is unusual, but that's the exception. Most websites want to look consistent across all their published content.

recursivedoubts 1y ago

yeah, this is a tricky area for us LoB enthusiasts: tailwinds is an example of LoB, but also I think sometimes it devolves into inlining implementation[1]. My gut reaction is to want a well named CSS class on the element instead, which feels like the equivalend of defining a function elswhere, but calling it on the element in question, thereby preserving LoB (to an extent) On the other hand, I know a lot of very smart folks who like the tailwinds approach, and I do acknowledge the difficultly of naming CSS classes, that the function metaphor breaks down due to the fact that CSS classes have non-encapsulated effects on child elements, etc. Interesting case to think about. [1] - https://htmx.org/essays/locality-of-behaviour/#surfacing-behaviour-vs-inlining-implementation https://htmx.org/essays/locality-of-behaviour/#surfacing-beh...

alganet 1y ago
tailwind bad

pphysch 1y ago

There's a middle ground which is having an optional <style> block in the page template, this allows you to express local style differences without going crazy with style attributes. And they are easy to refactor into a global style sheet if needed.

alganet 1y ago
I think the web platform is really simple, easy to understand and great. A. Your content is a document. A semantic HTML document, boring, mostly made of text. B. You can make the document alter parts of itself with JS. You don't mess with appearance here, just change the boring document content. C. You can make the document look good by applying some styles to semantic HTML tags. If you respect them, you get both LoB and SoC neatly arranged into meaningful layers. -- Tailwind-like stuff breaks semantic HTML. Classes like ".flex-7" are about style, not the text. CSS classes should be stuff like ".introduction" or ".cooking-ingredients". It makes documents otherwise simple to read into a mess. Now there's appearance concerns hidden in between the content. It's bad. -- All good rules come with great exceptions. In this case, stuff like Google Maps. You can't really represent it as a document. But that's rare on the web. Somehow, people were convinced to use those "frameworks for rare use cases" to make simple documents, forms, etc. -- Local <style> tags fall into this category of exceptions. Sometimes you need some extra style for a content that is unusual, but that's the exception. Most websites want to look consistent across all their published content.