- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Jul 2018 20:26: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.
=========================================
CSS Box Styling
---------------
- RESOLVED: New module CSS Box Styling (css-box) to hold margin and
padding definitions.
Improving Contribution Workflow
-------------------------------
- TabAtkins will add an "Edit this spec" link to specs, once PR
#2320 has been fixed
Transforms
----------
- RESOLVED: Pad the shorter one with identity functions, find the
common prefix, interpolate common prefix pairwise,
interpolate the rest matrix-wise. (Issue #927)
- RESOLVED: Transform establishes a containing block for all
elements. (Issue #913)
- RESOLVED: Publish CSS Transforms Level 1 as a CR
Web Animations
--------------
- RESOLVED: Add these new editors of Web Animations [Robert Flack
immediately; Stephen McGruer and Antoine Quint once they
join the working group]
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: heycam
CSS Box Styling
===============
github: https://github.com/w3c/csswg-drafts/issues/2851
Need a spec for margin/padding
Rossen: This is something put forward by fantasai and Tab
fantasai: Basically we ported a lot of CSS 2.1 props to Level 3 spec
fantasai: Margin and padding properties haven't been copied over,
though, and don't really have a home in our new specs
fantasai: It would be useful if we had a spec to put these in
fantasai: I don't think any particular layout model spec makes
sense, since they affect every type of box
fantasai: Suggestion is to create a short spec just about margins,
paddings, what they are, and defining the terms margin
box, padding box, etc.
florian: And content box?
fantasai: Yes
TabAtkins: Sizing maybe
Rossen: Maybe that's in box model
dbaron: In Backgrounds and Borders?
fantasai: Yes but margin and padding aren't defined there
fantasai: Could make that Backgrounds, Borders, Margin and Padding!
fantasai: Or a new Box Styling module, which is padding, margins,
and maybe pull borders into there
florian: I think it would make sense to be in a standalone module
florian: to ease advancement
florian: Maybe we pull in border related props in general
florian: If not, we should have some anchoring terms like corner
shaping
florian: so modules that want to affect these kinds of boxes
fantasai: With no historical precedent, I would suggest Borders,
Margin and Padding in one spec
fantasai: but since Borders already live in B & B...
fantasai: I don't think it will take long, just going to copy over
definitions from 2.1, make sure they're in a Bikeshedded
spec
fantasai: and keep gradually replacing CSS 2.1 with modules
florian: So all the boxes, and the margin and padding props?
florian: Margin collapsing?
fantasai: No, margin collapsing goes in the Block Layout spec
florian: Sure
<fantasai> https://www.w3.org/TR/CSS2/box.html 8.1, 8.2, 8.3 (not
8.3.1), 8.4
astearns: If not planning on adding anything new, the only purpose
is to make it easier to write newer specs?
TabAtkins: And continue on our slow grind to obsolete CSS 2.1
fantasai: [mentions section numbers in CSS 2 for these definitions]
ericwilligers: What happens to CSS Box 3?
fantasai: Kill it
fantasai: Part of my proposal is to name this new spec css-box, so
we can overwrite that dangerously outdated spec
Rossen: Sounds like a good proposal
Rossen: So CSS Box Styling, overriding css-box
Rossen: alternate proposals or objections?
RESOLVED: New module CSS Box Styling (css-box) to hold margin and
padding definitions.
TabAtkins: We should re-tag all the old tests to the new spec
fantasai: Might want to also consider splitting the Borders out of
B&B to move into here
florian: Definition of border box should go in there immediately
<skk> Regarding new CSS Box Styling Module (css-box) is different
against https://drafts.csswg.org/css-box/ ? The naming sounds
a bit confusing.
<astearns> skk that's intentional - we want to replace the old
css-box
<skk> astearns Oh. I see! Thanks
Improving Contribution Workflow: Linking the .bs sources
========================================================
github: https://github.com/w3c/csswg-drafts/issues/2472
chris: This is for people proposing wording changes
chris: some people propose changes to generated files
chris: I was talking to this guy, asking how can we do it, so we can
find where the .bs file
chris: from the spec
chris: We've already got an ED, with a .bs link
chris: I want to say "right here, this wording, I want to find that
text in the .bs file"
TabAtkins: That's substantially more difficult
TabAtkins: I can do the first part
TabAtkins: second part is way harder
florian: First part, I'm not sure it's a good idea
florian: makes it easier to propose trivial fixes
florian: but also easier for PRs when they should be filing issues,
about more complicated problems
<fantasai> +1 to what Florian said
rachelandrew: Some people want to up the github contributions
rachelandrew: and file lots of trivial fixes
tantek: As long as this goes through the W3C IPR thing
tantek: that's actually a win
iank: For editorial changes it's non IPR required
tantek: But if that's the default, then serious folks will think, no
problem
tantek: Might be a barrier to these troublesome fixes
chris: I agree we do want to encourage issues for discussion
chris: we can just reply with that
tantek: If someone shows up proposing new text, it's someone we can
train to be a new editor!
florian: Sometimes
chris: They're already doing that, but just on a generated file
fantasai: I think we should remove the generated files from the repo
chris: They're mostly gone, but sometimes pop up
leaverou: Don't we have a .gitignore in the repo?
TabAtkins: We do, but if it got manually added, it will still be
there
chris: So it's easy to do the straightforward thing?
fantasai: I don't think it makes that big of a difference
fantasai: I'm concerned with florian's comment
fantasai: landing on a page to contribute a page without any
context, what our processes are
tantek: They're already doing that but against the generated versions
fantasai: Only have that for things on Bert's old preprocessor
chris: Fonts and Colors 3
florian: CSS 2
astearns: There are some FX specs too
fantasai: We should just delete those and solve them that way
tantek: Does FX still exist?
florian: As a repo, yes
tantek: We can assimilate it?
Rossen: We already have
plinss: Shaders and Compositing 2 are the only two in there with
generated files checked in
TabAtkins: I can add some default boilerplate, with some macros that
point to a new URL
florian: Weren't we saying that if the generated specs aren't in the
repo we don't need that link?
TabAtkins: No
florian: Because the purpose of that link is to avoid changing the
output, and if the output isn't there, it's fine?
TabAtkins: One benefit is that. another benefit is to encourage
small changes / typo fixes more easily
TabAtkins: Less friction for typo PRs the better
florian: We can try
Rossen: How many non trivial PRs will we get?
[some discussion about WHATWG contribution]
Rossen: Sounds like Tab can add a link to change the original source
fantasai: I would prefer not to have a link without info/context to
what editing the spec means
Rossen: How to add that info?
fantasai: We can do that if we want to, ways we can do it, but it's
not a link to "here edit this spec"
TabAtkins: I would like to try this out without assuming people will
make substantive changes without discussion
Rossen: Let's roll it out to a couple of specs
TabAtkins: I'll do it for all specs
myles: Let's just try it, get more engagement
fantasai: No reason to do a subset
Rossen: ok then
fantasai: But would like to note the documentation sucks on how the
WG operates, we need to fix that.
florian: When you open a PR you get some information right?
florian: there's on old blog that's a bit outdated
chris: I know on GitHub you can have issue templates. Can we do that
for PRs?
TabAtkins: Yes
<TabAtkins> `"!Edit This Spec":
"https://github.com/w3c/csswg-drafts/blob/master/[VSHORTNAME]/Overview.bs"`
florian: For quick fix, this is welcome, if substantial, don't start
with a PR
tantek: I've seen things about code of conduct etc. agreements, so
presumably we can do this
rachelandrew: I can write some text that's easy to read about
contributions if that's helpful
<fantasai> https://github.com/w3c/csswg-drafts/pull/2320
fantasai: I would like this ^ fixed up and merged in before doing
this
florian: Yes
ACTION: Tab to add an "Edit this spec" link to specs, once #2320 has
been fixed
[ At this point a section of the group did a breakout on Transforms,
Animations, Transitions - all open issues. What follows is the
minutes from that breakout ]
Transforms
==========
Scribe: ericwilligers
Smarter interpolation of truncated transform lists
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/927
birtles: (summarizing) There was a proposal for when we have
mismatched transform lists to do something smarter than
matrix interpolation
birtles: We resolved on some behavior (April 2017) but when
implementing, spec text did not match what was discussed in
WG.
birtles: We implemented what is in spec text but we want to do
something smarter: interpolate common prefix and use matrix
interpolation for the remainder
krit: Do other implementers also want to change?
dino: We should do this: go as far as you can, smoosh the rest
iank: Will have to check with Waterloo team
rossen: No objection
[pad the shorter one with identity functions, find the common prefix.
interpolate common prefix pairwise, interpolate the rest
matrix-wise]
krit: Proposal from fantasai to do the same from the right if they
have a common suffix.
tabatkins: Don't like it - common to have ambiguous situations
krit: Agree
tabatkins: Prefer prefix over suffix, prefer not to try to do both
<birtles> I agree
RESOLVED: Pad the shorter one with identity functions, find the
common prefix, interpolate common prefix pairwise,
interpolate the rest matrix-wise.
Make transform a containing block for all descendants
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/913
krit: Because of the compositing model of many browsers, much the
same reason as for filter effects
rossen: This means it will also be a containing block for fixed?
<krit> https://github.com/angular/material2/issues/3031
rossen: Is there interop?
<birtles> dbaron has a test for some of these cases
https://dbaron.org/css/test/2018/stacking-context-z-order
ericwilligers: Motion path and individual transform properties
explicitly create a containing block and stacking
context.
rossen: Seems like transform in Edge and Chrome and Firefox is
considered a containing block.
birtles: transform-style flat creates a stacking context in the spec
but not implementations.
krit: Some developers don't like the behavior - some want fixed-pos
to not create a containing block even if there is a transform.
dbaron: It is a little late to change that.
dbaron: I tried this on 4 engines. Notes at the bottom of test
linked above.
dbaron: This is testing many different things. Green means it does
the thing, red means it does not. Sometimes does not
correspond to pass/fail.
dbaron: Crossed out means the engine does not implement property.
krit: Confirm WebKit behaves same as Edge and Chrome and Firefox in
creating a containing block.
krit: Will we resolve for filter too?
RESOLVED: transform establishes a containing block for all elements.
Scribe: dino
ericwilligers: Didn't we resolve to add a few options for
transform-box?
ericwilligers: It's already in the spec
ericwilligers: I'm just noting that there have been differences
since the most recent publication
CSS Transforms Last Call
------------------------
dbaron: Last call doesn't exist any more. Do you mean CR?
krit: I don't know what it is called. But I meant Last Call.
ericwilligers: The concern is that there is no interop for
transform-box
dbaron: That's fine for entering CR
Rossen: We should definitely go to CR
Rossen: Once the changes are in
Rossen: krit, are you going to do the work preparing for CR?
krit: yes
krit: I'll work with Chris Lilley
Rossen: any objections to taking transforms level 1 to CR
RESOLVED: Publish CSS Transforms Level 1 as a CR
Updating Editors for Web Animations
===================================
birtles: Supposedly we need WG approval to change editors
birtles: shane and doug are currently editors but can no longer
continue
birtles: I propose adding Robert Flack (Google), Stephen McGruer
(Google), Antoine Quint (Apple). The latter two need to
join the WG.
Rossen: We can't add them while they are not members. Add Flack now.
Rossen: Objections to adding Flack?
[none]
Rossen: Any objections to adding McGruer and Quint when they become
CSS members?
[none]
RESOLVED: Add these new editors of Web Animations
Any more animations or transitions issues
=========================================
birtles: Not many that are worth discussing
birtles: I'm blocked on moving definitions into values and units.
Tab and fantasai offered to help. They can't continue to
live in transitions.
birtles: The other issue is I need to redo a lot of WPT because they
are not very reliable. We've disabled a bunch in gecko due
to flakiness.
birtles: This makes it hard to edit the spec and make more tests
birtles: I need to get those fixed
krit: Maybe eric wants to discuss filter on root?
Rossen: We might need simon for this. What is it about?
<krit> https://github.com/w3c/fxtf-drafts/pull/263
Rossen: I think we discussed this 2 weeks ago, and we need a lot
more investigation. It will happen on github.
Rossen: We are adjourned.
Received on Friday, 20 July 2018 00:27:44 UTC