Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

That's not what he's saying. He's saying they're good at times but he took ages to realize that because the old table based layout using <table> used to result in extreme tag soup.

If you are looking for reasons why they're actually not that great anyway, this succinct post on /r/webdev reminded me why I haven't unsubbed from that highly variable sub:

http://www.reddit.com/r/webdev/comments/2k8ud2/why_does_no_o...

In this case, the example the OP gave at the beginning, a dashboard, can't work with a responsive layout using display:table, which is a feature you'd kinda expect in this day and age.

So they finally release a half decent display:table and it's too late as we now need responsive designs.

Pretty much sums up how pants the W3C process is.



> So they finally release a half decent display:table and it's too late as we now need responsive designs.

I'm not sure what you mean by "finally release." The display: table property was part of the CSS 2.1, which became a Candidate Recommendation in 2004 and an official Recommendation in 2011. It also works perfectly in IE8, which was released in 2009.

The term "Responsive Design," on the other hand, wasn't even coined until 2010, and didn't really become mainstream for another 2-3 years.

There were a couple of years when working with display: table was perfectly reasonable and the "Responsive Design" trend hadn't yet hit the tipping point.

I dislike overdone/late W3C processes as much as anyone, but this isn't a good example of that.


Even earlier, display: table was part of the original CSS Level 2 which became a REC in 1998 — twelve years before "responsive design" came into being. It largely followed what had been added to HTML 3.2 in January 1997 — based on what most browsers (with Netscape first) in 1996.

There's also a lot of unwillingness to do much around display: table — it remains largely unspecified (mostly because we basically know web compatibility requires you to do what IE6 does — and nobody knows quite what that is, and MS people have struggled to get permission to disclose the detail).


At least it was mostly copied from Netscape, and source for that is available as Mozilla Classic (from the cancelled Mariner project). I used it to figure out where HTML legacy color parsing come from.


Sadly, we know that what web compat relies on isn't quite what NN4(-ish) does, so the mere fact that that is available doesn't really help too much. :(


Actually, the same thing is true for HTML legacy color parsing too, but the only difference there is a few lines of code. I think it is these lines that was added (from http://mxr.mozilla.org/classic/source/lib/layout/layimage.c#...):

  if (bytes_per_val > 4)
  {
        bytes_per_val = 4;
  }


Table parsing is nowhere near that similar. It's almost certain IE's algorithm is largely different — it just obtains similar results to NN's in most cases.


But yea, I have been thinking of the idea of a IE only shared source program for a while now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: