Re: Coordinate spaces in SVG and CSS

On 04/27/2010 12:32 PM, Tab Atkins Jr. wrote:
> On Tue, Apr 27, 2010 at 11:33 AM, fantasai
> <fantasai.lists@inkedblade.net>  wrote:
>> On 03/26/2010 06:49 PM, Tab Atkins Jr. wrote:
>>>
>>> I've committed a first draft of the View Boxes section to the dev copy
>>> of CSS3 Images.  This needs some revision, and I think it may be a
>>> good idea to expand this into a more complete description of how
>>> background images are handled in CSS.
>>>
>>> Any feedback is appreciated, particularly if what I have specified is
>>> somehow inaccurate.  I'd also like to know just what CSS's behavior is
>>> for an image with an intrinsic width but not an intrinsic height (or
>>> vice versa).
>>
>> So... Step 2 in your algorithm is completely wrong. Intrinsic sizes
>> do not win against specified sizes. The rules for resolving the size
>> of a CSS view box are not simple, and do not belong in this spec.
>> (I suggest hanging out in CSS2.1 Chapter 10 for a bit, and then
>> reading up on image-fit and image-position if you don't believe me.)
>
> I don't think Chapter 10 has anything to do with this section.  You
> may be conflating my use of the term "view boxes" with a
> browser-internal term referring to some rendering-pipeline objects.
> I implicitly defer to normal CSS sizing algos in the definition of the
> "default image sizing area" - should I be more explicit here that I'm
> deferring in such a manner?

Chapter 10 has a lot to do with this section, because you're trying
to override it in step 2. You can't defer to normal CSS sizing
algorithms in the definition of "default image sizing area"
because the algorithms are more than just a box you resolve to.
They need the values of various properties as well as the image's
intrinsic dimensions in order to resolve to a rectangle. It has
to happen in step 2, i.e. after the intrinsic size is requested
from the replaced object.

Like I said, read Chapter 10 and the image-fit definition.
Specifically, you want CSS2.1 sections 10.3.2, 10.4, and 10.7.
Don't /scan/ it; you have to really read it if you're writing
spec text that interacts with it!

> I see what you mean about specified vs intrinsic sizes, though.  I was
> writing this in the context of background-image and list-style-image,
> where intrinsic sizes *do* win.  Given the context of the Images
> module, which is about the<image>  value, this should still be
> correct.

No, they don't win. You can specify the size of the background image
with background-size, and that wins over the intrinsic size. Also,
the 'content' property can create a replaced element.

> Should I throw some extra verbage at this defining how replaced
> elements work?  Considering that all elements can become replaced by
> using the 'content' property, which makes use of the<image>  value,
> this is probably relevant.  I believe I'd just have to break step 2
> into "normal image" and "replaced element" sections, which respond to
> box dimensions and image dimensions slightly differently.

Images are a subset of replaced elements. "Extra verbage" is not what
you need, a terminology change is what you need.

On another terminology note, you're defining "object view box" as
synonymous with "intrinsic dimensions". We don't need another term
meaning "intrinsic dimensions". The concept without a term was the
bounding box of the image--the thing that's usually synonymous with
its viewport. The reason it was needed was so that we could
disassociate it from the clipping behavior of having a viewport.

~fantasai

Received on Tuesday, 27 April 2010 20:51:07 UTC