No. Not at all.
OOCSS focuses on patterns that are reproduced in the page (or site) multiple time with little variation of look or positioning.
This is everything but that.
I agree. First of all, why is a ui class necessary? Second, what's large? The icon, the button, the label? All of it? What's red, the icon or the button? Certainly not both. There's a reason we have classes like "btn btn-small icon-* icon-2x". A large icon in a small button. I think those names are more 'semantic'.
Yeah that one was too specific for my liking I don't think you should use colors names like 'red' as a class. What if you decide you don't want it to be red?
This is a great idea, however the website needs some work I keep getting struck scrolling because the code boxes have overflow scroll on them. Also the navigation arrows at the top don't work :/
The bootstrap markup is actually more semantic than Semantic UI. Classes like large, red, floated, right, circular etc.. are presentational not semantic. If you want to use a framework and keep semantic CSS then look in to using the LESS/SASS version of Bootstrap or Foundation.
Edit: After a more detailed look, the framework is actually really nice (and very comprehensive). The name still doesn't make much sense though.
I don't understand this. It's CSS. Of course it's presentational. Do CSS class names have to describe the semantic structure, as well as the DOM structure?
No, it is about marking up the data (HTML) with labels that have a representation described in the CSS.
So the HTML should say "this is important" (em) while the CSS is free to define "important" as bold, different color or some other font change.
For example the HTML should not contain anything about number of columns. It will be 1 column on iPhone, 2 on iPad and 4 on Desktop - but the HTML does not change.
This is actually pretty regressive given the examples. This is the reverse of the attitude that brought us the <article> tag. I disagree that stuff like this should be in classes, so definitely not for me.
Yes, this EXACTLY. We need CSS libraries that encourage the use of new HTML5 tags. We're no longer living in a world of scrambled DIVs, we have a page structure to follow now. I feel as if this may even be a step backwards, just the third example code in which the Bootstrap version has button while the semantic version is a DIV makes no sense, it's a button, not a DIV.
Frankly, Bootstrap is exactly that, for me. I've been converting our products (Webmin/Virtualmin, which are 15 and 10 year old codebases, respectively, and it shows badly in the current UI). Converting to Bootstrap, while extremely time-consuming, is not requiring significant design skill on my part to make everything look freaking awesome.
Thank you for redesigning Webmin. I used it for a client's server and the functionality was fantastic, the design a bit less so. A Bootstrap'd frontend sounds fantastic.
It is also immediately theme-able with any Bootstrap theme, which is a major leap forward. And, it is responsive...another major leap forward. The old way of handling mobile is to have a custom theme for mobile devices (currently based on Joe Hewitt's iUI, which is pretty long in the tooth, and looks like ancient iOS versions).
We're about a week away from an alpha release (suitable for testing in the wild), a month away from a beta release (suitable for daily use by people who understand how to file bug reports), and two months away from it being the default theme in all of our products, both Open Source and commercial. Assuming I am able to maintain the current pace of development.
Bootstrap (and maybe moreso, jQuery) is pretty miraculous, honestly. I've tried to do this on two separate occasions in the past with YUI and ExtJS, and failed miserably, because they simply don't work well in a progressive enhancement environment (and my brain doesn't work the way their developers brains work...jQuery fits my Perlish brain a lot better).
I don't what about this is semantic except the class names. But even that comes with a heavy loss in maintainability. If I have to customize say, the border radius of an icon button, I'd have to override this specificity:
`.ui.vertical.labeled.icon.buttons .button:first-child > .icon`
Not cool.
In their examples, none of their buttons were actually buttons. Nor were they even links. They were all DIVs. This is pretty terrible HTML, for many reasons, especially for accessibility.
No they don't. On different browsers the padding is completely different, and on many browsers you can't even control it. And don't tell me "you don't need to control the padding of buttons."
It's a little concerning using library claims to be about "semantic" when the demo code doesn't even care about using the semantic tag for button. It makes you worried if the author actually knows what he's doing.
There are tags you can put on your markup that will tell screenreaders and other accessibility tools that this thing is a button, there is an entire set of aria roles and states for things like checkboxes, buttons and other ui objects so you aren't limited to the defaults provided by the various html standards.
Can you guys please stop whining about the name and talk about the features? Didn't your elementary school teacher tell you not to judge a book by its cover? They could always change the name if they had to. They never actually say they're semantic HTML, it could have other meanings. Or, you know, it could just be a name. There's plenty of projects with meaningless names.
Semantic UI has a meaning. The authors chose to ignore its meaning while trading on the cachet of the name. While their web dev skills may be unsurpassed, it's a reasonable criteria on which to judge them.
Because semantic actually means something, it's not a subjective term.
Calling something Semantic UI and comparing it to another library, that more follows the actually meaning of semantic, is silly. Yes you can change the class name but setting up the name as something meaningful, something semantic, such as 'submitButton' lets you redefine it in the CSS.
If I'm building something that multiple clients will use I don't want each client having buttons with class names specific to the client, but something I can modify easily in the CSS to get the look and feel they want.
Him calling you an idiot isn't an ad hominem. It's only an ad hominem if he's arguing "You're an idiot, and therefore you are wrong ". "You're being an idiot, and here's why: <reasons>" is just impoliteness.
Sorry if i misunderstand it, but where is the semantic and where the ui?
This contradicts to all efforts of the last years for real symantec and a good readable html page with simple customizable css.
I see you intention to make a page readable for an ui designer and add symantec to ui elements. But whom help this? (except a designer)
Great idea except you don't namespace anything! I like namespaces because one library or css import from another won't ever stomp on each other. I've seen 'ui', 'button' and 'red' in several other packages and places. They're going to conflict. The one with the greatest specifity is going to win and cause untold hours of frustrating debugging.
+1 with that. I dont understand why css framework authors dont namespace their frameworks. That's should be a basic requirement before distributing any css library.
Because it makes the selectors less efficient. On individual selectors it probably doesn't make much of a difference (for most of them at least) but add it all up and you can have a significant impact on performance for large DOM trees.
If the website creator is reading this - Please do something about the moving background image. It's nausea-inducing, and I had to exit the website due to it.
Regarding the semantic-ness of the class names - I see people complaining that "ui three column grid" is not semantic. I don't understand what the big fuss is about - how could a generic, non-preprocessed grid be semantic ? It's presentational by definition, and the class names reflect that. If they implemented the framework as SASS mixins, sure, you can be as as semantic as you want when you use those mixins. That's what I like about Foundation. For example:
84 comments
[ 3.9 ms ] story [ 159 ms ] threadI used to eschew any and all presentational classes, but it makes development quicker for me to use them occasionally, esp with css frameworks.
Edit: After a more detailed look, the framework is actually really nice (and very comprehensive). The name still doesn't make much sense though.
So the HTML should say "this is important" (em) while the CSS is free to define "important" as bold, different color or some other font change.
For example the HTML should not contain anything about number of columns. It will be 1 column on iPhone, 2 on iPad and 4 on Desktop - but the HTML does not change.
So yes, since HTML is designed to describe its content, the class names should describe the content and the CSS should select that content to style.
I got a half-hearted lecture about HTML.
<header> <h1>Title</h1> <nav> <button class="active">Home</button> <button>Link</button> <button>Link</button> </nav> </header>
not this:
<div class="ui menu"> <div class="header item">Title</div> <a class="active item">Home</a> <a class="item">Link</a> <a class="item">Link</a> <div class="right floated text item"> Signed in as <a href="#">user</a> </div> </div>
http://i.imgur.com/l5gEwUJ.png
It is also immediately theme-able with any Bootstrap theme, which is a major leap forward. And, it is responsive...another major leap forward. The old way of handling mobile is to have a custom theme for mobile devices (currently based on Joe Hewitt's iUI, which is pretty long in the tooth, and looks like ancient iOS versions).
We're about a week away from an alpha release (suitable for testing in the wild), a month away from a beta release (suitable for daily use by people who understand how to file bug reports), and two months away from it being the default theme in all of our products, both Open Source and commercial. Assuming I am able to maintain the current pace of development.
Bootstrap (and maybe moreso, jQuery) is pretty miraculous, honestly. I've tried to do this on two separate occasions in the past with YUI and ExtJS, and failed miserably, because they simply don't work well in a progressive enhancement environment (and my brain doesn't work the way their developers brains work...jQuery fits my Perlish brain a lot better).
There are tags you can put on your markup that will tell screenreaders and other accessibility tools that this thing is a button, there is an entire set of aria roles and states for things like checkboxes, buttons and other ui objects so you aren't limited to the defaults provided by the various html standards.
Semantic UI has a meaning. The authors chose to ignore its meaning while trading on the cachet of the name. While their web dev skills may be unsurpassed, it's a reasonable criteria on which to judge them.
A single post or two on the name I could understand, but every comment? HN fixates on the absurd.
Calling something Semantic UI and comparing it to another library, that more follows the actually meaning of semantic, is silly. Yes you can change the class name but setting up the name as something meaningful, something semantic, such as 'submitButton' lets you redefine it in the CSS.
If I'm building something that multiple clients will use I don't want each client having buttons with class names specific to the client, but something I can modify easily in the CSS to get the look and feel they want.
It's ass backwards.
"Semantic" actually means something important in the context of HTML, and this project completely violates it.
I see you intention to make a page readable for an ui designer and add symantec to ui elements. But whom help this? (except a designer)
Regarding the semantic-ness of the class names - I see people complaining that "ui three column grid" is not semantic. I don't understand what the big fuss is about - how could a generic, non-preprocessed grid be semantic ? It's presentational by definition, and the class names reflect that. If they implemented the framework as SASS mixins, sure, you can be as as semantic as you want when you use those mixins. That's what I like about Foundation. For example: