Hacker News Reader

Comment by jameslk | Hacker News Reader

I've always found it ironic that this library calls itself "Semantic UI" but doesn't follow the practice of semantic HTML/classes[0]. W3C suggests[1] that classes should be used for semantic roles (e.g. "warning", "news", "footer"), rather than for display ("left", "angle", "small" -- examples taken from Semantic UI's docs). So instead of giving a button the class of "button" it would be better to give it a class such as "download-book." The benefit of this is when it comes time to redesign parts of a site, you only have to touch your stylesheets instead of manipulating both the stylesheets and HTML. That is, so we don't fall into the old habits of what amounts to using <blink> tags.

0. https://css-tricks.com/semantic-class-names/

1. https://www.w3.org/QA/Tips/goodclassnames

View on HN

I used to think this way until reading this article by Nicolas Gallagher:

http://nicolasgallagher.com/about-html-semantics-front-end-a...

These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards.

If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.

Your HTML documents are already coupled to your project, so rather than writing CSS that's coupled to that HTML, I've found it to work much better to author CSS from a mindset that the CSS knows nothing about the document it's trying to style.

This leads to writing what I call "library-style" CSS, where you are almost trying to build your own Bootstrap or similar; something that you could actually use on multiple projects if you wanted.

A class like "download-book" is not very useful if you have multiple buttons in a project that are meant to look the same way and not all of them trigger a book download.

I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation.

I find

  // style.scss
  @mixin button($color, $size) { ... }

  .download-book {
    @include button(
      $color: red,
      $size: big
    );
  }

  .send-email {
    @include button(
      $color: blue,
      $size: small
    );
  }

  // index.html
  <button class="download-book">Download book</button>
  <button class="send-email">Send email</button>

much cleaner than

  // style.scss
  .button { ... }
  .red { ... }
  .blue { ... }
  .big { ... }
  .small { ... }

  // index.html
  <button class="button big red">Download book</button>
  <button class="button small blue">Send email</button>

1. When you change the visual aspect of an element, you go to the stylesheet and don't go adding/removing classes from the content layer (HTML).

2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

Of course, your CSS file becomes a lot bigger. But when enabling compression, the stylesheets using mixins turn out to be smaller (see https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.

I agree with your point of view as well. With Vue, I am writing all my styles in a .vue file which contains a component composed of style, markup, and js. It's incredibly clean and easy to maintain.

>> Of course, your CSS file becomes a lot bigger.

If you use something like webpack and you start splitting code based on the page you are on, this problem goes away as well.

I find that only place the 2nd case makes sense is if you are writing a CSS framework like Bootstrap. Otherwise, I find this way writing CSS increasingly rare.

> 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr":

[0]: https://github.com/css-modules/css-modules

I find tha the library-style "button" "red" "blue" "big" example prevents me from having to flip over and maintain CSS with every HTML change.

Yet your first example has everyone editing CSS files and appending new classes to it all the time, which in my experience is the fastest way to end up with unmaintainable CSS.

Mixins sounded good to me at first, but I've only experienced less maintainability when the CSS was too clever.

A class called "download-book" wouldn't be semantic either.

A semantic choice of classes should represent the roles that things have in the UI hierarchy: if a "book download" button is the main action of the page, it should have a class of, say "main-action", possibly with an extra "download" class to show UI specific to download actions.

If a "book download" button is just an action, for example a button that is repeated multiple times in a table, then it needs a different class, like "action", still possibly with "download".

This is exactly like properly written HTML is semantic, elements represent hierarchical roles ("nav", "footer"), not their look, nor their content.

that misses the point.

parent described things like moving the navbar to the left when the html can have it before or after the content on the dom. can you use float:left?

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style:

    <div class="red pull-left pb3">
    <div class="grid row">
    <div class="col-xs-4">

when you could look at this:

    <div class="basket">
    <div class="product">
    <div class="searchResults">

The latter, aside from sparing your brain endless visual noise, makes it instantly clear how the html maps to the page elements.

Taken from http://maintainablecss.com/chapters/semantics/

> If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.

As for this technical argument, it's flatly untrue. Writing semantic HTML and the coupling you are referring to are completely orthogonal as long as you are using a tool like Sass / postCSS / etc to author your CSS.

Thing is, if you're using Angular (or most likely any of the hot SPA frameworks out there), you don't need semantic CSS class names, since the model bindings will make the meaning quite clear.

You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.

My answer was implicit is the final comment. The purpose of those elements is not re-use. It's clarity. The re-use happens in the Sass (or other preprecessor) code. Somewhere in your Sass, you define "basket" as a "pull-left; row; col-xs-4" or even higher level constructs which you plan to re-use... that's up to you.

The point is they are orthogonal issues. Creating re-usable chunks of CSS does not suddenly absolve you of the responsibility to make your HTML readable. You can do either one without the other, but you should be doing both.

I agree you can write your Sass like that and 'do both', and I'm all for writing good Sass and building up higher level abstractions for re-use where you can.

However, there's no denying the reusability of classes like 'col-xs-4', despite the knee jerk hatred of that 'non-semantic' class from some in this thread, and I maintain that if all you needed was a col-xs-4 and your team know what col-xs-4 is, then why not just stick it in your HTML.

It doesn't make it less 'readable' for your team, and they're the primary audience.

> You can do either one without the other, but you should be doing both.

I guess I'm disagreeing you should always be doing both. Do both (create a new semantic class-name) where it makes sense. But when you already have a reusable class that does the job, and all of your team will understand, just use it.

To change it, I'll have to go spelunking through either the HTML or the CSS, and if I was a designer, I'd probably pick the CSS. Looking for the 'product' class and tweaking a few properties sounds much nicer than figuring out how I need to change 'col-xs-4'. I'd rather have a conversation with the layout engine than struggle with some middle-man generic CSS framework like Bootstrap - it's simpler and more flexible (imo).

The lower-level abstraction (raw CSS) vs the higher level (bootstrap's grid) is more flexible. It's not simpler though, which is why the abstraction is worth learning. With a grid framework, you can make changes at a common level of abstraction that your teammates will understand. Because I guarantee the way you'd implement the equivalent behaviour in raw CSS is not how I would, and now we have both styles in the codebase (complexity).

Also yet to meet one of these 'designers' that would rather change CSS than HTML. And logically ... you can't understand CSS without understanding HTML, so preferring to make the change in CSS is just an arbitrary decision.

You could look at "basket", "product", and "searchResults", except that it tells me absolutely nothing as a dev about what it looks like. You shouldn't be using your CSS classes to tag sections, that's what id is for. And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.

> except that it tells me absolutely nothing as a dev about what it looks like.

That's because it shouldn't be.

> You shouldn't be using your CSS classes to tag sections, that's what id is for

No, you might can have multiple "products" on the page.

> And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.

Absolutely none of this true if you use Sass (or an equivalent) properly.

> That's because it shouldn't be.

Why not? Who's reading my HTML? It's not there to be read by a user. HTML is for devs. They're the ones that deal with it.

> No, you might can have multiple "products" on the page.

True, in that case you would use a CSS class with no styling if you need code to select the block.

> Absolutely none of this true if you use Sass (or an equivalent) properly.

It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).

> HTML is for devs. They're the ones that deal with it.

Correct. You make it readable the same reason you make any code readable.

> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).

No. The whole point is if you use SASS properly you don't have to nest anything unless you want to.

> The whole point is if you use SASS properly you don't have to nest anything unless you want to.

I don't follow at all. One of the biggest selling points of Sass is being able to nest styles. If you don't need to nest styles, then Sass doesn't get you much. But once you start nesting, your CSS is coupled to your HTML. That's absurd.

it may be "a big selling point," but you're being sold a bill of goods.

using sass as you describe is an anti-pattern.

the important thing that sass allows you to do (which CSS should have built in, but doesn't) is to apply chunks of style to a named class. that is, precisely to decouple naming, styling, and html structure. you do this in sass with @extend or @include.

practically, this means i can take canned styles of my own making or from libraries like bootstrap, and then define my semantically named classes in terms of them. this allows composition at any level of granularity, total control over the units of re-use, and clear, readable markup.

I'm not convinced you can just call using a major feature of sass an "antipattern"... Without nesting, what you've described is essentially utility classes abstracted an extra level away under pretty names. Might as well get rid of that layer because it makes false promises. You'll end up reusing that CSS class and then find out that the usage in one area needs a slightly different markup. Cue nesting/extra CSS classes with slightly different names, etc.

There's this dream that you will need to "reskin" your application often, and be able to reuse a bunch of CSS classes all over your codebase. Instead what I've found is that it's better to think of your application as consisting of components with their own styling. Component-oriented frameworks like React are moving in this direction. Take a look at the styled-components library.

> HTML is for devs. They're the ones that deal with it.

As devs, we can view this html through a browser and use in-browser dev tools to view the associated CSS. There's no need to explain the style in the HTML.

You can still do that when you use utility classes. The benefit is that now you have a guarantee that you can drop a view anywhere in the application and have it render the same. I can restructure the HTML without worrying that I broke styling in an edge case.

There is no way for you to mess up something at the other end of your web app if you use specific sass files for specific web pages. The 'basket' class can be defined as one thing on the page for selling baskets, and it can be defined completely differently on some other page where baskets are, idk, displayed in some other way.

Single Page Applications. Reusable components. Both of these make CSS harder to manage, and semantic classes start becoming a problem.

Please elaborate. I don't see how having a library of SASS mixins that you mix in to make specific CSS classes for specific purposes make anything harder to manage? If anything, decomposing things to smallest common denominator makes it easier to build better and more versatile CSS for your apps.

It's not the sass mixins that makes things harder to manage. The problem is having nested CSS rules that cause your CSS to become tightly coupled to the structure of HTML. Then when the HTML changes, you have to rethink the relationships. And if you're not using nesting, then isn't what you described just utility classes abstracted one level away?

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. The reason we need semantics in HTML is to make the markup accessible for screen-readers, and no screenreader considers the class name of an element when reading it out. What we instead need are semantic tags like article, section etc. and aria tags like role.

CSS classnames are purely for the developer's benefit. Not the user's. And as developers, forcing ourselves to find semantic meaning for every element we write leads us to component-oriented CSS like BEM. Which is a fine thing, but we can also use purely visual classes - like `bg-red bold border-solid` if it helps (and it does. check out tachyons.io)

The class names of elements in Google's homepage for example reads like 'tsf-p', `oq`, `gsb` etc. I suspect these are machine generated. Same with Facebook. One of the best libraries to do this currently is styled-components (https://github.com/styled-components/styled-components).

Consider reading http://nicolasgallagher.com/about-html-semantics-front-end-a..., http://mrmrs.io/writing/2016/03/24/scalable-css/, and http://johnpolacek.com/2016/06/17/atomic-css-movement/ for reasoned perspectives.

I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single source of truth) without rummaging through our entire codebase to modify appearances of things (separation of concerns).

When I first discovered csszengarden.com, I realized the point of CSS and its power. HTML was made for hypertext and semantic content structure and CSS was made for appearances. Either one could be completely replaced partially or wholly, separate of each other. Classes are like interfaces[0] which allows for HTML to remain dumb and decoupled from presentation. When the HTML and CSS are hardcoded to specific design concepts themselves, then the usefulness of CSS as in "cascading style sheets" is nearly eliminated. These concepts aren't a fad, this is good software architecture brought to you by an international consortium who's been thinking about it for decades.

0. https://en.wikipedia.org/wiki/Dependency_inversion_principle

There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments.

Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup changes tend to be more expensive (you can't just move a block of HTML from one place to another and not expect its appearance to change).

These days though, we're increasingly building things in a UI-oriented way. What you see on the page is a composition of a number of components. If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. So now i'm authoring CSS that is bound to the structure of this component, naming becomes a lesser issues. The other thing worth pointing out is that it's not too difficult to built a document-UI (like say a magazine) using app-UI patterns, but it's rather challenging to do it the other way around.

If the goal is maintainability, then there should be zero industry-wide dogma. Best practices are going to be coupled to the methodology of the maintaining team. Personally, I did document-oriented CSS for 15 years, now i'm doing component-oriented CSS, and the results are much better. Obviously this is just an anecdote, but i'm not alone in this.

This idea that design is a "layer" on top of structure is somewhat offensive to the designer in me. Visual design is (and should forever be) coupled to structure and behaviour. Design is not a higher abstraction, it's something that pervades everything.

> If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties.

What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML?

We use components everywhere. We style in stylesheets. Handily we even keep the stylesheets in the same component as the module, thanks to npm-sass / sass-npm.

Sorry, i'm struggling to follow what you're asking here.

Whether you style in stylesheets or by some other means (CSS-in-JS?) is an implementation choice rather than something that affects the fundamental pattern. If your components are truly portable, you're already doing things the way I suggest. If they inherit things like fonts and colors from their parent via the cascade rather than via explicit properties, then you don't have truly portable components - their appearance will change when you move them around.

> Whether you style in stylesheets or by some other means (CSS-in-JS?)

We're specifically talking here about putting styling logic - "left" "shiny" "big" etc - in HTML.

> is an implementation choice rather than something that affects the fundamental pattern.

Sure, you can still use a component pattern with styling split into HTML and stylesheets - it certainly doesn't effect the pattern.

The issue is: when you want to change the appearance of your component, do you want to modify styling logic in two places or one?

One, that's why I style inline :)

Do you mean inline in CSS / style tags, avoiding visual HTML classes (in which case we're in agreement - there's one way to edit how something looks, though style tags have other issues) or combining either of those with visual HTML classes like this library uses?

Okay, I think we're in agreement and are just crossing wires a but. The main reason i'm loosely okay with Semantic UI is that I just see it as using HTML fragments as building blocks rather than using JavaScript components. I wouldn't advocate it for anything elaborate, but I think it can work well within a certain problem space.

I'm not sure you read the articles GPP mentioned, yes CSS Zen Garden was the dream, but I feel like articles like the excellent mrmrs one [1] address the reality.

[1] http://mrmrs.io/writing/2016/03/24/scalable-css/

> The reason we need semantics in HTML is to make the markup accessible for screen-readers

Not sure about the screen-readers but when you add a class for, say, "small", it's a bit confusing because you can't guess how it is used when looking from the CSS side. One day, you decide to represent the unimportant text as grey (bad idea) and then you need to find all instances of .small that are used for the unimportant content and change them to .grey (then you discover there already is a class named gray, oh the horror) whereas if you used .unimportant as a class name, your change would be a single line of CSS. Also, "h1 .unimportant { color: something-not-grey }" is way clearer than ".bold.big .small { color: something-not-grey }".

Semantic names for CSS classes have the same utility as good variable/function/method names in code. They describe what is this for, not how should it look. I have seen enough .red12px where it was green and 10 px already. Cannot wait for the new web standards movement to start already.

`.red12px` is for sure a bad example, but often-times "what is this for" in the context of a tag with a class on it is purely for styling. This div is here because I want padding here / a different font / whatever, and I can either be upfront about that (maybe with something a little more maintainable like `.padding-large` rather than `.padding-40px`), or I can do a little dance and invent some semantic name like `.widget-inner-details` that serves no purpose other than giving me a hook to say "I want larger padding here"

There are really two different concerns which are often conflated:

1) Semantic markup for the sake of screen readers (and Google and so on)

2) Separation of concerns for the sake of maintainability

