- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Dec 2018 20:14:53 -0500
- 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.
=========================================
Upcoming Telecons
-----------------
- The group will have a call on 19 Dec, but not 26 Dec or 2 Jan.
Grid
----
- RESOLVED: Return computed value for getComputedStyle() for these
properties [grid-row-start/etc] (Issue #2681)
- RESOLVED: Fully specify the first 2 bullet points and leave it at
that for this level (Issue #3201)
- Bullet points:
- Check interpolation type per track, rather than for the
entire list, before falling back to discrete. I.e. a
length-percentage track can animate between two values
while an adjacent auto track flips discretely to
min-content.
- Allow discrete interpolation of line name changes
independently of track sizes.
- RESOLVED: Use the normalized value to serialize
grid-template-areas (Issue #3261)
- The plan is to request republication of Grid next week so anyone
interested in review should look over the spec.
CSS Text 3
----------
- myles and anyone else interested will review issue #337 (Segment
Break Transformation Rules for East Asian Width property of A)
for discussion on next week's call.
- RESOLVED: Publish a new WD of Text L3
CSS Fonts 4
-----------
- The proposal to add an @partial rule to serve as a way to
overwrite a parts of an @rule (details here:
https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-442167124 )
was interesting to the group, but there needs to be more use
cases to argue that there is a larger need that justifies this
change.
- Either way, the original use case of being able to override
some values on the @font-feature-values
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0016.html
Present:
Rachel Andrew (IRC Only)
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Alan Stearns
Lea Verou
Regrets:
Chris Harrelson
Nigel Megitt
Jen Simmons
Greg Whitworth
Scribe: dael
Upcoming Telecons
=================
astearns: Let's get going. Does anyone have any extra agenda items?
We'll do publish text 3 after item #4
astearns: My extra is, is there anyone on the call that will not be
able to make 19th Dec or 2nd Jan that hasn't already
mentioned it?
chris: I won't be able to.
leaverou: Me neither.
Rossen: Probably not the 2nd. 19th is fine
astearns: I'm inclined to meet next week, but not the 2nd.
astearns: How does that sound?
<Rossen> sgtm
myles: Great
Grid
====
gCS() of grid-row-start/etc properties should return used values?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2681#issuecomment-396441751
fantasai: We discussed and resolved to accept the change, keep issue
open, and don't do edits until implementation commitment
fantasai: Currently these properties return computed, but authors
pointed out that there is no way to get used.
Straightforward way as gCS() to return that value.
fantasai: We decided it's a good idea, but no one agreed to
implement. So WG said we agree but won't put edits in.
That's from the end of May. I wanted to check where we're
at now. Is that something anyone is interested in impl?
astearns: Mats said there could be performance issue in returning
used when call is made
fantasai: The answer is deafening silence so I'll take that as a no
florian: How do we make sure we don't forget?
fantasai: There's a note in the spec
astearns: Saying we could make change if there's implementor
interest?
fantasai: Something to that effect, yeah
<fantasai> note
https://github.com/w3c/csswg-drafts/commit/77b8f93eb5b30c408bdd8ca91e4d4d61b3605570
astearns: Alternative is not to use used and close off this. Find
some other way to solve this problem.
fantasai: Right, we'd need a new API
astearns: Not hearing implementation interest.
astearns: Objections to not returning the used value in gCS for
these properties?
Rossen: Returning computed values always?
astearns: Yes
astearns: New resolution that we return computed value for these
properties in gCS
astearns: Objections?
RESOLVED: Return computed value for getComputedStyle() for these
properties
Interpolating track listings
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3201
fantasai: How do we interpolate track listings. Current definition
is basic, there are options to make it nicer
fantasai: Asking WG what do they want to put in here.
fantasai: I've tried to ping people for opinions but I'm not getting
info
TabAtkins: The templates have a lot of different information and
being inconsistent in one part means you have to do the
whole thing discretely. Options in issue for level of
granularity. More fine then one difference makes thing go.
TabAtkins: 3rd point is the only no go to me. All others are
reasonable to me if someone likes them
astearns: There is reasonable to TabAtkins. There's also willing to
implement. Do we have both?
TabAtkins: I'd have to ping Igalia folk.
rego: I think we don't have support for animations on these
properties in blink
fantasai: What would you like spec to say?
rego: I don't know how complex the different options will be. We can
have something better here, but not sure how it can be done
fantasai: Okay. I think Mozilla is in process of implementing this.
Rossen: Is the 3rd option...
fantasai: The options are checkboxes, not radio buttons. Just to be
clear
Rossen: Trying to figure out what Brian was talking about in terms
of current differences between Gecko and Blink and his
preference for less granular fallback
Rossen: Looking through options it sounds like if we allow discrete
independent of tracks we solve this. They both sound fine
fantasai: I would like this closed by next week
Rossen: I'm trying to figure out implications of 3rd. If we need it
at all. Since we have Igalia who is interested in trying
that in Blink perhaps we can try and resolve now. Or push to
next week. Either is fine.
Rossen: I'm trying to tease apart technical implications.
rego: We can discard the 3rd one. That one property depends on
another doesn't seem good idea. Other 2 I don't have opinion.
Rossen: I think the first 2 are straightforward and doable. 3rd I
have reservations.
Rossen: If this is acceptable for now we can try and do that.
Rossen: fantasai is the idea we want all 3?
fantasai: The idea is we want this defined.
Rossen: Good. Take one by one? I think first 2 are
non-controversial. 3rd we can leave it or fork it
fantasai: We can resolve to do first 2 and not 3rd. These are the
options I can think of we have to decide yes/no on each
astearns: And 3rd is something we can add later if it proves
feasible.
fantasai: Prob possible
Rossen: Good to see what that 3rd option blocks in terms of use
cases. First 2 will solve a lot of use cases. We can wait
and see if 3rd is required.
astearns: Proposal: Fully specify the first 2 bullet points and
leave it at that for this level
astearns: Objections?
RESOLVED: Fully specify the first 2 bullet points and leave it at
that for this level
How to serialize the strings in grid-template-areas?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-446018130
<fantasai> https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-436830050
fantasai: This issue is well illustrated by ^ comment
fantasai: grid-template-areas takes a series of strings and assigns
names to different areas. When re-serializing that back
out do we normalize things that are equivalent like
compressing whitespace or do we return original string
TabAtkins: Already not returning original, we have compressed
whitespace. It's how much compression is okay. Should we
do more tracking of original author like keeping number
of dots in the slot
myles: Can't imagine an impl that stores original string
Rossen: Make it available to things like dev tools. It's there. Not
sure if it's required and useful. I think that's the
discussion
TabAtkins: 2 comments above linked eric made a table of who returns
what.
<fantasai> table
https://github.com/w3c/csswg-drafts/issues/3261#issuecomment-435698461
astearns: One argument to normalize is to make it easier for script
to parse. Handling string as spec they have to impl
browser's normalization to get useful information
emilio: Other hand this is only string that would get normalized.
All others we just store and return the string. This is
special
Rossen: What's an example of other properties?
TabAtkins: Every other property that takes string takes text or a
name. This is one place where it's a string for
non-string purposes
<dbaron> I think there might have been one other case recently where
we did normalization inside a string...
<dbaron> (or maybe it was this one)
Rossen: That's why asking for example. This is the only snowflake
where we're defining behavior and not something simpler
Rossen: I think current normalized format seems reasonable
emilio: Arguments for both. Either you make it easier for script to
parse it or just reserve right thing useful for editors.
Don't have strong preference, but we need interop
Rossen: Not sure what you mean by editors. WYSIWYG type things are
using script APIs so that would be also easier
myles: Another axis is for an impl [missed]
myles: This is speed vs memory trade off. If don't store original
you can build it but that's slower
rego: On the dev tools or the CSS editor you can set one thing and
after it's applied you get something different. That's an
issue reported in chromium. When you use repeat we're only
returning computed values because we're not storing. That's a
similar issue
Rossen: Your point is right on. Had this discussion at length with
repeaters. I had a similar argument for keeping normalized
computed for same purpose so you can represent a repeat.
Consensus at that point is if you're building an editor you
have enough source information to rebuild that knowledge and
use the used values to infer what engine processed.
Rossen: I think consistency is something we should value between
repeat and this one. In which case we'd have to stick with
normalized version
astearns: emilio are you back?
emilio: Yes, I'm fine with whatever decision we take. Rossen's
argument is fine
astearns: Proposal: Use the normalized value to serialize
grid-template-areas
astearns: Objections?
RESOLVED: Use the normalized value to serialize grid-template-areas
Publishing
----------
astearns: Was this a grid issue sweep for publishing?
fantasai: Not yet, but hoping by next week. If interested in review,
these edits need to go in and there's one or two items
open with small details
fantasai: There's 2 significant issues with auto-sizing which will
need to remain open. Everything else should be able to be
closed over next few days and I'll compile DoC
astearns: Please look at grid
CSS Text 3
==========
Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/337
fantasai: This issue started as being about using [noise issues]
fantasai: Using language information for doing break transformation.
As I edited that in I ran into problems around emoji.
They're wildly inconsistent about which characters are
which East Asian Width and that's what we use to determine
if line break is transformed
fantasai: To work around that we're taking a subset of emoji with a
width of n or w and treating as ambiguous
fantasai: This issue is about if it's okay to make that change. If
we don't characters like smile face has one behavior
around line break and grinning face has a different
behavior
<fantasai> https://unicode.org/cldr/utility/character.jsp?a=1F600&B1=Show
vs https://unicode.org/cldr/utility/character.jsp?a=263A&B1=Show
fantasai: Sent email to author of East Asian Width spec to ask why
it's inconsistent and they said they don't recommend this
for emoji and use the emoji property so that's sorta what
we're doing
<chris> It sounds like Unicode spec should be fixed
astearns: I'm not clear on koji's comments. Seems he's against. His
last comment about troubles win over benefit
myles: Is email to unicode guy public?
florian: No
myles: Would love to read
florian: I'll check with him before forwarding
florian: Not sure I understand koji either. We need to define
somehow. East Asian Width of unicode is messy so I'm not
going to be surprised if we come back. Pushing back means
leave undefined or what?
fantasai: [reads unicode email]
myles: Did we explore emoji related properties?
fantasai: That's what we did here.
astearns: Divining koji's intent. "Even though there are cases it
looks strange it's interop, right" So is there interop
behavior?
fantasai: Not sure how interoperable this set of rules are. Mozilla
implemented previous line break transformation and not all
impl had. I do think case of line break transformation in
emoji I don't think we have a web compat problem if we
make an exception. I think we get weird results either way.
fantasai: Purpose of transformation rules is to make it easier to
format source code of doc rather then put all text that
can't have spaces on one line. If rules are unpredictable
that's not helpful. Should treat all smileys same.
florian: I checked, there is no interop
florian: And that comment was about processing of line breaks
entirely
astearns: "that comment" being which?
florian: Suppression of space introduced by line break is done by FF
and not by Chrome.
astearns: Given all this I think remaining question is if anyone is
interested in implementing this change
Rossen: It sounds like koji is not interested in implementing based
on comments
florian: I don't get if he disagrees with implementing this feature
in this way or if he doesn't want to implement the entire
feature.
florian: Given Chrome doesn't impl feature and I can't tell if he's
against implementing...
myles: I won't implement until I do another pass through spec and
try and understand
Rossen: Try to cover when koji is on?
florian: Possibly. Is everyone up to speed on this feature in the
first place?
astearns: I'm not sure a quick summary on the call is right. myles
is going to look through spec to get up to speed. Maybe we
leave this open. It's in the spec and we have issue with
intent to keep in but leave it to review and raise
objections.
astearns: I know we just closed an issue where we left it in that
state for 6 months but coming back in Jan might let people
get up to speed
fantasai: Or next week
myles: I could have something to say by next week
astearns: Let's leave to next week. I'll ping koji to clarify his
comments
Text 3 publication
------------------
astearns: Publish now or leave until next week?
fantasai: I think we should do it now.
astearns: We did a CFC so most up to date is good
astearns: Objections to publishing a new WD of Text L3?
RESOLVED: Publish a new WD of Text L3
CSS Fonts 4
===========
font-display says it's valid in @font-feature-values but it isn't
an at-rule
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-442167124
TabAtkins: A while back got a request to override font descriptor
for fonts they don't control. Specifically Google fonts.
Google fonts control that and due to caching don't want
arbitrary things in there. Idea is add font-display to
font feature values which kinda adds additional
information and we can expose that
TabAtkins: Right now font-feature-values doesn't take descriptors.
Needs minor spec edits for that.
TabAtkins: myles objected because seems ad hoc. We want to define
additional font-face, but they cascade atomically. Rather
then trying to come up with special fix for this one
problem we thought why not try and fix the general
problem and have a way to explicitly extend these @rules
<myles> i didn't "object"
<myles> just said it would be a shame if we did it
TabAtkins: In thread had proposal for @partial rule that looks like
an @rule where partial is the first ident. Whatever is in
there is matched with the appropriate @rule and override
what's in it with the partial. @partial font-face and
then put the descriptor. Font family or a weight or what
have you. Changes the font display value of font-faces
loaded from another source
TabAtkins: Only a handful of atomic cascade now, but this lets you
handle that override case
TabAtkins: Proposal in thread if we want it. Probably a new WD,
doesn't fit in Fonts spec. I'm happy to edit and pursue
if people are interested, but want interest before more
time
leaverou: How to determine which @rule it overrides?
myles: The way this would have to work is each @rule has to opt in.
By default none get a change and we opt in @rules. When it's
opted in it would have to spec how the partial rules match
with the base @rule. For Fonts there are 3 descriptors that
would match, different for other @ rules
TabAtkins: Font-family has to match and the partial has to be equal
to or less restrictive match on style, stretch, and
weight descriptors.
TabAtkins: If you only want the bolds you can specify that, or you
can allow for everything
TabAtkins: Defined by each @rule when it claims I'm allowed to be
extended. Rules are ad hoc for what the @rule does
chris: I agree with this belonging in separate spec. Also have
questions on how matching works. I understand how it works
for each @rule differently, but I'd like a definition that
says see each @rule for matching and there's a common term
the @rules can refer to.
chris: Seems generally useful, but I'd like more examples and where
it won't work, like I assume not on @supports
<fantasai> The contents of @supports already cascades
chris: I think it's great, it's really interesting
<chris> kind of like inherit applies to non-inheritable properties,
which is also a bit weird :)
dbaron: This feels like it's a confusing mechanism to me. Applies to
some but not other @rules. Applies to those that don't
cascade and turns them into cascading @rules
dbaron: I think it's confusing enough that some do that and some
don't. What TabAtkins said about @font-face where it
interacts differently also sounds weird and confusing
<fantasai> +1 to dbaron
<leaverou> +1 to dbaron as well
dbaron: I feel it might be better handled as extensions to each
@rule that needs this mechanism. Feels like a variant, not a
new @partial rule
TabAtkins: That's what it is, I'm just unifying it under one name to
be recognizable. The stuff after the @partial is what
that @rule wants to do its extension grammar with
chris: I think as unified as possible on extension mechanism is
better than duplicating half the @rules
myles: That's the direction I was going to mention
myles: 2 pieces, one to open a closed block and add stuff. Then
there's the specific idea of the fonts problem where
different people want to change different parts.
myles: Such a general solution would solve this use case. I don't
think this use case is sufficient for this complicated thing.
If there are other use cases the combination of them could
motivate.
astearns: As long as solutions are generalizable. I'd like to see
other rules we'd want to open and see if enough similar.
I'm a little scared with each rule can define how
overwritten with partial rule
TabAtkins: All reasonable.
TabAtkins: The particular use case for fonts is strong. I'd like to
address that. If we're not going for general until we
find more things, I'd push to solve this use case
myles: Rather than giving up I think somebody should do research to
see if there are use cases. We're asking the question, not
answering it
astearns: I think general solution merits a bit more work. Will need
non-font use cases so we can evaluate general solution
outside this thing that needs to be solved. Agreed we need
to solve this and we should take time to see if general
solution is the way to do. More specific @rules is a rats
nest we've added to for decades and normalizing would be
good
fantasai: I don't think a generic rule is normalizing anything.
Agree with dbaron that if we're going to do it...we might
decide on a specific syntax, but the @rule should be named
after its @rule and not be generic
TabAtkins: I don't care about @partial font-face or
@font-face.partial I just want to see partials as a thing
<myles> @partial font-face @partial-font-face @font-face-partial
<myles> @font-partial-face ????
<myles> @key-partial-frames
TabAtkins: Let's look at use cases, see if we can find decent ones
for other cases of extension. Maybe there's a good reason
to extend something like keyframes.
astearns: Alright. Sound good to everyone?
astearns: Alright, thanks.
<leaverou> Besides use cases, I'm also a bit concerned that we are
introducing a mechanism to override that is so completely
different than the cascade and completely breaks with
reordering. I was wondering if we can somehow "match" the
defined font-face rule and override it in a more
cascade-like manner
<fantasai> +1 to leaverou's comment about making sure this behaves
like a cascade
<astearns> leaverou: can you add your comment to the issue?
<leaverou> astearns: ok!
<myles> leaverou: i think you're right
<myles> leaverou: i've ranted about this before, one of the biggest
problems with @font-face from an implementor's point of view
is that it is trying to handle the things that are already
handled by selectors and properties
<myles> leaverou: implementing a second cascading system that's
separate than how selectors would be a disaster
<myles> leaverou: you are soooooo right.
<leaverou> Ok, comment posted :)
https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-446683982
CSS Inline
==========
Should first/last baseline values of `vertical-align` belong to
`alignment-baseline` or separate longhand?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/861#issuecomment-408323378
fantasai: Issue is scoped, but don't know how to make decision. I
don't have arguments in favor of either version.
astearns: That's it for the week. We'll meet next week. Thanks
everyone for calling in.
Received on Thursday, 13 December 2018 01:15:50 UTC