Homeopathic HTML Solutions
christianheilmann.com
christianheilmann.com
<div id="doc2" class="yui-t6"> <div id="bd"> <div id="yui-main"> <div class="yui-b" id="content"><div id="pad">
<div> is fine for layouts. It's not fine for labels.
My passive-aggressive point is that 'semantic html' is an academic concept with a peak in popularity amongst the web dev plebs around 2000 and an occasional flare-up of interest from new-ish developers who re-discover the fundamentals. CSS has failed to make add the 'presentation layer' on top of semantic html as we once thought it would. It's simply not powerful enough. For the dream of real semantic html to come true, CSS should be able to 'implicitly' add elements to the content to apply styling to, so that we can 'add' a div around the body content in order to center it on the page, to name one use case. The cold reality is that nobody cares enough. Just toss in a few divs, use simple tech like html and css to make it look good, send the invoice, go home. Let the Googles of the world care about machine-readable semantics (because that's what we're talking about here - 'semantic html' is BS from a human's point of view, a human wants to have semantics through styling, not separate from it!).
The continual references to 'assistive techology' in the post are especially laughable. Yes yes it's nice that blind people can use the web. Just as it is nice that people in a wheelchair can access buildings. I'm all for that, and I'd love to see more tech that allows people with bodies that function differently from those of the majority of people lead better lives. But arguing for 'semantic html' in that context is fighting wind mills and displays a gross lack of pragmatism. Let's spend our time on things that make the world better, rather than on talking about ways that would make the world better if only everybody in the world changed their behavior.
It's not hard to make good quality, semantic html.
It makes code more readable for the next developer, better for SEO etc.
You can use :before and :after to implicitly create elements.
Sometimes needs-must and we have to throw in divs and poor-quality markup (mostly thanks to old IE), but there's no reason for it to be the default standpoint if it takes the same amount of time.
:-O
Seriously? Please show me the site that does so, and still looks OK (or even OK-ish) by moderns standards?
"Sometimes needs-must and we have to throw in divs and poor-quality markup (mostly thanks to old IE)"
Look, I take it you are a web dev, am I right? If so, how can you say something like this? Please link me to the last 5 or so sites you made, and tell me which div's and span's you only put in to support old IE versions. Every real site out there today uses div's and span's in non-semantic ways. That was the whole point of my post - :before and :after don't cut it. CSS just isn't powerful enough to make real semantic html happen. It's not a value judgement, it's just stating the blindingly obvious. The fact that the GP's blog post, complaining about this, starts with not one, not two, but five non-semantic div's is a painful manifestation of this.
In < IE8 there's loads of <div class="clearfix"> around because display:inline-block wasn't supported.
Why don't we just call a spade a spade - real semantic html is impossible for the vast majority of real-world use cases, and all we're left with is trying not to fuck it up even more by using <div class="p">. Which brings us into, as I called it elsewhere, 'duh' territory.
It's also a legal requirement in the UK for both of those things.
> Just toss in a few divs, use simple tech like html and css to make it look good, send the invoice, go home.
Just whack in some stairs, nobody cares about the person in a wheelchair stuck at the bottom because it'd have taken longer to do things properly. Accessibility is hard, let's go shopping!
> The continual references to 'assistive techology' in the post are especially laughable.
Would you say that to someone struggling to read your site because you didn't take the time to use the right tags?
> rather than on talking about ways that would make the world better if only everybody in the world changed their behavior.
Screenreaders already exist, making your website accessible improves things even if nobody else does it.
I suppose I'm just confused at your anger over the suggestion that you use p for paragraphs, actually add labels to forms, use em for emphasis, section for sections and h1-h6 for headings. Is it really that hard?
Oh I'm not angry, that's just my way of talking. You should meet me in person some time, it's fun, really ;)
"over the suggestion that you use p for paragraphs, actually add labels to forms, use em for emphasis, section for sections and h1-h6 for headings. Is it really that hard?"
Oh no it's not, and everybody should do it. That's not what the 'semantic web' or 'semantic html' is though. But if he's going to talk about grandiose subjects like 'semantic html', then the discussion is about that, and 'semantic html' is dead and buried. If he just wants to say 'use p/label/em/hx appropriately', then just say so, don't bury it under pseudo-philosophical waxing (but then again, his post wouldn't have made HN, so as it is, mission accomplished, right?)
Semantic web != semantic html. Maybe that's the source of the problem here. The article says absolutely nothing about the semantic web.
Semantic html is absolutely about using tags correctly.
True, in the sense that "sustainability != solar power". They're different concepts that cannot be compared "by equality", to speak in those terms; but semantic html certainly is part of the semantic web.
Of course we can go around and redefine "semantic html" to mean "use <h1> instead of <div class="header1">, a heavily diluted interpretation of "semantic html" as it was conceived in the context of "the semantic web". And I cannot argue with the point that "semantic html" is being used that way sometimes, maybe even increasingly so. Now I have no interest in letting this discussion degenerate into linguistics, semiotics and descriptivism vs prescriptivism, but if we are to use that watered down definition, the whole article loses what could potentially have made it interesting and descends into 'duh' territory.
Redefine? I'm pretty sure it hasn't meant anything different. It's about semantically marking up a document.
> but if we are to use that watered down definition, the whole article loses what could potentially have made it interesting and descends into 'duh' territory.
But you assumed it was around that, then said that was dead. The other definition (the one wikipedia and everyone else seems to use) is something that lots of people still don't follow. Did you see the "new way of writing" last week? That had an article structure but didn't mark it up properly, screwing with the order when you removed CSS and made a big block of json invisible on the page.
In fact you yourself said:
> Just toss in a few divs, use simple tech like html and css to make it look good, send the invoice, go home
Can you see why that sounds exactly like the people who don't use things like <section>, <nav>, etc? The same people that won't bother putting in alt tags because 'nobody reads them'? In fact, XKCD is an example of buggering this simple thing up. HN is built out of tables, where replies are indented with a spacing gif. Basic semantic HTML is not commonplace.
On the down side, it's adding a fractal dimension to an already complex system, and things will probably get 'weird' until developers come up with new working patterns.
He's suggesting that we make our CSS selectors more complex while simplifying our HTML to make it more semantic.
While semantic HTML is a nice idea, it's not worth doing at the expense of well, basically anything else. It doesn't affect search engine ranking and there are easier ways to support assistive technologies (ARIA).
Making your selectors more complex comes with a great cost. Suddenly changes that would normally be simple cause cascading changes throughout your stylesheet and document because CSS is not very modular and complex selectors tightly couple multiple rules to your document structure.
This isn't an opinion or a matter of style. It is a simple, fundamental fact of computer science: that increasing coupling tends to make maintainability harder due to the number of cascading changes since multiple components depend on one another. And advocating Heydon Pickering's technique tightly couples your selectors to your particular document structure. Worse, it does so implicitly -- if you at least use class selectors this coupling is explicit and easier to reason about.
If he instead advocated something like SMACSS you'd have much more maintainable code.
I guess the closest might be, programming by coincidence/accidental implementation: http://pragprog.com/the-pragmatic-programmer/extracts/coinci...
How do you apply homeopathic concepts to web development?
Superstitious coding is one thing, programming by "random changes until it works" is another, but none of them approach the illogic of homeopathy (find a poison that mimics the symptoms you want to cure, then dilute it in water so much that there's very likely no actual poison molecules left in your sample, then consume that).
I'm unable to conceive of a development equivalent. That's the main reason I clicked on the article.
It's actually telling that the development equivalent of homeopathy is so obviously nonsense that no one would actually do it.
But you have a good start. Here's real homeopathic coding, then:
My code was performing poorly. So I created a new module that would run several time-wasting loops... then I gradually removed all of the code from my new module (so it does nothing). Then I linked it with my existing codebase - now my code should perform much better!