51–60 of 71 posts
Earlier quoted context omitted.
Nicer looking div soup is still div soup. != semantic.
no, but or are semantic, and there's no reason you couldn't use those instead of by using the features of LESS or SASS.
I've used Bootstrap and been forced to use it on existing projects already engulfed in it. It isn't pretty on a large project. I've sworn off using Bootstrap in any new project that isn't a prototype for a hack day. The only things I borrow from Boostrap these days are some of the JavaScript niceties like modal, tooltip, and scrollspy. And when I do that I'm very explicit in what code I pull in to use those. Build th…
I believe initially Bootstrap was intended for just this use case—make it easier to do a quick mock-up in markup. Once your design is relatively stable, you would naturally spend some time custom-fitting markup and stylesheets (enhancing source code readability, accounting for those who can't see, basic SEO optimization, etc.). This whole ‘front-end framework’ thing seems to me like a wrong direction to take.
Earlier quoted context omitted.
no, but or are semantic, and there's no reason you couldn't use those instead of by using the features of LESS or SASS.
In my experience, really trying to be semantic ends up requiring gargantuan leaps of creativity trying to come up with semantic meaning for elements that are there purely for presentational reasons (wrapper classes, clearfixes, etc.)
Still, it's very possible to be almost entirely semantic with a few minor exceptions using a css preprocessor.
[1] http://compass-style.org/reference/compass/utilities/general...
We need a better word for this than "semantic". We're just passing the complexity back and forth between the HTML and the CSS, and the only "semantics" or meaning that arise are to the author/editor. Users don't care, machines don't care, and I've never, ever seen a large-scale site design that doesn't involve some reworking of both the HTML and the CSS.
That's because you aren't blind.
We need a better word for this than "semantic". We're just passing the complexity back and forth between the HTML and the CSS, and the only "semantics" or meaning that arise are to the author/editor. Users don't care, machines don't care, and I've never, ever seen a large-scale site design that doesn't involve some reworking of both the HTML and the CSS.
Abstractions still require names, and the names should be meaningful (not easy: "naming things is one of the hardest things to do in software development"), at least to the development team (hate to keep rattling off platitudes, but "you should write code for humans first, computers second"). Rather than "semantic", "descriptive" seems to fit the bill.
"Abstract and descriptive". Doesn't quite roll off the tongue, but I tried :)
Earlier quoted context omitted.
Sure, but what if you have more than another section that should be styled differently? Classes can help differentiate same-name elements with different contexts, so you don't need unwieldy structure-specific CSS selectors like main > section > main just main.semantic-class
You'll also get major specificity issues when using element selectors with other class/id type selectors. My rule of thumb is classes and only classes for styling, it really makes life a lot easier. (Even if you have a unique element on the page, don't use the ID in your selector to style it.)
Since large projects will inevitably have to rely on non-semantic HTML and class names anyway (e.g. to differentiate between sibling
tags), a simple rule of thumb would be to only use class names in selector construction. HTML elements can still be semantic for other purposes, but the CSS should not care about it.
The other half of the specificity problem is nesting. I advocate strongly against the descendant combinator ` ` in favor of the child combinator `>`. E.g. `.body > .content` is much more robust than `.body .content`. However, an alternate approach would be:
I think this would be more semantic (with or without the classes)
Sure, but what if you have more than another section that should be styled differently? Classes can help differentiate same-name elements with different contexts, so you don't need unwieldy structure-specific CSS selectors like main > section > main just main.semantic-class
main
> section
> main
text-decoration blink
If you try this with the method outlined by the OP, you'll end up with a giant css file.
I've used Bootstrap and been forced to use it on existing projects already engulfed in it. It isn't pretty on a large project. I've sworn off using Bootstrap in any new project that isn't a prototype for a hack day. The only things I borrow from Boostrap these days are some of the JavaScript niceties like modal, tooltip, and scrollspy. And when I do that I'm very explicit in what code I pull in to use those. Build th…
But you know what's worse than Bootstrap? The hand-rolled framework that rises out of the muck on a large project. At least Bootstrap is always the same. It's a lingua franca, and a decent one at that.