Hacker News new | past | comments | ask | show | jobs | submit login
Semantic UI – A language for sharing UI (semantic-ui.com)
230 points by knes on Sept 13, 2013 | hide | past | web | favorite | 81 comments

This is semantic:

<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>

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.

they're both semantic, its just that one splits it between tag names and class structure and the other puts it all in the class structure.

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?

There's no such thing as a "CSS class". HTML has classes, and CSS has class selectors.

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.

Not true. A "CSS class" is where you go to be taught about CSS.

Any good sites I can select a CSS class?

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.

I wouldn't call writing "ui large red labeled icon button" in HTML semantic anything. I'd called it confusing orgy of style and content.

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'.

I assume the ui class is there for namespacing, which I think is a good idea.

I don't see any content; those are all stylistic properties.

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?

Remove the "red" class from the element?

I used to eschew any and all presentational classes, but it makes development quicker for me to use them occasionally, esp with css frameworks.

I guess my point was you'd have to refactor your html and css as well as the property itself

Use a SASS mixin instead? @include red;

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.

It's also the exact opposite of semantic HTML as I understand it.

I really liked it visually speaking but yes, buttons implemented as divs it's sad.

It's a tag ambivalent CSS library. There's nothing sad about that. Just use buttons tags, it's not stopping you. Don't get hung up on the demo code.

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.

Although it's sad, what's really sad is that buttons don't render consistently across browsers. I try to avoid buttons for that reason :(

Trapped in 1999? Buttons render ok since IE7/8.

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."

No they don't. Apples buttons are round, ms buttons aren't.

That's before you use appearance: none and normalize any styles, the subject is customizing with CSS.

Thanks for the info! It's helpful ... but looks like IE and Opera still don't respect this.

Not any more.

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.

Hey, I'm jack the guy behind semantic UI. Semantic isn't ready for release yet. A lot of the copy on the site is only currently in draft form. and there are plenty of inconsistencies with the code base itself. Hell, there isn't even a download link.

I've been privately been working on the framework trying to get it to a place where i'm happy enough to open it up for outside feedback and it's not quite there yet.

The idea behind semantic UI is that html tags aren't truly semantic, but have become conventional to programmers. There is nothing semantic about using an 'a' tag to refer to a link or td for a table cell. These codifications make web development less accessible to non programmers. Ideally we'd all start going around creating our own top level tags to define user interface, but we don't really have that opportunity today.

The only chance, I believe, we have to build a linguistically semantic web is to build conventions around class names usage, the bit of web design where most FEDs make their decisions.

Semantic uses DIVs as an equalizing factor. If we can't control how browsers interpret tags then we might as well ignore them. I'm sure a lot of this stuff sounds terribly bombastic. The intention is quite the opposite. Define by convention, not by prescription.

I'm looking forward to bringing semantic back to hacker news sometime when its more fully completed.

The HTML in the project is brittle, problematic for consumers and parsers, confusing to developers and designers, and future-unfriendly. I encourage you to spend some time researching the reasoning behind HTML and markup in general, including why it's important to use id and class names that describe the content (rather than the presentation) and HTML elements other than div. They exist for a reason.

Think about this: I can see from the linked page that you understand how adding type="password" to an input makes some consumers, like various web browsers, treat that field differently. There's a lot of stuff like that in HTML.

If you want a short intro that also explains some of the "why" behind various aspects of HTML5, read this: http://www.abookapart.com/products/html5-for-web-designers

The HTML5 spec also has a lot of info ( http://www.w3.org/TR/html5/grouping-content.html#the-div-ele... ). For example:

> Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.

Seriously, HN? Downvoting a post by the guy behind the actual project so much that it (currently) ends up at the bottom of the discussion? Wow!

(That said, I don't agree with the author's opinion but it just seemed so disrespectful. Obviously quite some work went into this already and visually, it shows.)

> The idea behind semantic UI is that html tags aren't truly semantic, but have become conventional to programmers.

This idea is simply false.

> There is nothing semantic about using an 'a' tag to refer to a link or td for a table cell.

HTML tags have defined semantics (and, in modern HTML, that's pretty much exclusively how they are defined, though there's a handful of remaining tags where the semantics refer to presentational conventions of print media, and are so at least quasi-presentational.)

> These codifications make web development less accessible to non programmers.

Only if by "non-programmers" you mean "people who don't read the definitions"; insofar as composing HTML is difficult to non-programmers, it has nothing to do with the defined tag semantics, and insofar as defined tag semantics make HTML difficult for some people, its not really about their skill as programmers.

> Ideally we'd all start going around creating our own top level tags to define user interface

I don't see why this is ideal; indeed, from a maintenance perspective, it seems to be the opposite of ideal.

> but we don't really have that opportunity today.

Sure we do; among other alternatives, XML+XSLT is a real thing supported by browsers.

That's not to say we should do it -- unlike you I think it is far from ideal. But certainly we could do it, using existed, widely-supported technologies.

> The only chance, I believe, we have to build a linguistically semantic web is to build conventions around class names usage

If semantic definitions of tags in standards documents make HTML inaccessible, how aren't semantic definitions of class names relying on knowledge codified outside of standards documents going to do exactly the same thing?

Independent of any semantic-or-not discussion, the UI looks great.

Regardless of how "semantic" it is, I think Semantic UI looks really promising, and I'm tempted to use it right away. I like the way classes are used.

Don't mind these silly geese bickering about the semantics, what really matters is the productivity increase a tool brings its users. Semantic UI looks to be very strong in that regard. There's a veritable shitload of good stuff in there.

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" actually means something important in the context of HTML, and this project completely violates it.

Don't be an idiot.

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.

Ad hominem attack, really?

A single post or two on the name I could understand, but every comment? HN fixates on the absurd.

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.

It's ass backwards.

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.

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.

What I'd really like is a UI toolkit for developers that goes <div class="whatever just make it look good">

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.

You're welcome. Here's the most recent screenshot of progress:


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).

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 :/

