- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 Aug 2018 21:25:57 -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 Inline
----------
- RESOLVED: Close this issue (#2926: Should dominant-baseline
inherit?) with no change to CSS Inline
- A new issue will be opened to determine how dominant-baseline
should behave in the presence of a writing mode change and if
there are other similar switches that may need to be examined.
- RESOLVED: Publish updated WD of css-inline-3
CSS Text
--------
- RESOLVED: Try a new rule in UA stylesheet and see how it impacts
rate of bugs for FF then come back to this (Issue #2951:
Having overflow-wrap: break-word affect min-content size
is not webcompatible)
CSS Fonts
---------
- RESOLVED: Have 'auto' follow platform conventions and add a new
value called 'unicode' to follow unicode conventions [
for font-variant-emoji] (Issue #1223)
- RESOLVED: Defer this issue (Issue #1289: Problem setting up a
"4-style family" with variable fonts) with issue #528
from last week
- RESOLVED: Add normative text describing this issue and being more
clear about how this all works with an example for how
things can go terribly wrong
CSS Scroll Snap
---------------
- RESOLVED: Add an auto value as the initial value and for auto
allow the agent to determine the padding size using a
heuristic they want (Issue #2929)
- Next week the group will resolve to republish CR once there is a
DoC written and any test edits necessary are in.
Grid L2
-------
- RESOLVED: Accept the diff in the issue [to support automatic grid
span for subgrids] (Issue #2565)
- RESOLVED: Publish a new WD of Grid L2
CSS Contain
-----------
- RESOLVED: Accept the PR that corrects this oversight [makes
contain:layout establish a staking context] (Issue #2942)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jul/0041.html
Present:
Rachel Andrew (IRC Only)
Tab Atkins
David Baron
Dave Cramer
Benjamin De Cock
Elika Etemad
Chris Harrelson
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Cameron McCormack
Xidorn Quan
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Eric Willigers
Fuqiao Xue
Regrets:
Angelo Cano
Emilio Cobos Álvarez
Tony Graham
Vladimir Levantovsky
Thierry Michel
Geoffrey Sneddon
Manuel Rego Casasnovas
Sean Voisen
Greg Whitworth
Scribe: dael
CSS Inline
==========
Should dominant-baseline inherit?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2926
fantasai: I don't remember if we resolved on this, but it's really
the only reasonable thing. As spec in SVG this has an auto
value that behaves like inherit but only on a text element.
fantasai: Seems awk design that's a result of not thinking about
inheritence. CSS inline L3 spec that dominant-baseline is
inherited value
fantasai: Wanted to ask for review and confirm
chris: This isn't so much inheritence it was more that once you
started a text run the font you set on that effected kinda
like underline when it effects the children. But if you can
make it work using inheritence that's fine, but that's why we
did it originally
fantasai: CSS modal I think we should use works that each element
has a dominant-baseline property generally same as parent
and that sets baseline to align own contents. When align
to parent uses alignment baseline which is different
property. I don't see need to inherit.
<chris> ok, sounds good
fantasai: If you want a baseline table that passes through changes
in font size etc to descendants I can see case for more
complex, but I don't think that's desired. I think you
want a localized baseline grid and then that whole thing
aligns to parent baseline table. Then you don't pass
baseline through multiple elements
chris: Fine to me.
fantasai: Okay
astearns: Any concern that 3 engines aren't making properties
inheritable?
fantasai: In SVG context the inheritence will be arcane. I don't
think most people will set on root SVG element. Once on
text element it does inherit. I don't think anyone is
changing OM value of dominant-baseline of a text element
in SVG. In general case behavior is identical. Weird cases
for a change and I don't expect them to be common
fantasai: That's my expectation, could be wrong
astearns: ericwilligers are you okay having dominant-baseline
inherit?
ericwilligers: Fine with it. It's what blink does. I can send a PR
for SVG spec to mention it's inherited.
fantasai: Also need to change auto value so it doesn't pretend to
inherit
astearns: Anything else on this?
astearns: Prop: Close this issue with no change to CSS Inline
astearns: Objections?
myles: Reset what dominant-baseline is at writing mode change?
fantasai: At writing mode change the dominant-baseline also changes.
myles: Isn't that what auto means? If someone sets to another value
you want to change at writing mode change
fantasai: That is an interesting idea. Don't know that it's strictly
necessary. I think you could argue you might want that to
happen, but it depends on writing system.
fantasai: If you have inline block with horizontal text you would
want it not to have central baseline in a vertical document
florian: Some kind of expanded version of dominant-baseline with two
values?
myles: No, not that. I think current behavior allows for this
fantasai: Currently initial value is auto and doesn't resolve to
anything. If you set to a different baseline it inherits
through orthogonal flow. For default case, that's typical
for Japanese or Chinese because it does the right thing
myles: I'm not sure saying auto works correctly means property is
correct. Maybe a new issue?
astearns: I was thinking new issue, but now I'm thinking that if we
do take from SVG that dominant doesn't inherit we can have
auto do the right thing. We're taking on complexity of
auto to solve a writing mode switch
fantasai: But when you switch writing modes and you set something
like mathematical baseline what do you expect at a writing
mode change? If what you want is to have alphabetic in
horizontal and central in vertical set to auto and it
works. If you set to mathematical-baseline what do we
propose to do other than mathematical. If it's the same as
before the writing mode change that's inherit
astearns: I suggest we define auto somewhat like SVG where auto
takes dominant-baseline of parent unless writing mode
change and if writing mode change auto takes standard
baseline for writing mode
myles: I was proposing something different. I was thinking that any
value for dominant-baseline would apply to all descendants
until a triggering condition makes it not apply
fantasai: What does not apply mean?
myles: On other side of trigger it resets to auto
fantasai: I don't think that is necessarily what you want. I don't
think it's worth the complexity to make this non-inherit.
That would be confusing because auto would have to look
deep in document trees if you set inside a root. You have
to go up the tree every time.
fantasai: And what would we gain? I don't think anything because I
don't think switching is always the right call. When we
want the writing mode to trigger a change in dominant is
switch between alphabetic or central and auto will do the
switch. Unless you set it to something else it will have
that behavior. I don't think resetting it is necessarily
the right answer
fantasai: No one has given me a clear use case where writing modes
should trigger a change in dominant-baseline except what's
covered in auto. Unless there's another use case it's not
worth doing.
dbaron: Is normal for Hindi and other Indic languages that you'd
want to set dominant-baseline to hanging?
astearns: No because fonts don't support. Indic uses alphabetic
baseline
myles: [missed] If you're using web fonts and you know it supports
you should
dbaron: If you're saying this works in auto and if for vertical
Chinese in a Hindi doc it doesn't work then it doesn't.
chris: To dbaron not all fonts support all baselines and it's more a
case that an occasional one does support.
chris: myles spoke about triggering conditions, which are other
triggering conditions? If it's just that one perhaps the 2
values florian suggested would be better?
myles: I don't know on other triggering. I haven't done research.
One property with 2 values seems a lot of added complexity.
fantasai: dbaron your case when switching Indic to Chinese when you
have a writing system change you want a baseline change.
Horizontal Chinese in an Indic doc you'd want Chinese to
have own dominant baseline. That's a writing system
change, not a writing mode change. Writing mode isn't
trigger you're looking for. Indic doc with hanging
baseline and both horizontal and vertical text would you
switch dominant-baseline for vertical Indic text would you
switch? I don't think so.
<dbaron> fantasai, that makes sense to me
astearns: I haven't heard anything that makes me thing we would keep
dominant-baseline from inheriting. I think we should open
a new issue for these switches and what happens. Is
everyone okay leaving this to another issue and close this
one?
myles: Fine
astearns: Everyone was interested, but it would be good to have this
as an issue.
<fantasai> proposed resolution: No change to css-inline,
dominant-baseline inherits and auto only switches between
alphabetic/central (not synthesizing inheritance)
florian: Fine. We can explore 2 value elsewhere
astearns: Objections to Close this issue with no change to CSS
Inline?
RESOLVED: Close this issue with no change to CSS Inline
Publish updated WD of css-inline-3
----------------------------------
astearns: Sounds good. We should do it
dauwhe: Approve
astearns: Objections to Publish updated WD of css-inline-3
RESOLVED: Publish updated WD of css-inline-3
CSS Text
========
Having overflow-wrap: break-word affect min-content size is not
webcompatible
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2951
xidorn: I put in the change to make overflow-wrap:break-word to
affect min content. We immediately got 4 bugs. fantasai
suggested we can make table reset the overflow-wrap to
normal which fixes 2 of them.
xidorn: I want to bring it to WG and see what we do next
florian: What are remaining 2? PHP manual thing was one?
florian: It looks like a strangely coded web page.
florian: What's last?
xidorn: I think fantasai and the [missed] said it was wrong use and
we can ignore
dbaron: We're talking about 4 bugs and it's on the nightly channel
fantasai: I'm not sure what to do. I think alternatives are terrible
but web compat is a problem
myles: We don't have a choice. 4 bugs on a nightly. Web compat is
more important
florian: I suggest we try the UA stylesheet change and see. If the
change on tables solves the general problem maybe we're
back. If not we have to do something else
frremy: My PoV I don't believe a quick change will fix. At MS we
have other issues we're seeing where we'd like to reconsider
word-break:break-word where we had websites change to
break-all and Edge breaks in the middle. I know we supported
not supporting it, but I'm becoming less convinced we can't.
So supporting break-word is an option on the table. We
should consider that as a part of this
fantasai: We have someone from the PHP site engaging on issue.
Example where table is not breaking, behavior they want
ideally is that you have 2 types of min-content? They want
table to wrap at normal word breaks but not in overflow
wrap cases unless it's necessary. If you look at example
there is text that could wrap more without breaking code
words and they expect those breaks take priority.
fantasai: Not sure where to go with that, but it occurred to me that
we're not handling that type of prioritization correctly
in general
florian: So I felt we did find 4 bugs and if we fix UA we fix 2 and
the other bugs were different
dbaron: Does the fix break what the sites were intending?
fantasai: Sites broken intended to not apply inside the table.
dbaron: I think you need to be careful on intent. A lot of sites
might have waned current behavior where it allows long
content to break
florian: Tables doesn't do that
dbaron: Okay
dbaron: because changes min-content
florian: Right, so table won't shrink to where it could break
fantasai: [sigh]
florian: I'd like Mozilla to try the UA stylesheet fix and see where
that gets us. Maybe not enough, but good to check.
florian: If that doesn't break the web more it provides a clean path
for new authors and maybe on top of that we still need
word-break:break-word for frremy's reasons
fantasai: Idea case maybe is that...One case was someone put content
in a 0 width container and said I'd like you to
word-break:break-word but shrink wrap took affect so it
didn't. Other cases it seems there's multi levels of
prioritization where we have 2 and authors would like 3.
That's a big thing to think about.
fantasai: Overflow-wrap breaks are de-prioritized in terms of when
we accept the break. We're not able to de-prioritize in
terms of min-content width.
fantasai: For word-break:break-word it's awful ergonomics for CSS to
add it. Authors are already confused on breaking prop and
what called
florian: That's why I think we should keep trying and maybe spec as
a corner
fantasai: If we have to revert this I'd prefer a keyword to
overflow-wrap that's the same as break-word but also
affects min-content like 'overflow-wrap-anywhere' that's
the same as word-break:break-word but lets author consider
like multiple properties. word-break:break-word and
word-wrap:break-word can't be combined
myles: Have we veered from original topic?
fantasai: Going back to this one
fantasai: I think it would be interesting to see if adding UA
stylesheet rule would make it tolerably compat, but I'm
not an impl so I'm not qualified to have an opinion for
how that would be as an experiment.
astearns: Given we don't have clear solution I think trying this in
browser stylesheet and getting more data is reasonable
next step
florian: Might not be enough but good start
astearns: xidorn and dbaron sound good to try?
xidorn: I think we can try that. Easy enough to add it
astearns: Objections to try a new rule in UA stylesheet and see how
it impacts rate of bugs for FF?
RESOLVED: Try a new rule in UA stylesheet and see how it impacts
rate of bugs for FF then come back to this
CSS Fonts
=========
font-variant-emoji property lacks an unopinionated, standardized
default
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1223
chris: Basically the thing with this is we describe auto which tries
to do 2 things. User agents may follow unicode or ignore them
and do what platform does. Seems like 2 use cases and you'll
have UA and platform variations. Some people might want to
say unicode is what we want, but you can't do that. You can
say mostly I have text or mostly I have emoji. We lack a 4th
value that says do what unicode does
myles: I think the idea of a new value is fine. It's fairly
important that our default matches platform so I agree can't
be default, but a new value for follow unicode is fine
chris: myles does that sound like it has impl complexity?
myles: I don't think that much. Property has some complexity, but
additional complexity isn't much bigger
<chris> ok
myles: Can't speak for other browsers
<chris> other implementors?
astearns: Do we also need a follow platform?
myles: Isn't that what auto is?
chris: At the moment auto isn't clear, but it I agree it should be
do what the platform does. That's closest to current impl
myles: Sounds good
astearns: All engines or is there an engine that's been taking
ambiguity in spec and it follows unicode
myles: As far as I know there are 0 impl
astearns: Proposal: Have auto follow platform conventions and add a
new value to follow unicode conventions
<chris> bikeshed the name?
fantasai: Call it normal? The new one. Auto is more magic, normal is
follow a convention. There's probably a better name
myles: Unicode? Or resolve without name?
chris: Let's not resolve unless we're stuck. I think unicode is
better
astearns: Objections to unicode as the name?
[none]
astearns: Proposal: Have auto follow platform conventions and add a
new value called unicode to follow unicode conventions
RESOLVED: Have 'auto' follow platform conventions and add a new
value called 'unicode' to follow unicode conventions
Problem setting up a "4-style family" with variable fonts
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1289
florian: I think it's a duplicate of something we deferred last
week. It was...
chris: 528
florian: Yes.
astearns: Objections to deferring this with issue #528 from last
week?
RESOLVED: Defer this with issue #528 from last week
issues with font-family descriptor in @font-palette-values rule
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1669
chris: I think basic problem is spec says if you say font-family it
will be unique IDed. Fine for fallback between different
families. Composite font there is no guarantee there is the
same palette with same palette values.
myles: Proposal to solve? I think as-is is fine and authors should
make composite fonts correctly.
chris: Other cases where users can come up with their own values and
map with @font-face, but that's a lot of complexity. Maybe
allow it to be an @font-face and define it there...not sure.
Worried about too complex
myles: Agree. Worried about making this really complicated.
myles: I think there are a couple different @rules that apply to a
font-family by name. If this is a problem here it's for the
other like font-feature-values
chris: Yeah, exactly. That one too.
myles: Another point, there can be different items in source list
and you could want this specific to an item in the source
list, but that's crazy. This is finding the right line in the
middle.
chris: If you do silly things you get strange results.
myles: That's my thought
astearns: Proposal is to close this no change?
myles: I could add normative text
myles: that makes it clear each of these are applied to each
@font-face that share a family name. There's 2 parts to this
issue and part 1 is 'I'm confused' part 2 is 'is this
valuable'. Part 2 we said no so let's describe
astearns: An example of how things can go wrong would be good.
myles: Sure.
astearns: Proposal: Add normative text describing this issue and
being more clear about how this all works with an example
for how things can go terribly wrong
<fantasai> sgtm
astearns: Objections?
RESOLVED: Add normative text describing this issue and being more
clear about how this all works with an example for how
things can go terribly wrong
CSS Scroll Snap
===============
Different browsers implement keypress scrolling differently
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2929
TabAtkins: Right now scroll-padding initial is 0 indicating no
special padding is applied. FF has heuristics where it
tries to detect like a fixed header and subtracts that
from its page scrolling operations. Suggested we should
allow those and then adjust initial value to reflect that
initial scroll padding may be impacted so change initial
to auto
fantasai: So set to 0 or anything else browser heuristics are set
off as opposed to having heuristics + your padding which
is not what wanted.
florian: sgtm
TabAtkins: Majid our implementor is fine, suggested by FF, so 2
browsers say cool
myles: Proposal is add an auto value?
TabAtkins: Add an auto value, make it initial, and define as roughly
0 but browser may impose heuristics with a description of
sort of heuristics
myles: Sounds great. Def do that
fantasai: 100% to do this
florian: Revisit in a few years
myles: Not spec exact heuristics
florian: Yes, if converge then standardize
astearns: Proposal: add an auto value as the initial value and for
auto allow the agent to determine the padding size using a
heuristic they want
astearns: Objections?
RESOLVED: Add an auto value as the initial value and for auto allow
the agent to determine the padding size using a heuristic
they want
Publication
-----------
fantasai: Approval to update CR one edits in?
astearns: I expect tests need updating that are checking initial
value
florian: Don't know if we have much test suite
fantasai: Majid would have those tests
astearns: No other scroll-snap issues?
fantasai: One deferred, one close no fix, another was unclear as to
if a feature request. There has been no response to my
clarification question for months.
astearns: DoC ready?
fantasai: No, but can make one quick.
astearns: Let's ask Majid about tests, someone does DoC and we
resolve to update next week
fantasai: Sounds good
Grid L2
=======
support automatic grid span for subgrids?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2565
fantasai: Suggestion was we used to have ability to have automatic
grid span. In grid L1 that resolves to span is 1. When you
have subgrid you can say it should resolve to number of
tracks in subgrid. Mats suggested we do that. Do we want
to?
TabAtkins: I think it's a nice feature. You expressed span in
subgrid so seems reasonable
<florian> seems pretty reasonable. And there isn't really any other
useful thing we should do. So yes
astearns: Seems okay to me
astearns: Anyone against?
astearns: Proposal: Accept the diff in the issue
astearns: Objections?
RESOLVED: Accept the diff in the issue
Publication
-----------
astearns: Objections to a new WD of Grid L2?
<chris> +1 to grid 2 wd
RESOLVED: Publish a new WD of Grid L2
CSS Contain
===========
Is it ok that contain:layout is a CB for fixpos/abspos descendants but
doesn't establish a stacking context?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2942
florian: Contain:layout sets the element to be a containing block
for lots of things, but didn't say it establishes stacking.
This would be a first time we would have something like
this that's not stacking, so let's do it as stacking.
TabAtkins: And it wasn't intentional, accidental tying concepts and
didn't realize.
astearns: Not seeing objections in issue.
astearns: Objections?
RESOLVED: Accept the PR that corrects this oversight
astearns: Talk to y'all next week!
Received on Thursday, 2 August 2018 01:26:52 UTC