11 ms·

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 class

• jasim 10y ago
  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 https://github.com/styled-components/styled-components). Consider reading http://nicolasgallagher.com/about-html-semantics-front-end-architecture/ http://nicolasgallagher.com/about-html-semantics-front-end-a..., http://mrmrs.io/writing/2016/03/24/scalable-css/ http://mrmrs.io/writing/2016/03/24/scalable-css/, and http://johnpolacek.com/2016/06/17/atomic-css-movement/ http://johnpolacek.com/2016/06/17/atomic-css-movement/ for reasoned perspectives.
  • jameslk 10y ago
    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 https://en.wikipedia.org/wiki/Dependency_inversion_principle
    • andrewingram 10y ago
      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.
• RubyPinch 10y ago
  > 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?
  • SerLava 10y ago
    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.
• Risord 10y ago
  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.
• Mikhail_Edoshin 10y ago
  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. <b>, <font>, and <blink> tags have perfect semantics, while things like <figure> or <article> have none or very vague wishy-washy one.
  • Firadeoclus 10y ago
    Semantics is the branch of linguistics and logic concerned with meaning. With tags like <b> or <font>, 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.
  • deleted 10y ago
    [deleted]
  • TuringTest 10y ago
    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.
• progval 10y ago
  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>
  • nailer 10y ago
    `<select>`s aren't styleable so you have to do a select proxy.
    • steveax 10y ago
      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.
      • nailer 10y ago
        Thanks! More info for others: http://stackoverflow.com/questions/1895476/how-to-style-a-select-dropdown-with-css-only-without-javascript http://stackoverflow.com/questions/1895476/how-to-style-a-se...
  • vinayakkulkarni 10y ago
    Look at the second example: https://semantic-ui.com/modules/dropdown.html#selection https://semantic-ui.com/modules/dropdown.html#selection
  • tregoning 10y ago
    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
• hnlauncher 10y ago
  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.
• olegkikin 10y ago
  They also use <i> 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 https://semantic-ui.com/elements/button.html
  • YCode 10y ago
    Is that a problem, give em/strong cover b/i these days?
  • mdtusz 10y ago
    Is this so bad? It seems to me that using <i> for icons has become pretty standard across many sites and you shouldn't be using the <i> tag for italics anyways - there's <em> for that now.
    • talmand 10y ago
      Using <i> for icons is a bad idea. Wait, no, it's the wrong thing to do. The <i> element still has meaning and can be used for that purpose, of which has absolutely nothing to do with icons.
    • strictnein 10y ago
      So <i> for icons and <b> for buttons then?
      • schindlabua 10y ago
        Don't forget <u> for URL's.
• spectistcles 10y ago
  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.
• adamwathan 10y ago
  I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/ 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.
  • yoran 10y ago
    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-data/ https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.
• jlukic 10y ago
  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.
  • jameslk 10y ago
    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.
• ahallock 10y ago
  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.
• ahallock 10y ago
  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.