191–200 of 257 posts
Earlier quoted context omitted.
Why does Bootstrap 4 feel like a sinking ship?
Because v4 has been in alpha since august 2015, and v3 hasn't had significant updates since 2015 either.
Semantic and Foundation are both on my list of things to look at.
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…
Semantic is based on the idea that describing physicality (the function of html/css) is a task natural language is acutely optimized for, while describing the implementation of behavior ("cooking recipes", or the vast majority of programming implementation) is best served by programming languages.
Part of how natural language optimizes for transmitting meaning is by reducing ideal forms of concepts to words based on the exact amount of specificity for conveying meaning between humans. I.e. "horse" instead of "quadrupedal mammal that has a heart and has eyes and has a tongue..." etc.
These 'units of optimized human idea transmission' (read words) are then clarified using a system of modifiers that take care of removing just enough ambiguity that the idea is communicated effectively. "The kindly, gentle lion", "The angry, hungry lion".
The modifiers themselves carry no absolute meaning. A "large ant" may be smaller than a "small planet", but we understand them -- in context -- of the nouns.
Language is littered with other interesting features like this that are designed particularly for this task of describing physicality. Most of which are absent from programmatic implementations of 'languages for describing physicality' like HTML/CSS.
Other key examples of useful cognitive optimization: Plurality, "Three large red buttons" vs "Large red button, large red button"; significant word order, "left floated right aligned column" vs "right floated left aligned" column.
I think the main drawback with using a natural language approach is that the implementation has to be bullet proof. Although everyone uses language, we never have to implement systems of interpreting language from phoneme to neuronal pathway. So even though the benefits are clear, the path forward in mapping language to systems of programmatic physicality isn't exactly straightforward.
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…
They also use tag for icons. https://semantic-ui.com/elements/button.html
* "...More Quickly".
Quicker is an adjective, used to describe nouns. You could say "design quicker websites", "quicker" in that case describing an aspect of the website. If you wanted to describe the manner in which you will do the designing, you have to use the adverb "quickly"-- "design websites quickly". Adding the adverb "more" to modify the adverb "quickly" is the proper way to make it comparative.
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…
FYI: The React version - is jQuery free http://react.semantic-ui.com/introduction
Earlier quoted context omitted.
Nobody, except the individual that has to change them all when you need to swap out frameworks or upgrade to a version that breaks compatibility or the product team decides on a new layout across the app...
Okay, no one has actually explained how Semantic UI overcomes this. What if in the future you decide to switch from Semantic UI to something else?
Now, I just kind of live with the ".col-md-12" business...
$('select.dropdown').dropdown('set selected', ['meteor', 'ember']);
Is the most unintuitive Javascript I've ever seen.
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…
Author of SUI here again. Semantic is based on the idea that describing physicality (the function of html/css) is a task natural language is acutely optimized for, while describing the implementation of behavior ("cooking recipes", or the vast majority of programming implementation) is best served by programming languages. Part of how natural language optimizes for transmitting meaning is by reducing ideal forms of c…
When I first heard about Semantic UI, I was excited because I had hoped someone had finally built something like Bootstrap using only Sass/Less mixins that were pure and side effect free (i.e. not littering the global namespace with generically named classes, not dependent on the structure of the HTML). I was disappointed that was not the case and frustrated with the confusion of the usage of "semantic" when its already widely adopted to mean something specific for HTML.
I really wish UI libraries were built on mixins. Pure mixins would allow for reusable component styles and modifiers such as "three large red buttons" to be mixed into semantically-named CSS classes such as "user-controls." Additionally, mixins would allow for media query usage (e.g. I could use a "big red button" for desktop and "small red button" for mobile), allow for more selectiveness about which components/modifiers I want to use (which may reduce the overall size of the CSS), allow for conditional styling logic, and generally be easier to work with in a CSS preprocessor. This facilitates all the goals you've mentioned while being more flexible, open to extension and enabling us to stick to the way HTML/CSS was meant to be used. Maybe you've already considered all of this and have your reasons for not pursuing it. I'm sure it would be much more work to go that way now regardless, although it seems Bootstrap 4 has started heading in that direction.
[1] github.com/nwmcsween/s.css