I don't know how separation of concerns cause grief for developers, my experience is the opposite. Separation of concerns not a "fad", it is a fundamental principle of any kind of systems design. That said, it doesn't directly affect users, just as users don't care if you write incomprehensible spaghetti code.

Getting both sides of this arg: basically 'sep of concerns' is viewed as being 'seperation of technology' rather than actual sep of concerns. Eg, put documents and styles and behaviour for a related component together, seperate that component from other components.

It's a slightly silly argument because really we're arging between slicing something vertically (tech) vs horizontally (components) and the nicer thing is probably to do both - have lots of components with the documents, styles, and behaviour separated out within each component.

Author of SUI here again.

Semantic is based on the idea that describing physicality (the function of html/css) is a task natural language is acutely optimized for, while describing the implementation of behavior ("cooking recipes", or the vast majority of programming implementation) is best served by programming languages.

Part of how natural language optimizes for transmitting meaning is by reducing ideal forms of concepts to words based on the exact amount of specificity for conveying meaning between humans. I.e. "horse" instead of "quadrupedal mammal that has a heart and has eyes and has a tongue..." etc.

These 'units of optimized human idea transmission' (read words) are then clarified using a system of modifiers that take care of removing just enough ambiguity that the idea is communicated effectively. "The kindly, gentle lion", "The angry, hungry lion".

