CSS3 Feedback: Animated Shapes
Published 15 years, 9 months past(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.
Comments (14)
Thing is, CSS animation is not stepping on the toes of JavaScript. As far as the purist standpoint goes, CSS is entirely devoted to the presentation of elements. JavaScript is about user interaction behaviour and HTML manipulation. Animating is (most often) merely triggered by a behaviour, but animation itself is entirely within the remit of “controlling presentation” and therefore belongs in CSS.
Irregular objects would be nice, certainly, but I’ve got bigger concerns with CSS. Sorting out layout is desperately needed, most of the other stuff that CSS3 has on the agenda is nice to have, but far less pressing. Rounded corners, drop shadows, animation – nice. But not critical.
Matt, while not trying to derail Eric’s point too much (since he wanted to avoid it to begin with), JavaScript is not just about user interaction or HTML manipulation. It’s about “change”. My concern with CSS animation has been that a change is being performed and it’s not entirely clear how that affects JavaScript’s ability to detect and work with that change. What is the computed style of an element half way through an animation? Does JavaScript know when the animation has started or when it’s stopped? Is it easy to bind and unbind animations? (And I haven’t had time to properly research the matter).
In any case, I agree with Eric Meyer on this post and (as I tweeted), I’m now thinking through the spec for element-shape (I’m already finding it harder than I expected).
The “contour” idea is the way to go for both floats and box envelopes IMO. This is the kind of work computers are good at—let them do it. Let us just draw the polygon and get on with it.
The question of how to deal with faded gradients isn’t hard to answer: masks. In fact, masks might be the right way to handle all contours: a simple B&W shape defining the borders.
Fair point, I’ll keep my reply brief so as to not get too far off topic (my apologies Eric). As I understand it, and I am by no means knowledgeable about the intricacies of browser functionality or mechanics, the JavaScript layer can inspect the properties of any element at any point in time. That’s the behaviour of web sites today, the caveat being that all state changes (bar :hover and it’s siblings) have been implemented in JavaScript. I would therefore expect that JavaScript would be able to see all the information about an object no matter what point in the animation it is in, even in a CSS powered animation. Whether that’s the case right now isn’t the point I was attempting to make, though it is certainly one that needs clarifying and I’m glad you pointed it out as I was taking it for granted. From an ideological perspective, animation fits into CSS. Whether the practical implications of that fit or not is a different matter.
Getting back on topic, I do not understand the desire to define non-rectangular shapes programatically. As mentioned by Eric and yourself, it gets very complicated very quickly, and hard to manage for the author. Perhaps I am not understanding quite what the use case is for this sort of ability – but wouldn’t CSS Masks achieve these sort of things far more easily? Apply an image mask to a content area and you have your irregular shape.
http://webkit.org/blog/181/css-masks/
Matt, CSS masks might be fine, assuming some clarification. You’ll need specify what happens if, for example, a 5×5 pixel mask image is applied to a
divcontaining several paragraphs of text in order to define the actual area of thedivwhere that paragraphed content is allowed to flow. Similarly, we’d need to know what happens when such a mask is applied to a floated 300×300 image with text flowing next to it. Also what happens when a mask image is bigger (whether by a little or a lot) than the element to which it’s applied, in both the replaced and non-replaced cases.As I understand it the mask can be made to grows/shrink to fit the content area using a nine-slice approach:
“One key difference between mask-box-image and its border-image counterpart is that it doesn”t attempt to fit itself to border widths. It will just render the corners unscaled and tile/stretch itself into the border box without regard for the border itself. This lets you easily use nine-piece-image effects as masks on elements without borders (often image or video elements).”
I assume that the other methods do not scale, though it’d be nice to have an option to control that. I also love the fact the CSS Mask takes SVG (which I presume does scale, but I’ve not tested.
Definitely there needs to be some clarification, for example I’d like to see a property to switch between treating the clipped area’s bounding-box as the float boundry, and the actual edge of the mask as the float boundry; so the author has the choice of allowing text to wrap to either the bounding box or the mask edges itself.
Either way I look at it, I find the concept of using an image to define a non-regular shape as easier to understand, easier to maintain, and more flexible than any kind of co-ordinate based system.
Pingback ::
Web roundup « MySQLTalk.com
[…] Meyer provides feedback on some long awaited CSS3 features. It will be very cool to use shapes in […]
Funny how the form inputs got almost no mention, specially considering how html5 will bring a LOT of different inputs into the game.
The calendar inputs (date, month, datetime…) will NOT be used by the large mass of designers unless they are able to style them and get them to look fancy enough.
> … coolness of slowly rotating an entire page. Which I totally need to do the next time I give a presentation.
Give a presentation on a boat in stormy weather and have what’s on your screen stay leveled with the horizon :-)
I’m not completely against CSS animations but I’m definitely afraid of it. I hope that “turn off CSS animations” browser option will come hand in hand with CSS animation implementations.
I don’t know that I agree with your assertion, Daniele, that “calendar inputs (date, month, datetime…) will NOT be used by the large mass of designers unless they are able to style them and get them to look fancy enough”. All the existing form inputs are used by, well, just about everybody, even though it’s quite possible to construct JS-based equivalents that can be fully styled. I think a good number of people will just drop in calendar inputs once they’re widely supported, so that they can reduce page weight and stop having to worry about all the JS and stuff that goes into calendar inputs now.
Of course, a lot of people will stick with what they’re already using. In that sense, I suppose, calendar inputs will face the same problem JS alternatives to existing form elements do: overcoming the inertia of what’s already in place.
Matt, the nine-slice approach is fine for what it does but not nearly enough to manage what a lot of people want. For example, say I want to put three paragraphs of text in a diamond shape. So I wrap them in a
divand apply a mask to thatdiv. All I have is a 20×20 PNG mask image. The nine-slice approach means I get cropped corners, but no diamond flow. A scaling approach means… what? Assume the rendered size of thedivis 500×500, if that helps.Saying “don’t do that” doesn’t fly, of course: someone will and the browser has to know what to do. So that has to be specced out.
I’m not opposed to your suggestion, mind you. I think masks are a nicely intuitive and powerful way of handling shapes, even if they do increase page weight in a way that a coordinate-based shape generally wouldn’t (though in some cases, like very curvy shapes, that might not be true). But we can’t simply say “masks are the way!” and expect it to Just Work. Someone has to work through all the ramifications and then—and this is always the tricky part—get the WG to consider it seriously and the implementors to get behind the idea of implementing it. Or do it the other way around, by getting implementors behind the basic idea and then speccing it out in a universally acceptable manner so that the WG can just publish and approve the result.
Sorry about that, but being italian I face a market where looks is king (“king-er” than content) from the customer perspective, and it’s going to be tough to say “here’s an upgrade to your site, with calendar inputs!” “but we already had those and they looked better”.
Explaining them that those are less mantainable is going to be a pain in the arse. Having pseudoclasses to style webforms inputs would be a very nice addition, say input[type=url]:icon{ url(/i/webicon.png) } for url items, and more complex ones for the calendar widget.
Altering colors, sizes, (single) borders/backgrounds would be enough for pretty much anyone.
There are definitely scaling issues when using an image-map as a mask. I’m not convinced that many authors would use a 20×20 image and expect it to work at 500×500, but as you say – it needs to be thought about. “How would I break it” interrogation like that is to be expected, and sensible answers must be given in the spec.
What I like about the Mask option is the ability to use SVG for scalable shapes, and also bitmaps for cases where the scale of the masked area is more rigorously known (which for the use cases I have in mind would almost always be the case anyway). It’s the best of both worlds – a vector/co-ordinate based mask capability alongside a less involved bitmap alternative.
As for page weight, that is and isn’t a concern depending on all sorts of things. At the moment Webkit expects a transparent PNG, which is 32bit, and therefore bloats the file-size fast. I filed a bug-report some months ago arguing for a change to use the luminosity value of any image as the alpha value of the mask – this way instead of a 200kb 32bit PNG you could use a 60kb JPG. Or a GIF.
I’m encouraged by the fact that Webkit already has an implementation of Masks working. I’d like to see a few changes, as we have discussed, but I see the thought process going on over there that would mean Masks have a credible chance of offering a solution to non-regular shapes in CSS that are flexible and un-complicated for an author to implement. I appreciate that it may be a lot harder for browser engineers, but frankly that isn’t my concern.
Also on my wish list (no matter how implausable) is that ability for CSS to interrogate connection speed and browser states. So I can set a default “low quality” version but serve a “high quality” version if the connetion speed is above a designated rate. Or detect cases where images are off but CSS is on.
@connection all and (min-speed: 512kbps) { body { background-image: url(high-quality.png); } }