Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-sizing-3][css-images-3] Distinguish intrinsic size's two definitions with two terms #4961

Closed
fantasai opened this issue Apr 16, 2020 · 7 comments

Comments

@fantasai
Copy link
Collaborator

We have used the term “intrinsic size” to refer to two slightly different concepts (that overlap) in our spec:

  • the inherent size of a replaced element (which sometimes exists)
  • min-content and max-content sizes (which always exist, and are derived from the content)

We need to have separate terms for these so there's no confusion.

@fantasai
Copy link
Collaborator Author

fantasai commented Jun 5, 2020

Related discussion #5032 (comment)

@SimonSapin
Copy link
Contributor

In Servo code we’ve been using "intrinsic sizes" for the optional width, optional height, and optional ratio inherent to replaced elements, and "content sizes" for min-content and max-content (per the term used in those keywords). I’m not super happy with the latter since it’s easy to confuse with the (computed or used) size of the content area https://drafts.csswg.org/css2/box.html#box-content-area

@fantasai
Copy link
Collaborator Author

fantasai commented Oct 13, 2020

HTML spec seems to use the term “natural width” and “natural height” for the first concept, so maybe “natural size” for the intrinsic size of replaced elements and “intrinsic size”for the content-based sizes?

A few other options from the thesaurus include “inherent”, “innate”, “essential”, and “inbuilt”. Maybe “inbuilt” since we're talking about sizing information built into the replaced element...?

@rachelandrew
Copy link
Contributor

I think I've been using natural size when describing replaced elements, certainly when teaching in person/online. "The natural size of the image ..." referring to the actual dimensions of the the thing. It may be that came from reading the HTML spec at some point if that is how they are described there. So I'd agree with @fantasai to use natural size for replaced elements and intrinsic size for content.

@SimonSapin
Copy link
Contributor

Natural size sounds good to me, and consistency with HTML seems worthwhile.

HTML defines natural size as density-corrected. I think we want that.

When an img element has a current pixel density that is not 1.0, the element's image data must be treated as if its resolution, in device pixels per CSS pixels, was the current pixel density. The image's density-corrected intrinsic width and height are the intrinsic width and height after taking into account the current pixel density.

This is based on a css-images definition, so changing that may require coordination with HTML.

The density in question is from srcset (through update image data and select an image source algorithms).

@astearns astearns added this to the TPAC-2020-08-20 milestone Oct 16, 2020
@css-meeting-bot
Copy link
Member

css-meeting-bot commented Oct 20, 2020

The CSS Working Group just discussed Distinguish intrinsic size's two definitions with two terms, and agreed to the following:

  • RESOLVED: Rename term "intrinsic size" of image with "natural size"
  • RESOLVED: Republish WD of css-sizing-3
  • RESOLVED: Add emilio as editor of cssom-view
The full IRC log of that discussion <Rossen_> Topic: Distinguish intrinsic size's two definitions with two terms
<Rossen_> github: https://github.com//issues/4961
<tantek> fantasai: we've been using intrinsic size to refer to two different concepts
<tantek> ... one is the size of a replacement element
<tantek> ... the other concept is referring to the min-content and max-content sizes, which always exists for any box, they are determined in some manner
<tantek> ... we need two different terms for this
<tantek> ... the HTML spec uses the term natural width and natural height
<florian> q+
<tantek> ... we were thinking to replace the use of intrinsic size as it applies to the inherit size of a replaced element with natural size
<tantek> ... and keep intrinsic size to mean the other
<Rossen_> ack florian
<myles> q+ to ask if this is a behavior change
<heycam> +1 for aligning terms across specs
<tantek> florian: with the new dfn, the intrinsic size of a replacement it would be the natural size and 0 otherwise?
<tantek> fantasai: no it can lack an intrinsic size
<tantek> florian: I don't understand
<tantek> fantasai: you have to distinguish between whether you are taking about a min-content and a max-content size
<cbiesinger> q+
<tantek> fantasai: when the natural size of something does not exist, there are rules for determining
<heycam> q+
<Rossen_> ack myles
<Zakim> myles, you wanted to ask if this is a behavior change
<tantek> myles: is this purely a rename or behavior change?
<tantek> fantasai: purely terminology in the spec
<Rossen_> ack cbiesinger
<tantek> cbiesinger: this is only for replacements but, don't you need a terminology for non-replaced elements with an aspect ratio because the regular min and max content size will be affected by the aspect ratio, but you also need a way to refer to the original min and max content size because you need that for width and height auto
<Rossen_> q?
<tantek> fantasai: I see what you're talking about, havent' thought about that yet
<cbiesinger> s/replacements/replaced elements/g
<Rossen_> ack heycam
<tantek> heycam: we should check what the HTML spec says
<tantek> ... and I did, and they return 0
<cbiesinger> s/width and height auto/min-size auto/
<cbiesinger> tantek: yep!
<Rossen_> q
<tantek> ... I just want to make sure we don't have any confusion by using the same terms
<tantek> fantasai: I think the DOM APIs can return 0 when there is no natural size
<tantek> TabAtkins: do the DOM APIs refer to it any other way other than the camelcased form?
<tantek> heycam: no it refers to JS properties
<tantek> florian: this is confusing / not good
<fantasai> scribenick: fantasai
<fantasai> fantasai: Their spec is using 'intrinsic size' because that's what our spec uses.
<fantasai> fantasai: when we update our specs, we'll make sure HTML updates their terms to match als
<fantasai> Rossen_: Hearing mostly support for having this clear distinction
<fantasai> Rossen_: Are we leaning towards also accepting the proposed names here, "natural size"?
<heycam> s/and the return 0/and they return 0 for images that have no natural size/
<florian> +1
<fantasai> fantasai: 2 votes in favor from rachelandrew and SimonSapin
<bkardell_> +1
<fantasai> Rossen_: I don't see anyone not liking it. Any objections?
<bkardell_> actually this confused me quite a bit last year
<bkardell_> I remember having exactly this converation with tab in toronto trying to figure it out
<fantasai> RESOLVED: Rename temr "intrinsic size" of image with "natural size"
<fantasai> s/temr/term/
<fantasai> Rossen_: Seems like everything on Sizing 3
<fantasai> Rossen_: Alan has an editorial issue to talk about
<fantasai> Rossen_: With everything we resolved, do we need to republish
<fantasai> fantasai: yes, and
<fantasai> fantasai: That closes all the major issues on this spec, so we'd like to issue a last call for comments and start preparing for CR
<fantasai> astearns: so resolution to publish after all these edits are in?
<fantasai> RESOLVED: Republish WD of css-sizing-3
<fantasai> and start CR process after that
<fantasai> astearns: emilio just volunteered taking on cssom-view at least on the issues he raised
<fantasai> RESOLVED: Add emilio as editor of cssom-view
<smfr> thank you emilio!
<myles> emilio is the best
@fantasai
Copy link
Collaborator Author

fantasai commented Dec 16, 2020

Tab and I made the edits for this today. Will need to republish css-images-3 first so that other TR specs can cross-link to it correctly when they're also republished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants