Re: Coordinate spaces in SVG and CSS

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?

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.

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.


> Also, seam carving is a method of scaling images that doesn't scale
> them evenly; it's not about clipping content.

Good thing I mentioned that in context of scaling the image, then.
^_^  (Though, seam carving does indeed clip content, it just clips out
individual seams that it determines to be least important, rather than
clipping a large rectangular region.  The effect is similar to
scaling, though.)


> I like how you define the terms and then list the negotiation steps,
> but yes, it needs some revision. Mainly clipping, I think. :) And
> some terminology changes, because Java applets are not images but
> they follow the same rules.

Hmm, true.  Didn't we decide to go with 'object' for the -fit and
-position properties at the ftf?  I could change my terminology to use
"object" instead of "image" for consistency, and make it clearer that
this refers to all kinds of external content in the introduction to
the section.

~TJ

Received on Tuesday, 27 April 2010 19:34:34 UTC