W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [css3-images] interaction of parts of the definitions of object sizing

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 21 Mar 2012 14:20:53 -0700
Message-ID: <CAAWBYDCmtRNUJtMr2SAYBfjVR3h=mpmrbD7HgONXi3s54G4qjg@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Wed, Mar 21, 2012 at 2:47 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 03/15/2012 05:08 PM, Tab Atkins Jr. wrote:
>> * I've split the old "replaced elements" case into three, since it was
>> wrong before.  There's now a section for the 'content' property
>> (non-replaced, which is all you can do in 2.1), a section for replaced
>> elements (just calling out that they *dont'* use the sizing algorithm
>> here, and pointing to CSS2.1 sections 10.4 and 10.7 instead), and then
>> a section for the *contents* of replaced elements, hooking into
>> 'object-fit'.
> Images in generated content are replaced elements just as much as actual
> replaced elements are. They're effectively anonymous replaced elements,
> but they behave the same way. If this is not clear, it should be a CSS2.1
> issue: we shouldn't be treating them as a separate case here.

They're a different case because they don't have width/height or
max/min-width/height properties that apply to them and affect their
sizing.  They're nice, simple constraint-less replaced elements.  Thus
they absolutely deserve a separate case in the algorithm.

(When we add the ability to declare that 'content' images are "real"
replaced elements and not anonymous replaced blocks, it'll need to
clarify that those fall into the "replaced elements" clause, not the
'content' clause.)

>> Please review these changes and let me know if you're satisfied with them.
> Still need to do that... but I suspect I'll say something like "instead of
> trying to exhaustively define all possible sizing constraints here (which
> is just asking for future failure), we should provide a default algorithm
> and make it easy for specs to hook into it".

I'm not trying to do so.  I'm adding in two apparently-common sizing
cases (cover/contain appear in multiple places, and rounding appears
twice but is complicated enough that it should be specified in one
spot to avoid accidental drift between uses) that might as well be
addressed once, properly, rather than repeated multiple times.

Received on Wednesday, 21 March 2012 21:21:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:13 UTC