Semantic UI – A language for sharing UI

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

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.

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!

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.

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