6 ms·

Homeopathic HTML Solutions

26 points by bergie 13y ago

danso 13y ago
Not bad points about HTML/CSS maintainability...but I'm disappointed that the homeopathy analogy wasn't actually used. Now I'm racking my head trying to think of amusing homeopathic-like coding practices...because even coding has its share of superstitious rituals. I guess the closest might be, programming by coincidence/accidental implementation: http://pragprog.com/the-pragmatic-programmer/extracts/coincidence http://pragprog.com/the-pragmatic-programmer/extracts/coinci...
- Udo 13y ago
  I know the phrase is pretty high on everybody's most-hated list, but Cargo Cult programming in any form can come pretty close to placebo/homeopathic solutions.
- jtheory 13y ago
  I read the first few sentences of the post, saw what it was about (okay, fine), and then searched the page for "homeopath" to see if he actually referred to homeopathy at all. 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.
  - scott_s 13y ago
    My code was broken. So I fixed it. Then, after testing, I removed the fix, because the surrounding code will remember the fix even in its absence. It's actually telling that the development equivalent of homeopathy is so obviously nonsense that no one would actually do it.
    - jtheory 13y ago
      It's worse than that, because you're forgetting the principal of "like cures like" (you "treat" the person with water that's remembering the poison that would cause similar symptoms to their disease). 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!
roel_v 13y ago
It wasn't quite clear to me what he was arguing, but if it was that people should write semantic html and not abuse div and p, I suggest he start with looking at his own website. Or try to make a modern design without said abuse. There's something ironic about a post that says "Think if what you did in HTML really gives the content meaning or if you just painted with tags." and then has this right after its body open tag: <div id="doc2" class="yui-t6"> <div id="bd"> <div id="yui-main"> <div class="yui-b" id="content"><div id="pad">
- rob_mccann 13y ago
  He wasn't arguing against <div> elements. He was arguing against using wrong elements. <div> is fine for layouts. It's not fine for labels.
  - roel_v 13y ago
    OK let's say that he's saying that, but then what does that mean? Don't use <div class="para">, but use <p> ? That's about it, then. He rages against 'painting with tags', but then what is 5 nested divs? It certainly doesn't add any semantic meaning, not in the way they are being used in the website. 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.
jplur 13y ago
After spending the weekend playing with the new web component stuff, I have a feeling that HTML is going to be written for humans again. Layout and Interactive 'sugar' can be hidden away leaving the content and hierarchy that we want to read or write. 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.
AdrianRossouw 13y ago
so, plain text then?
gweinberg 13y ago
Is there a particular menaing to "homeopathic" in this context, or is the author just using it as a bizarre synonym for "bullshit"? If you're trying to encourage clarity, why would your post a deliberately obfuscated title?
- roel_v 13y ago
  Well according to another post in the front page, being on that front page is worth about $3K + some intangibles if you play your cards right, so there is the answer right there...
caryhartline 13y ago
Glad to see that semantic HTML is being promoted here. There are a lot of programmers who think doing everything in <div>'s and <table>'s is "just fine".
peterhunt 13y ago
This is really bad advice. 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.
- idProQuo 13y ago
  I'm new to web development, so I haven't dealt with a truly hairy stylesheet yet (though I've had plenty of experience with overcoupled and hard to maintain code). Do you think tools like Sass can help alleviate some of these CSS problems? I've heard that some people who go crazy with Sass end up with a couple thousand selectors, yet the organization and logic helps them manage the complexity.
  - peterhunt 13y ago
    Variables are certainly awesome, but it's easy to get stuck in a situation where you generate giant stylesheets. It also doesn't really solve the selector modularity problem :/

26 points by bergie 13y ago

danso 13y ago

Not bad points about HTML/CSS maintainability...but I'm disappointed that the homeopathy analogy wasn't actually used. Now I'm racking my head trying to think of amusing homeopathic-like coding practices...because even coding has its share of superstitious rituals. I guess the closest might be, programming by coincidence/accidental implementation: http://pragprog.com/the-pragmatic-programmer/extracts/coincidence http://pragprog.com/the-pragmatic-programmer/extracts/coinci...

Udo 13y ago
I know the phrase is pretty high on everybody's most-hated list, but Cargo Cult programming in any form can come pretty close to placebo/homeopathic solutions.
jtheory 13y ago
I read the first few sentences of the post, saw what it was about (okay, fine), and then searched the page for "homeopath" to see if he actually referred to homeopathy at all. 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.
- scott_s 13y ago
  My code was broken. So I fixed it. Then, after testing, I removed the fix, because the surrounding code will remember the fix even in its absence. It's actually telling that the development equivalent of homeopathy is so obviously nonsense that no one would actually do it.
  - jtheory 13y ago
    It's worse than that, because you're forgetting the principal of "like cures like" (you "treat" the person with water that's remembering the poison that would cause similar symptoms to their disease). 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!

roel_v 13y ago

It wasn't quite clear to me what he was arguing, but if it was that people should write semantic html and not abuse div and p, I suggest he start with looking at his own website. Or try to make a modern design without said abuse. There's something ironic about a post that says "Think if what you did in HTML really gives the content meaning or if you just painted with tags." and then has this right after its body open tag: <div id="doc2" class="yui-t6"> <div id="bd"> <div id="yui-main"> <div class="yui-b" id="content"><div id="pad">

rob_mccann 13y ago
He wasn't arguing against <div> elements. He was arguing against using wrong elements. <div> is fine for layouts. It's not fine for labels.
- roel_v 13y ago
  OK let's say that he's saying that, but then what does that mean? Don't use <div class="para">, but use <p> ? That's about it, then. He rages against 'painting with tags', but then what is 5 nested divs? It certainly doesn't add any semantic meaning, not in the way they are being used in the website. 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.

jplur 13y ago

After spending the weekend playing with the new web component stuff, I have a feeling that HTML is going to be written for humans again. Layout and Interactive 'sugar' can be hidden away leaving the content and hierarchy that we want to read or write. 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.

AdrianRossouw 13y ago

so, plain text then?

gweinberg 13y ago

Is there a particular menaing to "homeopathic" in this context, or is the author just using it as a bizarre synonym for "bullshit"? If you're trying to encourage clarity, why would your post a deliberately obfuscated title?

roel_v 13y ago
Well according to another post in the front page, being on that front page is worth about $3K + some intangibles if you play your cards right, so there is the answer right there...

caryhartline 13y ago

Glad to see that semantic HTML is being promoted here. There are a lot of programmers who think doing everything in <div>'s and <table>'s is "just fine".

peterhunt 13y ago

This is really bad advice. 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.

idProQuo 13y ago
I'm new to web development, so I haven't dealt with a truly hairy stylesheet yet (though I've had plenty of experience with overcoupled and hard to maintain code). Do you think tools like Sass can help alleviate some of these CSS problems? I've heard that some people who go crazy with Sass end up with a couple thousand selectors, yet the organization and logic helps them manage the complexity.
- peterhunt 13y ago
  Variables are certainly awesome, but it's easy to get stuck in a situation where you generate giant stylesheets. It also doesn't really solve the selector modularity problem :/