Ask HN: Why does this site use center and table tags?
60 comments
I'm not the site owner, and I'm not a web developer. I'm a big iron programmer who writes algorithms and implements processes for dealing with specialist data. I've written HTML, but not since v2.0. I'm not up to speed with CSS or HTML5, although I've glanced over the specifications and have some idea of the concepts.
With 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?
With 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?
Its verbose, hard and slow to change, hard for end users to customise, works terribly in any other context than a desktop browser, plays terribly with all other web tooling.
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.
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.
"Its verbose, hard and slow to change, hard for end users to customise, works terribly in any other context than a desktop browser, plays terribly with all other web tooling."
[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.
[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.
HTML is presentation and CSS is the design and one does not mix the two on a properly designed site. If they are independent, it become possible to change the look of the site, independent of the data presented.
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.
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.
Yes, that's the propaganda. I don't think reality has worked out that way. At least, I've never seen a site get overhauled via CSS alone on anything other than demo sites designed for that explicit purpose. Since CSS now lets you override anything and turn tables into lists and lists into tables, it hardly matters any more, and the entire concept of "semantic" is just a sick joke unless the word "context" shows up somewhere, which it never seems to in these conversations, and in particular, hasn't got much place here either.
I hate to bring that site up, but 4chan's recent overhaul was a move to HTML5 and CSS from table-based design for that very reason.
HN Discussion on it: http://news.ycombinator.com/item?id=3902976
HN Discussion on it: http://news.ycombinator.com/item?id=3902976
.a, .bunch, .of, .selectors, .youd, .use, .anyhow {
text-align: center;
}
one time, in one place, in the CSS is a lot terser than:
<center></center>
repeated 20x per page.
one time, in one place, in the CSS is a lot terser than:
<center></center>
repeated 20x per page.
Well, in order to help me (and no doubt others) to learn further, would you be able to produce what you consider as good html that produces a page that looks effectively the same? I'm specifically asking not for a redesign, I'm looking to be able to compare "good code" against "bad code" to produce this layout.
I think that would be really useful - thanks.
In particular, I don't understand:
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.
I think that would be really useful - thanks.
In particular, I don't understand:
* It's verbose,
* hard and slow to change,
* hard for end users to customise,
* works terribly in any other context than a desktop browser,
* plays terribly with all other web tooling.
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.
> How are end users going to customise it? It's a web page.
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.
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'm not the parent, but I do web development - here's how I understand it:
> 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.
> 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.
http://www.icombinator.net/#_home is a reasonably decent example, its very obvious from reading the source that it is easier to read and understand (I am not even sure I can remember what vspace="" does). Instead of duplicating inline styles for every element you use minimal markup and use CSS to style the page. There are a few advantages to this: CSS caches, dynamically generated html with inline styles do not, its easier to edit, click inspect on the page and change some of the css, the whole page changes, you dont need a change + reload cycle.
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.
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.
Probably worth mentioning that the icombinator home page is a 6KB download vs a 25KB one for ycombinator.
For a simple site like HN you won't see much benefit in rewriting it. Complex, heavily-styled websites are where HTML4/5 shine.
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.
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.
> Well, in order to help me (and no doubt others) to learn further, would you be able to produce what you consider as good html that produces a page that looks effectively the same?
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 :)
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 :)
The main problem for me is it makes the site pretty painful to use on a mobile browser. With proper markup and good CSS, the site could easily be much more usable on a smaller screen.
Interesting. It works fine for me on my mobile device, and on my netbook, whereas other modern mobile sites often don't.
It "works", but not without copious zooming and scrolling. Clicking the vote buttons in particular is a kind of challenge I don't like subjecting myself to and I actually find I vote on comments much less frequently on my phone than on my desktop browser just because its such a pain.
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 :)
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 :)
I agree about the voting buttons and mobile use in general on this site (many links are small and hard to hit) but to be fair that has nothing to do with the use of table tags and center.
What mobile device do you have? It's impossible to read on my iPhone.
I wouldn't say it's impossible to read on my 4S, but it is certainly not "optimal", due to the table-based layout (with large margins). The page is zoomed out quite far when first loaded. Text is rendered pretty small, even when you double-tap to zoom in on the content "column". It's readable for me, but I still have pretty reasonable eye-sight. I can imagine it would be a lot harder if your eyes were even just slightly less capable than mine.
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.
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.
Do people really read the desktop version on mobile? The hn.gethifi mobile site is excellent!
Renders perfectly well on my Blackberry (foist upon me by work)
Same here. I'd add that trying to get better content is not completely decorrelated from improving the interface. In fact, it could have a negative correlation: only those who really have something to say would use ugly and unfriendly interface...
Google said they would rank sites that use tables for structure lower than they would rank site that used semantic HTML and CSS.
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.
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.
> I will admit to being driven near raving mad trying to make CSS do things that were dead simple using a table.
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.
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.
When data is tabular, tables make sense. I think there's been a lot of brainwashing that tables are evil; really, it's just that tables aren't ideal for layout.
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.
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.
I agree. My point was that pre-css-grid, it was easier to use a table to build a pages's layout than it was to figure out the wibbly-wobbly divvy-floaty stuff.
I'm not going to regurgitate what's already said here:
http://stackoverflow.com/questions/83073/why-not-use-tables-...
---
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.
---
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.
Here's the key:
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 wanted to create an extension for the site;
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.
You have never used a web extension/addon? Are you browsing the web using Lynx? Stallman, is that you?
Correct, I have never used a web extension or addon. I use Konqueror 3.0.3 on KDE 3.0.3, I use Konqueror 2.0, I use Firefox 2.0.11, I use Firefox something or other than comes with Ubuntu 12, and another Firefox that comes with Ubuntu 11, I use the browser that comes on the Blackberry bold, I use my own web browser/fetch system on a machine that I built by hand, I use Chrome on Ubuntu 12, I use Chrome something on Windows XP, and I use Lynx.
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.
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.
Start by reading http://www.htmldog.com
It will give you a good launching pad for HTML and CSS.
It will give you a good launching pad for HTML and CSS.
Last time I tried htmldog I found it an exercise in extreme frustration, but I assume it's changed, and based on your recommendation I'll give it another go.
Thanks.
Thanks.
It's not because it's old.
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.
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 question is _why_ is it important to be semantically correct, not do positioning in the html, and to separate areas of concern. Note - I agree with you, I'm just clarifying the question.
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?
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?
The main reason I avoid tables is because of my previous experience. Tables, and especially nested tables that wrap the entire site, would be noticeably slower when changing styles dynamically. For example, changing the positioning of an element on hover when the element is deeply nested in divs. The second I removed the tables, this was calculated much faster. This was about five years ago so I have no idea if this performance concern exists any more.
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.
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.
It's basically OK to keep older styles, but:
"(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.
"(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.
a) Agree
b) It's fast? More markup = faster? Definitely not the case
c) You mention HTML5 & CSS3 which some browsers don't have full support for but considering none of those features would be required for HN I don't understand this point at all. How far back to you need to go to find a browser that doesn't support "background-color"?
d) Why is this a pro?
e) What context would it not be considered overkill? Completely arbitrary decision.
Yup, you're definitely not a web developer.
Regardless of the answer, I have a very hard time believing that, if shown a random site also using <center> tags and a table layout, HN commenters would be as defensive and accepting of the usage.
The real answer is probably "PG doesn't give a shit".
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.
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.
Part of the argument for designing with web standards (i.e. using semantically appropriate tags) is that it makes things more maintainable. But this only applies if you're coding in (X)HTML. For this site, pg codes almost exclusively in Arc so he only has to worry about keeping that code maintainable. In general, you should only worry about the source language, not the object code it spits out.
The other part of the argument relates to accessibility and to my knowledge the latest accessibility tech can handle "messy markup" just fine.
The other part of the argument relates to accessibility and to my knowledge the latest accessibility tech can handle "messy markup" just fine.
Pg has gone on record (one of his essays - I'm mobile or I'd find it for you) as preferring table based layout for his own projects because it's easier to understand and hack. The HTML layout in arc is thus table based, and hn is written in arc. So there you have it.
>because it's easier to understand and hack
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.
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.
If using a table based layout you have to type
many many more characters and keep a mental
log of what's in where.
Honestly, understanding how to use floats and clears properly is one of the hardest "computing" concepts to learn out there. First of all, they're a completely non-intuitive way of structuring layout, and secondly, they can break in 1000 different ways if you don't know exactly what you're doing.
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.
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.
I used to believe in <div>, but nowadays I just believe in whatever works. I haven't noticed any rendering problems on HN, so I'm not sure what the problem is.
Probably for the same reason the site has terrible graphic design, usability, and discoverability.
(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 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! :)
I agree on the content, it has a lot of interesting things directly related to my profession. :)
Dare I say that many HN readers (myself included) enjoy HN also because of it's "vintage" look-and-feel. Yes, it does hearken back to the AngelFire/Geocities days. It feels like a calling back to the time of some of the web's first innovations.
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.
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.
You could keep the 1999 vibe with CSS.
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?
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?
Because it works just fine, that would be my guess.
This compatibility of HN is far superior than both of reddit's mobile versions. Please don't fix what isn't broke
This site is a bad example but tables aren't inherently bad. For tabular data or charts they are just fine, but should not be used as a tool for layout.
That's just the point. Using tables for layout is what's causing the 1999 vibe.
It works! ;)
I guess it's because they work.
Is it because of a "if it ain't broke don't fix it" mentality?
Maybe it's just plain "who cares?"