Even big boys can't do CSS properly...

[versatilia]

One of the big EU banks and they may not have fully tested their website...

Shot 1 - home page without javascript:
 

Shot 2 - even with javascript, a failed attempt at pure CSS equal height columns:

(see the size of the scrollbar, apologies for the quick cut+paste job!) 

[Steeldragon]

Now that is a WTF w/ writing over writing and 4 massive unneeded scrollbars.

[aythun]

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

[versatilia]

The 4 lots of scrollbars are me cutting+pasting several screenshots together - it was just one massive scrollbar.  It's a well known technique to create equal height columns by having a 30,000 pixel high div, but it shouldn't be visible to the user, obviously!

[Daniel_Beardsmore]

@versatilia said:

... It's a well known technique to create equal height columns by having a 30,000 pixel high div, but it shouldn't be visible to the user, obviously!

That has to go in my long list of reasons to stay away from advanced CSS layout. An average advanced CSS layout must have more painful workarounds than any front-page material here. Someone has to smash Microsoft and the W3C's heads together and knock some sense into them both. I used to be on the W3C's CSS working group e-mail list but left in complete desperation after it seemed apparent that no-one there seems to have any vague interest in supporting any kind of worthwhile layout improvements. I don't think anyone there (the men, anyway, the women seem to have more of a clue) understands that computer screens are 2D and people want to make useful and intelligent use of 2D space. HTML never had any worthwhile layout so everyone took to abusing tables. We can only hope that CSS3 Advanced Layout turns out to be useful for something one day.

Abbey National have my sympathy as does anyone trying to get CSS to work.

[Cap_n_Steve]

@aythun said:

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

I'm still wondering what exactly the point of that is. The only benefit I've seen from serving up the "correct" content type is that you get to rewrite a lot of Javascript to be uglier and slower.

[asuffield]

@Cap'n Steve said:

@aythun said:

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

I'm still wondering what exactly the point of that is. The only benefit I've seen from serving up the "correct" content type is that you get to rewrite a lot of Javascript to be uglier and slower.

If you use the XHTML content type then the browser will process the page as XHTML. If you do not, then the browser will process it as HTML, and the only reason why your XHTML page works at all in this mode is because the browsers are designed to cope with all kinds of stupid invalid HTML junk, and XHTML looks sufficiently similar to HTML that quirks mode manages to render it.

So, why the hell are you using XHTML? It's just plain retarded not to use HTML proper, if you're going to render it as HTML anyway. If you're complaining about the need to rewrite Javascript, then you clearly don't even want to use XHTML, so why are you doing it?

[Lingerance]

@asuffield said:

So, why the hell are you using XHTML? It's just plain retarded not to use HTML proper, if you're going to render it as HTML anyway. If you're complaining about the need to rewrite Javascript, then you clearly don't even want to use XHTML, so why are you doing it?

Because the mean man in the corner said I have to write in XHTML, HTML is dead. Please don't make him come out of the corner, I hurt enough as it is. Oh the glaiven.

[PSWorx]

@asuffield said:

@Cap'n Steve said:

@aythun said:

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

I'm still wondering what exactly the point of that is. The only benefit I've seen from serving up the "correct" content type is that you get to rewrite a lot of Javascript to be uglier and slower.

If you use the XHTML content type then the browser will process the page as XHTML. If you do not, then the browser will process it as HTML, and the only reason why your XHTML page works at all in this mode is because the browsers are designed to cope with all kinds of stupid invalid HTML junk, and XHTML looks sufficiently similar to HTML that quirks mode manages to render it.

So, why the hell are you using XHTML? It's just plain retarded not to use HTML proper, if you're going to render it as HTML anyway. If you're complaining about the need to rewrite Javascript, then you clearly don't even want to use XHTML, so why are you doing it?

