Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'Standards' Category

The Web Stack

Following on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more.  But first I need to get some terminology straight.

As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies—(X)HTML (of any flavor), CSS, and JavaScript—as “the web stack”.  I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand.  It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”.  If you like, think of “web stack” as a rough equivalent to “Ajax”—a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.

The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack.  SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.

When I use the term “web stack”, though, I’m not referring to back-end technologies.  Those things are important, certainly, but not from the front-end point of view.  A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you.  It doesn’t even care if the server runs on Apache or something else.

Furthermore, it doesn’t refer to plugins.  Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth.  What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all.  They’re just not part of that core web stack any more than the web stack is part of them.  That doesn’t stop them working together, obviously.

Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone.  Please do leave a comment if it isn’t.  Onward!


The winners of Microsoft’s MIX 10K Smart Coding Challenge (for which I was honored to serve as one of the judges) have been announced, and the Grand Prize has been awarded to…

Jimmy D‘s Frog Log.

Which is an HTML5/CSS/JS entry.

That doesn’t run in Internet Explorer.


Frog Log was my top pick, and obviously did very well with the other judges too, for a good reason: it’s a fun game.  It doesn’t play quite the same in Firefox previous to v3.5, as the drag-n-drop doesn’t work.  Instead, you click on a frog, then click where you want to place it.  I actually found that made the game a touch easier for me, but your interaction may vary.  In addition to working in Firefox, Safari, and Opera, it also runs on a number of mobile devices.

Here’s an excerpt from my judging remarks:

Just a great little game, addictive and well thought out with some interesting gameplay.  I would LOVE to see this developed further by the author…  My only ding was that drag-n-drop failed in Firefox 3.5; clicking worked fine, though.

I’m not sure why I had trouble with drag-n-drop in Firefox 3.5, since I don’t have have the same problem now.  Maybe I got confused with browser version numbers or something.  Regardless, it works fine, it’s a great game, and remember: it’s less than 10K unzipped.

I also gave high marks to the HTML5 runner-up, Chris Evans’ 100pxls, which was the source of my Dadaist tweet a couple of weeks back and lands right in my personal sweet spot for “doing odd things with popular web services”.  Here’s some of what I had to say in my remarks:

…really liked the concept here, especially the nonsensical tweets that were generated by drawing your own icon.  The icons could be made easier to see in the main display, but I suppose that’s a minor quibble.

I’d like to thank the MIX 10K crew for getting me involved as a contest judge; I really enjoyed seeing what people created and had a hard time narrowing down my votes to just a handful of winners.  More importantly, though, I offer my heartiest congratulations to all the winners, and most especially to Jimmy and Chris for doing such fun, interesting, and downright cool stuff with 10K of web standards goodness!

Fixed Monospace Sizing

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

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

