5 ms·

The problem is the modern webs hyper focus on appearance over content. Content first, style second. I still say that the answer is just semantic HTML/CSS. You'

by donatj 2y ago

The problem is the modern webs hyper focus on appearance over content. Content first, style second. I still say that the answer is just semantic HTML/CSS. You're coming at the problem from the wrong direction naming things for how you want them to appear. Name them for what they are. Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document. SCSS and extending placeholder[1] selectors makes this insanely easy and viable. You can write your "how things appear" classes as placeholder classes, and then simply extend those from your "what they are" classes. Super easy to keep organized. 1. https://naxoc.net/2014/01/28/placeholder-selectors-in-sass/ https://naxoc.net/2014/01/28/placeholder-selectors-in-sass/

have_faith 2y ago
Is `my-card` not a declaration of what something is (supposed to be)? The attributes are then encapsulating the state of the thing e.g. "is-loading", "size", etc. And the style then naturally follows, becoming a function of state e.g. "large loading indicator". The extend selector solves the problem of one style definition inheriting styles from another style definition, but the author is trying to solve the problem of how styles are mapped to stateful elements. It's the mapping process that introduces the combinatorial problems of class names.
- the_other 2y ago
  `.my-card` is semantic, but `.big` is presentational/visual. You could maintain the semantics with rules like: .my-card { width: normal; } .homepage .my-card { width: bigger; } .sidebar .my-card { width: smaller; } (where 'normal', 'bigger', and 'smaller" should be replaced with real values). BEM suggested state labels (e.g. `.my-card__loading`). I'm on the fence about those vs `.my-card.loading`. The class-based syntax seems shorter than either BEM-style or attribute selectors, and thus I prefer it. You might get a bit more rigour from the more longer-form methods, but I'm not convinced the energy isn't better spent training your team to be more careful. Shared code, CSS toolkits, shareable widgets present bigger challenges... the thing is that none of the tools suggested actually fix the problems. Your code can still break 3rd party code and vice-versa because of the global nature of CSS. Specificity needs management, but so do type systems and class hierarchies. Stop pretending the cascade and global namespace don't exist and just do the work.
  - wruza 2y ago
    .big is what it really is, big. Inventing a new name for it like emphasized, enlarged or attention-grabbing is just unnecessary pedantry. Naming things what they are and then styling with how they must look like creates an additional linguistic layer in an already csessed up system. “What things are” must become component names, not a part of markup. If there’s no reason to componentize a chunk, it doesn’t get a name (and vice versa).
    - the_other 2y ago
      It's only visually big. To a blind person, it doesn't matter what size it is. It's big to fulfil some layout concern, and the layout concern is there to fulfil some attention or intent concern. And also, I didn't say one should use `.emphasised`. I said to change the size based on the container: `.hero .card {}` would be big but `.articles .card {}` would be normal sized. `.card`s are always just cards; their context makes them different variations. "But `.hero` is just another way of saying big, or emphasised"... Not really. A `.hero` is "the focus of the page. EVERYTHING (`.card`, `button`, `.btn`, `q` etc) inside `.hero` might all be big, or bold, or a contrasting colour, or surrounded by extra negative space, or in italic, or a mixture of those. Back when there were going to be aural style sheets [0], you'd have a way to specify alternate modality presentations using the same class names. It doesn't always make sense that something is aurally louder when it's visually bigger. `.big` is not "what things are". `.big` is "how do we express what that thing is in this situation". [0]: https://www.w3.org/Style/CSS/Speech/speech.html https://www.w3.org/Style/CSS/Speech/speech.html
jcelerier 2y ago
> The problem is the modern webs hyper focus on appearance over content. Content first, style second. That's not "the web", that's "most humans"
danbruc 2y ago
The problem is that you are trying to use a document markup language to create an user interface including designing and styling the controls themselves. Also computers were not black and white in the 90s.
Kiro 2y ago
> Name them for what they are. I've kept hearing (and believing) this for 20 years but never seen a project where it's actually enforced. It seems like one of those things that doesn't work in practice and that come with very few benefits compared to the overhead it creates. Every time I redesign something I throw out both HTML and CSS anyway.
- isleyaardvark 2y ago
  Whenever I have seen code like that, it’s awful. “Name them what they are” becomes “name them after their content”, which is the opposite of separation of concerns.
noirscape 2y ago
SCSS in general is a very good preprocessor for writing any amount of CSS when you're designing more than a single webpage. It's a very nice wrapper around CSS that make CSS feel so much less archaic to use. Do use SCSS though, not the weird SASS syntax which differs just a bit too much from CSS to be useful.
deleted 2y ago
[deleted]
Joker_vD 2y ago
> I still say that the answer is just semantic HTML/CSS It's literally impossible to implement because humans just don't function like that. I'm sorry. The answer for discoverability on the Internet was not semantic URLs or even link directories, it was the search engines.
dgb23 2y ago
> I still say that the answer is just semantic HTML/CSS. You're coming at the problem from the wrong direction naming things for how you want them to appear. Name them for what they are. Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document. I would love to do that, but it's simply not practical, at least not without CSS hacks that are hard to reason about. --- A few reasons (non-exhaustive list): In general, the separation of HTML and CSS is theoretical, not practical. They are tightly coupled descriptions of your overall layout, which is why there are so many incomplete attempts to manage the resulting complexity (see: this article). HTML is not just content. It complects content plus layout. If you separate content from layout you get something like XML+XSLT, not HTML. HTML is a strict tree structure and CSS can only query it in two directions: "down" and "next". A lot of layout and styling concerns are graph relationships. You need to adorn things _up_ the tree (in the form of nodes/attributes/classes etc.) in order to give enough context for layout and styling down the tree. And in some cases that doesn't work either. Many CSS properties describe styling relationships between nodes. For example flex and grid make no sense in isolation. This couples the structure of your HTML with its styling in a profound way. Some HTML tags don't represent their structure well, for example: <dl>, <dt>, <dd>. The natural way of thinking of these elements, laying them out and styling them, is to group each <dt> and <dd> together. --- I agree half-way with you though. It's often useful to generate _just_ the "semantic" content at first: just use the tags and structure you need to lay out the structure of your content in a meaningful way. But as soon as you start caring about design, you will have to add tags, attributes classes etc. that are only there to serve styling.
- extra88 2y ago
  > CSS can only query it in two directions: "down" and "next". :has() has entered the chat.
  - dgb23 2y ago
    :has() is a lookahead. See my other comment.
- emmacharp 2y ago
prmph 2y ago
> Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document. But it's not possible to write HTML agnostic to how it's intended to appear, in the general sense. That's the issue with CSS. This whole thing about separating content and styling is carried too far leading to very bad UI architectures. Stuff like colors and fonts can be separated from content. Stuff like positioning, hierarchy, etc. cannot be meaningfully separated from content in many cases, and trying to do so is the root of UI evil. This is why the component approach is so powerful. By combining content (with its implied style) with explicit styling in an integrated package, large UI trees become composable and easier to reason about. But many devs still don't grasp this, and continue to fantasize about pure content that can exist totally separate from presentation, a pipe dream.
- emmacharp 2y ago
  You can use structural HTML and CSS inside components as their content is already structured and should not change on whim. Same for the first "master" layout layer. Applying styles with "form" classes like card still is semantic too!
jeroenhd 2y ago
It's the classic "internet as a means to share information" versus "internet as a means to make money" distinction. Clear, correct, semantic HTML is important to people who want information to be shared as effectively as possible, who want collecting and processing information to be done easily, and who value correctness. People trying to make a product don't give a rat's ass about correctness. They don't care if the button is actually a span with some weird inline CSS rules, they just want the blue "buy now" button to be front and center. Semantic CSS is correct and it's the theory behind web browsing, but priorities have shifted. The web has moved away as a method to share information and has become a method for making apps and interactive experiences. There's no business incentive for correct HTML and CSS, only for the buttons that make money to render correctly.
- emmacharp 2y ago
  Aren't there inherent advantages to correct and semantic code, advantages like performance, simplicity, understandability, expressivity, that could/should benefit the business?
  - RugnirViking 2y ago
    Those advantages don't appear on metrics and therefore don't exist. If the benefit to the business is in two years and isn't measurable, the benefit it would bring will be misattributed to whoever happens to be around afterwards using it
    - emmacharp 2y ago
      Quite true, unfortunately. But I think there are benefits that can be "feeled" almost instantly. I think problem is one of focus. Lots of team leads don't focus on these solutions and their benefits but rather on the most recent technologies and their own benefits while ignoring (or accepting as inevitable) their costs. The longer you look in that direction, the harder it gets to see what you are missing or could get by looking elsewhere.
    - _heimdall 2y ago
9dev 2y ago
Time and again, people argue as if everyone was just trying to style their blog. HTML isn't only used for documents that roughly look like a printed page, but also for actual web applications. Applications don't map too well onto HTML, and while the pedants are hung up on separating content from appearance, the rest of us is busy working on actual software. If nobody "does it right", maybe right is just wrong?
- azangru 2y ago
  > If nobody "does it right", maybe right is just wrong? It is certainly possible. However, what I have seen in the industry is that there are very few real CSS experts among people who are "busy working on actual software". Few people who have thought deeply about their methodology, the problems that it solves, and the problems that it introduces. And, on the contrary, there are too many people who either regard html/css as a playground for juniors, or are too happy to copy what other people are doing. In such context, it is very difficult to have a well-informed discussion about what is "right", and what is "wrong".
- emmacharp 2y ago
  I'm curious, why would you say "applications don't map too well onto HTML"?
  - 9dev 2y ago
    Most of the heavy lifting of modern web applications is still on "userland" JavaScript frameworks instead of the browser, because lots of dynamic interactions can't really be modelled with HTML alone. For example, consider creating a dropdown menu to select a contact, displayed with an avatar, name, and email as a subtitle. Doing that right—so it is accessible to screenreaders, has dynamic completions fetched from a server, adjusts to different output devices—is not only quite complex on its own, but also requires reinvention of several things, like an input field with a custom select box. Support for modal dialogs just became widely available two years ago. Two way data bindings between dynamic state and HTML elements still requires complex Javascript code. Drag and drop is a pain. Input elements haven't really caught up to the last twenty years. And while HTML does provide capabilities to register custom elements, they don't really catch on for a reason. I will say HTML is flexible enough to be used for just about anything, but it certainly is better suited for text documents than web applications.
squidbeak 2y ago
Rather, developer convenience over users.

by donatj 2y ago

have_faith 2y ago

Is `my-card` not a declaration of what something is (supposed to be)? The attributes are then encapsulating the state of the thing e.g. "is-loading", "size", etc. And the style then naturally follows, becoming a function of state e.g. "large loading indicator". The extend selector solves the problem of one style definition inheriting styles from another style definition, but the author is trying to solve the problem of how styles are mapped to stateful elements. It's the mapping process that introduces the combinatorial problems of class names.

the_other 2y ago
`.my-card` is semantic, but `.big` is presentational/visual. You could maintain the semantics with rules like: .my-card { width: normal; } .homepage .my-card { width: bigger; } .sidebar .my-card { width: smaller; } (where 'normal', 'bigger', and 'smaller" should be replaced with real values). BEM suggested state labels (e.g. `.my-card__loading`). I'm on the fence about those vs `.my-card.loading`. The class-based syntax seems shorter than either BEM-style or attribute selectors, and thus I prefer it. You might get a bit more rigour from the more longer-form methods, but I'm not convinced the energy isn't better spent training your team to be more careful. Shared code, CSS toolkits, shareable widgets present bigger challenges... the thing is that none of the tools suggested actually fix the problems. Your code can still break 3rd party code and vice-versa because of the global nature of CSS. Specificity needs management, but so do type systems and class hierarchies. Stop pretending the cascade and global namespace don't exist and just do the work.
- wruza 2y ago
  .big is what it really is, big. Inventing a new name for it like emphasized, enlarged or attention-grabbing is just unnecessary pedantry. Naming things what they are and then styling with how they must look like creates an additional linguistic layer in an already csessed up system. “What things are” must become component names, not a part of markup. If there’s no reason to componentize a chunk, it doesn’t get a name (and vice versa).
  - the_other 2y ago
    It's only visually big. To a blind person, it doesn't matter what size it is. It's big to fulfil some layout concern, and the layout concern is there to fulfil some attention or intent concern. And also, I didn't say one should use `.emphasised`. I said to change the size based on the container: `.hero .card {}` would be big but `.articles .card {}` would be normal sized. `.card`s are always just cards; their context makes them different variations. "But `.hero` is just another way of saying big, or emphasised"... Not really. A `.hero` is "the focus of the page. EVERYTHING (`.card`, `button`, `.btn`, `q` etc) inside `.hero` might all be big, or bold, or a contrasting colour, or surrounded by extra negative space, or in italic, or a mixture of those. Back when there were going to be aural style sheets [0], you'd have a way to specify alternate modality presentations using the same class names. It doesn't always make sense that something is aurally louder when it's visually bigger. `.big` is not "what things are". `.big` is "how do we express what that thing is in this situation". [0]: https://www.w3.org/Style/CSS/Speech/speech.html https://www.w3.org/Style/CSS/Speech/speech.html

jcelerier 2y ago

> The problem is the modern webs hyper focus on appearance over content. Content first, style second. That's not "the web", that's "most humans"

danbruc 2y ago

The problem is that you are trying to use a document markup language to create an user interface including designing and styling the controls themselves. Also computers were not black and white in the 90s.

Kiro 2y ago

> Name them for what they are. I've kept hearing (and believing) this for 20 years but never seen a project where it's actually enforced. It seems like one of those things that doesn't work in practice and that come with very few benefits compared to the overhead it creates. Every time I redesign something I throw out both HTML and CSS anyway.

isleyaardvark 2y ago
Whenever I have seen code like that, it’s awful. “Name them what they are” becomes “name them after their content”, which is the opposite of separation of concerns.

noirscape 2y ago

SCSS in general is a very good preprocessor for writing any amount of CSS when you're designing more than a single webpage. It's a very nice wrapper around CSS that make CSS feel so much less archaic to use. Do use SCSS though, not the weird SASS syntax which differs just a bit too much from CSS to be useful.

deleted 2y ago

[deleted]

Joker_vD 2y ago

> I still say that the answer is just semantic HTML/CSS It's literally impossible to implement because humans just don't function like that. I'm sorry. The answer for discoverability on the Internet was not semantic URLs or even link directories, it was the search engines.

dgb23 2y ago

> I still say that the answer is just semantic HTML/CSS. You're coming at the problem from the wrong direction naming things for how you want them to appear. Name them for what they are. Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document. I would love to do that, but it's simply not practical, at least not without CSS hacks that are hard to reason about. --- A few reasons (non-exhaustive list): In general, the separation of HTML and CSS is theoretical, not practical. They are tightly coupled descriptions of your overall layout, which is why there are so many incomplete attempts to manage the resulting complexity (see: this article). HTML is not just content. It complects content plus layout. If you separate content from layout you get something like XML+XSLT, not HTML. HTML is a strict tree structure and CSS can only query it in two directions: "down" and "next". A lot of layout and styling concerns are graph relationships. You need to adorn things _up_ the tree (in the form of nodes/attributes/classes etc.) in order to give enough context for layout and styling down the tree. And in some cases that doesn't work either. Many CSS properties describe styling relationships between nodes. For example flex and grid make no sense in isolation. This couples the structure of your HTML with its styling in a profound way. Some HTML tags don't represent their structure well, for example: <dl>, <dt>, <dd>. The natural way of thinking of these elements, laying them out and styling them, is to group each <dt> and <dd> together. --- I agree half-way with you though. It's often useful to generate _just_ the "semantic" content at first: just use the tags and structure you need to lay out the structure of your content in a meaningful way. But as soon as you start caring about design, you will have to add tags, attributes classes etc. that are only there to serve styling.

extra88 2y ago
> CSS can only query it in two directions: "down" and "next". :has() has entered the chat.
- dgb23 2y ago
  :has() is a lookahead. See my other comment.
emmacharp 2y ago

prmph 2y ago

> Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document. But it's not possible to write HTML agnostic to how it's intended to appear, in the general sense. That's the issue with CSS. This whole thing about separating content and styling is carried too far leading to very bad UI architectures. Stuff like colors and fonts can be separated from content. Stuff like positioning, hierarchy, etc. cannot be meaningfully separated from content in many cases, and trying to do so is the root of UI evil. This is why the component approach is so powerful. By combining content (with its implied style) with explicit styling in an integrated package, large UI trees become composable and easier to reason about. But many devs still don't grasp this, and continue to fantasize about pure content that can exist totally separate from presentation, a pipe dream.

emmacharp 2y ago
You can use structural HTML and CSS inside components as their content is already structured and should not change on whim. Same for the first "master" layout layer. Applying styles with "form" classes like card still is semantic too!

jeroenhd 2y ago

It's the classic "internet as a means to share information" versus "internet as a means to make money" distinction. Clear, correct, semantic HTML is important to people who want information to be shared as effectively as possible, who want collecting and processing information to be done easily, and who value correctness. People trying to make a product don't give a rat's ass about correctness. They don't care if the button is actually a span with some weird inline CSS rules, they just want the blue "buy now" button to be front and center. Semantic CSS is correct and it's the theory behind web browsing, but priorities have shifted. The web has moved away as a method to share information and has become a method for making apps and interactive experiences. There's no business incentive for correct HTML and CSS, only for the buttons that make money to render correctly.

emmacharp 2y ago
Aren't there inherent advantages to correct and semantic code, advantages like performance, simplicity, understandability, expressivity, that could/should benefit the business?
- RugnirViking 2y ago
  Those advantages don't appear on metrics and therefore don't exist. If the benefit to the business is in two years and isn't measurable, the benefit it would bring will be misattributed to whoever happens to be around afterwards using it
  - emmacharp 2y ago
    Quite true, unfortunately. But I think there are benefits that can be "feeled" almost instantly. I think problem is one of focus. Lots of team leads don't focus on these solutions and their benefits but rather on the most recent technologies and their own benefits while ignoring (or accepting as inevitable) their costs. The longer you look in that direction, the harder it gets to see what you are missing or could get by looking elsewhere.
  - _heimdall 2y ago

9dev 2y ago

Time and again, people argue as if everyone was just trying to style their blog. HTML isn't only used for documents that roughly look like a printed page, but also for actual web applications. Applications don't map too well onto HTML, and while the pedants are hung up on separating content from appearance, the rest of us is busy working on actual software. If nobody "does it right", maybe right is just wrong?

azangru 2y ago
> If nobody "does it right", maybe right is just wrong? It is certainly possible. However, what I have seen in the industry is that there are very few real CSS experts among people who are "busy working on actual software". Few people who have thought deeply about their methodology, the problems that it solves, and the problems that it introduces. And, on the contrary, there are too many people who either regard html/css as a playground for juniors, or are too happy to copy what other people are doing. In such context, it is very difficult to have a well-informed discussion about what is "right", and what is "wrong".
emmacharp 2y ago
I'm curious, why would you say "applications don't map too well onto HTML"?
- 9dev 2y ago
  Most of the heavy lifting of modern web applications is still on "userland" JavaScript frameworks instead of the browser, because lots of dynamic interactions can't really be modelled with HTML alone. For example, consider creating a dropdown menu to select a contact, displayed with an avatar, name, and email as a subtitle. Doing that right—so it is accessible to screenreaders, has dynamic completions fetched from a server, adjusts to different output devices—is not only quite complex on its own, but also requires reinvention of several things, like an input field with a custom select box. Support for modal dialogs just became widely available two years ago. Two way data bindings between dynamic state and HTML elements still requires complex Javascript code. Drag and drop is a pain. Input elements haven't really caught up to the last twenty years. And while HTML does provide capabilities to register custom elements, they don't really catch on for a reason. I will say HTML is flexible enough to be used for just about anything, but it certainly is better suited for text documents than web applications.

squidbeak 2y ago

Rather, developer convenience over users.