Tags:








Advertise here: Contact FM.


CSS3 Now
June 16, 2009 2:15 PM   RSS feed for this thread Subscribe

Take Your Design To The Next Level With CSS3.Why can’t we make use of the rich CSS3 features and tools available in modern web browsers and take the quality of web designs to the next level? It’s time to introduce CSS3 features into projects and not be afraid to gradually incorporate CSS3 properties and selectors in style sheets.
posted by netbros (77 comments total) 40 users marked this as a favorite

The fear... the fear of using CSS3 features in my projects, it haunts me in my dreams.
posted by XMLicious at 2:23 PM on June 16 [3 favorites has favorites]


My shop is still concerned about IE5 users.

...

Just throwin' that out there.
posted by boo_radley at 2:24 PM on June 16 [16 favorites has favorites]


Any amateur web developer's response: Cooooooooool!

Any professional web developer's response: Yeah, yeah, yeah. Later.
posted by rokusan at 2:25 PM on June 16 [10 favorites has favorites]


"Realistically, you won’t be able to use these on your everyday client projects for another few years, but for design blogs and websites aimed at the Web design community, these features can help you push the boundaries of modern Web design today..."

These are shiny new toys, not tools. What rokusan said.
posted by waxboy at 2:28 PM on June 16 [3 favorites has favorites]


Sure, waxboy, but that same philosophy applies to CSS2 and other long extant technologies as well. It's tremendously difficult to get some people to ever make the jump, regardless of how good it would be for them.
posted by boo_radley at 2:34 PM on June 16


> My shop is still concerned about IE5 users.

Well, most CSS3 things require browser-specific hacks/rules, so one extra browser to deal with can't be a problem! Seriously though, IE5? Doesn't that have a browser share in the promille range by now?
posted by bjrn at 2:35 PM on June 16


Although I am going to pimp the hell out of my wordpress blog, yo.
posted by boo_radley at 2:35 PM on June 16 [2 favorites has favorites]


CSS makes my head hurt. It's declarative programming. All the fun of prolog without finding out who own the zebra.
posted by GuyZero at 2:35 PM on June 16 [22 favorites has favorites]


Text columns is nice. I suspect that's something we'll see get a lot of use.
posted by Astro Zombie at 2:36 PM on June 16 [1 favorite has favorites]


Seriously though, IE5? Doesn't that have a browser share in the promille range by now?

Yep.

Browser Market Share (May 2009):

Microsoft IE (all versions) -- 65.50%
IE 5.0 -- .04%
IE 5.5 -- .03%
posted by ericb at 2:50 PM on June 16


You're only making me sadder.
posted by boo_radley at 2:52 PM on June 16 [1 favorite has favorites]


Boo_radley, I should have said "...not tools, yet". The problem is legacy support, and it will be a while before enough users switch to modern browsers and enough sites get so old that an overhaul using the latest technology makes sense to management. Not that this stuff is useless, just that it will be a while before it can blossom. In the mean time we're stuck with the status quo, hence the meh.
posted by waxboy at 3:01 PM on June 16


This article states that we should use all these new features, then you go through the list of browser support and some of them are barely supported (e.g. Safari and Konquerer only). What good is that?

Look, when CSS first hit the scene, we had this problem. People loved their table-based layouts, and there were huge issues with disparate rendering problems (which, apparently, hasn't changed much.. thankfully I left the web design biz 8 years ago). This sounds like exactly the same situation -- people are used to doing it a certain way, and there's questionable support for it across the board. We'll eventually start using it, but now is most certainly not the time.
posted by spiderskull at 3:01 PM on June 16


Yeah, I've been playing around with some of this stuff on my own (I'm trying to draw a cartoon zombie using border-radius). It's pretty neat, but it'll be a while before we can really use it.
posted by brundlefly at 3:05 PM on June 16


It's tremendously difficult to get some people to ever make the jump, regardless of how good it would be for them.

Well, that's sort of the problem, isn't it? Just how is any of this "good" for them? What's the point of making any "jump" if it's just about rounder corners, smoother shadows, etc. etc? CSS3 just looks like more shiny objects for squirrels. Wake me when an actual improvement in true functionality and usage pops up. One that doesn't require a hack to make it work with 90% of your visitors.
posted by Thorzdad at 3:06 PM on June 16 [1 favorite has favorites]


