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

On Aug 31, 2010, at 2:47 PM, Tab Atkins Jr. wrote:

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

A -webkit-canvas is not really a "thing in the page". There is no canvas
element in the DOM.

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

I'm glad you brought up -webkit-box-reflect; this is another example of
rendering a "replica" of something in another place on the page. It would
be nice if we could unify reflections and element() somehow (without having
to add another element in the page for the reflection).

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

No push-back from me, but I'm not convinced that element() is quite right yet.

Simon

Received on Tuesday, 31 August 2010 22:36:08 UTC