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

On Tue, Aug 31, 2010 at 9:38 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 8/31/10 12:25 PM, Tab Atkins Jr. wrote:
>>
>> While all the uses right now are element-as-image, this also finally
>> offers the possibility of selectors on the RHS of properties.  At the
>> moment -moz-element() only accept id selectors, but one could imagine
>> it accepting an arbitrary selector and just grabbing the first matched
>> element
>
> This is actually significanty more complex to implement, withou being
> deathly slow; id selectors are nice and simple because browsers already have
> a hashtable they maintain mapping IDs to elements and can notify interested
> parties when the mapping for a given id changes.  For an arbitrary selector
> you somehow have to make sure you change what element is matched when the
> DOM mutates.  This can get pretty complicated.

Right, it's certainly much more complicated.  But it's a future direction.  ^_^


>> one use in particular that I'm interested in is being able to specify an
>> arbitrary element as the "positioning root" for an abspos element.
>
> This seems like a use case that could be restricted to selecting only on ID
> for now without much loss of functionality.  That said, using
> element(#some-id) for this might not be too bad.

Yes, the id-selector version is definitely sufficient for this,
particularly since it occurs in a heavily scripted environment.  Using
element() more generally than just images and making element() accept
more than just ids are orthogonal feature requests.


> You'd have to specify what
> happens if that element is not in the DOM or is in a display:none subtree,
> of course.

Yes, these would need to be solved in such a case.  There are several
possible solutions, some of which should be quite easy.


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


>> 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().  The point was to
suggest that Webkit also sees the value in being able to use an
element as an image source.

~TJ

Received on Tuesday, 31 August 2010 16:49:07 UTC