Posts in the CSS Category

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart.  (Sort of like Return of the Jedi had a working title of Blue Harvest.)  In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise.  The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose.  I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves.  Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article — which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.

• In Defense of Vendor Prefixes was published on Wednesday, July 7th, 2010.
• It was assigned to the CSS, Standards, Web, and Writing categories.
• There have been seven replies.

Monospace text sizing is, from time to time, completely unintuitive and can be quite maddening if you don’t look at it in exactly the right way.  Fortunately, there is a pretty simple workaround, and it’s one you might want to consider using even if you weren’t aware that a problem existed.

But first, allow me to lay some foundations.  Assuming no other author styles beyond the ones shown, consider the following:

span {font-family: monospace;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

All right, what should be the computed font-size of the span element?  Remember, there are no other author styles being applied.

The savvier among you will have said: “It depends, but most likely 13px.”  That’s because here, the size of the monospace text is controlled by the browser’s preferences.  The vast majority of users, of course, have never touched their default settings of “16” for proportional fonts and “13” for monospace/fixed fonts.  For them, then, the answer is 13px.  Similarly, if I’d asked about the p element’s computed font-size, the answer would be: “It depends, but most likely 16px.”

So let’s add a bit more and see where we land.

span {font-family: monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

As before: bearing in mind that there are no other author styles, what should be the computed font-size of the span element?

In this case, building on the previous question and answer, you might say, “It depends, but most likely 16px.”  The reasoning here is pretty straightforward:  since the computed font-size of the p element is 16px, the font-size: 1em; assigned to the span will result in it having the same size.

And that’s true… in two of five browsers I tested: Opera 10 and Internet Explorer 8.  In the other three I tested—Firefox 3.6, Safari 4, and Chrome 4—the computed (and rendered) font-size of the span is 13px, the same as in our first example.  This result holds true if the rule is changed to use font: 1em monospace; instead of the two separate properties.  The behavior continues to persist even when adding specific font families, like Courier New, Courier, Andale Mono, and so on to the rule.  It also persists if 1em is converted to 100%.

So in other words, even though I have written CSS that explicitly says “Make the font-size of this element the same as its parent”, three of five browsers apparently ignore me.

I say “apparently” because what’s happening is that those browsers are allowing the span to inherit the default font-size from its parent (and thus, indirectly, all its ancestors), but the default font-size is medium.  If you go look up medium, you find out that it doesn’t have a defined numeric size. So what those browsers do is equate medium with the preference settings, which means it’s different for monospace fonts than for everything else.

In other words, those three browsers are doing something like this:

1. This span needs to have the same font-size as its parent element.
2. The parent’s font-size is medium, even though when my web inspector (or an author’s DOM script) asks, I report the 16px I used to output the text.  So the span‘s font-size is actually medium.
3. This medium-sized span is using a monospace font.  The preference setting for monospace is “13”, and I equate medium with the preference setting, so I’ll output the span using 13-pixel text.

Opera 10, as I said, doesn’t do this, even if your monospace font preference setting is the default value of “13” or indeed different from the preference for non-monospace fonts.  And IE8 doesn’t appear to do it either, although you can’t set numeric font size preferences in IE8 so what it’s actually doing is open to interpretation.  Oh, IE8, you inscrutable little scamp, you.

All that might seem reasonable enough, but it turns out that’s not the whole story.  No, the three resizing browsers are being a good deal more “clever”, if that’s actually the word I want, than that.  In fact, what those browsers do makes it seem like they use the two preference settings to create a ratio, and that ratio is used to scale monospace text.  That’s not actually what’s happening, but it looks that way at first.  To see what I mean, let’s consider:

span {font-family: monospace; font-size: 2em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Again: in the absence of other author styles, what should be the computed font-size of the span element?

The answer: “It depends, but most likely 26px as long as we aren’t talking about Opera 10 or IE8.  If it is one of those two, then most likely 32px.”  Why?  Because the resizing browsers see the font-size: 2em; declaration as “twice medium” and twice 13 is 26.  Opera 10 and IE8, as previously established, don’t do the resizing.  Or else they simply interpret medium as being equal to the proportional font size preference setting.  Whatever.

Okay.  So what all this means is that in many browsers, you can declare that an element’s font size should be twice the size of its parent’s and have it actually be 1.625 times the size — or, if you want to look at it another way, 0.8125 times the size you expected it to be.  The 0.8125 comes from 26/32, which of course reduces to 13/16.  If you were to adjust your browser’s preferences so the monospace setting is “15”, then monospace fonts would be 0.9375 (15/16) times the expected size.

But — and here’s where things get really fun — this is not always so.  See, you may not have run into this problem if you’ve been declaring specific font families with no generic fallback.  Consider this variation (note that I dropped back to 1em for the font-size):

span {font-family: "Courier New"; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time, in every one of the five browsers I mentioned before, assuming the browser defaults, the computed (and rendered) font-size of the span will be 16px.  Not 13px.  And the only difference is that we switched from a generic font family to a specific one.

“Hey presto!” you shout.  “We’ll just tack the generic family on the end there and be right as rain!”  Sadly, no.  For if you do this:

span {font-family: "Courier New", monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

…then the answer to the question I keep asking will be:  “It depends, but given browser defaults it will be 16px, unless we’re talking about Safari.  In that case, it’s 13px.”

Really.  Alone among the browsers I tested, Safari goes back to doing the resizing when you provide a generic fallback to your specific family.  Or even multiple families.  Do your best to make sure the user at least gets a fixed-width font, and you get a size smaller than you’d intended.  (You can get the back story on this in a late-2006 post on the Surfin’ Safari blog.)

So what do we do?  Get creative.  That’s what the ARIA folks did in their specification’s style sheet, where they declare two font stacks: the first with a generic fallback, and the second without it.  That works, but it’s ugly.  I didn’t like that at all.  And then, halfway through writing up this post, a fix came to me like a shot in the dark.  Check this out:

span {font-family: "Courier New", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time around, the answer is:  “It depends, but given browser defaults, 16px.”

Really!  Even in Safari!  And in all tested browsers, it falls back to a generic monospace font at the requested size even if the specific family (or families) we declare aren’t available!  This can be verified by altering the specific font family to something that doesn’t actually exist:

span {font-family: "Corier Neu", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Monospacey goodness at the intended, parent-matching size.  It’s enough to make a body believe in monotheism.

Since I generally assume that anything I devise was already invented by someone else, I went Googling for prior art.  And wouldn’t you know it, the Wikipedia folks had worked it out around the end of last year.  This, of course, supports my contention that Wikipedia is the new Steve Allen.  I also found some claims that ending the font stack with monospace, monospace would have the same effect, but that wasn’t borne out in my testing.  Perhaps it worked in older versions of browsers but no longer does.

I did leave out another way to make monospaced fonts behave as expected, which you may have already figured out from the preceding: declare the font-size for any parent of a monospaced element to be a length value, along the lines of body {font-size: 12px;}.  That will pass the length value down the document tree to the monospaced element via inheritance, which will use it without resizing it in every browser I tested.  Though you may have heard that page zooming makes pixel-sized text okay, I’m not really convinced.  Not yet.  There are too many people who don’t know how to zoom, and too many whose browsers aren’t advanced enough to zoom pages.  Even in page-zooming browsers, there are problems with pixel text.  So I’m still on the ems-and-percentages bandwagon.

In fact, there are a fair number of details and extra browser oddities that I left out of this, as it’s already way more than long enough, and besides you don’t really want to hear the gory details of manually stepping through 37 different preferences settings just to verify a theory.  Plus you already heard about the font-size rounding investigation that spawned off of this one, about halfway through.  I think that’s more than enough for the time being.

I should also lay down a caveat: it’s possible that this behavior will be interpreted as a bug by the Safari team and “fixed”, if that’s the word I want, in a future release.  I really hope not — and if they’re looking for ways to improve how they handle monospace font sizing, I have a few suggestions — but it is possible.  Adjust your expectations accordingly.

And with that, I’m going to stop now.  I hope this will be useful to you, either now or in the future.

• Fixed Monospace Sizing was published on Friday, February 12th, 2010.
• It was assigned to the Browsers, CSS, Standards, and Web categories.
• There have been twenty-three replies.

In the course of digging into the guts of a much more complicated problem, I stumbled into an interesting philosophical question posed by web inspection tools.

Consider the following CSS and HTML:

p {font-size: 10px;}
b {font-size: 1.04em;}

<p>This is text <b>with some boldfacing</b>.</p>

Simple enough.  Now, what is the computed font-size for the b element?

There are two valid answers.  Most likely one of them is intuitively obvious to you, but take a moment to contemplate the rationale for the answer you didn’t pick.

Now, consider the ramifications of both choices on a situation where there are b elements nested ten layers deep.

If you hold that the answer is 10px, then the computed font-size of the tenth level of nesting should still be 10px, because at every level of nesting the mathematical answer will be rounded down to 10.  That is: for every b element, its computed font-size will be round(10*1.04), which will always yield 10.

If, on the other hand, you hold that the answer is 10.4px, then the computed font-size of the tenth level of nesting should be 14.802442849px.  That might get rounded to some smaller number of decimal places, but even so, the number should be pretty close to 14.8.

The simplest test, of course, is to set up a ten-level-deep nesting of b elements with the previously-shown CSS and find out what happens.  If the whole line of text is the same size, then browsers round their computed font-size values before passing them on.  If the text swells in size as the nesting gets deeper, then they don’t.

As it happens, in all the browsers I’ve tested, the text swells, so browsers are passing along fractional pixel values from level to level.  That’s not the interesting philosophical question.  Instead, it is this:  do web inspectors that show integer font-size values in their ‘computed style’ windows lie to us?

To see what I mean, load up the font size rounding test page in Firefox and use Firebug to inspect the “1(“, which is the first of the b elements, in the first (1.04em) test case.  Make sure you’re looking at the “Computed Styles” pane in Firebug, and you’ll get a computed font-size of 10.4px.  That makes sense: it’s 10 × 1.04.

Now try the inspecting that same “1(” in Safari or Opera.  Both browsers will tell you that the computed font-size of that b element is 10px.  But we already know that it’s actually 10.4px, because the more deeply-nested layers of b elements increase in size.  These inspectors are rounding off the internal number before showing it to us.  Arguably, they are lying to us.

But are they really?  The reason to doubt this conclusion is that the values shown in those inspectors accurately reflect the value being used to render the characters on-screen.  To see what I mean, look at the last example on the test page, where there’s sub-pixel size testing.  The “O” characters run from a flat 10 pixels to a flat 11 pixels in tenths (or less) of a pixel, all of their font-sizes assigned with inline style elements to pin the characters down as much as possible.  In Safari, you can see the size jump up one pixel right around the text’s midpoint, where I wrote font-size: 10.5px.  So everything from 10px to 10.49px gets drawn at 10 pixels tall; everything from 10.5px to 11px is 11 pixels tall.  Safari’s inspector reflects this accurately.  It’s telling you the size used to draw the text.

In Opera 10.10, you get the same thing except that the jump from 10 to 11 pixels happens on the very last “O”, both visually and in the inspector (Dragonfly).  That means that when it comes to font sizes, Opera always rounds down.  Everything from 10px to 10.9px — and, presumably, 10.99999px for as many nines as you’d care to add — will be drawn 10 pixels tall.  Brilliant.

In Firefox for OS X, there’s no size jump.  The “O” characters look like they form a smooth line of same-size text.  In fact, they’re all being drawn subtly differently, thanks to their subtly different font-size values.  If you use OS X’s Universal Access screen zooming to zoom way, way in, you can see the differences in pixel shading from one “O” to the next.  Even if you don’t, though, the fact that it’s hard to tell that there is an increase in size from one end of the line to the other is evidence enough.

In Firefox for XP, on the other hand, the size jump occurs just as it does in Safari, going from 10 pixels to 11 pixels of text size at the 10.5 mark.  But Firebug still reports the correct computed font-size values.  Thus, its reported value doesn’t match the size of the text that’s been output to the screen.  Arguably, it’s lying just as much as Safari and Opera,  in a different way.

But, again: is it really?  The computed values are being accurately reported.  That there is a small variance between that fractional number and the display of the text is arguably irrelevant, and can lead to its own confusion.  Situations will arise where apparent rounding errors have occurred — I see people complain about them from time to time — when the apparent error is really an artifact of how information is delivered.

I have my own thoughts about all this, but I’m much more interested in the thoughts of others.  What do you think?  Should web inspectors report the CSS computed values accurately, without regard to the actual rendering effects; or should the inspectors modify the reported values to more accurately reflect the visual rendering, thus obscuring the raw computed values?

Addendum 10 Feb 10: I’ve updated the test page with a JS link that will dynamically insert the results of getComputedStyle(el,null).getPropertyValue("font-size") into the test cases.  The results are completely consistent with what the inspectors report in each browser.  This tells us something about the inspectors that most of us probably don’t consciously realize: that what they show us rests directly on the same JS/DOM calls we could write ourselves.  In other words, inspectors are not privileged in what they can “see”; they have no special view into the browser’s guts.  Thus another way to look at this topic is that inspectors simply repeat the lies that browsers tell the world.

• Rounding Off was published on Wednesday, February 10th, 2010.
• It was assigned to the Browsers, CSS, and Web categories.
• There have been thirty-seven replies.

In the course of a recent debugging session, I discovered a limitation of web inspectors (Firebug, Dragonfly, Safari’s Web Inspector, et al.) that I hadn’t quite grasped before: they don’t show pseudo-elements and they’re not so great with pseudo-classes.  There’s one semi-exception to this rule, which is Internet Explorer 8’s built-in Developer Tool.  It shows pseudo-elements just fine.

Here’s an example of what I’m talking about:

p::after {content: " -\2761-"; font-size: smaller;}

Drop that style into any document that has paragraphs.  Load it up in your favorite development browser.  Now inspect a paragraph.  You will not see the generated content in the DOM view, and you won’t see the pseudo-element rule in the Styles tab (except in IE, where you get the latter, though not the former).

The problem isn’t that I used an escaped Unicode reference; take that out and you’ll still see the same results, as on the test page I threw together.  It isn’t the double-colon syntax, either, which all modern browsers handle just fine; and anyway, I can take it back to a single colon and still see the same results.  ::first-letter, ::first-line, ::before, and ::after are all basically invisible in most inspectors.

This can be a problem when developing, especially in cases such as having a forgotten, runaway generated-content clearfix making hash of the layout.  No matter how many times you inspect the elements that are behaving strangely, you aren’t going to see anything in the inspector that tells you why the weirdness is happening.

The same is largely true for dynamic pseudo-classes.  If you style all five link states, only two will show up in most inspectors—either :link or :visited, depending on whether you’ve visited the link’s target; and :focus.  (You can sometimes also get :hover in Dragonfly, though I’ve not been able to do so reliably.  IE8’s Developer Tool always shows a:link even when the link is visited, and doesn’t appear to show any other link states.  …yes, this is getting complicated.)

The more static pseudo-classes, like :first-child, do show up pretty well across the board (except in IE, which doesn’t support all the advanced static pseudo-classes; e.g., :last-child).

I can appreciate that inspectors face an interesting challenge here.  Pseudo-elements are just that, and aren’t part of the actual structure.  And yet Internet Explorer’s Developer Tool manages to find those rules and display them without any fuss, even if it doesn’t show generated content in its DOM view.  Some inspectors do better than others with dynamic pseudo-classes, but the fact remains that you basically can’t see some of them even though they will potentially apply to the inspected link at some point.

I’d be very interested to know what inspector teams encountered in trying to solve this problem, or if they’ve never tried.  I’d be especially interested to know why IE shows pseudo-elements when the others don’t—is it made simple by their rendering engine’s internals, or did someone on the Developer Tool team go to the extra effort of special-casing those rules?

For me, however, the overriding question is this: what will it take for the various inspectors to behave more like IE’s does, and show pseudo-element and pseudo-class rules that are associated with the element currently being inspected?  And as a bonus, to get them to show in the DOM view where the pseudo-elements actually live, so to speak?

(Addendum: when I talk about IE and the Developer Tool in this post, I mean the tool built into IE8.  I did not test the Developer Toolbar that was available for IE6 and IE7.  Thanks to Jeff L for pointing out the need to be clear about that.)

• Pseudo-Phantoms was published on Tuesday, November 3rd, 2009.
• It was assigned to the Browsers, CSS, DOM, Tools, and Web categories.
• There have been nineteen replies.

In creating the combo-bar charts for the survey report, I stumbled into an Explorer bug that I didn’t remember ever seeing before, and Google didn’t turn up anything that seemed to be related.  This could easily mean that I’m the only person who ever did something this insane and thus found the bug.  It could just as easily mean that my Google-fu has failed.  Either way, I’ll write it up here so it can enter the collective memory.  (And surely someone has already noted that Google is positively Jungian?)

You can see both the problem and two workarounds if you visit this test page using IE6 or IE7.  In brief, the problem occurred when I had a table cell containing a paragraph with an explicit width set.  I did this through the style attribute, though tests show that for this bug, it doesn’t matter whether you use the attribute or assign it via a style sheet.  Around these explicit-width paragraphs were div elements with width: 200%;, for bar-drawing purposes (it’s a little complicated).  Everything was fine in 99% of cases.  But as soon as the header text at the beginning of the row went to two lines of text, the explicit-width paragraphs doubled in width.  What was 80.1% wide would be drawn as though it were 160.2% wide.

My hopefully understandable reaction was to say, “Whuh?”.  I threw a few hasLayout triggers at the offending paragraph (relative position, zoom, etc.) and got nowhere.  In the end I worked around the problem by telling IE6 and IE7 to not wrap text in the row headers of combo charts.  (The bug is not present in IE8.)

I mentioned all this in my announcement post, and the ever-awesome Dan Wilkinson discovered that the problem could be fixed by setting all of the table rows to, say, height: 3em.  Armed with that breakthrough, I experimented a little more and found that I could actually set the offending table row’s height to 2.75em and still have things work as intended.  Below that and the paragraph widths doubled.

Then I lowered the line-height of the headers to 1 and found that I could take the overall row’s height as low as 2.33em before triggering the bug.  And that’s when it dawned: the bug was triggered by the layout height of the header cell’s content being taller than the content of the cell containing the paragraph, and not explicitly declaring styles that would make the data cell as tall as or taller than the height needed to have the header cell contain its content.

Okay, that’s a little dense.  Let me step through the symptoms and two found workarounds to see if that clears it up:

1. The data cell always has a single line of text.  The bug is triggered by having the header cell go to two lines of text, whereas it is not if the header cell has a single line of text.
2. If the row’s height is explicitly set to a value equal to or greater than the header cell’s content, the bug is not triggered.
3. Alternatively, if the height of the data cell is set or forced to be equal to or greater than the height of the header cell, the bug is not triggered.  This can be done with an explicit height or with added top and bottom padding or by adding top and bottom margins to the paragraphs in the cell.

Some side tests I did indicate that the header cell is not needed to trigger the bug.  In other words, the problem could happen even if there are only data cells in the row.  Furthermore, I found that the width-scaling was directly affected by the width of the wrapping div, and thus the widths were doubling only because I had the div‘s width set to 200%.  If I set it to 150% instead of 200%, then the paragraphs only got half again as wide instead of doubling.  That seems to make sense until you see it in action.  When I say the paragraphs got half again as wide, I mean that instead of being 75% as wide as the div, they were 112.5% as wide as the div.  If I set the div‘s width to 200%, then they were 150% the width of the div.

So.  As I say, this bug does not affect IE8, so that’s good, and it can be worked around in IE6 and IE7, which is even better.  The problem would be if you didn’t know how tall your cells might get—in my case, I can be (reasonably) sure that the tallest a cell’s content will ever get is two lines of text, and by setting an explicit line-height on the headers I can know how tall I have to make the rows in order to avoid the bug.

Another day, another workaround!

• Handling an Explicit-Width Bug in Internet Explorer was published on Saturday, April 11th, 2009.
• It was assigned to the Browsers and CSS categories.
• There have been nine replies.

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008′ series.)

My few thoughts on the “Graphical Effects” part of the feedback document.  A lot of what was mentioned by the community is already in the pipeline, so there’s not a lot to say about those except “hurry ’em up, willya?”.

Gradients — like rounded corners, no surprise these came up.  (All we need is to define wet-floor-reflect and we’ll complete the Web 2.0 design tricks hat trick.)  I’d like to see them myself, and I don’t think defining them is quite as hard as the commentary implies:

Imagine, for example, applying a gradient to the text of a <span> broken across two lines. Do you apply the gradient to each part individually? Glue them together as if they were all on one line first? Draw a rectangle around both parts and apply the gradient to that? (CSS3 Backgrounds and Borders has a control for this.)

I’d say the answer is right there, in the form of background-break, but let’s assume for a moment that said property never existed and we still had to deal with this problem.  I can think of two solutions:

1. Only allow gradients to be applied to non-inline boxes.  This would not be my preference, but it could be so defined.  There’s already precedence with CSS for that sort of limitation:  width, height, text-align, and other properties are restricted to non-inline boxes.
2. Treat gradients the way backgrounds and borders are already treated on inline boxes.  I’d be much more in favor of this.  In other words, lay out the inline box as though it is all on one line and then break it in pieces as needed to fit into the actual text flow.  (This is the behavior of continuous, the default value of background-break.)

But since background-break exists, you just treat gradients as you would any other background in accordance with background-break‘s definitions.

The somewhat trickier problem is how to define the value syntax for background-gradient so that’s both powerful and extensible without being unusable.  I think that’s solvable, but not easily, and probably not in a way that will satisfy everyone.

(Though this would be a fabulous place for the cardinal-point values from pre-CSS1 days, which you can still find in the specification if you look hard enough, to make a roaring comeback, wouldn’t it?)

Unidirectional background repeats — I say yes.  Here, have some values: repeat-up, repeat-right, repeat-down, and repeat-left.  In each case, the image would be repeated in the indicated direction from the origin image (the one placed by background-position).  Ironically, really old versions of IE did half of this by not correctly supporting repeat-x and repeat-y, treating them instead as if they were repeat-right and repeat-down.

There are occasions where this would be very useful, especially if you can combine the values into something like repeat-down repeat-right, and most especially in conjunction with multiple backgrounds.  So you could put an image stripe across the top of the element background, another one down the left side, and then fill in the rest of the background with a repeat-down repeat-right image.  Not a particularly common case, but the only way to handle it at present is with multiple nested elements, each with its own background and possibly a lot of negative margin trickery, and nobody wants that.  (Which may also be why it isn’t a particularly common case.)

You could also put an image in the center of your page and then a single stripe that goes only downward from behind it.  Like a golf ball on a tee, say; or a tree trunk below the leafy crowm; or a stem from a flower.

Slanted corners — sure, why not?  The issues are all the same as with rounded corners; the only difference is that you have a flat corner instead of a rounded one.  It makes joins between different borders styles/colors more obvious, but that’s a good thing: any solution that works well for the slant corner should work as well for the rounded corner.  Besides, if we’re already going to the effort of rounding corners, this seems like a pretty easy add-on.

Multiple borders — I think this would be quite useful.  I occasionally fake this with a border and an outline (as in my diagnostic styles) but that only works for two; if you want three or more nested borders (or two or more in IE/Win) you have to start nesting elements.  Also, having multiple borders lets you define your own gradient borders like you were a pixel artist, and who doesn’t like pixel artists?

At the same time, though, I do feel that this should be fairly low on the implementation totem pole.  And, as pointed out in the document, if image borders get implemented then a lot of the need for multiple borders goes away.

Alpha channel image masks — the problem I have here is what happens if you, say, try to use an image to alpha-mask a non-replaced element?  How does it scale?  Or does it?  Will there be a mask-stretch property?  Who really wants to stretch an image over a great big div anyway?  (From a visual-results point of view, I mean.)

Allowing masks might help in figuring out how to do non-rectangular float areas, in that you could use the alpha image to define the area used for float exclusion.  Combine that with a stretch ability and SVG support, so you can draw scalable vector masks, and I think you’re really getting somewhere.  (As does Matt Wilcox; he and I have been chewing this over in the comments on the previous post in the series.)

• CSS3 Feedback: Graphical Thoughts was published on Tuesday, February 24th, 2009.
• It was assigned to the Commentary, CSS, Standards, W3C, and Web categories.
• There have been twenty-seven replies.

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008’ series.)

The portion of the feedback devoted to shapes had two overarching themes, as I saw it.  That makes this entry a bit short, but when I tried to combine it with my feedback on “Graphical Effects“, it quickly got too long.  So, a little amuse cerveau, as it were.

Animations, transformations, and so on — the WebKit team have of course been having a field day in this area, and what they’ve done will likely make is way to other browsers.  Or not.  I don’t know.  I’m not entirely thrilled about the effort that’s gone into those properties when there are so many other, more basic things that need love and care, but there’s no denying the essential coolness of slowly rotating an entire page.  Which I totally need to do the next time I give a presentation.

I’m not going to get into the “these things are behavior and therefore JavaScript!” argument.  CSS already does behavior (think :hover) and it’s going to do more over time.  I don’t see how that historical pressure can be resisted for much longer, short of outright refusing to take on any more behaviors and thus making itself a prime candidate for replacement with something else.  We may as well do our best to make sure CSS does good behaviors well, in ways that makes the most sense to the most authors.

So that’s basically my feedback: since we’re going to do it, let’s do it right.  Apple’s made a start, and unless the syntax they’ve defined in their CSS Animations draft is completely unworkable in other browsers for technical reasons, then let’s just roll with it.  And please note I said the syntax, not the overall concept.  (Ditto for their CSS Transforms draft.)

Stuff that isn’t rectangular — including both polygonal element boxes and polygonal floats.  I’ve wanted these for at least a decade, so it’s little surprise that I’m in favor.  Ragged floats were invented as a hack to make the latter happen, of course, and the basic idea’s been improved upon more than once.

The tricky part, of course, is actually defining polygons.  Regular polygons, as in hexagons and octagons and dodecagons, are not terribly difficult; but creating an irregular polygon requires defining a set of point coordinates in relation to some origin and resolving what happens when the lines cross over each other and… well, yeah.

The build-on-what-exists approach would just adopt the syntax HTML area elements use in the coords elements.  There would be two interesting questions there, which are what happens with negative coordinate values, and what happens if you draw a polygon that cuts through some of the element’s content.  For example, you have a div containing an image, and you define the polygon to be smaller (in places) than the image.  Is the browser obligated to prevent content overlap in such cases?  I would tend to say no but I can see arguments for the opposite view, particularly when it comes to floats.

Then there’s the problem that you’d have to define a separate polygon for every element that needed a non-rectangular float, as Bert Bos notes in his thoughts on the topic from a couple of years ago.  His contour idea is certainly interesting, though I’d then start to wonder how you define a contour point on, say, an irregular faded gradient.

Anyway, I thought about adapting clip to the purpose of defining float polygons, but then I remembered the long, tortuous hell that is the history of clip (and offset-clip) and decided that a new property is the way to go.  Clean break, start fresh, et cetera.  I don’t know what it would be called.  content-shape, maybe, to go with element-shape.  Or not.

• CSS3 Feedback: Animated Shapes was published on Thursday, February 19th, 2009.
• It was assigned to the Commentary, CSS, Standards, W3C, and Web categories.
• There have been fourteen replies.

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008’ series.)

Not surprisingly, there was a lot of community feedback asking for better layout mechanisms.  Actually, people were asking for any decent layout mechanism at all, which CSS has historically lacked.  Floats mostly work, but they’re a hack and can be annoyingly fragile even when you ignore old-browser bugs.  Positioning works in limited cases, but does not handle web-oriented layout at all well.

Why do we use floats for layout, anyway?  clear.  That’s pretty much the whole answer.  The unique in-flow/out-of-flow nature of floats means they interact with each other and with the normal flow, which means they can be cleared, which makes them useful.  Because with clear, we can float layout blocks around and then push other non-floated blocks, like footers, below the floats.

Positioning, of course, permits total layout freedom in the sense that you can put a layout block anywhere with respect to its containing block.  The downfall is that absolutely positioned elements are entirely out of the normal flow, so they can’t stay out of each others’ way like floats do, and you can’t clear anything with respect to a positioned element.  If there had been a position-clear or its equivalent from the outset, we’d never have bothered with floats.

(And if we can just add position-clear to CSS, that would be completely awesome.  It’s been done with JavaScript and it will most likely be done again and better.  It wouldn’t even be that hard to implement, at least for 99.5% of cases.)

All this is why the old “only use tables for layout” argument keeps coming up over and over: strip away the overheated rhetoric and obvious link-baiting, and you find the core of a real need.  Because as powerful as CSS can be, table cells do certain things very easily that CSS makes very, very hard.  Cells stretch vertically, keeping equal heights as a matter of their intrinsic nature.  They stay out of each others’ way, while still being allowed to sit next to each other and use any sizing dimensions.  They tie their layout to their parent elements, and vice versa.

There are no equivalents in CSS.  There have been various very clever attempts to replicate bits and pieces of those capabilities using CSS.  What CSS does, it does very well: if you don’t need equal-height layout blocks, then no problem.  If you do, it’s a massive pain.  Clever techniques provide substitutes, but can’t replace what tables already do.

And please, let’s put the whole “display: table-cell will grant those abilities through CSS” to rest.  Saying that is just saying “use tables for layout” with different words.  Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it’s arguably worse.  Using element names other than table and td to create layout tables, and then claiming it’s not using tables for layout, borders on self-deception.

Not to mention doing things that way means you’re doing your layout in a highly source-order-dependent fashion, which was one of the things about table layout we were trying to get away from in the first place.

So how do we get really powerful source-order-independent layout?  I wish I knew.  The Advanced Layout module has been sitting around for a while now, and even if you’re a fan of defining layout as ASCII art—which I find repels and appeals in equal measure, but that’s probably just me—there appears to be close to zero implementor interest.  So how do we get those abilities in a form that implementors will, y’know, implement?  I don’t know.  I don’t care.  We just need it, and have needed it for a good decade or so.  Without it, CSS is a styling language but not a layout language.  We’ve bent it into being something close to a layout language, which is nice but not really ideal.

Maybe CSS isn’t the place for this.  Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility.  Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.

I don’t have a concrete idea to propose here, because it’s not up to us any more.  A solution was worked out over the course of several years and then found wanting by the implementors.  Really, it’s up to the implementors to figure it out now.  I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest.  I might even supply food and water.

And yes, I just advocated doing this outside the W3C process.  Why wouldn’t I?  The process has, in the last decade, not produced anything even remotely resembling an answer to this problem.  Time to try another path and see if it gets any closer to the goal.

No doubt someone’s going to spin this as “See, even noted standards zealot Eric Meyer now says CSS is flawed!”—only they’ll be wrong because this isn’t a now thing.  I’ve been saying this for years in interviews, in person, and in general.  Any time someone asks me what CSS is missing or should do better, the answer has always been a variant on “a strong layout system”.  I’ve been saying it for at least a decade.  So I’m not saying it now.  I’m saying it again.  And again and again and again and…

If I sound frustrated, it’s because I am, and have been for a good long while.  I’m not the only one.  It rankles to have CSS be, as Winston Churchill would have put it, the worst form of layout except for all the others that have been tried.

• Wanted: Layout System was published on Tuesday, February 17th, 2009.
• It was assigned to the Browsers, CSS, Rants, Standards, and W3C categories.
• There have been one hundred thirty-eight replies.