About CSS on Wikipedia

I was searching today for browser support for CSS3 properties, and somehow landed on the Wikipedia page for CSS.

And there I read

Some noted disadvantages of using “pure” CSS include:
Poor controls for flexible layouts
While new additions to CSS3 provide a stronger, more robust feature-set for layout, CSS is still at heart a styling language (for fonts, colours, borders and other decoration), not a layout language (for blocks with positions, sizes, margins, and so on).

I guess I’ve been wrong the last seven years, I should have used tables (or maybe frames) for layout. :rolleyes:

So the question is; how many here is experiencing this ‘disadventage of using “pure” CSS’.


You really are pissing against the wind. You should, first, provide info to support your theory about slow rendering of tables.

While that may be true in some cases, it’s the dev’s fault if so. Like anything else, for that matter, if the dev knows, the dev avoids. Otherwise, the dev complains.

Anyway, here’s what you’re asking for. Mind you, it’s from 1999 :wink:

Incremental display

For large tables or slow network connections, incremental table display is important to user satisfaction. User agents should be able to begin displaying a table before all of the data has been received.

I’d have to say that any true designer knows not to check wikipedia, hence the obvious bad information that has gone unedited for so long…

I do.

I don’t find that what it says there is half bad. And if you were looking around this forum long enough, you’ll notice that too.

On wiki they don’t blame the CSS as is, they blame the implementations, mainly, though they point out a few shortcomings of the language it self too, and I tend to agree with most of what’s written there.

But that’s my interpretation of what’s there.

CSS is still at heart a styling language (for fonts, colours, borders and other decoration), not a layout language (for blocks with positions, sizes, margins, and so on).
100% disagree. This all comes back to the conversation that’s been had on these forums hundreds of times before, and it makes me mad. CSS’ purpose is to style a page. Tables are for tabular data. Tables are messy and have 10x more disadvantages / short comings compared to css when in the hands of someone who knows what they are doing.

Typical argument w/o proper understanding :slight_smile:

In the said article, there is nothing about promoting tables for layout. Neither there is one in any of my posts in this thread.

The phrase you quoted is indeed the truth: you have to struggle with layouts while rounded corners and text shadows are a priority in CSS3.

Plus, the poor CSS 2.1 support even in modern UAs makes out of the CSS language a hack tool, when it should be a straight, simple, clean cut tool since it’s aimed at use by anybody with a little interest in web dev.

So yeah, there is a basic support for real CSS and there is a big interest for bling in CSS. And yeah, CSS3 should have been a better spec. Like HTML5. But hey, bling-bling.

That page is a little misleading in places.

In the section on Limitations it notes: “Some noted disadvantages of using “pure” CSS include:”… but doesn’t explain “as opposed to what”?

They can only be limitations if they can be done better and easier by other methods (e.g. tables). If I make a new car that can drive at 200mph then I could say the disadvantage is that it doesn’t go at 300mph :slight_smile:

For example:

Selectors are unable to ascendCSS offers no way to select a parent or ancestor of an element that satisfies certain criteria.
Tables can’t ascend either. Scripting can target the parent but scripting can’t make the monitor swivel automatically or fly off the ground. It seems a senseless comment as there are many other things that css can’t do. It’s called cascading style sheets for a reason not “floating upstream without a paddle”.

Cannot explicitly declare new scope independently of position Scoping rules for properties such as z-index look for the closest parent element with a position:absolute or position:relative attribute.
That is just plain incorrect as positioned elements get z-index of auto by default and the z-index of children are not trapped by their positioned parent unless that has a z-index applied other than auto. (Older IE gets this wrong which is probably where they got the error from but has nothing to do with css itself)

Simple tasks, such as … getting a footer to be placed no higher than bottom of viewport, either require complicated and unintuitive style rules, or simple but widely unsupported rules.

Tables can’t do this either which brings me back to my first question. How can this be a limitation when nothing else can do it either (apart from scripting).

Of course it can be done in CSS because I did it back in 2002 when it was actually a lot easier to implement than the current version.

With the current CSS, the process is often done using floating elements, which are often rendered differently by different browsers, different computer screen shapes, and different screen ratios set on standard monitors.

Floats are pretty consistent across all browsers apart from old versions of IE.

Pseudo-class dynamic behavior not controllable CSS implements pseudo-classes that allow a degree of user feedback by conditional application of alternate styles. One CSS pseudo-class, “:hover”, is dynamic (equivalent of javascript “onMouseOver”) and has potential for abuse (e.g., implementing cursor-proximity popups),[30] but CSS has no ability for a client to disable it (no “disable”-like property) or limit its effects (no “nochange”-like values for each property).

Wrong a user stylesheet can control all those.

I just find the limitation section rather misleading as it is assuming that all these things are possible more easily by other methods and they are not.

I do get the feeling it’s written by folks who still struggle with CSS.

CSS is still at heart a styling language (for fonts, colours, borders and other decoration), not a layout language (for blocks with positions, sizes, margins, and so on).

I have to agree with that. CSS and HTML are woefully lacking in some areas such as layout. My opinion is that floating was not intended to be used to layout columns. Yes, it works. But that’s not the intended purpose but, rather, a workaround. (Right?)

HTML (or CSS perhaps) should have included a way a long time ago to lay out columns within a container. Maybe a <container> element and <column> elements or something. I don’t know. When the specs were created years ago I think they were short-sighted. With webmasters still supporting IE6 almost 10 years after release, it is going to be a long time before any real changes come to laying out webpages without using floats.

CSS should have also included a way to do rounded borders, shadows and gradients without images a long time ago, too.

Just because something is better than a leading alternative does not mean it does not have limitations.

So far almost everything that has said to be impossible with CSS has been disproven.

There are very few things that (I believe) are impossible with CSS>

But when I say impossible, I mea it hasn’t been done yet :rolleyes:

Wikipedia is wikipedia. Written by noobs who don’t know what they are talking about.


No, that’s not quite right as the first demonstration by the w3c way back in about 1998/9 was showing the use of floats for columnar layouts and to replace tables for layout where possible. Floats were always meant for this purpose but this urban myth has arisen that they were never meant to do that but is plainly wrong as can be seen from the link below.

See my post 22 in this thread from some years ago which links to the original test pages from the w3c which were about 12 year old. Unfortunately the main link has gone awol now but as you can see from the reply after my post 22 that the case was clearly stated and won.

Floats aren’t perfect and can drive you mad at times but most of the time they are pretty useful and flexible and can do amazing things. However there is something better around the corner in the multi column layout but I doubt it will ever completely replace floated layouts because they are so unique.:slight_smile:

Just because something is better than a leading alternative does not mean it does not have limitations.
I don’t understand how something can be limited when it exceeds what went before. You have to have a comparison to measure the limitation. My analogy with the car was a perfect example. You can’t add in extra requirements such as the limitation of a car is that it doesn’t fly.

You could quite rightly say that the limitations of CSS was that it didn’t do equal columns which tables can do quite easily. (Although again that is the limitation of a certain browser and not of the css specs.)

Well then there are two members here that have “misunderstood” the context of that article. That article most certainly is promotional listing CSS’ “short comings” true or not as opposed to tables which is not a proper comparison at all.

It’s not about what you can or can’t do with CSS. It’s about how you achieve your goals with CSS.

Yes, it’s nice that CSS keeps a layer separation from HTML. But, and here I seem to be having the most arguments with Paul, it’s also HOW you achieve your goals with CSS.

“Tables this, tables that.” “HTML is the main concern.”

Well no! You can’t replace a bigger evil with a lesser evil and pat your self on the back. As any lightweight programmer knows, any code is important. So, when you have to take CSS code to circus to achieve what should be basic layout tasks, then yes, I can conclude the same as on wiki: CSS is mainly for fonts and borders and colours.

In my experience as a programmer, any crap like the one you have to pull with CSS this days to get some jobs done, no matter how clever or revolutionary, it’ll byte your smart ass later on. Examples are many.

I, as a programmer, I’m in the productivity and reusability business. I’m not in the business of CSS art. That’s pointless for any computer related task. I need to produce clear cut code. Mind you, not dumb simple!

So yes, wiki is right: CSS and CSS implementations are not where they’re supposed to be, no matter how smart web devs are in overcoming their lack of substance. For that matter, the article could have been on a p0rn site, it’ll still be true :wink:

Once again, where did you even read about a CSS Layout vs Tables Layout in that article? Isn’t it your Pavlov’s reaction making you see in that article an old age controversy, when, in fact, the article tackles the today’s reality of CSS code?

In my experience as a programmer, any crap like the one you have to pull with CSS this days to get some jobs done, no matter how clever or revolutionary, it’ll byte your smart ass later on. Examples are many.

As a result of browsers not rendering the css properly. Not the fault of the language itself. And for those with enough experience with css, these things tend to be a problem less and less as you have a more powerful understanding of the language and the browsers its run on. Much like when you were learning one of your first programming languages, you’d be researching for answers to simple actions less and less.

I can conclude the same as on wiki: CSS is mainly for fonts and borders and colours.

My guess is you roll with tables?

My guess is you overreact and you question my knowledge in a dirty way. It’s fine, you can do that, but only after you’ve checked out some of my posts here. That is, if you have the time :slight_smile:

And to answer your question: no matter how much you know about CSS, CSS will still have the same problems, specs or implementations. So no, there are not greater values to CSS, as you’re implying, once you “get to know more”, only more monkey business. Called HACKS. These don’t constitute solid programming language knowledge and expertise.

Please name an example of a hack that you have used that isn’t a result of browser cross compatibility issues.

I thought we were done with the tables vs CSS years ago. It really is no discussion anymore, we’ve moved on.

The Web Standards war is over. You should no longer have to argue for the separation of semantically meaningful HTML, and the presentational layer.

My initial post was mostly rhetorical; I was mildly shocked from the quality of the article, and I think deep inside I wished for someone here with more time could take it upon themselves to fix it :wink:

noonnope, practice makes master. There’s tons of tutorials on CSS, and there’s no ‘circus’ involved. Once you go CSS, you never go back. I’ve tutored a few budding web developers, and it’s amazing to see the change in how they approach web design once they’ve reached their CSS ‘Eureka’ moment.

Since that article is on wikipedia why doesn’t someone who knows the true situation update what it says so that it will correctly explain the situation.


First off, tables were not brought up in that article. You, and K. Wolfe seem to be bringing the tables discussion out of the blue. :wink:

Per contra, I’m a very much a CSS fan. But I guess you should’ve browse through this forum as a helping user more often to see that. BTW, I didn’t see much of you, or K. Wolfe for that matter, being so involved in this forum. At least, not lately, so I have to question whether you really know more about CSS as to be taken seriously. As far as I can tell, you’re here to be helped not to help. :slight_smile:

And any CSS coder worth its salt knows CSS and CSS implementations suck :slight_smile: So, what’s your point, both of you?