Despite being horribly cliche, I'd say the root of all evil here is once again Microsoft. Even IE7 refuses to interpret the application/xhtml+xml content type. And that basically leaves web developers two choices: Serve XHTML wrongly or abandon it altogether. And until they finally change this in a further version of IE (and it don't looks like this) I don't think this will change in any way. Okay, maybe in one way: that XHTML will die and everyone will return to HTML. But then again, there is no "everyone" on the web, so the ubiquitous mess will just increase.

Meanwhile, I think there IS one good reason for serving XHTML. If you violate the spec once more and ignore the content type, you CAN interpret it as XML. And that can make life much easier if you want to extract data for mash ups or other aggregation solutions. If you as the web author of course want to permit that is another story.

@Daniel Beardsmore said:

@versatilia said:

... It's a
well known technique to create equal height columns by having a 30,000
pixel high div, but it shouldn't be visible to the user, obviously!

That has to go in my long list of reasons to stay away from advanced CSS layout. An average advanced CSS layout must have more painful workarounds than any front-page material here. Someone has to smash Microsoft and the W3C's heads together and knock some sense into them both. I used to be on the W3C's CSS working group e-mail list but left in complete desperation after it seemed apparent that no-one there seems to have any vague interest in supporting any kind of worthwhile layout improvements. I don't think anyone there (the men, anyway, the women seem to have more of a clue) understands that computer screens are 2D and people want to make useful and intelligent use of 2D space. HTML never had any worthwhile layout so everyone took to abusing tables. We can only hope that CSS3 Advanced Layout turns out to be useful for something one day.

Abbey National have my sympathy as does anyone trying to get CSS to work.

I think this article, gives a good picture why some people there are thinking this way. It's already somewhat dusty (2001, with statements like "CSS1 will never take hold") but it's worth a read nevertheless.

I'm always a fan of semantic markup, but the "original mission" of HTML seems to go a LARGE step further. In short, they demand(ed) nothing less than to completely abandon styling and layout by the authors. The authors of web pages were supposed to just give a semantic skeleton, the browsers should do ALL the styling based solely on user preferences.

Of course this approach simply ignores one of the IMO most important factors of the web: That layout and styling is a product of its own. One of the prevalent web professions is called "web designer" for a reason. I don't think that authors would ever freely give all layout control out of their hands and I don't think customers would want this either.

So yeah, what stays is a huge mess of contrary approaches, all halfway implemented in a foul compromise. 

[Cap_n_Steve]

@asuffield said:

@Cap'n Steve said:

@aythun said:

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

I'm still wondering what exactly the point of that is. The only benefit I've seen from serving up the "correct" content type is that you get to rewrite a lot of Javascript to be uglier and slower.

If you use the XHTML content type then the browser will process the page as XHTML. If you do not, then the browser will process it as HTML, and the only reason why your XHTML page works at all in this mode is because the browsers are designed to cope with all kinds of stupid invalid HTML junk, and XHTML looks sufficiently similar to HTML that quirks mode manages to render it.

So, why the hell are you using XHTML? It's just plain retarded not to use HTML proper, if you're going to render it as HTML anyway. If you're complaining about the need to rewrite Javascript, then you clearly don't even want to use XHTML, so why are you doing it?

As of right now, I'm not.  But since the difference between HTML and XHTML is a doctype and a header, I'd like to do things the "proper" way and I'd like to know what I'm missing besides a huge headache.

[Daniel_Beardsmore]

Whee, is this my longest post ever so far? Haha. Doh. Now no-one is going to read it.

@PSWorx said:

I think this article, gives a good picture why some people there are thinking this way.

