W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [css3-values][css3-images] element() function

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 31 Aug 2010 13:00:46 -0400
Message-ID: <4C7D353E.5030606@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
On 8/31/10 12:48 PM, Tab Atkins Jr. wrote:
>>   And this obviously breaks incremental layout where absolutely
>> positioned boxes are involved, because you have to lay out the referenced
>> element before you lay out the abs pos boxes, right?
>
> Yes, if the referenced element comes later in the document than the
> abspos.  Incremental layout will, in general, start to break more as
> we introduce more advanced layout features.

Yes... but this particular case has especially interesting breakages 
because it imposes constraints on when you can lay out your absolutely 
positioned elements that, unlike now, have nothing to do with the 
document tree.

I assume that you've also thought about the case when you get 
positioning root cycles?

>>> I believe it is safe to add this to V&U right now.  Given that we
>>> already have one implementation, and Webkit offers a similar ability
>>> as well, it should be quite safe to add on the verge of Last Call.  If
>>> necessary, we could add it as At Risk.
>>
>> I don't see how -webkit-canvas is much similar...
>
> It's similar in that it's referencing an element to be used as an
> image.  The implementation is quite different underneath, since I
> believe we just use the<canvas>'s backing store rather than actually
> looking at the element itself, but we have code sitting around that is
> much closer to the behavior we need for element().

Do you?

What you have, based on http://webkit.org/blog/176/css-canvas-drawing/ 
and without having looked at your code, is an identifier-to-element map 
with explicit update locations (the getCSSCanvasContext calls).  It 
doesn't have to get updated on DOM mutations, etc.  And as you point out 
the drawing end is totally different from what -moz-element does, though 
that's not relevant to values&units.  So as far as I can see, what you 
have is similar to what -moz-element is doing only in the sense of 
having a string-to-element hashtable somewhere at its core; pretty much 
nothing else (i.e. none of the hard stuff) is shared.

Am I just missing something?

Note, I'm not at all against adding an element() to Values&Units.  I 
just don't think we have two implementations of such a beastie right 
now, even in different guises, as you implied.

> The point was to
> suggest that Webkit also sees the value in being able to use an
> element as an image source.

More precisely, Webkit sees the value of allowing authors to dynamically 
create images to use in a CSS context; that's a natural extension of 
<canvas>, which allows it in an HTML context.

I can take your word for it that Webkit sees the value in the other, if 
that's what you're saying.  But using -webkit-canvas as justification 
for that claim doesn't make sense to me.

-Boris
Received on Tuesday, 31 August 2010 17:01:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT