I've been investigating some corner-cases for the element() function,
because it's not fully specified yet. The current spec has several
issues attached to that section with demos of each, showing Firefox's
current behavior for them. I'm going to go over them and ask whether
each is sane to everyone else.
1. Using an element with a transform
- The size of the image is generated from the element's normal
geometry, ignoring the transform (as normal, since transforms never
touch geometry). The image itself reflects the transform. This may
mean that the appearance is chopped up, as the transformed element no
longer fits within the actual geometry constraints.
2. Using an element with a transformed ancestor
- The transform is ignored entirely. Size the image and render the
element as if it wasn't transformed at all.
3. Using an inline element broken across lines
- The image is sized to the bounding box of all the individual
boxes. The element is rendered in its normal, broken-up, positions
within that box.
4. Using an element broken across columns
- The same as #3; the image is sized according to the bounding box.
5. Using an element broken across pages
- ??? Haven't yet tried to test it.
6. Using an element broken across regions
- ??? Regions and element() don't yet exist at the same time in a
single browser, so I can't test. What would be sane?
7. Using an element within a replaced element (currently, <option> is
the only example that can be said to "render")
- Firefox renders them fine, as the things in the "popup" portion of
the select. The currently-selected option shown within a closed
select isn't targetable; you only see it when you actually use the
select.
Again, all of these have demos in the spec right now, so review them
there if you want to see them in action (use a recent Firefox,
obviously).
Are these things sane? I'm not sure how to even define #7, since
<select> is a replaced element and thus the rendering of <option> is
officially out-of-scope.
~TJ