span {font-family: monospace;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>
All right, what should be the computed font-size of the span element?  Remember, there are no other author styles being applied.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MIX Judging

I was recently honored to be asked to be a judge for the MIX 10k Smart Coding Challenge, running in conjunction with Microsoft’s MIX conference.  The idea is to create a really great web application that totals no more than 10KB in its unzipped state.

Why did I agree to participate?  As much as I’d like to say “fat sacks of cash“, that wasn’t it at all.  (Mostly due to the distinct lack of cash, sacked or otherwise.  Sad face.)  The contest’s entry requirements actually say it for me.  In excerpted form:

  • The entry MUST use one or more of the following technologies: Silverlight, Gestalt or HTML5…
  • The entry MUST function in 3 or more of the following browsers: Internet Explorer, Firefox, Safari, Opera, or Chrome…
  • The entry MAY use any of the following additional technology components…
    • CSS
    • JavaScript
    • XAML/XML
    • Ruby
    • Python
    • Text, Zip and Image files (e.g. png, jpg or gif)

Dig that:  not only is the contest open to HTML 5 submissions, but it has to be cross-browser compatible.  Okay, technically it only has to be three-out-of-five compatible, but still, that’s a great contest requirement.  Also note that while IE is one of the five, it is not a required one of the five.

I imagine there will be a fair number of Silverlight and Gestalt entries, and I might look at them, but I’m really there—was really asked—because of the HTML 5 entries.  By which I mean the open web entries, since any HTML 5 entry is also going to use CSS, JavaScript, and so on.

The downside here is that the contest ends in just one week, at 3pm U.S. Pacific time on 29 January.  I know that time is tight, but if you’ve got a cool HTML 5-based application running around in your head, this just might be the time to let it out.

HTML5 And You

I mentioned in my previous post that I “had come away with my head reeling from the massive length and depth of the often-changing specification”, which is entirely true.  Printouts of the current draft of the HTML5 spec can reach, depending on your operating system and installed fonts, somewhere north of 900 pages.  Yes: nine hundred.  There are unabridged Stephen King novels that run shorter.

You might well say to yourself: “Self, is it just me, or are the people doing this completely off their everlovin’ rockers?  Because the specification for something as fundamentally simple as HTML should reach maybe 200 pages, max.”  You might even despair that the entire enterprise is doomed to failure precisely because nobody sane will ever sit down to read that entire doorstop.

But there’s no real reason to panic, because here’s the thing about the HTML5 specification that might not be obvious right away:  it’s not for you.  It’s for implementors.  And that’s a good thing.

If you do start reading the HTML5 draft, you’ll start running into really lengthy, excruciatingly detailed algorithms for, say, parsing a time component.  Or moving through the browser’s history.  Or submitting a form.  There’s an entire (long) chapter on how to process the HTML syntax.

Those are all good things, actually.  They greatly increase the chances of interoperability actually happening within our lifetimes.  There’s no guessing about, well, much of anything.  It’s all been exactingly defined, to the extent that one can exactingly define anything using a human language.  A browser team doesn’t have to wonder, or even guess, what to do when the document has been completely parsed.  It’s all spelled out.  And the people on those browser teams will, in the end, be the people who read that entire doorstop.  (Their sanity is another matter, and not discussed here.)

How is all that stuff relevant to you, the author?  In the sense that when browser teams follow the spec, their products will be interoperable, which is to say consistent.  (Just imagine that for a moment.)

Beyond that, though, the detailed implementation stuff isn’t relevant to you.  You are not expected to know all those algorithms in order to write HTML documents.  Pretty much all you need to know is the markup.  That’s the part that should be no more than 200 pages, yeah?

Turns out it is, and by a comfortable margin.  Michael(tm) Smith’s HTML5: The Markup Language is a version of the HTML5 draft with all of those eye-wateringly pedantic implementor sections stripped out, and when I generated a PDF it came in at 147 pages.  That’s what you really need in order to get up to speed on what’s in HTML5.  It’s for you.

Nine Into Five

Like so many others, I had tried to dig into the meat of HTML5 and figure out just what the heck was going on.  Like so many others, I had come away with my head reeling from the massive length and depth of the often-changing specification, unsure of the real meaning of much of what I had read.  And like so many others, I had gone to read the commentary surrounding HTML5 and come away deeply dispirited by the confusion, cross-claims, and rancor I found.

Then I received an invitation to join a small, in-person gathering of like-minded people, many of them just as confused and dispirited as I, to turn our collective focus to the situation and see what we found.  I already had plans for the meeting’s scheduled dates.  I altered the plans.

Over two long days, we poked and prodded and pounded on the HTML5 specification—doing our best to figure out what was meant by, and what would result from, this phrase or that example; trying to reconcile seemingly arbitrary design choices with what we knew of the web and its history and the stated goals of the HTML5 specification; puzzling over the implications of example code and detailed algorithms and non-normative notes.

In the end, we came away with a better understanding of what’s going on, and out of that arose some concerns and suggestions.  But in the main, we felt much better about what’s going on in HTML5, and have now said so publicly.

Personally, there are two markup changes I’d like most to see:

  1. The content model of footer should match that of header. As others have said, the English-language name of the footer element creates expectations about what it is and how it should work.  As the spec now stands, most of those expectations will be wrong.  To wit: if your page’s footer includes navigation links, and especially if you have an HTML5-structured “fat footer“, you can’t use footer to contain it.

    If this feels a little familiar, it should: the same problem happened with address, which was specified to mean only the contact information for the author of a page.  It was quite explicitly specified to not accept mailing addresses.  Of course, tons of people did just that, because they had an address and there was an address element, so of course they went together!

    A lot of us cringed every time this came up in the last ten years of conducting training, because it meant we’d have to spend a few minutes explaining that the meaning of the element’s name clashed with its technical design.  We saw a lot of furrowed brows, rolled eyes, and derisively shaken heads.  That will be magnified a millionfold with footer if things are allowed to stand as they are.

    As I said, the fix is simple: just change the content model of footer to state:

    Flow content, but with no header or footer element descendants.

    That’s exactly the same content model as header, and for the same reasons.

  2. time needs to be less restrictive.  That’s not very precise, I know.  But as things stand now, you can only apply time to Gregorian datetimes, and you’re not supposed to use it for anything that couldn’t be easily represented in a calendaring program.  The HTML5 specification says:

    The time element is not intended for encoding times for which a precise date or time cannot be established.

    That makes me wonder, in a manner not at all like Robert Plant, how precise do we have to be?  The answer, I’m sorry to say, is too much.

    To pick an example: I have what I think of as a great use case for the time element, and while it uses the Gregorian calendar, it’s only accurate to whole months (as is Wikipedia’s version).  In some cases I could get the values down to specific days; but in others, maybe not.  So I can’t use the datetime attribute, which requires at least year-month-day, if not actual hours and minutes.  I could omit the attribute, and just have this:

    <time>October 2007</time>

    In that case, the content has to be a valid date string in content—which is to say, a valid date string with optional whitespace.  So that won’t work.

    I’ve pondered how best to tackle this, as did the Super Friends.  Our suggestion is to allow bare year and month-day values as permitted in ISO8601.  In addition, I think we should allow a valid date string to only require a year, with month, day, and time optional.  That seems good enough as long as we’re going to go with the idea that the Gregorian calendar contains all the time we ever want to structure.

    But what about other, older dates, some of which are fairly precisely known within their own calendars?  On that point, though the historian in me clamors for a fix, I’m uncertain as to what.  PPK, on the other hand, has put alot of thought into this and written a piece that I have skimmed but never, perhaps ironically, found the time to read in its entirety.

These are not my only concerns, but they’re the big ones.  For the rest, I concur with the hiccups guide, though of course to varying degrees.  I’m still trying to decide how much I care (or don’t) about the subtle differences between article and section, for example, or the way aside fits (or doesn’t) with its cousin elements.  And dialog just bugs me, but I’m not sure I have a better proposal, so I’ll leave it be for the time being.

At the other end of the two days, I felt a good deal more calm and hopeful than I did going in.  As Jeffrey said, “the more I study the direction HTML5 is taking, the better I like it”.  While there are still rough edges to be smoothed, there is time to smooth them.  We’ve already seen responsiveness on some of the points we addressed in the hiccups guide, and discussions around others.  The specification itself is daunting, especially to those who might remember the compact simplicity of the HTML2 spec.  Fortunately, it has good internal cross-linking so that you can, with effort, track down exactly what’s meant by “valid date string with optional time” or “sectioning content” or “formatBlock candidate“.

With HTML5, the web is not ending, nor is it starting over.  It’s evolving, slowly and in full view of the public, with an opportunity for anyone to have their say (which is not, of course, the same as having one’s proposals accepted).  It’s the next step, and I feel quite a bit more confident that it’s a step onto solid ground.

CSS3 Feedback: Graphical Thoughts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CSS3 Feedback: Animated Shapes

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

April 2014