Hacker News Reader

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.