- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Mar 2019 19:34:12 -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.
=========================================
Scroll Snap
-----------
- RESOLVED: Publish updated CR for Scroll Snap
CSS Fonts
---------
- RESOLVED: Void the previous resolution and close no change (Issue
#3675: Font-family name matching requires full Unicode
case comparison)
CSS Grid
--------
- RESOLVED: Make the same result for min content sizing apply to
automatic minimums (Issue #2674: Resolving percentage
heights of grid items during min-content sizing)
- RESOLVED: Change the algorithm take baseline from the first grid
content instead of synthesize from first row (Issue
#3645: Unintentional change to grid container baseline?)
CSS Lists
---------
- RESOLVED: Go with fantasai proposal (option a) for initial value
of counter increment (Issue #3686: Initial value of
counter-increment needs to be something different from
none)
CSS Multicol
------------
- RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/3649
(refer to columns not tracks)
CSS Text
--------
- There is still concern that the proposed solution for issue #337
(Segment Break Transformation Rules for East Asian Width
property of A) relies on a unicode property that the unicode
consortium isn't particularly maintaining. The counter argument
is that the subset of properties this proposal creates will
continue to be correct, even if the definition changes. A few
working group members will reach out to unicode contacts to
garner more feedback to lead to a decision.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0000.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Dave Cramer
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Chris Lilley
Peter Linss
Myles Maxfield
Manuel Rego Casasnovas
François Remy
Florian Rivoal
Jen Simmons
Alan Stearns
Greg Whitworth (IRC Only)
Fuqiao Xue
Regrets:
Lea Verou
Scribe: dael
astearns: We've got enough to go on
astearns: Thanks everybody for calling in at the weird time
astearns: Does anyone have any extra things to add or changes to
make?
Scroll Snap republication
=========================
github: https://github.com/w3c/csswg-drafts/issues/3721#issuecomment-471783264
fantasai: Made some spec clarification to make implications easier
to notice. Clearly editorial, asking for repub
astearns: What about the issue from jonjohnjohnson?
fantasai: That's filed against CSSOM View spec. If that needs
clarification I didn't fix anything in there. I just fixed
scrollsnap
fantasai: Updated CR
astearns: There is a change list and DoC?
fantasai: There was only one comment which was mine. DoC seemed
excessive
astearns: Should have a changes list so when we repub people know
it's one thing
<fantasai> https://drafts.csswg.org/css-scroll-snap-1/#changes
fantasai: Here it is ^
astearns: Just editorial or any test changes?
fantasai: No normative implications. Emphasizing points on stuff we
agreed
astearns: Comments on updating?
<florian> I have reviewed the change and support it.
astearns: I see florian supports
astearns: Objections to Publish updated CR for Scroll Snap?
RESOLVED: Publish updated CR for Scroll Snap
CSS Fonts
=========
Font-family name matching requires full Unicode case comparison
(reconsider FTF resolution)
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3675#issuecomment-468238875
astearns: Got feedback maybe resolution wasn't best
myles: Anyone on the call not at F2F and has opinions?
chris: I wasn't. I agree most impl do full unicode case folding and
ascii only case folding will give odd results. Myles you said
WK hasn't adhered
myles: True on iOS and OSX
chris: You sure it's a big performance regression? People are saying
it wasn't
myles: Haven't measured because haven't impl.
chris: But you do have the function call
florian: At the F2F mentioned the other function is not called
anywhere in WK codebase
myles: I don't have anything new that I didn't bring up. We've never
had behavior and never had compat problems. Doesn't seem need
to slow down browser.
AmeliaBR: Main new information is that when we resolved it was based
on other impl doing quick look and saying I think we do
this but in issue people who know better say no we follow
the spec and they're concerned about changing
fantasai: We do have concerns from i18n as well
chris: CSS does ascii only case folding for syntax but for this the
font name can be anything and is usually localized. But most
scripts don't have two cases
florian: Mostly Cyrillic and Greek?
fantasai: No because accented Latin is also outside ascii
florian: I think in practice concern will be less accented Latin
then Cyrillic
florian: It's not that it will not happen, just more common to have
problems in Cyrillic. Could be in all sorts of places
astearns: Interesting there haven't been reported compat issues
given this incompat in code bases. I wonder if people
modify to work around this
chris: Could be, it was interesting that Android matches on a
Latin-only xml font database, so people munge the fonts names
to Latin there
dbaron: People use different fonts on different platforms so there
may be a compat issue on other platforms
myles: Would other browsers be interested in speeding this up in
their impl?
[silence]
astearns: Given issue comments I doubt this is the case.
fantasai: Given no one is seriously concerned about performance. We
have existing impl that are aligned and it's the right
thing to do from i18n view it seems we should not make
this change and keep spec as is with full unicode case
folding
florian: Agree and at same time I would also understand if Apple
didn't prioritize this
<dbaron> I agree with fantasai as well.
myles: Like I said we don't have compat issues
fantasai: If we had interop on ascii only and there was performance
concerns I would understand. But apparently neither is
true so we should do the right thing
chris: I agree. It would be interesting to know where there are
compat issues, like actual fonts used on the web that give
different results without the unicode case folding. We can
punt that to i18n and request examples
myles: Not sure if it's worth it, but we can do it
chris: If there are no examples then it doesn't matter and impl
might want to use simpler. If there are examples it might
persuade you down the line where we didn't realize we were
disadvantaging someone. Maybe there is a community with a
problem, maybe there isn't
astearns: myles are you okay reverting previous and close no change?
myles: yes
astearns: Objections to void the previous resolution and close no
change?
RESOLVED: Void the previous resolution and close no change
astearns: If new information comes up we can look at it
CSS Grid
========
Resolving percentage heights of grid items during min-content
sizing (review last fix)
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2674#issuecomment-465490328
<fantasai> https://github.com/w3c/csswg-drafts/commit/534f79283a4687a5f0bc722baed5792e2c54433a
fantasai: There's some sizing rules where we decided percentages
resolve to 0 something depending on when you're tacking
intrinsic sizes. Clarifies the 0 basis also applies for
automatic min size so that it ends up being definite
fantasai: Automatic min size is a derivation of min content sizing
so this is saying same rules for min-content sizing apply
to automatic minimum
astearns: Reasonable to me
astearns: Other comments or concerns?
astearns: Objections to make the same result for min content sizing
apply to automatic minimums
RESOLVED: Make the same result for min content sizing apply to
automatic minimums
Consider setting base sizes to growth limits when sizing under
max-content constraint
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3646
astearns: Discussed at F2F. Didn't conclude. Is there new
information or kick to issue?
fantasai: Kick to issue for a bit. jensimmons and rachelandrew
wanted to think more and I need to fold in #3648 changes
which are related
<jensimmons> sounds good to me
astearns: Anything else to bring up about this?
astearns: I'll take agenda+ off
Unintentional change to grid container baseline?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3645
fantasai: Error I want to revert at least. What would we expect
baseline alignment of grid with a single item in 2nd row.
We can use the first item in the first row for where we
derive baseline from
fantasai: I think we should do the baseline of the first available
grid item even if not on first row, but wanted to check
astearns: Prefer FF behavior. Better to take baselines we have then
punt
astearns: Looking through comments to see if anybody disagrees
astearns: Only thing Javier brings up is if there's no content in
first track you can synthesize
fantasai: If no content in grid we synthesize.
fantasai: Question is if we have an empty row do we look at next row?
AmeliaBR: When first item is it grid layout order?
fantasai: Yes
AmeliaBR: First item in DOM is in a different row we skip over that
and focus on rows and columns?
fantasai: Yes
astearns: Looks like I was confused on rows and columns
astearns: There's an actual difference in opinion between impl
fantasai: jensimmons rachelandrew opinions?
jensimmons: Not really
astearns: If the first track is empty then is the design using that
track for space?
astearns: In which case does aligning grid on 2nd track baseline
void that decision?
fantasai: If you're using it for space, we've seen cases to use
first track to make padding, seems reasonable to use the
content of the 2nd row in that case
astearns: First track is for padding if grid is not baseline align?
fantasai: We have a grid with an empty first row and content in 2nd
row. Do we treat this grid as not having baseline or do we
take baseline from 2nd row. That's the question
jensimmons: How would that effect sizing of first row?
fantasai: Doesn't. Effects how that grid aligns with other content.
If you have grid inside a table cell and another grid next
to it
rachelandrew: In that example 2nd row makes sense. It does seem
using first row as padding is the common case. Trying
to think if other cases
<gregwhitworth> Agreed with fantasai and rachelandrew
astearns: If you have 2 grids in adjacent table cells and you are
using the first row for space in the first grid and both
have a BG color so you can see the space added if those 2
are not baseline aligned then the content in the first is
pushed down by the amount of first row. If you do baseline
align the 2 table cells the first grid's space is
maintained and push table height up in FF case. In chrome
case space is maintained and push table cell height down
astearns: That's the case for this in a concrete case
[mic problems with someone]
astearns: I think it does make a bit more sense to take baseline
from first available content in the grid. I don't know
that it is something that is going to be used often.
Probably an edge case that will not come up often
jensimmons: I think it might come up. Not sure edge case. I can see
real world use cases for this. Not 2 grid items in a
table cell, but 2 grid items in a grid
astearns: Or a flex container. Or if we get to baseline aligning in
other cases
jensimmons: Options is align second row with other grid or...?
astearns: Options are at moment algorithm says you take baseline of
content in first row and if there isn't you synthesize. So
if first row is empty spec says you synthesize a baseline.
Considering saying take first content in grid and use that
for baseline
jensimmons: Result of synthesization? Just make up a line? I guess
yes
rachelandrew: I can think of using baseline of first content item,
that can be explained. You can say you haven't got
content in the first track so we're using first item
to work out baseline. Being worked out on something
that doesn't exist is harder to explain. As someone
who explains this stuff to people it's easier to work
off first item that appears
jensimmons: Lean that way too. I can see where people would make
separate grids, put in a grid, and then align baselines.
At this point you can't have an empty row with a visual
thing. But if we get to where you can style grid rows
there's a case to show on nothingness
astearns: Will show if there's border or BG
jensimmons: I lean toward do the first row with content in it. That
makes sense as an author. I think that's what
rachelandrew is saying
astearns: Converging on take baseline from the first grid content
instead of synthesize from first row
astearns: Objections to take baseline from the first grid content
instead of synthesize from first row and see how Blink and
WK impl take to it?
<jensimmons> I also think this makes baseline alignment more useful
RESOLVED: Change the algorithm take baseline from the first grid
content instead of synthesize from first row
CSS Lists
=========
Initial value of counter-increment needs to be something different
from none (three proposals)
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3686#issuecomment-468098431
TabAtkins: Discussion about what to do with initial value of counter
to handle default list item. Few possibilities from F2F,
but couldn't decide. dbaron helpfully wrote them.
TabAtkins: Reviewing them I believe fantasai's approach is best
TabAtkins: Proposal: if an element has display list item default
list item counter is incremented unless counter increment
already says something about that item. If you want to
pause you can set counter-increment list item 0 and it
will work
TabAtkins: dbaron proposal is we can pretend it always adds a
counter increment of 1 and you just stack them if you
repeat. So if you want to pause count you would say list
item -1. Canceling out is useful for impl value attribute.
TabAtkins: I don't like that because it looks a lot more confusing.
A -1 making it not increment is interesting. fantasai's
proposal is most similar to UA impl list via UA styles.
Still some magic but for most part it seems UA generated
and you can interact with it in the same way
TabAtkins: I think we should go with fantasai's proposal and I can
write it into the spec
AmeliaBR: This is the version where if you want to set the list item
to a spec value you have to explicitly say 0 increment on
the list item?
TabAtkins: Yes if you're doing this by yourself. You use counter-set
to set to a value and then set the 0. Works the same as a
normal counter you define on your own
<fantasai> Original thread on this issue , from 2007:
https://lists.w3.org/Archives/Public/www-style/2007Oct/0100.html
astearns: dbaron opinion?
dbaron: Fine with fantasai proposal
astearns: Objections to going with fantasai proposal for initial
value of counter increment?
RESOLVED: Go with fantasai proposal (option a) for initial value of
counter increment
CSS Multicol
============
pseudo-algorithm refers to "track size", terminology not already used
in the spec
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3649
rachelandrew: Reading spec with authors. This is the first time
track size mentioned in spec. Aim was to unify how
sizing works but tracks isn't useful for multicol.
Wanted to bring up since it was added with a
resolution. I put sample wording in the issue
astearns: Not changing effect of resolution, just the term?
rachelandrew: Yeah
florian: I've looked at that and if you assume tracks=columns it's
clear but if you leave the two terms it confuses everything
astearns: Objections?
<fantasai> sgtm
RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/3649
(refer to columns not tracks)
CSS Text
========
Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/337
fantasai: Leftover from F2F so probably get rid of
astearns: This is definitely a better in the room discussion. Don't
know if we want to wait 3 months
fantasai: I'd like to get text to CR before that but this is main
issue blocking CR
astearns: How do we get to resolution?
fantasai: I think current text is fine. I don't know if anyone has
issues. I think myles is not happy
myles: Yep
fantasai: Dunno where to go from there
florian: Support current text.
astearns: myles do you have a suggestion to improve?
myles: Not concretely but using a solution from unicode where
experts agree won't work well and doesn't have semantic
meaning seems wrong direction. We would work with unicode to
come up with classes we need
florian: We're the only user of that thing b/c relates to how css
and html wrap lines or source code. So if we're not doing
effort they're not either. Solving this usefully for most
cases is sufficient to be useful. I hear what you're saying
but it seems like this is the perfect as the enemy of the
good
myles: We're using this to determine where to unbreak lines. Knowing
if character or parts of scripts use spaces is useful for any
text editor. And I think that, you're right that perfect
enemy of good is not the best way to create the web but I'm
worried we'll come up with a busted solution and be stuck
forever
florian: Not too worried because we're not trying to solve entire
problem but instead a useful chunk. I think the defined
part is safe. If we look for areas of unicode we can find
where we should have used more but we're using a safe
subset. If unicode does better in the future it will
include what we defined
myles: If we encourage authors in cjk to add new lines in source
code we need interop
florian: Oh yeah, we do. The part we have is safe to get interop on.
What I mean is that I don't foresee given the subset we're
defining I don't see us having to remove from it. Having to
add to it maybe, but not remove.
myles: If we're considering this solved and say to authors add line
breaks where you want it will be wrong in many places and
those in the future will change when we have better solution
florian: That's the thing I think will not happen. If we later
expand we will create new places where they can break, but
the places we're offering here will stay. If you find such
a thing please call it out. I think we will find other
places in unicode where we can add breaks, but I don't
think we'll remove from the current list. So there's no
risk in that sense
astearns: Risk is limited to if the current attempt at fixing a
subset is a true subset of the eventual good solution or
not
astearns: I don't have a way of evaluating if what we have now is a
true subset
astearns: One question - does anyone know if current proposed rules
are enough for a native Japanese author who has no idea of
anything to do with unicode and they're just writing
Japanese is there a set of rules for this author that
would make sense? Can we tell them you can put line breaks
where you want or is it complicated?
florian: For Japanese it's mostly straightforward when writing text.
If you're doing dingbats in the middle it gets weird. In
text it's fine. Dingbats isn't Japanese specific, they just
get weird.
astearns: I have not read whole thread, it is long. Have we had
anyone from unicode give a thumbs up that this is a safe
subset?
florian: Had conversation with unicode but mostly off topic because
they didn't understand what we were trying to do
myles: That convo the expert didn't comment about the specific
modification in the spec right now, but said properties these
modifications are based off of....I don't want to put words
in their mouth but they said it was fairly broken
fantasai: And they broke it even more recently
myles: Seems like the wrong thing to base on
fantasai: We're working around that by ignoring a subset of
characters they decided to change
fantasai: If we're gonna do anything like this, this is the set of
properties. Alternative is ask unicode for a new prop
which seems unlikely
myles: Not necessarily just this purpose. Knowing if char are part
of a script that uses space as line breaks is useful. Spec
says [reads]
myles: It just seems like we're patching a broken system and we
should try and solve properly
florian: Not just special cases. A large chunk of the spec text is
the necessary conditionals to make sure we're in the right
language. This new fabled unicode thing wouldn't know what
lang you're in. That part would stay in CSS. If we're
keying off [missed] it could be better from unicode, but
keying from language cannot
astearns: Agree with myles that I'm a bit worried about referring to
a thing in unicode that they want deprecated and don't
care enough to prevent it from having changes. If this is
something unicode is not interested in keeping stable we
shouldn't reference it
florian: Therefore we don't solve?
astearns: We work with unicode to come up with something they want
to maintain and contribute expertise so we can come up
with better handling that's maintained and can rely on
florian: It's not marked as deprecated. It's in the spec they're
theoretically maintained and they're doing a bad job of it.
We can start paying attention and raise issues. Their
opinion is that in current shape it's not useful, but it's
still in the spec
astearns: This will need to kick back to the issue for discussion.
I'll see if we can get Ken to engage on the particular
problem we're trying to resolve
fantasai: Maybe reach out to other unicode people too
astearns: Suggestions on who?
fantasai: myles had Apple's contact. We've got other people from
unicode. I'll try and reach out
astearns: I think that's where we'll leave this
astearns: Thanks everyone for calling and we'll talk next week
Received on Wednesday, 13 March 2019 23:35:12 UTC