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

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

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 used to eschew any and all presentational classes, but it makes development quicker for me to use them occasionally, esp with css frameworks.

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.

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.

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.

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

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?

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.

"Semantic" actually means something important in the context of HTML, and this project completely violates it.

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.

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

I got a half-hearted lecture about HTML.

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

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.

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)

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.

Keep up the good work!

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!