- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Jan 2018 20:09:50 -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.
=========================================
Grid L2 FPWD
------------
- The request for FPWD was deferred to next week in order to allow
time to review the ED. Proposed draft is available here:
https://drafts.csswg.org/css-grid-2/
FXTF - Geometry
---------------
- RESOLVED: Remove no interface object from geometry interface.
(https://github.com/w3c/fxtf-drafts/issues/233 )
FXTF - Filter Effects
---------------------
- RESOLVED: Add a second param to blur() in L2 of filter-effects.
(https://github.com/w3c/fxtf-drafts/issues/229 )
- RESOLVED: Allow filter functions to work without params. Drop
shadow aside arguments on filter functions will be
optional. sepia, grayscale, and invert it would be the
complete effect and for the others no effect.
(https://github.com/w3c/fxtf-drafts/issues/1 )
FXTF - Masking
--------------
- RESOLVED: Create an ED for Masking L2.
- RESOLVED: Put mask-position-x/y into the Masking L2 draft.
Flexbox & Grid
--------------
- Rossen informed the group that Edge intends to change their
implementation for padding and margin percent values of grid/
flex items to align with the Webkit/Blink implementation.
- He believed that the group should now consider resolving to one
behavior in the specs (Issue:
https://github.com/w3c/csswg-drafts/issues/2085 )
however the Firefox team will review their plans internally
before resolving.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0100.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Thierry Michel
Myles Maxfield
Michael Miller
Anton Prowse
Manuel Rego
Melanie Richards
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Liam Quin
Florian Rivoal
Greg Whitworth
Scribe: dael
astearns: Let's get going.
astearns: FPWD for Grid 2 was added to the agenda.
<fantasai> related to FPWD is https://github.com/w3c/csswg-drafts/issues/1116
astearns: Anything else to add?
Rossen: I wanted to add if we have time to ask on the padding and
margin % issue for grid and flex. If not we can discuss next
week.
astearns: Let's do that after fxtf priority issues.
Rossen: That's fine.
Grid L2 FPWD
============
astearns: We have content thanks to fantasai. A bit of the subgrid
properties.
fantasai: Grid 2 proposal has had the subgrid text that was removed
from L1 and per axis sub grid. I've added a diff against
grid. I've integrated the duel axis proposal into the main
body. That's what in the draft.
<fantasai> https://drafts.csswg.org/css-grid-2/#alignment
fantasai: There's a 2nd section that's aspect ratio controlled
gutters. Highly desired. When you have justify content
setting your gaps to take whatever is left you want the
same amount of gap in the other axis, but there's no way
to say that. This proposal will add a number to
align-content adjust where you can take what is in the
other axis.
fantasai: Do we want this also in fpwd?
Chris: If we can get the stuff into fpwd that's good because we get
patient out because elsewise we have to wait until CR for
legal review. I prefer as much as possible in fpwd.
Rossen: I haven't had a chance to review the stuff that came out of
grid 1. This isn't an ED yet. I think we should do ED first
and then do FPWD. I'd prefer first level doesn't have added,
at least not until we can review.
Rossen: I would support fpwd in the form we agreed on in Tokyo. I'd
be fine with that. Then if we need to add anything else we
can do that.
astearns: It is an ED in our repo and it is in grid 2
<Chris> fair enough, if there is not consensus on a feature it
should not be in the fpwd
<Rossen> https://drafts.csswg.org/css-grid-2/
Rossen: I'm looking at the one in css drafts ^
fantasai: What we have is an outstanding resolution to publish
subgrid as fpwd with the per axis proposal in as an issue.
Only question is do we want the gutter stuff as well.
Rossen: And that's what I was commenting on.
astearns: You'd prefer not gutter?
<tantek> +1 to including the gutter stuff
Rossen: Not in first public.
Rossen: Or at least we'll need time to review and go from there.
fantasai: That's fine.
Rossen: I haven't had a chance to review.
<rachelandrew> +1 to include the gutter stuff
astearns: Chris point is reviewing and getting commitment at fpwd is
preferable to putting in later and only getting legal at
CR.
Rossen: Yes and to do that we have to review.
fantasai: We can come back next week if that's easier.
Rossen: Sure. I cannot vote yes right now today.
tantek: Understandable
<Chris> rossen, how long to review (a week, a month ...)
<Chris> to clarify, if we don't have consensus on features I am fine
with a fpwd without them.
astearns: To complicate things I'd like the styling grid area stuff
in too.
fantasai: I would too but that's much more complicated. We should
continue to work, but until there's a solid
proposal...this stuff is a lot more ready to go. There
isn't a whole lot here and it could go quickly. Subgrid is
the #1 thing we need to fix. It's needed and an a11y issue.
fantasai: Then for the styling I would want to work on that but it
involves pseudo elements and more interactions and there
isn't a solid proposal. Therefore I don't think it should
go in here, it would hold everything else up.
fantasai: If there's a solid proposal I'm happy, but I want to get
subgrid to CR in 6 months.
astearns: I have not heard anyone is actively working on impl
subgrid. So taking it to CR without impl starting is
premature. If I'm wrong, I'd be happy.
<Chris> alan +1
Rossen: There will be a lot more interest from impl on subgrid to
address all the issues fantasai raised, especially a11y
where the styling is just another feature.
tantek: First, I'm okay waiting a week if that's enough time for
Rossen. Rossen is that enough time to come up with
objections?
tantek: That's what I understood.
tantek: Second: A lot of the feedback that caused us to move subgrid
out was from Mozilla so you can count that as impl interest.
tantek: Once we have fpwd the momentum will build and I'm hoping for
additional impl interest
astearns: Let's take a week to allow Rossen and others to review and
do fpwd next week.
CSS Fonts 3
===========
Default feature list should not require a list of features to turn on
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1267
myles: I closed the issue no change.
Chris: Okay, because an hour ago I was arguing osx was wrong.
myles: We can take it offline, but no change.
FXTF
++++
Geometry
========
Update WebIDL definition(s) to use new mixin syntax
---------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/233
astearns: First is WebIDL definitions?
<krit> https://www.w3.org/TR/geometry-1/#DOMRectList
krit: Yes and this is geometry interface modal. It doesn't have an
active editor. The spec removed the no interface term and
therefore all interfaces need updating. Usually no interface
was used for mixins.
krit: In the future authors should always use sequences of DOM. The
question is why it's a no interface in the first place. The
suggestion was to remove the object.
krit: Done in Firefox already.
krit: My guess is we didn't want JS to create new DOM rec lists with
this.
krit: WebIDL pointed out it should be safe to remove it. I'm asking
for approval to change the spec and remove the no interface
object from the spec.
astearns: Obj/comments to removing no interface object?
Chris: sgtm
<frremy> sounds good to me
<Rossen> +1
RESOLVED: Remove no interface object from geometry interface
Filter-Effects
==============
blur() to take two parameters
-----------------------------
github: https://github.com/w3c/fxtf-drafts/issues/229
krit: Currently takes one argument, proposal is to take 2 so you can
blur in horizontal and vertical with a different setting. I
think this is good, but browsers don't impl. Move to level 2
or are browsers interested?
krit: I propose moving it to L2.
Chris: Agree. Since they all do 1 param it's better to move it and
get impl interest first.
smfr: I agree. For webkit I'm happy to impl it in L2.
krit: Maybe we can also resolve to put it into L2?
astearns: Do we have a L2?
krit: Yes.
astearns: Great.
astearns: Objections to adding a second param to blur() in L2 of
filter-effects?
Rossen: What was the only impl?
krit: There is none. It's a proposal from a dev.
Rossen: Okay.
dbaron: One thing to do is if it's in L2 to point out it's the new
feature in a list that's elsewise the same.
krit: It's already a diff spec so yes.
RESOLVED: Add a second param to blur() in L2 of filter-effects.
CSS Masking
===========
Add mask-position-{x,y}
-----------------------
github: https://github.com/w3c/fxtf-drafts/issues/103
krit: One property at the moment. There was a proposal to add -x and
-y. It's in webkit, I believe. Request was to spec. We agreed
to align as much as possible to background spec. If background
won't do position-x and -y then mask won't. Same for
mask-repeat.
fantasai: Background-position-x and -y is in L4 which isn't fpwd but
it was resolved to add.
krit: and repeat?
fantasai: I don't think so.
krit: Then since this is CR it's probably best not to add yet.
<Chris> agree, better not to add them *yet*
fantasai: I think we had a discussion about repeat and we weren't
going to add unless required for compat since there wasn't
a use case.
krit: My concern isn't them having it, but how we handle for masking
spec. Since the spec is in CR I don't want to add features
that aren't in L4.
<Chris> yeah it is more alignment between masking and backgrounds.
fantasai: I would agree. Adding mask-position-x and -y to L2 might
make sense. L1 should stay.
krit: We don't have a L2 yet. Should we wait or create the L2
already and put the properties in there?
astearns: I have a question about background-position-x/y. Have
blink and webkit already impl it?
krit: As far as I know yes. For mask it was a webkit prefix.
astearns: Right.
<smfr> https://webkit.org/css-status/?#?search=background-position
astearns: For myself I would like to have a next level of masking
with these features since mask-position-x/y is in a couple
engines and maybe a third.
krit: Then we need to resolve to have level 2 and then move it.
astearns: I think first step is have a resolution to put it into the
next level. Once an ED has these features we can have
another call.
<Chris> +1 to ED
krit: I wasn't asking for fpwd, just an ED for L2.
<AmeliaBR> +1 to having a level 2 of Masking
astearns: Fair.
astearns: Any objections to creating an ED for Masking L2?
RESOLVED: Create an ED for Masking L2.
astearns: Objections to putting mask-position-x/y into that draft?
RESOLVED: Put mask-position-x/y into that draft
Filter Effects
==============
Make grayscale() work without parameters
----------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/1
AmeliaBR: The shorthand functions as currently defined all have
required parameters. For the one prompting this, though it
applies to a few, to get a grayscale filter you have to
say 100%. That wasn't how it worked in webkit prefixed and
when I checked it last June even without the prefix safari
& chrome support a number of functions without param.
AmeliaBR: Confusing part is the way the functions are defined in
some there is an obvious do this all the way, like
grayscale(100%) is all the way gray scale. Other functions
have two possible directions. You can make something
lighter or darker. For those 100% is no effect.
AmeliaBR: That's the baseline and you need more or less than 100%.
<Chris> Agree with AmeliaBR grayscale() equivalent to
grayscale(100%) and same for sepia and invert
AmeliaBR: I think that's why this spec was defined as it was. For
the effects like grayscale where there is a clear apply
this completely it's a nice author convenience to not have
the 100% on grayscale. We also have existing differences
in impl.
krit: I'd like to add webkit and blink do support none arguments for
everything except drop shadow. It's convenient to have no
argument for some functions. The other kinds of functions if
you don't specify it's no effect. If there's no value for
opacity you don't get opacity
krit: Do we agree sepia, grayscale and invert don't need a scale and
would result in complete change. And if yes do we want the
others to not require a param is that no effect?
Chris: It seems obvious that if there's no param it does the obvious
thing. Only down side is the knock on items for
interpolation. It's not clear that's been sorted, but if we
can do that yes.
AmeliaBR: I've never tested safari and chrome for transitions. I'm
assuming they treat grayscale no param as 100%. There
would be text about serialization.
leaverou: I would agree to sensible defaults. I seem to recall being
confused on grayscale no param, but I just tried it on
chrome so perhaps it's been fixed.
<smfr> animations work: https://codepen.io/smfr/pen/PEvZwb
krit: Also possible to keep as is on L1 and think about good options
for L2.
krit: To Chris we think about different initial for normal and
interpolation so differing between two initial values is fine.
smfr: I'd prefer we spec L1 in terms of what browsers impl. So I'm
fine having no arguments in L1. I don't think animations would
be a problem, so I don't see anything tricky there.
<fantasai> +1 to smfr
krit: Only webkit and blink support without arguments with the
exception of drop shadow.
smfr: But if spec requires arguments there's compat issues. It seems
harmless to allow no arguments then require and later on allow
optional.
fantasai: I would agree we should allow no argument where there is
an obvious default. I'm less convinced for all the others.
AmeliaBR: I think it would be best to resolve soon because we do
have browser issues. If the end is allow some and not
others I'd like to see impl match asap.
AmeliaBR: Otherwise...right now the other ones are no effect
independently but if they're in a filter list, like a
transition, there's a question as to if that's a valid
parsing sequence. You could suddenly break a site so we
want to resolve asap.
krit: And it's a question if safari/webkit and blink are willing to
change if we change requirements.
smfr: I think that's too much of a compat risk.
krit: In this case it makes sense to make arguments optional and we
need to decide what happens for those that it's not obvious.
Most are no effect. Brightness it will use 0 and I'm not sure
that's preferred and if content relies on that.
krit: smfr would you be willing the change brightness to no effect
if there's no argument?
smfr: I don't know. I'm not sure if brightness [missed]
* fantasai agrees with krit
AmeliaBR: Logically brightness should behave like contrast or
saturate because you can increase and decrease. Brightness
100% is no effect. I'm not sure why no param as 0 was impl.
<fantasai> +1
smfr: I don't feel too strongly. But brightness without arguments
doesn't seem common.
krit: Would you change brightness w/o arguments to no effect?
smfr: I think so.
* bradk agrees with AmeliaBR
krit: Drop shadow aside we agree we'd have arguments on filter
functions be option. sepia, grayscale, and invert it would be
the complete effect and for the others no effect.
smfr: sgtm
astearns: Objections?
RESOLVED: Allow filter functions to work without params. Drop shadow
aside arguments on filter functions will be optional.
sepia, grayscale, and invert it would be the complete
effect and for the others no effect.
astearns: Chris added a needs test case.
krit: Agree
astearns: fxtf issues #221 and #178 need people who understand color
to look. Please do.
CSS
+++
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: We discussed ~1 month ago. I raised it before we locked down
flexbox and grid. I wanted one behavior for resolving the
block level padding and margins. Current spec allows to
resolve those from corresponding inline or block axis.
Rossen: In a little more css 2.1 terms top and bottom margins
resolve to either height or width. FF and Edge impl that we
resolve from the same direction as the padding and margin.
Webkit & Blink impl the similar behavior to block. They
resolve from width. That enables the hack to have the aspect
ratio on elements other than replaced.
Rossen: We've gone by for a couple years. Now that grid usage is
picking up we're seeing pretty bad compat issues
<Rossen> https://www.bloomberg.com/pursuits/travel
<Rossen> https://thepeachtruck.com/blogs/the-peach-truck-kitchen
<Rossen> https://maps.google.com/localguides/event/summit
Rossen: ^ here's a couple. If you have FF or Edge you can compare.
Rossen: A month ago we left that rachelandrew would write a blog.
She did. Thank you.
Rossen: We got back quite a bit of opinions. They are kind of split.
To summarize about 1/2 the people want to be able to spec on
value and expect that padding and margin is the same.
[Rossen lost audio]
<fantasai> https://wiki.csswg.org/planning/berlin-2018
fantasai: While we wait. If you're planning to come to Berlin please
put yourself on the wiki. If you're interested in air BnB
let florian or I know.
Rossen: I'm back.
Rossen: Second part of the group advocated for keeping the behavior
symmetric.
Rossen: They basically were motivated because they don't want to
learn the wacky way of resolving against something not the
same.
Rossen: We are where we are. I listed some of those bad compat
issues.
Rossen: One other point brought up is at this point there's quite a
bit of usage in Chrome so this won't be easy for Chrome to
back away unless they want the compat issues we have.
Rossen: Given where we are and the community is split I think the
better service to the web is align on something which is at
least consistent. For that reason I'm going to go and impl
this behavior in the next version to Edge, to align to
Chrome and Webkit, provided we can resolve to go with that.
<tantek> I thought we were going to give more time for a proposal
for the aspect ratio stuff first?
<tantek> so we could eliminate that as an excuse
Rossen: Last time we chatted TabAtkins was, I believe, also fine
with going down to one behavior as long as there's impl
interest. I'm committing to changing Edge so the only thing
would be for FF to catch up.
Rossen: But we are not going to continue to put our users through
this suboptimal experience.
Rossen: So I'm sorry I couldn't hold up for the new comers to CSS.
It is what it is. So for UX we'll align with Chrome and
Webkit.
Rossen: I want to put it back on the WG to resolve on one behavior
and I mostly want to hear from FF since they'll be the only
ones left with the different behavior.
dbaron: I'd want to hear Mats' comments. I haven't spoken to him on
this for a bit.
tantek: I'd like to hear from dholbert as well before FF has an
opinion.
Rossen: I don't mind if we hold back, but at this point we're going
to ship to be interop with webkit and blink behavior on our
next version.
Rossen: So this will put more pressure on your folks. But that
doesn't mean you have to agree right now. Please chat.
<tantek> basically this is about giving in to compat right?
fantasai: One pattern I saw in the comments is a lot from the group
supporting asymmetric is that it initially doesn't make
sense, but it is more useful more of the time in the end.
fantasai: I found that convincing.
Rossen: I also found it convincing. But given that everyone can only
use that it's hard to argue the opposite.
rachelandrew: From talking to people I think what you see if
existing web dev think it's sensible and new people
will find it strange. But I can understand the compat
issue.
tantek: Only the oldest behavior...those of us that have been around
15-20 years would say that. Anyone who used positioning or
flexbox/grid would see it as weird and different.
rachelandrew: Yeah. I'm just telling you what I'm hearing.
tantek: I want to go on record to say I'm a little disappointed
because this is an ex where the WG essentially failed by
evidence of we're in a compat issue. It's not the first
time, but I wanted to call it out. Every time we resolve to
do it some way because a number of browsers do something and
then websites depend on it and then we hit a threshold where
other browsers are compelled to change.
<Rossen> +1 to tantek - this is exactly why I was fighting for so
long and hard on the issue
tantek: I fully sympathize. But this is a compat forced change. I
don't think this is good for the model.
astearns: I would agree.
astearns: Given that the discussion was evenly split and that we are
going in the compat direction it seems this will end up
with another switch like box sizing where people can opt
into the more sane way.
astearns: We're nearly out of time. Rossen do you want to put your
intent in and tag dholbert and Mats?
Rossen: I will. I wanted the minutes into the issue before I do it.
If we can resolve sooner rather then later so we can make
the spec changes that would be great.
tantek: I'd like to call this out as a meta issue for the F2F which
is when we don't act on some ambiguous we spec due to
compat. I feel this is the latest data point.
astearns: Can you put it on the F2F agenda?
tantek: Yep.
astearns: Thanks everyone for calling in.
Received on Thursday, 25 January 2018 01:10:45 UTC