- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Oct 2018 19:20:55 -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.
=========================================
Publications
------------
- RESOLVED: Publish CR Update for CSS Flexbox L1.
- RESOLVED: Publish CR Update for CSS Fragmentation Level 3.
- RESOLVED: Republish CR of CSS Contain.
- RESOLVED: Republish WD for Transitions L1.
- RESOLVED: Republish Animations WD.
- RESOLVED: Republish Web Animations WD.
- RESOLVED: Republish Values & Units L4 WD.
Values & Units 3
----------------
- RESOLVED: Redefine <'property-name'> to strip off top-level #
multiplier. (Issue #3146)
- RESOLVED: Update publication of CSS Values & Units L3.
CSS Text
--------
- RESOLVED: Add text-transform: full-size-kana to Text L3 marked
at-risk. (Issue #3143)
CSS Animations
--------------
- RESOLVED: Serialize all keyframes as identifiers. (Issue #2435)
CSS Snapshot
------------
- RESOLVED: Push boilerplate to the end of documents. (Issue #1867)
- RESOLVED: Canonical propdef should go to OM and applies to propdef
should go to cascade. (Issue #1139)
- The snapshot will continue having different short names every year
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Oct/0004.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Garrett Berg
Tantek Çelik
Dave Cramer
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Florian Rivoal
Jen Simmons
Alan Stearns
Sean Voisen
Greg Whitworth
Regrets:
Manuel Rego Casasnovas
Angelo Cano
Chris Lilley
Nigel Megitt
Melanie Richards
Lea Verou
Scribe: dael
Rossen: Let's get started
Rossen: As usual I'd like to call for any additional items besides
ones from florian
Rossen: There's also a publication request for CSS Contain that's
not on the agenda
Rossen: Anything else?
Publications
============
Flexbox CR
----------
<Rossen> https://drafts.csswg.org/css-flexbox-1/#changes
<Rossen> https://drafts.csswg.org/css-flexbox-1/issues-cr-2017
Rossen: Changes & DoC links ^
<astearns> tests for everything in the changes section?
Rossen: Request for CR republication
fantasai: 2 open issues but they need more investigation. There has
been a ton of bug fixes so we should issue an update and
continue working on those two issues
Rossen: Agree. With all the fixes made to content distribution
algorithm they need to be in published version since there's
implementors shipping
florian: There is ongoing discussion in AB for what is criteria to
update CR with open issues. I'm pushing this should be
allowed
fantasai: In this case the open issues are very specific. One it's
not clear edits are needed and the other is a change of
behavior request that needs web compat investigation
florian: Looks good to me
Rossen: Objections?
astearns: Tests for everything in changes?
fantasai: No idea
Rossen: Good point. If there's no tests we must have issues tagged
with PRs to updated changes.
fantasai: I can make sure all issues have needs testcase flag
Rossen: Okay. Great point astearns.
Rossen: Other comments or objections?
RESOLVED: Publish CR Update for CSS Flexbox L1
Fragmentation
-------------
Rossen: Same deal. There have been a number of changes made since
last publication
<Rossen> https://drafts.csswg.org/css-break-3/#changes
<Rossen> https://drafts.csswg.org/css-break-3/issues-cr-2016
Rossen: Changes & DoC links ^
Rossen: Anything to draw attention to fantasai?
fantasai: I think most changes were straightforward. One open issue
I haven't thought about what spec should say. I don't
think it's difficult, but it's specific and tightly scoped.
florian: Not opposing, but since list of changes isn't as large as
flexbox, why not fix the issue before publish?
fantasai: We could if anyone has feedback on issue. Issue is in
general you can only break between sibling boxes. I can
break between pair of paragraphs, but not between first
<p> and margins, border, padding
fantasai: However if parent has fixed height so there's a gap, some
space between margin of last and the parent you might
break there. In general not ambiguous but for multi col it
becomes a question of where is the bottom
dbaron: Broader issue is when the breaking behavior says height
disappears in some context it makes column balancing weird.
Rossen: I know this needs to be discussed. I'd prefer we do it as a
separate issue. Back to publishing and florian's comment.
florian: I got my answer. We have a bunch of tightly done issues and
the issue left is gnarly and would delay good fixes from
being published
Rossen: And some of the changes were really fundamental. Like if
something establishes a monolithic box. There's merit to
republish CR
fantasai: I'm happy to issue transition request next week so if we
end up with a solution in the next few days we can fix it
before the transition happens
Rossen: If this was enough to spur interest that would be great.
Rossen: Same comment about testing. We need to flag issues if we
don't have coverage.
florian: We have at least one change tested.
Rossen: Good to hear
astearns: Note that flagging the issues isn't sufficient. We said we
wouldn't publish CRs until there are tests to make sure
that changes were reviewed. I won't die on the hill for
these because they'll need more CRs, but we should be more
serious about tests before updates
fantasai: I think it comes down to who will do the work to write
tests and no one is willing to. TabAtkins and I were
against this because we felt it would come to us on tests.
astearns: It's not just me that wants this, it's the process.
astearns: I won't die on this hill today, I won't object. But I
think we should have had the tests in place before we
republish.
florian: Don't disagree. fantasai point is valid too
Rossen: I think they're both valid. For flexbox we have tests and
feedback from impl. For specs early in impl that's not the
case. Fragmentation is in between.
Rossen: As astearns won't hold us from publishing we will continue
to encourage tests for all CR or later changes.
Rossen: By no means is this intended to say that by having this
process the onus is on the spec editors only. That is not
the intent. fantasai and TabAtkins should not be responsible
to make these test changes.
<astearns> right - the intent is to have someone separate from the
editors check the changes
Rossen: Objections to Publish CR Update for CSS Fragmentation Level
3?
RESOLVED: Publish CR Update for CSS Fragmentation Level 3
Contain
-------
florian: It is a CR update
<florian> * zero open issues:
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-contain-1
<florian> * DoC: https://drafts.csswg.org/css-contain/issues-2018-cr.html
<florian> * Change section:
https://drafts.csswg.org/css-contain/#2018-05-24-changes
<florian> * Test suite:
http://test.csswg.org/harness/results/css-contain-1_dev/grouped/
<florian> * WIP transition request:
https://github.com/w3c/transitions/issues/98
florian: Links ^
florian: Have test suite for entire spec and delta.
Rossen: Anything specific to draw attention to for changes put
forward?
florian: Not really. All discussed in group.
florian: I don't think there's anything controversial. Large part of
changes were driven in para. with fixing in Blink.
Rossen: Opinions or objections?
RESOLVED: Republish CR of CSS Contain
florian: I want to thank Gerard for writing missing part of test
suite
CSS Transitions
---------------
<Rossen> Changes:
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-contain-1
<Rossen> https://drafts.csswg.org/css-transitions-1/#changes
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Oct/0001.html
<dbaron> and https://lists.w3.org/Archives/Public/www-style/2018Oct/0003.html
Rossen: Can anyone take this?
Rossen: dbaron anything to highlight? Or just republish?
dbaron: Not familiar with changes so nothing to highlight
Rossen: Objections to publish WD for Transitions L1?
RESOLVED: Republish WD for Transitions L1
Animations
----------
<tantek> note:
https://drafts.csswg.org/web-animations-1/#changes-since-last-publication
Rossen: Let's republish all 3 remaining requests
RESOLVED: Republish Animations WD
Web Animations
--------------
RESOLVED: Republish Web Animations WD
Values & Units L4
-----------------
RESOLVED: Republish V&U L4 WD
fantasai: birtles and I pulled out computed value of propdef to V&U
L4 and simplified down. Possible values are 'not
animatable', 'discrete', 'per computed value', or you can
give details
fantasai: It's a generic logic for all various animation lines. I
took computed value lines and made them more tightly
described.
fantasai: Nothing special that's different about computed value
lines, we just need to know how it animates as well as
inherits.
<fantasai> https://github.com/w3c/csswg-drafts/pull/3198
fantasai: I changed most specs, there's a PR TabAtkins pulled for
the last remaining specs ^
fantasai: If you're editing one of those specs please look at those.
fantasai: I'll probably do second pass through computed values
Rossen: Thanks
<fantasai> https://drafts.csswg.org/web-animations-1/#animating-properties
<fantasai> https://drafts.csswg.org/css-values-4/#combining-values
<dbaron> fantasai, does that handle stuff like repeating lists?
<fantasai> dbaron, yes
Values and Units 3
==================
Define <'property-name'> notation to exclude listification
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3146
fantasai: This is an issue about our notation syntax.
fantasai: In CSS 2 we didn't have list valued properties of
font-family. There was a convenience location where you
could do name of property in quotes and a angle bracket
and it meant use this whole property over there.
fantasai: There's a ton of specs where in CSS2 we could use that
notation. We have to create non-terminal terms that are
identical to another property except they're not comma sep
lists.
fantasai: Means property definitions are more obscure. When you look
at table rather then listing color and then repeating
there's a new type
fantasai: I think it would be nice to use this notation. We have to
unlistify it in order to use it.
fantasai: I was thinking it might make sense to redefine as the
property's value space but if it has a top level hash
multiplier we remove it and take the value space within
each item
fremy: Makes a lot of sense. Reasonable
fantasai: Notation change so it's editorial
florian: Makes sense to me as well
Rossen: Other opinions?
Rossen: Objections?
<tantek> +1
RESOLVED: Redefine <'property-name'> to strip off top-level #
multiplier
Publication
-----------
fantasai: Need resolution to update V&U L3
Rossen: Objections?
RESOLVED: Update CSS Values & Units L3
CSS Text 4
==========
text-transform: full-size-kana
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3143
florian: We discussed this a long time ago. I was opposed
originally, but I regret that. Had in spec this value. It
is meant to be used within Ruby. Because characters in Ruby
are very small there is a typographical process where you
use different characters in very small font sizes [gives
example]
<myles> U+3083 HIRAGANA LETTER SMALL YA
<myles> U+3084 HIRAGANA LETTER YA
florian: If people do that using the wrong letter in markup speech
synthesis reads it wrong. So this was proposed to do the
typographical thing without using a different character.
florian: Original objection was this is niche and instead of doing
this we should allow authors to make custom text
transforms. Wrote a spec for custom, but no one paid
attention and there have been no additional use cases. So
there is no slippery slope.
florian: Another thing is there is an open type feature that can be
turned on for Ruby and allow fonts to do this. That would
only work if font you're using has that. But it's not clear
that it's meant for this effect in Ruby. And as far as I
know actual fonts don't do that.
myles: I think the general idea here is good. One thought and
question. Thought is I don't think font-variant is right. It
is a unicode transformation. Font features weren't designed
for this. We should model this as a text-transform. Is there
ever a situation where Ruby wouldn't want this? Can it be on
by default?
florian: I don't think on by default. Semantically it reads
different. If the font size isn't so small it's unreadable
you might not want this.
fantasai: Agree with florian and myles that we should add. This is
important for a11y. It keeps the underlying text data the
same while allowing authors to do the style they want. And
I agree font-variant Ruby is not right. That's about
changing shape, not changing one letter to another.
florian: Some authors might not want it because they argue it's not
a legibility issue, people just got into the habit of doing
it. If people want to do it is something that's disagreed
on so it would not work as a default.
Rossen: I hear support to add this. I also hear we should add this
to transforms and not variants
Rossen: Do we have other opinions?
fantasai: Do we add to L3 or L4 of text? Originally in L3 but was
removed.
Rossen: Reason not to put it in L4?
fantasai: I think it's simple enough we won't get issues
florian: at-risk in L3?
myles: Will spec include list of mappings?
fantasai: Definitely.
Rossen: L3 still has quite a bit of open issues. Adding this to L3
won't delay. Let's add there and not mark at-risk
florian: I would mark at-risk. We're getting closer to CR
Rossen: Looking at number of open issues I don't think we're close
florian: Really?
Rossen: Please prove me wrong.
fantasai: We can adjust at-risk later.
Rossen: Objections to adding text-transform: full-size-kana to Text
L3 marked at-risk
RESOLVED: Add text-transform: full-size-kana to Text L3 marked
at-risk
CSS Animations
==============
Serialize all keyframe names as strings
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2435
fantasai: Question about...as we were going through computed values
do we need to preserve a distinction between animation
names that are strings and ones that are identifies
fantasai: You can use either for keyframes
fantasai: Main issue afaict is we can't serialize things as strings.
They have to fundamentally be identifiers. One case we
can't treat them to compute as the same there's CSS-wide
identifiers like 'none' where if you wanted to name your
animation that you can't refer to it in the property
fantasai: I don't think it's an issue.
fantasai: Nice if we didn't have to maintain the difference.
myles: Web compat risk?
fantasai: If someone relies on web animation name as 'initial'
'inherit' or 'none' yes. Otherwise no.
<Rossen> 'auto'
Rossen: Any other concerns, comments, suggestions?
Rossen: Objections?
fantasai: Proposal is serialize all keyframes as identifiers
Rossen: Objections?
RESOLVED: Serialize all keyframes as identifiers.
dbaron: Somethings wouldn't round trip?
fantasai: CSS wide things. I propose we make them invalid and that's
why they don't round trip.
dbaron: Is someone volunteering to change first?
Rossen: I don't hear any. Are you dbaron?
dbaron: Not particularly
fantasai: I believe current behavior was a recent change. 2016.
fantasai: Before 2016 you could not have a keyframe name that is a
string. That was a webcompat problem because webkit
supported a string in that position as animation name. We
changed to allow strings or idents but decided to keep
them distinct. Only reason is if you have 'initial' or one
of those values.
fantasai: It's really about will we maintain that if you put in a
string or an ident both end up as an ident
fremy: We still don't support strings in Edge. If someone is using
'none' they're doubly failing. I don't feel like making the
change is end of the world
dbaron: Other question; are you proposing this for values of
properties, @keyframes or both
fantasai: Anywhere accepting a string as an animation name.
<fantasai> https://github.com/w3c/csswg-drafts/issues/118
fantasai: Proposal is everywhere issue #118 says we can accept a
string we treat it at parse time as an ident
myles: Do we need a rule for idents that aren't 'auto' and the list?
fantasai: Have that rule already.
<fantasai> https://www.w3.org/TR/css-values-3/#custom-idents
fremy: Yes, because you need it for font-family
<dbaron> font-family is extra-weird
Rossen: Still not hearing reason to change resolution
CSS Snapshot
============
Copy document conventions (and conformance?) from 2.1
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1867#issuecomment-424755198
florian: This and next are related.
florian: This one is there is on the bottom of every spec a section
about conformance criteria. At some point we moved that to
snapshot and removed from other specs. I don't think it's a
good idea because snapshot is a note and normative text in
a note is not possible. And if snapshot is a WD it wouldn't
work because it's not intended to be a REC.
florian: If we want that text normatively referred to we can do
that, I just don't think snapshot is a good place to do it.
Also because we have a practice of changing snapshot
shortname every time we update.
florian: I would like to not do that.
Rossen: Reasonable. What do others think?
fantasai: I like the idea of pulling boilerplate from end of specs.
We didn't do it because there were issues about
normativity.
florian: Snapshot won't get to rec so even if normative we don't
solve it. Let's put it into something that is stable.
florian: chrisL agreed in github
Rossen: Objections?
<tantek> that sounds like a reasonable solution
RESOLVED: Push boilerplate to the end of documents
What defines the various fields in the property definition blocks?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1139#issuecomment-424751081
florian: Next is that at some point we said various entries in
propdef aren't anywhere and we said we should do in
snapshot. Now they're mostly not in snapshot. Canonical
order and applies to line are all that's left. Canonical
should go to OM and applies to should go to cascade.
fantasai: Sounds great
<dbaron> yes, sounds good
florian: Once we do that there's no reason to have them in snapshot.
Rossen: Other opinions?
Rossen: Objections?
RESOLVED: Canonical propdef should go to OM and applies to propdef
should go to cascade.
Shortname
---------
florian: We got into the habit of having a different shortname every
time we publish snapshot. I think we should switch to
having a shortname and republish and let usual process of
dated drafts.
florian: There were +1s on GH
fantasai: We did it as separate so it was a replacement for levels
of CSS. So it would be possible to refer to a set of CSS
specs published as a snapshot. So you could go back and
fix that doc. If it's single stream you can't do that
because updating changes date.
florian: What updates did you envision?
fantasai: Generally we find problems with a draft and we should fix.
Be it typos or bad wording. We could fix it.
fantasai: Or we added a propdef table of all properties in a
snapshot you could regenerate all of them and go back and
see what properties were in each snapshot
fantasai: But if we're doing dated we can never add it to older.
florian: That sounds true.
florian: Flip side I don't think we've ever done that and this makes
it harder to update.
fantasai: If issue is about doing publication process, I can take it
over. It only takes an hour.
florian: I'm okay with either, but if it took 3 minutes we'd do it
more often.
fantasai: I think the hold up is there's edits that aren't done.
Publication is pretty straight forward.
florian: I'm okay with dropping this request. I can try and convince
you later, but no need today
florian: I've got the resolutions I wanted
Rossen: Thanks for joining. We'll pick up remaining items next week.
Please add TPAC topics if you haven't.
Received on Wednesday, 10 October 2018 23:21:48 UTC