That page is a wonderful example of one my pet peeves on the Web. Sites that fail to indicate where a link points to a fragment of the same page. You see a bunch of interesting links and middle-click them all, only to open lots of copies of the same page, a real pain when the page takes an age to render and the browser is tied up re-parsing and re-rendering multiple copies of the same page (browsers don't have a concept of New Window/New View like text and image editors). I had my site set to mark local fragment anchors with an image using CSS -- a[href^="#"]:after { content: url(some-image) ...} -- but it just looked a mess. Maybe I just needed a better icon instead of an up/down arrow saying that I had no idea where on the page the link was :P

It's yet another area where the Web is badly lagging behind. It's schismed into two halves -- the backwards HTML Web and the ultra-modern Flash/AJAX Web -- and neither of which seems to have anything in common with the realities of using a browser and a present-day desktop computer interface. It's scary to realise that all the people who obsess over Flash apparently still have no idea that browser interfaces have moved on a long way. I remember the days when I had to have my Windows taskbar on three rows to make room for all the buttons I had on it, many being Internet Explorer. All my Mac browser windows were hidden behind each other and I had to keep digging them out of the window menu. Flash is in fact so tremendously useless at bulding sites (at least, given how people abuse it) that I doubt the sanity of anyone who makes sites in it. At least some parts of some Flash interfaces do support copy and paste. Some.

Google are trying to build a complete GUI inside a browser tab in some sort of horrible expansion of emacs without contemplating that a real desktop GUI has far more power and flexibility and features and trying to trap one inside of a browser tab is going to stop it from making any good use of the real GUI. Google, to me, are barking up wrong trees -- distributed GUI software still belongs on the desktop, and trying to shoehorn it into a browser tab and expect it to intregrate with the user's choice of GUI (be it Windows or Mac OS X or one of the interesting fringe X11 window managers) is nuts.

The Web was, fundamentally, a brilliant idea. It's just a shame that it was so misdirected at the beginning and remains so misdirected now.

@PSWorx said:

It's already somewhat dusty (2001, with statements like "CSS1 will never take hold") but it's worth a read nevertheless.

Something he notes about CSSs, is "It is difficult to understand how it is intended to work, and even if you understand, you won't remember. The system really begs to be misunderstood and misused ...". I do find the cascading system to be incredibly useless at times. If I specify in my central stylesheet that all instances of a particular element should have a particular style, e.g. ul.menu { margin: 0; padding: 0 }, it can become impossible to then override this later when a given page needs a slightly modified version. The rule form in the global stylesheet has too high a specificity to let anything else override it. This is freaking nuts. You can abuse > to artificially drive up the specificity but that won't work in Internet Explorer (not 6 anyway). You can also assign it an ID I think, to have a more specific selector. I forget what I did end up doing, but it was a real pain. It's too tangled up in rules to just stop and do what is really needed ;)

He writes, "Now if an author has provided a style sheet specifying some particular background color for his examples, and if there is a need to separate examples from the rest of the text clearly, this would fail - because the style sheet model is too concrete. (What was really needed is a standardized element for specifying that we have an example here, letting each environment and user decide how to present such elements in general.

This is dangerous (says the Prodigy). This is where I'm divided over semantics. Human language is incredibly ambiguous really, and our written text is no better. I notice that Wikipedia has no sign of requiring abbreviations and especially acronyms to be marked as such along with their definition (although it's ironic that neither <abbr> nor <acronym> has any formal way to express the definition. But then, it gets stupid fast. I always mark every acronym with its complete expansion everywhere in a page, which looks worse than tag soup and wastes bandwidth. You could only give an expanded definition to the first example, but the first example may no longer be the first example if you rearrange the page. Besides, marking something as an acronym without giving an expanded definition is useless -- you already know it's an acronym, but you can't be sure that Acronym Finder will give you only a single possible match. Sometimes there are a great deal of plausible matches shown.

