- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Oct 2019 05:31:49 -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.
=========================================
Charter update discussion
-------------------------
- The charter has the proposed changes edited in and is ready to be
announced: https://www.w3.org/2019/10/css-wg-charter.html
Writing Modes
-------------
- Issue #4357 (propagation from body to document element is
annoying) will be covered next week, but in advance browsers are
requested to review to see if they intend to make the change
that's being questioned.
CSS Values
----------
- RESOLVED: Accept the proposed changes: We move where
simplification occurs from being consequence of
serialization to happening on the underlying value
(Issue #2245: Actually describe how/whether computed
math functions are simplified from specified ones)
CSS Sizing
----------
- RESOLVED: Accept proposal in favor of serializing with the calc
expression (Issue #3757: Support <number> (and therefore
calc) as a <ratio>)
Transforms
----------
- RESOLVED: Allow percentages inside the scale (Issue #3399: Have
scale function accept percentage value)
- mwoodrow will create proposed spec text for issue #3322 (Should
the overflow area take scroll position into account) based on
how Gecko has written their code.
- RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/3084
(Interpolation of perspective) no change
- RESOLVED: 0 is allowed with 1px being the render time clamp (Issue
#413: Zero value in perspective() function)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Brian Birtles
Dave Cramer
Kevin Ellis
Elika Etemad
Simon Fraser
Daniel Holbert
Dael Jackson
Dean Jackson
Sanket Joshi
Philippe Le Hégaret
Myles Maxfield
Cameron McCormack
Florian Rivoal
Jen Simmons
Matt Woodrow
Regrets:
Oriol Brufau
Emilio Cobos Álvarez
Christian Biesinger
Thierry Michel
Manuel Rego Casasnovas
Christopher Schmitt
Scribe: dael
Rossen: Let's get started
Rossen: As usual I'm going to call for changes to the posted agenda
Rossen: We have way more than the capacity for one call, but we'll
go in proposed order unless anyone has reason to change.
Rossen: Any changes?
smfr: We could skip 14, but no way we'd get that far
Rossen: If we surprise ourselves we'll skip
<fantasai> reordering makes sense to me
dbaron: One comment, maybe we have a good set of people to discuss
transforms. matt and smfr are here. Don't know if worth
re-ordering
Rossen: emilio sent regrets though and he raised the second issue
Rossen: We'll see traction on text and if none move to transforms
Charter update discussion
=========================
<plh> --> https://www.w3.org/2019/10/css-wg-charter.html CSS WG
Charter
Rossen: plh sent proposed change to the current charter that was
inspired/proposed mostly by florian
Rossen: I think text changed is pretty great
Rossen: CTA is to take a look at this. If you have reasons to object
or propose additional changes now is it. Otherwise need
horizontal review completed sooner
<fantasai> I think the changes are much better
plh: The changes shouldn't impact WG in operation. Unless someone
raises a flag today I'm ready to announce new charter.
Everything is in place and will be announced tomorrow.
fantasai: Changes look good. Much more reflective of what we want to
happen so we should approve
<dbaron> changes relative to AC review draft look like
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fproposed-css-2019.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F10%2Fcss-wg-charter.html
florian: Agree. We spent a while replacing it with something that
makes sense. We should go ahead
Rossen: And thank you florian and everyone involved
plh: Then by tomorrow you guys will have a new charter.
Rossen: Thank you very much. That is exciting.
Rossen: Let's do more work based on that charter.
Writing Modes
=============
propagation from body to document element is annoying
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4357
Rossen: dbaron do you want to talk now or wait for emilio next week?
Rossen: I'm happy to defer
dbaron: I think better to defer to next week with emilio
Rossen: One thing I would point out is we're in PR and he's raising
issue against PR
<dbaron> unless heycam or dholbert want to cover it
florian: One brief comment for everyone else to prepare, this is how
we propagate writing modes and related properties up.
Changed it recently and it's either impl or on its was to
impl in Gecko. emilio thinks Gecko can do the change but
he's skeptical other browsers will do it
florian: Please do some reflection. If we resolved against what
people want to do that's annoying. For next time please
not-Mozilla people know if you have intention of
implementing
CSS Values
==========
Actually describe how/whether computed math functions are simplified
from specified ones
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2245
TabAtkins: Mostly a matter of if everyone else is cool with me doing
spec work
<AmeliaBR> +1 to Tab's proposal as described in the issue (any
simplifications required for serialization should happen
at parsing / setting time so they also show up in Typed
OM)
TabAtkins: In the spec calc and math functions are simplified during
serialization. Has implications for typed OM because if
not simplified I have to represent in a full version of
what parsed
TabAtkins: Didn't matter before because serialization was the only
way to observe internal values. Now we have 2 ways want
to make sure spec is clear simplification is on
underlying value and then both emit simplified values,
but don't simplify on their own
TabAtkins: Means we don't have to store another version of
simplification for typed OM to emit
TabAtkins: Unless there's a reason to keep pre-simplification tree
I'm going to say simplification is during parsing and
serialization spits out the simplified thing
AmeliaBR: Agree with proposal. There are consequences for numeric
precision. If you have calc with division and end result
is not finitely represented we agree post simplification
is the canonical presentation. That's how it works in
browsers so it's acknowledging how it works
dbaron: Confused in issue about which is computed vs specified
values versus which is parsing vs serialization
TabAtkins: That's because it's confused in spec. Simplification as
spec now only happens as result of asking to serialize.
There's nothing saying simplification happens earlier.
Typed OM doesn't have a hook to get the value
serialization has and turn into object. Want to make sure
emitting same thing. computed vs specified doesn't matter
here
dbaron: No change to what spec values serialize to
TabAtkins: Correct. Assuming we say they serialize in a simplified
manner then yes no change. Just moving where in process
it happens. Unobservable to old code
dbaron: Worth checking that is the behavior. I didn't think it was
AmeliaBR: It is the current. If you set in an inline style
font-size=calc(10px/3) and you read back that style from a
DOM, specified style, you get calc(3.3333px)
dbaron: Then I'm fine
Rossen: Hearing support. Any objections?
RESOLVED: Accept the proposed changes: We move where simplification
occurs from being consequence of serialization to
happening on the underlying value
TabAtkins: Also, all of the text about computed values,
serialization, all that in calc is outdated. Dates from
values 3 with simple calc stuff. Now we have algebra none
works.
TabAtkins: I'm filling in details and there's a link to those
changes from the issue. Got a little more work to do on
that, but I'll continue. Comments are appreciated. I'll
fill in serialization. Goal is old calc is the same, need
to handle the new stuff
TabAtkins: Anyone planning to work on this I'd love it if you review
as you impl and if there's mistakes or improvements let
me know
CSS Sizing
==========
Support <number> (and therefore calc) as a <ratio>
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3757
AmeliaBR: Finishing a discussion that was time clamp in Aug. Issue
is about serialization issues.
AmeliaBR: Aspect ratio is unique and this applies to MQ and
property- defined where division is part of syntax not
just part of calc. Brought questions on how to serialize
AmeliaBR: Proposal I had was we treat numerator and denominator as
separate components of the value. Each simplified as
independent. If one is omitted the other becomes a
default 1
AmeliaBR: Only issue I found since last discussion is right now both
values required to be positive. Calc expressions that
resolve to -value/-value you clamp them so it's 0/0
instead of negatives canceling. Might be worth doing
clamping at used value as this is non-intuitive
TabAtkins: Allowing individual numbers to be calcs is consequence to
CSS syntax. All numbers can be calcs
TabAtkins: Agree negatives not worth allowing. I don't see why two
negatives should pop out. Even if they would cancel
doesn't seem worthwhile.
TabAtkins: Anything with single calc?
AmeliaBR: Single calc is same as single number. I propose for
serialization that's your numerator and insert the missing
denominator as a 1
jensimmons: Agree but don't see practical case for negative over
negative so if that's difficult I'm for disallowing
AmeliaBR: Proposal as in my comment for Aug 28: Always serialize as
number/number where the numbers might be calc expressions
heycam: Against principle of shortest simplification, but fine for
me. As long as we write that in spec
fantasai: It is the shortest most backwards compat serialization
heycam: Is it a thing with this property?
AmeliaBR: Yes with the MQ. Keep property consistent with MQ
<fantasai> regardless, should indeed be made explicit :)
smfr: What about proposal to use units?
AmeliaBR: Agreed not to do that, but can do it by putting it inside
a calc
smfr: Okay
Rossen: Other comments? It's not perfect but sounds like best we
can do
Rossen: Objections to resolve in favor of serializing with the calc
expression?
RESOLVED: Accept proposal in favor of serializing with the calc
expression
<AmeliaBR> (that should really be "with the division", not a
`calc()`!)
CSS Lists
=========
Should automatic list-item increment adjust for ol[reversed]?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4181
fantasai: I think we should skip to transforms. Seems a lot of these
are overflow and have right people for transforms
TabAtkins: Agree
Rossen: Question about text ones, are any of the text issues ones we
should do on this call?
florian: Interested in all, but none are urgent
Transforms
==========
Have scale function accept percentage value
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3399
AmeliaBR: This was a community suggestion that scale transforms that
current accept number also accept % values,
transform-scale: 150% instead of 1.5
AmeliaBR: Question of author convenience and intuitiveness. We've
done this recently for opacity. Just like that it would
only effect parsing. Actual rendering wouldn't change.
AmeliaBR: Question of if people think it's enough value to users to
change parsing code
Rossen: Any expectation for how computed serializes?
AmeliaBR: I would assume convert to simple number
TabAtkins: Given this is a place where number represents same as %
I'm fine with it. It's low value, but low effort and I'm
good with being more consistent across the language.
TabAtkins: Idea is it would parse into a number internally and
serialize as a number
<heycam> +1 for consistency across all values that accept a
proportion-like value
AmeliaBR: smfr can correct, but I assume this is transforms 2. I
don't think any rush to get that to PR so we have time to
ship impl
smfr: I think that's true. Would effect 2d transform functions. New
in transforms 2. Fine with this
Rossen: Objections to accept proposal Allow percentages inside the
scale?
RESOLVED: Allow percentages inside the scale
Should the overflow area take scroll position into account
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3322
mwoodrow: Had bugs with parallax scroll effects. You can scroll past
content and get white area or can't scroll all content
into view
mwoodrow: Wondering is we should take into account when fixing scroll
AmeliaBR: For 2d most browsers extend scrollbars to cover 2d
translated position.
AmeliaBR: Question is to do with 3d?
mwoodrow: Yes, particularly hard with 3d where scrollable range
changes based on scroll position
dbaron: This is cases where scrolling moves things because of
perspective
AmeliaBR: What is spec proposal? Or just general recommendation to
browsers?
mwoodrow: Worth specifying you should be able to scroll to all of
transformed values. I can try and translate Gecko work to
words
smfr: I think scroll height needs to be computed to make transformed
elements visible to all scroll positions. Need to do
computations to get max scroll height. No thing like that in
css now
heycam: Do you need to get extremes or all in between?
mwoodrow: I do overflow at scroll position 0 and 1 and use that to
calculate how fast transform moves and use that to calc
when bottom edge scrolls into view
AmeliaBR: Are you willing to try and draft some text? Maybe we can
say tentatively sounds good pending seeing it written down?
mwoodrow: Willing to have a go with that
dbaron: Question of if other browsers interested/willing to impl
Rossen: Is this always stable? If transform is based on scroll
position and you're scaling
AmeliaBR: It isn't transform based on scroll position. The flattened
position of the element on screen after you flatten is
based on scroll position based on how perspective position
gets scrolled
smfr: It's not stable, further you scroll the bigger the scroll
height. I don't think you can compute max, you have to do
something like Matt suggests with doing a computation on a
fixed scrolling format
dbaron: Max is to the position that would cause the bottom of the
thing to scroll into view
mwoodrow: and possibility of multiple transforms so it's the last
piece of content
Rossen: Hearing no pushback. Matt, you expressed willingness to try
and put proposed text together. Let's do that, circle back
in issue, and when you're ready we can discuss and resolve.
mwoodrow: sgtm
smfr: Before we go there, we could say we're not going to fix this
and go simpler. You don't take perspective into account when
compute scroll height. Is there content we know is broken? The
parallax is for ambient backgrounds usually
AmeliaBR: I suspect authors are playing with adding extra padding
until get result they want
Rossen: Matt do you have reports?
mwoodrow: I had one where an author was trying to create parallax
and ran into this.
Rossen: smfr sounds like this could become a symptom. Are you
opposed to addressing?
smfr: Not theoretically opposed. Just thinking this could fall off
priority list as this is a tricky chunk of code
Rossen: But from a standards point of view try and address issue and
let impl catch up
smfr: Can address by saying we're not going to address this
specifically. Is alternative so bad we won't handle it
Rossen: I don't hear objection on merits of proposed behavior.
Unless I misunderstand
mwoodrow: Always had case when you have scrollable overflow you
should be able to get to all elements. We should uphold
that. Parallax is pretty popular
Rossen: smfr would you be opposed to proceeding by having Matt draft
proposal?
smfr: No objection
Rossen: Matt action is to you.
Interpolation of perspective
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3084
smfr: emilio noticed perspective property and transform function
interpolate different. Property is just length value. Function
is matrix interpolation. Gives different results. I think he's
right they should be same
smfr: I'm not sure how they differ visually. Would be interesting to
see if look really different or slightly different
AmeliaBR: Probably different because one creates an inverse
Rossen: Isn't the codepen in the issue enough?
<Rossen> would this test case be enough?
https://bug1488414.bmoattachments.org/attachment.cgi?id=9006258
smfr: That's just snapshotting one point, not showing animation
AmeliaBR: Converting perspective function to matrix isn't consistent
with other transforms. rotate we interpolate to a single
value
AmeliaBR: My preference would be to follow that pattern and
interpolate the parameter to the perspective function
rather then a matrix. Unless there's an impl reason why
that can't work. Apparently FF used to do that and emilio
changed to match spec
AmeliaBR: On the other hand if we now have conforming impl maybe we
stick with that
Rossen: Do we have conforming implementations?
smfr: Chrome and Safari match. Not FF. I think
mwoodrow: Do you know what Chrome and Safari are doing?
smfr: Not offhand
AmeliaBR: According to issue they do what spec does and generate
transform matrix from function and interpolate. According
to linked FF bug which was fixed in FF63 FF is now doing
same
mwoodrow: So we do have matching impl now
Rossen: Is proposed to punt on this and resolve no change?
AmeliaBR: Not used enough to insist on a change
Rossen: Objections to resolve close no change?
smfr: Should we do this without emilio?
Rossen: He can re-open if he wants to
<birtles> it seems weird to me
RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/3084 no
change
Zero value in perspective() function
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/413
AmeliaBR: The issue is that now spec says perspective parameter
needs to be a positive non-0 which goes against general
rule that we don't have indeterminate ranges that include
everything except exact value. need firm closed range
AmeliaBR: Eric put together a PR for exact wording. Proposal: it's a
closed range that's UA determined for the end of the range
AmeliaBR: No, his is specifically 0 is valid but when you give 0
then your matrix equivalent is the identity matrix. 0 is
valid parsing value with clearly defined behavior
<AmeliaBR> Eric's PR text: https://github.com/w3c/csswg-drafts/pull/4279/files
smfr: Problem with 0 as identity you get discontinuity of animating
from 0. 0 is no perspective and then you animate to non-0 and
it's super close. It's like scale(0) which is non-invertible.
perspective(0) should be like perspective(infinity)
AmeliaBR: Expecting perspective(0) to be same as infinitely large
which is no transformation. Does cause discontinuity when
moving from that to a very small value
dino: I don't think matters what we do. If you animate to 0 it's a
horrible result. Rather it disappears or infinity...it looks
bad
AmeliaBR: Just important to have a clear rule
dino: 0 = infinity is best user result even though it doesn't quite
make sense
Rossen: Where do we take this?
AmeliaBR: Do we accept Eric W. proposed edits?
dbaron: The discussion you were having made me feel like we'd be
better saying it's UA defined close range at some amount
slightly above 0 rather than say 0 is valid
dino: Should be clamped a fair way above 0. If you want to do
something good for user don't let them get close
TabAtkins: 0 not valid or valid and clamped upward
dbaron: I was saying not valid, but okay with clamp upward
TabAtkins: In general that's an open range and I don't like that.
Much prefer 0 is valid with a UA clamp to reasonable
minimum.
AmeliaBR: Agree we don't want UA dependent limits for parsing
validity. Actual rendering clamping upwards seems
reasonable
TabAtkins: Letting 0 be equivalent to a minimum value UA clamps to,
that's the best situation. That's our normal principle
for these ranges
AmeliaBR: TabAtkins will you make edits for this interpretation?
TabAtkins: Yeah
AmeliaBR: Other question is on impl and what do they do and who will
change
dino: webkit is willing to change. It's rendering time. CSS goes to
0, but won't paint as 0
TabAtkins: Agreed
mwoodrow: I think gecko would be willing to change but I'd like to
define it in the spec
TabAtkins: 1px?
mwoodrow: Fine
myles: Need to say if 0 returned by getComputedStyle?
TabAtkins: If it's a render time clamp getComputedStyle will be 0
AmeliaBR: As far as limit 1px should be valid and used on exact
math. 0px not exact math and somewhere in there browsers
are allowed to clamp rendering code
TabAtkins: Right now I don't think...I think every browser does 1px
and down below. Render depends on precision or when the
rendering library barfs. I'm fine with UA defined limit
with a suggestion of 1px. If we want defined 1px is a
nice thing to hit
florian: If we have a specific value it's not an open range anymore
Rossen: Proposal is?
TabAtkins: 0 is allowed with 1px being the render time clamp
Rossen: Objections?
RESOLVED: 0 is allowed with 1px being the render time clamp
Rossen: That's the top of the hour. Thank you for calling in. We'll
take the rest of the agenda for next week. Thank you and
talk to you in a week
Received on Thursday, 3 October 2019 09:32:42 UTC