The modifiers themselves carry no absolute meaning. A "large ant" may be smaller than a "small planet", but we understand them -- in context -- of the nouns.

Language is littered with other interesting features like this that are designed particularly for this task of describing physicality. Most of which are absent from programmatic implementations of 'languages for describing physicality' like HTML/CSS.

Other key examples of useful cognitive optimization: Plurality, "Three large red buttons" vs "Large red button, large red button"; significant word order, "left floated right aligned column" vs "right floated left aligned" column.

I think the main drawback with using a natural language approach is that the implementation has to be bullet proof. Although everyone uses language, we never have to implement systems of interpreting language from phoneme to neuronal pathway. So even though the benefits are clear, the path forward in mapping language to systems of programmatic physicality isn't exactly straightforward.

Thank you for clarifying your library's usage of "semantic." Although I disagree with how it currently abuses the original design philosophies of HTML/CSS, I can see an interesting perspective that this library has taken alternatively with the meaning of being semantic, which is valuable and insightful.

When I first heard about Semantic UI, I was excited because I had hoped someone had finally built something like Bootstrap using only Sass/Less mixins that were pure and side effect free (i.e. not littering the global namespace with generically named classes, not dependent on the structure of the HTML). I was disappointed that was not the case and frustrated with the confusion of the usage of "semantic" when its already widely adopted to mean something specific for HTML.