When you start looking at tags like <kbd> and <addr> you start wondering just when to use them and why (and the W3C have no real clue either). You start getting fringe cases where you don't know if it counts for that tag or not, and then you'd get usage creep until it's used for so much that the semantics are meaningless. And yet you'd still be left with far too many semantic ideas that can't be expressed in HTML anyway. Humans are smart enough that we don't need any of this mark-up anyway. If we started adding tags to indicate all possible semantics we'd soon end up with <verb> and <noun> and the like. It's too hard to figure out where to stop. The document suggests <example> and <warning> and I do feel that HTML does, still, need extra tags and extra structural control. For example, a means to formally attach a caption to any element, such as an image, and not just tables. The ability to constrain a heading to only a certain amount of successive elements, so that you can mark up a section of text with a heading without a document tree parser thinking that the heading applies to eveything down to the next header of equal or higher level. Think things like sidebars and examples that need heading captions. The tag soup needed for latching on CSS forces the creation of all sorts of extraneous <div>s that muddy up the document tree and make it impossible to tell what a heading applies to (someone suggested they be bounded to the enclosing <div> but that element may only be there to achieve presentation control!). HTML needs a substantial rethink, and HTML 5 does appear to be going in the right direction.

There are advantages though for blind people trying to deal with large pages of text that take a lot longer to get through by speech than it takes a sighted person to skim through. I don't know that lots of dubious, ambiguous semantic tags are really the answer in any way at all. (They do, however, provide something useful to latch styling onto, default, author or reader.) XML though has gone in the direction of letting you just make up whatever tags you feel like and deciding what they're to look like, which seems to be the insane extreme.

@PSWorx said:

I'm always a fan of semantic markup, but the "original mission" of HTML seems to go a LARGE step further. In short, they demand(ed) nothing less than to completely abandon styling and layout by the authors. The authors of web pages were supposed to just give a semantic skeleton, the browsers should do ALL the styling based solely on user preferences.

The page makes a great many good points and reminds us that it's a harsh problem to solve. That said, I don't think that humans as a species could ever tolerate the utter and complete monotony that he's suggesting we embrace. If every site in the whole world looked the same? The Web has a wide range of uses. In many cases, it would be awesome if all sites looked the same because then we'd not be forced to battle the innumerable bad designs out there that are impossible to navigate or read. However, everyone from private individuals up to large companies wants to demonstrate their uniquess. Companies want to stand out, and individuals want to use their own sites to demonstrate themselves as a person. All this would be wiped out if took away author styling. Some people, oddly enough, nerds especially have no time for aesthetics at all or no design abilities of any kind and to this day still author completely style-free, monochromatic and incredibly dull pages. The article in question is almost a case in point except that the proliference of blue underlines puts some colour into it.

Curiously enough, though, what is to stop people from simply switching off author CSS and replacing it with 100% user CSS? The snags come in at least two ways. Poor use of HTML, from HTML-based formatting to a lack of semantic tags, e.g. people using <span> tags instead of <h2> tags for headers. The author of the page called for HTML to be extended, which illustrates another problem -- so many ideas that cannot be expressed semantically in HTML yet, so there's nothing we can latch onto with user styles. For example, I use <code> tags displayed as blocks with text rendered as pre-formatted in order to have blocks of code marked up correctly. Take away author CSS and this reverts to chaos -- all the line breaks are gone. If you add <br> tags, you get double-spaced text. If you take away white-space: pre then all the indentation is lost. As I recall, there is a white-space mode that will preserve spaces but not line breaks, but little or nothing ever implemented it! Argh. There's always   but that ends up a real mess to work with.

[asuffield]

@Cap'n Steve said:

@asuffield said:

@Cap'n Steve said:

@aythun said:

Considering the "big boys" are the guys who use tag soup XHTML 1.0 Transitional pages served as text/html, this isn't very surprising.

I'm still wondering what exactly the point of that is. The only benefit I've seen from serving up the "correct" content type is that you get to rewrite a lot of Javascript to be uglier and slower.

If you use the XHTML content type then the browser will process the page as XHTML. If you do not, then the browser will process it as HTML, and the only reason why your XHTML page works at all in this mode is because the browsers are designed to cope with all kinds of stupid invalid HTML junk, and XHTML looks sufficiently similar to HTML that quirks mode manages to render it.

So, why the hell are you using XHTML? It's just plain retarded not to use HTML proper, if you're going to render it as HTML anyway. If you're complaining about the need to rewrite Javascript, then you clearly don't even want to use XHTML, so why are you doing it?

