About CSS on Wikipedia

Really ?! I seriously question whether you’re posting here only because you felt CSS layout vs Tables Layout was a thing you really understood and you think that that’s about it with CSS.

1st. I’m not really bring tables into the argument. It seemed at first as though you may be favoring tables, but now I’m just looking to see how you are still able to bash CSS as a language. These hacks you speak of are not as a result of poor design the CSS, rather the browsers that we are forced to use these hacks for.

2nd. You are questioning JunJun and I’s reputability on these forums because we don’t have 1.2k posts in less than your 1 year as a member here while we both have been a member of this community for close to a combined 16 years. Seems a little odd.

That is what I was hoping for :blush:

What is the alternative? If you do not use CSS for layout, what do you use?

This is not about you, or me, or any other people in this thread. This is about CSS. And you’re trolling.


@K. Wolfe, @junjun

Relevance in your latest posts? On any level?

No, I’m not trolling :slight_smile:

I’m teaching you a lesson about CSS. CSS sucks. No matter if there is no alternative. Or just because of it. And saying CSS and CSS implementations are far from what they should be HAS NOTHING TO DO WITH TABLES!!! WHY YOU KEEP RETURNING TO TABLES!!!

And, if you would know a little more about the subject at hand, there is an answer for your question: XSLT, XLS and XML. But we are now heading towards HTML5 and CSS3. Two blings in one. Two jokes on web devs in one.

So yeah, CSS specs sucks. CSS3 specs sucks more. UAs CSS implementations, CSS 2.1 or CSS 3, sucks. Get it now? It has a promise it never fulfils. That’s why SP CSS Forum is so active.

Kyle, you could argue that almost anything done in CSS aside from fonts, colors and so on is a hack. Maybe I am forgetting something but you could only do three link colors: link, visited and active circa 1998. Now you can do that PLUS set different value based on class or ID.

Alright, children. Play nice. Let’s please stay away from the personal attacks. I’d hate to see what started out as an interesting discussion go down the drain because people are getting their noses out of joint for some perceived attacks (I’m not saying there are attacks going on or not - just that they are perceived).

How about we redirect this discussion back to something useful - how can we improve the information provided there? You’ll need to provide citations to back up your information…

Well, the article really expresses the current feel about CSS. CSS is no longer the next best thing it was years ago. The expectations are higher.

It needs improvements in some areas. That are not coming from specs and are not implemented or are not properly implemented by UAs.

And the article DOES presents the advantages of using CSS. So it’s not like a dismissal, a call to avoid the use of CSS, but rather like a general overview on what’s expected to become a more serious language and a more sturdy support from UAs part.

Take z-index. It exists, w/o question, but when it comes to programmatic handling, in order to customize this property, you need to watch for:

Scoping rules for properties such as z-index look for the closest parent element with a position:absolute or position:relative attribute. This odd coupling has undesired effects such as it is impossible to avoid declaring a new scope when one is forced to adjust an element’s position, preventing one from using the desired scope of a parent element.

Looking at specs: http://www.w3.org/TR/CSS21/visuren.html#z-index

Specifying the stack level: the ‘z-index’ property
Applies to: positioned elements


In CSS 2.1, each box has a position in three dimensions.

By default, each box is positioned. Why the need to explicitly position the boxes for z-index, when the default value for the position property is not void, null, but static, and when the z-index functions by default in the stacking context?

Yes, I agree that there really was no need to differentiate between positioned and non positioned boxes as far as I can see. z-index could just have applied to all elements quite easily especially as auto is the default - basically meaning no effect.

The fact that they didn’t do this means that when an element is statically placed you have to go and add position:relative which I’ve always found a little odd.

There are definitely things that can be improved in CSS but that is straying from the topic which was about the correctness of the information presented in the OPs link. I don’t think it’s a cause for a great argument but as I said in my earlier post there is certainly some misleading information there that could do with updating by some kind soul :slight_smile:

I do find it resonates a bit with me. Although things have come a long way, especially with browser compatibility, I find CSS layout is still cumbersome when thinking horizontally. Vertically it’s very easy, but when you want to put things side by side it seems fragile. Floating things just doesn’t seem like the most obvious way to stack things horizontally, since it was probably designed more for having text wrap around it (like in a newspaper article).

Another thing is the difficulty with putting things in the middle. Suppose you have an image that you want in the middle of some container. It seems like a trivial exercise, but for auto margins to work, you need to actually say how wide it is. Otherwise you have to use text-align, which is not always appropriate, particularly if you want the image to have block display.

I’m sure someone will now point out bulletproof and trivially simple methods for doing these two things. :wink:

lol :slight_smile: - If you have made the image display:block then you can use auto margins without a width because as a replaced element images have intrinsic width.


Of course for non replaced elements you need to specify a width because they don’t have intrinsic dimensions.

