4 ms·
There's little point complaining about the current state of front-end development while we're on the cusp of the next generation of front-end technology. e.g.
by secoif 13y ago
There's little point complaining about the current state of front-end development while we're on the cusp of the next generation of front-end technology.
e.g. Non-semantic HTML is avoided with Shadow-Dom + Custom Elements + aria attributes & JavaScript library management is mostly solved by ES6 modules.
- cnorthwood 13y agoSemantic HTML is possible now, but the way our tools have been built (and documentation written - e.g., add this class to your element) makes it hard to do the right thing
- integraton 13y agoI'm guessing by your name that you are the author. In the post you ask: > why does every single Sass/Less framework suggest first in the documentation that you should write your HTML like this? Most major Sass grid frameworks encourage semantic HTML and always have. See, for example, Chris Eppstein stating the rationale behind blueprint-sass in 2008: "The biggest advantage of using the "sassified" version of blueprint is that you can use semantic class names again and stop putting "display classes" in your markup." - https://groups.google.com/d/msg/blueprintcss/Yyx9PpZpCRA/wq1nRU5gxloJ https://groups.google.com/d/msg/blueprintcss/Yyx9PpZpCRA/wq1... Both Susy (http://susy.oddbird.net/ http://susy.oddbird.net/) and Bourbon Neat (http://neat.bourbon.io/ http://neat.bourbon.io/) follow in this tradition. The Foundation and Bootstrap documentation is targeted at people using the generated CSS, which is why they use non-semantic class names. I'm not familiar with Gumby, but there is no good reason for them to encourage non-semantic class names when using SCSS, although presumably they are assuming their main users are similar to the CSS-only users of Bootstrap and Foundation.
- cnorthwood 13y agoThat's great, I wasn't aware of those frameworks, thanks.