Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Semantic UI

semantic-ui.com

Post reply on HN
Print view View original

111–120 of 257 posts

Re: Semantic UI

#111

Post by wut42 »

jwr wrote: post #56

I use Semantic UI in production on https://partsbox.io/ and can list some upsides and downsides. On the positive side: * very complete, with good form styling, and lots of widgets you will use often, which is especially important for larger apps, * the default theme is mature and has good usability, without the crazy "oh, how flat and invisible our UI is!" look. * the class naming plays well with React (I use Clojure…

You don't have to use their build system. I'm purely using the less version of Semantic, which is built as a normal less files.

It also allows to pick individual components, to reduce the CSS file size.

Re: Semantic UI

#112

Post by andrewingram »

jameslk wrote: post #73
jasim wrote: post #58

Earlier quoted context omitted.

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. The reason we need semantics in HTML is to make the markup accessible for screen-readers, and no screenreader considers the class name of an element when reading it out. What we instead need are semantic tags like article, section etc. and aria tags like role.…

I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single sourc…

There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments.

Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup changes tend to be more expensive (you can't just move a block of HTML from one place to another and not expect its appearance to change).

These days though, we're increasingly building things in a UI-oriented way. What you see on the page is a composition of a number of components. If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. So now i'm authoring CSS that is bound to the structure of this component, naming becomes a lesser issues. The other thing worth pointing out is that it's not too difficult to built a document-UI (like say a magazine) using app-UI patterns, but it's rather challenging to do it the other way around.

If the goal is maintainability, then there should be zero industry-wide dogma. Best practices are going to be coupled to the methodology of the maintaining team. Personally, I did document-oriented CSS for 15 years, now i'm doing component-oriented CSS, and the results are much better. Obviously this is just an anecdote, but i'm not alone in this.

This idea that design is a "layer" on top of structure is somewhat offensive to the designer in me. Visual design is (and should forever be) coupled to structure and behaviour. Design is not a higher abstraction, it's something that pervades everything.

Re: Semantic UI

#113

Post by nilliams »

jameslk wrote: post #73
jasim wrote: post #58

Earlier quoted context omitted.

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. The reason we need semantics in HTML is to make the markup accessible for screen-readers, and no screenreader considers the class name of an element when reading it out. What we instead need are semantic tags like article, section etc. and aria tags like role.…

I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single sourc…

I'm not sure you read the articles GPP mentioned, yes CSS Zen Garden was the dream, but I feel like articles like the excellent mrmrs one [1] address the reality.

[1] http://mrmrs.io/writing/2016/03/24/scalable-css/

Re: Semantic UI

#114

Post by nailer »

andrewingram wrote: post #112
jameslk wrote: post #73

Earlier quoted context omitted.

I think this is missing the point. For me, semantic class names have lead to very maintainable websites/apps that I've been able to completely redesign without touching much of the HTML, which is usually much harder to change in larger dyanmic applications. It's also made it much easier on teams I've worked with because the designers could quickly dig into the styles to make tweaks in a central location (single sourc…

There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments. Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup chang…

> If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties.

What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML?

We use components everywhere. We style in stylesheets. Handily we even keep the stylesheets in the same component as the module, thanks to npm-sass / sass-npm.

Re: Semantic UI

#115

Post by nailer »

olavk wrote: post #103
jasim wrote: post #58

Earlier quoted context omitted.

The concept of 'semantic classnames', even if propagated by w3.org has caused as much grief as the concept of 'separation of concerns' between HTML & CSS fad. The reason we need semantics in HTML is to make the markup accessible for screen-readers, and no screenreader considers the class name of an element when reading it out. What we instead need are semantic tags like article, section etc. and aria tags like role.…

There are really two different concerns which are often conflated: 1) Semantic markup for the sake of screen readers (and Google and so on) 2) Separation of concerns for the sake of maintainability I don't know how separation of concerns cause grief for developers, my experience is the opposite. Separation of concerns not a "fad", it is a fundamental principle of any kind of systems design. That said, it doesn't dire…

Getting both sides of this arg: basically 'sep of concerns' is viewed as being 'seperation of technology' rather than actual sep of concerns. Eg, put documents and styles and behaviour for a related component together, seperate that component from other components.

It's a slightly silly argument because really we're arging between slicing something vertically (tech) vs horizontally (components) and the nicer thing is probably to do both - have lots of components with the documents, styles, and behaviour separated out within each component.

