- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 6 Dec 2017 21:55:47 -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.
=========================================
CSS Sizing
----------
- Everyone was requested to review the major update to fold in width/
height & box-sizing propdefs. Link:
https://lists.w3.org/Archives/Public/www-style/2017Dec/0008.html
Scroll Snap
-----------
- RESOLVED: Rename scroll-snap-margin to scroll-margin
- RESOLVED: Request an updated CR for CSS Scroll Snap
Values & Units
--------------
- There were two possible solutions to issue #434: Computed value of
a negative calc unit that doesn't allow negative lengths
1) Clamp as early as possible based on values.
2) Clamps as early as possible based on the property.
- The group was moving toward option #1, but that would lead to not
preserving calc to which there had been objections in other
cases.
- A note will be added to the issue to look back at the reasons for
previously wanting to preserve calc and see if those reasons
apply in this case as well.
Counter Styles
--------------
- RESOLVED: Mark <image> in <symbol> at risk
Grid
----
- The group did intend the implementation breaking change resolved
in issue #1921 (Percentage tracks and indefinite sizes). The
timing of implementing this change will depend on results from
the usage counter being run as well as implementation complexity
and browser coordination.
- RESOLVED: Request publication of new Grid CR.
Selectors
---------
- The group didn't reach a conclusion on issue #2037 (:link and
:visited are not mutually exclusive in implementations) however
there was agreement that the spec text didn't align with most
implementations and that Edge will likely need to change their
implementation to align with the spec.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Dec/0010.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Dael Jackson
Dean Jackson
Brian Kardell
Peter Linss
Xidorn Quan
Naina Raisinghani
Manuel Rego
Melanie Richards
Florian Rivoal
Alan Stearns
Victoria Su
Lea Verou
Greg Whitworth
Eric Willigers
Regrets:
Rachel Andrew
Angelo Cano
Tantek Çelik
Benjamin De Cock
Tony Graham
Michael Miller
Scribe: dael
Agenda/Spec Rec Next Steps
==========================
astearns: Things are still a little lite. Are TabAtkins or fantasai
on?
fantasai: I'm here
astearns: We should start.
astearns: First thing, any extra items? I do see Rossen commented on
#1120 so that should go in with grid
astearns: Any other items?
astearns: I didn't put spec rec next steps because fantasai and
Chris sent detailed notes. Anyone else have something to
bring up?
florian: Is Chris on the call?
[silence]
florian: I just wanted news on CSS UI 3 transition. There has been
discussion, but I'm not sure on conclusion.
astearns: Send a query to private list or Chris directly.
CSS Sizing
==========
Major update to fold in width/height & box-sizing propdefs
-----------------------------------------------------------
link: https://lists.w3.org/Archives/Public/www-style/2017Dec/0008.html
astearns: I don't think we need to comment, this is a call to please
review.
Scroll Snap
===========
Should scroll-snap-margin lose it's snap?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1954
astearns: Since scroll-snap-padding is now scroll-padding, should
scroll-snap-margin be scroll-margin?
TabAtkins: fantasai and I are fine with it. Seems good. I don't
believe there are impl so rename should be free.
florian: I seemed to remember during TPAC we had a discussion where
that rename would be useful, not just principle.
fantasai: Previously we renamed padding because it had effects
without snap. When we did #1708 for using margin when not
in snapping mode, it now makes sense.
florian: okay, yes, I'm all for it.
dbaron: I'm a little worried the name sounds more like something
general, but maybe it's okay.
astearns: Right, margin on scroll port rather then margin on an item
in scrolling situations? The name could invite that
confusion.
TabAtkins: Yes, that's an unfortunate consequence.
fantasai: Another thing to note is that point of confusion existed
independent. It's just the choice of using padding and
margin. And what would a margin be outside a scrollport.
dbaron: Somebody might expect it to be margin on the stuff inside
the scrollport.
fantasai: That's what it is, isn't it?
florian: What do you mean by stuff?
dbaron: The gap between...when you hit the edge of the scrollport
between the edge of the content and the limit of what you
can scroll to.
dbaron: That's something today people can't control because that's a
function of what the scrollable overflow is.
dbaron: Maybe it's not a big deal.
florian: I think what you're talking about is more similar to
padding than margin.
<fantasai> +1 to florian's reply
dbaron: I guess we should go ahead with it. Maybe worth another
issue about possible confusion.
astearns: Any other concerns?
astearns: Objections to rename scroll-snap-margin to scroll-margin?
RESOLVED: Rename scroll-snap-margin to scroll-margin
Publication
-----------
astearns: And there's a question of if we ask for new CR.
astearns: Thanks to fantasai we have a test case for the previous
large change. This resolution will require a few tests to
be changed.
fantasai: The ones I just checked in need to be changed so I'll do
that.
astearns: Objections to requesting an updated CR for css scroll snap?
RESOLVED: Request an updated CR for CSS Scroll Snap
Values & Units
==============
Computed value of a negative calc unit that doesn't allow negative
lengths
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/434
astearns: I added some tests with idea we would want to be picking
either used or computed time. Sounds like proposal is to
clamp as soon as possible. Correct?
fantasai: Not quite. To clamp them both...twice effectively.
fantasai: Some values you can calc through at the beginning and
others you can't.
<fantasai> Summary of the issue / proposal :
https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908
dbaron: I think what I suggested is that when the value...when all
values of property can be computed through at computed value
you clamp at computed value time. If not you clamp at used
value time.
TabAtkins: That is what we're saying.
fantasai: No it's not.
fantasai: There's two proposals. One is you clamp at each stage if
it's possible at that stage for values under consideration
at that moment; other is you clamp when it's guaranteed to
be possible for that property in general.
TabAtkins: The answer is the forward compat one. A prop is used
value clamping if any property needs used value time to
tell. It will have an observable effect if we later add
an item that is used to a clamp. The clamp as early as
you can has no observable effect when we add new things
to value space.
florian: So is there an argument against that?
astearns: My question is since clamping at used value appears to be
slightly useful for animations could we only clamp at used
value time?
TabAtkins: That might be possible
fantasai: It's not because font size property needs to compute
through to ems can be computed.
TabAtkins: Is that true though...
??: I think so.
TabAtkins: What's wrong with ems computing to a calc.
fantasai: ems are a length, they resolve to px.
TabAtkins: That's current. What's wrong with the other way around.
TabAtkins: It eventually falls through to layout. Only difference is
what things you can observe at computed value time.
fantasai: It means you'll carry a calc around that's 50px+100%+2em
you have to carry that and insert it into a margin that's
a descendant of a descendant but still have it resolve on
the parent on the original element on which it was
declared ... are you crazy?
TabAtkins: Yeah, that would be the technical consequence. Every
situation here is bad.
dbaron: That's bad for impl complexity and performance if you say
you can never simplify.
TabAtkins: Sure.
<fantasai> A) Clamp as early as possible based on values.
<fantasai> B) Clamps as early as possible based on the property.
florian: What's wrong with clamp as soon as you can. It sounded good
to me. It's fine with animations.
TabAtkins: Someone advocating for that would have to argue for it
because I don't know.
astearns: I'm still unclear.
TabAtkins: florian means what we're suggesting.
florian: As soon as you can based on values, not based on which
property it's in.
dbaron: % will behave differently depending on how they behave for
prop.
TabAtkins: We're saying as early in the context of a property. Since
in the property you can tell if you can know at computed
and clamp them or you wait until used.
dbaron: Are there cases...where we distinguish between calc(10%) and
10% doing something different.
TabAtkins: I don't think so. In position % don't resolve to a simple
pixel value, but still a bare % goes to same in or out.
fantasai: If it's negative. We throw those out at parse time.
dbaron: If we want to throw out negative it also makes sense to
simplify away the calc.
dbaron: If you're at a point where you can fix the negative you
should compute calc to a single value.
TabAtkins: That's against our general consensus to maintain calc
structures somewhat so that authors get to look at a
regular thing. I've argued against that, but that was
what the group wanted.
florian: Channeling glazou: when possible, keeping what the author
wrote helps with authoring tools.
dbaron: I don't see how you maintain a calc structure while
clamping. If you have 50px+2em and you know an em is large,
do you change the em or do you turn it into 0px?
TabAtkins: For animation it's 0px.
dbaron: But we're talking what the computed value is.
TabAtkins: Well, what the animated value is. It's mostly the
computed, but sometimes diverges.
TabAtkins: Big observable thing is in your animated behavior
dbaron: I guess...you could compute it to calc 0px rather then 0px.
But it seems weird to deal with clamping but not simply
expressions.
astearns: Seems weird to me to have a clamp happen but then give the
non-clamped expression and the person using it doesn't
know if it's evaluated as expression or clamped value.
TabAtkins: I don't have a strong opinion but people have objected to
removing calc before.
fantasai: Removing calc should be a separate issue.
dbaron: It would also be useful to have links to the other decisions.
TabAtkins: I recall glazou being a proponent of maintaining calc
astearns: fantasai in IRC had 2 comments [reads]
A) Clamp as early as possible based on values.
B) Clamps as early as possible based on the property.
astearns: My understanding is we're going with option A.
astearns: Is that correct?
florian: Yes, I think so.
astearns: What if we resolve on option A: Clamp as early as possible
based on values. and I'll open a new issue as to what to
do with calc when they're clamped.
dbaron: I'm uncomfortable agreeing to clamp at a time when we're not
agreeing to simplify calc at the same time.
florian: Would you object to not simplifying or is there another
option?
TabAtkins: I'm fine with simplifying. There were arguments against
it before.
dbaron: I think we should table and go back to look at those
arguments.
astearns: I'll add a comment that we need to look at why we had been
deciding to preserve calcs. This being a new situation
where we're clamping the value I suspect the previous
arguments about preserving calc-ness will go out the
window.
florian: astearns when you make that it's good to mention glazou.
astearns: I will tag him on it.
TabAtkins: This is the only thing blocking CR and V&U is quite out
of date. Can we do a new CR with this unfinished and get
it up to date?
astearns: How many other changes are in the changes section?
<fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016
TabAtkins: I'll look. A decent amount. A number of new units
astearns: And we're in CR?
fantasai: The new units are in 4.
TabAtkins: Let me link the changes.
<TabAtkins> https://drafts.csswg.org/css-values-3/#changes
astearns: Given we're in CR I don't think we can ask for updated
before we republish.
TabAtkins: Then let's close it no change and re-open it because this
is dumb process preventing us from publishing.
fantasai: I think we can ask for republish and explain this is a
minor issue and still open and we'll deal with it.
astearns: Republishing and knowing we have to do it again is also
dumb. I'd rather wait.
florian: Does spec have the thing we're likely to resolve to?
TabAtkins: let me look
TabAtkins: Current spec says always clamped at used value which is
the one thing we agreed to not do.
[laughs]
florian: So resolve unless glazou objects?
astearns: I don't want to rush this through.
astearns: I'm sorry.
TabAtkins: I'm just frustrated that we can't publish because
process. I'd rather publish and publish again in a month
then have a month of buggy TR draft.
astearns: I agree on regular WD but CRs are extra work.
Counter Styles
==============
Mark <image> in <symbol> at risk?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1991
TabAtkins: xidorn pointed out the image value no one has impl and
he's not interested in impl. I noted it complicates the
definition of counter in unexplained ways. I'm happy to
mark as at risk on track to drop.
astearns: Any objections to Mark <image> in <symbol> at risk?
RESOLVED: Mark <image> in <symbol> at risk
fantasai: We just submitted it as a transition.
<fantasai> https://github.com/w3c/transitions/issues/23
Grid
====
Percentage tracks and indefinite sizes
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1921#issuecomment-347993853
astearns: We decided on a change, but it was pointed out impl have
interop.
fantasai: We discussed that at TPAC. We re-resolved to do the thing
impl don't do. This is the are you sure you meant the
thing.
florian: We took impl into account when we decided, yes?
fantasai: We did.
TabAtkins: We just want to be able to mark WG is cool with this.
astearns: I'm looking at tpac discussion and I see Rossen said this
is fine, not a big deal.
TabAtkins: He just didn't want to do it alone b/c it's a breaking
change.
Rossen: That's true. That's still my point. I'm still okay as long
as others do the change as well.
Rossen: We're still cool. Others?
astearns: webkit or gecko?
dbaron: It's a question for Mats or dholbert
astearns: dholbert deferred to Mats.
astearns: Given we have two impl willing to make the change and no
obj from the others, shall we reaffirm we want this change?
astearns: Objections?
dbaron: Who will change first?
dbaron: If no one will do that we shouldn't do it.
fantasai: Rossen it looks like webkit and blink will follow if you
lead.
<fantasai> mrego said “We're not planing to change Blink/WebKit
implementations until other browsers do it”
Rossen: I won't do it the same way we tried with control characters.
I will allow the market leader to lead and we will happily
follow. The change is straight forward, but I don't want to
introduce interop change.
Rossen: For technical decision I'm fine. For scheduling and who
when, we won't be first.
fantasai: Rego said they won't change until other browsers do it.
Igalia folks are good about following up so I don't think
it'll get lost. But it will require MS to go first or at
least say it's impl and will release on a date as long as
WB and blink will also trigger.
Rossen: How about we table scheduling discussion. If it's as easy
for Rego and Igalia as it is for us, let's stop the
discussion and we'll discuss timing. As far as spec decision
is concerned we'll ship first as long as there are
assurances others will follow.
rego: We checked how many chases will go through this. We first want
to gather data on how many websites will break with this
change.
Rossen: You want us to change to see breakage?
rego: No, we added a use counter in chromium to gather data. So we
want to wait to gather some data before doing anything.
<gregwhitworth> rego do you mind linking to the use tracker?
Rossen: Sounds good. Let us know that data and what it shows.
rego: Sure.
astearns: So anything more on this issue?
Rossen: Is take away everyone is still okay pending some data
collection from Igalia folks?
astearns: Yes, pending data collection, impl complexity, and timing
of all engines getting change done.
Resolving 'fr' flexible lengths during intrinsic sizing of grid items
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1120
astearns: I'm not up on this issue. What was your comment Rossen ?
Rossen: We are most likely going to have to change. We're okay with
it, it will be simple. I'd like TabAtkins and fantasai to
give this a read one more time. If they're still okay with
current resolution we don't have to re-open. If they find
additional points we can bring it back. for now I don't see
a reason to re-open
fantasai: Our analysis from the comment is there was a clarifaction
place and an error in terminology. We checked in those
fixes. We couldn't find any other wanted change then those
errors. We checked that in and asked Rossen if there's
anything else. I'm guessing he said no.
Rossen: Mostly. We can discuss if after you read the comment you
feel like we need to discuss.
astearns: Sounds like action is for fantasai to take a look and if
everything is fine she can mark as commenter satisfied.
Rossen: Yes.
astearns: Good fantasai ?
fantasai: Yeah.
Publication
-----------
fantasai: Rossen are you okay if we publish cr without the one you
just found (https://github.com/w3c/csswg-drafts/issues/2085 )?
Rossen: I really want resolution on this
fantasai: Can we do it in Jan,? If we don't get it today it doesn't
get published this year. But we need to publish, grid is
super out of date, it hasn't published since may.
fantasai: Unless you want to block on this for publication.
Rossen: I won't object to publishing for this issue.
fantasai: Let's resolve to publish CR update. Then we can publish
again.
Rossen: Do we not have a call next week?
fantasai: This is the deadline for CR publication.
Rossen: I'm fine discussing next week.
<fantasai> Disposition of comments at
https://drafts.csswg.org/css-grid-1/issues-cr-2016
astearns: Proposal is publish an updated CR of grid minus this
issue. fantasai put together tests for all the issues
since we resolved to require them. So I think we should
try to publish.
astearns: Objections to asking for a new CR of grid?
RESOLVED: Request publication of new Grid CR.
Selectors
=========
:link and :visited are not mutually exclusive in implementations
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2037
victoria: We found it weird that edge is doing something different
then the rest of us.
victoria: It is technically doing what spec says.
TabAtkins: I don't think it is.
TabAtkins: I think I agree with dbaron it should be mutually
exclusive. I thought it depended on which, it's one or
the other not a mix.
TabAtkins: It's not agreeing with how we thought the model worked
for this.
<fantasai> oh, wow that's super interesting testcases
Rossen: I was seeing if fremy is on.
[trouble hearing fremy]
<fremy> don't worry
<fremy> everything is in the issue
astearns: Given fremy last comment in issue, do we need a spec
change to more closely define what other browsers do or is
it just clear edge is doing something weird?
TabAtkins: I think spec is clear that Edge is weird. They're clearly
mutually exclusive conditions.
<fremy> TabAtkins: not true
<fremy> TabAtkins: you still need to apply :link { padding } for
instance
astearns: fremy disagrees
* fantasai *wishes* that they weren't mutually exclusive, but
legacy... :(
<TabAtkins> https://drafts.csswg.org/selectors/#link
TabAtkins: I think his disagrees that it's an important difference.
dbaron: I think fremy thing is after selector matching. Because the
way the property restrictions work for some properties you
always get the thing as if it's just visit, but for
something like color you use the styles for has visited.
That was derived from the legacy where we didn't have
property restrictions.
Rossen: fremy is coming to my office so you can hear him.
[pause to wait for fremy]
fremy: I think...tbh I think we do agree edge is different and we
need to change. But I don't think the spec clearly defined
what should be done. dbaron documents those.
fremy: I think it would be good to clarify the spec so people get it
right, especially because there's privacy involved. It's
clear to me you need to match link values for visited links.
TabAtkins: The spec says "these two states are mutually exclusive"
so I don't know how to make it clearer.
fremy: In practice they're not mutually exclusive.
fantasai: What fremy says is try because you're doing background
color for visited at same time as color from link. We
should think of an easier way to describe this in the
spec. For some properties visited doesn't apply and link
applies.
fremy: They're mutually exlcusive for some not all properties. I
think that needs to be in the spec
dbaron: It's a bit dangerous to mix it into the selector. It is a
layer above selector matching in gecko. If you mix it into
selector matching you get different results potentially.
fantasai: I need an example
<TabAtkins> Yeah, impls don't seem to match the spec, I agree now.
astearns: We're out of time. There will need to be some changes to
the spec to clarify and Edge will need to change to match
the spec
TabAtkins: No one matches the spec. So something has to be done.
Rossen: So we agree to do work.
astearns: So that's where we need to leave this. I apologize that we
didn't get to :focus-ring and :focus-indicator. We'll
continue in the issue and try and resolve there.
Received on Thursday, 7 December 2017 02:56:44 UTC