- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 01:18:13 -0400
- 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.
=========================================
Fragmentation L3
----------------
- RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/issues/2614#issuecomment-385836043
- Change Summary- pulled out break propagation into its own
section into CSS-break-3 and clarified that:
- out-of-flows don't propagate their break values up to
their parents
- layout modes like Flexbox and Grid have more specific
propagation rules which override the one in CSS-break-3
- Flexbox uses order-modified document order in determining
first/last child
Grid L2
-------
- RESOLVED: Add a feature that allows max to win over min in Grid
L2, name tbd. (Issue #1102)
CSS Transforms
--------------
- RESOLVED: SVG attribute reflects current interop, future
improvements will be in CSS transforms. (Issue #2623)
CSSOM View
----------
- RESOLVED: Add returning a promise to all scroll functions. (Issue
#1562)
CSS Align
---------
- TabAtkins introduced issue #1432 (Rules for align/justify-self on
static position of absolutely-positioned boxes need more detail)
and the proposal to have align/justify-content be similar to how
CSS 2.1 behaves for blocks.
- There were concerns that this does not give you a true center
for the center value.
- Additionally it was expressed that this change in alignment
may cause re-layout which isn't desirable.
- Continued discussion and additional feedback are welcome on
the github issue: https://github.com/w3c/csswg-drafts/issues/1432
Typed OM
--------
- RESOLVED: Allow fr and resolution units in calc functions, add a
note to Values & Units explaining they don't combine
with length. (Issue #734)
- RESOLVED: Add a note to CSS Values & Units that new unit value
types should be added to calc as they're added to CSS.
(Issue #734)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0025.html
Present:
Rachel Andrew (IRC Only)
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Garrett Berg
Dave Cramer
Alex Critchfield
Dael Jackson
Brad Kemper
Peter Linss
Anton Prowse
Liam Quin
Manuel Rego
François Remy
Melanie Richards
Dirk Schulze
Majid Valipour
Regrets:
Benjamin De Cock
Elika Etemad
Florian Rivoal
Alan Stearns
Lea Verou
Greg Whitworth
Scribe: dael
Fragmentation L3
================
Fragmentation rules around break propagation are confusingly-written
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2614#issuecomment-385836043
Rossen: Summary: There were some comments made about fragmentation
rules not being clear, especially with child/parent break
propagation. Changes added to CSS break were intended to
address this.
Rossen: "out-of-flows don't propagate their break values up to their
parents" makes sense because out of flow items propagate to
containing block.
Rossen: 2nd is flex and grid layout have specific propagation rules
that override CSS 3 break. That was in tune to previous
since we've extended fragmentation before and assume that
overrides, but now that's explicit
Rossen: Last is flexbox....I think also grid...order is modified and
propagation is based on layout order, not doc order.
Rossen: These are the changes. Issue was on the agenda to either
accept or challenge the changes.
Rossen: From the 3 changes, as I said, 2 are mostly editorial. 1st
is out of flows don't propagate their break...that can be
seen as normative.
Rossen: Opinions? Questions? Reasons not to accept?
Rossen: I'll take silence as no. Objections to accept changes in
https://github.com/w3c/csswg-drafts/issues/2614#issuecomment-385836043
?
<dbaron> I think it's probably fine, but I think out-of-flows might
be a *little* interesting, maybe?
RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/issues/2614#issuecomment-385836043
Rossen: dbaron, you said something in IRC?
dbaron: I think it's fine.
CSS Grid 2
==========
Allow minmax where max wins over min
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1102
TabAtkins: Someone brought a use case where they want to set up
columns that are like 20% of the grid but no larger then
250px. Obvious way doesn't work the way they want because
min wins over max. If viewport is large the min will win
and it'll be >250. They want priority to min.
TabAtkins: Seems reasonable. We chose min win over match because it
matches CSS. Reasonable to want different order.
Suggestion is to add some way to achieve that in grid L2.
<Rossen> what if we call it maxmin
<Rossen> meaning max wins vs minmax where min wins?
TabAtkins: We can decide on the functionality addition and not the
syntax. It's a minor change to layout algorithm. There
will need to be a check to say if it's this type of
sizing you can't go above this value.
Rossen: Support adding. Did we resolve on using maxmin?
TabAtkins: I don't want maxmin because it suggests max comes first
in argument. We can figure syntax out later. fantasai and
I will recommend something.
Rossen: The feature request makes sense.
Rossen: Opinions? Reasons not to put this in grid L2?
Rossen: Objections to adding a feature that allows max to win over
min in Grid L2?
RESOLVED: Add a feature that allows max to win over min in Grid L2,
name tbd.
CSS Transforms
==============
Browsers do not implement transform attribute syntax as described
by w3c
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2623
krit: This is the transform attribute for SVG name spaced elements.
Syntax browsers allow is different then specified in
transforms.
krit: We have transform attribute that uses SVG syntax. Is some ways
incompat to CSS syntax. Since there's interop between browsers
do we accept transform attribute is using SVG syntax or do we
force browsers to support CSS?
<krit> https://github.com/w3c/csswg-drafts/issues/2623#issuecomment-388005994
krit: Tests^
chrisl: Given there's interop we should go for that.
chrisl: Given we're chartered to document what works now we have to
go with situation as it is.
Rossen: As an impl that just added this, having had to do all the
work to support both parser and object model version I
wouldn't rush to modify one or the other. Certainly not CSS
transforms. Document what's fully interop is very much
supported by us.
krit: Might mean we can't support CSS syntax in the future for
transform attribute, but no indication an implementation would
pick that up.
AmeliaBR: Way it's specified is that transform attribute is supposed
to accept both legacy and new syntax. No one supports new
CSS syntax. If we match current we say attribute is tied
only to SVG 1. Separate issue is what browsers support
doesn't match what has been copied from SVG 1 so still
need to work to figure out what's interop and then define
that in grammar. It's not a perfect match.
krit: Only difference as the tests show is that there's currently a
requirement to have a comma or a space between numbers. That's
not followed. Broader issue is do we ever want to support CSS
transforms syntax? I don't think we can do both.
krit: Mostly because functions in CSS requiring function name and
then parenthesis. SVG allows spaces between. There's other
things like SVG allows lots of separators and CSS is strict.
chrisl: I think we have to say for historical reasons there's
differences.
krit: What about CSS transforms?
chrisl: Means you have to use a selector to apply.
krit: Also propose if you want new syntax you have to use a property.
chrisl: Agree.
AmeliaBR: We lock down the attribute, no new features except those
to match reality
Rossen: That's our take.
Rossen: To go back, is there any implications to CSS or where we
need to give input? I'm not hearing changes or requirements
to CSS. I would suggest if you want to discuss SVG lock down
you do that with SVG and decide how to lock attribute. Are
there specific questions for CSS?
krit: If the WG would object to that?
Rossen: Group, do you object to having SVG WG defining what SVG
attribute should do?
AmeliaBR: Currently defined in transforms.
krit: Probably needs to stay.
Rossen: Take it out?
chrisl: Don't see need. No one is queuing to change impl so document
what works
krit: Question from Rossen is if we spec differences in CSS
transforms or in SVG
AmeliaBR: Agree with chrisl keep in same spec.
krit: Good idea.
Rossen: I don't have anything against that.
Rossen: Do we need a resolution? Summary: SVG transform attribute
will document what's interoperable.
AmeliaBR: Worth a resolution because that's a major change.
AmeliaBR: We've currently got it spec the attribute accepts new and
old syntax.
Rossen: Okay.
krit: I'm fine SVG will define details. Resolution that transform
attribute is locked down to current interop impl is nice.
Rossen: Other impl opinions?
krit: Webkit PoV securing status quo is preferred.
Rossen: Blink or Gecko?
AmeliaBR: Issue was started by a Gecko contributed. He said he can
make minor fixes.
Rossen: dbaron are you guys okay?
<dbaron> I said it seems fine to me given what Robert said in the
issue
Rossen: TabAtkins?
TabAtkins: I believe fine
Rossen: Sounds like no implementors object.
liam: Does anyone know what non-web SVG impl do?
Rossen: Not sure. If any do something else and no major impl can
support I'm not sure the use case.
AmeliaBR: As far as I know they stick to SVG 1.
liam: Thanks.
Chrisl: It's not a weird syntax, they impl SVG 1.
liam: That was my expectation. Just checking if anyone looked.
Rossen: Objections to document the SVG attribute to be as currently
supported by all implementation, possibly with a note that
future extensions will be made at CSS level
RESOLVED: SVG attribute reflects current interop, future
improvements will be in CSS transforms.
CSSOM View
==========
Consider making scroll methods return promises
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1562
TabAtkins: Right now all scrolling methods are void, return
undefined. When they were instant that was fine. Now that
there's smooth scrolling it may be worthwhile to have
something tell you when it's finished. Someone suggested
that scroll methods return promises.
TabAtkins: I don't think they would ever fail.
TabAtkins: Upgrading void methods into promise returning is a
standard way to do this and should be compat. As long as
there's no implementor objecting I'd like to add.
Rossen: Defined behavior for overlapping scroll timelines?
TabAtkins: Don't know, use case?
Rossen: You want to impl your own overscroll behavior for a spring
effect. When your scroll is complete you want to scroll down
and back. I can see someone doing that. So I start a scroll
for something fairly long in time and then I'll wait for the
promise to do the little overscroll. But another scroll in
the opposite direction happens.
TabAtkins: If a scroll is started and interrupted it's done and you
fulfill promise.
Rossen: So interrupt or complete fulfills.
TabAtkins: We only reject promises on errors and there's no sense
the scroll throws an error
dbaron: You might want data on if interrupt.
TabAtkins: Agree. Should fulfill, but argument should give data
majidvp: Can you not read scroll offset with actual offset and it
means interrupt?
TabAtkins: No because you're interrupted mid-way. Using that as a
method an interrupted will be forever pending unless you
hit it by luck.
dbaron: I think it's an alternative to data, not to the promise.
dbaron: That said, I think there are a bunch of scrolling operations
where you don't know destination offset. You can cause
scroll by page and you don't know pixel.
TabAtkins: And scroll into view is at least difficult to calculate
Rossen: I would want to have something cleaner and richer for hints.
When you intersect this with scroll snapping and you stop
for a different reason...if you scroll by and need to scroll
up more because a scroll snap has a mandatory scroll you'll
overscroll based on target.
Rossen: Meta point, I don't think anyone objects use case of promise
pattern. I think the addition to this is adding some data
that describes how this was fulfilled.
TabAtkins: I can see fulfill with an object that's an enum of
completed or interrupted or something like that.
AmeliaBR: I suggest looking at web animations spec. Smooth scroll is
a type of animation and web animation uses lots of
promises and I could see a use case for chaining things
like web animation after a complete smooth scroll. Compat
here is useful.
TabAtkins: Agree. I didn't know about that but I will take a look at
it.
majidvp: Another case is a scroll-into-view where we scroll multiple
scrollers and we need details on when we fulfill. I imagine
after all scrolls are complete.
TabAtkins: Yes, if you have 2 nested scrollers inner is a bit and
outer is a lot so inner completes fast. Makes sense. Good
detail.
<dbaron> https://developer.mozilla.org/en-US/docs/Web/Events/scroll
Rossen: Is there a reason we wouldn't want this as an event that you
can subscribe instead of adding promises to all scroll
functions?
TabAtkins: Possibly. But if you only care about a given scroll you
have to subscribe and then unsubscribe. Also there may be
another scroll and you might get the wrong one. Event is
useful, but doesn't do the use case of I want to know
when this scroll is complete.
Rossen: Okay. Makes sense.
Rossen: Sounds like a feature that merits addition of promise.
Likely details to work out.
Rossen: Additional comments or objections to add returning a promise
from all scroll functions?
RESOLVED: Add returning a promise to all scroll functions.
CSS Align
=========
Rules for align/justify-self on static position of
absolutely-positioned boxes need more detail
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-387153116
TabAtkins: We've made the changes of what we've interpreted from the
working group's earlier resolutions. Quick intro and if
there's interest people can look. Not expecting
resolution. Just an introduction.
TabAtkins: Size of containing block, sizing rules for static abspos
are complex. Standard LTR page and you have a standard
element size is constrained on left by static and on
right by abspos edge. This is reasonable, it's fine. But
there's questions about how to interact with alignment of
staticpos. Current is a different ridiculous thing done
by each browser.
dbaron: What existing features did you use to test?
TabAtkins: One is swapping direction. We think that's good. Using
align-content which switches where static pos and that's
where it's different and bad everywhere.
TabAtkins: Just tested in flex, should be same for grid.
Rossen: I'm not surprised it's less then interoperable.
TabAtkins: Main thing, we think browsers with blocks when you toggle
direction is good. You swap the sides so right is from
static and left is from abspos container. This is good.
Align switching from start to end should have same swap
is what we think.
TabAtkins: Only not covered is when you center. We think then both
edges come from static pos element. So the left from ltr
and right from rtl. It gives you reasonable centering. If
you want other behavior you can get with left:0 right:0.
Also seems less intuitive.
Rossen: One addition, we've discussed this in the past, especially
when doing grid. Having the static position modify your
containing block size, or what you use for layout position,
so that you redefine space for position left and
right...because layout you first measure content to get
preferred sizes and then you do arrangement and then you do
alignment...you should assume alignment doesn't change
layout though some baselining does.
Rossen: If we assume alignment doesn't reintroduce layout the
problem is simple. Need to figure out how much to
additionally allow alignment adjustment.
Rossen: One thing we considered is if static pos is a point to where
the actual static element would have been you then do your
layout however you'd do it. You size and position as if
block. Then you use this point and say align the box you
have created and then additionally aligned about that point
something else in that box. 30% additionally on the left, or
align me in the center. So you can reposition without layout
changes.
Rossen: That also means there's additional alignment values we'd
need, but they can apply in all layout modes.
Rossen: Food for thought. This is where we ended up after
investigating.
TabAtkins: In this case that...you're sticking with alignment can't
alter. That gives you Firefox behavior. I suggest looking
at the test case in FF and flip start to end for align
and you can see why it's not really sensible.
TabAtkins: The original box size is okay, but as soon as you
re-align it's a nonsense size. But if you direction
toggle it's good.
dbaron: Probably there's other behaviors for Rossen variant.
Including these properties should mess with static pos at
all.
TabAtkins: I don't particularly like that. Seems odd that swapping
direction is different then swapping alignment. Going
from align-content:start ltr to rtl we like that. We want
to make it so swapping align seems the same.
dbaron: But considering this align has weird consequences like
center isn't halfway between left and right.
TabAtkins: Yes. But we think the center we proposed is a useful
approximation.
Rossen: Question. You mentioned you wanted to introduce this. Not a
resolution. Pretty sure we need to work more.
TabAtkins: Yes. Look in details on the thread and we can discuss in
future.
Rossen: Okay. Anything else you want on this issue?
TabAtkins: Nope.
Rossen: There were a few Houdini and FXTF topics that have been
lingering. I'm happy to prioritize those now.
TabAtkins: I'd love that.
Typed OM
========
'fr' units cannot be used in a calc
-----------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/734
TabAtkins: When typed OM defined math rules it treated fr like any
other type
TabAtkins: You can divide a resolution by 2 for example. Anything
else added confusion. But looking at value spec fr and
resolution aren't allowed in calc.
TabAtkins: Seems like not it's a purposeful limitation. I think the
types were added to V&U after calc. Given you can express
them in typed om I'd like to be able to express in calc.
Or go back to typed OM and say no you can't use these.
That's oddly limiting. Proposal is allow fr units and
resolution units in calc. They are independent units.
dbaron: I think we have resolutions to allow more unit algebra in
calc.
TabAtkins: [missed]
dbaron: Then they're their own type in the unit algebra.
TabAtkins: Yes. fr doesn't add to length, though. but you can
combine as long as end result is a reasonable unit.
Rossen: Sounds reasonable. Other opinions?
<dbaron> I'm in favor.
<dbaron> That said, it seems like we might want to be able to add in
the future...
AmeliaBR: I'd ask that maybe somewhere there's an informative note
emphasizing fr can't be added and combined with length and
percentage.
TabAtkins: I think that's a note in grid. If not, I'm happy to add
it.
AmeliaBR: Sounds good.
Rossen: I think V&U is good for this note.
Rossen: Anything besides the note. Other ideas or objections?
RESOLVED: Allow fr and resolution units in calc functions, add a
note to Values & Units explaining they don't combine with
length.
TabAtkins: Do we want a standing resolution that any new numeric
units should add to calc?
chrisl: I'd rather exceptions on case by case basis.
TabAtkins: Agree.
Rossen: Sounds reasonable. It's not like we add numeric units that
often.
dbaron: Agree new numeric values should be supported by calc.
Rossen: Separate resolution for CSS Values that adds a note that
numeric values are supported by default in calc.
TabAtkins: New unit value types should be added to calc as they're
added to CSS.
Rossen: Obj?
RESOLVED: Add a note to CSS Values & Units that new unit value types
should be added to calc as they're added to CSS
Rossen: We're top of hour. Thank you everyone for calling in. We'll
chat next week.
Received on Thursday, 17 May 2018 05:19:10 UTC