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

On Tue, Aug 31, 2010 at 10:00 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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?

Yes, I have.  I'll break it, probably based on which one is first or
last in document order.


>>>> 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?

Well, -webkit-canvas() suggests that we're cool with using things in
the page as image sources.  Then we have properties like
-webkit-box-reflect, which show that we've already got the issue of
drawing a single element in multiple places solved in some fashion
(though from what I hear, it's not being solved in the way we'd
probably want to use for element()).

So, the will and the techniques are there, is my point.  Webkit
probably won't push back on this feature.  ^_^


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

I still think we sorta do, but I won't push the point.  Having one
impl is enough to show that adding it to V&U is reasonable.  We're not
blue-sky speculating here, is what I'm saying.

~TJ

Received on Tuesday, 31 August 2010 21:48:31 UTC