- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 2 Dec 2018 06:24:33 -0500
- 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