[CSSWG] Minutes Telecon 2018-03-07 [css-color-3] [css-fonts-3] [typed-om] [css-2018] [css-sizing] [css-backgrounds] [css-text-decor] [css3] [css-counter-styles] [css-images-4]
(too old to reply)
Dael Jackson
2018-03-08 10:55:08 UTC
Raw Message
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.

TYPO Conference

- Anyone interested in speaking should reach out to Rossen or reply
to the private thread.

CSS Color 3

- RESOLVED: Request a transition to PR for CSS Color 3

CSS Fonts 3

- RESOLVED: Publish updated CR of Fonts L3

CSS Typed OM

- TabAtkins will edit in his proposal for Houdini issue #716 (Trim
CSSResourceValue and subclasses to opaque objects for this
level, punt rest to level 2)

CSS Snapshot 2018

- The group approved the pull request in Issue #2281. Issue #2388
(List features cleared for shipping) will still need to be
resolved before publishing the snapshot.

CSS Sizing

- RESOLVED: Accept the edit in
with a clarification (for what counts as containing a
percentage) and a hyperlinked term (as to what is a
sizing property).

Backgrounds & Borders 3

- dbaron reviewed the Mozilla input tests with issues and filed an
issue to get help fixing the error they all had.
- There are still other tests that need to be reviewed.

Text Decoration

- RESOLVED: Change the default behavior for emphasis marks in the
current level of text decoration spec.

Backgrounds & Borders 4

- Issue #2114 (Border width rounding clarification) requires more
testing to discern if there is a common behavior that can be
standardized around.

CSS Counter Styles

- liam will file a bug on webkit to support setting list style to a
fixed string. Either he or franremy will add the same to
Microsoft's user voice.

CSS Images 4

- RESOLVED: Clear conic-gradient() for shipping


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Mar/0016.html

Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Garrett Berg
Tantek Çelik
Alex Critchfield
Elika Etemad
Dael Jackson
Dean Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Xidorn Quan
Liam Quin
François Remy
Florian Rivoal
Alan Stearns
Shane Stephens
Eric Willigers

Angelo Cano
Benjamin De Cock
Manuel Rego Casasnovas
Melanie Richards
Greg Whitworth

Scribe: dael

TYPO Conference

astearns: I think we should start.
astearns: Does anyone have any extra items to add today?
Rossen: I want to add one.
Rossen: I wanted to draw attention to the TYPO conference CSSWG
presentation. I don't think we've had much engagement on the
mailing list. I attempted to provoke conversation last week
there. I'd like to discussion options today.
[unminuted people trying to decide who can talk]
Rossen: Please reach out to me if you're at all interested even if
you're not sure. The conference is in a month from now so it
would be bad to have nothing prepared.
<fantasai> I thought I already said I wanted to present?
astearns: fantasai mentions on IRC she's interested. There's at
least 3 maybes. If you 3 could talk and if you do this on
the private list you can maybe get more people.
Rossen: Perfect.
<Chris> I can also do a cut-down portion of my webfonts talk as a
fallback if we have nothing better
Chris: I've got a web fonts talk I can cut from. It's prob better
from browser vendors then me, but as a fallback.
<leaverou> I can give my variables talk if needed
Rossen: I've achieved what I want. Let's re-engage on the private
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2018JanMar/0023.html

CSS Color 3

Transition back to PR

Chris: Published as a CR in Dec. Since we've had almost nothing in
comments. One was a stray semi-colon. So we need a resolution
to do a PR.
astearns: There was one substantive change with a passing test case.
Chris: Yes, it passes exit criteria.
<tantek> +1
astearns: Objections to requesting a transition to PR for CSS
Color 3?

RESOLVED: Request a transition to PR for CSS Color 3

Writing Modes


Rossen: While we're on the topic, can I ask the status of writing
modes which was supposed to rec some time ago?
astearns: Good question. I think what we're stuck on is getting an
updated test result. I believe liam has pledged to look
soon so we may want to wait on liam
liam: Yes, I'll be looking over the next week.
Rossen: Thank you liam. We were so close to rec and then there were
some minor issues and we're spiraling back from our progress.
florian: I don't know if fantasai is on the phone. There were edits
and tests to write based on a recent decision. She and I
made them and she'll be in Tokyo with koji to look at it.
liam's effort with theirs will be the final push.
astearns: Let's revisit next week.

CSS Fonts 3

Review disposition of comments, publish updated CR
<Chris> https://drafts.csswg.org/issues?spec=css-fonts-3&doc=cr-2017

Chris: There wasn't a DoC so I made one. I sent mail to the list in
case anyone had comments. No objections. There were a few
rejections due to compat. Spec is up to date, change list is
updated. We had a resolution to publish ages ago but we
weren't ready.
Chris: myles is on and I know there was work on fonts 4. Should we
publish together?
florian: I don't think they need to hold up.
Chris: We have updated tests for fonts 3.
myles: florian is correct there's no need to wait on one or the
other. I'm reaching a pretty good place to publish fonts 4.
Chris: Okay, that's fine.

florian: Saw lots of edits from Myles on css-fonts via twitter, and
was very happy about it.
<myles> yep, i went through all the issues marked "Needs Edits"
<myles> well, all but one

Chris: I'd like a re-resolution.
astearns: Comments on publishing updated CR of Fonts L3?
astearns: Objections?
<fantasai> +1 to publishing
<tantek> +1

RESOLVED: Publish updated CR of Fonts L3

astearns: Thanks Chris
<Chris> made a bunch of recent edits to fonts 3, too. Mainly
clarifications, see the changes section

CSS Typed OM

Trim CSSResourceValue and subclasses to opaque objects for this
level, punt rest to level 2
github: https://github.com/w3c/css-houdini-drafts/issues/716

shane: Let me look. I guess TabAtkins is not on.
astearns: I think it was taking things out of the first level, but
there's quite a lot of discussion.
shane: We need TabAtkins.

CSS Snapshot 2018
github: https://github.com/w3c/csswg-drafts/issues/2281

Chris: I saw a PR with all the changes. I commented favorably but
didn't approve to give time. florian anything else?
florian: I'm happy with what I wrote and comfortable that you agree.
It will not be enough to close the snapshot because there
are other open questions. List of specs is done. There's a
thing about indexes. Thread about if we should move
normative text.
Chris: That one we agreed we would. This snapshot will be a WD. When
we publish next year we'll republish as a note.
florian: If we agree on PR we'll merge it. If there's other things I
can agenda+ this back.
Chris: Okay.

florian: Is dbaron on?
florian: You suggested some additions. I took cascade 4 but the
others had too many issues for my taste. Would you like to
push back?
dbaron: I think they're getting a bunch of impl. If the issues
aren't getting resolved we need to deal with that.
florian: I think there is a stable core, but 50 open issues I don't
feel is stable and reliable. But we should get to them.
They should be on the priority list. But not on the already
fantasai: Snapshot to to document what's stable, not things that
should be. If there is some thing that we need to say this
is cleared to ship unprefixed in broad release as an
exception we can document that separately. These are
things that are okay to ship. Transitions, animations, and
transforms have been on the list forever. The spec isn't
dbaron: We should gather that list. We might need a category for
things that are stable because web needs them but spec
doesn't cover it yet.
florian: fantasai did open an issue about the first category.
<florian> https://github.com/w3c/csswg-drafts/issues/2388
florian: Link ^ please look.
florian: For the other suggestion do you want an issue on that
dbaron: Maybe. Might depend on this other issue.
florian: I'll agenda+ it now so we cycle back to it.

florian: For the pull, should we merge?
Chris: I would say we should. We can always make more changes later.
astearns: Agree.
<dbaron> Yeah, +1 to merging, can change more later if needed
florian: Agree

astearns: Anything more on the snapshot?
Chris: Assuming we get linking/indexing do people want more time to
suggest or do we move toward publish?
florian: I'd like a resolution to fantasai's issue but then we can
move to first public.
astearns: Let's go back to issue #2388 on a future week.
florian: Sounds good.

CSS Typed OM

Trim CSSResourceValue and subclasses to opaque objects for this
level, punt rest to level 2
github: https://github.com/w3c/css-houdini-drafts/issues/716

astearns: Now that we have TabAtkins.
TabAtkins: This was brought up a week or two ago as an ask for
review. Anne had some discussion.
TabAtkins: Big points: I did discuss rough outline before. Newer
bits: because CSS distinguishes between normal and
fragment-only URLs we want to reflect that in the URL
structure somehow. To say this is full or fragment. My
plan was storing what it was, but Anne remarked he would
prefer if it was referred more directly either as a
boolean or a separate URL class. franremy had a weak
TabAtkins: I'll do those edits soon. Any opinions let me know.
Otherwise I'll do what I outline in the thread here.

astearns: Any other opinions for TabAtkins to consider?
astearns: Alright. We're on notice you're going to change.
TabAtkins: I guess not. Wanted to ping for review because it's a
decent change.

CSS Sizing

Percentage sizing section is kind of vague
github: https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845

fantasai: Sizing issue was that we...we're asking for review of the
astearns: There is a test. There are proposed edits in the comment.
astearns: Basically you either want a resolution to make the edit or
reasons why not or things to improve?
fantasai: Yeah. Looking for review.
fantasai: For margins and padding case I think it's a separate issue
that we need to discuss.
fantasai: This text is just about sizing properties. margins is not
a sizing property.
fantasai: For margins and padding we could honor whatever is in the
calc that's not the percentage and treat percentage as 0.
I suspect that would not cause a problem and makes a bit
of sense to do if we can.
fantasai: For sizing properties it's more complicated because you
want to be able to measure the content. But for margins
and padding there isn't a thing to measure. So we could
resolve % against 0 to calc the containing block rather
then ignore the margin entirely.

franremy: This was brought up 2 weeks ago. me and dbaron reviewed
and I think we were both fine with the proposal. dbaron
pointed out you want to link to the sizing properties. I
think this is fine. We found more things to work on but
it's fine to open a new issue.
dbaron: The one sentence...the one comment is I think containing a
percent could be two different things. It could be syntactic
or mathematic.
tabatkins: 0% definitely should count as "containing a percentage".
franremy: I think there is a test that covered this. We can clarify
the text, but there is a test I think.
fantasai: Yeah, we need clarification.
dbaron: I'm fine given the clarification and hyperlink.

astearns: Other comments?
astearns: Does anyone object to the change with the clarification
and hyperlink?
<fantasai> Discussion of margins is kinda mixed in here:

RESOLVED: Accept the edit in
with a clarification and a hyperlinked term.

fantasai: I think margin stuff is in issue #2297
astearns: So franremy please look there and see if you can continue
in that or open a separate issue.


Min-content sizing currently too smart to be web compatible?

franremy: That was brought up last week. TabAtkins needed time to
review. I don't know if they had time. If not we can move
fantasai: Next week. I've been working on text last week.
<TabAtkins> Same, been heads-down on TypedOM this last week.
franremy: I think it's fine to skip

Backgrounds & Borders

20+ tests need correction
link: https://lists.w3.org/Archives/Public/www-style/2017Sep/0051.html

astearns: I think I saw some movement on this. I think someone
opened an issue?
dbaron: I went through Gerard's list. 2 chunks were Mozilla
contributed. We didn't do something right to get support
files in right. I filed an issue on that and if someone
wants to tell me how to fix that we can get them better.
There's a whole other piece.
<Chris> they need to be in a subdirectory called support
astearns: I don't think Gerard looks at github.
dbaron: I responded to thread too.
<dbaron> The issue I filed was
<dbaron> And my www-style response was

