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

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

From: Simon Fraser <smfr@me.com>
Date: Tue, 31 Aug 2010 10:57:51 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-id: <35071D09-B44E-48AF-A26B-98AE880190BF@me.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
On Aug 31, 2010, at 10:00 AM, Boris Zbarsky 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?
>>>> 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.

Agreed, I think -webkit-canvas is a different beast to element(). -webkit-canvas simply creates a canvas context with the specified height and width; there is no associated canvas element, and there's nothing in the document.

One useful use case I see missing with element() is the ability to reference an element in a display: none subtree, so you can, for example, have some nodes in the <head> that you use to draw HTML content into a <canvas> or CSS background or WebGL.

Received on Tuesday, 31 August 2010 17:58:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC