|
Let me start by saying I am the most vocal person about semantic HTML at my company, but it really depends on your purpose, and I'm not sure you are realizing you are taking a hard line. Also, I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong. Well developed solutions are always better than just explaining what's wrong unless there is no solution and the existing proposals are wholly unsatisfactory. Take a step back and realize that there is at least one more way of doing this. Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead (via the use of helpers and all other commonly accepted forms of duplication reduction). Your post basically declares this Doing It Wrong™, but I imagine that's just because you'd rather see better looking html than you would see better looking css. You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics. For most projects, the HTML is only used in a browser, and isn't the source of truth for the application, i.e. it is inherently coupled with the presentation. They might as well be one and the same because this is it's only purpose in the world. Leading from that, the only issue is maintainability, and here is where your ideas aren't fully developed. As will all separation of concerns, your solution (the one about breaking news) also adds a layer of misdirection. Sure I don't have to change the html to change the presentation, but now I have figure out where that part of the presentation is modified. My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds. It took probably 3 or 4 weeks for me to relent on this before I accepted, but it is much easier for everyone (think of the new hires as you pointed out!) if they don't have to know tons of info about the domain, but just look for the offending element and make a simple change in place rather than have to unravel the css toolkit to find where my button was made blue instead of green. Additionally, they know this change is only affecting this one element they were told to change. On our team, that is better maintainability because that is how real changes are specified. In your case, by the time this spec makes it's way to the developer, it needs to have traveled through people who know that part of the web page is a breaking news container and translated from whatever the original complaint was or the developer will likely have another problem to figure out before he can even begin changing what will likely end up being a single css rule. Loose coupling is simply about defining avenues of change, and it only improves maintainability when it enables making changes easier. This has been extrapolated to mean "does this have to change or not", which is over thinking it a bit. In my example, I made a typical update by changing exactly one thing in exactly one place, without having to traverse any levels of misdirection. Just figuring out how to make one thing not have to change doesn't make it more maintainable. When we're talking about web pages, it's also important to realize that we're typically not changing just the presentation of static data; we're adding and removing features to figure out what makes this page more useful. The HTML is typically going to change anyway when we're modifying the page, which again leans in favor of a common set of CSS selectors to build against (in terms of avenues of change). As I said, I'm probably the most outspoken person at my office when it comes to semantic HTML, but it's only when I'm describing actual data, i.e. the parts you read. These parts tend to change very little and can be generated and stored in their already rendered state. The parts that do change more often gain a lot from the benefits of OOCSS and BEM techniques. |
"They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds."
There's a whole series of unasked questions going on there:
* Why is the button blue - what led to that conclusion?
* Why is green the right colour?
* What about the other buttons, are they all the right colour? If so, why. If not, why?
* Why does the style guide for the site not specify this properly? (You have a style guide, right? Your CTO and designer did present you with an up-to-date, style guide, right?)
Asking these questions leads you to the semantic understanding of why buttons are supposed to exhibit specific characteristics. It's the WHY that's important, not the WHAT.
CSS excels when there's a requirement for consistency in design, and there's a style guide. When your requirements are a superficial "this button must be green" and you don't stop to ask why, then you've already sacrificed the semantic aspects of the documents you are supposed to be vocal about.
Also, how difficult is it to find what stylerule is causing the button to be blue. Right click on the button, click "Inspect this element in Firebug", in the CSS Inspector find the CSS rule that specifies the colour as blue. Look at the CSS selector itself - does it describe the semantic reason why the presentation is coloured blue? With that understanding of the semantic basis of the button being blue, you have an answer WHY the button is blue.
So now you need to understand why the button is supposed to be green. Get that explained to you, and now you have a good idea of the semantics you need to express, or reuse, a CSS rule that will cause the button to be rendered in Green.
This is where semantic class names win hands down, it tells you the WHY of styles. Without the WHY you don't have a basis for explaining why the button is blue, and no clear inkling of why now it should be green. And absolutely no idea which other buttons on the site are the wrong colour.
And that's about as far away as you can be from a consistent style guide, and presentational accuracy. If everything is ad-hoc, then nothing is consistent.