Live data from Hacker News

Semantic UI

semantic-ui.com

201–210 of 257 posts

Re: Semantic UI

#201
post #188

Earlier quoted context omitted.

I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-a... These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards. If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your…

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: when you could look at this: The latter, aside from sparing your brain endless visual noise, makes it instantly clear how…

Thing is, if you're using Angular (or most likely any of the hot SPA frameworks out there), you don't need semantic CSS class names, since the model bindings will make the meaning quite clear.

Re: Semantic UI

#202

Semantic recently adopted my team's React adaptation as their official React port. It's lighter weight, eliminates jQuery, and all components are standard React components that can be extended or dropped in as-is. https://react.semantic-ui.com/

When I click that link I get a blank page with a spinner saying "loading docs" for several seconds before anything actually loads... and it's just a bunch of static text content.

Why does it take several orders of magnitude too long to load? Makes me very concerned to implement it in any production application of my own.

Re: Semantic UI

#203
post #193

Earlier quoted context omitted.

They also use tag for icons. https://semantic-ui.com/elements/button.html

Is this so bad? It seems to me that using for icons has become pretty standard across many sites and you shouldn't be using the tag for italics anyways - there's for that now.

Using for icons is a bad idea. Wait, no, it's the wrong thing to do. The element still has meaning and can be used for that purpose, of which has absolutely nothing to do with icons.

Re: Semantic UI

#204

Semantic recently adopted my team's React adaptation as their official React port. It's lighter weight, eliminates jQuery, and all components are standard React components that can be extended or dropped in as-is. https://react.semantic-ui.com/

I might have to try this out, too bad I didn't see this yesterday. Settled out with trying http://ant.design/ which has actually been pretty nice as well. Seems most React components libs are material design and I can't stand the look.

I've been using react semantic ui for the last week and am thinking of switching to ant. Or going a la carte for everything.

Ant is good at making the css importable module by module using webpack. Semantic ui could adopt this approach too.

Have you had mobile problems with Ant? Seems a touch buggy there

Re: Semantic UI

#205

Might also check out Ant Design. https://ant.design/ It's integrated with React and there's a separate mobile UI for it. Ant is Chinese, with docs translated into English. Like China, it's huge^^ I've just been fooling around with it today for the first time in create-react-app and seems good so far. Haven't tried on mobile.

I like that you can import just the css you need for a component. Semantic ui should do this too.

Some mobile glitches with Ant, but I'm considering trying it. I only need a few components

Re: Semantic UI

#206
post #188

Earlier quoted context omitted.

I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-a... These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards. If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your…

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: when you could look at this: The latter, aside from sparing your brain endless visual noise, makes it instantly clear how…

You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.

Re: Semantic UI

#207
post #193

Earlier quoted context omitted.

They also use tag for icons. https://semantic-ui.com/elements/button.html

Is this so bad? It seems to me that using for icons has become pretty standard across many sites and you shouldn't be using the tag for italics anyways - there's for that now.

So for icons and for buttons then?

Re: Semantic UI

#208
post #188

Earlier quoted context omitted.

I used to think this way until reading this article by Nicolas Gallagher: http://nicolasgallagher.com/about-html-semantics-front-end-a... These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards. If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your…

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: when you could look at this: The latter, aside from sparing your brain endless visual noise, makes it instantly clear how…

You could look at "basket", "product", and "searchResults", except that it tells me absolutely nothing as a dev about what it looks like. You shouldn't be using your CSS classes to tag sections, that's what id is for. And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.

Re: Semantic UI

#209
As a blind web developer, I want to like Semantic. My usual mode of developing HTML, once it's at the "I need to make this look good" stage, is "show it to my girlfriend and ask her various questions." She says things like "I wish X were a bit larger," or "Y should be blue," and pulling that off in Bootstrap is challenging. I can drop down to lower-level CSS, but have no clue how my changes interact with Bootstrap's defaults, or indeed if they take effect at all. I mean, I can tweak font sizes and hex codes, but at the end of the day they're all numbers, when what I want to do is say "No really, make this thing larger relative to these other things," not "make it 125%, with this hex code I scraped out of some color list and hope looks nice."

But, gods, buttons as divs. Maybe they're easier to style, but if I had a dollar for every time I couldn't use someone's site because they used a div as a button, then didn't do the several other things that gives you for free that make all the accessibility difference, well, I'd not worry about money ever again.

I'm glad to see that the homepage example at least uses , but then the rendering of the example isn't keyboard-focusable or actionable. Then, when I look at the actual code they're rendering, it's back to divs. So they're not even rendering their example code.

Can I use Semantic with the actual HTML elements that the divs are meant to style, so I can use the CSS class names some folks hate and derive their benefits to me, but still get the accessibility benefits of the tags? I'd read their docs and check, but I don't know if they're linked from the main page. I see links to 1.X/0.X docs, but I can't find a link to 2.X docs. There's a "Menu" link which may pop up more links, but I can't seem to trigger this with Enter. I seriously spent 10-15 minutes on this page looking for docs using only my keyboard, before deciding that I really had better ways to spend my day.

I hate to advise people to avoid projects because I'm not so arrogant as to think my language/stack/framework/whatever is anything other than my favorite, and I do want to like this one, but every time I look at it the accessibility story is disappointing, and given that it's a framework, that means other sites will likely inherit disappointing accessibility stories too.

And now it's back to drinking, which seems to be the only fix for this[1].

1. Not really, but damn am I tired of a) fighting the same battles again and again and b) answering the same questions about said battles again and again. All of this stuff is exhaustively documented by folks who are smarter than I am, so it isn't obscure, nor is it something I need to (or am even highly qualified to) answer.

Re: Semantic UI

#210
post #188

Earlier quoted context omitted.

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style: when you could look at this: The latter, aside from sparing your brain endless visual noise, makes it instantly clear how…

You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.

My answer was implicit is the final comment. The purpose of those elements is not re-use. It's clarity. The re-use happens in the Sass (or other preprecessor) code. Somewhere in your Sass, you define "basket" as a "pull-left; row; col-xs-4" or even higher level constructs which you plan to re-use... that's up to you.

The point is they are orthogonal issues. Creating re-usable chunks of CSS does not suddenly absolve you of the responsibility to make your HTML readable. You can do either one without the other, but you should be doing both.

Post reply on HN