Comment by iroboto | Hacker News Reader

Comment by iroboto | Hacker News Reader

The arguments presented seem like a half truth to me.

1 HTML multiple CSS not 1 CSS multiple HTML

The whole concept should be that HTML should be written to have 100% accessibility across all readers (browsers and mobile devices), meaning someone with the most ancient browser can read the page and understand the content of everything without any form of presentation.

What the author has done essentially is the following: Try reversing some words in a sentence and then later complain that English is flawed because the sentence no longer makes sense reading it left to right.

The HTML won't make any sense if you start reversing it... I mean what is the point of putting <h2> tags below your <p> when it's obvious that the <h2> tag is acting as the heading for the <p> below. I wouldn't be able to read that, so why is CSS @ fault?

The logical flow of the content should be based upon the reading the raw HTML in a procedural order. This will keep it simple for coders to update the content, and css artists can pump many different layouts and show many different layouts to clients in a matter of seconds.

Good CSS also requires good HTML. Why the author of the article is using a div container to wrap them all when a body tag exists is beyond me.

I think as much as we point our fingers at css as a flawed language, we need to point our fingers at how write our HTML as well.

www.csszengarden.com

> I mean what is the point of putting <h2> tags below your <p> when it's obvious that the <h2> tag is acting as the heading for the <p> below. I wouldn't be able to read that, so why is CSS @ fault?

Nobody is talking about putting headers after the content they're introducing. The author is talking about a situation where it makes sense to order the markup one way, but CSS demands it to be done a different, not easily readable way. Which does happen sometimes.

> Why the author of the article is using a div container to wrap them all when a body tag exists is beyond me.

This looks like a ridiculous statement to me. But please, explain further what you want him to do.

I find it comical that you go on about "good HTML" and then point to CSS Zen Garden, where the HTML is inextricably bound up with the presentation (ie, adding wrapper elements to allow for flexibility in styling). CSS Zen Garden is an example of HTML as it should not have to be.

CSS doesn't demand it to be done differently though. If the HTML is written with a different flow the CSS will need to be written to accompany that.

I won't say it's perfect, but if you wrote div col 1 div col 2

and then you wanted col 2 to be on the left of col 1, you'd write the css differently then you would the forward method.

>This looks like a ridiculous statement to me. But please, explain further what you want him to do.

Well look at it this way <html><body><div container><stuff><div container></body></html>

What is it that div container is doing so well that body isn't already doing as a binding tag?

> I find it comical that you go on about "good HTML" and then point to CSS Zen Garden.

I will have to disagree. CSS Zen Garden reads perfectly and logically without css. It's something that 90% of sites are missing out there. And although the HTML is inextricably bound up with the presentation as you write, it is 100% readable by Netscape 1.0.

He uses HTML to describe the data that is being wrapped in the tags, and the information that is grouped by divs are grouped by the fact that the content is related, not by the fact that the data should be visually sitting beside each other.

While there is excessive usage of <span> tags written throughout, it was a design decision to enable css artists to replace text with images, or allow them to get around browser quirks that are challenges that CSS still face today.

> and then you wanted col 2 to be on the left of col 1, you'd write the css differently then you would the forward method.

At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.

> Well look at it this way <html><body><div container><stuff><div container></body></html>

The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.

> CSS Zen Garden reads perfectly and logically without css.

I didn't say that it's hard to read. I said that by the standards community's definition it is not good HTML, because it mixes content and presentation.

Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.

>At the cost of a lot of flexibility. Most people, when faced with a change in design like this, simply reorder their HTML. So perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.

I don't doubt that cost/time is a factor. As programmers, we would all love to do without the additional overhead of coding practices, and for an unlimited number of reasons.

I realize that css isn't the best language in the world. But if it was intuitive to write css forwards and backwards regardless of document flow -- this wouldn't be a discussion topic. The question is the amount of time invested to learn it.