zomgwtfbbq - I didn’t know that. I didn’t know CSS was that clever. I thought auto margins only worked when you actually specified the width property. I could swear this hasn’t worked when I tried it before, but now it does. Damn.

It still doesn’t work when you want to wrap it in an anchor though, which is a problem.

Maybe I’ll submit something to the HTML5 working group to say “do away with anchors, and just let any element have a href attribute”. That would also solve the problem of the “clickable div”!

@noonope, I have to say, I absolutely agree with you here. I’m glad there is someone here who represented my opinion before I looked at this thread. :slight_smile:

The excerpt posted is fairly accurate. Anyone who knows something about CSS should be able to recognized how utterly flawed and limited it is. CSS never provided robust positioning mechanisms until CSS3 and even then, their implementation will be contrived as they are almost like an afterthought (and they are).

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

I wouldn’t say tables because their behavior is easily duplicated in CSS. Maybe as opposed to the center element for example - an element whose behavior still cannot be replicated properly in CSS. Hopefully the flexible box layout will change this.

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

Floats are horribly inconsistent in IE7 and below. You can say they’re consistent in modern browsers, but that’s almost meaningless because pretty much every modern browser is converging in terms of consistency now.

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>

Go try to change an element’s containing block to a non-ancestral box and tell me that it’s possible. I’ll save you the trouble though: it is not possible (also, display:run-in does not accomplish this in any tangible way). This is something that should be so essential to a presentational language as well. It’s not like the inclusion of this capability is unrealistic to ask for or expect.

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. …

You can determine the limitations by examining other mediums of presentation. Presentation doesn’t only exist on the web. For example, CSS can’t do true multi-column text layouts like you would see in a newspaper or magazine. Many people who migrated from magazine or print to web design will easily acknowledge how limited CSS is in this regard. That will probably be one of the first things they notice - that they can’t do multi-column text layouts (yet).

And any CSS coder worth its salt knows CSS and CSS implementations suck

Noonope is right. It should be fairly obvious how limited CSS is.

And some of those things took quite a while to be “discovered” and require a lot of effort to accomplish, such as a centered horizontal drop-down menu. Intuitive? Not exactly. If it was, it wouldn’t have taken years for these things to come to light.

I can go to the grocery store and buy the ingredients to bake a batch of cookies. Or I can raise my own wheat and cocoa beans, grind them up, milk cows myself and churn it into butter, and extract sugar from beets to get the ingredients I need. Both methods can produce the desired result. But which is easier and requires less effort?

Current HTML/CSS is like the second method requiring a lot of work.

Well, my understanding is that floats were intended to take something out of the regular flow, push it up and allow other content to flow around it. That doesn’t exactly meet the definition of a column to me. Yes, it can be done. But don’t you think there could be or should be a better way?

Learning CSS was pretty easy as far as the styling goes. Layout using floats was a bit trickier given the necessity to clear floats, something I didn’t quite understand in the beginning… Then when padding and borders are added to a fixed width column increasing width instead of being applied inside, that makes things a little more complicated. Vertical centering, anyone?

There are limitations to everything. Anytime something is lacking in features or could be done a better or easier way, there are limitations. Could CSS/HTML be improved? If you answer yes, then clearly there are limitations in their current implementations. The only time you achieve a state of no limitations is when you reach perfection. Perfection does not exist in the real world. It certainly does not exist with CSS as far as layout is concerned.

You could quite rightly say that the limitations of CSS was that it didn’t do equal columns which tables can do quite easily.

There you go. I also think CSS should have a way to do menus that are not flush left. Is it possible to do it now? Sure. But it requires some work and some ugly CSS.

I think some people are making this an argument about tables versus CSS and it’s not. It’s about the limitations of CSS pertaining to layout. I find it difficult to argue there are no limitations in the current implementation of CSS.

And another limitation to add to the list.

The needs of web designers have evolved faster than CSS/HTML specifications, respective of the inherent limitations. It would be nice if the standards could keep up with the wants and needs of the internet community instead of people having to get creative through trial and error and the use of lots of ugly CSS to accomplish what should be easy to do or not being able to do it at all.

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

As an addendum to my above post, I would also like to mention that things like XBL and XSLT could also enhance positioning capabilities. They allow for dynamic positioning that pure CSS cannot accomplish on its own.

Also, on floats: To my understanding, the reason you need to forcefully “clear a float” (I hesitate to use that phrase) when you’re using floats to position a layout is because a number of the float use-cases were for text wrapping around floated boxes:

+-----+ This is the first <p>
|p>img| element.
+-----+ This is the second
<p> element.

That doesn’t mean some of the use cases weren’t for positioning layouts, but you can’t deny that the reason floats are so awkward and counterintuitive for newcomers to CSS is because of use cases like the above example.

How did I get drawn into this discussion :slight_smile:

On the contrary I find IE7 and IE6 are “pretty” consistent with floats and rarely run into trouble with them. There are some well known bugs of course but 90% of the time they are fine and fit for purpose. They could be better and life would be easier without the bugs but I still stand by my statement that they are pretty consistent or to put it another way “I don’t have any trouble with them”

You can determine the limitations by examining other mediums of presentation.

Yes but that’s plainly a wrong approach as a webpage is unique and nothing like other mediums especially newspapers. We shouldn’t really be copying newspapers or trying to mimic some graphic designers “piece de resistance”. We should be creating layouts that suit the web and there are more important issues than newspaper columns.

As I said before I just bought a new car and even though it was made for travel it can’t fly and it can’t float. A serious limitations if I want to travel to another country. Sorry to harp on about this point but to me it’s like comparing chalk and cheese.:slight_smile:

I’ve already said that you can say CSS is limited if it can’t do what has gone before (e.g. saying CSS can’t do equal columns as easily as tables was a valid point (before modern browsers)) but you can’t make up new things and say it is still limited. It isn’t perfect by any means and there is plenty of room for improvement or expansion which is a positive connotation unlike limitations which are negative.

I was originally just making a mild point of emphasis which as usual has been blown out of all proportion and seems to have gone way off topic again.:slight_smile:

Many people who migrated from magazine or print to web design will easily acknowledge how limited CSS is in this regard. That will probably be one of the first things they notice - that they can’t do multi-column text layouts (yet).

Yes and they are usually the worst offenders trying to make us read up and down in columns on a webpage is a usability nightmare.:slight_smile: The web is not print and is nothing like it.

I will agree though that we should be able to create every type of layout on a web page (for better or for worse) and eventually/hopefully that will be true. Mind you, even then you could still say its limited because it can’t be done in holographic 3d. In fact anything that exists in the world today could be said to be limited by the criteria used in this discussion.

No, I can’t deny that you have to learn the tools of your trade and learn them well. One of the things I love about CSS is that it is such a rich and in-depth mark up system. I did my fair share of hair pulling ten years ago but I wouldn’t have had it any other way. A job worth doing is worth doing well.

Who said that newcomers should be able to “code in a day”. I wish I could learn Javascript in a day. I wish I could have learned tables in a day.

I will accept that some things are not intuitive, and some things seem to be harder than they should be. Hopefully the new layout modules will enhance what we already have but don’t expect them to be any easier than floats or tables.

I don’t care what we “should be doing”. The topic of discussion here seems to be the potential limitations of CSS, not how we should try to ignore the potential limitations of CSS by dictating what people “should” be doing with their designs.

I don’t see why you insist on bringing this up. This analogy is irrelevant. Something practical, and realistic that is to be expected from a certain technology is completely different from something that is only to be expected in science fiction. A spec that allows for dynamic containing block management is conceivable right here and now, whereas flying cars are still ages away and exist only in the realm of science fiction.

Even so, I would still add, we do have the power of flight. We can acknowledge the limitations of cars by comparing them to the convenience achieved through powered flight. If past inventors were simply content with the limitations of traveling on foot or horseback we wouldn’t have trains, aircrafts, cars, etc.

The difference is, I wouldn’t expect a train to fly me to my destination. This simply wasn’t possible at the time trains were invented. In contrast, my expectations for a presentational language are entirely possible whether the language was created in 1995 or 2015.

The most rudimentary concepts of web page design and rendering evolved out of print. I think I’m entirely justified in comparing presentation in other media to web presentation.

Limitations can be a positive. They drive you to improve something, thereby removing limitations. Acknowledging your faults is the only way you can begin to change for the better. Even if limitations were negative though, that doesn’t mean they don’t exist. Just because an idea is uncomfortable/negative doesn’t mean it’s not true.

Once again, you’re aiming at the wrong target. Regardless of who does what with their designs, CSS is still limited. Criticizing certain people who use it won’t conceal that.

“holographic 3d”? Please don’t mischaracterize my arguments. …as if I’m fabricating limitations here. When did I ever voice unreasonable expectations for CSS? I believe I mentioned dynamic containing block management, and better support for centering boxes. Too much to expect from a presentational language?

Perhaps I did exaggerate too much to make a point and I apologise :slight_smile:

My main argument with the entry was the negative emphasis which I found slightly misleading (and of course the factually incorrect information I pointed out that needs to be changed - but that can happen in any reference of course).

Awww, does this mean no one is going to update the Wikipedia page? Maybe I’ll do it myself.

Nothing said in this thread has given me any reason not to scorn that comment. I lay out web pages day-in, day-out, using CSS alone, and I don’t find it hard at all. The comment seems utterly ridiculous … (and IMHO betrays a longing for the old table layouts, as the OP suggested, despite not explicitly saying so).

Hmm, where’s the like button such as Facebook has?