CSS makes my head hurt. It's declarative programming. All the fun of prolog without finding out who own the zebra.

This made me laugh really hard, but....

When you can, you want to move to declarative-ish programming... places where you tell the computer what something is, and from some framework, the computer figures out what to do for you. A lot of the gains from MVC frameworks are essentially made by turning certain tasks into something that just happens when you define your pieces.

YMMV, I suppose. And it's certainly frustrating that you can't do computational things in CSS. Sometimes I think we might have been better off if DSSSL had won.
posted by weston at 3:09 PM on June 16 [2 favorites has favorites]


I had never heard of DSSSL but if I wanted PostScript, I'd program in PostScript.

Man, NeWS should totally have won. Xview stank. Motif stank. NeWS was Gosling's "THX 1138" that is way better than the huge hit he had right after that.
posted by GuyZero at 3:19 PM on June 16 [2 favorites has favorites]


Take Your Design To The Next Level With CSS3.

With a few exceptions, isn't this a misconception?

Features like web fonts, multi-columns, and CSS rounded corners sure make implementing a given design and content changes easier, but once we passed the alpha transparency hurdle, I'm not sure how many features actually make new levels of design possible.
posted by weston at 3:23 PM on June 16 [2 favorites has favorites]


CSS3 allows designers to do the same things we do today with fewer divs, and in some cases with fewer images.
posted by verb at 3:29 PM on June 16


Still no variables or constants? I'll be sticking with Sass.
posted by PenDevil at 3:31 PM on June 16 [1 favorite has favorites]


I had never heard of DSSSL but if I wanted PostScript, I'd program in PostScript.

?

DSSSL wasn't stack-based, and even though it had some computational and I think some drawing ability, the usage was intended to be more or less declarative, even if the syntax is LISP-y/s-expressionish.

Man, NeWS should totally have won.

NeWS was extended PostScript from everything I've heard, and I'm not sure the same things that work for a windowing system would work for a semantic document centered browser, but I could be wrong.
posted by weston at 3:33 PM on June 16


CSS3 allows designers to do the same things we do today with fewer divs, and in some cases with fewer images.

OK, I get it now. The perils of the terminology "web design" strike again.
posted by weston at 3:35 PM on June 16 [1 favorite has favorites]


Does CSS3 really still not support definitions of colors?

As a programmer that's relatively new to web development, I found it boggling that CSS did allow the definition of reusable color constants. Instead, you're forced to either do global find and replace on your CSS files or put scripting elements into your CSS files and parse them accordingly.

This seems like such a common sense feature that I'm dumbfounded as to why it wouldn't be included. Is it truly not included? Is there a reason why not?
posted by christonabike at 3:48 PM on June 16


> Why can’t we make use of the rich CSS3 features and tools available in modern web browsers and take the quality of web designs to the next level?

Internet Explorer.

Okay, that's glib.

Different browsers support different subsets of CSS3. It's not an official standard yet. It has reached minefield status, because any draft specifications that a browser conforms to now may change before ratification, especially if a representative of a competing browser successfully changes the spec.
posted by ardgedee at 3:53 PM on June 16


I want to be able to have two boxes side-by-side, each with content of varying lengths, where the shorter-content box's bottom border is aligned with the bottom border of the longer-content box. Without JavaScript.

I want to be able to have ellipse-based truncation without resorting to XUL in FireFox.

While I'm at it, I want em-based measurements to round off consistently. FF3 and IE6, I'm looking at you.

Until those things are supported everywhere I need them, there is no revolution.
posted by davejay at 3:55 PM on June 16 [3 favorites has favorites]


This seems like such a common sense feature that I'm dumbfounded as to why it wouldn't be included. Is it truly not included? Is there a reason why not?

CSS is not a scripting language.
posted by davejay at 3:59 PM on June 16 [4 favorites has favorites]


I want to be able to have two boxes side-by-side, each with content of varying lengths, where the shorter-content box's bottom border is aligned with the bottom border of the longer-content box. Without JavaScript.

I think there's some markup that's supported this handily since the mid-90s. :)
posted by weston at 4:00 PM on June 16 [1 favorite has favorites]


I think there's some markup that's supported this handily since the mid-90s. :)

Forgot to say: not in a table, either. :P
posted by davejay at 4:21 PM on June 16


Forgot to say: not in a table, either. :P

Ok, use frames then :)
posted by wildcrdj at 4:25 PM on June 16


