Semantic UI(semantic-ui.com)
semantic-ui.com
Semantic UI
https://semantic-ui.com/
256 comments
I used to think this way until reading this article by Nicolas Gallagher:
http://nicolasgallagher.com/about-html-semantics-front-end-a...
These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards.
If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.
Your HTML documents are already coupled to your project, so rather than writing CSS that's coupled to that HTML, I've found it to work much better to author CSS from a mindset that the CSS knows nothing about the document it's trying to style.
This leads to writing what I call "library-style" CSS, where you are almost trying to build your own Bootstrap or similar; something that you could actually use on multiple projects if you wanted.
A class like "download-book" is not very useful if you have multiple buttons in a project that are meant to look the same way and not all of them trigger a book download.
http://nicolasgallagher.com/about-html-semantics-front-end-a...
These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards.
If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.
Your HTML documents are already coupled to your project, so rather than writing CSS that's coupled to that HTML, I've found it to work much better to author CSS from a mindset that the CSS knows nothing about the document it's trying to style.
This leads to writing what I call "library-style" CSS, where you are almost trying to build your own Bootstrap or similar; something that you could actually use on multiple projects if you wanted.
A class like "download-book" is not very useful if you have multiple buttons in a project that are meant to look the same way and not all of them trigger a book download.
I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation.
I find
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 find
// style.scss
@mixin button($color, $size) { ... }
.download-book {
@include button(
$color: red,
$size: big
);
}
.send-email {
@include button(
$color: blue,
$size: small
);
}
// index.html
<button class="download-book">Download book</button>
<button class="send-email">Send email</button>
// style.scss
.button { ... }
.red { ... }
.blue { ... }
.big { ... }
.small { ... }
// index.html
<button class="button big red">Download book</button>
<button class="button small blue">Send email</button>
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.
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.
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":
[0]: https://github.com/css-modules/css-modules
css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr":
[0]: https://github.com/css-modules/css-modules
I 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.
>> 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.
that misses the point.
parent described things like moving the navbar to the left when the html can have it before or after the content on the dom. can you use float:left?
parent described things like moving the navbar to the left when the html can have it before or after the content on the dom. can you use float:left?
Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style:
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.
<div class="red pull-left pb3">
<div class="grid row">
<div class="col-xs-4">
<div class="basket">
<div class="product">
<div class="searchResults">
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.
You could look at "basket", "product", and "searchResults", except that it tells me absolutely nothing as a dev about what it looks like. You shouldn't be using your CSS classes to tag sections, that's what id is for. And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.
> except that it tells me absolutely nothing as a dev about what it looks like.
That's because it shouldn't be.
> You shouldn't be using your CSS classes to tag sections, that's what id is for
No, you might can have multiple "products" on the page.
> And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.
Absolutely none of this true if you use Sass (or an equivalent) properly.
That's because it shouldn't be.
> You shouldn't be using your CSS classes to tag sections, that's what id is for
No, you might can have multiple "products" on the page.
> And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.
Absolutely none of this true if you use Sass (or an equivalent) properly.
> That's because it shouldn't be.
Why not? Who's reading my HTML? It's not there to be read by a user. HTML is for devs. They're the ones that deal with it.
> No, you might can have multiple "products" on the page.
True, in that case you would use a CSS class with no styling if you need code to select the block.
> Absolutely none of this true if you use Sass (or an equivalent) properly.
It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).
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.
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.
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.
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.
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.
There is no way for you to mess up something at the other end of your web app if you use specific sass files for specific web pages. The 'basket' class can be defined as one thing on the page for selling baskets, and it can be defined completely differently on some other page where baskets are, idk, displayed in some other way.
Single Page Applications. Reusable components. Both of these make CSS harder to manage, and semantic classes start becoming a problem.
Please elaborate. I don't see how having a library of SASS mixins that you mix in to make specific CSS classes for specific purposes make anything harder to manage? If anything, decomposing things to smallest common denominator makes it easier to build better and more versatile CSS for your apps.
It's not the sass mixins that makes things harder to manage. The problem is having nested CSS rules that cause your CSS to become tightly coupled to the structure of HTML. Then when the HTML changes, you have to rethink the relationships. And if you're not using nesting, then isn't what you described just utility classes abstracted one level away?
> 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.
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.
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.
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.
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).
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.
CSS classnames are purely for the developer's benefit. Not the user's. And as developers, forcing ourselves to find semantic meaning for every element we write leads us to component-oriented CSS like BEM. Which is a fine thing, but we can also use purely visual classes - like `bg-red bold border-solid` if it helps (and it does. check out tachyons.io)
The class names of elements in Google's homepage for example reads like 'tsf-p', `oq`, `gsb` etc. I suspect these are machine generated. Same with Facebook. One of the best libraries to do this currently is styled-components (https://github.com/styled-components/styled-components).
Consider reading http://nicolasgallagher.com/about-html-semantics-front-end-a..., http://mrmrs.io/writing/2016/03/24/scalable-css/, and http://johnpolacek.com/2016/06/17/atomic-css-movement/ for reasoned perspectives.
I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single source of truth) without rummaging through our entire codebase to modify appearances of things (separation of concerns).
When I first discovered csszengarden.com, I realized the point of CSS and its power. HTML was made for hypertext and semantic content structure and CSS was made for appearances. Either one could be completely replaced partially or wholly, separate of each other. Classes are like interfaces[0] which allows for HTML to remain dumb and decoupled from presentation. When the HTML and CSS are hardcoded to specific design concepts themselves, then the usefulness of CSS as in "cascading style sheets" is nearly eliminated. These concepts aren't a fad, this is good software architecture brought to you by an international consortium who's been thinking about it for decades.
0. https://en.wikipedia.org/wiki/Dependency_inversion_principle
When I first discovered csszengarden.com, I realized the point of CSS and its power. HTML was made for hypertext and semantic content structure and CSS was made for appearances. Either one could be completely replaced partially or wholly, separate of each other. Classes are like interfaces[0] which allows for HTML to remain dumb and decoupled from presentation. When the HTML and CSS are hardcoded to specific design concepts themselves, then the usefulness of CSS as in "cascading style sheets" is nearly eliminated. These concepts aren't a fad, this is good software architecture brought to you by an international consortium who's been thinking about it for decades.
0. https://en.wikipedia.org/wiki/Dependency_inversion_principle
There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments.
Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup changes tend to be more expensive (you can't just move a block of HTML from one place to another and not expect its appearance to change).
These days though, we're increasingly building things in a UI-oriented way. What you see on the page is a composition of a number of components. If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. So now i'm authoring CSS that is bound to the structure of this component, naming becomes a lesser issues. The other thing worth pointing out is that it's not too difficult to built a document-UI (like say a magazine) using app-UI patterns, but it's rather challenging to do it the other way around.
If the goal is maintainability, then there should be zero industry-wide dogma. Best practices are going to be coupled to the methodology of the maintaining team. Personally, I did document-oriented CSS for 15 years, now i'm doing component-oriented CSS, and the results are much better. Obviously this is just an anecdote, but i'm not alone in this.
This idea that design is a "layer" on top of structure is somewhat offensive to the designer in me. Visual design is (and should forever be) coupled to structure and behaviour. Design is not a higher abstraction, it's something that pervades everything.
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.
What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML?
We use components everywhere. We style in stylesheets. Handily we even keep the stylesheets in the same component as the module, thanks to npm-sass / sass-npm.
Sorry, i'm struggling to follow what you're asking here.
Whether you style in stylesheets or by some other means (CSS-in-JS?) is an implementation choice rather than something that affects the fundamental pattern. If your components are truly portable, you're already doing things the way I suggest. If they inherit things like fonts and colors from their parent via the cascade rather than via explicit properties, then you don't have truly portable components - their appearance will change when you move them around.
Whether you style in stylesheets or by some other means (CSS-in-JS?) is an implementation choice rather than something that affects the fundamental pattern. If your components are truly portable, you're already doing things the way I suggest. If they inherit things like fonts and colors from their parent via the cascade rather than via explicit properties, then you don't have truly portable components - their appearance will change when you move them around.
> Whether you style in stylesheets or by some other means (CSS-in-JS?)
We're specifically talking here about putting styling logic - "left" "shiny" "big" etc - in HTML.
> is an implementation choice rather than something that affects the fundamental pattern.
Sure, you can still use a component pattern with styling split into HTML and stylesheets - it certainly doesn't effect the pattern.
The issue is: when you want to change the appearance of your component, do you want to modify styling logic in two places or one?
We're specifically talking here about putting styling logic - "left" "shiny" "big" etc - in HTML.
> is an implementation choice rather than something that affects the fundamental pattern.
Sure, you can still use a component pattern with styling split into HTML and stylesheets - it certainly doesn't effect the pattern.
The issue is: when you want to change the appearance of your component, do you want to modify styling logic in two places or one?
One, that's why I style inline :)
Do you mean inline in CSS / style tags, avoiding visual HTML classes (in which case we're in agreement - there's one way to edit how something looks, though style tags have other issues) or combining either of those with visual HTML classes like this library uses?
Okay, I think we're in agreement and are just crossing wires a but. The main reason i'm loosely okay with Semantic UI is that I just see it as using HTML fragments as building blocks rather than using JavaScript components. I wouldn't advocate it for anything elaborate, but I think it can work well within a certain problem space.
I'm not sure you read the articles GPP mentioned, yes CSS Zen Garden was the dream, but I feel like articles like the excellent mrmrs one [1] address the reality.
[1] http://mrmrs.io/writing/2016/03/24/scalable-css/
[1] http://mrmrs.io/writing/2016/03/24/scalable-css/
> The reason we need semantics in HTML is to make the markup accessible for screen-readers
Not sure about the screen-readers but when you add a class for, say, "small", it's a bit confusing because you can't guess how it is used when looking from the CSS side. One day, you decide to represent the unimportant text as grey (bad idea) and then you need to find all instances of .small that are used for the unimportant content and change them to .grey (then you discover there already is a class named gray, oh the horror) whereas if you used .unimportant as a class name, your change would be a single line of CSS. Also, "h1 .unimportant { color: something-not-grey }" is way clearer than ".bold.big .small { color: something-not-grey }".
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.
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.
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"
Author of SUI here again.
Semantic is based on the idea that describing physicality (the function of html/css) is a task natural language is acutely optimized for, while describing the implementation of behavior ("cooking recipes", or the vast majority of programming implementation) is best served by programming languages.
Part of how natural language optimizes for transmitting meaning is by reducing ideal forms of concepts to words based on the exact amount of specificity for conveying meaning between humans. I.e. "horse" instead of "quadrupedal mammal that has a heart and has eyes and has a tongue..." etc.
These 'units of optimized human idea transmission' (read words) are then clarified using a system of modifiers that take care of removing just enough ambiguity that the idea is communicated effectively. "The kindly, gentle lion", "The angry, hungry lion".
The modifiers themselves carry no absolute meaning. A "large ant" may be smaller than a "small planet", but we understand them -- in context -- of the nouns.
Language is littered with other interesting features like this that are designed particularly for this task of describing physicality. Most of which are absent from programmatic implementations of 'languages for describing physicality' like HTML/CSS.
Other key examples of useful cognitive optimization: Plurality, "Three large red buttons" vs "Large red button, large red button"; significant word order, "left floated right aligned column" vs "right floated left aligned" column.
I think the main drawback with using a natural language approach is that the implementation has to be bullet proof. Although everyone uses language, we never have to implement systems of interpreting language from phoneme to neuronal pathway. So even though the benefits are clear, the path forward in mapping language to systems of programmatic physicality isn't exactly straightforward.
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.
When I first heard about Semantic UI, I was excited because I had hoped someone had finally built something like Bootstrap using only Sass/Less mixins that were pure and side effect free (i.e. not littering the global namespace with generically named classes, not dependent on the structure of the HTML). I was disappointed that was not the case and frustrated with the confusion of the usage of "semantic" when its already widely adopted to mean something specific for HTML.
I really wish UI libraries were built on mixins. Pure mixins would allow for reusable component styles and modifiers such as "three large red buttons" to be mixed into semantically-named CSS classes such as "user-controls." Additionally, mixins would allow for media query usage (e.g. I could use a "big red button" for desktop and "small red button" for mobile), allow for more selectiveness about which components/modifiers I want to use (which may reduce the overall size of the CSS), allow for conditional styling logic, and generally be easier to work with in a CSS preprocessor. This facilitates all the goals you've mentioned while being more flexible, open to extension and enabling us to stick to the way HTML/CSS was meant to be used. Maybe you've already considered all of this and have your reasons for not pursuing it. I'm sure it would be much more work to go that way now regardless, although it seems Bootstrap 4 has started heading in that direction.
They also use <i> tag for icons.
<div class="ui icon buttons">
<button class="ui button"><i class="bold icon"></i></button>
<button class="ui button"><i class="underline icon"></i></button>
<button class="ui button"><i class="text width icon"></i></button>
</div>
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.
Is that a problem, give em/strong cover b/i these days?
Also, it uses this instead of <select>:
<div class="menu" tabindex="-1">
<div class="item" data-value="ad"><i class="ad flag"></i>Andorra</div>
<div class="item" data-value="ae"><i class="ae flag"></i>United Arab Emirates</div>
<div class="item" data-value="af"><i class="af flag"></i>Afghanistan</div>`<select>`s aren't styleable so you have to do a select proxy.
They are, to some extent at least, depending on what browsers you need to support. You have to set *-appearance: none and build the styles back up.
Thanks! More info for others: http://stackoverflow.com/questions/1895476/how-to-style-a-se...
Look at the second example:
https://semantic-ui.com/modules/dropdown.html#selection
https://semantic-ui.com/modules/dropdown.html#selection
Unfortunately there are some severe limitations of using native select, in particular in relation to list item (i.e. option element)
- Can't have anything but plain text: (e.g. no images, bold text etc)
- Can't have a line-break, or somehow wrap text into a 2nd line if entry is too long
- Can't have anything but plain text: (e.g. no images, bold text etc)
- Can't have a line-break, or somehow wrap text into a 2nd line if entry is too long
Keeping html independent from css would be nice thing for sure. But since reusable stylesheets from these libraries are used we need to have also stylesheets to be independent from html. When we have just 'two things' both of those really cannot be independent from each other. So some trade-off is must.
One interesting way I have tried is to add third thing. So I can create stylesheet with visual class names (or use 3rd party) and html with semantic ones. After this I create separated stylesheet-html mapping. In practise it's just a sass where I extend semantic classes with visual ones.
I haven't tried this yet on scale but it's very handy for example mapping icons at least.
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.
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.
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.
[deleted]
> you only have to touch your stylesheets instead of manipulating both the stylesheets and HTML.
Well isn't the point here that you'd only have to modify the HTML, leaving the CSS alone for the most part?
Well isn't the point here that you'd only have to modify the HTML, leaving the CSS alone for the most part?
I find that this is such a superior approach for certain websites. If a site has a large number of secondary pages designed around totally different content, the "only touch the stylesheet" seems to lead to despair.
I've seen people crap out things like #aboutPage #mainContent p:nth-child(2) div button {styles go here} ... because they follow the "separation" concept blindly. And then, you know, a paragraph gets added in later. Made up example but you get the point.
I've seen people crap out things like #aboutPage #mainContent p:nth-child(2) div button {styles go here} ... because they follow the "separation" concept blindly. And then, you know, a paragraph gets added in later. Made up example but you get the point.
That W3 tips link is a decade old and not in any way normative. Appealing to it's authority is silly IMO and talking about semantic CSS like one does semantic HTML is even sillier as semantic CSS doesn't exist in the HTML sense.
I know, all these users viewing source and getting excited about the semantic HTML classes. HTML classes are for devs so let's use them how we see fit. I don't even think screen readers take into account HTML classes. While semantic class names (odd term -- even presentational names have meaning) is a recommendation, in practice, it actually works against you.
If you break your HTML into partials using a template language or components with React, Vue.js, etc., you only need to update in one place as well.
This has always been my understanding as well. I've always tried to write HTML in a manner that would remove all presentational aspects to the point that I could redesign an entire site by changing the CSS only.
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.
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.
FYI: The React version - is jQuery free
http://react.semantic-ui.com/introduction
http://react.semantic-ui.com/introduction
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
├─┬ [email protected]
│ └── [email protected]
Sorted it, thanks to this: https://github.com/Semantic-Org/Semantic-UI-React/issues/114...
import 'semantic-ui-css';
import 'semantic-ui-css/semantic.min.css';
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.
After including Semantic UI and dropping an example form component in, it jumped up to ~140k JS and ~93k CSS.
The Angular integrations seem to still use jQuery, that is such a bummer for me personally, it's like a bad omen.
Yes, I recently learned about that version. I am not yet sure whether it fits well with my ClojureScript code.
You don't have to use their build system. I'm purely using the less version of Semantic, which is built as a normal less files.
It also allows to pick individual components, to reduce the CSS file size.
It also allows to pick individual components, to reduce the CSS file size.
[deleted]
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."
"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))`.
React Semantic UI doesn't have the jQuery dependency.
I also wanted to echo: cool project! Have you written about your experience using clojurescript?
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.
The long version is of course more nuanced :-) But there are surprisingly few downsides to using ClojureScript.
For people who are curious about theming here is classic GitHub done entirely in Semantic UI.
http://semantic-org.github.io/example-github/
(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
(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
For a minute I though I was looking at the real github and they finally got rid of that black bar. Well done! ;-)
haha, yep, this example shows the power of Semantic-UI, I was attracted by this---I was really amazed by the power of Semantic-UI.
Besides, I don't like github's black navbar.
Besides, I don't like github's black navbar.
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.
Are there decent options for themes out there? I really like what I see but my design talents are...lacking. :-)
Looks like their SSL cert is expired/bad.
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.
https://react.semantic-ui.com/
https://react.semantic-ui.com/
Thanks for your work on porting Semantic UI to React. I've used it in an internal application and it was a breeze to work with.
I've been using your react version with a personal project for a while and it's been really helpful, so thank you for your work.
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.
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 might have to try this out, too bad I didn't see this yesterday.
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.
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.
Ant looks really good as well!
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/
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/
I've been using react semantic ui for the last week and am thinking of switching to ant. Or going a la carte for everything.
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
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
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 :)
Have you used React-bootstrap at all? I've used it in the past and it's not bad. And is relatively well maintained.
https://github.com/react-bootstrap
However, there is the bigger problem that bootstrap feels more and more like a sinking ship.
https://github.com/react-bootstrap
However, there is the bigger problem that bootstrap feels more and more like a sinking ship.
Why does Bootstrap 4 feel like a sinking ship?
Because v4 has been in alpha since august 2015, and v3 hasn't had significant updates since 2015 either.
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.
Semantic and Foundation are both on my list of things to look at.
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...
The react port is top notch. I'm switching my app to it.
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.
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.
Thank you for the hard work done here! We make extensive use of your library, and love how well maintained and easy to use it is.
Can it be used with project that initiated with `create-react-app`?
Yep! I actually am using it in the sample project for my "Practical Redux" tutorial series: http://blog.isquaredsoftware.com/series/practical-redux/ . Also using it at work.
Hi, guys,
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.
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.
I hate to say this, but when I opened this with my smartphone, the layout was not responsive. So I closed it again
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:
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.
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.
I think it's not detecting my mobile as mobile. Motorola Play X here in Android, chrome
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!
The rendering is awful and somewhat irrational for all three links on my phone. Was that designed to show non-responsiveness?
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.
This site was released for just about one week, and yes, we know there're still many many problems, we will fix that as soon as possible.
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.
Really interesting and useful site for searching lecture videos of certain people or topics, bookmarked, thanks for sharing!
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.
This doesn't work well on mobile - on iOS at least... scrolling is funny, flickering screens, jerky inputs. Loading feels slow too - and I'm on wifi.
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.
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...
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?
Why is this on HN frontpage?
Why is this on HN frontpage?
Because its an otherwise very useful and good looking CSS library.
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.
If your site needs good mobile support, don't use it I guess, but I have never had any issues on my low end Alcatel Pixi 4.
[deleted]
It feels like they added their own smooth scrolling in. I barely scrolled and it shot to the bottom of the page in iOS.
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
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.
That one confused me, I thought "It's not working" but you actually have to press "Run Code" just above the snippet.
Rather atypical for this kind of showcase.
Rather atypical for this kind of showcase.
Better than the scrolling I had on iOS which was shaking up and down as it was semi scrolling. Thought I had one too many drinks.
The ever-useful "Request Desktop Site" fixes the site on iOS.
Nor with JavaScript disabled. I'm actually trying to figure out what it actually is.
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?
[1] https://picnicss.com/
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/
Sad I am considering to use picnicss in my next project. What you would recommend besides Semantic UI?
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.
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.
I used it, thanks for creating it!
> Design Beautiful Websites Quicker
* "...More Quickly".
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.
* "...More Quickly".
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.
Might also check out Ant Design.
https://ant.design/
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.
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 like that you can import just the css you need for a component. Semantic ui should do this too.
Some mobile glitches with Ant, but I'm considering trying it. I only need a few components
Some mobile glitches with Ant, but I'm considering trying it. I only need a few components
Semantic-UI does allow this. If you look in the build folder, it has CSS files for every component, and you can include whichever you need.
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 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?)
Been using this library and generally impressed. +1
Looks great! I wish the doc was fully translated though.
Wow Ant Design looks pretty great.
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.
However, don't use it on mobile - it will destroy performance.
Curious about this. Any clue why? Too much animation, heavy JS-use? Not familiar with how the framework does its stuff.
Only the size is an issue, the performance otherwise is great.
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...
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...
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.
It's 850k in size plus jquery.
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.
This sort of stuff is worse than useless.
This sort of stuff is worse than useless.
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.
But people will be forced to use it. That's my complaint.
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.
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)
(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.
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.
Not sure about your definition of "these things" -- are you including say Bootstrap, jQuery or Angular/React/Vue/etc.?
Spot on. Do we work at the same company? I deal with the exact same problems every day with our in-house component framework.
Wow, I wonder what happened in your childhood.
32,000+ stars is insane, how have I not heard of this? Does anyone have production experience with it?
It looks great.
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.
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...
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.
Wouldn't a semantic UI have things like a <menu> tag that was up to the browser to render?
What is the best way to think of this. Is this like Twitter Bootstrap and Zurb Foundation, or is this like something else entirely?
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).
"There are three of them" counts as functionality now?
[deleted]
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.
>>You don't want your final build to have a bunch of 'col-md-6' class names.
Why not? Who cares what your class names are?
Why not? Who cares what your class names are?
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...
Okay, no one has actually explained how Semantic UI overcomes this.
What if in the future you decide to switch from Semantic UI to something else?
What if in the future you decide to switch from Semantic UI to something else?
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...
Now, I just kind of live with the ".col-md-12" business...
Some people think bootstrap without dashes in the class names is better... or is there more to it?
Good question. From looking at it, it looks less, well, dashy.
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>
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>
From Semantic UI docs:
<div class="ui three column grid">
<div class="four wide column"></div>
<div class="eight wide column"></div>
<div class="four wide column"></div>
</div>
I think Google takes it one step further and minifies the CSS class names
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.
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.
It's alpha meaning the API will change most likely just be aware to check release notes as breaking changes are expected to happen.
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...
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...
Pretty neat looking and interesting site.
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 ??
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 ??
Semantic-ui does require jQuery. See https://github.com/Semantic-Org/Semantic-UI/issues/1175
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.
[deleted]
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.
[1] http://semantic-org.github.io/Semantic-UI-Ember/
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/
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.
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.
[1] http://tachyons.io/
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/
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
It may be possible, but it would be very difficult to make it accessible for screen readers, etc.
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.
https://www.nngroup.com/
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.
https://www.nngroup.com/
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.
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'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.
Just FYI,
https://www.zomato.com/ one of the biggest in it's industry uses Semantic-UI :)
Love the Framework and Jack + all contributors effort in it :)
https://www.zomato.com/ one of the biggest in it's industry uses Semantic-UI :)
Love the Framework and Jack + all contributors effort in it :)
Whoa! This is interesting. Just curious to know
- how did you decide to go with Semantic UI? - what all frameworks did you compare? - which preprocessor are you using?
- how did you decide to go with Semantic UI? - what all frameworks did you compare? - which preprocessor are you using?
I ain't working in Zomato :P
Got the info from this thread: https://github.com/Semantic-Org/Semantic-UI/issues/2449#issu...
Got the info from this thread: https://github.com/Semantic-Org/Semantic-UI/issues/2449#issu...
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.
We used Semantic UI for Startup School (https://startupschool.org) and it has been awesome. Really happy with the choice.
Nice! I am actually IN this round of Startup School, and I never noticed that it was built with this framework. Good work.
I love semantic UI. I'm using it now with my new project (serverboards.io) and it really was a huge time saver.
I would prefer it using sass, but the is a 'port' (https://github.com/doabit/semantic-ui-sass/tree/master/app/a...)
I would prefer it using sass, but the is a 'port' (https://github.com/doabit/semantic-ui-sass/tree/master/app/a...)
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).
[1] github.com/nwmcsween/s.css
[1] github.com/nwmcsween/s.css
> Intuitive javascript:
$('select.dropdown')
.dropdown('set selected', ['meteor', 'ember']);
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.
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.
Not every project needs to use React.
Sometimes you just want some quick JS for your one dropdown component that comes with the framework you're already using.
Sometimes you just want some quick JS for your one dropdown component that comes with the framework you're already using.
Semantic UI is really great! I suck at frontend design and it really helps me to make decent looking websites :)
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.
Checked it out, and it looks quite nice! Congrats on making such a nice tool. I'm a fellow CSS library author here, of Wing[1].
Everything seems fine, but as others have said, the scrolling is jumpy. Might want to fix that :)
1. http://usewing.ml
Everything seems fine, but as others have said, the scrolling is jumpy. Might want to fix that :)
1. http://usewing.ml
Anyone able to help explain to me how to use this with e.g. a simple static site?
i.e. hand written HTML (perhaps compiled from markdown) with no JS?
The manuals for semantic UI seem to jump strait into integrations with other frontend frameworks and build tools; but I don't want to use them.
i.e. hand written HTML (perhaps compiled from markdown) with no JS?
The manuals for semantic UI seem to jump strait into integrations with other frontend frameworks and build tools; but I don't want to use them.
I use it for small projects/pages just because it looks so good :) http://cryptologie.net/links
but I found it harder to get into compared to bootstrap/foundation.
but I found it harder to get into compared to bootstrap/foundation.
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.
Anyone else find the pages jitter when scrolling? At least on Safari (iPhone)
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.
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.
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.
Great sharing, it seems that HTML tags are safer and more robust.
This really broadens my mind, HTML tags have such functions, thanks, good to hear that.
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.
I work for quite some time now with Javascript and I must say:
$('select.dropdown').dropdown('set selected', ['meteor', 'ember']);
Is the most unintuitive Javascript I've ever seen.
$('select.dropdown').dropdown('set selected', ['meteor', 'ember']);
Is the most unintuitive Javascript I've ever seen.
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.
All this and it still looks like Yet Another Bootstrap website. Guess that's the modern meaning of 'beautiful website'.
There's a pretty bad bug on that website. When you open it in Safari on iPhone 6 it jitters badly as you scroll the page down.
I'd like to find a framework like this that comes with platform-neutral (handlebars or similar) templates for each component
I am starting a new project, and I am considering semantic UI and grommet. Anybody has experience with grommet?
The interface looks good but it is like a nightmare to remeber every single class.
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.
Anyway many times I need SUIs documentation open for reference.
I'm fine with Bootstrap though... another day, another framework
What makes the Internet so exciting is the direct opposite of this.
I love semantic UI React for my teams internal tools. So easy to drop in an use without having to think about css
[deleted]
0. https://css-tricks.com/semantic-class-names/
1. https://www.w3.org/QA/Tips/goodclassnames