- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 3 Jan 2014 14:36:50 -0800
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: www-style list <www-style@w3.org>, public-fx <public-fx@w3.org>, www-svg <www-svg@w3.org>
On Fri, Jan 3, 2014 at 2:34 PM, Dirk Schulze <dschulze@adobe.com> wrote: > On Jan 3, 2014, at 10:40 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> Note the closely-related question of what to do for paint servers in a >> CSS context, which Images defines in line with Firefox implementation, >> based on an old blog post of roc's: >> <http://dev.w3.org/csswg/css-images/#paint-sources> >> >> There, the space you're drawing into is identical for both cases; the >> only difference is the size of a coordinate unit. >> >> I think the same really makes sense here, for things like clip-path - >> use the bounding rect. If we have a way to manipulate the box used, >> it should also affect stuff using objectBoundingBox, in the same way >> as images. >> > > It makes very much sense to use the same definition. While I describe the size as the bounding client rect (based on the result of getBoundingClientRect()), CSS Image is using the term “concrete object size”. The definition of this term spreads across three other definitions and is a bit confusing to me. Could you provide examples how this looks like for overflowing content? > > I assume that the definition of "concrete object size" is not necessarily compatible with the observed behavior in Firefox, WebKit and Blink where it is the mentioned bounding client rect for objectBoundingBox for example. The “concrete object size” is just the size of the CSS image, after processing things like intrinsic sizes, cover/contain constraints, etc. Don't read it as referring to anything more complicated. It has nothing to do with layout or element boxes. ~TJ
Received on Friday, 3 January 2014 22:37:37 UTC