Re: Semantic UI

#116

Post by nailer »

progval wrote: post #110
jameslk wrote: post #34

I've always found it ironic that this library calls itself "Semantic UI" but doesn't follow the practice of semantic HTML/classes[0]. W3C suggests[1] that classes should be used for semantic roles (e.g. "warning", "news", "footer"), rather than for display ("left", "angle", "small" -- examples taken from Semantic UI's docs). So instead of giving a button the class of "button" it would be better to give it a class suc…

Also, it uses this instead of : Andorra United Arab Emirates Afghanistan

``s aren't styleable so you have to do a select proxy.

Re: Semantic UI

#117

Post by andrewingram »

nailer wrote: post #114
andrewingram wrote: post #112

Earlier quoted context omitted.

There's flaw in reasoning here, but I'm glad we're at least focusing on the maintainability arguments. Ultimately it comes down to how your CSS is authored, and how your teams works. If you develop in a heavily document-oriented way, and make big use of the cascade, you're most likely to benefit from semantic (rather than presentational) class names. This is because when you make full use of the cascade, markup chang…

> If I move a component from one place to another, I expect it to look the same (with a caveat for responsive layouts) assuming it's still rendered with the same input properties. What's preventing you from doing this with your presentation login in your stylesheet, and what about this requires you to split your presentation logic between a stylesheet and HTML? We use components everywhere. We style in stylesheets. H…

Sorry, i'm struggling to follow what you're asking here.

Whether you style in stylesheets or by some other means (CSS-in-JS?) is an implementation choice rather than something that affects the fundamental pattern. If your components are truly portable, you're already doing things the way I suggest. If they inherit things like fonts and colors from their parent via the cascade rather than via explicit properties, then you don't have truly portable components - their appearance will change when you move them around.

Re: Semantic UI

#118

Post by du_bing »

NicoJuicy wrote: post #92
du_bing wrote: post #76

Earlier quoted context omitted.

Co-worker here, yeah, truly some pages of the site are not yet quite responsive, sorry for that, we plan to improve it in the future. On the site there are some particular templates designed to show the responsiveness or non-responsiveness, you could open them on smart phone or desktop computer to see the differences: http://semantic-ui-forest.com/templates/bootstrap/grid/ http://semantic-ui-forest.com/templates/boot…

I think it's not detecting my mobile as mobile. Motorola Play X here in Android, chrome

Oh，yeah, it's set to be like so in the HTML's header, so you could see the whole webpage's layout like on a computer, we are going to improve the responsiveness soon. For developers who want to apply some themes and templates to build their websites, it may be useful. Thanks for visiting!

Re: Semantic UI

#119

Post by vinayakkulkarni »

progval wrote: post #110
jameslk wrote: post #34

I've always found it ironic that this library calls itself "Semantic UI" but doesn't follow the practice of semantic HTML/classes[0]. W3C suggests[1] that classes should be used for semantic roles (e.g. "warning", "news", "footer"), rather than for display ("left", "angle", "small" -- examples taken from Semantic UI's docs). So instead of giving a button the class of "button" it would be better to give it a class suc…

Also, it uses this instead of : Andorra United Arab Emirates Afghanistan

Look at the second example:

https://semantic-ui.com/modules/dropdown.html#selection

Re: Semantic UI

#120

Post by Firadeoclus »

Mikhail_Edoshin wrote: post #85
jameslk wrote: post #34

I've always found it ironic that this library calls itself "Semantic UI" but doesn't follow the practice of semantic HTML/classes[0]. W3C suggests[1] that classes should be used for semantic roles (e.g. "warning", "news", "footer"), rather than for display ("left", "angle", "small" -- examples taken from Semantic UI's docs). So instead of giving a button the class of "button" it would be better to give it a class suc…

I always found that "semantic" approach very misleading. In computer languages "semantics" is what the computer does with your input. This is the semantics of C, for example. Markup languages are no different. Until you have a clear specification what computer does with the markup, you have no semantics. I.e. , , and tags have perfect semantics, while things like or have none or very vague wishy-washy one.

Semantics is the branch of linguistics and logic concerned with meaning.

With tags like or , the meaning of the tags themselves as they're supposed to be understood by the browser is clear. Semantic tags, on the other hand, are supposed to associate meaning to their content.

Post reply on HN