Now, please note that I’m not saying the DiggBar, or any other framing bar, is cool and we should all love it. I’m not. I absolutely, completely, totally get all the reasons why framing bars are bad for breaking bookmarking and navigating and search engines and copyright and hijacking content and so on. But that’s precisely why I’m so confused, because we’ve known for years now that framing bars are bad mojo—and yet StumbleUpon, for example, is based on bars. There is a browser extension/plugin StumbleUpon thingy you can install, but there’s also a web-based framing bar thing (see this link, for example) that they offer, and I bet people use. You don’t have to be a member to use it: I hit that link in a browser that allows cross-site frame loading and I get the bar and the page it’s framing, and I’ve never been a StumbleUpon member. The source shows it’s using iframes to make it happen. So far as I can tell, it’s not really different from the DiggBar.

So why do we have people writing JavaScript and PHP and Ged-knows-what-else that specifically busts out of the DiggBar framing, instead of busting out of all framing? After all, site framing is universally agreed to be objectionable; even yet-to-be-discovered life forms orbiting distant stars think it’s a bad idea. So why is one instance of it being targeted while the rest are tolerated? Why are we all not just using if (top != self) {top.location.replace(self.location.href);} and other-language equivalents? Yes, I know, some of you do just that, but why isn’t everyone?

Perhaps because I have yet to eradicate a stubborn streak of faith in the rationality of my peers, I assume that there’s some technical difference here that I’m missing and that, once understood, would let me understand the source of the outcry. So can someone please explain to me, or point at an explanation that states, the technical ways in which the DiggBar is worse enough than already-extant framing bars that it’s triggered this outrage? Again, nobody has to enumerate the complete list of the DiggBar’s sins; I understand. A list of any different and more egregious sins would be just fine, though.

Also, if anyone comes up with a way to bust out of the frames while still preserving the bar—that is, correcting the problems framing bars cause while preserving their functionality for the people who want to use them—that would be extra-cool. After all, people who use those services like the bars. If we could let them browse the web the way they prefer while fixing bookmark/SEO/etc. problems framing bars can cause, that would be a win all the way around.

Update 14 Apr 09: looks like Porter’s trying to keep the bar without the framing.

Update 16 Apr 09: in his post about Digg changing the way the DiggBar will work, John Gruber lists (by way of quoting Digg VP John Quinn’s post about it) the two things that made the DiggBar extra-objectionable (at least in his eyes). Thanks, John!

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!

There are a great many reasons why it took so long to get this out the door. A big part is that it’s almost entirely a volunteer effort, which means it happens in our “free time” (and there the word “free” has a couple of meanings). I say it’s almost entirely a volunteer effort because the detailed analysis is actually done by a pair of professional statisticians, who are paid for their time and expertise. They did a great job once more, and did it in a reasonable time frame. It just took us a while to get them the data to analyze, and then a while longer to take their report and findings and process them into report form.

The biggest change this year is that we’re publishing the results as HTML+CSS instead of a PDF. This greatly increased the challenge, because it was important to me that the data be presented using styled tables, not images. That’s easy like cake if all you’re doing is putting them up as visual tables, and we certainly do that for some of the figures. In the other cases, where we have bar charts of varying kinds, things got difficult. I managed to devise solutions that are 99.9% effective, and I’m both proud of and frustrated by those solutions. Proud, of course, because I managed to wring three-stack bars out of table markup; frustrated because of the markup I had to construct to make them possible. I think this report represents more than half my lifetime usage of the style attribute, but unfortunately there’s no way (using just CSS) to say {width: content;}.

So why not use JavaScript to do that, or to just replace the tables with canvas-drawn charts? I did consider both, but decided that I would push as far as I could with plain HTML+CSS.

A few implementation notes:

• I used HTML 5 in order to step around some previously unrealized limitations of HTML 4—did you know tfoot has to come before tbody in HTML 4? I didn’t. I did not use elements like header and footer due to known problems in Firefox 2 and related browsers, which mangle pages containing those elements. Instead, I took the same path Jon Tan recommends, and classed divs using those names for later, easier conversion.