>The container is providing a hook for layout information that the body tag cannot. For instance, if I wanted the body background color to be blue and the container's background to be white. Also, if you want your content to be restricted in width, it's a lot easier to wrap it with a div than deal with the lack of the > operator in IE 6.

This is true. I was looking purely from layout perspective, but yea, body bleeds background-color and image everywhere regardless of limiting the width.

>Just to be clear, I think that "bad HTML" is pretty much the only practical way to go right now. So, I don't have a problem with the way CSS Zen Garden uses wrappers, nor do I have a problem with the wrappers in this blog post. But you are criticizing one and making excuses for the other.

Practical -- yes I don't disagree. With the way browsers interpret things differently, it's just about the only way you can get compatibility across the board.

Though you are right that I criticizing one and making excuses for the other: at least one follows a clear stated goal -- html describes the content, css draws the presentation. Provided items are added to make do with incompatibility issues, but at least at the core we can see that HTML is purely being used to describe the content. Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.

The other has no such goal; creating a massive grey area between the programmers and the designers.

> I realize that css isn't the best language in the world. But if it was intuitive to write css forwards and backwards regardless of document flow -- this wouldn't be a discussion topic. The question is the amount of time invested to learn it.

Quite right. The argument, as I see it, is that it's much more practical to use the best cross-platform tool for the job, which in many cases is tables and not CSS. He's arguing that it's not worth the time.

> at least one follows a clear stated goal -- html describes the content, css draws the presentation.

This isn't even close to CSS Zen Garden's stated goal. Its goal is to show what is possible to do using CSS. It's goal is to be "A demonstration of what can be accomplished visually through CSS-based design." There's nothing about content/presentation separation anywhere on the site.

> but at least at the core we can see that HTML is purely being used to describe the content

That's certainly not what I see at all, especially at CSS Zen Garden, if that's what you're still referring to here.

> Allowing _enough_ separation required for programmers to be nearly clueless of a designer's job.

If you mean programmer == HTML, and designer == CSS, then this is simply wrong.

Programmer == backend html // designer = AI/PS/CSS cutter, and css writer

When I view source csszengarden this is what I see: <div id="intro"> <div id="pageHeader"> <h1> <h2><acronym>

     <div id="quickSummary">
        <p class="p1"><acronym>
        <p class="p2">
     <div id="premable">
         <h3>
         <p class="p1">
         <p class="p2">
         <p class="p3">

<div id="supportingText"> etc etc. And it goes on.

All I see are information grouped by content. The ids, and class tags describe the information. The paragraphs are ordered p1,p2,p3, because for them to make sense they have to be in that order.

Page header, quick summary and preamble are all items that belong to an introduction.

I think it's great.

In the source of csszengarden, do you also see this

> There are more classes and extraneous tags than needed, and in a real world situation, it's more likely that it would be much leaner.

and this

>  <div id="linkList2">

and this

>   <div id="extraDiv1"><span></span></div><div id="extraDiv2"><span></span></div><div id="extraDiv3"><span></span></div> <div id="extraDiv4"><span></span></div><div id="extraDiv5"><span></span></div><div id="extraDiv6"><span></span></div>

The HTML guy could not be "nearly clueless" about the designer's needs if CSS Zen Garden's flexibility is what you're looking for.

Sure I see it.

But your whole argument is on the basis points of 2 commented divs?

Add extra imagery -- it's posted at the bottom and away from the content. It's not like it's messing with what the programmer needs to develop. You could have easily have removed those tags and only the designs that decided to take use of them would get hurt -- but it is optional, not a requirement.

I thought we discussed that browsers incompatibilities are the reason for this.

The core of the content is listed at the top of the HTML page which is organized properly.

TBH: I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.

> it's posted at the bottom and away from the content

But it's HTML, and should therefore should BE content. But it's not; it's presentation.

> I thought we discussed that browsers incompatibilities are the reason for this.

