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.
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.
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.
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.
> 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 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.
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.
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.
> 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?
> 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.
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.
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.
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 }".
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.
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"
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.
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.
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.
I find that this is such a superior approach for certain websites. If a site has a large number of secondary pages designed around totally different content, the "only touch the stylesheet" seems to lead to despair.
I've seen people crap out things like #aboutPage #mainContent p:nth-child(2) div button {styles go here} ... because they follow the "separation" concept blindly. And then, you know, a paragraph gets added in later. Made up example but you get the point.
That W3 tips link is a decade old and not in any way normative. Appealing to it's authority is silly IMO and talking about semantic CSS like one does semantic HTML is even sillier as semantic CSS doesn't exist in the HTML sense.
I know, all these users viewing source and getting excited about the semantic HTML classes. HTML classes are for devs so let's use them how we see fit. I don't even think screen readers take into account HTML classes. While semantic class names (odd term -- even presentational names have meaning) is a recommendation, in practice, it actually works against you.
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.
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.
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.
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."
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))`.
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.
(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.
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.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
Quicker is an adjective, used to describe nouns. You could say "design quicker websites", "quicker" in that case describing an aspect of the website. If you wanted to describe the manner in which you will do the designing, you have to use the adverb "quickly"-- "design websites quickly". Adding the adverb "more" to modify the adverb "quickly" is the proper way to make it comparative.
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.
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 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?)
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.
Please stop with these things. They're never fit for purpose, and now there's another thing that looks - to non technical people - like a panacea for all development woes. Designers will never follow your constraints. Managers will never understand why this hasn't magically reduced our estimates by 90%. And yet again, it's just "developers being difficult" because there's a bunch of guys in India who say they CAN work with this for half the price.
Nobody is forcing you to use it. I don't use these libraries anymore, but that doesn't mean they don't have a purpose. And no, people shouldn't 'stop with these things'. You shouldn't be the one telling people what they should and should not be doing. You don't have to like it, but there are many developers who are really bad at styling. They don't have a good eye for design and they're trying to build a usable product, or they have an internal need, or want to learn. Libraries such as these have many purposes, even if you don't like them.
I have also had the misfortune of explaining to my PM and designer that the framework they chose heavily limits our ability to colour outside the lines.
These kitchen-sink CSS frameworks get you started quickly but it's incredibly difficult to override any one aspect of them. This comes off as a blessing while building out your initial design, but ultimately any team with enough design and development resources is going to want some custom UI/UX elements and what would ordinarily take half a day to build requires an additional week to integrate without side effects.
The initial development velocity gives a false sense of progress, as it is followed with death by a thousand cuts.
Whenever the tech stack is chosen by a non-developer, the the above scenario inevitably plays out. That's why we offer a stack optimized for ease of onboarding, decreased overall complexity, and reduced technical debt. The clients who use our stack tend to have fewer problems down the line.
You're right, people need to stop coming up with all this stuff. I have an idea to end it: why don't we just take all the good parts of all the frameworks and leave out the bad parts and finally make one framework that everyone can use? DM to discuss.
(p.s. this is a joke! no need to actually DM me except for coffee)
Working on enterprise-level sites this stuff is essential, not useless. CSS modals are a solved problem, I don't feel like solving it again. Designers won't follow any constraints.
I dont agree with this. Just because semantic(or any other tool) does not work for you does not mean it should not exists. Semantic is a massive time saver as a small team trying to build a functional product, where the team cant afford to have a pure front end focused developer. As a 2 person team, I can get a lot of functional product out with Semantic. I would recommend semantic any day.
It might not work for you, but like I said, it does not mean it should not exist. Thats me trying to defend a framework that I absolutely worship.
However, I've used it in the past and the CSS size is _HUGE_, with no way to reduce it. We're talking about > 500KB of CSS (in my case, at least). The JavaScript is extremely bloated as well.
Honestly, being that heavy I wonder how anyone can use it. If your site is to be viewed by mobile users, adding 500KB just to style a few elements is unacceptable.
I'd much rather go with Bootstrap. It has the added benefit of having the majority of front-end devs know it, and you can buy or use a theme for free and make it look great.
A custom build with only the components you're using cuts the CSS size dramatically. You also get to specify your supported browsers, which can cut down the size as well. Finally, you don't have to use their javascript, and not every component requires it.
Somehow we were unable to reduce the file size to a sane level and we switch to another framework. I guess we needed some components and we had to load jQuery as well.
In any case, wouldn't it make sense for the default configuration to be suitable for the average project? 500KB is really something...
Sidenote: the https://en.bem.info/ website (mentioned in the first paragraph of text about Semantic UI) totally irritates me. Would you be so kind and explain with a single sentence what is the purpose of your website/platform/framework?
I recently dropped Bootstrap early in a project and switched to Semantic. I've been using it for a few months - so far it seems fantastic and much more "natural" to work with than Bootstrap. The gigantic set of components, and integration with both EmberJS and React make it even more amazing.
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...
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.
Why is bootstrap 4 taking so long to get to a final version? All that waiting is pushing me towards other libraries. But me, being primarily backend engineer, want a library that has a large community because I am not so skilled with frontend UI and want the possibility to find the help easily.
I wonder same as well. I am building something right now with v4alpha and I have not found any problems. Therefore it is a bit weird why don't they just call it 4.0 and be done with it.
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...
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.
Am I the only one that passionately dislikes the menus that require clicking on the hamburger icon? I'm okay with it in phone apps when used tastefully, but it seems like too many websites are adopting it now for no good reason. This trend is especially evident among the online Wordpress/HTML template communities and creators...
The worst is when, if you maximize the browser window, the hamburger menu expands into actual menu elements, but then if you resize the browser window to, say, half the width of your screen, it turns into a hamburger button with enough whitespace around it to display the hidden menu elements. Really, really hate that. The web was more usable 15 years ago.
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.
I have been using Semantic UI for a while now. Overall I love this framework. It has lots of essential components. I highly recommend it to lean startups who dont have enough expertise for designing and developing their own UI components.
But I do hate it for having weak and restrictive responsive queries.
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.
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.
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.
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
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).
"Semantic is a development framework that helps create beautiful, responsive layouts using human-friendly HTML."
Claims made without evidence can be dismissed without evidence.
I'm not singling out Semantic UI here except to say that usability studies validate beautiful, responsive layouts using human-friendly HTML.
Has anybody done a usability study to confirm any such claims?
Again, not singling out Semantic UI except to point out an opportunity. Semantic UI could be the first to quantify this by providing usability study support rather than just putting it our there.
We use semantic-ui at Highlyreco (https://www.highlyreco.com). Semantic is a CSS framework that we absolutely love. Cant recommend it enough. Semantic made it possible for 2 developers(non of us are front end focus engineers) to build out a fairly complex ui at Highlyreco. Semantic gives us the ability to iterate really fast on UI.
We probably would not exist without semantic. For earlier projects I used to use bootstrap. My opinion is that Bootstrap is good for designing landing pages and semantic is good for building user interface pages.
My company has been using SUI in production the past 3 years and it's been absolutely great, sure it is big, but that translates into flexibility and speed of development as well as having a production-ready framework that we know can handle anything thrown at it.
I've seen some mentions of jQuery, I don't think that's a bad thing at all - the framework uses the plugin system so fully that without jQuery, I'm sure the framework would be even bigger and less flexible. The added advantage is that other jQuery plugins work without adding anything.
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 guess it's as good of time as any to plug my project s.css[1], it tries to be the exact opposite of semantic ui. Class names are simply abbreviated properties such as .di-bl { display: block; }. It isn't meant to be used as a framework, but something that other frameworks can build upon (I will soon be releasing something that build on it).
Please no...just use React, Vue, Angular or some other sane data binding framework already. Don't mix logic and presentation. Your javascript code should never know about CSS classes, and ids and preferably not DOM-states either.
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.
There seems to be some sort of impedance mismatch CSS is _for_ developers give me .di-bl { display: block; }, make it easy to understand by just looking at the markup instead of having to having to dig into other files.
As a blind web developer, I want to like Semantic. My usual mode of developing HTML, once it's at the "I need to make this look good" stage, is "show it to my girlfriend and ask her various questions." She says things like "I wish X were a bit larger," or "Y should be blue," and pulling that off in Bootstrap is challenging. I can drop down to lower-level CSS, but have no clue how my changes interact with Bootstrap's defaults, or indeed if they take effect at all. I mean, I can tweak font sizes and hex codes, but at the end of the day they're all numbers, when what I want to do is say "No really, make this thing larger relative to these other things," not "make it 125%, with this hex code I scraped out of some color list and hope looks nice."
But, gods, buttons as divs. Maybe they're easier to style, but if I had a dollar for every time I couldn't use someone's site because they used a div as a button, then didn't do the several other things that <button/> gives you for free that make all the accessibility difference, well, I'd not worry about money ever again.
I'm glad to see that the homepage example at least uses <button/>, but then the rendering of the example isn't keyboard-focusable or actionable. Then, when I look at the actual code they're rendering, it's back to divs. So they're not even rendering their example code.
Can I use Semantic with the actual HTML elements that the divs are meant to style, so I can use the CSS class names some folks hate and derive their benefits to me, but still get the accessibility benefits of the tags? I'd read their docs and check, but I don't know if they're linked from the main page. I see links to 1.X/0.X docs, but I can't find a link to 2.X docs. There's a "Menu" link which may pop up more links, but I can't seem to trigger this with Enter. I seriously spent 10-15 minutes on this page looking for docs using only my keyboard, before deciding that I really had better ways to spend my day.
I hate to advise people to avoid projects because I'm not so arrogant as to think my language/stack/framework/whatever is anything other than my favorite, and I do want to like this one, but every time I look at it the accessibility story is disappointing, and given that it's a framework, that means other sites will likely inherit disappointing accessibility stories too.
And now it's back to drinking, which seems to be the only fix for this[1].
1. Not really, but damn am I tired of a) fighting the same battles again and again and b) answering the same questions about said battles again and again. All of this stuff is exhaustively documented by folks who are smarter than I am, so it isn't obscure, nor is it something I need to (or am even highly qualified to) answer.
Incredible, thanks for sharing your unique experience, I don't know the difference of <div class="ui button"> and <button class="ui button"> when I use Semantic-UI, because they show the same thing. According to your declaration, I think from now on I will better use the latter one.
1. The div is not keyboard-focusable by default, so you need to add `tabindex="0"`.
2. By default, the div does not trigger click on Enter/Space, so you need to add a keyup handler to make it do so.
3. Screen readers won't report the div as a button because they can't identify widgets based on how they look, so add `role="button"` as per the ARIA spec (only on first cup of coffee now, so I'm not providing a link.)
Yes, it isn't super complicated, but a) most don't do it because they look identical and b) multiply that by any other widget where the HTML version is replaced with a div and suddenly things get complicated. If you're not a keyboard user, you may not understand how the web works without a mouse. All that is lost when switching to divs.
This says nothing about how OS/screen reader combinations differ in key handling, nor about how complex widgets such as multiselects include similarly complex key handling. Also, the above ARIA is super simplistic. It doesn't handle situations where, for instance, you have multiple roles and have to toggle some of them based on what item is selected, what item is focused, etc.
So, TLDR: It's so much better to use the HTML elements specifically designed for a certain task because you get a lot for free that is taken for granted. That said, I like how Semantic specifies how my UI might look, an wish I could have the best of both worlds.
And a custom button is certainly not the worst offender, though it's probably the most commonly cited example. A blind friend just needed sighted help to complete a purchase, because the process included a custom checkbox with no ARIA support. At least with a button that's not identified as such, the user can figure out that it's a button from the name and context, and use their screen reader's ability to simulate a mouse click. Unless the buttons are implemented using spans rather than divs, and there's more than one of them in the same block element.
I have been using bootstrap exclusively for years. I will give this a try on a small throwaway project. I am concerned by the apparently large size of CSS and JS, based on other comments here.
Does anyone else feel that the documentation does not clearly explain how to create responsive layouts? I see the visual examples, but no clear code like in bootstrap's docs.
Sounds great in theory, but the dropdown box on the front page is a list where only half the height of the letters are shown, instead of a proper dropdown box.
I actually think the opposite. The names are very logical and once you know some the rest is quite logical. Bootstrap on the other hand never made sense to me.
Anyway many times I need SUIs documentation open for reference.
0. https://css-tricks.com/semantic-class-names/
1. https://www.w3.org/QA/Tips/goodclassnames