As of right now, I'm not. But since the difference between HTML and XHTML is a doctype and a header, I'd like to do things the "proper" way and I'd like to know what I'm missing besides a huge headache.

There are two "proper" ways: HTML and XHTML. Unless you've got a damned good reason for using XHTML, leave it alone. It exists primarily because of the "let's do everything in XML because it has an X in it" mentality of w3c, not because it has any particular advantages in the context of the web. It may have advantages in applications other than the web, but if you don't know you've got one of those cases, then you don't have one.

There are many wrong ways, and perverse HTML-pretending-to-be-XHTML is one of them. It is equivalent to writing a php script that happens to execute on the perl interpreter - possible, but insane.

[ender]

@Daniel Beardsmore said:

Something he notes about CSSs, is "It is difficult to understand how it is intended to work, and even if you understand, you won't remember. The system really begs to be misunderstood and misused ...". I do find the cascading system to be incredibly useless at times. If I specify in my central stylesheet that all instances of a particular element should have a particular style, e.g. ul.menu { margin: 0; padding: 0 }, it can become impossible to then override this later when a given page needs a slightly modified version. The rule form in the global stylesheet has too high a specificity to let anything else override it. This is freaking nuts. You can abuse > to artificially drive up the specificity but that won't work in Internet Explorer (not 6 anyway). You can also assign it an ID I think, to have a more specific selector. I forget what I did end up doing, but it was a real pain. It's too tangled up in rules to just stop and do what is really needed ;)

Hint: [code]ul.override { margin: 1em !important; padding: 1em !important }[/code]. No, I'm not kidding.

[dhromed]

@Daniel Beardsmore said:

e.g. ul.menu { margin: 0; padding: 0 }, it can become impossible to then override this later when a given page needs a slightly modified version. The rule form in the global stylesheet has too high a specificity to let anything else override it.

A normal class like that, in a global, linked stylesheet is overridable by practically anything that comes after it in the total stylesheet picture.

I figure there's something else wrong in your setup.

This stylesheet bit:

    ul.stuff {
      margin:0;
      padding:0;
   }

   ul {
      margin:100px;
      padding:100px;
   }

And this HTML: 

<ul class="stuff">
   <li>xfgd</li>
   <li>xfgdfgfgj</li>
</ul>

will cause this list to have no margin and no padding, as the class is more specific than the element.

To override it, you can add a class to the UL, and add styling for it after the .stuff declaration. Or add an id attribute, and its corresponding selector with to without element name anywhere in the stylesheet. ID is more specific thanb class or element and overrides without problems.

Usage of "!important" should be avoided. And it can be, easily.

[Daniel_Beardsmore]

I wondered if it was the notices page, which for some reason has two elements with the same ID. Curses. That came about from HTML generated by re-use, and the code doesn't know that it can't re-use the same ID. The use of an ID instead of a class, though, as I recall, was specifically to force an override.

The problem is that I'm decorating a <ul> with a class, and then I want to apply a second class with conflicting properties. Generally, the main class ("menu") zeroes margin and padding on a <ul> to reset any which browsers supply, but this one specific page does want a controlled amount of margin, put on a class "jumplist". Neither <ul class="menu jumplist"> nor <ul class="jumplist menu"> will permit properties set in .jumplist to override .menu -- the specificity for both classes is equal, and the order that classes are assigned in the HTML has no say in the order. That's why I ended up using an ID, but then code re-use produced duplicate IDs. This is one reason why I wish CSS classes had true inheritance, to force one class to copy another but replace certain properties.

However, a style property will work, and that will have to do, as I don't want to dismantle and rebuild all the code to allow me to have two different IDs for otherwise completely identical lists. The only other way to do it is to alter my site's template system to link the global stylesheet last of all so page-defined styles are listed first, giving them priority in cases liike this.

[Random832]

@Daniel Beardsmore said:

The problem is that I'm decorating a <ul> with a class, and then I want to apply a second class with conflicting properties. Generally, the main class ("menu") zeroes margin and padding on a <ul> to reset any which browsers supply, but this one specific page does want a controlled amount of margin, put on a class "jumplist". Neither <ul class="menu jumplist"> nor <ul class="jumplist menu"> will permit properties set in .jumplist to override .menu -- the specificity for both classes is equal, and the order that classes are assigned in the HTML has no say in the order. That's why I ended up using an ID, but then code re-use produced duplicate IDs. This is one reason why I wish CSS classes had true inheritance, to force one class to copy another but replace certain properties.

Well, there are two solutions:

put the .jumplist code after the .menu code in the CSS file (I can tell you didn’t try this, because it works and is guaranteed to), or add a style to .menu.jumplist (or .jumplist.menu), which is more specific than a single class.

[Daniel_Beardsmore]

@Random832 said:

put the .jumplist code after the .menu code in the CSS file (I can tell you didn’t try this, because it works and is guaranteed to) ...

Ahem. I am not going to clutter up my global CSS file with every single individual page's customisations. If you read what I wrote, I did make it clear that I already understood this problem. The global CSS file is referenced first in generated HTML before any page-specific CSS (be it inline or @imported) which does upset specificity in rare cases like these. It would be trivial to fix this if I wanted to.

@Random832 said:

... or add a style to .menu.jumplist (or .jumplist.menu), which is more specific than a single class.

I don't think I've seen that before anywhere. The specs indicate that it's new in CSS 2, which is probably why I missed it. Interesting, thanks.

[dhromed]

@Daniel Beardsmore said:

@Random832 said:

put the .jumplist code after the .menu code in the CSS file (I can tell you didn’t try this, because it works and is guaranteed to) ...

Ahem. I am not going to clutter up my global CSS file with every single individual page's customisations. If you read what I wrote, I did make it clear that I already understood this problem. The global CSS file is referenced first in generated HTML before any page-specific CSS (be it inline or @imported) which does upset specificity in rare cases like these. It would be trivial to fix this if I wanted to.

@Random832 said:

... or add a style to .menu.jumplist (or .jumplist.menu), which is more specific than a single class.

I don't think I've seen that before anywhere. The specs indicate that it's new in CSS 2, which is probably why I missed it. Interesting, thanks.

IE6 doesn't do double classes like that. :(

Is .jumplist in a true local styesheet, or is @imported? @import has lower specificity than LINKed css, regardless of position.

[Daniel_Beardsmore]

@dhromed said:

IE6 doesn't do double classes like that. :(

D'oh. Figures. One of the most painfully horrible hacks on my site comes from the lack of :last-child. It's obvious, it's logical, but it only made it to CSS3 and IE still won't support it and apparently nor does Safari. It would be used to remove the bottom margin from whatever is last in #content so that there won't be a gap between #content and #footer. The tricks used to remove that gap are much messier and much more fragile.

@dhromed said:

Is .jumplist in a true local styesheet, or is @imported? @import has lower specificity than LINKed css, regardless of position.

Inside an @imported CSS file referenced by <style>, since at present I can't directly add a new <link rel="stylesheet" …>. I guess the W3C already thought of a way to hobble the next plan. I hate being at the mercy of specificity rules, and trying to figure out things that would normally just be made specific. (!important itself is pretty insane and generally shows things have gone wrong, and it's the only way Stylish and userchrome.css (!) is able to assert user CSS; I have no idea how Firefox lets userchrome.css have lower specificity than the Firefox main CSS even though it only exists to override the main CSS ...)

[dhromed]

@Daniel Beardsmore said:

at present I can't directly add a new <link rel="stylesheet" …>.

Dude. Howcome? 

[Daniel_Beardsmore]

@dhromed said:

@Daniel Beardsmore said:

at present I can't directly add a new <link rel="stylesheet" …>.

Dude. Howcome? 

Because the template system doesn't do that, and @import always worked fine without having to alter anything ;)