astearns: So there are other things that need to be addressed?
dbaron: Yes. They included a big chunk but there are others.
astearns: I know tmichel spent some time, but I don't know if he'll
spend more.
Chris: As I understand he's still tasked to work on it.
astearns: Okay. Could you prod him?
Chris: Yes.
astearns: Hopefully we can have Gerald help us with the fix. Anybody
else interested in looking at these issues? B&B is one of
those specs we could get to PR if we get the test issues
sorted out.
astearns: Not hearing volunteers.

CSS Text Decor

Characters to skip for emphasis marks (text-emphasis)
github: https://github.com/w3c/csswg-drafts/issues/839

fantasai: This is about emphasis marks that are the dots put over
the character. In general they're not on top of
punctuation or spaces, just characters. When we drafted
the css3 text for this koji and I asked what characters to
skip. At that time Japanese task force said usually skip
punctuation but the author might want to so you should put
markup to skip.
fantasai: That seemed to be their position and that's what we spec
and then in L4 we added a property to control on
punctuation or not etc.
fantasai: We got a comment from someone as to why the dots are on
the punctuation. That re-opened the topic. i18n said we
should do the right thing by default and a control to
allow other things.
fantasai: Not skipping punctuation by default means authors have to
do weird things with markup to get the right effect.
fantasai: Does the group want us to change the behavior to only put
emphasis on not-punctuation? Or keep the current behavior?
<Chris> it sounds like the right thing to do, and I guess unicode
character classes help there
florian: If there's no compat constraints doing the right thing for
default is better.
many: I agree.
Chris: Unicode character classes should make this fairly tractable
florian: Some punctuation and symbols might be mixed up but mostly

myles: Do you have specific text as to how to tell where they should
and should not go?
fantasai: Looking for the reference.
<fantasai> https://drafts.csswg.org/css-text-decor-4/#text-emphasis-skip
fantasai: It's here^
fantasai: Basically we'd propose to change the initial value to
spaces and punctuation.
astearns: And change the default behavior to be that setting.
astearns: Is text-emphasis-skip implemented?
fantasai: No but if you don't impl you have to do the initial value.
So we put the behavior to L3.
myles: Is there a reason this should inherent specificity from text
emphasis style?
fantasai: Yes because you don't want to reset what should skip.
myles: Isn't skipping document wide?
fantasai: Did I mix it up?
myles: No, no, you're right.
fantasai: Kinda similar to why text underline position doesn't get
reset by text decoration.
myles: Right. Okay

astearns: Given we have at least one complaint about current
behavior and i18n okay to change it seems reasonable to me
to move it into the current level of the spec.
astearns: Objections to changing the default behavior for emphasis
marks in the current level of text decoration spec?

RESOLVED: Change the default behavior for emphasis marks in the
current level of text decoration spec.

fantasai: I'll edit that in and we can cycle back to republish next

Backgrounds & Borders 4

Border width rounding clarification
github: https://github.com/w3c/csswg-drafts/issues/2114

fantasai: My question was do we want to work on this or leave it
undefined. In the past we have left this kind of thing
dbaron: Probably good to define better then we do, but not fully.
That requires careful work to do. It's work figuring out
what the range of behaviors is and figure out if there's
willingness to converge and then spec around that range.
astearns: So we need testing to see if there's something we could
spec that's interop.
franremy: It also depends on screen DPI which makes testing hard.
It's always been tricky to get this right. We get from
time to time reports we render differently but I am not
confident it's easy to explain the exact behavior because
every drawing path may be different. We need more testing
<dbaron> I think it's also more about the layout effects than the
drawing paths.
fantasai: Do we want to spend time on this and if so who?
franremy: Eventually I might be able to but it's not a priority.
We've been asked to investigate if we can be better
interop. It's a stretch goal we could look. I'm fine
assigning to me.
astearns: And I suggest franremy you can ask the person that opened
the issue if they have tests or evidence of convergence.
We can put it on them what the solution should be.
franremy: Sounds like an awesome idea.
astearns: Good on this issue?
fantasai: Yes.

