- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Aug 2019 19:22: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.
=========================================
Rechartering
------------
- Charter issue #219 ( https://github.com/w3c/charter-drafts/issues/219 )
needs to be resolved before the charter goes for approval since
no one is happy with the current horizontal review text
Writing Modes
-------------
- The implementation report has been updated
https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
Implementors are requested to review to see if any of the
changes are small bug fixes that can be addressed quickly and
easily
- The unintentionally dropped text about sizing orthogonal flows
(Issue #4220) was edited back into the spec for review:
https://drafts.csswg.org/css-writing-modes-3/#orthogonal-layout
- RESOLVED: Republish Writing Modes L3 with added/missing section
for orthogonal writing modes provided no issues raised
before Friday
CSS Images
----------
- RESOLVED: Loading images are not invalid but treated similarly as
explained in https://drafts.csswg.org/css-images-3/#image-values
(Issue #1984: Specify fallback behavior when replaced or
background image content not available)
- RESOLVED: Republish CR of CSS Images 3
CSS Color Adjust
----------------
- RESOLVED: background-color computes to the system background-color
for all values but the alpha channel (Issue #4175:
background-color in forced color modes needs more than a
simple unset)
Quick intro to content-size
---------------------------
- TabAtkins briefly introduced the proposal for content-size
http://tabatkins.github.io/specs/css-content-size/ so that
people could review in advance of a longer discussion. Comments
can also be added to github issue #4229
CSS Fonts
---------
- myles introduced the proposal to add system-ui-serif,
system-ui-monospaced, and system-ui-rounded in order to
reference the new fonts introduced in iOS and macOS (Issue #4107)
- The fallbacks need to be clearly defined for these values
- Environmental variables should also be investigated as a
possible solution to this use case
- There wasn't time for a full conversation so this will be
discussed on next week's call
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0007.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Florian Rivoal
Devin Rousso
Jen Simmons
Alan Stearns
Lea Verou
Fuqiao Xue
Regrets:
Brian Kardell
Melanie Richards
Greg Whitworth
Scribe: dael
astearns: Does anybody have extra things for the agenda?
astearns: I do
<astearns> https://wiki.csswg.org/planning/tpac-2019
astearns: We have a meeting coming up with 10 people attending and 2
items ^-^
astearns: If that seems small to anyone else please add agenda items
and yourself to those planning on attending
Rechartering
============
<chris> charter status 3 issues closed
https://github.com/w3c/charter-drafts/issues/230
https://github.com/w3c/charter-drafts/issues/229
https://github.com/w3c/charter-drafts/issues/228 one open
but not blocking https://github.com/w3c/charter-drafts/issues/219
astearns: Little changes going in
astearns: xfq anything to add?
xfq: I saw chris sent some links
xfq: W3C management has reviewed charter. If no one objects to
charter in 24hr we'll extend current charter to end of sept and
put new charter for AC review
xfq: 2 unresolved issues. One is 219 about horizontal review
<xfq> https://github.com/w3c/strategy/issues/188#issuecomment-523071407
xfq: Other is ^
xfq: Richard hopes for more completion dates for specs related to
i18n users including text, text-decor, ruby [missed some of the
list]
chris: Seems similar to 228 and seems a request to work on it rather
then surely you must have dates. Don't know how to answer
differently
florian: I'd like 219 addressed before charter sent for review.
Current text is not what other horizontal review WGs asking
for. Richard explains what he wants and current text
doesn't do that and constrains us beyond requirements. I
don't see why we should go with the text we don't want. If
we can't find text we want we should go with process. Seems
reasonable to agree with Richard but no text for that
florian: Either wait for text or go with nothing. Having text we
don't want isn't great
chris: Agree. Text is from charter template, though. Can you express
your opinion on the github issue and raise this on the
template?
florian: Can you see if my last comment is enough for my objection?
I will follow up on template
chris: You haven't expressed urgency.
<xfq> +1 to chris
florian: Will do. Thank you.
florian: Thank you for all the work xfq and chris
chris: xfq did most of the work
Rossen: Is that everything?
xfq: Yes, on my side
Writing Modes Update
====================
Dropped definition of automatic block sizing
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4220
Rossen: fantasai I think you raised an issue about part of a chapter
being dropped and it warrants a republication?
Rossen: Is fantasai on?
fantasai: Section about how to size orthogonal flow was dropped.
There is a section on available space, but not sizing.
Need to put that section back.
fantasai: It was dropped with text about multi-col.
Rossen: Editorial mistake during the update? Or did we resolve?
fantasai: Resolution was to drop everything at risk which does not
include sizing block elements in orthogonal flow. Without
that you interpret rules quite differently
Rossen: Don't disagree this is core functionality on how we size.
I'm surprised we had it out of the spec so far and just
discovering it's out.
fantasai: Also surprised, but I don't know.
dbaron: Also feels like we should have a chance to review it again
since there has been lots of spec review with it out.
fantasai: Sure. But what is dropped was related to what's
implemented. Without that text we do not match
implementations
florian: It's in L4 right?
fantasai: Text is in L4 but it's...its embedded in multicol text. It
says this is what you do if you support multicol and this
is what you do if you don't. Then we made multicol a may
and the alternative behavior ended up dropped as well
fantasai: If you want I can do that
AmeliaBR: I think question was is this missing from both L3 and L4?
fantasai: L4 includes all the text
florian: dbaron said we need to review again and we have as part of
L4? Given it has been part of a CR spec we don't need to
heavily review
dbaron: L3 and L4 have had different amounts of review
fantasai: If anyone reviewed the spec and paid attention to this
part they would have noticed it does not match impl
<tantek> that sounds bad (that nobody noticed)
dbaron: I think add it back, but I'd like to look at it.
fantasai: Of course
Rossen: Review before merge into L3?
dbaron: No.
dbaron: I'd like to look before it's a new CR
Rossen: For sure
Rossen: Let's add the missing section back.
Rossen: We can come back next week. Are we close to republish CR?
florian: We just did. This is only issue since. Should be close to
republish
Rossen: What would this section mean from testing PoV?
<florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08
florian: That's the next topic; I have just compiled the impl report
florian: I have not checked if the tests aligned with presence or
absence of that section. I only reviewed failing tests for
correctness.
florian: We have ~1200 tests and ~25 are mandatory and lack 2 impl
florian: Some is related to recent fix about propagating from body
to root at used time. A few are sizing in orthogonal flow
and I think there's work planned to fix.
florian: One large-ish problem is orthogonal table cells have
problems. Edge reasonably well, FF with some problems, WK
and Blink don't do it.
florian: There are small corner cases we might decide to overlook.
Not quite PR but may be close
Rossen: Thank you for putting this together
Rossen: I'm expecting new section might require additional tests
florian: Have tests for that area, if need verified need to decide
Rossen: With that we can see if we need to address the 18 with
mandatory pass of 2+
<florian> https://drafts.csswg.org/css-writing-modes-3/implementation-report-2019-08#pb
florian: I encourage impl to look at the report. 1st section with
detailed results is the list of things that need to fix
before move forward. If you can look and see if there's
anything easy to fix it would be appreciated
florian: It's not that many
Rossen: That's a reasonable ask
Rossen: The things that would have put a pause for me are table
related. From impl PoV tables were particularly rusty when
we had to impl writing modes. Should be something we can
hope to impl in Blink once layout has enough wind behind it
for purposes of common-based browsers. Hopefully FF and WK
can follow
florian: FF is closer. WK does not support orthogonal table flows.
FF only has problems with sizing, rest works.
<dbaron> Firefox table-cell issues are related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1231656 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1244601
Rossen: Case where orthogonal cell sizing is titchy. Missing section
will help
Rossen: In summary; we have a number of cases impl should go back
and look to see what can be done to address in short term.
If they're bug level I hope people can address soon. If
major refactor we need another conversation about if we
insist on those cases to pass or if we push the spec with
the fails
Rossen: We'll give it a week for dbaron and anyone else to look at
the dropped section we're going to add and then we'll have a
resolution to add it next call.
florian: Didn't we say add now and discuss republish next week?
Rossen: We don't gain anything by doing that. I'd prefer anyone has
opportunity for feedback before we do editorial
florian: Easier to read if it's edited in
<chris> yes, easier to read in-place
Rossen: Missing section is clear in the PR fantasai pasted. It's
self-contained
florian: What fantasai pasted is a deletion that deletes too much.
Only parts need to be added back. I'd rather an editor
decide what parts.
<dbaron> I agree with Florian
Rossen: Fair. If we can prepare PR for added section that would be
great.
Rossen: fantasai will you handle this?
Rossen: I'm hoping you're saying yes to a muted mic
fantasai: Yes I'll do it today
Rossen: Thanks florian for taking time to piece together impl
report. It's super helpful. Hopefully make progress before
TPAC.
Rossen: One more nudge to impl to look at failing test cases
CSS Images
==========
Specify fallback behavior when replaced or background image content
not available
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1984
fantasai: Just waiting on myles to review
myles: I did review and commented on issue
Rossen: Said it looks fine
Rossen: Let's try and resolve. Any additional comments or concerns?
Anyone need summary before we resolve?
Rossen: I'll take silence as a no.
TabAtkins: Proposal: Accept edits to images spec about specifying
behavior of not yet loaded images [missed, bad connection]
fantasai: Proposal: Specify what's happening when you're loading
image and add text explaining what you do while it's
loading
<fantasai> https://drafts.csswg.org/css-images-3/#image-values
fantasai: Added a section for what it means for an image to be in
process of loading and what you're supposed to do ^
fantasai: [reads spec]
<chris> That wording on loading images sounds great to me!
<AmeliaBR> 👍
Rossen: For those hearing this for the first time, any questions or
comments?
chris: sgtm. It covers and don't need anything else
Rossen: Proposal: Loading images are not invalid but treated
similarly as explained in
https://drafts.csswg.org/css-images-3/#image-values
Rossen: Fair summary?
fantasai: Yes
Rossen: Comments or objections?
RESOLVED: Loading images are not invalid but treated similarly as
explained in https://drafts.csswg.org/css-images-3/#image-values
Publication
-----------
<fantasai> https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
<fantasai> DoC https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
fantasai: That's all the issues
Rossen: Are we ready to republish Images 3?
<chris> +1 to republish!
fantasai: I am
<xfq> \o/
Rossen: Objections to republish CSS Images 3?
smfr: Draft does not have image orientation removal note. Or is
that 4?
fantasai: Should. Thought I added it.
TabAtkins: It's there
<smfr> https://drafts.csswg.org/css-images-3/#the-image-orientation
Rossen: Section 5-1
smfr: That right? Oh, I see.
smfr: nevermind
Rossen: You're good?
smfr: Yeah, that's fine.
Rossen: Thanks
Rossen: Other comments or objections?
RESOLVED: Republish CR of CSS Images 3
<fantasai> xfq, note this publications requires a change of shortname
<xfq> noted, thanks fantasai
CSS Color Adjust
================
background-color in forced color modes needs more than a simple unset
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4175
Rossen: I'll take it since melanierichards is on vacation
astearns: How much time do you need?
Rossen: Quick.
<Rossen> https://www.w3.org/TR/css-color-adjust-1/#forced-colors-properties
Rossen: When the forced color behavior was desc in the link^
Rossen: These are the properties overwritten by system colors.
Fallback was spec that every property that has no overrides
gets the revert !important which means revert to original UA
stylehseet which for background color is transparent
Rossen: Not expected. All other colors reverting makes sense.
Background being reverted to transparent you lose all
non-transparent. Intended it go to system background color
<aja> re: forced-colors, should transparent (borders-color only?) be
allowed in addition to the non-deprecated system colors? will
file issue if it sounds reasonable.
Rossen: Idea from fantasai was can re do something to transparent
color and see if computes to self similar to currentColor.
Not really the same. Transparent color is a named color.
Rossen: If we spec transparent computes to itself as computed we're
making an exception for one named color. Think it's a bit
weird. currentColor is an instruction to cascade algorithm
to go back to a value. Not really the same
Rossen: Ask here is that we take background color out of the list
and spec the behavior that it falls back to system
background color in case of forced colors
Rossen: That was intended implementation that we had to back out
when making code according to spec
AmeliaBR: This would need to be defined in prose because involves a
switch on computed value we can't define in cascade.
Rossen: Yes
AmeliaBR: Would it work to force all background to be opaque?
Rossen: Inverse problem which would be just as bad
AmeliaBR: Okay.
AmeliaBR: It really has to be done with a little magic and special
prose
Rossen: Magic is simple. When you compute value of background color
for non-transparent the value is computed to the system
background color.
Rossen: To your observation AmeliaBR the explanation will be
background color only.
AmeliaBR: Any interaction with background image? Background image
the current proposal is keep the image and use backplate
behind text to add contrast. Would you do them separately?
Rossen: What you said is right for background image. For background
color if the color is non-transparent it will be system
background color. So if you draw a backplate it would be
non-observable visually or object model. Somewhat wasteful
to render.
Rossen: Otherwise for background image the backplate takes effect
and guarantees foreground in desired contrast
dbaron: Is this the right treatment for background colors with alpha
between transparent and opaque. Alternative is don't touch
alpha and change color components to system color
Rossen: Valid point. There's a different issue that addresses what
you described when talking about interpolation. It will end
up interpolating most of alpha channel. I like your proposal
astearns: Summary Rossen?
Rossen: Proposal: background-color computes to the system
background-color for all values but hte alpha channel
astearns: Can we resolve on this?
astearns: Objections?
RESOLVED: background-color computes to the system background-color
for all values but the alpha channel
astearns: Can we have the Quick intro to content-size quick and if
have time go to item #12
Writing Modes
=============
fantasai: There is a 28 day waiting period after we publish. Do we
want a async cfc to get to Friday's deadline or wait?
Rossen: Okay as soon as possible. I defer to dbaron because he
wanted to review this
* fantasai will get the edits done today, probably this morning
Rossen: If dbaron you're okay to review then I'm fine doing the CFC
over email
Rossen: Or we resolve to republish as long as no objections before
Friday?
dbaron: Fine with me
Rossen: Objections to Republish Writing Modes L3 with added/missing
section for orthogonal writing modes provided no issues
raised before Friday ?
RESOLVED: Republish Writing Modes L3 with added/missing section for
orthogonal writing modes provided no issues raised before
Friday
Quick intro to content-size
===========================
Link: http://tabatkins.github.io/specs/css-content-size/
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4229
TabAtkins: Quick intro, will bring up properly at TPAC-ish
TabAtkins: Larger context. You may have seen Chrome team efforts on
async layout. Ability to tell a dom tree don't render
what's in you yet. Go ahead and keep invisible and let me
know when you're ready
TabAtkins: While exploring found a small number of additions to CSS
that would be generally useful. Content-size property is
intro here. Important part of async layout is it not
effecting outside subtree. Need to constrain size in
particular.
TabAtkins: Don't want it to render to 0 size, usually have a rough
idea of size and update when finish rendering.
TabAtkins: Idea to fix that is content-size property. When none,
none pretend 1 child with spec size and render like that
TabAtkins: Still gives you layout shielding effects of contain-size
but ensures it's not going to get too small
TabAtkins: Why not use width and height? A few reasons. Biggest is
different layout modes react differently to fixed vs
auto. If you pop this into grid won't stretch anymore.
TabAtkins: I had a reason not to use min-width/height but I forget it
florian: Because in a flex situation where trying to shrink beyond
natural size?
TabAtkins: Yes. I feel like more, but yes. There are layout effects
you may not want.
TabAtkins: This is be as normal as possible and assume the kids will
be about this big
TabAtkins: We'll want to discuss properly in a call in 2 or 3 weeks
or in TPAC but thoughts and feedback are welcome in the
issue.
Rossen: Thank you TabAtkins. I think TPAC would be good with a
whiteboard.
CSS Fonts
=========
system-ui-serif, system-ui-monospaced, and system-ui-rounded
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4107
myles: In latest version of macOS and iOS we've added 3 new fonts.
You can see them in this issue
myles: These are new fonts but aren't like regular fonts. Don't show
in font pickers and you can't get them in native apps by
name. There's a new codepath that causes these fonts and
that's intentional
myles: These fonts are designed to match design language of OS. Not
intended to be used in a document font. Not supposed to use
in an essay in Word.
myles: There's nothing you can type in CSS to use these fonts which
is unfortunate. Have heard requests to use them.
myles: Proposal is that because these fonts designed to match the
system they should be added as siblings to system UI generic
font family
myles: Might ask why not use existing generic font family. Reason is
mechanically we can't because serif face is mapped to Times
and if we change that we break the web. Need to be a new
opt-in thing.
myles: New fonts shouldn't be used as a document typeface
myles: What do you guys think about adding a way to get to these
fonts?
Rossen: Curious if another way is have them in static variables
introducing for other system things like scrollbar thickness
myles: Mechanically fine. Confusing to authors because there's a way
to ask for font-family from system.
<dbaron> I'm curious about whether we want the 'rounded' name in
CSS, rather than our existing 'sans-serif' which it seems
similar to...
<AmeliaBR> dbaron, rounded isn't the same as sans; it's usually a
sans font, but with rounded ends of strokes. Myles'
naming system assumes that the default system-ui is
sans-serif, so they haven't included a system-ui-sans.
chris: Why do this if whole point is not to use in Word documents?
If you give CSS they can do specifically that. I'm curious
why you hide in one hand and available on the other hand
leaverou: Seems this is adding a very specific language feature
that's OS specific. I don't think we generally do that.
myles: One at a time. Chris' question: This is interesting. On our
platform there's a tension between system fonts and not.
There isn't that on the web. Only distinction is they're font
families that start with 'system-ui'. Can't stop people, but
it's more important to give access then the design
restrictions.
myles: Trying to indicate these are system fonts by manner exposed
to CSS and hoping that's good enough people will do the right
thing. Things are either present or not in CSS 3.
chris: If an impl supports these keywords by on platform they don't
map would it fallback to next font or system-ui? I'd like to
propose clarify that case
myles: I see both arguments. Willing to go with WG desires
<chris> I can see merits in both options also. I just want it to be
clear.
AmeliaBR: For the existing generic fonts I think we still require
UAs to have something match those. I think we have
exceptions for emoji generic font. If we have generic font
names that are allowed to not match that would be a new
way of talking about what a generic font is
AmeliaBR: One benefit of the suggestion to use environment variables
is they then allow authors to decide what the fallback
would be. Would have to think carefully of how that works
with the way environment variables work with replacing
tokens and how that works with font-family fallback. Don't
want to invalidate entire expression
AmeliaBR: Fallbacks worth thinking about because don't have logical
equivalent in other systems
Rossen: Need to think through use cases.
Rossen: We're a minute over. myles I don't think we'll get to
resolve. Anything else you want to add before we end the
call? Of course there's a call for people to read proposal
and comment on the issue.
myles: It sounds like there's more to discuss so I hope this comes
up on a future call
Rossen: Will put it on next weeks call as well. Hopefully people can
also discuss on github
Rossen: Thank you everyone and we'll chat again next week.
Received on Wednesday, 21 August 2019 23:24:28 UTC