- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Jun 2016 20:36:16 -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 WG Charter
--------------
- astearns will input the dates he proposed on the private mailing
list (available here:
https://lists.w3.org/Archives/Member/w3c-css-wg/2016AprJun/0251.html)
Scroll Snap Publication
-----------------------
- RESOLVED: Publish CSS Scroll Snap
Line breaking opportunities at the boundary of a white-space:pre
inline element
---------------------------------------------------------------------
- RESOLVED: Line break opportunities should be controlled by the
parent.
Round Display
-------------
- The 'auto' value of offset-position will be written to mean do
nothing to the position of the element.
- 'contain' will be moved into offset-path as it's only relevant
when there's an angle.
- RESOLVED: Change the initial value of offset-rotation to 0deg.
- jihye will move the offset-* properties into the Motion Path.
Edits that have been accepted and need WG approval for MQ
---------------------------------------------------------
- RESOLVED: Rename update-frequency to update (issue #1).
- RESOLVED: Rename normal to fast (issue #1).
- RESOLVED: Move inverted colors to level 5 (issue #8).
- RESOLVED: Move custom MQ to level 5 (issue #9).
- RESOLVED: Publish a new WD of MQ4.
Grid Issues
-----------
- A decision on what happens with grid line names when dropping
tracks (Issue here: https://github.com/w3c/csswg-drafts/issues/172w)
was deferred until next week to give people time to review.
- RESOLVED: vertical-align: baseline means first baseline except
for inline-blocks (due to CSS2.1 legacy)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0151.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Jihye Hong
Joone Hur
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Michael Miller
Edward O'Connor
Simon Pieters
Anton Prowse
Liam Quin
Matt Rakow
Florian Rivoal
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Ian Vollick
Scribe: dael
Rossen: Let's get going.
Rossen: As usual, let's start with a quick call for anything to
add to the agenda.
CSS WG Charter
==============
Rossen: There have been a few updates since last week.
Rossen: The one remaining piece is going over the dates and
finalizing.
Rossen: There was an email started by astearns and there have been
dates proposed and chatter. astearns can you summarize?
astearns: I put together a straw man schedule I think we should
put in the charter and then do what we can to meet those
dates.
astearns: The other thing that needs to go in is the list of
things working on. TabAtkins gave me an automation that
has about half the information. I'm hand-editing the
rest and should be done today.
Rossen: To the WG: has everyone had a chance to look at the
proposed straw man dates from the private list?
Florian: Just the part that lists REC right?
astearns: Right. This is REC dates over the charter period.
Florian: That seemed reasonable.
Florian: I haven't looked at the rest. What do we say about things
not listed as going to REC. Do we list them all or...?
astearns: Current plan is have them in list of things working on,
show current status, and not give dates for progression.
plh thought that was okay.
ChrisL: Deliverables and dates are separate sections.
Florian: For a spec like CSS 3 UI which has been fairly
implemented fairly tested but not fully we just don't say
anything special?
astearns: Correct. It doesn't mean we can't work on it.
<Florian> then it looks all good to me
Rossen: Again, to summarize. It sounds like our plan is to put the
automated list of drafts in the scope section. Dates will
be those astearns posted.
Rossen: That will send a message the rest is in progress but don't
have a clear idea of where it will land.
Rossen: Is everyone okay with that?
<ChrisL> +1
<glazou> +1 to rossen
hober: Sure.
fantasai: My position is if people don't commit to testing nothing
will get to REC so I'm skeptical of the dates.
Rossen: That's okay.
glazou: That's no different than the last 20 years. We've always
had a testing problem.
Florian: There is discussion in the AC forum about that. There's
talks about if we can change the charter process to deal
with that, but it's not changed yet.
Rossen: Anything else anyone wants to bring up? Otherwise we can
action astearns to make the edits.
ACTION astearns make the edits to have your proposed rec dates in
the charter
<trackbot> Created ACTION-780
Scroll Snap Publication
=======================
Rossen: Just a quick request for a resolution.
Rossen: Anyone opposed to publishing CSS scroll snap?
RESOLVED: Publish CSS scroll snap
<MaRakow> yay :)
ChrisL: fantasai are you using the automatic from bikeshed or does
it need to queue?
fantasai: It needs to be queued up. There's a short name change.
ChrisL: You don't have to zip it, I can do it manually.
fantasai: short name change is to css-scroll-snap
<fantasai> css-snappoints -> css-scroll-snap
<ChrisL> css-scroll-snap-1 ?
<fantasai> yep
Rossen: And we have a resolution on that and that editors are
yourself, TabAtkins and MaRakow.
fantasai: Yes.
Rossen: Great. Let's get that to a more final WD and proceed.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jun/0020.html
<- previous resolutions on name change, editorship, etc.
<TabAtkins> ChrisL: If you run `bikeshed echidna --just-tar`,
it'll prepare a TAR with all the TR fixes you need
before publishing.
<TabAtkins> ChrisL: In the folder you run it in.
<ChrisL> cool
<ChrisL> although, see my recent comments on bikeshed issues about
that, still things to fix manually
Line breaking opportunities at the boundary of a white-space:pre
inline element
=====================================================================
<Florian> https://github.com/w3c/csswg-drafts/issues/189
<Florian> <p>あいうえお<span style="white-space:pre">か</span>きくけこ</p>
Florian: Here's the relevant bit of code.
Florian: I've been through the spec and it doesn't say how it
should work. If you didn't have the span you'd have a
line break opportunity between all characters. We have
the white-space:pre in there. Should you be able to break
on element boundaries? All browsers except blink and the
webkit family do.
Florian: I suspect that's from another bug they have. But either
way the spec doesn't say it's a bug and I think it is.
Florian: On github we were leaning toward when white-space:pre is
applied to an element the parent should determine.
fantasai: It should be just like letter spacing where the spacing
is given by the parent.
Florian: I think so too. If everyone agrees can we put it in the
spec?
fantasai: I agree.
Florian: I suspect we have the same issue about things like
word-break, but I didn't check the spec.
fantasai: Line break opportunities should be controlled by the
parent. All of them.
Florian: Makes sense to me.
Rossen: Okay. Question. When you say parent do you mean block
container parent or parent?
<fantasai> by block container parent, you meant "containing block"
:)
fantasai: Parent of the boundary.
Rossen: Okay.
Rossen: Any objections?
<bcampbell> I'm seeing this in the git issue, is that just me?
"<p>あいうえお<span style="white-space:pre">か</span>きくけこ
</p>"
RESOLVED: Line break opportunities should be controlled by the
parent.
<dbaron> by "the parent" do we mean "the nearest common ancestor"?
CSS Round Display
=================
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jun/0126.html
<jihye> https://github.com/w3c/csswg-drafts/issues/214
jihye: I think it's better to see the github conversation. At San
Francisco F2F there was a resolution to integrate polar
positioning to motion path.
<jihye> https://drafts.csswg.org/css-round-display/#positioning-content
jihye: I wrote a draft to describe the resolution.
jihye: Properties related to polar positioning were merged to
motion path. It's not just about motion but becomes path
positioning. There are some properties that changed the
name. offset-path and the like.
jihye: offset-path defines the path an element can move on. It's a
merge of motion path and polar-angle. offset-distance is
the positioned element along the path. offset-anchor is the
origin of the element which comes from round display polar
anchor. I have another suggestion for rotation that wasn't
in resolution.
jihye: There's 2 issues to discuss.
jihye: First is about the need for offset-position. It is similar
to polar origin.
jihye: The path which the element is positioned along is specified
by offset path property. When angle is given to offset-path
it is a straight line with the degree of the angle.
jihye: The start is the center of the containing block and end is
the edge of the containing block.
jihye: Initial position of the elements is the start point of the
path. After defining the path like that we can use
offset-position. I defined polar-position as specifying the
initial position. For example when I define:
<jihye> offset-path: 90deg;
jihye: It means the path starts at the center and ends at the
middle of the right-side edge.
<jihye> offset-position: 0% 50%
jihye: Then I add offset-position: 0% 50% the path starts at the
middle of the left side edge and ends at the middle of the
right side edge.
* smfr needs to see pictures
jihye: With this use case, do you think it's useful and defined
properly?
bradk: Several things aren't what I understood the resolution to
be in San Francisco. Offset-position when discussed I
agreed to because it had use independent of if you're
moving along a path. We didn't say when using path it jumps
to the center. The path is a position relative to where the
element started. So if you use relpos or top it starts
where ever it started.
<fantasai> +1 to bradk
bradk: If you did an angle you'd move from an angle. Not that it
jumps to the beginning of the position.
bradk: Instead of positioning the shape for the containing block
you position the path's initial point to the element. That
was it works to all the other positioning properties like
top and offset and position: relative.
<TabAtkins> And starting it in the center is just a matter of
"offset-path: 45deg; offset-position: center;"
fantasai: The auto value of offset-position was intended to be
don't do anything special to the position of the
element. If it was relpos it would be based on its
position. If abspos it's from the calculation in 2.1 and
left/right etc. properties. The position of the element
and path is determined by the position. When it's not
auto it moves according to offset-position.
bradk: I don't think you need offset-position to come up with the
origin. We described that you would start from where ever
the position was. You don't need it for an origin point.
Florian: There were two reasons why it was better that way. One
being that the path itself will change depending on where
you put the origin. If it's not center and goes to edge
it's different points than center to the edge.
bradk: And that's what offset-anchor was for.
fantasai: You're mixing it up.
bradk: You need an anchor for where align point to element.
fantasai: The original proposal says where the path begins. From
that point you go at an angle until you reach the edge.
If you start center and go to edge length is 50%.
fantasai: This applies even if the element is a 1x1px. The path
will change depending on origin.
fantasai: Where you attach element to path is the anchor.
fantasai: Where the path is with respect to containing block is
origin.
bradk: If using offset:position.
Florian: It doesn't just change the position, but also the shape.
bradk: Why?
Florian: If you say center and right you do it as center bottom.
bradk: For a circle or whatever the only odd thing is the inset
shape. For everything else you position the path the the
point.
fantasai: It changes what percentage means. 100% means all the
way, 0% means stay. 100% changes depending on length of
path and length depends the origin and end point.
bradk: Shouldn't. Percentage should be of containing block
fantasai: No of the path. If you do polar positioning and you want
45 deg 100% should go as far as you want until the edge.
That isn't how it's defined in the spec.
<ChrisL> agree with fantasai, this is how it should work
bradk: I'm talking about where the path is relative to the
element. The distance part doesn't come into that expect
you're picking a size for the path. You're taking a length
along that path. As long as you have the length you can be
positioned along it.
jihye: When path is defined by angle it has to pass through the
center point.
bradk: Why?
bradk: You pick where it starts based on element, pick an array,
and determine your point along that. You need to know where
it starts relative to the element itself.
jihye: I agree. Path doesn't have to start at center. Path has to
pass through the center of the containing block.
bradk: No...
fantasai: The auto values need to be fixed. I think everything
else is fine.
Florian: Another point of difference. offset-difference has
optional contain keyword and the like. I think they
should be on the path not the distance.
fantasai: Yes.
Florian: Because they define what the path is. 100% gets you 100%
on the path. Right now the contain and the like keywords
are attached to the distance. But since we decided to put
the angle as a part of the path they should go together
with the angle to define the path. And 100% means 100% of
the path.
jihye: I put contain on the offset-distance because when I first
suggested it for polar the major use is the element is not
overflowing from containing block.
Florian: I'm not changing behavior, but which property. What we
put it in is offset-path, not -distance. At least I
think. Behavior is correct, it's which property it goes
in.
bradk: I'm not sure the advantage of one or the other.
Florian: When offset-path isn't an angle what do the keywords mean
on the distance. That's why they have to stay with angle.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0233.html
<fantasai> Florian: offset-path newly takes an angle plus a
keyword (as yet
<fantasai> undefined list, including contain).
jihye: When offset-anchor is the center of the element and
offset-distance is 100% then some part of the element can
overflow from containing block. So when you put contain on
offset-distance the overflowing part can come inside the
containing block.
Florian: But for offset-path let's say you have a circle or a
polygon. And then on offset-distance you have the closest
edge. What does that mean?
Florian: I don't think it has a clear meaning. And I think the
behavior is correct but only makes sense when there's an
angle. That's why I think it should be with the angle.
When you have it with and angle and percentage I think
we're fine.
bradk: Florian, I think I agree, but I guess you could shrink the
path to be contain.
TabAtkins: That's going way beyond the use cases. It's keeping a
polar element from overflowing.
bradk: But it would more or less. I think I agree it's just a part
of path.
Rossen: Going back to jihye...
Rossen: Are you okay with that?
jihye: Now I agree with Florian. I agree with contain keyword is
meaningful when path has an angle value. I think contain
should be moved to offset-path. I agree with that.
Florian: And same with closest-side, etc.
jihye: I agree.
Rossen: Do you need a resolution from the WG or is this already
covered?
jihye: The offset-position I defined on the spec has to be changed
or remain?
bradk: The important thing on offset-position it shouldn't be
required on path movement. You start the path on the
element, not the containing block.
Florian: I think we had agreed on that.
Rossen: I'm trying to stop us before we open the can of worms.
Florian: We're in the can already.
fantasai: Offset-position always has a value and the initial is
auto and it means do the things.
<fantasai> that you would do if offset-position didn't exist.
Rossen: And that's what we agreed already.
<fantasai> yes
TabAtkins: But the spec doesn't say that.
Rossen: So it's editorial to make the changes.
<fantasai> Right, the spec needs to be brought in line with the
resolution.
Florian: Yep. It's just auto stops doing the magic.
<fantasai> It's not editorial, it's correcting the spec.
Rossen: So the proposed path is jihye to take the clarifications
into the spec. And that's it.
<fantasai> It's not clarifications, it's fixes.
<fantasai> Clarifications don't change behavior, this will. It
will change the behavior to match the resolution.
bradk: I'm still not clear on the auto magic.
Rossen: Same as SF
TabAtkins: Basically stop doing magic.
jihye: I have 1 more topic. Initial value of offset-rotation
jihye: Motion rotation means the path the element moves along.
Initial value of auto is reasonable while element moves
being rotated in direction of the path seems natural.
offset-path could be for an element without motion. So in
this case having initial rotation as 0deg is natural
<fantasai> +1 to 0deg initial value
jihye: I think 0deg is more proper than auto as the initial value
for offset-rotation. Is it okay to change that?
fantasai: I strongly agree.
bradk: So do I. I think the only person who had it different is
shans. We always had it so that if the property doesn't
exist it matched and 0deg is that.
TabAtkins: We should probably re-name auto to be more useful. Like
follow or match. Don't need to discuss that now.
bradk: There's another issue as to if we can use transforms, but
that's a different day.
Rossen: So proposed resolution is to change to 0deg as the initial
value of offset-rotation.
Florian: Isn't there a compat issue? It's changing the initial
value of an existing property.
TabAtkins: This isn't existing.
Florian: It's called motion.
bradk: That's separate and I don't think it's impl.
TabAtkins: The motion properties aren't publicly impl. I think we
have them a behind a flag. We have room to change.
bradk: With a different property name there isn't an issue.
TabAtkins: There's 0 compat issues
Florian: caniuse.com says motion path is enabled in Chrome.
ChrisL: That's in SVG.
Florian: Alright.
Rossen: I'll take TabAtkins's word.
Rossen: Any objections to the resolution?
RESOLVED: change to 0deg as the initial value of offset-rotation
TabAtkins: Final bit. I thought we agreed to move these to motion
path spec. I'd like to do that or resolve on it. It's
the proper place for them to live.
Rossen: I don't recall.
Florian: I think we had one and added jihye as a co editor.
Rossen: Okay. Who is editing motion path?
jihye: shans
bradk: What do we move?
TabAtkins: All of them. They're transform based at the bottom.
Florian: Yep.
TabAtkins: They all get triggered into a transform in the
transformation matrix.
bradk: I guess, but offset-position doesn't have much to do with
paths.
fantasai: It doesn't belong in round display. We can argue on the
rest later.
<astearns> from the SF minutes: "The motion path spec will need to
be renamed since it's more about path positioning than
it is about motion."
fantasai: shans agreed with the changes and we added jihye as the
editor.
ACTION: jihye to move offset- properties to motion-path spec
<trackbot> Created ACTION-781
Edits that have been accepted and need WG approval for MQ
=========================================================
<Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-1
<Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-8
<Rossen> https://drafts.csswg.org/mediaqueries/issues-wd-2016-01-26#issue-9
Issue #1
--------
fantasai: There were some issues. 1 was rename update-frequency:
normal to update: fast.
fantasai: List seemed to find that okay.
fantasai: Dunno if there are other opinions.
<fantasai> https://drafts.csswg.org/mediaqueries/#update
<fantasai> So, two changes: 1) rename update-frequence to update
2) rename normal to fast
Florian: I'm okay with the change, but I think there was a purpose
to the naming. slow and fast doesn't give a reference
point. When you have slow and normal it's quite clear.
It's the usual thing and slow. But then again people can
read the spec.
Rossen: Okay. fantasai you want a resolution?
fantasai: One to rename the property and one to rename the value
Rossen: Property first. Objections?
RESOLVED: Rename update-frequency to update (issue #1).
Rossen: Objections on normal to fast?
Florian: I prefer the other but don't object
RESOLVED: Rename normal to fast (issue #1).
Issue #8
--------
Rossen: Defer inverted colors is next.
fantasai: Yeah. Discussed deferring it so we can do a proper
evaluation for all the things needed to handle colors
correctly since it's not clear that's sorted out.
Proposal is to move this so we can cut down to
everything stable and ship this summer.
Florian: I think deferring is okay. This is an investigation we
haven't done.
Rossen: I'd agree on moving this to later. As an implementor of
high contrast more time would be good.
Rossen: Any objections to moving inverted colors to level 5?
RESOLVED: Move inverted colors to level 5 (issue #8)
Issue #9
--------
Rossen: Issue #9
fantasai: This one isn't 100% baked so defer it to level 5.
Florian: I'm okay with it. I think TabAtkins intended to move to
houdini?
TabAtkins: We'll move it where it needs to be. Doesn't matter.
Rossen: Objections to move custom MQ to level 5?
RESOLVED: Move custom MQ to level 5 (issue #9).
Publication
-----------
Rossen: Any other MQ items?
fantasai: There's some stuff for later, but I think we should
publish a new WD and deal with the next set of issues in
the next cycle.
Rossen: That would be great. Anyone objecting?
RESOLVED: Publish a new WD of MQ4.
TabAtkins: I'll handle publication.
<ChrisL> tab, mq4 is already in place and queued for publication
tomorrow
Grid
====
What happens with grid line names when dropping tracks
------------------------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/172
fantasai: We discussed...the question was with the auto-fit:
repeat we dropped tracks that were empty after the
layout. You collapse and give them 0 width and merge
gutters. We made a proposed set of edits and what to
resolve on this definition shift.
fantasai: The collapse helps with the abspos items that need to
define where they are if using lines. Also output of
CSSOM is clear because it's just 0 width. In terms of
determining positioning and gaps the gutters around
collapsed tracks are collapsed to nothing. If you're in
the middle of the grid they overlap. This gives the
expected behavior.
Rossen: Only end or beginning as well?
fantasai: It's symmetric.
fantasai: We wanted to define the correct behavior, not because we
expect this to be common but it's quite likely we'll add
a concept of collapsing tracks explicitly. Looking
forward this hooks into how that would work.
<fantasai> https://github.com/w3c/csswg-drafts/commit/ac370302681c2425777a57b8461281e1bd88afc8
fantasai: That's the change set.
Rossen: Any comment or feedback?
Rossen: I don't hear anything. I'm personally behind on this, but
I can comment on github. Are you looking for a particular
outcome?
fantasai: Resolution on the change.
fantasai: We can defer a week
Rossen: That would be great for us.
TabAtkins: We just wrote it yesterday.
Rossen: If you're okay to push a week let's do that.
Baseline alignment
------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/195
fantasai: Do you align to the first or last baseline? We say the
first. In CSS 2.1 it has tables align to the first and
inline blocks to the last. Other precedent is how
baseline values work in flexbox which always uses the
first. So grid will interpret first line is the baseline.
Rossen: I'm in favor of keeping those in sync as much as can.
Rossen: We do the same for inline tables as well?
fantasai: Yes, that's the first row.
Rossen: So I'm even in more favor.
Rossen: Objections?
RESOLVED: vertical-align: baseline means first baseline except for
inline-blocks (due to CSS2.1 legacy)
fantasai: Last one, #8, needs more work from TabAtkins and I. It
needs to defer anyway.
Rossen: In that case that's the top of the hour and the end of the
agenda. Thank you everyone. We'll call it a day.
Rossen: Thanks, bye
Received on Thursday, 23 June 2016 00:37:21 UTC