It's like Twitter Bootstrap where the classes are named after the functionality you are adding to the div. For example a div of an container of three buttons has two classes (three and buttons).
This is the step between making prototypes with Bootstrap/Foundation and turning those classes/mixins into a final working application. You don't want your final build to have a bunch of 'col-md-6' class names.
Nobody, except the individual that has to change them all when you need to swap out frameworks or upgrade to a version that breaks compatibility or the product team decides on a new layout across the app...
Fair point, but I'm with you on it—I'm not proposing Semantic UI is any better, just that ".col-md-12" has its own set of problems. I suppose in theory what would be the best is using application selectors (i.e. class names your application owns) with the sass version of bootstrap/semantic/etc to extend the selectors with appropriate styles. However, I've done this, and while I'm no CSS expert so I probably was doing something wrong, my stylesheets became ginormous.
Now, I just kind of live with the ".col-md-12" business...
Gosh that irritates me - does that mean that the "tap just above the clock to return to top" doesn't work?
Edit: just checked, and yes it does. Also breaks the pattern where iOS shrinks the address bar and navigation bar when you scroll down. Completely unacceptable for a UI library to break these OS-level patterns
Also pretty spotty animations and such on Safari Tech Preview (#27) for me. Also, the "Intuitive Javascript" demo doesn't really work intuitively. It shows a scrollable box the size of one item—it doesn't drop down and you cannot see multiple items at once to select many in the "select multiple" example.
Websites implementing their own scroll behavior irritates me to no end. Scrolling is implemented pretty damn perfectly in every browser and OS I use. I really would love to have someone explain why they feel they need to tinker with it. In addition even if it's not broken it makes the website feel off because you are expecting a certain behavior and it's just somehow different and makes me feel even a little sick to my stomach. Similarly to narrow FOV in a game.
Author of SUI here. There's some weird JS flickering occurring on the homepage in iOS.
Not an issue with the library (other pages besides homepage are fine), probably an issue with the gradient animation at the top of the homepage. I'll try to add a fix.
On S7 / Chrome, animations like accordion and message dismissal all lag heavily.
Here I am, using a phone more powerful than my desktop, and basic UI elements are still lagging.
Don't get me wrong - the project looks nice and solves problems in its domain, but I still feel we've made a seriously wrong turn somewhere that made us end up with UIs on the web...
The worst site I visited the last 7days (iOS). A lot of things broken, flickering, broken scrolling, overlapping things, slow, laggy, buggy. Do you even test for mobile?
Trying to tell me a big comprehensive CSS library breaking mobile devices in 2017 is useful is like trying to sell me a car that can't drive on pavement.
I alternate between thinking this sort of thing is merely misguided, or merely a waste of time.
I want to like it, a lot. But I can't help feeling that this ship sailed years ago.
Simple UIs that are easy to interpret are a thing of the nineties. We left them because we evidently didn't realize what we had. Also, people like flashy things. A lot.
Seems like a next evolution of Bootstrap components. The trick with this type of stuff is always in how it plays with other frameworks. Can I drop into jQuery if I need to, and still interact easily with controls? Is there some obscene DOM skeletons in the closet that's going to bite me in the ass later?
We use an Ember library of Semantic UI [1] and it's pretty much a drop-in install to get a visually coherent front-end up and running with a minimal amount of redesigning a wheel. It's themeable and pretty extensible on the CSS side (and is all prefixed with a 'ui' class), and on the javascript side Ember lets you get right to it's hooks with Ember.$.component(). It may be a little on the heavy side, but it's been designed to be severable when needed, by component, by css, and by javascript-requiring components. I've not felt hemmed in or constricted by it's design mechanics.
I've had a few javascript 'settings' fail to make it all the way to my Ember components, but in general these were bugs that were promptly fixed in newer versions. Docs are pretty good too.
I kind of like it. It's been pretty nice to just have a dropdown, a button, a label, a whatever out of the box without me having to figure out all the CSS tricks for mobile or various browsers. And the more I've used it I've been able to craft my own visual components upon its foundation that conform to a consistent style.
It's integrated with React and there's a separate mobile UI for it. Ant is Chinese, with docs translated into English.
Like China, it's huge^^
I've just been fooling around with it today for the first time in create-react-app and seems good so far. Haven't tried on mobile.
I started working with it yesterday. It's a little gratuitous on hover state animation usage but has otherwise been very pleasant!
I also couldn't find css classes just for coloring text in the docs anywhere which kinda made me sad, but wasn't too hard to add a couple to my baseline css. I just wish there were a text-primary class or something (is there one that I missed?)
Slick, first library that gets many things right I think. However, there's apparently a desktop-version and a mobile-version. Is this normal? Don't people make responsive designs these days, but separate UIs for mobile/desktop?
I've done a few projects with Sematic UI. I think it's great for desktop based business applications. It looks slick, and has great animations. Plays nice with heaps of frameworks, I was using meteor.js
However, don't use it on mobile - it will destroy performance.
It's just a huge amount of CSS - with lots of animations and transitions. The css is somewhat optimised, it just does lots of cray shit, lots of repaints.
Is it possible these days to have a fully interactive mobile application with just HTML and CSS? Have CSS animations gotten good enough? I'm talking things like pure CSS accordians, modals/pop-ups, tooltips, etc.
Semantic UI is something I personally use for a few projects, but I really wish some of this stuff didn't require so much javascript and was more encapsulated like Tachyons [1]. The main problem I've encountered when using Semantic UI is that it becomes difficult to change the prebuild components significantly.
Can you elaborate? I was under the impression that HTML and CSS were by default already accessible and Javascript is likely to break things (an instance I've encountered is not properly setting tabindex, for example).
Web components definitely help, IMO, not by getting rid of JavaScript, but by making it possible to use custom elements without JavaScript. You can just import someone's widget and user it in markup. Check out the elements on http://webcomponents.org
Oh yes you can, there are many examples of individual components and I made one aggregating some of those in https://picnicss.com/ , but of course it has its limitations and tabs for example are deprecated as the HTML in those becomes funny/fragile. Modal and responsive nav are in the limit of what I consider sane enough to be in the default library.
Semantic-UI is my favourite front-end CSS website, I have built several websites with Semantic-UI, and I love it, feel delightful when developing with Semantic-UI.
Co-worker here, yeah, truly some pages of the site are not yet quite responsive, sorry for that, we plan to improve it in the future. On the site there are some particular templates designed to show the responsiveness or non-responsiveness, you could open them on smart phone or desktop computer to see the differences:
Semantic-UI gives more freedom for features like responsiveness, theme customization with 3000+ variables, although the default configurations are also very good.
Oh，yeah, it's set to be like so in the HTML's header, so you could see the whole webpage's layout like on a computer, we are going to improve the responsiveness soon. For developers who want to apply some themes and templates to build their websites, it may be useful. Thanks for visiting!
I think the layout issues go beyond not being responsive. I usually don't mind at all to just center on the main article text and read in the general layout. However, the article layout assumed such a huge screen width that it's impossible to read on an iPhone without coming in and manually dragging left and right as you read.
Just a piece of adv bro, this thread is full of advertising. If you didn't mention it nobody would care, but now that you used the word your post sounds terrible.
I've been incorporating it into https://www.findlectures.com as well, and it's been great. I'm slowly moving pieces from Bootstrap to Semantic UI, and they work surprisingly well together.
Semantic recently adopted my team's React adaptation as their official React port. It's lighter weight, eliminates jQuery, and all components are standard React components that can be extended or dropped in as-is.
I've been looking for a replacement for Bootstrap since it's been alpha for ages and it doesn't look like there is any interest in an official React implementation. So this might be it, I'm going to give it a try :)
Yes I did, thanks, I've also checked out: https://reactstrap.github.io
They're both building on top of the v4 alpha, which feels like a sinking ship indeed. Though it could all change ofcourse, they are also updating the official themes to v4 so maybe we'll see an official release this year after all. But then again, it might be too late ready...
Over the years I've gotten an incredible amount of value out of bootstrap and 3 has been great but the uncertainty over 4 and the huge delay has made me start seriously looking at alternatives over the last few months.
Semantic and Foundation are both on my list of things to look at.
and well documented, thank you for that ! using it right now.
Though it is for a private project. I'm not sure I will use it on a professional job due to the size of the css. I spend a lot of time importing things and I'm never sure how much weight and runtime complexity is being added.
It has a nicely designed DatePicker [1]. Semantic UI doesn't currently have an official implementation of a Date Picker (although there are unofficial versions on GitHub).
When I click that link I get a blank page with a spinner saying "loading docs" for several seconds before anything actually loads... and it's just a bunch of static text content.
Why does it take several orders of magnitude too long to load? Makes me very concerned to implement it in any production application of my own.
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 <b> <font> <blink> tags.
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).
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.
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.
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.
> 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.
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.
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. <b>, <font>, 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 <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.
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.
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.
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.
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.
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.
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.
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":
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.
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:
> 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.
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.
> 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).
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.
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?
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.
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.
When I started Picnic CSS[1] there were few CSS libraries out there and the ones that were available were severely lacking. They didn't have either :hover or :active states, no transitions, etc.
Now with new libraries or modern versions of those, including Semantic UI, I wonder whether it's time to stop supporting it and switch to one of those. They are still different but with somewhat similar principles (at least compared to others) such as the grid: <div class="flex two"><div></div><div></div></div>.
What I want to say, kudos. As I see jlukic answering some questions, how do you find the time/sponsorship to keep working on it? Is it a personal project, company project, funded through some external medium, etc? I see there's a donate button, does people contribute there a lot?
I haven't really seen Picnic CSS in the wild (only here https://gyshido.com/ and in my own projects) so I actually have no idea on adoption, which is one of the main decision points. I will probably keep using Picnic for most of my projects.
My two main alternatives are Materialize CSS for mobile because of the styles ( http://materializecss.com/ ) and Semantic UI for quick mock-ups/prototypes because of how complete it is (while looking way better than Bootstrap). Another "alternative" (not for CSS but for the type of projects I do) is https://html5up.net/ since they are really well designed when personalization is not so important.
Semantic has replaced Bootstrap as my go-to web framework. I find it more natural, and the default components are nicer. I think it needs a larger theme ecosystem and more consistent documentation, but I appreciate all the work that has gone into it.
(Click the small paint icon in the top menu to swap themes to see in native SUI)
I did a meteor dev night where I talked about some of the ideas behind Semantic UI, which might clear up some of the linguistic origins for the library and it's ideas about language:
https://www.youtube.com/watch?v=86PbLfUyFtA
Fantastic work. Our company use Semantic-UI for pretty much every project, as do I privately. A pleasure to work with, way above other frameworks I've used.
Personally I have chose Semantic UI as my go-to css framework over bootstrap. While bootstrap performs better on mobile, SUI is way nicer/cleaner it therefore eliminates the need to customize anything which I think is one of the reasons that someone would use a css framework in the first place.
I've been a Bootstrap user for years on all my web apps, but thinking that perhaps instead of re-learning things for v4, I look at expending a similar amount of time and effort to learn something new.
I came across Semantic-UI last year and remember being impressed by it, but for some reason it just slipped my mind until I saw this post today. I seems it could work for another small project that I am thinking of starting.
Just to clarify - No reliance on jQuery with this framework, right? Has anyone else worked with Semantic-UI using Umbrella.js and/or Intercooler.js ??
Ah, thanks for the clarification... A bit surprised that libraries written within the era of mobile devices etc. still have that dependency. Not a put down of jQuery per se - it was a great toolkit in its day.
I love the style and components of Semantic UI, but it's really heavy in terms of CSS file size, even once minified. I'd recommend running UnCSS or something similar on it before deployment.
I use Semantic UI in production on https://partsbox.io/ and can list some upsides and downsides.
On the positive side:
* very complete, with good form styling, and lots of widgets you will use often, which is especially important for larger apps,
* the default theme is mature and has good usability, without the crazy "oh, how flat and invisible our UI is!" look.
* the class naming plays well with React (I use ClojureScript and Rum) and looks good in your code,
On the negative side:
* the CSS is huge and there is little you can do to trim it down,
* the JavaScript code is not Google Closure-ready, so it's a drag compared to my ClojureScript codebase: large and unwieldy,
* there is a jQuery dependency, so I have to pull that in, too,
* the build system is… well, strange, let's put it that way. I'm used to typing "make" and getting things built, while this thing here insists on a) painting pretty pictures in the console window, b) crapping node_modules in a directory up from the one I'm building in, c) requires interactive feedback. I still haven't found a way to automatically build Semantic UI from a zip/tarball, and others seem to struggle with it, too.
Overall, I'm happy with the choice and it has been serving me well.
Cool, just today I was just looking for something like sematic/bootstrap.v4 that works well with clojurescript, do you have any suggestions? Have you had any issues pulling in jquery alongside react?
No, no issues apart from the dead weight (jQuery can't be compiled with Google Closure advanced optimizations either). jQuery is almost invisible, you only notice it sometimes because of the `js/$` appearing in your code, as in the common idiom: `(-> state rum/dom-node js/$ (.popup popup-params))`.
they added a new silent install feature in version 2.2:
"We've added a new semantic.json setting autoInstall which allows for silent install when Semantic UI is used in CLI environments, making testing more streamlined."
I'm trying that out, and it seems that jquery is installed when you include the Semantic UI CSS. According to the docs: http://react.semantic-ui.com/usage, you need to install the CSS separately with
$ npm install semantic-ui-css --save
and with that I get
├─┬ semantic-ui-css@2.2.10
│ └── jquery@3.2.1
Plus a whitescreen because jQuery is not defined...bummer
As one would expect with a fully featured framework, it does add some weight. I have a basic form project I'm working on that just uses some basic styling and components that I hand coded and the production JS and CSS (after gzip) are ~70k and ~2k respectively.
After including Semantic UI and dropping an example form component in, it jumped up to ~140k JS and ~93k CSS.
No, and I probably should write up an experience report. The short version is that ClojureScript is fantastic and I would never have been able to create PartsBox without it.
The long version is of course more nuanced :-) But there are surprisingly few downsides to using ClojureScript.
I chose Semantic UI for my project: https://suitocracy.com if anyone wants to see another live example, it also uses the default theme.
Like others, I was somewhat concerned about the bloat - over half of my front page's total file size. But at about 250KB all up, I realised this was only around a tenth of what the average website throws at people these days. https://www.wired.com/2016/04/average-webpage-now-size-origi...
256 comments
[ 3.1 ms ] story [ 220 ms ] threadWhy not? Who cares what your class names are?
What if in the future you decide to switch from Semantic UI to something else?
Now, I just kind of live with the ".col-md-12" business...
But in addition, there also seems to be much more compact HTML. I don't know if that is actually the case.
Compare:
<button type="button" class="btn btn-primary"> Primary </button>
<button class="ui button"> Follow </button>
or
Semantic UI:
<div class="ui breadcrumb"> <a class="section">Home</a> <div class="divider"> / </div> <a class="section">Store</a> <div class="divider"> / </div> <div class="active section">T-Shirt</div> </div>
Twitter Bootstrap:
<ol class="breadcrumb"> <li class="breadcrumb-item active">Home</li> </ol> <ol class="breadcrumb"> <li class="breadcrumb-item"><a href="#">Home</a></li> <li class="breadcrumb-item active">Library</li> </ol> <ol class="breadcrumb"> <li class="breadcrumb-item"><a href="#">Home</a></li> <li class="breadcrumb-item"><a href="#">Library</a></li> <li class="breadcrumb-item active">Data</li> </ol>
Edit: just checked, and yes it does. Also breaks the pattern where iOS shrinks the address bar and navigation bar when you scroll down. Completely unacceptable for a UI library to break these OS-level patterns
Didn't know about that. Thanks!
Fixed the scroll issue in the docs. Should be glorious normal iOS scroll.
Rather atypical for this kind of showcase.
Not an issue with the library (other pages besides homepage are fine), probably an issue with the gradient animation at the top of the homepage. I'll try to add a fix.
Here I am, using a phone more powerful than my desktop, and basic UI elements are still lagging.
Don't get me wrong - the project looks nice and solves problems in its domain, but I still feel we've made a seriously wrong turn somewhere that made us end up with UIs on the web...
Why is this on HN frontpage?
I want to like it, a lot. But I can't help feeling that this ship sailed years ago.
Simple UIs that are easy to interpret are a thing of the nineties. We left them because we evidently didn't realize what we had. Also, people like flashy things. A lot.
I've had a few javascript 'settings' fail to make it all the way to my Ember components, but in general these were bugs that were promptly fixed in newer versions. Docs are pretty good too.
I kind of like it. It's been pretty nice to just have a dropdown, a button, a label, a whatever out of the box without me having to figure out all the CSS tricks for mobile or various browsers. And the more I've used it I've been able to craft my own visual components upon its foundation that conform to a consistent style.
[1] http://semantic-org.github.io/Semantic-UI-Ember/
It's integrated with React and there's a separate mobile UI for it. Ant is Chinese, with docs translated into English. Like China, it's huge^^ I've just been fooling around with it today for the first time in create-react-app and seems good so far. Haven't tried on mobile.
I also couldn't find css classes just for coloring text in the docs anywhere which kinda made me sad, but wasn't too hard to add a couple to my baseline css. I just wish there were a text-primary class or something (is there one that I missed?)
Some mobile glitches with Ant, but I'm considering trying it. I only need a few components
However, don't use it on mobile - it will destroy performance.
There is even performance debugging built in, so you can monitor how your app performs.
If you ignore the debugger and just build insane things, of course it's going to be slow...
Semantic UI is something I personally use for a few projects, but I really wish some of this stuff didn't require so much javascript and was more encapsulated like Tachyons [1]. The main problem I've encountered when using Semantic UI is that it becomes difficult to change the prebuild components significantly.
[1] http://tachyons.io/
We have spent hundreds of hours build a new website with Semantic-UI for Semantic-UI: http://semantic-ui-forest.com/.
Semantic-UI is my favourite front-end CSS website, I have built several websites with Semantic-UI, and I love it, feel delightful when developing with Semantic-UI.
But compared with Bootstrap, the ecosystem of Semantic-UI is small, so we have semantic-ui-forest for you: http://semantic-ui-forest.com/posts/2017-04-05-introducing-s... .
In this website, we have ported 16 themes from bootswatch(bootstrap) to Semantic-UI (http://semantic-ui-forest.com/themes), and also, we have ported 18 official bootstrap examples (https://getbootstrap.com/getting-started/#examples) and reimplemented in Semantic-UI (http://semantic-ui-forest.com/templates/).
Not advertising, however, we think this maybe helpful for people who are interested in Semantic-UI and want to give it a try.
http://semantic-ui-forest.com/templates/bootstrap/grid/
http://semantic-ui-forest.com/templates/bootstrap/navbar-fix...
http://semantic-ui-forest.com/templates/bootstrap/non-respon...
Semantic-UI gives more freedom for features like responsiveness, theme customization with 3000+ variables, although the default configurations are also very good.
A SEO expert walks into a bar, bars, pub, public house, Irish pub, drinks, beer.
Case insensitively and including partial matches, 14 times.
Semantic-UI is literally "spam", in its original meaning.
https://react.semantic-ui.com/
https://github.com/react-bootstrap
However, there is the bigger problem that bootstrap feels more and more like a sinking ship.
Semantic and Foundation are both on my list of things to look at.
Though it is for a private project. I'm not sure I will use it on a professional job due to the size of the css. I spend a lot of time importing things and I'm never sure how much weight and runtime complexity is being added.
Settled out with trying http://ant.design/ which has actually been pretty nice as well.
Seems most React components libs are material design and I can't stand the look.
It has a nicely designed DatePicker [1]. Semantic UI doesn't currently have an official implementation of a Date Picker (although there are unofficial versions on GitHub).
[1] https://ant.design/components/date-picker/
Ant is good at making the css importable module by module using webpack. Semantic ui could adopt this approach too.
Have you had mobile problems with Ant? Seems a touch buggy there
Why does it take several orders of magnitude too long to load? Makes me very concerned to implement it in any production application of my own.
0. https://css-tricks.com/semantic-class-names/
1. https://www.w3.org/QA/Tips/goodclassnames
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.
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
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.
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.
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.
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?
[1] http://mrmrs.io/writing/2016/03/24/scalable-css/
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 }".
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.
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.
Well isn't the point here that you'd only have to modify the HTML, leaving the CSS alone for the most part?
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.
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.
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.
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.
https://semantic-ui.com/modules/dropdown.html#selection
- 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
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 find
much cleaner than 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.
>> 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.
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
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 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.
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?
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Now with new libraries or modern versions of those, including Semantic UI, I wonder whether it's time to stop supporting it and switch to one of those. They are still different but with somewhat similar principles (at least compared to others) such as the grid: <div class="flex two"><div></div><div></div></div>.
What I want to say, kudos. As I see jlukic answering some questions, how do you find the time/sponsorship to keep working on it? Is it a personal project, company project, funded through some external medium, etc? I see there's a donate button, does people contribute there a lot?
[1] https://picnicss.com/
My two main alternatives are Materialize CSS for mobile because of the styles ( http://materializecss.com/ ) and Semantic UI for quick mock-ups/prototypes because of how complete it is (while looking way better than Bootstrap). Another "alternative" (not for CSS but for the type of projects I do) is https://html5up.net/ since they are really well designed when personalization is not so important.
Everything seems fine, but as others have said, the scrolling is jumpy. Might want to fix that :)
1. http://usewing.ml
(Click the small paint icon in the top menu to swap themes to see in native SUI)
I did a meteor dev night where I talked about some of the ideas behind Semantic UI, which might clear up some of the linguistic origins for the library and it's ideas about language: https://www.youtube.com/watch?v=86PbLfUyFtA
And if anyone wants to dig really deep, there are a few podcasts as well https://changelog.com/podcast/106 https://changelog.com/podcast/164
Besides, I don't like github's black navbar.
I came across Semantic-UI last year and remember being impressed by it, but for some reason it just slipped my mind until I saw this post today. I seems it could work for another small project that I am thinking of starting.
Just to clarify - No reliance on jQuery with this framework, right? Has anyone else worked with Semantic-UI using Umbrella.js and/or Intercooler.js ??
On the positive side:
* very complete, with good form styling, and lots of widgets you will use often, which is especially important for larger apps,
* the default theme is mature and has good usability, without the crazy "oh, how flat and invisible our UI is!" look.
* the class naming plays well with React (I use ClojureScript and Rum) and looks good in your code,
On the negative side:
* the CSS is huge and there is little you can do to trim it down,
* the JavaScript code is not Google Closure-ready, so it's a drag compared to my ClojureScript codebase: large and unwieldy,
* there is a jQuery dependency, so I have to pull that in, too,
* the build system is… well, strange, let's put it that way. I'm used to typing "make" and getting things built, while this thing here insists on a) painting pretty pictures in the console window, b) crapping node_modules in a directory up from the one I'm building in, c) requires interactive feedback. I still haven't found a way to automatically build Semantic UI from a zip/tarball, and others seem to struggle with it, too.
Overall, I'm happy with the choice and it has been serving me well.
"We've added a new semantic.json setting autoInstall which allows for silent install when Semantic UI is used in CLI environments, making testing more streamlined."
It also allows to pick individual components, to reduce the CSS file size.
http://react.semantic-ui.com/introduction
After including Semantic UI and dropping an example form component in, it jumped up to ~140k JS and ~93k CSS.
The long version is of course more nuanced :-) But there are surprisingly few downsides to using ClojureScript.
Like others, I was somewhat concerned about the bloat - over half of my front page's total file size. But at about 250KB all up, I realised this was only around a tenth of what the average website throws at people these days. https://www.wired.com/2016/04/average-webpage-now-size-origi...