'object-fit' values 'cover' and 'contain' contain redundant definition from Leif Arne Storset on 2012-02-22 (www-style@w3.org from February 2012) (original) (raw)

Tab Atkins Jr. <jackalmage@gmail.com> skreiv Wed, 22 Feb 2012 03:06:48
+0100

On Thu, Feb 2, 2012 at 4:12 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

On Wed, Feb 1, 2012 at 7:07 AM, Leif Arne Storset <lstorset@opera.com>
wrote:

In section 5.4, both 'contain' and 'cover' seem to be defined twice.
For example, 'contain' says

| Determine the used ‘height’ and ‘width’ of the element as usual, |
except: If both ‘height’ and ‘width’ are ‘auto’, and the used | value of at least one of ‘max-width’ and ‘max-height’ is not | ‘none’, then compute the element's used width and used height as | though the intrinsic dimensions of the contents were infinitely | large numbers whose ratio is the actual intrinsic ratio of the | contents. This will proportionally scale the used width and | height up to the given maximum constraints. | | Set the concrete object size to the largest width and height that has | the same aspect ratio as the object's intrinsic aspect ratio, and | additionally has neither width nor height larger than the replaced | element's used width and height, respectively.

These seem redundant to me. I suspect the first definition, written in 2007, hails from a time when '(max|min)-(width|height)' were
underdefined in level 2, and "as usual" wasn't sufficient. [0] Determining used
values for 'width' and 'height' seems out of scope for this property and this spec, as implied by the introduction to 5.4:

| The ‘object-fit’ property specifies how the contents of a replaced | element should be scaled relative to the box established by its used | height and width.

I could be wrong: my head is spinning from trying to calculate some examples according to both the specs. If I am wrong, and some situation does require all the infinity math, I feel we could phrase it more simply and/or state the covered cases more clearly.

My primary suggestion, however, is to delete the first paragraph, both under 'contain' and 'cover', so that both consist only of a paragraph starting with "Set the concrete object size…".

[0] At the moment I can't find old versions of CSS 2.1, but CSS 2 does
not define it as well as CSS 2.1. CSS 2: http://www.w3.org/TR/2008/REC-CSS2-20080411/visudet.html#min-max-widths CSS 2.1: http://www.w3.org/TR/CSS21/visudet.html#min-max-widths

Nope, it's not redundant. Those first paragraphs have the effect of forcing the size of the element itself to the min/max constraint.

I agree that this is out-of-scope for this property. Fantasai does not.

Since I rejected this feedback, could you indicate whether you're okay with this resolution or not, Leif? This is necessary for the Disposition of Comments.

Ah, didn't realize that was a rejection (rather than a postponement).

I disagree (i. e. agree that it is out of scope). You're right that they
are not redundant with each other, but the first definition is redundant
with the now more robust CSS 2.1 section 10.4.

I can live with it, though, since it's not incorrect, and I've already
implemented and understand what it's talking about. :) I do think it is
very confusing for first-time readers.

(Just now I realized that the introduction also mentions this behavior:
"[The property] also enables scaling a replaced element up to a specified
maximum size or down to a specified minimum size while preserving its
aspect ratio.". That should also have been deleted in my change proposal.)

If you do keep it (and it's not too late in the process for editorial
changes!), I would suggest adding a reference to CSS 2.1 section 10.4,
where element sizing is defined more explicitly. That way, first-time
readers will get that this part of the definition deals with something
different than the other part. Such as:

| 'contain' … | This will proportionally scale the used width and height up to the | given maximum constraints.

and similarly for 'cover'.

-- Leif Arne Storset Core Technology Developer, Opera Software Oslo, Norway

Received on Wednesday, 22 February 2012 11:00:48 UTC