Ask YC: Why is YC's layout table based?
I'm a big fan of HTML, and I really don't understand why Hacker news is using tables instead of lists.
Lists make a lot more sense than tables in this case, also the CSS will be easier to modify.
People might down-mod me for that, but it's basically the truth.
Now, the only real benefits that Paul would probably consider CSS giving him would be the bandwidth usage (stylesheets are cached) and maintenance issue.
I can't imagine either of those two would be enough to coerce him into learning a whole new way of doing things.
I certainly think that PG is missing many more benefits by not coding the site properly, but from his vantage point, (and everyone else who would see learning css as confusing and pointless) it's likely that the risk/reward assessment is not pointing in favour of a tableless layout.
I kinda wish I could have an outter body experience +add that with time travel, and go back a few months so I can kick my old self in the ASS(twice) for wasting hours trying to make a forums page in all CSS, only to give up and accomplish it with tables, in what felt like seconds compared to the time I had spent previously.
CSS is of course a really good thing, especially if your building a big site(my site still mainly CSS based), But there's no need to spend unneeded time on things that the end user won't see,notice or care.
Correcting IE6 bugs on a mainstream site is part of the job. (and not that bad once you get the hang of it unless you've got a heavy design)
I'd be very surprised if a CSS version of Hacker news needed any IE hacks at all really.
Not this again...
The answer being who gives a shit? Does it look fine in most browsers?
As a web developer, you should. It will save you work in the long run (see below).
As a hacker, you should, the same way you care about the beauty of readable code in any other language.
As a business owner, you should, because it will save you money, in bandwidth costs, future maintenance, training etc etc.
>Does it look fine in most browsers?
It looks fine in most browsers because the browser decided to make it look fine. That doesn't mean that it'll look fine in the browser everyone is using tomorrow. That means more work for you down the road, for no particular reason.
Do I care about it? No, not really. But I do get a little annoyed at hackers that concern themselves with code elegance in every language except HTML.
That's the biggest lie of them all. And maintenance? No one does that, they do re-writes. How many hours have I wasted on this joke of not using tables?
And as far as hours wasted, having coded both ways, and originally viewing css as stupid and more work, I can now code a website in half the time using it than tables.
In fact, when I'm just hacking something quick, it's great not to bother with any layout at all and just come back to it when I have the time. You can't do that with tables.
If you are a programmer on a large site you won't touch the design. It will be done by a skilled designer, or designing firm. You won't care how its done whatsoever.
There is a lot more to say here...but basically you won't touch the design. Or want to. Or care how its done :)
The reality has always been quite different.
At least churning out valid XHTML+CSS from Photoshop designs has now become a commodity business: http://onwebapps.com/39-photoshop-psd-to-xhtml-css-services/
A quick rewrite took care of that too. HTML is an output format, not a language.
CSS with semantic HTML achieves this, embedded presentation does not.
The hell it does... Not to mention that separating the two is such a futile waste of time in so many cases.
Should you, as a developer (ahem... I mean hacker), care about the quality of the markup your app is producing. Definitively yes..
i.e. they insist on a tableless layout, yet when you look at their design in IE6/7, the right sidebar always seems to end up at the bottom of the page.
So instead of working on real code / markup, you always seem to be fixing a broken sidebar CSS issue, due to insistence on not using tables. (i fix these problems in 5min w/ a table-based layout)
But then you'll note that his code is full of tab, tr, and td macros so it's not like html tables are completely abstracted out. So a better answer might be that he puts a premium on quickly getting things out that work and ignoring details that the user never knows about; I'm guessing you didn't know the page was table based until you looked at the source. I'm also guessing that it's as easy for him to make arc changes as it would be for you to make the corresponding css changes (were the page list based).
Programmers love to read beautiful code, As a web designer, I love to read beautiful and meaningful HTML. ;)
The only reason to do something differently is a client requirement, or a desire on my part to get someone else to do stuff for me.
That's refreshingly honest. :)
First one is on line 34. An end tag isn't finished . . . there are several more, and I am not even a web designer.
That's a lot of nerve, criticizing the work of others, while not getting your own done right.
If you find any error, let me know and I'll fix it. Thanks.
On the other hand I'm not criticizing any HTML errors, I'm just saying that for this case a list suits better than tables.
Sounds familiar, the whole "it's not a bug, it's a feature!"
I DID take a look at the source code, that is how I saw that . . .
Speaking of the W3C validator . . . I suppose YOU would know better than they do when it comes to HTML, right? Right.
I found an error and you claim it was intentional.
No one asserted that you were criticizing HTML errors (nice attempt at a strawman) I stated that you ARE criticizing the work of others while not getting your own done right.
:)
On the internet, it shouldn't matter. :)
Because you're still viewing the page as a table. Once you stop doing this, you stop asking questions like these.
Now, you could give the object in question a width and simply give it margin-left/right: auto. That would center it in the width-less parent, but it wouldn't fix its position to the particular spot you're currently seeing it in.
For understanding, take it up to the highest level, the browser window. Make your browser 1024x768. Now make it bigger or larger - where is the "center"? It's moved depending on the size of the browser window.
If you have a parent whose width is variable, you can't center the child. The key is that, unlike years of using tables to hack up a website, the canvas CSS uses is variable; its height and width is undefined. Thinking of it like this, it makes perfect sense that center isn't used.
That's not exactly true. Every block element has a width, but inline objects do not. Furthermore, some block elements may have fixed widths, while others may be designed to take up as little as they require.
The "center" attribute that you describe would run counter to the visual formatting model of the standard that is in place to support a number of other things. That would mean that its behaviour would be next to impossible to design around if you were trying to account for all of your users screen sizes at the same time.
See here: http://www.w3.org/TR/REC-CSS2/visuren.html#containing-block
See, there's where we differ. I'd like to easily design a webpage that renders fine on 90% of my user's screens. I'd bet 90% of my users will be using personal computers, and use a resolution between 800x600 and 1920x1200. Want to look at my page on your non-iPhone? I'd love to introduce you to the m.mypage.com section of my site.
Something like "Center a child relative to a parent" isn't hard to do (we do it at work for our video game GUI), and it really seems like a few architecture astronauts got ahold of the CSS standards to cause these API usability problems.
Also, arguments like "You can't do that simple thing because.." are starting to sound like the arguments C++ pundits use to justify its monstrous complexity compared to C.
parent {}
child{ margin-left: auto; margin-right: auto; width: 100px; }
child{ center: horizontal; }
1a. child is 0px wide.
2. semantics: You're basically saying "Why isn't language x exactly like language y/how I want it to be?"
3. margin is what you're adjusting, so saying margin-auto makes sense.
4. Layers and layering are an important aspect of CSS, you've just broken all of them.
1. To the parent, the width of which is known by the layout code of the browser at any moment at 'runtime'.
1a. Fair enough, then it won't show up. But it will not-be-there centered, goddammit!! >:)
2. Which is a very fair question, and how languages get better.
3. That is one way to look at it, the one the language seems to force into you, and apparently it's the least intuitive.
4. If you can get an exactly equivalent effect with other expression, how come you can't have "center horizontally" just become an alias/shortcut/abstraction for that, if newbies expect it?
Then again, this is only an issue for hand-coded CSS. If you use your HTML/CSS as object code, this is easy enough to abstract in your generating code.
Bingo! And that's one reason Arc is pretty exciting. I'll be able to do the equivalent of center: horizontal, and the details can be abstracted.
You don't re-use the CSS, you re-use the HTML. That's the point. All it needs is a new style sheet, not a whole new webapge.
Seriously though, it's not just a list, it's an ordered list.
But seriously, you can play that game forever. At some point, you have to pick one definition and stick with it. This site uses tables.
Not worth arguing over in all but the lowest levels though.
I can't believe this thread has 49 comments (and counting). What a classic bicycle shed.
But seriously, what do you mean degenerate case of tables? CSS?
I suppose my biggest gripe is a statement like that; once understood and learned, HTML w/ CSS is actually easier to use. It's easier to code, re-code, fix, format, and just generally muck around with.
Aside from that though, inconsequential.
HTML w/ CSS is actually easier to use
You just don't seem to get that I don't use html. I generate it. Your argument is like saying it's easier to write programs in old-style instruction sets than RISC ones. Sure, but the best approach of all is to write in neither, and instead have a program generate it. Then it doesn't matter which you use.
Complaining that the html source of a software-generated site is ugly is like complaining that the code generated by the compiler of a high level language is ugly. Of course it's ugly; that's the whole point of high level languages.
1. Your generated code is fast becoming obsolete, even IE passed Acid 2 the other week. That might be a concern.
2. What do you do to fix it when things go wrong, especially given number 1?
1. Ignore web standards, 2. Forgo readability, or 3. Make bloated code.
I mean, look at the source of hacker news. Its just not elegant. Whether or not you believe it should be, HTML/CSS was designed to be coded a certain way and browsers expect that format. Why change it and suggedt that you're turning HTML into something it isn't ?
2. Html is object code. What matters is the readability of the source code that generates it. Worrying about the readability of the output of a compiler is akin to premature optimization.
3. The front page of News.YC is 30k. If you think that's bloated, I hope you don't visit sites that contain images.
Do you understand what I mean about the distinction between source and object code? Saying that html ought to be elegant implies that you don't. As a rule, the more elegant the language, the less elegant its object code is, because the further removed its concepts are from the primitive concepts used by a compiler.
2. I guess we know where you stand on the semantic web, don't we! :-) (http://en.wikipedia.org/wiki/Semantic_Web)
3. It's your bandwidth money. I'm not paying for it. (Of course, I would disagree with the GP that HN is bloated)
2. Ill admit defeat on this point. (but see below)
3. With all the td, tr, etc tags, it seems messy. I don't know for sure, but I think using a stylesheet could reduce the size. I'll code hacker news in CSS when I have a few minutes and try to get the HTML+CSS under 30k.
Relatively, its a small site. That's awesome because it loads fast and I can comment using my treo, like I am now. Thanks for spending so much energy on speed.
But if it can be smaller by using CSS, I think that's a reason to switch. Don't you?
Anyway, regarding source/object code, I don't mean to disagree with you. I'm just saying that HTML was designed to be looked at and Hacker News disregards all of the convention there. I guess that's okay, its just extremely unusual.
As for speed, no: when you've got a site down to 30k, you shouldn't be spending time making it smaller.
Are you sure HTML was designed to be looked at? I thought it was a subset of SGML, which as far as I know was a portable representation for the kind of documents that would ordinarily be seen with a WYSYWG editor. But even if HTML had been designed to be manipulated by hand, the general trend in technology is always away from that. Machine language was designed to be looked at. Then technology advanced and people started using programs to generate it.
Are you saying that the future of HTML looks like what happened to machine language?
Here's a suggestion. If you think the answer is yes, then how about posting a link to a site that could show us how and we'll up/down mod your post accordingly.