> Whether you style in stylesheets or by some other means (CSS-in-JS?)
We're specifically talking here about putting styling logic - "left" "shiny" "big" etc - in HTML.
> is an implementation choice rather than something that affects the fundamental pattern.
Sure, you can still use a component pattern with styling split into HTML and stylesheets - it certainly doesn't effect the pattern.
The issue is: when you want to change the appearance of your component, do you want to modify styling logic in two places or one?
Re:Semantic UI
by andrewingram on Monday April 10, 2017 @07:17AM
(#14077495)
One, that's why I style inline :)
Do you mean inline in CSS / style tags, avoiding visual HTML classes (in which case we're in agreement - there's one way to edit how something looks, though style tags have other issues) or combining either of those with visual HTML classes like this library uses?
Re:Semantic UI
by andrewingram on Monday April 10, 2017 @10:43AM
(#14078860)
Okay, I think we're in agreement and are just crossing wires a but. The main reason i'm loosely okay with Semantic UI is that I just see it as using HTML fragments as building blocks rather than using JavaScript components. I wouldn't advocate it for anything elaborate, but I think it can work well within a certain problem space.
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.