I really wish UI libraries were built on mixins. Pure mixins would allow for reusable component styles and modifiers such as "three large red buttons" to be mixed into semantically-named CSS classes such as "user-controls." Additionally, mixins would allow for media query usage (e.g. I could use a "big red button" for desktop and "small red button" for mobile), allow for more selectiveness about which components/modifiers I want to use (which may reduce the overall size of the CSS), allow for conditional styling logic, and generally be easier to work with in a CSS preprocessor. This facilitates all the goals you've mentioned while being more flexible, open to extension and enabling us to stick to the way HTML/CSS was meant to be used. Maybe you've already considered all of this and have your reasons for not pursuing it. I'm sure it would be much more work to go that way now regardless, although it seems Bootstrap 4 has started heading in that direction.

They also use tag for icons.

    <div class="ui icon buttons">
      <button class="ui button"><i class="bold icon"></i></button>
      <button class="ui button"><i class="underline icon"></i></button>
      <button class="ui button"><i class="text width icon"></i></button>
    </div>

https://semantic-ui.com/elements/button.html

Is that a problem, give em/strong cover b/i these days?

Is this so bad? It seems to me that using for icons has become pretty standard across many sites and you shouldn't be using the tag for italics anyways - there's for that now.

Using for icons is a bad idea. Wait, no, it's the wrong thing to do. The element still has meaning and can be used for that purpose, of which has absolutely nothing to do with icons.