• The tables which underlie the charts do not have summary attributes. If a group of civic-minded individuals would like to write useful summaries, please let me know in the comments and I’ll let you know how best to submit them. Similarly, I did my very best to make sure all the table headers had accurate scope values, but if I botched any, let me know.

• I’m aware that Opera shows horizontal scrollbars on most chapters of the report. This is due to its refusal to apply overflow to table boxes, which according to my recent reading of the CSS 2.1 specification is the correct thing to (not) do. Every other browser I tested does apply overflow to table boxes, though, which I found most useful. I tried applying overflow: hidden to a few other boxes, and that got rid of Opera’s horizontal scrollbars, but it also cut off actual content in some other browsers. I chose a cosmetic problem in one browser over loss of content in others. The best fix I’ve devised is to wrap the tables in divs and apply overflow: hidden to those divs, but I didn’t want to rush the fix and botch it, so it didn’t make it in time for first publication. I expect to get it in shortly after publication.

• In a like vein, there are a few combo charts where a bar goes shooting off the right side of the chart in IE7. This appears to be due to some kind of width-doubling problem that’s only invoked on elements with a style attribute when the row header goes to two lines instead of being just one. Googling for an explanation yielded no joy, and a lengthy series of attempts to hack around the problem came to nothing. If anyone knows how to counteract that problem other than preventing the header text from going past a single line, I’d love to hear it. (Update: I’ve implemented the “fix” of preventing line-wrapping in the report, so there aren’t any off-the-page bars right now, but you can see an example of the problem on this test page.)

• Surprisingly, the charts mostly work in IE6. The exception is some of the triple-stack charts, where data points overlap when the rightmost sub-bars get too small, and also the double-width bars mentioned in the previous point. I don’t really have a fix for this short of upgrading the browser, but if somebody finds one, I’d be happy to test it out.

On that last point, if there are questions or suggestions surrounding the implementation of the report, we can certainly discuss them here. With regard to the survey and report itself, though—that is, the questions asked and the results we’re publishing—please direct those thoughts to the comments section of the ALA article announcing the report. I’m hoping that we’ll have the 2009 survey up within a few months, so comments on what we asked and how we asked it, what we didn’t ask but should have, and that sort of thing could well have a direct impact on the next survey. But please put those on the ALA site, where more people are likely to see them.

It’s done, it’s out, it’s yours—both the report and the data, about which I’ll soon write a little bit more. Read the report, or produce your own report using the data. Just always know that when we publish these reports, we do not mean for them to be the final word. No, what we always mean is for them to be the first words, a starting point, a place from which to grow. What comes next is as much up to you as anyone else, and I can’t wait to see what you do.

What’s even worse is that the dialog requires mouse input to get past. It would be just within the limits of acceptability if the dialog buttons responded to keyboard input; if I could hit command-O or something to invoke “Open”, then I’d probably keep the safeguard in place, because I could just charge past it with a quick twitch of the fingers. Since I can’t, I want it gone. And of course there’s no “don’t ask me again” checkbox to tick.

After a plea on Twitter, I got pointers to a couple of ways to disable this annoyance (as well as a ton of “oh God, I hate that too; let me know if you find an answer!” replies). The first way is done as a Folder Action. For a variety of reasons, I’m not that thrilled by folder actions, so I gave it a pass. The other approach is to write your own preference file. Ah, much better! (Why is this better? I don’t know. It just intuitively feel like the better approach to me.)

Now, one way is to just disable the warning for all public.item files—which is to say, every type of file. I was tempted, but it turns out there’s a finer grain that can be applied: listing specific file types to be ignored. Better still! That way I can switch this off for the file types that I download all the time, like HTML files, and keep the safeguard in place for file types I almost never download, like executable scripts.

Doing this means you need a list of OS X’s Uniform Type Identifiers, so I dug around to find that listing, which appears to have moved in the not-too-distant past. Here’s the preference file I’ve put together with that listing as a guide. This file lists all of the file types I don’t want to be nagged about.

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
   "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>LSRiskCategoryNeutral</key>
    <dict>
      <key>LSRiskCategoryContentTypes</key>
      <array>
        <string>public.text</string>
        <string>public.plain-text</string>
        <string>public.xml</string>
        <string>public.archive</string>
        <string>public.image</string>
        <string>public.audiovisual-content</string>
        <string>public.font</string>
      </array>
    </dict>
  </dict>
</plist>

I led with public.text because it encompasses not just regular text files, but HTML files as well; public.xml appears to cover XHTML, though I’m not 100% sure where those files fall. public.audiovisual-content covers all audio and video files, as you might guess. There are probably a few other types I’ll add over time, as I encounter enough resistance on certain types of files that I don’t need to be safeguarded. I’ll probably never add public.script or public.executable to the list; personally, I prefer to be warned about that sort of stuff.

To make the magic happen, save the above file (or your own variation) as ~/Library/Preferences/com.apple.DownloadAssessment.plist. Then log out of and back into your account. Finito.

So if you’d like to get your Mac to be less of a nag about opening downloaded files, there’s how. As the links above show, I’m standing on the shoulders of giants here, so my thanks to those who paved the way. I hope that you will be able to benefit from both their work and my small additions thereto.

Update [13 Mar 09]: Potentially very bad news, folks. I just tried this on my 10.5.6 machine and it failed utterly. As did the Folder Action approach. Older versions of Leopard apparently didn’t have this problem. Anyone else seeing the same kind of thing on their machines? If either way is still working for you under 10.5.6, can you tell us which one it is in the comments? Thanks.

Update [18 Mar 09]: Great news, folks. Ben Millett kindly sent me a copy of his working-under-10.5.6 file and I tried it out, and it worked! The difference seems to be that the version I was using was encoded as “Unicode™ (UTF-8, no BOM)” whereas the encoding of the file Ben sent me is “Western (Mac OS Roman)” (both according to BBEdit). So if your copy doesn’t work, check the file encoding. Next I’m going to experiment with adding file extensions, and will report back if I meet with success.

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

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.

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.

In this round, layout. Not all of it, but the bits that struck me as either really useful or really, really way too long overdue.

Float containment – yes, we need a property that does just that. As long as we’re tied to floats for layout—and I plan to rant about that soon—there should be a clear, unambiguous, intentionally defined property that tells elements to wrap themselves around floated descendant elements. overflow works in most cases but can fall down in unusual circumstances (I’ve seen scrollbars appear where none were actually needed) and anyway, it wasn’t intended to provide the wrapping effect in the first place. That it does so is a happy side effect, but it’s still a side effect. The rest of the float-wrapping techniques are even more convoluted. “There are already ways to do that so we don’t need a property” is rather like saying “we can already do layout with tables so why do we need CSS layout?”.

Positioning by center – yes, please. The way to center an absolutely positioned element within its containing block is to set the top and left to 50% each and then define negative top and left margins that are half the positioned element’s height and width. That’s just awful, and requires at least an explicit width, if not an explicit height. When I did the structured timeline, here’s how I got the version numbers to center below the dots:

#timeline tbody td p {
	position: absolute;
	top: 50%;
	width: 2.1em;
	margin: -5px 0 0 -1em;
}

See that -1em left margin, and the 2.1em width? Just to get the center of positioned elements’ boxes sit on top of a certain left offset (defined elsewhere in the CSS). Ditto the negative top margin, to pull it upward just enough so that the elements’ boxes would have the point five pixels down from their tops line up with the vertical midpoint of their containing blocks.

I wanted to do something like this:

#timeline tbody td p {
	position: absolute;
	top: 50%;
	position-anchor: 50% 5px;
}