reusable color constants...

.green {color: #0f0;}

<p class="green">Hi I'm green.</p>
posted by rokusan at 4:31 PM on June 16


The next level of what? What level are we on now? Did this team come here to play ball? Do they have both speed and quickness? Are they giving it 110%??
posted by Devils Rancher at 4:31 PM on June 16 [5 favorites has favorites]


Ok, use frames then :)

First tables, now frames; you people obviously want me to stab myself in the neck. :P

.green {color: #0f0;}
<p class="green">Hi I'm green.</p>

This works beautifully until someone decides those elements should be yellow.
posted by davejay at 4:36 PM on June 16


People like to do round corners on DIVs at the moment because its slightly tricky (at least its tricky if you want to do it in pure HTML and CSS and get it to either work in all browsers or degrade nicely) and so if you have a nice round-cornered design it sets your page design apart from the norm.

So once CSS3 becomes widely adopted and round corners are easy to do, there wont be as much point in doing it anymore. And the cutting edge of web design will move on to things that are difficult to do in CSS3.

In other words, however much they evolve the CSS and HTML standards, people will still be hacking their way over the cutting edge into a tag soup of browser hacks.
posted by memebake at 4:43 PM on June 16 [9 favorites has favorites]


So once CSS3 becomes widely adopted and round corners are easy to do, there wont be as much point in doing it anymore. And the cutting edge of web design will move on to things that are difficult to do in CSS3.

Boy, isn't that the truth. However, IE8 still doesn't support border-radius apparently, so look forward to more rounded corners for the time being.
posted by davejay at 4:56 PM on June 16


Pooh, rounded corners! Now what about circles?
posted by Brandon Blatcher at 4:57 PM on June 16


First tables, now frames; you people obviously want me to stab myself in the neck. :P

Well, if you've been trying to do what you described above using any other method than table markup, I'd argue you've already been conducting exercises in self-flagellation for a while now, but sometimes the constraints are the fun.

And regarding frames... I also think it's horribly annoying to have your document explode into multiple HTML files, but there's at least some rumor that blind users like 'em.
posted by weston at 5:06 PM on June 16


This works beautifully until someone decides those elements should be yellow.

I was once called in to do a redesign on a site whose original builders had subscribed to the "we don't understand what the C in CSS means" name scheme, so used hundreds of individual classes for each element on the page, all with names like "redBoldLeftalignedBigtext". By the time I got to it the site had already been through enough tweaking that the RedBoldLeftalignedBigtext was neither red, bold, left aligned, nor big.

It was still text, though.


That said, though, rokusan's partly right: if you're doing a lot of search-and-replacing color definitions in your css, you're probably doing it wrong; it's usually better to define a single class to contain the hex code and apply that class to whatever nodes should use it, instead. Preferably a semantic name describing the usage, though, not "green".
posted by ook at 5:09 PM on June 16 [1 favorite has favorites]


> I want to be able to have two boxes side-by-side, each with content of varying lengths, where the shorter-content box's bottom border is aligned with the bottom border of the longer-content box. Without JavaScript.
Faux columns is what you’re after. Or the liquid variant, if you prefer.

As for rounding errors and proper ellipsis, I couldn’t agree more.
posted by sidesh0w at 5:10 PM on June 16 [1 favorite has favorites]


> CSS is not a scripting language.

I understand this. However, CSS already supports color constants. CSS3 is supporting the full SVG color spec, all I'm asking for the ability to define my own colors.

> ...it's usually better to define a single class to contain the hex code and apply that class to whatever nodes should use it...

I understand this and do this in some contexts. What I'm asking for is the ability to avoid redundantly entering color information and it's very hard to do with CSS. The problems with a class based color approach are at least two fold:
When I design websites, I probably use about 8-12 different colors. It's a pain in the ass to both remember all those hex codes or change one of the hex codes when I want to. All I want to be able to do is something like this:

div.foo { color: primaryBackground; }

which would then be easy to change to:

div.foo { color: secondaryBackground; }


Are people really arguing that this wouldn't be useful? I certainly don't see anyway to replicate that behavior without running into the two problems I outlined above.
posted by christonabike at 5:29 PM on June 16


You may or may not know that what you're describing is a very long-standing controversy in CSS, christonabike. See here, here, and here just for a quick random sampling of the first few links on the subject I could google up.
posted by ook at 5:58 PM on June 16


Faux columns is what you’re after. Or the liquid variant, if you prefer.

Believe it or not, we explored those (and some others) and always encountered some shortcoming that invalidated it for our needs. I appreciate the links, though, in the spirit of "if I didn't know, I'd be thrilled." :)