You seem to be missing my point. If CSS, as implemented NOW, worked as advertised and offered a way to separate content from presentation while retaining flexibility, then we'd have no argument. I'd happily be using it for what is intended. You just can't do that now, and I'm tired of people telling me that I can.

> I would hardly call this level of adding extra markup anywhere close to other HTML where the presentation is completely ingrained.

Of course it's not completely ingrained. But I want it to be able to be completely separated before I'm going to join your camp.

>I didn't say that it's hard to read. I said that by the standards community's definition it is not good HTML, because it mixes content and presentation.

I meant this by reading http://www.csszengarden.com/zengarden-sample.html

not reading the html markup, but what the markup gets converted to when there is no css involved. Even the earliest of mobile devices can read this web page because the information still makes sense just reading it from top to bottom.

If CSS Zen Garden was truly mixing presentation with content, you wouldn't be able to read that link above as easily as you can.

> I meant this by reading http://www.csszengarden.com/zengarden-sample.html not reading the html markup

But you started that part of you message with

> The HTML won't make any sense if you start reversing it

?

> If CSS Zen Garden was truly mixing presentation with content, you wouldn't be able to read that link above as easily as you can.

I'm sorry, but using wrapper divs for purely presentational purposes is mixing presentation and content. The whole concept has to do with how the code is written.

>But you started that part of you message with > The HTML won't make any sense if you start reversing it >?

I thought what I written was clear, but I guess it's coming off as vague. When you view an html page without presentation the logical flow of all the information should be based on the content. Therefore the tags and what is written you would never reverse the order, because the content will no longer make sense right?

So when you're doing something like div #header div #col left div #col middle div #col right div #footer

You've grouped content in the form of header, left, middle right, footer. You can't reverse it, it's stuck because of the way it's been written. Every site redesign will require an HTML redesign each and every time.

If you grouped your content in the form of (like csszengarden has done) Introduction About the site Site Navigation Sub Menu Content Corporate Info

Then ONLY the CSS needs to change. Which is why there are 300+ different and dramatic css layouts on csszengarden, and yet only 1 html. If presentation was truly mixed in there, something would have locked them all into looking a certain way - but as you can see, all the designs are different.

CSS does not demand that the markup be ordered that way. That is entirely a product of the author's choice of layout and his chosen method of generating it, which happens to bring his expectation (that floats work like tables) into conflict with the way that floats are specified to work (that floats work like floats).

You should read my reply to the other guy for a fuller treatment, but here's what I said about this to him, 'perhaps "demand" was hyperbole, but CSS does still push developers to rewrite their HTML when design changes happen.' The cost in flexibility to do it any other way is simply too high. This is sufficiently close to demanding to justify the hyperbole, in my mind.

edit: Furthermore, you speak as if the author is criticizing floats, but he is not. He is criticizing the attitude that tables are to be avoided for layout at all costs, when there simply is not a simple, implemented, cross browser way to replace them. Floats are simple the closest thing we can practically use, so he uses them for comparison.

The author draws a conclusion about CSS in general from an argument that hinges entirely on the use of floats to emulate table-based layout. Ergo, he's criticizing floats for not being tables.

He is criticizing the available subset of CSS of not being tables. As I said, floats are the closest approximation currently on offer. How many times must I repeat it?

Repeat what? Previously you claimed that the author was criticizing an "attitude" and not the way that floats work. Now you're saying he's criticizing the "available subset" which you define as floats.

I don't understand what you're disagreeing with.

Repeat the thing I said right before "How many times must I repeat it?" It's not hard to follow. Here's where I said it before:

> Floats are simple the closest thing we can practically use

Furthermore, I did not define the "available subset" as floats. I'm saying that floats are the best available tool in that available subset for implementing table-like behavior. And yeah, they suck for that purpose, but _there is no better alternative_.

If you still don't understand that, then I'm afraid there's no use in continuing this discussion.

I was clear on what you wrote. I was, and still am, unclear on what you're disagreeing with, i.e. why you wrote it.

Reply on news.ycombinator.com