That would have said that the point in the center of the absolutely positioned element should be placed at the point in the containing block 21.7% down from the top and 44% of the way across from the left. That would hang the positioned element’s center on that point, regardless of the size of the positioned element—note that I took out the width. I could stop defining explicit sizes and just let the elements be the size they want to be to show their content.

The problem is that approach doesn’t fit at all well with the way positioning layout is defined. Suppose I said this:

#timeline tbody td p {
	position: absolute;
	top: 50%; bottom: 0;
	left: 50%; right: 25%;
	position-anchor: 50% 5px;
}

Now what? I’m not even sure myself. Maybe define rename it to position-offset and define percentages to be relative to the height and width of the positioned element (not its containing block), so that it doesn’t interact directly with the offset properties like top and right?

All I want is a way to hang elements off of offset points, and not be restricted to the corners of the elements, and have the solution work even when the elements have automatic height and width, and not require extra markup to make it happen. Oh, and a ponycar.

Box sizing – what in the nine hells of Valeria is taking so long? We needed that one ten years ago. I no longer care if it’s done as its own property or as new keywords on height and width. I just want it. Someone will make it happen, with or without the WG or implementors—mark my words.

Same-height elements – yes, a way to tie element heights (whether they’re siblings or not) together would be welcome, although I can see how specifying it in an implementable would be tricky; no, display: table-cell is not the answer. Soon I will rant about this. Soon.

Out of all the selector feedback, selector blocks was the part that really caught my attention. I also see the usefulness of a parent selector, but that one has come up many times before, and it’s always died at the doorstep of implementors, who point out that it’s far too difficult to implement without serious performance penalties and even risk of browser lockup. See, for example, the comment left by David Hyatt on Shaun Inman’s post on the idea. Similarly, I think constants (or macros or whatever they’re called) are a great idea and would be very helpful, especially if you’re coding up a Jason Special. Both are loaded with use cases, so I don’t feel like I can add a lot; besides, constants are already in the WG charter, so there’s once more hope in the land.

So anyway, selector blocks. To pick one recent example, while working on a project that should very soon see the light of day, I had a situation involving the following chunk of rules.

h1, h2, h3, h4, h5, h6, table {
   font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
h1 {font-size: 275%;}
h3:first-child {margin-top: 1em;}
p.tagline {margin: -0.25em 0 1.25em;
   font-size: 125%;
   color: #7B7960;}
h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
h3:before {font-size: 75%; counter-increment: subhead;}
h4 {margin: 2.5em 0 0.75em;
   text-transform: uppercase; font-size: 125%;
   color: #928F59;}
p {margin: 0 0 1em;}
ul {padding-left: 1.5em;}
ul li {list-style: disc; margin: 0.5em 0;}

Nothing unusual about them, of course, unless you count my use of counters. These rules had been written early on in development, and the design had evolved around that part of the document. As more page components were added, I realized that I needed to scope all these rules to one section of the document: specifically, a div with a class of main. So here’s what I had to do.

.main h1, .main h2, .main h3, .main h4, 
.main h5, .main h6, .main table {
   font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
.main h1 {font-size: 275%;}
.main h3:first-child {margin-top: 1em;}
.main p.tagline {margin: -0.25em 0 1.25em;
   font-size: 125%;
   color: #7B7960;}
.main h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
.main h3:before {font-size: 75%; counter-increment: subhead;}
.main h4 {margin: 2.5em 0 0.75em;
   text-transform: uppercase; font-size: 125%;
   color: #928F59;}
.main p {margin: 0 0 1em;}
.main ul {padding-left: 1.5em;}
.main ul li {list-style: disc; margin: 0.5em 0;}

This, on the other hand, is what I really wanted to do:

.main {
   h1, h2, h3, h4, h5, h6, table {
      font: 1em Arial, "Helvetica Neue", Helvetica, sans-serif;}
   h1 {font-size: 275%;}
   h3:first-child {margin-top: 1em;}
   p.tagline {margin: -0.25em 0 1.25em;
      font-size: 125%;
      color: #7B7960;}
   h3 {margin: 1.5em 0 0.25em; font-size: 125%;}
   h3:before {font-size: 75%; counter-increment: subhead;}
   h4 {margin: 2.5em 0 0.75em;
      text-transform: uppercase; font-size: 125%;
      color: #928F59;}
   p {margin: 1em 0;}
   ul {padding-left: 1.5em;}
   ul li {list-style: disc; margin: 0.5em 0;}
}

Or, if necessary, to put the whole original chunk into its own style sheet and then do one of the following:

div.main {@import url(main-style.css);}

<div class="main" style="@import url(main-style.css);">

Interestingly, the latter is theoretically possible, thanks to the more advanced profiles in the CSS module “Syntax of CSS rules in HTML’s ’style’ attribute“. I’m not aware of the former having been seriously considered (despite my best efforts, once upon a time), though it’s always possible I missed something.

But either one of those approaches would be a last resort, in my opinion. I’d much rather just wrap the whole chunk in .main { }, like I showed previously, and be done with it. That capability would also simplify certain annoyingly repetitive patterns, like the very first of those rules. I think it’s pretty obvious which of the following is easier to write and maintain:

body.home #content .entry h2, 
body.home #content .entry h3, 
body.home #content .entry h4, 
body.home #content .entry h5, 
body.home #content .entry h6 {...}

body.home #content .entry {
   h2, h3, h4, h5, h6 {...}
}

I mean, just look at the former, and imagine what one goes through to write it in the first place. Copy, paste, paste, paste, paste, paste… maddening. And that’s just for a small block of CSS like this one. Imagine the tedium of doing this for a block of 50 rules, or 150. (Also, this is the the same thing that was requested in the feedback as “Grouped Alternates“, albeit with a different syntax.)

One objection to this sort of pattern is that it increases dependence on descendant selectors, which are computationally inefficient. But it doesn’t: I had to create a whole bunch of descendant selectors as it was, and did so far more clumsily. And had I missed a command-V somewhere, I’d have had styles that applied outside their intended subtree. Introducing a way to nest blocks like this doesn’t change anything except make it easier and more maintainable to do what we already do. Honestly, it’s pretty much impossible to increase dependence on descendant selectors. The best we can do now is make them less difficult to write.

I realize that the syntax I depict would cause backwards-compatibility problems, as in older browsers would not behave as intended when exposed to this sort of thing, but I’ve also stopped being concerned about that. We can’t keep holding ourselves hostage to decisions made a decade or more back. Provide the capability and authors will use it when they can. Over time, its use will become more prevalent—kind of the same way authors adopted CSS in the first place.

I also realize that this case has been made time and again by many, many other people. This isn’t even the first time I’ve made this case, though I think the other times were within the WG and therefore off the public record. The fact that it keeps being made is a strong indicator that the need exists, and dismissing the idea because the same end effect can be achieved with existing selector syntax (as shown above) isn’t acceptable. That’s like saying that complex selection effects can be achieved with JavaScript or XPath, so there’s no need for advanced CSS selectors.

So that’s my use case. I actually have a bunch more, but they all follow the same basic pattern: the desire to group rules together into subsections of a document, or to otherwise simplify the writing of CSS.

Here you go:

1. Selector blocks
2. Layout
3. Wanted: Layout System
4. Animated Shapes
5. Graphical Thoughts

I want to make clear up front that I’m not going to address every single point in the feedback document: it’s just too incredibly huge. I did think about making my own copy and then just filling in my reactions to each point, but that didn’t scale very well. Not only did it seem really overbearing and maybe just a touch egotistical, but some of my reactions were based on related topics in separate areas of the original. Besides, I know what it’s like trying to read a really, really long article, so breaking it up and just focusing on the parts that got me fired up made way more sense.

There is one thing I want to address before I start serving up the follow-on installments. At the end of Fantasai’s post, there’s a link to my 2006 post about the benefit of having a community liaison, someone who bridges the gap between the WG and the public. She then asks if anyone is interested in volunteering, but personally, I don’t see the need. The WG already has a community liaison: it’s you, Fantasai. It has been for some time now, thanks to your regular and informative CSS WG blog posts and other outreach work such as “WaSP Community CSS3 Feedback 2008″. The job is being done, and being done very well, I don’t think there’s any doubt that the Working Group is much, much better for it.

You can get the details at the CW site, and note the special price for the first quarter of the seats. That’s right, this will be a small, intimate workshop, with plenty of chances for questions about and challenges to what I’m saying. Previous workshops have featured some really great conversations among everyone there, and I expect the same this time around.

I had meant to blog this before life intervened and took me out of my wifi cloud (and more on that soon), so time is a little more of the essence than usual—if you know someone who you think might be interested, pass the word on, willya? Thanks!

1. Makes local changes to your style sheet(s).
2. Upload the changes to the staging server.
3. Switch to your browser and hit “reload”.
4. Nothing happens.
5. Force-reload. Nothing happens.
6. Go back to make sure the upload is finished and successful.
7. Reload again. Still nothing.
8. Try sprinkling in !important. Upload, reload, nothing.
9. Start swearing at your computer.
10. Check Firebug to see what’s overriding your new styles. Discover they aren’t being applied at all.
11. Continue in that vein for several minutes before realizing you were hitting reload while looking at the live production server, not the staging server.
12. Go to the staging server and see all your changes.
13. Start swearing at your own idiocy.

This happened to me all the time as we neared completion of the redesign of An Event Apart. It got to the point that I would deliberately add obvious, easily-fixable-later errors to the staging server’s styles, like a light red page background.

Now that we’re launched and I have time to actually, you know, think about how I do this stuff, it occurred to me that what I should have done is create a distinct “staging” style sheet with the obvious error or other visual cue. Maybe repeat the word “staging” along the right side of the page with a background image, like a watermark:

html {background: url(staging-bg.png) 100% 50% repeat-y;}

Okay, cool. Then I just need to have that served up with every page on the staging server, without it showing up on the production server.

One way to do that is just make sure the image file never migrates to production. That way, even if I accidentally let the above CSS get onto production, the user will never see it. But that’s inelegant and wasteful, and fragile to boot: if the styles accidentally migrate, who’s to say the image won’t as well? And while I’m sure there are all kinds of CMS and CVS and Git and what-have-you tricks to make sure that doesn’t happen, I am both clumsy and lazy. Not only do I have great faith in my ability to screw up my use of such mechanisms, I don’t really want to be bothered to learn them in the first place.

So: why not send the link to the style sheet using HTTP headers? Yeah, that’s the ticket! I can just add a line to my .htaccess file on the staging server and be done. Under Apache, which is what I use:

Header add Link "</staging.css>;rel=stylesheet;type=text/css;media=all"

Those angle brackets are, so far as I can tell, absolutely mandatory, so bear that in mind. And of course the path in those brackets can be absolute, unlike what I’ve shown here. I’m sure there are simple PHP equivalents, which I’ll leave to others to work out. I really didn’t need to add the media=all part, but what the heck.

Seems so simple, doesn’t it? Almost… too simple. Like there has to be a catch somewhere. Well, there is. The catch is that this is not supported by all user agents. Internet Explorer, for one; Safari, for another. It does work in Opera and Gecko browsers. So you can’t deploy this on your production server, unless of course you want to use it as a way to hide CSS from both IE and Safari. (For whatever reason.) It works great in Gecko-based production environments like mine, though.

I looked around for a quick how-to on do this, and couldn’t find one. Instead, I found Anne van Kesteren’s test page, whose headers I sniffed in order to work out the proper value syntax; and a brief page on the Link header that didn’t mention CSS at all. Nothing seemed to put the two of them together. Nothing until now, that is.

Consider the following structure, which is a much-edited-down version of part of the HYDEsim code:

function Detonation(name,lat,lon,yield) {
    var scale = Math.pow(yield,1/3);
    var gz = new GLatLng(lat,lon);
    this.name = name;
    this.lon = lon;
    this.lat = lat;
    this.gz = gz;
    this.yield = yield;
    this.overpressure = {
        p30 : 0.108 * scale,
        p15 : 0.153 * scale,
        p10 : 0.185 * scale,
         p5 : 0.281 * scale,
         p1 : 0.725 * scale
    };
    this.psi30 = {
        radius: 0.108 * scale,
        overlay : {
            points: makePoints(this.gz,0.108 * scale)
        }
    };
    this.psi15 = {
        radius: 0.153 * scale,
        overlay : {
            points: makePoints(this.gz, 0.153 * scale)
        }
    };
    this.therm20 = {
        radius: thermDist(20,this.yield,0.33,conditions.visibility),
        overlay : {
            points: makePoints(
                this.gz,
                thermDist(20,this.yield,0.33,conditions.visibility)
            )
    };
    // ...and so on...
}

There are two things I’ve tried and failed to do. And tried, and tried, and tried; and failed, and failed, and failed.

1. Eliminate the redundant calculations of radii. Note how I define a radius property in each case? And then have to not use it when I create the overlay? It seems like there must be a way to just define the value once for each subsection and then use it as many times as needed within that context. How?
2. How do I make it so that all those properties and overlays and such automatically recalculate any time one of the “upper-level” terms changes? As in, once I’ve created a new Detonation object det, how can I set things up so declaring det.yield = 250; will trigger recalculation of all the other pieces of the object? At present, I’m just blowing away the existing det and creating a whole new one, which just seems clumsy and silly. I have to believe there’s a better way. I just can’t find it.

Please note: tossing off comments like “oh, just instantiate a mixin constructor with an extra closure” will be of no help at all, because I don’t understand what those terms mean. Hell, I’m not even sure I used the words “object” and “property” correctly in my explanation above. Similarly, pointing me to tutorials that use those terms liberally is unlikely to be of help, since the text will just confuse me. Sample code (whether posted or in a tutorial) will help a great deal, because it will give me something to poke and prod and dissect. That’s how I’ve always learned to program. Actually, it’s how I’ve always learned anything.

As well, I’m absolutely willing to believe that there are much, much better ways to structure the object, but right now I really need to learn how those two things are accomplished in the context of what I already have. Once I get familiar with those and finish up some other work, I can start thinking about more fundamental overhauls of the code (which needs it, but not now).

I really appreciate any concrete help you can give me.

Addendum: if you leave code in a comment, please just wrap it in a code element and use whatever indentation you like. The indentation won’t show up when the post goes up, but I’ll go in after and wrap the code in a pre and then everything will be fine. Sorry to those who’ve already gone to the effort of posting with indents or nbsp entities to try to preserve indentation! As soon as I can dig up the right preference panel or plugin to allow pre in comments, I’ll do that, but for now I’ll manually edit in the needed pres as comments are added. THanks, and again, apologies to those who posted before I made this clear!

Here’s the original equation:

Q = (3.07 × F × Y × (1 + 1.4 × ((D/V) × e^{(-2 × D/V)}))) / D²

I want to be able to solve for D, not Q; in other words, have a single D on the left and everything else on the right of the equation. F, Y, and V are all variable terms; the e is the classic irrational constant. I tried for quite a while to do this and ran very firmly aground. The best I managed was this minor simplification:

Q = (3.07 × F × Y × (1 + 1.4 × (D / (V × e^{(2 × D/V)}))) / D²

…and even that assumes that I did things correctly. Here’s the original equation in pretty shoulda-done-it-in-MathML-but-oh-well form:

I can shuffle the chairs around, as it were, but never really get anywhere close to having a single D on the left. “But it’s so easy!“, you may well be shouting. That’s why you’re working for Google and I’m not.

I remember having questions just like this on tests back in college: “Given this equation, solve for blah”. It’s been too long, though, and in all honesty I was never that great at this sort of thing in the first place. Help, please?

[Update 14 Jan 09]: several commenters have shown that what I’m trying to do is impossible. Frustrating, but that’s math for you. Looks like I’ll have to take another approach.

One of the things I’ll be talking about is the choice of markup language for the site, which ended up being HTML 5. In the beginning, I chose HTML 5 because I wanted to do something like this:

<li>
<a href="/2009/seattle/">
<h2><img src="/i/09/city-seattle.jpg" alt="Seattle" /></h2>
<h3>May 4—5, 2009</h3>
<p>Bell Harbor International Conference Center</p>
</a>
</li>

Yes, that’s legal in HTML 5, thanks to the work done by Bruce Lawson in response to my href-anywhere agitation. It isn’t what I’d consider ideal, structurally, but it’s close. It sure beats having to make the content of every element its own hyperlink, each one pointing at the exact same destination:

<li>
<h2><a href="/2009/seattle/"><img src="/i/09/city-seattle.jpg" alt="Seattle" /></a></h2>
<h3><a href="/2009/seattle/">May 4—5, 2009</a></h3>
<p><a href="/2009/seattle/">Bell Harbor International Conference Center</a></p>
</li>

I mean, that’s just dumb. Ideally, I could drop an href on the li instead of having to wrap an a element around the content, but baby steps. Baby steps.

So as Bruce discovered, pretty much all browsers will already let you wrap a elements around other stuff, so it got added to HTML 5. And when I tried it, it worked, clickably speaking. That is, all the elements I wrapped became part of one big hyperlink, which is what I wanted.

What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link. Sometimes everything would lay out properly, and other times the bits and pieces were all over the place. I could (randomly) flip back and forth between the two just by repeatedly hitting reload. I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs. Nope, same problems. So I converted them all to classed spans and that solved the problem. The layout became steady and stable.

I was happy to get the layout problems sorted out, obviously. Only, at that point, I wasn’t doing anything that required HTML 5. Wrapping classed spans in links in the place of other, more semantic elements? Yeah, that’s original. It’s just as original as the coding pattern of “slowly leaching away the document’s semantics in order to make it, at long last and after much swearing, consistently render as intended”. I’m sure one or two of you know what that’s like.

As a result, I could have gone back to XHTML 1.1 or even HTML 4.01 without incident. In fact, I almost did, but in the end I decided to stick with HTML 5. There were two main reasons.

1. First, AEA is all about the current state and near future of web design and development. HTML 5 is already here and in use, and its use will grow over time. We try to have the site embody the conference itself as much as possible, so using HTML 5 made some sense.

2. I wanted to try HTML 5 out for myself under field conditions, to get a sense of how similar or dissimilar it is to what’s gone before. Turns out the answers are “very much so” to the former and “frustratingly so” to the latter, assuming you’re familiar with XHTML. The major rules are pretty much all the same: mind your trailing slashes on empty elements, that kind of thing. But you know what the funniest thing about HTML 5 is? It’s the little differences. Like not permitting a value attribute on an image submit. That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5. (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.)

   Oh, and we’re back to being case-insensitive. <P Class="note"> is just as valid as <p class="note">. Having already fought the Casing Wars once, this got a fractional shrug from me, but some people will probably be all excited that they can uppercase their element names again. I know I would’ve been, oh, six or seven years ago.

   Incidentally, I used validator.nu to check my work. It seemed the most up to date, but there’s no guarantee it’s perfectly accurate. Ged knows every other validator I’ve ever used has eventually been shown to be inaccurate in one or more ways.

I get the distinct impression that use of HTML 5 is going to cause equal parts of comfort (for the familiar parts) and eye-watering rage (for the apparently idiotic differences). Thus it would seem the HTML 5 Working Group is succeeding quite nicely at capturing the current state of browser behavior. Yay, I guess?

And then there was the part where I got really grumpy about not being able to nest a hyperlink element inside another hyperlink element… but that, like so many things referenced in this post, is a story for another day.