Christonabike, I had a bit of trouble following your example, but a common approach (at least in this neck of the woods) is to use semantic markup. Assign one or more classes that describe each component, then assign visual attributes to that component description instead of the component itself.

Oversimplified example (i'd normally use more descriptive classnames):

h2 {font-weight:108%;font-weight:bold;color:#333;}
p {font-weight:100%;font-weight:normal;color:#666;}
.error {font-weight:bold;color:red;}
.success {color:green;}

<h2>I am a normal header</h2>
<p>I am a normal text string, <a class="error">but this link is related to an error condition.</a></p>

<h2 class="error">I am an error header</h2>
<p>I am a normal text string</p>
<ul>
<li class="error">I am an error</li>
<li class="success">I am a success</li>
</ul>

This way the markup defines its purpose when you read it, and you can use element-specific selectors when your common design pattern (for errors, say) requires an element-specific presentation:

.error {color:red;}
a.error {font-weight:bold;}

<p class="error">I am red text <a class="error">and I am red and bold</a></p>
<li>I am normal text <a class="error">and I am red and bold</a></li>

Then, when you want all your errors to be orange instead of red, you just update your single .error selector to the new color. .error becomes the constant, but it's not tied (in name) to the presentation, and it's not tied to any specific element, except where it must be for your own design requirements.

Of course, that's one of many solutions; it's just one that works for us. Requires discipline, though, and you must take care to avoid digging yourself a hole where .foo.bar (as opposed to .foo .bar) is required since not all browsers support it.
posted by davejay at 6:14 PM on June 16 [1 favorite has favorites]


So...will this newfangled CSS3 actually keep people from designing crappy web sites? If not, then it's not really an improvement, just more of the same, only more of it.
posted by happyroach at 6:39 PM on June 16


CSS makes my head hurt. It's declarative programming. All the fun of prolog without finding out who own the zebra.

Take a look at XSLT sometime.
posted by delmoi at 6:44 PM on June 16


This works beautifully until someone decides those elements should be yellow.

Yeah, yeah, I was just making a simple example.

Replace 'green' with 'christonabikes_favcolor' for the complete result. Named colors would be cute, but that's close enough that it's not worth fretting about, I don't think.
posted by rokusan at 6:53 PM on June 16


Well, our state-wide department should be getting rid of IE6 at the end of the year, fingers crossed. They're waiting for IE8 to get established before they move to IE7 :)

I'm looking forward to including a few CSS3 tweaks and frills for the people using non-mainstream browsers, without worrying about the IE audience seeing exactly the same design. Proper support for CSS2 didn't happen until web developers/designers started just using the features and telling IE audiences that they weren't getting the full experience. This will be the same - those at the cutting edge will start using CSS3, and that'll put pressure on the mainstream to catch up with their support.
posted by harriet vane at 6:54 PM on June 16



> Why can’t we make use of the rich CSS3 features and tools available in modern web browsers and take the quality of web designs to the next level?

Internet Explorer.

Okay, that's glib.


Is it really? I mean, this is why I don't use this stuff. I work in the real world, where you have to build stuff that looks good in what people actually use.
posted by dubitable at 7:23 PM on June 16 [1 favorite has favorites]


I want to be able to have two boxes side-by-side, each with content of varying lengths, where the shorter-content box's bottom border is aligned with the bottom border of the longer-content box. Without JavaScript.

Does this count?

CSS:

#main {
width: 900px;
display: table;
}

#box1 {
width: 450px;
background-color: #999;
display: table-cell;
}

#box2 {
width: 450px;
background-color: #C9C;
display: table-cell;
}

HTML:

&lt div id="main"&gt

&lt div id="box1"&gt Content for id "box1" is Here&lt/div&gt

&lt div id="box2"&gt Content for id "box2" is Here. Content for id "box2" is Here.Content for id "box2" is Here.Content for id "box2" is Here.Content for id "box2" is Here.Content for id "box2" is Here.Content for id "box2" is Here.&lt/div&gt

&lt/div&gt
posted by jeremias at 7:26 PM on June 16