I expected something about declarative, generic UI definitions.

I got a half-hearted lecture about HTML.

Very nice, and has lots of components. I like 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:

  .my-foobar {
    @include grid-columns(3);
    @include panel;

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.

I think the point that a lot of people are missing is that the library is just tag ambivalent. The demo code uses divs, but of course you don't have to use divs. You can use whatever tag you like. It's hard to see why that could be construed as anything other than an advantage.

If you like <button> tags then by all rights use button tags. It makes sense that the demo code would use divs, because to do otherwise would imply that a certain tag is required for the css to work.

Advantage? Tell that to screenreader users.

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.

Should "large" and "red" really be part of the semantic, or should it be up to the CSS to style the element with appropriate size and color ?

Why does it do away with using <button> for buttons?

It doesn't. You just don't have to use <button> or any other tag for that matter.

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)

This. I like this. It's sort of like an OOCSS Bootstrap.

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 like the design a lot better than Bootstrap, but I don't think "Semantic UI" matches the implementation.

Shouldn't a language for sharing UI be human readable like QML ( http://en.wikipedia.org/wiki/QML#Basic_syntax ) instead of machine readable like XML with its claustrophobic tag soup mess, flow killing end tags, and so on?

What is this? Inuit css is more semantic than this, and i don't see the point to use classes in html document anymore, I actualy inject them via js or just extend reausable classes made in scss, semantics of html should just have attributes that actualy describe what the element is for with ARIA, roles, etc.

I see semantics is much inclined to OOCSS (object oriented CSS) which is actually good because the project is cleaner, works really great for large websites with lots of pages.

But it's poorly executed. The good deal is, to use Bootstrap + OOCSS. Ive had really good experiences and full control of the project by this method.

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.

This is not semantic at all!

am I the only one suffering from massive CPU usage while on that Semantic UI page due to the "#example .masthead:before" CSS3 background animation? my MBA fan starts spinning up like crazy.

Would be good if it didn't suffer such a big case of divitis...

Ok so the name and tagline of this library is wrong/confusing. But forgetting that, visually it looks like a nice alternative to bootstrap. Still some work to be done.

Some parts are so beautiful, it's a very good inspiration.

Looks great. I am also using a Chromium-based browser, so half the elements do nothing when I click on them, but that's understandable seeing how new this is.

Keep up the good work!

Agree with everyone else on the semantic issue, nonetheless I'm loving the theme and built-in features and would 100% use this for some prototype builds.

This is really nice, certain parts are just amazing. Such nice UI flow. I will keep an eye on it and try and use it in my next project!

Showing a modal takes ages on Chrome on iPad, presumably as the blurred background is being rendered.

The first example claims that "ui three column grid" is semantic. Not in my book.

Actually, I think we've all misunderstood this: it's "Semantic". Nowhere does it actually claim it's 'semantic' :-)

You Keep Using That Word, I Do Not Think It Means What You Think It Means.

Wow, I really like this.

This is cart-before-the-horse-ism.

Where did this trend come from to use presentation frameworks as a barometer for developing semantic markup?

Go to http://schema.org to understand what descriptive semantics is about.

"What it looks like" is not basis for initiating a project into generic semantic structures that involve interoperability with existing, mature systems.

These exercises really need to stop. There are no "three column grids" in e-mails. C'mon, folks !

How can we get drag-and-drag complex objects from microdata? — This is a question of semantics, and this framework follows a principle of "UI is the language of the web." With this axiom, one cannot even begin to talk about interoperable/shared semantics!

Following such a principle, what do we end up saying about the lingua franca of the Web, HTML, which does not describe any UI component? We're not "writing for UIs"; we're writing for other humans, and possibly other species which can parse a base language. If all we're writing for is the UI, we'd first need to describe our grammar before we can begin to send a message, and this is clearly not the case with natural language. We describe what we [mean] before we go about describing how we meant it!

This site infuriates me. Half the stuff I click does nothing(chrome).

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact