Re: Coordinate spaces in SVG and CSS

On Tue, Apr 27, 2010 at 1:50 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/27/2010 12:32 PM, Tab Atkins Jr. wrote:
>> 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.

Ah, k, so the issue is that you're referring to images like in <img>,
when I'm referring to *just* background-image and list-style-image.
You are correct that I have to do more to make it apply to the sizing
of replaced elements.


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

Me reading that section is not the issue; I simply am currently
purposely not addressing the cases where that chapter is relevant.


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

background-size and background-origin are explicitly called out as
affecting the size of the "default image sizing area".

Handling replaced elements correctly does indeed appear to be
something I need to do, but that's not an error in my current algo,
just a purposeful lack.

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

I think that's covered by the CSS View Box, right?  I can change the
text in step 3/4 to make it more explicit that clipping is not
automatic, and the image may spill out of the View Box, and CSS will
take care of the clipping if necessary later down the painting
pipeline.

I'll see about rewording things so that I'm not inventing a new term
just for the intrinsic dimensions.

~TJ

Received on Tuesday, 27 April 2010 22:24:58 UTC