Crap, my tricky method of making brackets backfired. Worked in preview.
posted by jeremias at 7:27 PM on June 16


> ...but a common approach (at least in this neck of the woods) is to use semantic markup. Assign one or more classes that describe each component, then assign visual attributes to that component description instead of the component itself...

I understand this concept thoroughly and this is already what I do. However, even with semantic markup you're still going to end up repeating colors. That was my original complaint: I don't want to repeat colors, I want to be able to set color constants.

Others argued that having a class correspond to a color is essentially the same thing, I was trying to explain (perhaps unsuccessfully) why that is an even worse idea than repeating color declarations.
posted by christonabike at 8:02 PM on June 16


When people talk about setting colors with a variable in CSS what they are really talking about is establishing a color palette in a small amount of CSS markup so you don't have to have the same color definition 30 times in your CSS file, or the same class name sprinkled throughout your markup umpteen gazillion times.

You can, however, get part of the way there.

* {border-color: #ccc; /*all my borders are light grey*/}
* {border-style: solid; /* all my borders are solid lines */}
* {border-width: 0px; /* hide borders until I need them */}

h1 {border-bottom-width: 1px;}

C in CSS means "Cascade". It works. Try it.
posted by device55 at 8:29 PM on June 16 [1 favorite has favorites]


>display: table (and the accompanying table row and cell styles) fail in all versions of internet explorer but IE8

IE 7, 6, 5- make up 60-ish percent of the browser market.

http://www.quirksmode.org/css/display.html

Also, entities must be followed by a semi colon - &gt; = >
posted by device55 at 9:04 PM on June 16


christonabike, you really ought to read the last of the links I pointed to earlier (this one)... it's a pretty clear explanation of why what you're asking for isn't going to happen. (For what it's worth, I think it'd be handy too, but I can see why they don't want to build it in to the core language -- mostly because you can already do it by preparsing the css file if you really want to.)

jeremias: IE doesn't support display:table or display:table-cell, so no, that doesn't count. I will never, ever, ever understand why people continue to throw such horrible complex code at this problem: just use a damn table. It works. It's easy to read, compact, cross-browser, and consistent. There is no reason to go through all the contortions with negative margins and weird floats and browser hacks and fragile dependencies on percentage widths or whatever that people keep trying, for no apparent reason other than an inexplicable allergy to the perfectly good tag that already does this just fine. Just use a damn table.
posted by ook at 9:14 PM on June 16 [1 favorite has favorites]


ook - for the simple reason that it's not tabular data. You use the right, and semantically correct, tools for the job.

Now, changing the display type to table-cell does work a treat. I know it's supported in IE8... I'll grant that it doesn't work in earlier versions of IE. And table-cell was part of the CSS 2 spec, which was finalised in 1998 for goodness sake: there's no-one to blame there but Microsoft.

Of course, flowing, newspaper-like multi-column layout is supported in CSS3 - needless to say, no version of IE knows anything about it as of this writing.
posted by Bora Horza Gobuchul at 9:30 PM on June 16


CSS Colors: Take Control Using PHP

How to deal with IE6
posted by kirkaracha at 9:50 PM on June 16


Semantic, schmemantic. Thpbpbpbpbpbpth.

Seriously, what tangible benefit does using the oh-so-semantic <div> tag give you, that outweighs the complexity and fragility of the "pure css" methods (most all of which wind up requiring extra nonsemantic html nodes anyway, to work around box model problems)? None. No benefit at all.

there's no-one to blame there but Microsoft.

Yeah, well, if I depend on code that isn't supported in half the user's browsers, there's no-one to blame but me.
posted by ook at 9:52 PM on June 16


ook - I would be happy to inform you, but I don't participate in childish banter.
posted by Bora Horza Gobuchul at 10:03 PM on June 16


Oh, come on now. Really?
posted by ook at 10:15 PM on June 16


Oh, you're an academic. I see. Well, yes, in that environment you're absolutely correct.
posted by ook at 10:22 PM on June 16


All I want to be able to do is something like this:
div.foo { color: primaryBackground; }
which would then be easy to change to:
div.foo { color: secondaryBackground; }

I do this in Django's template language, like so:

div.foo { color: {{ primaryBackground }}; }

where {{ primaryBackground }} get transformed into a variable within the template's context.
posted by signal at 10:24 PM on June 16


I do this in Django's template language, like so...

Those arguing for seemingly endless scope creep in CSS really need to realize that CSS should no more be generated by hand than machine code. Well, it will probably be somewhat manually generated, but a lack of variables in CSS is easily rectified by using one of the millions of web template systems out there.
posted by GuyZero at 11:05 PM on June 16 [1 favorite has favorites]


it's not tabular data. You use the right, and semantically correct, tools for the job.

Seriously, what tangible benefit does using the oh-so-semantic <div> tag give you

ook - I would be happy to inform you

Recalling some of ook's posting on past related topics, I suspect he's probably familiar with a lot of the discussion, and I tend to agree with him.

The div tag is more or less a block level container element with no semantics, used to place pieces of a document in a presentation scheme. Table markup, while originally intended for tabular data, has essentially acquired some semantic ambiguity in actual usage. Sometimes it means tabular data. Sometimes it's essentially used like the div, an asemantic block level container, largely used to place sections of the document in a presentation scheme.

This is usually the part where people talk about the potential of the semantic web and things like screen readers and spiders and other mechanical readers that don't produce visual layout and which theoretically could use an unambiguous situation to better process and present the document. While I think there's some weight to that discussion, it seems to me a closer look at the issue reveals it to be overblown.

The assumption seems to be any ambiguity between tabular data and layout will wreck the whole semantic potential. Even if that were true, that horse has been out of the barn since 95/96 and won't be back for a while yet despite the fervor and progress of related evangelism. I don't think that assumption is true, though. In a reasonably well-structured document, most human coders can readily distinguish the disposition of a given piece of table markup, and the heuristics involved aren't so difficult that a machine couldn't learn to do it. And the information I've got suggests that indeed, at least some screen readers have managed to reach a level of sophistication where they can make distinctions... heck, Lynx has been doing it more or less since 1999. Which makes sense, really. Any reader which was going to be useful for most of the web over most of its history so far has to have developed this capacity, because that's how HTML turned out to be used.

Now, even if semantic issues are overblown, there are some additional potential advantages to separating layout entirely from markup when it can be done (not always possible even with mighty CSS skills) which are completely practical: you don't have to muck about with markup to make some layout changes, and sometimes the CSS way turns out to be easier. But if you're in the realm of practical advantages, I agree with ook, when you get to a certain point of hoop-jumping with CSS positioning, where the tools are putting you through gymnastics and causing you grief rather than facilitating solutions, it's perfectly fine to consider the tradeoffs of other tools that might not.

People sometimes act as if CSS layout is the goal. It’s not, it's just one tool. More or less, what you really want are documents that:

1) Render a given design effectively for visual user agents (and potentially a variety of user agents)
2) Don't impose unwieldy costs when being moved over the network or being processed and rendered
3) Don't break when arbitrary content is added/edited
4) Aren't difficult for humans to read, edit, and potentially even re-mold when re-design comes.
5) Convey information to germane mechanical readers
6) Are created with the above goals in mind within a likely limited budget of time and money.

By and large I've found that CSS positioning helps with these goals, but sometimes I still find it working against some of them (particularly that last one), despite the fact that I've had considerable practice with doing things that way for literally hundreds of arbitrary designs. Things are clearly getting better as browser support improves, but IMHO, even in browsers where support is quite good, the limitations of CSS positioning itself sometimes still show.
posted by weston at 11:52 PM on June 16 [3 favorites has favorites]


There might be a theoretical semantics for TABLE, but no-one in their right mind would ever apply different practical mark-up rendering to it because the vast majority of TABLE elements are used for layout. So the real-world semantics of TABLE are "layout".

I'd argue (and I implemented in my web browser for blind people) that any of "a TABLE with a child CAPTION element" or "a TABLE with TH children" or "a TABLE with a child SUMMARY element" has the semantics "This is a data table". Any other TABLE is simply for layout. This is the real-world situation, and it is never going to change. You are never going to be able to assume that a TABLE you encounter is a data table and parse it differently.

So in my web browser, if a "data table" is encountered then the user is given the ability to open it in a grid format that can be navigated around with the cursor like an Excel spreadsheet. Otherwise I just ignore it (or use it for structuring blocks of layout.)

Imagine if the W3C issued HTML 4.2 with these de-facto semantics enshrined in the de-jure specification. We could keep using our practical working TABLE elements and we could have data TABLEs too! And most of all imagine the person-years (-decades? -centuries?) of times we could save in coding and arguing! Think of the extra time with our children/reading a book/going for a walk/writing better content!
posted by alasdair at 11:54 PM on June 16 [1 favorite has favorites]


there are some additional potential advantages to separating layout entirely from markup when it can be done

The web is a connected graph of visually-formatted pages. The semantics are in the connections (Google search) and in the visual layout of the pages (left-hand-side, lots of links, smaller = navigation bar; larger text near the top but under some little links = page title; thing styled to look like an application button = something you can click on; etc, etc.) There are very few meaningful semantics in real-world HTML: TITLE, H1-H6 if you're lucky. OL and DL a bit. That's about it. You can't rely on anything else being meaningful.

As soon as you make one set of links one colour and another set of links another color you're using CSS for semantics. Sure, there may be different "class" attributes on each set in the HTML, but the semantics of these classes are undefined and you have no real way of communicating them to the user. They only make sense when you see (and I mean use sight) the sets of links and their color on the page.

Don't agree? OK, here's a relatively simple one: without rendering on the screen, or assuming semantics on class and id elements, how do you identify the presence and content of a navigation bar on an arbitrary web page? We all know what they are: we can all identify them instantly when we see them: but they aren't defined in HTML4. You'll have to wait for HTML 5, with a NAV element, to come out before you can do it. (If we'd spent half the time over the last decade on improving the semantics of HTML4 rather than doing pointless TABLE to CSS conversions we'd all be much better off!)

So until the majority of websites are using the semantic elements of HTML5 correctly - and how long do you think that will be? - I'd suggest that while one should be a "good citizen" and respect the limited HTML4 elements' semantics where it doesn't cause any problems, and use H1-6 because they have a real benefit to screenreader users, one shouldn't give it too much thought.
posted by alasdair at 12:28 AM on June 17


Those arguing for seemingly endless scope creep in CSS...

GuyZero has it. If variables were added to CSS people would start whining, "I can set my fixed layout width as a variable, why can't I have some mathematical expressions to do calculations off of that?" and next, "I can do mathematical expressions, why can't I write functions?" and it won't be too long until you have something starting to look just like javascript or XSL which we already have access to. I was actually kind of surprised that just stuff like CSS 2.1 counters were ever added.
posted by XMLicious at 12:49 AM on June 17


The only new kind of combinator introduced in CSS3 is the general sibling selector. It targets all siblings of an element that have the same parent.

I'm sure this won't lead to any unmaintainable messes.
posted by atrazine at 1:29 AM on June 17


I like this discussion. Keep going.
posted by CCBC at 2:55 AM on June 17


As far as preprocessors go, I feel that LESS has hit the right balance between usefulness and complexity. It has variables, mathematical operations, mixins and nested scope, but its greatest virtue is that it's a superset of CSS and doesn't force you to throw out or convert your existing stylesheets. And the syntax chosen for the new features is just perfect.
posted by dmit at 3:28 AM on June 17


If variables were added to CSS people would start whining, "I can set my fixed layout width as a variable, why can't I have some mathematical expressions to do calculations off of that?"

Well to be fair (and as one of the links above makes clear), what people are really talking about are constants, not variables. Just the ability to define a palette would be incredibly useful.

The best way to emulate it, as far as I can see, is pre-parsing the CSS file to replace, say "$color1" with "#FF5566", with a lookup table of the palette in a separate file.

Unfortunately, I'm not a web designer. These days, my mucking about with HTML generally involves modifying pre-made templates for pre-made applications, where this sort of system is very rarely in place, and I have to resort to finding-and-replacing manually. Ugly.
posted by Jimbob at 4:00 AM on June 17


(Oooh, I like the look of LESS...)
posted by Jimbob at 4:02 AM on June 17


Constants, whatever. People would still immediately ask to be able to do expressions that calculate an HSV color variant of the value of a constant or do arithmetic on constants holding dimensions of layout elements.

Just get a pre-processor / build system / "bake" CMS, or use a server-side scripting language (Server Side Includes is built-in to the major web servers, though you need to configure security correctly - which should be done anyways - and enable it), or use javascript or XSL (I think this could be accomplished with a client-side XSLT... hmm...) or one of the bazillion methods already available for doing this.

Heck, the search and replace in your editing tool isn't that bad if your CSS is separated out into .css files - unless you're using data URLs it's unlikely you'd match anything other than the hex color code you're searching for.

I personally use Maven to do this, which lets you define an unlimited number of search-and-replace tokens, or because it's actually for heavy-duty Java development would also let you run regexes or an XSLT or anything else you can think of (I should see if there's a plugin for LESS) as a pre-processing step. (Also very handy is that I can hook in ImageMagick as a build step and thereby do things like auto-crop and resize my original images or generate pngs from svg graphics.)
posted by XMLicious at 4:31 AM on June 17 [1 favorite has favorites]


Give Up and Use Tables
posted by jcruelty at 7:18 AM on June 17 [3 favorites has favorites]


:not should have been part of CSS vocab from Day 1.
posted by spamguy at 7:54 AM on June 17 [1 favorite has favorites]


Well to be fair (and as one of the links above makes clear), what people are really talking about are constants, not variables. Just the ability to define a palette would be incredibly useful.

Run your CSS files through CPP then, ffs. C programmers somehow managed to live without support in the language for global constants. Since most web sites are de facto applications, you need a build process for them. Again, scope creep isn't the solution for every problem.
posted by GuyZero at 8:22 AM on June 17 [1 favorite has favorites]


Thanks for stepping in, weston and alasdair (and for your cheerleading, CCBC! :-)

You all make very good points: practically, especially given the fact that the vast majority of pages don't even validate, insisting on the semantic use of tables may be something of a Sisyphean quest. However, that's my boulder to roll. ;-)

OK, here's a relatively simple one: without rendering on the screen, or assuming semantics on class and id elements, how do you identify the presence and content of a navigation bar on an arbitrary web page?

By the fact that it's an un/ordered list of local links? I do agree that the semantic clarity could be a lot stronger, and nav will go a long way towards making that happen, should it be taken up. The nearest existing tool in the existing spec is the rel attribute, which never really took off, unfortunately.

I do appreciate the approach of your browser in regards to tables, alasdair, tho personally I think it presumes a little too much on the ability of coders: HTML tables that don't use th, caption, or summary would be the majority of web content, I'm guessing, including those that contain actual tabular data: if I'm following your approach correctly, your browser would assume that all tables lacking those elements are presentational "tag soup".

To me, this comes back to Microsoft adamantly refusing to support the CSS2 spec (or worse, implementing it in a half-assed way) for the last dozen years. Using CSS to change the display type of a element from block to inline to table-cell is very straightforward to me: it doesn't change the semantics of the element, but changes the presentation... which is exactly what CSS is for.

I would argue that div does have some meaning, if overly broad - it's a logical division to group like content. I'm in complete agreement that nav and footer are what div should have been in in the first place, perhaps with the addition of a content tag.
posted by Bora Horza Gobuchul at 10:18 AM on June 17


By the fact that it's an un/ordered list of local links?

Better (with anchor tags omitted for clarity):

<dl>
<dt>Site Navigation Links</dt>
<dd>Link</dd>
<dd>Link</dd>
<dd>Link</dd>
<dd>Link</dd>
...

Then use CSS to hide the <dt></dt> tag pair. CSS-enabled browsers get your pretty links in the right position (where the position provides the clue that they're navigation), CSS-disabled browsers get your "Site Navigation Links" term to make up for the lack of CSS positioning, and screen readers read out the definition term "Site Navigation Links" followed by a list of definition descriptions they can navigate and select from.

Also: Alasdair, I applaud your decision on judging tables that way, because it's a great way to overcome the prevalence of table-based layout -- but not all screen readers work that way, unfortunately. It ends up being a toss-up; do you make a sub-par accessibility experience but give your visual designers exactly what they want, or do you make a sub-par visual experience to better serve your blind users? The ideal choice is to give the best experience to both...which we can't yet do without javascript or trickery or convincing visual designers that their designs should be simplified to improve them. Needless to say, I always try that last one first.
posted by davejay at 10:32 AM on June 17


Another unfortunately ignored standard that was designed to account for many of the logistics of expressing which links are important and where they're going to take you is XLink.
posted by XMLicious at 10:57 AM on June 17


I should note, XLink can be kind of thick to wade through if you're just looking for the application it might have to web pages because it's written to be pretty general-purpose.
posted by XMLicious at 10:59 AM on June 17


« Older The Medill School of Journalism's Washington Progr...   |   Hooping. The hoops adults use ... Newer »


This thread has been archived and is closed to new comments