- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Jun 2019 19:26:41 -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.
=========================================
CSS Syntax 3
------------
- There is a resolution to republish already, all that's left to do
is update the DoC before sending the request
CSS Multicol
------------
- The proposal to have column-fill behave more similar in paginated
and continuous contexts (Issue #4036) ran into conflicting
compat concerns where one solution would break pdf viewer to
print and the other would break webpage to print scenarios.
- On the call the group agreed that the way to solve both compat
concerns is to rollback the resolution in Issue #3224 (Improve
column-fill and make it backward-compatible). Not everyone
involved in the discussion of both 3224 and 4036 were on the
call so discussion will continue on GitHub.
Text Decoration
---------------
- RESOLVED: Update the spec so positive offsets are outward from the
text (Issue #4021: text-decoration level 4 clarification
on text-underline-offset positive/negative lengths)
- myles mentioned that in Safari's implementation of
text-underline-offset there was a clamp so that the underline
didn't go so high that it looked like a strikethrough. The group
was interested in getting this, and possibly not letting to get
too low, into spec text. Issue #4059 was filed to further refine
this proposal.
CSS Text
--------
- There's still not clear winner to decide Issue #3987 (Clarify
whether soft breaks exist at boundaries of an inline element
with `word-break:break-all`). fantasai will reach out to the
i18n working group to see if they have input.
Fill-Stroke, Filter Effects & Color 4
-------------------------------------
- RESOLVED: No change to spec [opacity can take a percent] (Issue
#3342: percentage opacity)
Backgrounds & Borders 3
-----------------------
- RESOLVED: No change to spec [computed value includes missing
autos] (Issue #2574: Computed value of background-size
includes missing autos)
- There needs to be a note in a centralized location clarifying that
computed value is not the same as specified values and detailing
the different purpose and usage.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jun/0005.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Dael Jackson
Brian Kardell
Peter Linss
Nigel Megitt
Melanie Richards
Florian Rivoal
Jen Simmons
Greg Whitworth
Eric Willigers
Fuqiao Xue
Regrets:
Christian Biesinger
Alan Stearns
Scribe: dael
CSS Syntax 3: Should we update the CR, or is there anything else we
should do before the update?
-------------------------------------------------------------------
Rossen: There was a ping for updated CR
Rossen: Looking through GH and issues doesn't seem to be open ones.
Anything holding us back from republish?
TabAtkins: No and I think we have a resolution I haven't gotten to it
fantasai: We have DoC and changes section and tests you wanted to
write?
TabAtkins: Have tests. Haven't written DOC but it's in github and
tagged correctly so it'll be copy/paste. Changes is up to
date
Rossen: Sounds like there's staff willing to help if things are ready
Rossen: Since we have a resolution no need for a new one. Just a
nudge to you TabAtkins
CSS Multicol
============
column-fill should behave more similarly in paginated and continuous
contexts
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4036
Rossen: Opened by dbaron. Is he on?
[silence]
Rossen: Can anyone take or should we wait?
florian: I can
florian: There is currently a difference between what happens to
columns in fragmented and non-fragmented context and
there's no constraint on height
florian: dbaron proposed to align fragmented context to
non-fragmented
florian: My reason why not is that the behavior specified in
fragmented context is the one pdf and print formatters
implemented interoperably. multicol in fragmented documents
is used a lot.
florian: If there wasn't a compat concern we could align but in
print we do have a dependency. I don't think they'll change
and I don't want to fork language. Based on that I suggest
don't
dbaron: Important difference is in browsers people care about print
being similar to on screen. If we leave this we end up with-
for multicols that happen to be in fragmented context and
don't fragment or for the last fragmented of a multicol in
fragmented context- you get different balancing then on
screen. Problematic. Mostly for when you print and it's not
fragmented and balancing on paper is different.
<fantasai> So basically we have two different, conflicting compat
constraints. :/
<AmeliaBR> Is “make browsers match print behavior” (for the last
fragment OR for no fragments) still an option?
Rossen: dbaron to visualize I'm assuming talking about multicol that
has auto balance and in the continuous space you have plenty
of height so no balance
dbaron: Yeah
Rossen: In print when we reach the last fragmented where the column
would otherwise fragmented to one per page we're not
balancing per fragmented we'll have 1 column per fragment
dbaron: Not sure what you mean. Confused me with last bit
Rossen: When we go to print and we have fragment now they have a
constrained height which triggers balancing
Rossen: Or did I mis-read?
Rossen: What is different between continuous medium and fragmented
<florian> this table has the summary:
https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-503648397
florian: 2 tables in GH, 2nd is correct. Unconstrained fragmented
with auto the columns don't balance.
florian: Would switch to balance columns when column fill is auto in
an unconstrained context. Can't have unbalanced column on
last page
Rossen: Balancing on last page in my case, it's only on last page
with current proposal?
florian: All pages including last.
florian: Currently it's all except last (I think)
<fantasai> I think the mistake in multicol was that continuous media
balances in cases where print does not, but I guess
that's not fixable...
dbaron: With column-fill:auto and unconstrained height you do not
balance on any page in fragmented context. In continuous you
balance
florian: Okay. I missed a step. I think print formatters balance on
every page but the last.
Rossen: That's...interesting. Almost opposite of proposal
florian: Proposal assumes spec says on non-last pages don't balance.
That's not what print impl do. They don't balance on last
page but do on others. Let me check spec
Rossen: Reason I looked at table as misleading you said for auto
balancing unconstrained if you're in fragmented and not last
you won't balance. If you're in fragmented context and last
you will balance. Continuous you always balance. Right
dbaron?
dbaron: In continuous you don't balance with auto and constrained.
Rossen: Unconstrained case. When you're in fragmented context but
not last fragmented you don't balance
florian: That's dbaron's table but spec says when value is auto you
fill sequentially
dbaron: Let me open spec. I think there's words. Not in value
definition.
Rossen: Sounds like in this case we print 4 pages with one column
and on last page we have 3 col and that's weird. We either
always or never balance. Half and half is weird.
dbaron: I think the previous resolution was also somewhat odd.
Reverting previous resolution gets us consistent state
Rossen: [missed]
florian: Which dbaron ?
Rossen: 3224?
dbaron: Yes
<Rossen> https://github.com/w3c/csswg-drafts/issues/3224
Rossen: This one ^
[everyone reads]
dbaron: Regarding florian's question on auto, I agree it's not clear
for unbalanaced. Clear for balance they are not. Balance
says [reads]
florian: What that means is not single column is filled, all filled.
But if you honor force break they have different heights.
Means you fill sequentially
dbaron: That's what I mean by not balanced in my table
florian: Except for last fragmented where not balance means fill
first column and stop
dbaron: With auto height?
florian: Yes
dbaron: Messy with auto height where have to define auto height calc
which can vary
florian: There's two behaviors for the no. Fill multiple and no
balance or fill a single column
dbaron: At a high level you might see those, but it's a result of
what auto-height calculation does
florian: What we'd lose with your proposal is ability on last page
to only fill first column. Or do you not lose that?
florian: If you have multi page and last has only enough to fill 2/3
of one column printers have 1 column and your proposal
there is 3
dbaron: Correct. Changed for continuous already in previous
resolution.
dbaron: There are cases where mutlicol is relatively small. You may
well print and it fits on one page
dbaron: So if you're in this case where previous resolution effects
and it fits on one page previous resolution only applies
before you print. After you print we do completely the
opposite. That's a major inconsistency
florian: True. Two problems. browser printing vs printing and pdf
printing vs printing
florian: What will save us if you called for auto it's okay and
[missed]
dbaron: Reality of printing in browsers users care about results
even if authors didn't
fantasai: I think florian says we've got two conflicting compat
constraints
dbaron: Three
fantasai: Ones I'm aware of is printing through pdf formatter and
printing through a browser should have same result. Other
is printing through a browser should have same result as
looking at page without printing.
dbaron: 2 web compat. One is PDF. Other is what led to 3224 which is
Chromium and Webkit did one thing and Gecko the other.
fantasai: So that's a 3rd
fantasai: What florian pointed out is because auto is not initial
it's possible 3rd between Chromium and others is not
incompat and we can revert
florian: That's possible. What I was saying is because balance is
initial most browsers will be on balance and when you print
it gets you the same thing. Don't change balance. For auto
behavior changes only if you haven't constrained. If you
constrained auto and balance do the same. If they do both
or neither we're safe.
dbaron: People leave things in code that didn't work
florian: True. I agree revert previous if we can. That's only sane
way. Would require WK and Chromium to change
Rossen: Opinions from WebKit or Chromium impl?
[silence]
dbaron: I think we could cycle back. I don't know if Morten is on
but he seems to know about Chromium limitation. There was
new information an hour before the call
florian: Sorry, just finished compat testing
dbaron: There's a new proposal, should let it cycle on the issue and
come back.
fantasai: Anyone else on the call with a concern or are we proposing
what florian and dbaron say?
Rossen: Proposal is revert resolution on issue #3224. With that we
leave discussion open for a week. When others can catch up
we can re-open the issue and try to resolve.
florian: sgtm
Text Decoration
===============
text-decoration level 4 clarification on text-underline-offset
positive/negative lengths
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4021
dbaron: The commenter is a Mozilla intern implementing
Rossen: Can you represent?
<myles> I can take it
<myles> if I can get my mic working
dbaron: Maybe emilio
fantasai: There's a text-underline-offset property that takes a
length to adjust underline position. Positive is inward
and negative is out. Negative goes down on an underline.
Safari impl opposite.
fantasai: Does something different.
fantasai: Property is positive values move outwards. Down for
horizontal text
fantasai: Seems fine to me. I don't understand what Safari is doing
dbaron: Sounds like which direction things move it.
dbaron: Apparently Safari treats negative as 0
fantasai: Okay
fantasai: I don't have a strong opinion. I'm fine if positive moves
outward
AmeliaBR: As someone with no experience I'd expect positive and
negative to map up/down consistent between under and
overline. Or I'd expect positive to be father from text.
Large values meaning closer to text for over and under
seems weird
<florian> agree with AmeliaBR
myles: Couple things. First I want to say when I implemented this
was an oversight not trying to thwart spec. We have a clamp
because worried about content spec underline and do offset
that looks like strikethrough but a browser without it looks
like underline and that changes meaning. We did it can't be
closer than baseline.
myles: Wanted to do other direction too but never got around to impl
that
myles: As far as positive and negative directions I believe they're
just flipped. That's and oversight, I'm sorry. Happy to
switch. But the person opened the issue said match Safari. I
don't have a preference here
<fantasai> myles, given Amelia's logic, I think it might have been a
good thing you misinterpreted the spec :)
jensimmons: On question on if positive moves away from text rather
than closer with margin and padding there's a cowpath in
author minds where if there's a border and you add
positive it moves away and negative is closer.
jensimmons: Instinct is Safari way makes more sense to author minds
fantasai: proposal: Change the spec. I think there has been good
arguments.
fantasai: Arguments against changing to match Safari?
Rossen: None against. Is what myles desc for clamping in spec? That
is good behavior to me and maybe to spec. That values can't
go beyond baseline in negative direction? Maybe something
like baseline+ascent in positive?
Rossen: Prevents underlines being used as strikethrough
fantasai: Separate issue so let's address separately. Good point,
let's close this.
<AmeliaBR> Agree these are separate issues. But +1 for a second
resolution to support clamping the used values to avoid
under/overline looking like strikethrough
<myles> Rossen: Should I open that issue or do you want to
fantasai: Proposal is update the spec so positive offsets are
outward from the text
Rossen: sgtm
Rossen: Objections?
RESOLVED: Update the spec so positive offsets are outward from the
text
<jensimmons> Thanks myles for "doing it backwards" so this would
come up and we could make it better!
fantasai: Thanks to myles for making a mistake, we have a better spec
fantasai: Second, I understand logic for having clamping. Happy to
add spec text, but need to think about reasonable limits.
ascent on upper is too high.
Rossen: Yep. Let's open as separate issue and figure out limits
myles: You want me to open?
Rossen: Please
Rossen: Anything else on this?
jensimmons: Preventing using it as a strikethrough: I'd love to see
clear interop and clear spec. That's exactly what
authors will try and do and if they're able in one and
get annoyed if they can't in another. I vote interop on
that whatever it is.
myles: I'm interested in this. You think there should be interop in
all browser try and prevent or don't? Or in specific algo for
limits?
jensimmons: Need to think more about what different limits might be.
If it's minor and technical I think doesn't matter. If
you can have a cool background for some text with
underline in one browser or not another that's a problem.
Rossen: I think there's consensus we want interop. Let's take this
conversation to the new issue and let's get to something
that can be implemented by all
fantasai: Want to point out jensimmons comments made me think it's
worth noting underline is under text not on top. Won't be
same as strike through.
Rossen: If same color it will be
fantasai: Could be reasons you want a thick underline that you
shift up.
Rossen: This is why we need a new issue. This is not a 4 minute
discussion
CSS Text
========
Clarify whether soft breaks exist at boundaries of an inline element
with `word-break:break-all`
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3897
fantasai: I don't know if we can resolve today. Issue is when you
have a span of text with word-break:break-all on it and
it's in a set of characters that would not break
fantasai: Clear that able to break between characters, but what
should happen at edges like first letter and previous
letter. Jonathan Kew posted an example. Browsers are
inconsistent
fantasai: Spec says when breaking between 2 characters you look at
breaking property on nearest common ancestor. Jonathan
argues how word-break is defined it reclassifies
characters so that definition doesn't apply. Have behavior
fall from re-classification
fantasai: break-all is Latin as CJK, keep-all is treat CJK as Latin
fantasai: There's also some related properties. line-break which
decides what rules in effect. If we do character based we
have asymmetric effects. Another thing is that one of the
fundamental line breaking is white-space and that uses
nears common ancestor def.
fantasai: Overview of considerations. This needs people to think
about it and try to figure out best cases. There were use
cases in favor of current spec. Nothing in favor of
proposal. Use cases are particularly welcome
Rossen: Thanks fantasai for summary. Issue has been kicked around
for some time now. How to make it more actionable?
dbaron: To what extent do you feel like compat is an issue vs this
is that impl haven't done well yet and you want to push
toward impl of spec?
fantasai: I don't think there is a web compat issue. It's making
sure impl of spec want to move forward in same direction
florian: I think it's in between. At first approx it doesn't seem
impl follow spec, but they don't follow alternative or each
other either. What they're closer to is difficult to say.
You could make arguments either way. We should make
everyone agree. I prefer the spec, but the alternative a
'b' in the last comment on the issue is sane but I like it
less. Don't like 'c'
<fantasai> Summary of the state of the issue -
https://github.com/w3c/csswg-drafts/issues/3897#issuecomment-505931859
Rossen: Give a week or try for progress?
fantasai: I don't have anything to add. If others have something to
add or want to think another week is good. Can try to ping
i18n WG
florian: Maybe rule C out. Then action impl to look at a and b to
see if one is harder
fantasai: Jonathan Kew advocated for c
florian: Oh, sorry.
Rossen: fantasai can you ping i18n group?
Rossen: Is b leading? No c? A is the spec. Seems people mostly
gravitate to c
florian: I like spec as-is. Can't advocate alternative is bad. I
would prefer not to change line-break.
Rossen: a or c
florian: I'd object to c. But we don't have a clear winner
Rossen: We'll ping people to chime in and look next week.
Fill-Stroke, Filter Effects & Color 4
=====================================
percentage opacity
------------------
github: https://github.com/w3c/csswg-drafts/issues/3342
ericwilligers: The argument is opacity can be percent or number.
Opacity property says same. Not browser impl that.
We're proposing to impl but want to ping other
browsers to make sure they're okay with it.
ericwilligers: To allow opacity to accept percent
AmeliaBR: Has anyone looked and found reason not to? Or has no one
prioritized?
myles: We're happy to adopt. Percent opacity is good in every context
Rossen: Other opinions or objections to resolve in favor of percent?
ericwilligers: Mozilla?
emilio: No strong opinion. Reasonable. As long as it doesn't cause a
conflict
ericwilligers: Serializes as a number
AmeliaBR: We don't have anywhere we're using opacity and they're
ambiguous. In color it's defined by position in param
list. In all others it's single value. No parsing concern
ericwilligers: Thanks everyone
AmeliaBR: It's resolve no change to spec.
Rossen: Prop: No change to spec
RESOLVED: No change to spec
Backgrounds and Borders 3
=========================
Computed value of background-size includes missing autos
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2574
emilio: The spec says the computed value includes the missing autos.
I think we don't need to impl if not relevant. Webkit and
Blink do that. I think Edge was with FF. There were wpt
tests depended on them.
TabAtkins: Agree. Should omit autos when not necessary. Irrelevant
to issue because that's about computed value.
Serialization is defined off of computed, but does not
match computed. The point of computed value is to get a
well structured value in specs. You serialize in shortest
value. I agree serialize without autos, but issue is
invalid.
emilio: Note to spec saying that?
AmeliaBR: Good explanation TabAtkins but if multiple implementors
misinterpret we need to explain it somewhere. Computed
value has auto for missing values but in serialization
dropped following shortest serialized.
TabAtkins: Should add a note in cascade which we link to when
talking about computed. We should have a specific note
this is not serialization rules.
AmeliaBR: Is it something the missing autos should be mentioned in
computed value line? If that's the as spec value has the
implied auto for unspec dimension ?
TabAtkins: That it's not there means it's not there. To talk about a
value we have to handle the full panoply of things or we
say computed value has all the possible things. Computed
values designed to be easy to work with and roughly model
interior.
<TabAtkins> clarify it here: https://drafts.csswg.org/css-cascade/#computed
fantasai: Computed value is not about serialization. We should
clarify that in a central place, not per property or here
specifically.
florian: That the method you call to get the serialization is
getComputedValue does confuse but what they say is true
Rossen: For CSS Backgrounds sounds like no change. Can we resolve on
that? If need to add text to Values or somewhere that's
great but I'd want us to make progress here.
TabAtkins: Yes, no change is valid.
Rossen: Objections to resolving no change?
RESOLVED: No change to spec
Rossen: That's the hour.
Rossen: Thanks for calling in
Received on Wednesday, 26 June 2019 23:27:36 UTC