So for icons and for buttons then?

Don't forget for URL's.

Also, it uses this instead of <select>:

            <div class="menu" tabindex="-1">
              <div class="item" data-value="ad"><i class="ad flag"></i>Andorra</div>
              <div class="item" data-value="ae"><i class="ae flag"></i>United Arab Emirates</div>
              <div class="item" data-value="af"><i class="af flag"></i>Afghanistan</div>

`<select>`s aren't styleable so you have to do a select proxy.

They are, to some extent at least, depending on what browsers you need to support. You have to set *-appearance: none and build the styles back up.

Thanks! More info for others: http://stackoverflow.com/questions/1895476/how-to-style-a-se...

Look at the second example:

https://semantic-ui.com/modules/dropdown.html#selection

Unfortunately there are some severe limitations of using native select, in particular in relation to list item (i.e. option element)

- Can't have anything but plain text: (e.g. no images, bold text etc)

- Can't have a line-break, or somehow wrap text into a 2nd line if entry is too long

Keeping html independent from css would be nice thing for sure. But since reusable stylesheets from these libraries are used we need to have also stylesheets to be independent from html. When we have just 'two things' both of those really cannot be independent from each other. So some trade-off is must.

One interesting way I have tried is to add third thing. So I can create stylesheet with visual class names (or use 3rd party) and html with semantic ones. After this I create separated stylesheet-html mapping. In practise it's just a sass where I extend semantic classes with visual ones.