CSS Counter Styles

testing considerations
link: (member only)

liam: I've been trying to get the tests for counter styles 3 up to
speed. 2 snags. One is there's only one impl of a lot of the
spec. There's an @rule to make your own counters. Mozilla has
done a reasonable job of impl but no one else has.
liam: To test the built in ones I discovered you can't override the
list items in browsers w/o counter styles 3. You're supposed
to say it can be a quoted string and only FF supports.
liam: I wanted to ask if anyone will impl this any time soon.
liam: I thought of putting the @rule in L4 but the other ones are
those you can't do the @rule. How can I ask for intent?
myles: Webkit has no one working on this right now.
liam: Microsoft?
franremy: If it's not on the status page we're probably not working
on it.

xidorn: I don't think the @rule needs to be a blocker. We can move
the requirement to impl in L4 and leave it in L3 as an
informative thing to define other style behavior. Is that
Chris: It's a worst case. We used to have this enormous list and now
there's a refactor so that for most there's the @rule and the
stylesheet designer describes it. If we go back to the magic
list it's strange. You get the things that can't be done
without the @rule with the @rule not in the spec. The spec
doesn't stand itself. If no one impl I guess that's all we
can do.

liam: Best compromise I can see is if other browser vendors impl
setting list style to a fixed string you can write a polyfill
for it.
<Chris> agreed, setting to a fixed string would really help here
myles: This is interesting to us, but this is the general response
of I want you to impl X: it would help if you described the
use cases and motivation in writing. That would help us
liam: I'm happy to. Do I do that as an issue against the draft?
fantasai: I'd file against webkit for the string value you
mentioned. Try and convince them to impl that so you have
the things you need.
franremy: I kind of recall getting a request from office to have
this feature but we didn't follow up strongly. I think if
support was better they'd want the feature.
liam: Yes.
astearns: Perhaps liam you could open an issue against webkit for
the fixed string and then franremy you can copy that to an
edge issue?
franremy: We don't have issue for new features. We keep that to
bugs. But there's probably something on user voice.
<Chris> put it on uservoice then!
myles: We track through bugs.
liam: Okay, buy end of tonight I'll have the webkit issue.
<franremy> https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/32403796-support-for-counter-style

CSS Images 4

Clear conic-gradient() for shipping
github: https://github.com/w3c/csswg-drafts/issues/2383

astearns: leaverou put it in the issue.
astearns: There's an impl, there's not outstanding problems. She
things it's time to clear it for shipping as Chrome wants
to ship. Likely won't be problems when other engines impl.
Chris: I agree. The polyfill has been out for a while and the syntax
is stable.
florian: No problem.
<florian> I support clearing it for shipping
leaverou: Implementation has been out for a year as well.

astearns: Any concerns about clearing for shipping?
<fantasai> sgtm
astearns: Objections for clearing conic-gradient for shipping?

RESOLVED: Clear conic-gradient() for shipping

Misc Announcements

astearns: I'm not sure there are other issues for the next 2 minutes.
fantasai: One thing to point out. There's issues about defining
max-lines block ellipsis and webkit line clamp. florian
and I worked for a few days. We posted a proposal. We're
putting this on F2F agenda, but please look before then if
<fantasai> https://github.com/w3c/csswg-drafts/issues/390#issuecomment-371076389

Rossen: I heard there was discussion about making normative changes
to CSS3 UI. Does this need WG time?
florian: Maybe at some point but not yet.
tantek: I don't think it needs WG time.
rossen: Making sure we're covered on our end
florian: I'll get back to the group if necessary.

florian: I made a 'tracked in DoC label' in github to help people
compiling DoCs

astearns: We're done. Talk to you all next week.