meyerweb.com

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

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

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

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

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.

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

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.

Back before holiday season hit, Elika Etemad—better known as Fantasai—published WaSP Community CSS3 Feedback 2008. I gave it a read and came away with a number of things I wanted to say. So many things, in fact, that I’ll need to split them up into a series of posts. This here post will serve as introduction and hub, with links to the follow-on entries added as they’re published. All very Bray-ny, no? (Go ahead, groan. It only encourages me.)

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.

So recently, I shared a number of ideas for improving the W3C, the last of which (posted a week ago) was to transition from a member-funded organization to a fully independent foundation of sorts, one that was funded by the interest earned by an endowment fund. Surprisingly, there seemed to be little objection to the idea. That was the one thing that I figured would get some pushback, mainly due to the magnitude of the change involved. I’m still interested in hearing any counter-arguments to that one, if somebody’s got ‘em (thought they’d be best registered on that particular post, and not here).

The other thing I was expecting to see, but didn’t, was other people’s ideas for improvements to the W3C. That was probably my fault, given the way I wrote the posts, which now that I look at them were set up more as soliloquies than the beginnings of a discussion. While I think my ideas are good ones (of course!), I’m only one person, and I very much doubt I’ve thought of everything.

So what are your thoughts for improving the W3C’s effectiveness and standing in the field?

Apologies for the break in posting just as I was getting to the best part of the W3C Change series, but back-to-back trips to Seattle and Dallas came up before I could finish writing up my thoughts. This one was, for all the simplicity of the content, the hardest one to write, because I kept revising it to try to be more clear about what I’m proposing and how it would be an improvement. I could keep revising ’til the end of forever, so I’m just going to take what I have now and go with it.

My third recommendation is simply this: Transform the W3C from a member-funded organization to a financially independent entity.

In order to accomplish this, the W3C would need to embark on a major capital campaign, similar to the efforts mounted by major non-profit organizations and American private universities. The campaign parameters that come to mind are a ten-year campaign whose goal is to build an endowment of $200 million. From the interest on this endowment—which at a relatively modest 5% return would be $10 million annually—the W3C could fund its activities.

(Note: I do not have access to the budget of the W3C, but with approximately 70 staff members at an average total cost of $125,000 per year in salary, benefits, and travel expenses, the staffing cost would be $8.75 million. If I am lowballing the budget, then obviously the capital campaign’s goal would have to be raised. The general approach remains the same.)

As the campaign progressed, the membership dues would be reduced across the board in proportion to the progress of the campaign. Once the campaign reached its end and the full endowment had been acquired, the dues would fall to zero and the membership model would be dismantled.

You might wonder where the blinking font the W3C could get that kind of money, even over the course of a decade. Well, 20 Internet billionaires could each donate $10 million in thanks for the W3C making their fortunes possible, and there you go. Even if that doesn’t happen, there are many foundations whose goal is to foster better technology and communications, and who might be persuaded to contribute. Government grants could help. And, of course, a supporter campaign like that run by the EFF would allow individual developers to add their support.

Frankly, I don’t think the problem would be finding the money, especially over a ten-year period. By hiring an experienced fund-raiser, I think the funds could be raised a good deal more quickly. I think this would be especially true if Sir Tim publicly put his weight behind the effort, and made personal appeals to potential major donors.

But why would I even suggest such a thing?

