[CSSWG] Minutes Virtual F2F 2020-07-27 Part II: Sizing, Images [css-sizing] [css-images]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Sizing

  - RESOLVED: 'height: stretch' behaves as 100% applied to margin-box
              where 'align-self: stretch' isn't possible (Issue #1614:
              `height: stretch` should just behave as `height: auto`)
  - There was interest/support in doing further exploration into and
      creating a proposal for importing the aspect-ratio from a child
      (Issue #5269: Import aspect-ratio from child image). Some items
      raised on the call for the proposal to consider is behavior
      around whitespace and importing from first child instead of
      importing only if there's one child.

CSS Images

  - RESOLVED: Do not expose orientation data for cross-origin images
              by treating EXIF orientation as integral (can't ignore)
              (Issue #5165: image-orientation:none violates
              same-origin policy)


Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday

Scribe: fantasai


`height: stretch` should just behave as `height: auto`
  github: https://github.com/w3c/csswg-drafts/issues/1614#issuecomment-661391733

  TabAtkins: A little while ago we added 'stretch' keyword to width/
  TabAtkins: width: stretch does what blocks normally do in block
  TabAtkins: even in cases that currently do fit-content for 'auto'

  TabAtkins: The question was what happens if specify for height
  TabAtkins: Initially tried to do something from an earlier attempt
             from dbaron
  TabAtkins: would increase height of item as much as needed to fill
             height of closest definite ancestor
  TabAtkins: This ended up being weird, potentially blows up further
             than you want
  TabAtkins: Took a resolution to make it behave like 'align-self:
             stretch' wherever that has a meaning
  TabAtkins: and in other cases, behaves like auto
  TabAtkins: but when editing in realized we could do most of what was
  TabAtkins: by treating similar to percentage height when percentages
             can resolved
  TabAtkins: So basically act like slightly smarter 100% (considers
             margins also)
  TabAtkins: wherever that's currently defined to resolve
  TabAtkins: and otherwise fall back to auto
  TabAtkins: no extra magic
  TabAtkins: Filling container when percentage could resolve
  TabAtkins: gives better abilities
  TabAtkins: this proposed behavior, acting like 100% minus margins,
             border, padding
  TabAtkins: Gives an expected and useful behavior for 'stretch'
             without causing the inflating behavior concerned with
  cbiesinger: This makes a lot of sense.

  AmeliaBR: If you did want the behavior of dealing with a couple
            parents levels of padding and borders, just describing
            each level as 'height: stretch', would that work?
  TabAtkins: Just as percentage resolved against definite size is
             treated as definite, stretch resolved against such would
             also be definite
  TabAtkins: would then follow up the tree

  cbiesinger: This is basically renamed fill-available keyword, right?
  TabAtkins: Yes

  astearns: Questions or comments?
  dbaron: I guess the one thing, the thing I originally proposed
  dbaron: for orthogonal flow stuff
  dbaron: somewhat different use case
  dbaron: it's a little weird
  TabAtkins: At least, I don't think we want that behavior by default,
             so don't think hooking it into 'stretch'
  TabAtkins: if we want that, maybe different keyword

  astearns: So proposed resolution is that height: stretch, when can't
            behave as align-self: stretch, will behave as 100% but
            accounting for margins
  <AmeliaBR> +1 for the proposal. Let's make this as useful as
  Rossen: Would it contribute to any other height sizing algorithms
          that aren't fixed?
  TabAtkins: What do you mean?
  Rossen: If this is just a block wrapped in a block...
  Rossen: grid item has behavior already defined
  Rossen: but block inside grid item is now simply defined by the
          closest fixed container
  Rossen: so if grid item is not fixed, then you have to propagate up
  Rossen: and stretch the size minus margins borders padding to
          whatever is in the further ancestry of that thing
  TabAtkins: That is explicitly what we are not doing
  TabAtkins: This just looks nearest container, same as percentages
  TabAtkins: it is exactly identical as 100%, but sizes margin box
             instead of content box
  Rossen: ok, then that makes a lot of sense

  <cbiesinger> nearest container -> containing block, I think?
  <fantasai> not exactly, e.g. <p><span><inline-block/></span></p>

  AmeliaBR: We have a few cases in CSS where percentages aren't doing
            useful things
  AmeliaBR: e.g. cyclic percentage contributes zero, resolves, lots of
            overflow, is bad
Scribe: dael
  fantasai: I think most of those cases where you have problems are
            those where percent isn't 100. If you put 50% you get
            weird overflow. If you put 100% these resolve ok.
  TabAtkins: Child of a float fills at 100%. There will be weird
             because margins/border/padding
  AmeliaBR: I had it in mind with weird percentages

  astearns: Other comments?
  astearns: Proposal: height-stretch behaves as even better 100%
  astearns: I have a concern
  astearns: Is it possible for modes that doesn't match to align-self
            we're in a corner?
  TabAtkins: This is meant to be same as align-self in those cases. If
             we didn't have that in grid and defined this it should be
             same. We anticipate extensibility.
  fantasai: Where align-self doesn't apply are cases where it doesn't
            make sense. You have a stack of things that are placed
            relative to each other. 'stretch' is not defined as whether
            align-self is implemented in that mode, but if it's defined
            to apply there per spec.
  astearns: Okay
  astearns: Objections to height: stretch behaves as better 100% where
            align-self: stretch isn't possible

  RESOLVED: 'height: stretch' behaves as 100% applied to margin-box
            where 'align-self: stretch' isn't possible

  <break type=30min>

Import aspect-ratio from child image
  github: https://github.com/w3c/csswg-drafts/issues/5269

  TabAtkins: Two big use cases people run into that make aspect-ratio
             not work how they want
  TabAtkins: In block layout if you have image with aspect-ratio and
             wrapper doesn't effect, but in flexbox or grid there is
             special code that is defeated by wrapper; Including link
             or picture element which are common
  TabAtkins: Request is for a parent element to get aspect-ratio from
             child but only if it has a single child with
             aspect-ratio. In all other cases acts like aspect-ratio
  TabAtkins: I don't think needs to grab other intrinsic sizes, but we
             can think about that. Flexbox only cases about ratio.
  TabAtkins: Some unanswered questions. What do you want to do with
             margins/borders/padding which change render size
  TabAtkins: We can probably resolve in further issues
  TabAtkins: General case to pull aspect-ratio from single child do
             people think this is reasonable?

  fantasai: Not sure we want to take from an only child. A lot of
            cases where we pull something like this where you grab
            first child. Whatever we do for grab info from child
            should be consistent. Not sure it should be check for only
            one child
  TabAtkins: I don't think SVG is useful for examples because it
             doesn't have layout. Further children don't affect. In
             this case if you have an element with image and fit
             caption if you take from image it's meaningless
  fantasai: You can have positioned caption on top of picture which
            makes sense
  TabAtkins: One inflow child then
  AmeliaBR: That's my point, one inflow child for case of figure with
            caption on top of image.
  AmeliaBR: I'm not sure what fantasai was thinking on SVG but I can't
            think of a case where it gets aspect-ratio from children.
            SVG in a CSS layout having these behaviors is useful
  fantasai: Not specifically aspect-ratio. I think some property in
            SVG grabs info from children
  AmeliaBR: title and description?
  AmeliaBR: Either way, need to think about would it be web compat to
            make this default change? We have lots of flex and grid
            layouts where if this was available authors would have
            loved but they have made adjustments and doing by default
            is problem
  AmeliaBR: Could make keyword for aspect-ratio property. On you
            picture element have an aspect-ratio from content that
            would have this special behavior
  AmeliaBR: If it's web compat to make it default where if you have
            one inflow child with an aspect-ratio container is
            aspect-ratio it would be great to be automatic.
  TabAtkins: I strongly suspect its not web compat. I'd like to run on
             that assumption that this is specific property; an
             aspect-ratio keyword that does it
  fantasai: Or some new syntax
  fantasai: New keyword or something else

  emilio: I was going to say behavior will be weird with applied
          whitespace. Children create boxes which can be collapsed or
          suppressed but that's optimization. Bit weird that
          whitespace around image this trick doesn't work
  TabAtkins: How weird if we did ignore collapsed whitespace
  emilio: Somewhat. I don't have strong opinions. Direction with
          single box is odd.
  fantasai: I would have said first child element
  Rossen: In doc order?
  emilio: Right
  fantasai: Yes
  TabAtkins: If you take first child element it excludes text.
             Non-whitespace text would be ignored too so should
             trigger no aspect-ratio
  <AmeliaBR> So… if the container has exactly one in-flow,
             non-collapsed-ws child box…, then `aspect-ratio:
             from-contents` works
  <fantasai> I think we can let the author not specify the keyword if
             there's other content they want to ignore

  <heycam> in SVG we did at one point discuss allowing properties that
           refer to elements by URL to have a "from-child" or
           something keyword, e.g. so you could do <path
           style="marker-end: from-child"><marker>. but that didn't
           really go anywhere beyond an idea. (might be fantasai is
           thinking about this)

  cbiesinger: I'm also concerned it's a lot of magic. A lot like
              emilio's comments
  cbiesinger: Have to be careful to not add something that will break
  cbiesinger: Use cases I've heard from webdev is they wanted
              aspect-ratio and they were happy. Didn't ask for this
  cbiesinger: Final thing, picture element should probably take
              aspect-ratio from img tag
  TabAtkins: I don't think just aspect-ratio is usable because of
             picture. Different source could provide different
             aspect-ratio and you can't easily predict
  cbiesinger: Getting aspect-ratio from child makes most sense
  TabAtkins: Don't see reason to differentiate between picture and a.
             Picture into link is common and easy and I would prefer
             it didn't break layout
  cbiesinger: Careful about line breaks between a and img
  TabAtkins: Unless we do something about collapsible whitespace
  fantasai: Collapsible whitespace doesn't generate box right?
  emilio: Maybe. In Gecko we don't when we can prove it doesn't have
          to. But we need to deal with it.
  TabAtkins: Unsure if it's clear if box is generated.
  fantasai: If it did it would interrupt margin collapsing.
  TabAtkins: Yeah, okay. Great observation. In that we observe this
             with margin collapsing should be able to observe without
             being particularly weird

  Rossen: Looking through issue this is mostly to introduce and feel
  Rossen: Sounds like some level of anxiety but also use cases which
          are supported.
  Rossen: What's next step? Work more for concrete proposal?
  TabAtkins: I was seeking if objections. Information is useful. We
             can put a proposal in spec and bring it to WG
  Rossen: Anything else on this?

CSS Images

image-orientation:none violates same-origin policy
  github: https://github.com/w3c/csswg-drafts/issues/5165

  heycam: We have image-orientation. Ignoring print processors it's
          used for authors to opt out of what we're moving to with
          EXIF orientation honored by defualt. It's really that EXIF
          orientation is impl detail on how image is represented in
  heycam: We have image-orientation: none which lets authors opt-out
  heycam: In Gecko and Chrome image-orientation: none applies to same
          and cross origin images
  heycam: Anne pointed out that applying to cross-origin it's a leak
          of one bit of info. For images cross-origin you can look at
          width and height. Because you can tell if it's re-oriented
          90 deg you can get an extra bit of info to know if image
          meta was one set of value or another
  heycam: Shouldn't add more leaks in theory. Perhaps arguable if it's
          super important if this makes a difference and weigh it
          against value for authors
  heycam: It's something to discuss

  TabAtkins: All this makes sense to me. image-orientation and the
             image resolution which you can observe via src set is
             info leaks. Way through is make cross-origin images
             behave like it's information was baked in so they can't
             turn off orientation. It would mean cross-origin would
             act as if exif was it's native orientation. Similar logic
             would apply to resolution where you could select correctly
             but it would act baked in
  TabAtkins: Regardless of how you look at image you get same data.
  TabAtkins: Sounds good, happy to adopt
  TabAtkins: Not sure if it's css or html but happy to figure it out
  fantasai: It think it lives in css-images.

  AmeliaBR: Support what TabAtkins said. One proposal in issue was do
            reverse where cross-origin ignores exif and I don't want
            that. Render it as the image format is supposed to be
            rendered including exif but don't make it inspectable how
            it was generated.

  cbiesinger: Two comments. Seems like angle is a possible value with
              same problem.
  cbiesinger: In response to TabAtkins I think a lot of websites are
              images from different host. Seems like not supporting
              would make chrome exif a lot less useful.
  cbiesinger: Don't have a good solution but it's not ideal
  AmeliaBR: This would be normal http cross-origin so if you have full
            control over cdn and can give correct headers that's one
            way to turn off exif
  TabAtkins: This should continue to work as normal for cdn but you
             wouldn't be able to turn exif off. It would always be on
  heycam: Possible you're using images from cdn and relying on
          orientation not being applied. I don't think there's
          anything special about images from cdn
  TabAtkins: In general our research has shown better for web if we do
             respect exif at all times
  heycam: I'm in favor of model TabAtkins describes. Had one person
          contact me where he would like it to continue to apply to
          cross origin because they have tool to present image and get
          user to annotate and then they hand over annotation to
          another tool. Without being able to tell the tool the
          orientation they can't tell if they have to process.
  heycam: They can work around that by fetching the image on the
          server side
  TabAtkins: Or proxy the image request to turn on cors stuff they'll
             be fine

  Rossen: Where do we go from here?
  TabAtkins: Unless there's objections proposal is do not expose
             orientation data from cross-origin images. Do it by
             having the masquerade as their exif orientation being the
  TabAtkins: 2 resolutions. One we want, one is implementation strategy
  Rossen: Proposal: Do not expose orientation data for cross-origin
  Rossen: Comments or objections?

  RESOLVED: Do not expose orientation data for cross-origin images
            by treating EXIF as native resolution

  Rossen: Question; for things like cloud functions are they
  Rossen: Cloud functions your source has an image call
  TabAtkins: Don't know but definition of cross-origin is stable so
             I'll rely on that. It's very precise and I don't want to
             manipulate it

  cbiesinger: Question is do we have use counter data for how often we
              have image orientation that's not from exif?
  TabAtkins: Don't think we do yet. We know in general honoring exif
             is the better way to go so even if there are cases that
             are specifically needing to care it's a smaller subset of
             the subset we consider is okay to break
  cbiesinger: Okay it's better, curious about how big the number is
  <cbiesinger> looks like image-orientation in general is only used on
               0.13% of pageloads so this is probably OK

  Rossen: Have the resolution on record. Add anything about impl
          direction or in the minutes is enough?
  TabAtkins: Minutes is enough
  heycam: Anne raised a separate issue about who defines this and have
          a spec which can be referenced. That's something for later.

Received on Monday, 3 August 2020 23:43:37 UTC