- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Dec 2017 20:19:23 -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.
=========================================
Meetings for the rest of 2017
-----------------------------
- Rossen will send out the proposed agenda for 20 December to garner
regrets and determine if there are enough people for a call.
- There will be no call on 27 December.
CSS Values
----------
- RESOLVED: Resolve to clamp negative calc unit values in context
and simplify as early as possible and then return the
clamped calc as a result of the computed style.
Selectors
---------
- RESOLVED: Change the name :focus-ring to :focus-visible.
Flexbox & Grid
--------------
- Rossen brought issue #2085 (https://github.com/w3c/csswg-drafts/issues/2085
| Choose a single option for resolving padding and margin
percent values of grid/flex items) to the call in order to get
more visibility and movement toward a solution.
- There wasn't a decision reached on the call, but rachelandrew will
make a blog post to garner from the community which behavior is
preferable.
- Most people expressed a desire to make sure that the same decision
is applied to Grid & Flexbox to keep them inline.
- As a part of this discussion several people have expressed an
interest in a permanent solution to the aspect ratio hack and
fantasai, TabAtkins, and gregwhitworth have all been looking
into writing some spec text.
Sizing
------
- There were many concerns that the proposal in issue #1865
(https://github.com/w3c/csswg-drafts/issues/1865 | Intrinsic
Sizes, Scroll Containers, and Grid/Flex Sizing) would cause
severe breakage.
- fantasai will go out and research if it will cause breakage and,
if the result is that there is no compat risk, there was
agreement that the proposal would be worthwhile to implement for
Flex, Grid, and Block.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Dec/0016.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
Manuel Rego
Melanie Richards
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Benjamin De Cock
François Remy
Florian Rivoal
Scribe: dael
Agenda & Process
================
Rossen: We should be good to get going.
Rossen: As usual, are there any extra agenda items or changes?
glazou: Is the discussion about short hands the deferred?
Rossen: I was asking which you were referring to.
glazou: The one about the shorthand impacting border image and that
it cannot set it.
Rossen: Do you have a GH?
glazou: I'm not sure I did. I mentioned it probably 10 days ago.
Last week because the different time astearns said it was
this week. No problem if it's not.
Rossen: I was hoping to see a GH or email that I can point to. It
would be good to give people a chance to get familiar. Can
we start with opening an issue in GH and then I don't mind
adding it to any call. Including this one if you insist.
<rego> it's on the mailing list
https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html
glazou: No, not this call, but I wanted it sorted b/c it's very
painful for web authors.
Rossen: Thank you. Any other extra items?
<glazou> Rossen https://github.com/w3c/csswg-drafts/issues/2108
Rossen: Should we have a call next week, 20 Dec?
Rossen: I'm asking because I believe we settled on no call 27 Dec
and I'm not sure the outlook for 3 Jan
Rossen: So 27 and 3 most likely not. So instead of discussing in or
out on the 20th I'll shoot a proposed email very early for
next week and it would be great to see the number of
regrets. Based on that we'll decide on if we should have a
call.
CSS Values
==========
Computed value of a negative calc unit that doesn't allow negative
lengths
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/434
Rossen: This was intro last week. We resolved to clamp as early as
possible, but not how to return computed values based on
this clamping. We wanted to hear about it from a few people,
one of them was glazou.
Rossen: That's the first topic.
Rossen: Is TabAtkins or fantasai on?
<TabAtkins> in.
fantasai: I'm on, but no computer.
TabAtkins: glazou didn't respond and I haven't had time to go
through and dig up previous issues. I'm fine resolving
now and waiting for complaints later if there are any.
Rossen: Let me get us on the resolve. Previously we said clamp
negative clamp as soon as possible.
astearns: We didn't actually resolve.
Rossen: Ah, thank you. So we didn't resolve. But there was consensus
on clamping as early as possible, right?
TabAtkins: I believe so.
<glazou> apologies I completely missed the RFI on that issue
Rossen: Proposal is negative calc units are clamped as early as
possible
fantasai: per value or per prop?
Rossen: I believe per value.
fantasai: That was key question, per property or per value.
Rossen: I assumed it was per value and if it was given to the
property it inherits.
astearns: Yes, it was definitely per value.
TabAtkins: mmhmm
Rossen: Right.
Rossen: So the consensus was to try and clamp those as early as
possible. There was not consensus on how to return computed
values. as calc with negative value inside or return the
clamped value.
Rossen: So we could resolve on clamping and leave serialization out.
TabAtkins or fantasai preference?
TabAtkins: That's fine with me. The question was if you have a calc
that's 50px-2em and that's negative at calc time do we
simplify to calc(0px) rather then keeping the original.
I'm fine simplifying the internal of the calc to the
clamped value. I think that's what dbaron wanted.
<gregwhitworth> so calc(0) rather than 0 or calc(<N> - 2em)
dbaron: I think clamping and simplification should go together. If
we're clamp we should also simplify.
TabAtkins: That happens already, we collapse units together. But if
we have units that we know will be clamped is the topic.
dbaron: When you can resolve between px and em and know it's
negative I think you also simplify to px.
TabAtkins: I'm fine with that.
Rossen: And the serialized value is whatever the clamped value?
TabAtkins: With a calc around it.
Rossen: Other opinions?
* glazou is fine with resolution
Rossen: Objections on resolving to clamp negative calc unit values
in context as early as possible and then return the clamped
calc as a result of the computed style.
RESOLVED: resolve to clamp negative calc unit values in context as
early as possible and then return the clamped calc as a
result of the computed style.
dbaron: We're saying clamp and simplify.
TabAtkins: Some simplification is speced. This is collapse all units
together that can be figured out. So we'd collapse em
with px etc.
fantasai: You have to do that for inheritence to work.
TabAtkins: Yeah.
<TabAtkins> Right now we already simplify calc(1px + 2px).
Resolution is to also simplify calc(1px + 1in) at
computed/used value, and things like calc(1px + 1em) at
the point where that's possible.
RESOLVED: Resolve to clamp negative calc unit values in context and
simplify as early as possible and then return the clamped
calc as a result of the computed style.
Selectors
=========
Rename :focus-ring to :focus-indicator
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2036
bkardell: :focus-ring is what the mozilla folks used on early
prefixed impl. When we said we'd adopt we carried the
name, but most documentation use a different name and it's
frequently not a name. In practice the name was confusing.
We proposed focus-indicator which matches most doc, but
there were worried that sounded more like a pseudo element
TabAtkins: One of the obj from Alice to focus-ring is people think
it's a pseudo element styling the ring and if that's the
confusion then focus-indicator just genericized the noun
since we name the thing shown not the quality of the
element.
bkardell: That's a fair other observation. I think focus-visible is
what people on GH seem to have gathered around and there's
a standing pull request with that.
Rossen: So I guess the current runner is focus-visible
<tantek> I reviewed https://github.com/w3c/csswg-drafts/issues/2036
and :focus-visible makes sense to me per Tab's arguments
about noun/thing vs. state of thing
bkardell: Yes and there's an outstanding PR so we can just accept
that.
Rossen: I'm sad focus-pocus isn't it, but focus-visible is good.
<fantasai> wfm
TabAtkins: I'm fine with focus-visible
Rossen: Other opinions?
RESOLVED: Change the name to :focus-visible.
Flexbox & Grid
==============
Choose a single option for resolving padding and margin percent
values of grid/flex items
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2085
Rossen: I'll intro this, but I'm also going to timebox this. We've
beaten this down in the past quite a bit. We've stated
differences already openly. I think the current GH captures
a lot of this.
Rossen: I want to recapture the topic and I'm speaking as an Edge
implementor on this.
Rossen: Base of the problem is that we have a spec that defines 2
different models of resolving percentage values for margin &
padding top/bottom.
Rossen: They are spec for flexbox and grid to either resolve
percentage against inline direction and that matches with
block behavior.
Rossen: Other proposed/defined behavior is keep everything symmetric
and resolve top & bottom in the same axis as the height and
width and those resolve in the respective block direction.
Rossen: I expressed the differences between flex and grid from our
PoV. In this case I am a proponent of keeping flexbox and
grid as close as possible. I wouldn't push for that
principle on this, but I wouldn't be opposed. Flex is mostly
a single dimensional layout where we distribute empty space
in block or inline direction.
Rossen: In the vertical case that's a lot closer to block layout.
Rossen: Grid has always been 2d layout and we have attempted to keep
everything as symmetric as possible when we worked on this,
even internally at MS. That was a key principle. Everything
is resolvable and symmetric to the extent where things are
computable.
Rossen: This has been our behavior since the original grid. Later
Gecko & FF caught up with grid and flexbox. At this point
the blink and WK impl caught up with grid and the opposite
for the inline direction % resolution was proposed/accepted
b/c of those impl and the strong argument at the time was
that people were trying to use % padding aspect ratio hack
for grid items.
Rossen: And here we are today.
* fantasai is very strongly opposed to making Grid and Flex differ
on this point. Otherwise defer to Jen & Rachel.
<astearns> my understanding (I might be wrong) is that people are
only complaining about this for Grid, not Flexbox. If
that's the case I'm less concerned with keeping Grid and
Flex the same
<TabAtkins> astearns I would hard-object to having Grid and Flexbox
act differently, unless there's *strong* web-compat
reasoning for it.
Rossen: Thanks to people from Igalia we have data that suggests
current usage of those properties as % has increased after
we had a wider release of grid. That, looking a the numbers,
is at least 2-4x higher.
<rego> just a clarification, the jump in the metrics is unrelated to
grid shipping, it was a change in the way to measure use
counters in Chromium
<rego> > Note: on 2017-10-26 the underlying metrics were switched
over to a newer collection system which is more accurate.
This is also the reason for the abrupt spike around
2017-10-26.
Rossen: The reason I'm bringing this up is we're starting to see
non-interop content. There are broken webpages due to this.
Rossen: I'll give you an example of this where content looks broken
on seemingly normal wordpress sites.
<Rossen> http://www.gpkafunda.com
Rossen: I'd like L1 of grid and flexbox with just one behavior so
that we're not introducing more breakage.
Rossen: That's everything I want to say.
Rossen: At this point the higher order importance is that we have
interop on those basic layouts that will be adopted more and
more.
Rossen: I'd like to hear from Chrome folks if there are additional
opinions or data.
TabAtkins: Nothing that hasn't been said a year ago when we first
had to introduce the undefinedness of this. We cannot
change behavior of blocks, it should have been symmetric.
Only reasonable use of % is the aspect ratio hack. Even
though it's weird, being consistent with block seems
easier for authors.
<tantek> FWIW "consistent with block" on one hand, "consistent with
positioned elements" is the other.
TabAtkins: Ultimately I don't care, I want consistency. We're split
in half. Once 3 browsers converge we can change the spec
to that. I don't want to change until someone bites the
bullet and changes behavior.
<rachelandrew> I'm having trouble with audio (on hotel wifi) but I
noted in the issue my thoughts previously
Rossen: Would FF or Gecko be willing to change to match Chrome?
dbaron: I don't know off the top of my head.
dbaron: I'd need to look into history.
Rossen: Our position is we want interop. We're more willing to
change now that grid is impl everywhere (which is awesome).
Rossen: One thing I want to throw out is there was another possible
solution proposed a couple years ago by myself in NY to
entertain the idea of a switch to resolve % in one way or
the other based on the container itself.
Rossen: It took me a couple of days to make a prototype and make it
work. That's another potential way forward.
Rossen: However I said I'd timebox. I don't want to force a decision
on this call. I really want to see grid L1 and flexbox have
a single defined behavior on that.
Rossen: Also, I know rachelandrew is having audio issues, but she
offered to write a blog post. It would be great to hear what
the community has to say.
<fantasai> +1 to blog
<rachelandrew> I'll write up something in the next couple of days
once I'm back in the UK
Rossen: To close the topic, does anyone else want to say anything?
tantek: I want to call out what I thought is new is it appears
there's consensus on developing an actual solution to the
aspect ratio hack. I see more interest on developing that in
this issue then I remember previous interest.
tantek: In the hope of making progress on something with consensus
I'd like to see the folks with proposals for that use case
to post them in a separate issue.
fantasai: TabAtkins and I are planning to spec it for sizing L4 once
L3 goes to CR.
tantek: That would be great to see. I just wanted to call that out.
I don't know if there's other new information.
Rossen: That's great. gregwhitworth has been working on that from
our end too so you might want to loop him into that
discussion.
tantek: +1 to gregwhitworth
<TabAtkins> +1 for developing a non-hacky aspect ratio thing
Rossen: Anything else? If not we can continue after rachelandrew
blogpost.
Sizing
======
Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1865
Rossen: fantasai can you take this?
fantasai: This was the issue about when you have a flex or grid item
and inside it there's really wide content that has
scrollbars.
fantasai: When you put this inside a flex item it triggers the impl
min size which looks at min-content size. Usually it's on
the smaller size, but for something like this it could be
really really big. Bigger then you expect, esp if you have
scrollbars in there.
fantasai: But you don't get scrollbars because the ancestor asked
for the min size.
fantasai: This is causing a lot of author confusion because some
ancestor is making it blow up. The work arounds are not
super obvious.
fantasai: Suggestion when there is an overflow scroll the
min-content contribution should be 0.
fantasai: That would prevent this from happening.
fantasai: There are some compat restrictions. For now proposal is:
a) don't do this to a block in the block axis and b) don't
do it for blocks that have overflow: hidden b/c that's
often used to create a flex-root
fantasai: If a box has overflow not visible and not hidden and it's
a block in the inline axis its min-content contribution
assumes 0. If it's a flex or gird item we do that for any
value of overflow that's not visible in both axis.
fantasai: We believe this would solve most cases. The fix if it's
too small is to apply a min-width which is a fairly
understandable fix.
Rossen: Thanks fantasai.
dbaron: This sounds like a substantial change to existing behavior.
fantasai: Yes.
fantasai: On flex items and grid items probably won't be too
surprising. Applying to blocks...if you have a scrollable
block and you're expecting inline size of that block to
control the size of its ancestor by sizing so it won't
scroll, then your layout would change.
fantasai: We can split into two parts, do for grid and flex and can
we do for block.
dbaron: If you do it for one but not the other you're changing from
one concept of min-content size to 2.
fantasai: Min-content contribution. We already have special behavior
for flex and grid when overflow is visible. This is
implying the same thing where we don't consider the
content for min-content contribution.
dbaron: Isn't this non-local? It's arbitrarily deep descendants.
fantasai: No. This is if a particular element is flex or grid and
has overflow not visible we don't look at its content when
looking at its own min-content contribution.
fantasai: We're assuming 0 for the purpose of calc the min-content
contribution of that item and this will fix the ancestor
issue.
dbaron: Only if the descendant is flex or grid.
fantasai: Yes. That's part 1. Part 2 without would apply to regular
block would fix it for block. But it's a local effect, to
fix the action-at-a-distance problem.
dbaron: Seems like you're saying the compat thing only solves half
the problem. Given how widely flex and grid are used I'm not
sure part 1 is even web compat.
Rossen: Certainly not for flexbox. I'd be more concerned about that
then grid at the moment, but definitely concerned about
flexbox.
dbaron: Any sign that impl are not interop?
Rossen: I don't believe so. fantasai ?
fantasai: I don't believe so either.
fantasai: I think the behavior is more in line with what authors
expect. When then set it to be scrollable you don't expect
it to force the ancestor to give enough space for you not
to scroll. I think this would make flex and grid more
intuitive to authors.
dbaron: I don't think we can change without more evidence it's safe.
fantasai: Fair. I guess we can discuss if we want to change if
possible, then we can look and see if it's possible. Not
make the change until there's more data.
dbaron: My gut is it's not safe and therefore not worth exploring.
Particularly the half change doesn't seem sensible.
fantasai: The thing is the only case...for a block element by itself
inside a container you can size it with %. For block
elements they're in a flow and they'll take their auto
size. The effect in that axis...we don't distinguish
between max and min content in the block axis. If we try
and apply to a block in a block axis we have to introduce
this concept and then have the min and max calc
differently.
fantasai: You have a set of blocks and they have a min and a max
size and you have to calc layout twice to get the min size.
dbaron: I'm not worried about block axis part. I don't agree with
these concepts existing in the block axis. It's the not
doing it for block, just for flex and grid, that's the half
change.
fantasai: Ideally I'd like to do both, yes.
Rossen: And the second part is a lot scarier meaning doing both
would be a lot harder.
Rossen: This is going to sizing right or flex and grid?
fantasai: Sizing
fantasai: In terms of collecting data, that's a project but I'm
willing to try and work on it b/c this issue is causing a
lot of problems for authors.
Rossen: Can you point to some of the confusion?
fantasai: There's a bunch of websites trying to explain the fix and
the fix isn't obvious.
fantasai: There's a pre several items deep that's causing this and
it's not obvious and it's getting exploded. And the
explosion is a min-width so even setting a flex-basis it
won't flex the way you expect.
Rossen: Do you want a resolution?
Rossen: More support to work on it? Sample interest?
fantasai: What I've gotten is we want more data on if it's
compatible. I'd like to know if the web compat comes back
as no problem, would people want to make this change? If
the answer is no there's no point in getting data.
Rossen: As an Edge impl, the impl itself won't be that difficult so
if you're probing to see how impl this it, it is fairly
doable. But I'm fairly concerned with breakage, I'm
sympathetic to dbaron's case.
fantasai: And the point is collect data. But if we get data that
says it's okay, would you accept the change? If you still
don't like the change we've wasted the time to get data.
Is it worth it to collect the data?
Rossen: Okay. If anyone wants to push back on any reason other then
interop concerns, this is your chance.
gregwhitworth: While people think, I want to loop back and say we
solved a similar problem for tables. I'll link to the
minutes. We hit a similar problem where we have this
very scenario.
<gregwhitworth> https://log.csswg.org/irc.w3.org/css/2017-08-03/#e843776
gregwhitworth: I personally feel there is enough there. I'm not sure
if it's worth gathering data. We have compat issues
with the inverse.
fantasai: What you're saying is we had an issue with a direct
descendants of the table which has scroll does not
contribute it's min-content. It was 0.
gregwhitworth: Yeah, it's floored out. The layout is done and then
Chrome fills out. In Edge we give it the 100% and
then the accept term of service ends up offscreen.
fantasai: That's an example of us having to make for compat reasons
the fix being proposed. This proposal is doing that same
kind of fix more generally.
fantasai: Same use cases.
fantasai: Concern for data wasn't if we needed use cases to see if
there's author want, this was to see if we can do it
without breaking the web.
gregwhitworth: To answer the question better, if there's positive
use cases showing people want this and you bring back
data saying it wouldn't be a problem, I would be
shocked if people pushed back.
Rossen: I also said that impl % resolution for padding was easy for
us and it wasn't for others. I'm only speaking for Edge.
fantasai: My understanding is because it's a local effect it's just
a switch on when computing the min-content not to do some
extra work. I don't think it's generally difficult to impl.
Rossen: We're pretty much top of hour. For fantasai to proceed we
need to hear there are not strong objections. Most people
are worried about interop. gregwhitworth pointed out some
issues where people need the opposite for tables which would
bring more arguments against making it for blocks.
fantasai: gregwhitworth's argument pointed out people are having
this behavior for specific tables. It's a point in favor
of people expecting the proposed.
Rossen: Okay.
Rossen: I'm not hearing any objections. fwiw continue with this.
fantasai: So the conclusion is we expect to accept the proposal if
fantasai can get data that's it's webcompat.
Rossen: Yes. I think going to the step of data is worthwhile.
dbaron: I would hesitate to accept the half proposal, though.
Rossen: +1 to dbaron
fantasai: We expect to accept the full proposal if fantasai can get
data it's web compat.
Rossen: I'll send the rest of the agenda to get how many regrets for
next week.
<dbaron> I think we'd want to know who would the first implementor
of the change would be, though.
Rossen: Thanks everyone.
Rossen: If we don't have a call, I wish everyone an early happy
holiday, safe travels, and we'll talk next week or next year.
Received on Thursday, 14 December 2017 01:20:23 UTC