1. The current membership model creates an apparent wall between the W3C and the rest of us. Because it costs a minimum of $15,000 over three years to become a W3C Member, individuals will rarely, if ever, be able to justify membership. The same is true of web design and development shops.

   For primarily this reason, there is the belief that non-paying members of the community cannot join Working Groups, and that the WGs are forever closed to the rest of the world. This is not really true, since any Working Group can ask people in the community to become Invited Experts. These are Working Group members who don’t have to pay to get in, and aren’t necessarily held to the same contribution standards as Member representatives. (Not that contribution standards are always upheld for them either, as I observed in an earlier post.)

   So now imagine a W3C where there are no Members. That means that every Working Group is comprised entirely of Invited Experts (except for any W3C staff members who might join). This bridges the perceived gap, and puts community members on a more equal footing with those who would currently be Member representatives. I’m not saying there wouldn’t be company representatives at all. The CSS WG is going to have representatives from Microsoft, Mozilla, Apple, and so on. The alternative is for them to not participate, and thus be at the mercy of what happens in their absence.

   Since someone’s going to bring it up, I’ll address the Microsoft question. You might think that Microsoft could decide to both abandon, say, the CSS WG and ignore what it produces. (Anyone could do this, but Microsoft is going to be the company accused of hypothetically plotting such a thing.) That could well be. But wouldn’t Microsoft departing the CSS WG be a large red flag that something’s seriously wrong, and that it needs to be addressed before worrying about exactly how the layout module is written?

   Of course, some other player could do this as easily as Microsoft. The point is really that, if a major player in the space with which the WG is concerned departs that WG, then it identifies a situation that needs to be addressed. The Member model actually goes some small way toward concealing that, because the dues paid create a certain impetus to put someone on a WG, even if there’s no serious interest.

   The flip side of this is the question, which I’ve heard more than once from people when I talk about this idea, “How would a WG force the players to the table?” For example, how could a new browser-technology WG force the browser makers to join the group?

   The question itself betrays a fallacious assumption: that players should be forced to work together. If you propose to form a WG that doesn’t interest one or more of the major players in the field, then the WG may well be flawed from the start. The point of a WG is to produce an interoperable standard. If a WG just goes off and does something without buy-in from players, and there’s never an implementation, then the whole effort was wasted. On the other hand, a specification that was produced with the involvement of all the major players stands a much better chance of being implemented, and thus a much better chance of being used and appreciated by the community.

   The flip side of that flip side is the question, “What if a WG refuses to admit a player in the field?” In other words, what if the CSS WG barred Microsoft from having a representative on the WG? Again, that would be an enormous red flag that something had gone awry. Any WG that refused to involve an important player in their field would need to be scrutinized, and probably reformatted.

   All this does raise the spectre of replacing a centralized model with a consensus model. Which is just fine with me, for all the reasons I just mentioned.

2. There is the perception—largely untrue, but no less persistent—that the W3C is controlled by those who fund it.

   It’s actually been my experience that there’s an inverse correlation between the amount of money a company puts into the W3C and the frequency with which their representatives get their way. During my time in the CSS WG, the Microsoft people faced more resistance and more grief from the rest of the WG than the Netscape reps ever dreamed of getting. CSS-like things which IE/Win had done faced a serious uphill battle to be incorporated in the specification, even when they were good ideas. I don’t know how to explain this odd variance from the usual effect of money, but it was there. Maybe in other WGs, the situation is different, although I kind of doubt it.

   But as I say, the perception is persistent. A financially independent W3C would remove that perception. I wouldn’t propose this kind of funding-model change solely to clear up some erroneous perceptions, but it’s an undeniably positive side effect.

3. Full financial independence allows the W3C to do things that its dues-paying Members likely wouldn’t permit.

   Now what could I be talking about, since I just claimed that dues money doesn’t drive what the W3C does, except in inverse ways? What I’m talking about is things like launching a program to pay Invited Experts a small stipend. Currently, Invited Experts receive no financial support, whereas Member representatives are supported by their employers while devoting some of their time to the W3C. I tried to imagine a world where the dues-paying Members of the W3C approved the idea of paying Experts, and although I managed to do so, it turned out to be entirely populated by talking kawaii unicorns who get joyfully teary about their perpetually rainbow-filled skies and giggle a lot.

   Here’s another W3C effort which probably could never get funded under the current model: a university scholarship for students who plan to study the web, or uses of the web. They might fund independent research on the effects of the web in developing countries, or what users want, or any number of other things. Or hey, how about putting enough money into the WWW conference series that people who present papers are given a complimentary registration? (I know—radical!)

   These things couldn’t happen if the W3C’s endowment generated only enough interest to cover staffing and overhead, but the endowment doesn’t have to be limited to just that much. A second capital campaign, or a simple continuation of the first one, could increase the endowment, thus giving the W3C (potentially) quite a bit of discretionary funding. It would give them the opportunity to spend money on efforts that advance their core mission (“To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web”).

There are various knock-on effects that arise from those points, of course, but I’ve gone on long enough.

As many of you have noticed, I’m effectively proposing that the W3C become a foundation instead of a consortium, albeit a foundation whose primary mission is to act as a consortium would. I’ve avoided using terms like “non-profit” and “not-for-profit” because they might imply specific things which I don’t fully intend in terms of tax law, or whatever, but I do think of it as a generically non-profit institution; that is, one that does not strive to create a profit, except as can be invested into the endowment.

I’ve tried to explain why I believe this is a good idea, but in the end, I think the most fundamental reason is that one I can’t explain: it just feels like the right thing to do. It’s like I can perceive a shape without grasping all its details, but the overall shape looks right, looks better.

I fully expect that some will recoil from this idea, convinced that a foundation is a poor substitute for a consortium. Obviously, I disagree. I think the W3C’s future could be made much more stable with this approach, especially in financial terms. I also believe, as I said before, that it would be no less of a force for the advancement of the web. In fact, I think it would be a much stronger force, and have a greater positive effect, over the long term.

It is not a small undertaking, but it is an important and worthwhile effort, and I hope it is one the W3C considers seriously.