I haven't tried this yet on scale but it's very handy for example mapping icons at least.

I always found that "semantic" approach very misleading. In computer languages "semantics" is what the computer does with your input. This is the semantics of C, for example. Markup languages are no different. Until you have a clear specification what computer does with the markup, you have no semantics. I.e. , , and <blink> tags have perfect semantics, while things like <figure> or <article> have none or very vague wishy-washy one.

Semantics is the branch of linguistics and logic concerned with meaning.

With tags like or , the meaning of the tags themselves as they're supposed to be understood by the browser is clear. Semantic tags, on the other hand, are supposed to associate meaning to their content.

The definition of the word "semantics" pretty much aligns with "meaning", so it may work as a placeholder for different topics when used in different areas. The use you describe applies only in the context of programming languages, where the semantics describe "what low level code will be generated from my high level code", or "what is the meaning of this code with respect to the capabilities of the language runtime engine".

On the web, though, "semantics" is applied to the problem domain; i.e. "what application am I trying to build with this code", i.e. "what is the meaning of this word with respect to the final user-facing application". Thus, for HTML you get words for the things that are typically build with HTML: web pages. Then you get tags for articles, images, quotes, headers and footers, side bars, etc. These describe the types of content in the page, not how they look.

The "semantic web" is a generalization of this "domain knowledge" idea, providing tools to define your own vocabularies and build applications with them. This approach amounts to creating your own programming language (a new one for each application) in a way that best suit the problem at hand, rather than using a general purpose programming language.

> you only have to touch your stylesheets instead of manipulating both the stylesheets and HTML.

Well isn't the point here that you'd only have to modify the HTML, leaving the CSS alone for the most part?

I find that this is such a superior approach for certain websites. If a site has a large number of secondary pages designed around totally different content, the "only touch the stylesheet" seems to lead to despair.

I've seen people crap out things like #aboutPage #mainContent p:nth-child(2) div button {styles go here} ... because they follow the "separation" concept blindly. And then, you know, a paragraph gets added in later. Made up example but you get the point.

That W3 tips link is a decade old and not in any way normative. Appealing to it's authority is silly IMO and talking about semantic CSS like one does semantic HTML is even sillier as semantic CSS doesn't exist in the HTML sense.

I know, all these users viewing source and getting excited about the semantic HTML classes. HTML classes are for devs so let's use them how we see fit. I don't even think screen readers take into account HTML classes. While semantic class names (odd term -- even presentational names have meaning) is a recommendation, in practice, it actually works against you.

If you break your HTML into partials using a template language or components with React, Vue.js, etc., you only need to update in one place as well.

This has always been my understanding as well. I've always tried to write HTML in a manner that would remove all presentational aspects to the point that I could redesign an entire site by changing the CSS only.

Reply on news.ycombinator.com