4 ms·
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 s
by iroboto 18y ago
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.
- chairface 18y ago> 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.
- iroboto 18y ago>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.
- chairface 18y ago> 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.