Ask HN: Why does this site use center and table tags?
I'm curious as to why a website made for developers by developers uses such bad practices? Table usage has it's merits but while reading the markup for the site I got a real 1999 vibe.
Is it because of a "if it ain't broke don't fix it" mentality?
Maybe it's just plain "who cares?"
60 comments
[ 3.1 ms ] story [ 142 ms ] threadWith that in mind ...
I'm always bewildered by people who ask this question. I don't understand what's wrong with using tables and center. No, it's not using the latest HTML5 standards, and it's not using bleeding-edge features, but
(a) it works
(b) it's fast
(c) it runs on both new and old browsers
(d) the HTML expresses the formatting intent
(e) in this context, separation of content from formatting is overkill.
So I'd be really interested to understand the alternate point of view. Apart from the obvious mistakes in the HTML, why is it regarded as bad practice?
Is it just because it's old?
PG has his priorities (and limited time). I remember him stating in another thread that any time he spends improving this site were on trying to improve its content, not other relatively meaningless problems like its formatting.
In the same circumstances I completely agree with his decision, but lets not pretend as font end code goes this is nothing else than a showcase of bad practices.
I think that would be really useful - thanks.
In particular, I don't understand:
I'd love to see how "modern" practices make it less verbose Until I can see something you claim to be easy to change I can't assess this. How are end users going to customise it? It's a web page. Actually it renders well on every browser I use, whereas most "modern" pages screwup royally on some of my browsers. That's one of the things I really don't understand. For reasons I won't go into, I use some really old browsers on some limited platforms. Frequently pages that are held up as examples of good design or good implementation render really badly, if at all. HN is one of the few sites I can browser on all my platforms, so I'd really like to see what you think would be better. I guess this is where my complete ignorance of modern web programming comes in, because I have no idea what this means.I appreciate your response, and look forward to learning more. I've wanted for some time to learn more about modern web programming, and despite several attempts I feel that it's just a foreign land. It would be great to get a real insight.
Thanks.
User-agent stylesheets, which play much nicer with CSS than HTML (<center> tags are evil.)
> Actually it renders well on every browser I use, whereas most "modern" pages screwup royally on some of my browsers. That's one of the things I really don't understand. For reasons I won't go into, I use some really old browsers on some limited platforms. Frequently pages that are held up as examples of good design or good implementation render really badly, if at all. HN is one of the few sites I can browser on all my platforms, so I'd really like to see what you think would be better.
HN renders the exact same on all three of the platforms I use -- Windows 7, iPad, and iPhone. This is not an inherently good thing, and it makes browsing a pain.
I've actually considered writing a sort of "proxy" website for HN that just rewrites the HTML to work better on a phone, just for my own use. If I ever get around to it, I'll let you know :)
> hard for end users to customise
I think, he means that a css-based ("modern") solution would allow end-users to just swap the css (a feature most web-browsers have as a built-in) to change the site's appearance - whereas you cannot change the way a <table> looks, for example. That is, you can't easily make <table> columns appear below each other, for example.
> works terribly in any other context than a desktop browser
The parent probably means modern non-desktop web browsers, i.e. ones with javascript and media-query support. Using media queries would allow automatically changing the site's appearance to something more usable for small-screen devices (for example) - by using bigger buttons/links/up-vote-triangles or something like that.
The problems you mentioned are orthogonal to that - mostly caused by devs that only target js-enabled modern browsers. That's bad, of course, but it's not part of "modern web development" per se - it's just bad web development.
> plays terribly with all other web tooling
If you use "modern" web-dev methods (that is, styling only per css), other (web-)services that display your site in different contexts (think google reader or desktop mail readers or something like that) can swap or remove the css and get the content (including semantics like "headline", "list" and so on) without the styling ("these are table columns", "this is centered"). In theory, at least.
I don't understand the rest of the points either, to be honest. <center> and <table> are very compact, compared to equivalent HTML/CSS solutions - that's part of the reason why people keep using them.
Lots of people apply custom stylesheets because the default one has a lot of flaws, or sometimes they just want to. See http://userstyles.org/
The fact that this website works terribly on mobile is unarguable.
Web tooling means the browsers inspectors tools, the css overrides plugins, there are millions of plugins / enhancement tools and most of them can only work given a reasonable set of html and css to work with.
The biggest benefit is simply separation of duties (context - html, format - css, function - js). It looks nasty as hell and is a pain to deal with when html, tag formatting attributes, css, and javascript functions are all combined in single tags, systemically throughout the entire site. Separating them all both reduces code reuse and makes the whole thing much more readable.
Also, implementing something like CSS Media Queries would be 'interesting' without separation of concerns.
[citation needed] x 4.
This is a recitation of the propaganda, yes. However, propaganda is not a logical argument. What about "<center>" is verbose? Do you have a CSS solution that is actually shorter than "<center></center>", while also being good CSS (and not just using 1 character class names)? Do end users really have a problem customizing the center tag? How so? CSS and XPath do not particularly have a problem with it. I use this site on my 3DS sometimes and it seems to work reasonably well. What "web tooling" matters, and how does it interact with Arc so horribly?
During the old CSS wars I sort of understood the argument for deprecating it, but with the way browser engines have been going, there's really no reason to pretend there's any reason to get rid of the element, because it's just one line in a definition file somewhere that specifies it as a block element with a certain default style.
Yes, that means you use tables, for tabular data, but forums are not tabular data. They are more akin to lists, which have their own rules.
HN Discussion on it: http://news.ycombinator.com/item?id=3902976
one time, in one place, in the CSS is a lot terser than:
<center></center>
repeated 20x per page.
As for the original question "why?" - my guess is because a) it works, and b) it's quick. Sometimes you need to be pragmatic about these things.
I know what you mean about many mobile sites since people often assume the only mobile devices are iPhones and Androids and nothing else, but that doesn't mean the way this site works is any better :)
However, CSS has, in the past, been extremely annoying to use if you want a simple tabular layout to your web site.
As other's have, or will point out, the table tags can end up being more data that you'll download each time the page contents are sent, whereas css, if you do it correctly - in a file external to the HTML - will only be downloaded one time, saving bandwidth and time.
If the site's author doesn't care about the SEO demerits of using a table, then she's not going to spend the time converting the site. This has the side effect of annoying semantic HTML purists, who believe that the HTML should only describe the content and only CSS should be used to apply styling.
While the semantic+CSS camp has a fair point, I will admit to being driven near raving mad trying to make CSS do things that were dead simple using a table. So I empathize with the people who don't want to spend large amounts of time figuring out how to make CSS do what they mean.
Definitely true. I'm usually in the semantic+CSS camp, but for lots of simple projects (which I'd say HN is) those considerations can really bog you down. Use tables -- knowing they're suboptimal in certain situations -- and get on with it.
If you've got a page with tabular data, use the table tag! It's semantically valid and a concise way to get the proper formatting!
But, if you're trying to lay things out - it's likely a grid layout will do the job better. Straight CSS is pretty hard to get right with all the floats, but starting with a grid system and especially something even higher level like Twitter Bootstrap can really be productive. Note, however, that bootstrap still supports and encourages tables when it makes sense.
b. not any faster than doing it without the deprecated and misused tags
c. you'd need to be a developer who hadn't updated their browser in over five years for this to be a concern... at that point you should probably find a different line of work
d. no, it doesn't, and this is the point. the data isn't tabular so it does not belong on a table
e. whaaaaaaaaaaaat
---
The reason I even brought this up is because I wanted to create an extension for the site; but this terrible markup isn't going to make things easy.
Plus it's heavy on my mobile phone because of all the tables.
I'm coming to the conclusion that the people who actually know and understand modern web programming can't actually explain things to someone who is an experienced programmer, but not a web programmer. I've searched diligently, and I've wasted a huge amount of time, but I've never managed to find anything that explains WTF goes on in modern web programming and/or development.
I've pretty much given up. It seems a completely closed shop.
I have a complicated life that means I use embedded systems, systems I've built, systems I've rescued, and a more modern desktop development system.
So, I don't spend a lot of time messing about with browser extensions or addons or other extras. It's not what I do.
Yes, I move in different circles from you, and while I'd like to learn about modern web programming, and feel I'm probably capable, I've yet to find a decent introduction, tutorial, and reference.
If you can offer any advice I'd be interested.
It will give you a good launching pad for HTML and CSS.
Thanks.
It's because it's semantically incorrect.
It's because positioning is done in the html. It is generally considered a good thing to separate areas of concern. Content in one place, style in another.
I think the answer is really only two things:
1) Accessibility. A screen reader can probably work better with semantically valid markup. I've not much experience with these, but it's my assumption.
2) Ease of development when making changes. This one is purely for the developer, not the end user. It's probably true, but there are definitely cases where just throwing a table at the problem is simpler than CSS, especially for someone not up on HTML5.
What else?
Separation of concerns is a design choice. I'm not sure what context you meant, but if you find that it's overkill, you can make that design choice that it's unnecessary. In general, I find separating these concerns leads to cleaner and more understandable code, but I can certainly imagine situations where your argument can be made, especially on sites that are simpler.
Some people do believe quite a bit in purity and believe the markup should just describe the data. I agree that it's nice but doesn't always work out in practice. This can get taken too far. For example, I've seen complex workarounds for centering vertical alignment when they could have just thrown a table, but they wouldn't do it because a table is for tabular data. In this case, I felt that the table would have been easier to read and understand. Again, this is my preference and others may disagree.
TL;DR; - It depends. And performance issues back in the day.
"(a) it works"
It does work, but when someone tries to reverse engineer the code( say to write a spider ) its difficult to read.
"(b) it's fast"
Thats probably true for sections of the html, but nested tables are not the fast.
"(c) it runs on both new and old browsers"
But nested tables aren't required in older browsers, they work with divs. Besides, who uses a browser that is older than 2000?
"(e) in this context, seperation of content from formatting is overkill"
Why? It makes quick changes much easier. I was fiddling with HN on firebug and had a hard time finding where everything was. There were tons of in-line styles that kept overriding the basic styles from the CSS file.
It's always better to change things in the CSS file, because it makes changes easier later.
I'm not saying for people to never use tables. But I think they should be used for what they were originally made for: tabular data. Some people go overkill trying not to use tables and that's not a good idea. Tables work really well when they are used right.
Wow, I never knew people actually thought it was easier. If using a table based layout you have to type many many more characters and keep a mental log of what's in where.
For anyone who doesn't do CSS professionally, tables are vastly easier. They're easy to understand, and generally do what you want.
It's just that, as time goes by and your site becomes more and more complicated, tables become less and less flexible and maintainable.
Right or wrong, there are many things about HN that are neglected. Layout is notoriously one of them. Expiring links is another.
PG either doesn't have time, doesn't care enough to change it or HN is written in a way where changing it would be a big project.
Probably all three. Crossing my fingers that this post doesn't raise the ire of moderators.
(The gray in the text of the submission above is so light to be practically unreadable, can't undo accidental upvote/downvote, can't collapse threads, hidden URL's like /best that don't have links to them, etc., etc., etc.)
Because it feels like it was hacked together in a weekend and never touched again.
Thank God the content is better than anywhere else, which makes up for it all! :)
The other part of the argument relates to accessibility and to my knowledge the latest accessibility tech can handle "messy markup" just fine.
For some, I think the internet has achieved a mature enough status that there is outdated, replaced technology that some of us miss, even if we understand it was replaced for very good reasons.
Are we having to explain why we don't use tables for layout in 2012!?
OK. Lots of reasons:
i) they create complicated HTML because presentation and meaning aren't separated. This makes it hard to manage if you want to make a layout change, or someone else needs to work on the site. ii) because content and its presentation aren't separated the layout isn't very flexible. It won't scale to fit on a mobile phone, for example. If the content was separated from its presentation you could feed devices the same HTML and take care of the presentation using CSS media queries. iii) because you use tables for layout rather than their intended purpose (to tabulate data) the site is inaccessible to users who are using a screen reader iv) using center tags is inefficient. Using .class-name {text-align: center;} is hardly difficult and saves you from trawling through your HTML should you want to get rid of the centring.
Isn't that enough?