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.
Most likely because PG or whomever else coded the site doesn't know how to use HTML with CSS, doesn't care to learn, and doesn't think it's important enough to learn.
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 think PG must have known, what I only ended up finding out myself after trying too hard to make everything CSS, is that it doesn't always need to be.
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.
CSS has a learning curve yes, so it always going to seem harder than it should be in the beginning, but otherwise it shouldn't make a difference time-wise to create a table or css 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).
Tables are embedded in the Arc code for news.yc, as brett mentioned, but probably it could be rewritten in a few hours for a list-based layout. Of course, changing the layout would require an Arc developer, which is the disadvantage to not using templates. You may have noticed that most hackers seem to think web design is unimportant and/or should require a programmer for each change.
NO it has not HTML errors, it has done that way to achieve the desired result, take a look at the source code if you like, don't rely just in the W3C validator.
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.
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?
Have you ever operated a website with over a hundred pages? Just curious.
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.
Who maintains 'hundreds of pages' of HTML? Don't you offload everything into templates or dynamically generate it? The last time I managed hundreds of pages of html, or even html with dynamic content spliced in, was in 2001, and that was against my will.
A quick rewrite took care of that too. HTML is an output format, not a language.
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 :)
It's been pointed out that HTML is not Turing complete. You can interpret a page as a state and a link as a transition. That makes HTML the equivalent of regular expressions. Definitely worthy of the title hack.
My only problem with table nazis is when they do their job poorly.
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)
That is. Table is 'not optimized object code' compared to lists. So you should ask: why your object code is not optimized (and it slow loaded and slow rendered on my PC :).
CSS is used for two purposes: for styling and for layout. In my mind, the value obtained by using CSS for larger site layouts is not much. Usually, the claim is that CSS layouts help you re-target the content for another device and stuff, easily. Based on my experiences, I think that's a grand dream not likely to come true. You have almost completely re-think your UI when you are developing for a different device. Re-using CSS layouts is nearly impossible for that.
I agree. CSS as a layout system is poorly thought out and even more poorly implemented. Why, to center an object, do I have to remember trivia like "the parent needs a width." You need hacks and non-intuitive tricks for cross-browser CSS. Tables are verbose, but they "just work" more often. I still use CSS layouts, but man what a steaming pile.
I'm open to new perspectives. In what way I should I see the page such that "center me in my parent" is unreasonable unless the parent has a fixed width? What, in particular, about the box model makes this impossible?
The notion of "center" doesn't exist without a width.
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.
>At any instant in time, every element on a webpage has a well-formed width.
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.
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, 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.
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.
I'll agree that that's the ideal, but I've also found that designers and clients are good at coming up with layouts for which it is far simpler to change the HTML than to try to contort it into the right places with CSS.
There are only three columns on the front page now, but when I was working on the site I experimented with different layouts in which there were more. Why constrain myself by using a degenerate case of tables?
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.
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.
I don't get it. Just because it's generated by Arc doesn't mean it has to:
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. 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.
You're changing the question on 1. Obviously whether or not I use tables is a separate question from whether the HTML I generate conforms exactly to the spec.
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.
That document you link to isn't part of the HTML standard. It seems to be an additional document from the W3C outlining how they'd like people to behave. Conforming to software standards is one thing; you have to do that to make programs work together. But complying with the W3C's wishes on how the web ought to be used is a very different matter. I feel like doing exactly what the W3C says on broader questions is not merely optional, but probably a mistake, considering the people who make it up. It would be like running your company according to a list of "best practices" compiled by a committee at General Motors.
I like YC's current look. Could CSS really improve it?
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.
with the value added to us readers, i think we can overlook this issue and get back to coding. would you yell at your girlfriend for cooking you a nice dinner and putting the fork on the wrong side of the plate?
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.