Re: [css3-images] Element() corner-cases

On 08/04/2011 02:35 PM, Tab Atkins Jr. wrote:
> 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.

If #1 means what I think it means, then no, that doesn't seem sane.
I'd go with matching the behavior in #2, i.e. ignoring the transform.

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

These seem sane.

> 5. Using an element broken across pages
>    - ??? Haven't yet tried to test it.

I'd glue together the page areas in the pagination direction and
take the bounding box. If the page areas have different measures,
start-align them.

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

Glue together pages, if it spreads across pages, and then take the
bounding box as for columns.

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

I'd make this undefined and tell authors not to do such things.

(I suspect this is one area where the way Gecko handles form controls
makes this a straightforward thing to do, but for UAs that transform
<select> into a native control, this would not be straightforward.)

~fantasai

Received on Friday, 5 August 2011 02:25:47 UTC