W3C home > Mailing lists > Public > www-style@w3.org > December 2018

[CSSWG] Minutes Lyon F2F 2018-10-23 Part II: Aspect Ratio, Shadow Parts, Grid L2 [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 2 Dec 2018 06:24:33 -0500
Message-ID: <CADhPm3u-kusLGAR6GYcOYWu+ps9Ajqb8HeZkPzWOc0cx1kjX6g@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Aspect Ratio
------------

  - There is a rough proposal to allow better management and
      understanding of aspect ratios in CSS:
      https://drafts.csswg.org/css-sizing-4/#ratios
  - The group was in favor of continuing to explore this more, either
      within the working group or within WICG.

Shadow Parts
------------

  - There was general consensus on the initial feature set for shadow
      parts had been agreed upon, so once the spec is cleaned up there
      will be a request for FPWD.

Grid L2
-------

  - RESOLVED: Rename AR to TR (Issue #3225)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: fantasai

Aspect Ratio
============

  jensimmons: There's been a longstanding desire for aspect ratio
              support in CSS
  jensimmons: Brought up not only because I brought it up, but many
              people around the world have been writing blog posts
              talking about this
  jensimmons: So fantasai drafted up some spec text last week

  jensimmons: Here's an example
  jensimmons: People are resizing their images in CSS, and width is
              being set to 100% and height to auto, and the image
              keeps its aspect ratio
  jensimmons: But some elements do not have an intrinsic aspect ratio
  jensimmons: e.g. iframe, article, etc.
  jensimmons: Some are replaced elements, some are not, but they don't
              have intrinsic aspect ratio so things get squished

  jensimmons: Why are people not using the video element?
  jensimmons: They're using youtube, vimeo, etc.
  jensimmons: because of adaptive bitrate streaming
  jensimmons: but it's a reality that's very important for supporting
              various network connections
  jensimmons: so videos in iframes are important
  jensimmons: Here's what happens when you try to resize the iframe:
              no preservation of the aspect ratio

  jensimmons: First solution of the industry was fitvids.js
  jensimmons: It's not a great idea
  jensimmons: Everything since has been using the padding hack
  jensimmons: Using the fact that padding in % is going off the width
              rather than the hack, and ppl exploiting that to get
              aspect ratio
  jensimmons: Only some ppl know about it, it's tricky to use...
  jensimmons: Would be much better to have something in CSS to solve
              this

  jensimmons: Our current thought is to use a property, 'aspect-ratio:
              16 / 9' e.g.
  jensimmons: This would cause the element to hook into all the
              existing rules that handle elements with an aspect ratio
  jensimmons: This is written up as a super rough draft in CSS sizing
              L4
  <astearns> https://drafts.csswg.org/css-sizing-4/#ratios

  jensimmons: Videos would be done like
  jensimmons: iframe { aspect-ratio: 16/9; width: 100%; height: auto; }
  jensimmons: Syntax of the property is coming from the Media Query
              syntax for aspect-ratio
  jensimmons: Idea was just to copy that syntax
  jensimmons: for consistency and also I like that


  jensimmons: So that's great, solve things like video in iframe
  jensimmons: But there are also other cases where we care about
              aspect ratios
  jensimmons: Let's say you want a bunch of squares with text in them
  jensimmons: In this example I used viewport units, but it would be
              nice to be able to just give an intrinsic aspect ratio
  jensimmons: Here's a use case
  jensimmons: We have boxes with different amounts of content in them,
              and we want them to have 2:1 aspect ratio
  jensimmons: Problem here is that in some cases there's too much
              text, and it overflows!
  jensimmons: Want to be able to say that "I want this aspect ratio as
              my min-height, if the box get bigger let it grow like
              usual"

  jensimmons: Two options in the draft
  jensimmons: Option A is to have a keyword of some kind which you can
              put in min-height to request from-ratio, and then say
              that the height is max-content
  jensimmons: article { aspect-ratio: 2 / 1; height: max-content;
              min-height: from-ratio; }
  jensimmons: Other possibility is to use 'ar' units, which come from
              grid L2 spec
  jensimmons: I would change the name, don't think 'ar' is the right
              name
  jensimmons: But basically it grabs the number of the corresponding
              property in the opposite dimension and multiplies it
  jensimmons: e.g. we have gaps in one side, the other side says 2ar,
              it'll be twice the width of the other-dimension gap
  jensimmons: So we could use those in the height properties, e.g.
              'min-height: 0.5ar'

  jensimmons: Going further, it'd be great if we could use attr() to
              grab the width/height attributes from the HTML and put
              it into the aspect-ratio
  jensimmons: This would solve a performance problem everyone wants to
              solve, to do layout before the image loads
  jensimmons: There's been a variety of proposals for adding new
              attributes to do this, but we could just use it with CSS
              by using attr
  jensimmons: e.g. iframe { aspect-ratio: attr(width px) / attr(height
              px); }

  <TabAtkins> https://github.com/ojanvafai/intrinsicsize-attribute for
              the HTML-based way to set intrinsic sizes/ratio before
              loading them.
  <TabAtkins> Still an early proposal, could use some feedback from us.
  <TabAtkins> (I've given some feedback, I think it's pretty decent.)
  <TabAtkins> (Ojan's proposal is *just* about setting intrinsic sizes
              of replaced elements that *already have* aspect-ratio
              information. Not directly intersecting with the
              'aspect-ratio' property.)

  gregwhitworth: I'm excited about this topic
  gregwhitworth: Prefer the aspect-ratio syntax from MQ
  gregwhitworth: We also did talk about aspect ratio in picture
                 elements
  gregwhitworth: I think we'd like an HTML solution because we want to
                 do it earlier
  gregwhitworth: but of course also in CSS too
  gregwhitworth: Interested in the other stuff
  gregwhitworth: We have a WICG thread under ? for aspect ratio that
                 has additional issues to think about that we should
                 think about
  <tantek> +1 I'm excited to see aspect ratio solved

  fantasai: In terms of adding attributes to HTML, we were looking at
            this, and thinking we can just do that using the existing
            height and width attributes
  fantasai: Currently, they link to the width and height property, so
            you lose their info when you set the css properties, which
            override
  fantasai: but we could change that, to make them also plug into the
            aspect-ratio property
  fantasai: so if you set width/height in css, you'd override the
            width/height from the HTML, but not the ratio
  fantasai: We might be be able to do that in a web compatible way
  fantasai: so before we add more to HTML, we should look into whether
            we can do that mapping into the CSS layer

  glazou: I really like that
  glazou: Two things I'd like to know
  glazou: First, when we have for some elements a placeholder to
          display until the element isolated from the network, we are
          going to have a change of aspect ratio
  glazou: So it would be good to detect that the aspect ratio is
          changing from some external source like the network
  <TabAtkins> (The point of doing *some* aspect-ratio things in HTML
              is, as Greg suggested, to be even more preloader
              friendly.)
  gregwhitworth: ....

  glazou: About your a) and b) proposals for the limits
  glazou: from-ratio won't allow partial values unless you allow into
          calc(), so I would prefer the unit
  <dbaron> I think I prefer option A over B, for being clearer, and I
           think we should eventually get from-ratio into calc()

  futhark: For the min-height problem, try min-max aspect ratio
  fantasai: We thought about it, but thought this was more
            straightforward and easier to understand
  fantasai: What's a min-aspect ratio? Would have to privilege one
            dimension over the other

  astearns: Might want to limit current discussion to concerns about
            whether to add to the draft
  florian: based on what you said, I'm happy to move this forward

  fremy: I would say that from-ratio seems way easier to implement
  fremy: ???
  fremy: Among the two solutions, an implementation perspective
         from-ratio is way easier
  fremy: That's all, not opposed to the unit
  fantasai: Note that this unit exists already for gaps, we're just
            copying that solution here

  krit: Should look at preserveAspectRatio attribute
  florian: I think parallel between preserveAsepctRatio is with the
           'object-fit' property in CSS
  florian: Some aspects of viewbox correspond to this
  florian: My first impression is that even if we add as properties
           the things that SVG already has
  florian: These things an this, have a shorthand-longhand
           relationship, so there's no conflict
  florian: We need to think through it but there's no conflict

  jensimmons: If you look at issue 333, I've dropped links to authors
              writeups on aspect ratios
  jensimmons: So we need to go through all that and make sure we've
              thought about those comments and ideas
  astearns: What about SVG?
  jensimmons: Sara Soueidan wrote up a blog post on viewport in CSS

  TabAtkins: I am in favor of doing this
  TabAtkins: I want to put it WICG
  florian: Let's incubate in the CSSWG like we always do

  astearns: I'm going to close the discussion at this point.
  astearns: It's break time

  <fantasai> https://www.w3.org/TR/2018/WD-css-grid-2-20180804/#alignment
  <fantasai> ar units ^

  <jensimmons> I posted the slides about Aspect Ratio being added to
               the Sizing Spec here:
https://noti.st/jensimmons/FnU3KJ/adding-explicit-aspect-ratios-to-css

Shadow Parts
============
  scribe: myles

  <TabAtkins> https://drafts.csswg.org/css-shadow-parts/

  TabAtkins: We discussed shadow parts in the past, fergal_daly worked
             closely with rniwa to figure out who we can get a
             consensus solution on some details. It went well, made
             many changes and feedback. Notable: we separated the
             naming of something as a part from forwarding something's
             parts up into your part namespace. They're now separate
             attributes. Changed syntax of part forwarding to match JS
             syntax for destructuring because it's the same. While
             it's easy to get confused about which name does what in
             JS destructuring, people only have to learn it once.
  TabAtkins: We're not exposing something new and novel. Functionality
             is the same - can expose chunks of shadow dom, can't do
             further structuring, can't grab a part of a part unless
             it's explicitly forwarded, can do ::before and ::after
             and other pseudo classes. There is still some discussion
             about ::theme, the thing that automatically exposes your
             parts arbitrarily up so they can be used from anywhere.
             Further discussion is ongoing but the core part, the
             ::part pseudo element and how to expose it appears to be
             reasonably agreed on by us and apple
  <astearns> github: https://github.com/w3c/csswg-drafts/issues/2368

  rniwa: There is consensus on the github issue. The 1 contentious
         part is the IDL attribute. For now we can add it and move
         forward. One question is because the topic of whether part
         applies to just the first element or everything? For theme,
         clearly all the elements with the theme should get the style,
         not just the first one. So the discrepancy there might be
         confusing. But on the other hand, the use cases are different
         it may be okay that only the first element gets the first the
         style
  TabAtkins: so it's treated like an ID?
  rniwa: It's a question. Let's say shadow root has 2 elements that
         have a part attribute, both say part=foo. Should both get the
         style? If the model is users are exposing an element to to
         outside to style, then it should be just one element. But if
         the model is more like the users define style for a part and
         the component takes it form the users and apply somewhere,
         then it makes more sense for multiple elements
  TabAtkins: Imagine a to do app. You want to expose for styling all
             of the individual to do items. You can give them the same
             part name and style them all, it works like a class. If
             you can only do one, each item would need a unique name.
  emilio: That's better. I prefer to style the style of elements to be
          independent
  emilio: Invalidation could be tricky. When you insert an element
          with a part element, you have to look for the same part name
          elsewhere in the tree
  rniwa: That's fine.
  rniwa: It's just a question. I don't know the answer.

  TabAtkins: The goal of the session is to confirm we have rough
             agreement on the feature set. Earlier there were more
             disagreement. So I don't think we're ready for FPWD now
             but we can adopt as official ED.
  astearns: I don't remember if its an ED
  TabAtkins: It's marked as an ED.
  TabAtkins: So we're pretty good. Comments?
  TabAtkins: Please raise issues.

  astearns: I suggest - the issue is a monster issue with many sub
            issues. If there's anything remaining, please move it to
            new issues. It's impossible to read.
  TabAtkins: ok.
  TabAtkins: We did try already
  fergal_daly: Please use existing issues
  astearns: Sometimes TabAtkins will move comments for people
  fergal_daly: I'll do that then.

  fantasai: What are you looking for before FPWD?
  fantasai: FPWD doesn't mean it's done. It means it's roughly
            sketched out
  fantasai: and we have consensus on the approach, but not details. We
            don't have to fix all the issues
  TabAtkins: It could be reasonable to do FPWD
  fantasai: If there are no major issues before FPWD and we all agree
            we want to do it, we should do FPWD
  fantasai: and continue work with more visibly public draft

  fergal_daly: Should we take theme out if we haven't decided on it?
  TabAtkins: I'd be okay.
  rniwa: It makes sense. We need to update the spec. The ED is
         outdated.
  rniwa: Remove the theme and the IDL attributes
  fergal_daly: IDL is already out.
  TabAtkins: yes.
  TabAtkins: Right now the only way to access parts is to get the
             attribute using the standard dom api

  fergal_daly: Is there controversy for adding IDL for part as opposed
               to part forwarding? That's useful for feature detection
  rniwa: No controversy. It's okay to expose part IDL attribute.
  fergal_daly: Okay I'll do that
  fergal_daly: and leave out the map stuff completely

  TabAtkins: It might be worthwhile to officially do FPWD in a few
             weeks.
  astearns: Yes, I'd like to see people sign off on the state of the
            draft before FPWD
  TabAtkins: ok

  fantasai: For extracting out the stuff we're not doing now, maybe
            throw that into Level 2
  TabAtkins: ok
  TabAtkins: We can incubate the theme attribute.

  astearns: Other comments?
  rniwa: Mozilla support?
  emilio: It's reasonable
  emilio: When people ask for feedback, the conclusion was it's worth
          experimenting. The current agreed on thing makes sense
  astearns: Edge signals?
  TabAtkins: Edge just agreed to do shadow dom, so we'll see you in 6
             months
  <gregwhitworth> I said that we'll take a look at the proposal and
                  provide feedback at a later date

Grid L2
=======

Rename 'ar' unit?
-----------------
  github: https://github.com/w3c/csswg-drafts/issues/3225

  jensimmons: There is an issue for renaming the AR unit
  jensimmons: It's in grid level 2. The use cases is if you're defining
              grid gaps, and are using alignment to increase spacing in
              one dimension and you want spacing in the other dimension
              to be an increment of the one in the first dimension,
              this unit lets you have a multiplier for the other
              dimension. It's similar to aspect ratios.
  jensimmons: I drilled aspect ratio math into my cells in my body in
              film, there's a way in those industries handle that
              math, the phrase aspect ratio triggers that mathematical
              model for those people, and this is different. So
              another name might be great
  florian: The confusion by calling it aspect ratio, once we have the
           aspect ratio property, if the property says half and you
           say 2x half, what does that mean
  jensimmons: What does "twice 16x9" mean
  jensimmons: With this measurement unit, you use the inverse fraction
              when you want to go the other direction, and there's no
              such thing in aspect ratio math

  florian: Idea: transfer ratio, transfer dimension. We're taking a
           measurement from somewhere and applying it somewhere else.
  rachelandrew: I like transfer size
  rachelandrew: it's descriptive
  florian: 0.5ts is half the transfer size?
  fantasai: Since it's a proportion, we have fr, so tr?
  fantasai: Other suggestions?
  fantasai: Rename ar to tr?
  florian: I like it better than ar, so let's resolve and make
           progress, but we may continue discussing later, but it's an
           improvement

  jensimmons: I don't know if I'm convinced about the r because it's
              not a ratio
  florian: The "r" is for "tr" for TRansfer
  fantasai: fr could be FRaction

  astearns: Is a design constraint that all units are 1 or 2 letters
  fantasai: It's easier to type
  fantasai: 7 letters is annoying
  astearns: yes

  glazou: Is an aspect ratio always above 1?
  fantasai: No
  glazou: Is 16/9 different than 9/16?
  fantasai: Yes
  glazou: Is a AR always above 1?
  florian: The convention is 16/9
  <jensimmons> well, there are many conventions in the film & video
               industries — many way aspect ratios can be defined.
  <jensimmons> 1.77 = 16x9 = 16:9

  fantasai: resolved??????
  astearns: feelings?

  heycam: Is transfer a term of art?
  heycam: it doesn't have a meaning in my mind
  fantasai: there's a transfer size in handling aspect ratios and
            other things. It's not exposed as term but it is used
            in the spec

  ericwilligers: why not fr?
  fantasai: A) you often have multiple fr units in the same dimensions
            and they take up segments of a total. This is a different
            concept, it's a multiplier to convert dimensions
            B) this could be used in grid track listings, where fr has
            a different meaning
  TabAtkins: fr means "Fraction of free space" which is a totally
             different thing.
  fantasai: It's not a generic ratio unit

  edent: Is there any user research on what people use when they refer
         to this?
  <tantek> see for example the iOS Photos app which shows a menu for
           editing aspect ratio based cropping with original | square
           | 3:2 | 5:3 | 4:3 | 5:4 | 7:5 | 16:9
  jensimmons: Yes, we haven't come across anything yet. In the film
              and video industry, this doesn't come up. They don't
              have this concept. So we're raising it to the group.
              Does anyone else know other parallel world where this
              exists? I will keep asking. Maybe font people?
  florian: We aren't convinced that it's the best name, but I didn't
           hear disagreement that tr is better than ar
  astearns: ok

  <heycam> 0.5or (for _or_thogonal dimension's value)

  astearns: objections?

  astearns: RESOLVED: Rename AR to TR

  RESOLVED: Rename AR to TR
Received on Sunday, 2 December 2018 11:25:37 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 December 2018 11:25:38 UTC