- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Nov 2016 21:45:27 -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.
=========================================
TTML2 horizontal review request
-------------------------------
- Anyone with interest was asked to respond to the review request.
Remaining Grid Layout Issues
----------------------------
- fantasai wasn't ready to discuss these issues yet so the
conversation will continue in hopes of being able to come to
the group for resolution next week.
offset-rotation vs rotate
-------------------------
- RESOLVED: Rename offset-rotation to be offset-rotate
- TabAktins was actioned to confirm this change is okay with Blink
since no one was on the call to speak for them.
Was the position of 'mask-mode' in the 'mask' shorthand intentional?
--------------------------------------------------------------------
- RESOLVED: mask-mode can be anywhere in the mask-shorthand other
than between position and size
Add shorthands for alignment properties
---------------------------------------
- There were concerns that adding the slash created an
inconsistency with other established properties such as in
background-position.
- On the other hand, there was a feeling that the slash would be
intuitive to those that use grid and flexbox and that not
having the slash creates a bad precedent.
- RESOLVED: Don't add the slashes.
- The group moved on to discussing what would be needed to move
Align to CR since there are dependencies for Grid.
- fantasai proposed trimming the spec to have only single-keyword
values only for longhands in this level of Align and moving
the rest to the next level. These properties are derived from
Flexbox and are therefore stable and unlikely to change.
- dbaron expressed a desire to know what is already shipping in
browsers before removing items from the spec so discussion
will continue next week once there's a fuller picture of
what's shipping.
====== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0101.html
Present:
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Peter Linss
Michael Miller
Anton Prowse
Liam Quin
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Steve Zilles
Regrets:
Rachel Andrew
Vlad Levantovsky
Myles Maxfield
Greg Whitworth
Scribe: dael
Rossen: Any extra items?
tantek: Not an extra, but a request to talk about #8 on the agenda
first.
Rossen: And what's the reason?
tantek: We've been trying to do it for ages. We need a resolution
because we're trying to ship soon. Like today.
Rossen: How about I make sure we have time? We have other issues
that were issue+ a few weeks ago on fx list that we missed.
Rossen: Any additional requests?
TTML2 Horizontal Review Request
-------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Nov/0091.html
Rossen: Anyone with interest or spare time could do this review
request.
Rossen: I added the item to bring attention.
Rossen: Please take notice if you're interested. The deadline is
soon.
Rossen: They don't have an exact one but let's assume they're not
far off.
Remaining Grid Layout Issues
----------------------------
Rossen: There were a bunch of issues from an implementor.
fantasai: What I meant in my e-mail is all the keywords and values
in flexbox or anything trivially analogous. Any single
value syntax of alignment is stable enough to ship. Any
two value I'm less sure about.
Rossen: What about min/max?
fantasai: The implied size of grid items I haven't looked in
detail yet.
Rossen: Okay, so we're not ready yet. We should look as this could
be behavior change in the spec.
Rossen: You mentioned item 3 on the list from the dev you've
looked at?
fantasai: I haven't had time to do anything. I'll work on things
starting today.
Rossen: So it should like we can't make much progress today.
Rossen: I'm not hearing any takers. Let's push to next week.
fantasai: I'm hoping we can close next week.
jensimmons: I know FF engineers are looking to ship so there's
urgency.
Rossen: Yep. That's the same vibe I'm getting from Chromium impl.
<gsnedders> (It's no longer behind the experimental flag in
Chromium now)
Rossen: We've got the attention of the right people.
offset-rotation vs rotate
-------------------------
<Rossen> https://github.com/w3c/fxtf-drafts/issues/70
jihye: In motion path there is a property name offset-rotation and
it defines the object's orientation that's positioned along
a path.
jihye: fantasai pointed out there's a rotate property in transform
spec and using the work rotate would be grammatically
consistent.
jihye: I agree because features in CSS are using rotate. Therefore
I think renaming to offset-rotate is reasonable.
jihye: I worry that the property is already shipped in Blink. Will
renaming matter for the implementation?
<jihye> https://drafts.fxtf.org/motion-1/#offset-rotation-property
<jihye> https://bugs.chromium.org/p/chromium/issues/detail?id=637543
Rossen: Anyone from Blink on?
<dbaron> One other concern is that I feel like property names are
usually nouns or adjectives rather than verbs
fantasai: I suggest we resolve that if shane says it's okay we
rename.
Rossen: That would mean for them they would need an alias for some
time. I'm okay with going with that. I wanted to hear if
anyone else in the WG has an opinion on renaming
offset-rotation to offset-rotate.
dbaron: We usually use nouns or adjectives not verbs. We've mostly
been consistent about that. So I feel like it's the names
in transforms that are unusual though consistent with
values for transform
fantasai: I think that's more important. We try and reduce amount
of grammatical morphemes. We try and avoid conjugations.
dbaron: Like text-decorate?
fantasai: That's an exception
dbaron: I think there's others.
fantasai: Yeah.
<dbaron> font-vary, direct, color-interpolate, opaque :-)
<Bert> (but vertical-align and text-align rather than
vertical-alignment/text-alignment')
<jensimmons> background-position
<jensimmons> text-transform
<jensimmons> position
<jensimmons> text-decoration:
fremy: Since there's no one from Blink I can't speak for them but
maybe we should not change it because the value of changing
isn't that big and we'd break an implementation.
Rossen: fantasai proposed renaming it but leaving it open until
someone from the Blink team looks at it.
fremy: That's fine too.
Rossen: dbaron's point about already having some inconsistency is
a valid point. Do we want to have offset-rotation to be
offset-rotate?
Rossen: fantasai do you feel strongly?
fantasai: We should resolve the inconsistency. We're using rotate
in the transform name and the value of the property. So
offset-rotate must be consistent. We can consider making
the value use rotation but I'm not sure that's good. For
people that don't speak English it is more confusing.
The noun vs verb thing is nice, but consistency within
CSS is much more important principle.
dbaron: I'm okay with that.
<tantek> +1 to what fantasai said about preference of consistency
over grammar
fremy: Having a quick look, there's flex-direction,
text-decoration, font-variant-position...we have a lot
ending in -tion
Rossen: I think it's about consistency.
fremy: We have a lot that add in -tion
fantasai: We have rotate already. It's more important to be
consistent with those long existing properties then be
consistent with something with the same grammatical
ending.
fremy: Uh, if you say so.
<glazou> +1 with fantasai
Rossen: I'm also with you. I'd take consistency over repairing
past mistakes. Let's put this to a decision.
Rossen: Obj to rename offset-rotation to be offset-rotate?
<glazou> +1
<Bert> +1 to fantasai (offset-rotate)
<astearns> +1 with fantasai
<tantek> +1
RESOLVED: Rename offset-rotation to be offset-rotate
ACTION TabAtkins make sure that rename offset-rotation to be
offset-rotate isn't a problem for the Blink team
<trackbot> Created ACTION-803
Was the position of 'mask-mode' in the 'mask' shorthand intentional?
--------------------------------------------------------------------
dbaron: Basically the mask shorthand is defined so that mask-mode
has to be positioned right after mask-reference
dbaron: I feel like that was a typo rather than intentional where
we want the shorthand to mostly allow arbitrary
re-ordering except this thing. I believe Gecko impl as
though there's a || but no one can answer if this is
intentional.
Rossen: What is your proposed change?
dbaron: Add an or so that mask-mode can be anywhere in the
mask-shorthand other than between position and size.
Rossen: Do we have a Blink implementation on that one?
dbaron: I don't know.
dbaron: I think there's implementation of the mask shorthand, but
I don't know if there's mask-mode in it since it's newer.
Rossen: What about webkit?
Rossen: I don't hear anyone. Any other opinions on this?
Rossen: Objections?
RESOLVED: mask-mode can be anywhere in the mask-shorthand other
than between position and size
Add shorthands for alignment properties
---------------------------------------
<astearns> I vote for the value syntax using /
fantasai: I think the main issue is we resolved on place-* but
what do we do about two value keywords?
<fantasai> align-content: space-around start;
fantasai: I can write ^
fantasai: If you have place-content and have a space separator you
can't do that because it would be...
<fantasai> place-content: space-around start; align-content:
space-around; justify-content: start;
fantasai: Suggestion is to use / separator. Problem with that is
we're using the same syntax to represent alignment in
other places, such as scroll snap and
background-position and they don't use slashes.
fantasai: We could go back and change the other specs since
scroll-snap is newer and background doesn't have the
logical keywords so we could require it for the logical
keywords but that doesn't make sense because
background-position is part of the background short hand
that uses slashes. So in background-position we can't
use the / to separate the keywords.
fantasai: We have two options. 1) we use a / in the place
shorthand but not anywhere else which gives us an
inconsistency or 2) we say the shorthand can only take
one keywords values so if you want two values you have
to use the long hands and the short hand is space
separated.
fantasai: Is that clear?
fremy: Clear to me.
fantasai: So that's the decision. I'm inclined to go with space
separation for consistency with the other properties.
<tantek> I'm ok with 2
<tantek> to keep it simpler / more consistent with existing
properties for now
<tantek> and be ok with the restriction
fremy: Seems reasonable. So you can't do two keywords in the
shorthand?
fantasai: Only to do alignment value of single axis.
fremy: Can we make a function that would take two keywords?
fantasai: That's a possibility.
fremy: I think then you don't lose any expression and you don't
have to remember a space.
fremy: In the meantime I agree with you the best option is we use
space like everything else and we can consider this in the
future.
astearns: I think the future extension would have to be a
function. This is not simpler, you have to remember you
can only use single value keywords in the shorthand.
People will be confused when they try and use a keyword
that works in the longhand. Adding a function doesn't
solve that confusion, you have to remember something
else.
fantasai: You'd use the same syntax in shorthand and longhand. The
second value is a fallback. Space between if you have
multiple items you put space between, but what happens
if there's only one item? It's a fallback. We could
consider a different syntax. We're doing space and then
the other value. We could introduce lots of keywords or
introduce a function or something else.
astearns: I'm a little concerned about the precedent. The
precedent if we take is for any long hand that takes
values that's anything like background-position you
can't use a slash. We're limiting more things because we
didn't consider an ambiguous syntax with these. When we
have ambiguous syntax we add slashes. I think that's the
better precedent to follow.
<jensimmons> +1 to astearns
fremy: I won't disagree. In this case it seems like mostly it's a
fallback and in fallbacks we use a function.
astearns: Here it's using a function to get around the ambiguity
of the two value version.
astearns: I don't see the function being a simple fix. It add
complexity.
astearns: I'd rather in the cases we know there can be positional
ambiguity we use a slash. It preserves expressivity of a
shorthand.
fantasai: I think there will be cases where we expect no ambiguity
and we'll have it later. In this case we can predict it
because we thought of the feature early. THere will be a
lot of cases where we won't come up with it early on.
<tantek> can't we add the slash option later if actual author need
is demonstrated?
fantasai: We can add a slash later where two values is space and
four is slash (to tantek)
<tantek> I'm thinking this is a non-issue for authors
<tantek> (the additional functionality that would require slash)
<tantek> that is, not worth introducing new syntax for
<tantek> I'd rather defer adding slash option until a need is
demonstrated later
<tantek> since we *can* add it later
jensimmons: I think the slash will feel natural to people learning
grid and flexbox. I think most people don't know you
can have two values. I think it could be useful. Just
to toss it in from an author's perspective.
Rossen: I'm hearing some people, maybe most, in favor of slashes.
Rossen: I think fremy was arguing the other way. Do you feel
strongly?
fremy: I don't feel strongly. For me it's strange to add the slash
because when you use them in the short hand they'll be out
of place. It'll be weird but I don't care that much.
fantasai: One possible thing we can do in the future...we could
consider to add more of a gradient between so we
represent start as 0% and center as 50% so we can merge
background-position and alignment in that fashion. I
think that's a real possibility in the future and then
the discrepancy would be more confusing as they'll
overlap more.
fantasai: Something else to consider.
Rossen: Let's try for a resolution.
Rossen: Objections to adding the slash?
fantasai: I wouldn't object, but I have strong reservations
because of the things I've explained.
tantek: Would anyone object to deferring adding a slash?
tantek: We could ship without that. We don't need that
functionality. Authors don't care right now. We're adding
syntax for an edge case.
fantasai: I think it'll turn up but we don't need it right now.
jensimmons: I think limit this so you can't put two values in, I'd
be on board for that. If people learn about it let's
create a fallback of the longhands. I don't think it's
realistic to say we ship it one way and change. If we
don't ship the slash now let's resolve not to do it.
fantasai: Agreed on that point.
Rossen: So we can take out the slash?
Rossen: So then, tantek wants to resolve so we can ship.
jensimmons: The other debate was the order of things. Many people
in the WG who understand grid say align then justify.
A lot of authors say it feels more natural to be
justify/align.
fantasai: We had this debate TPAC a year ago. We have...I'll have
to look at the minutes but there's a set of problems
where if we do logical does block or inline come first
and we resolved on inline first. scroll snap and
background-position 4 does it that way. So place would
be consistent. We decided 2 value and 4 value should be
block and then inline so there's consistency.
fantasai: Physical values we have now does x and then y, but
margins and borders do y then x.
fantasai: We would have to have an inconsistency somewhere so we
resolved to say if you're using logical then the
coordinates will always be block and then inline so all
of grid is that way.
fantasai: If you look at grid placement property vs grid template
property. If you look at grid template the old system
would be x then y, but grid placement because they're 4
valued they would be y then x.
fantasai: So we wanted to make those consistent so 2 value vs 4
value has to be consistent and if we're doing it in grid
it should be in the other logical values. That let's
have margin and border be consistent.
jensimmons: Okay. Thanks for the background.
fantasai: Ideally we'd go back in time but we can't.
Rossen: We want to take a resolution here. Let's try and take one
to not add slashes. Objections?
<tantek> +1
RESOLVED: Don't add the slashes.
Rossen: Is there a second one?
<SteveZ> I thought that the resolution was that two values were
not allowed
<Rossen> SteveZ: this is the next one
fantasai: Ordering was resolved a year ago. I believe that's on
record.
<jensimmons> SO: this place-items: <'align-items'>
<'justify-items'> ;
<jensimmons> place-self: <'align-self'> <'justify-self'> ;
<jensimmons> place-content: <'align-content'> <'justify-content'>;
<jensimmons> or here (where it’s easier to read):
https://github.com/w3c/csswg-drafts/issues/595#issuecomment-262584268
fantasai: I think it would be wise given we want to ship to take a
cut of the alignment spec and just spec to have only
single value for each of the properties other then the
shorthand. So dropping fallback and safe/unsafe
alignment to give us more time.
fantasai: I'm not sure how impl feel but that would reduce the set
of new things.
<tantek> +1 to what fantasai said
<tantek> this seems conservatively prudent
fantasai: There has been some cross-consistency concerns and I
want to defer that entire set of topics by pushing to a
next level.
dbaron: Aren't some of those things shipping?
fantasai: I don't know.
dbaron: I think we're shipping safe|unsafe. I don't know on
fallback.
fantasai: That's a space around left, I think. Two values on
distribution. I think we recently resolved on
first-baseline and last-baseline. I'm just concerned
we'll want to change these or at least syntax.
tantek: They haven't been sufficiently incubated.
Rossen: So let's try and move forward instead of talk about
incubation.
fantasai: If implementors want to keep them in but I want to drop
as much as I can.
Rossen: It sounds like tantek wants to ship and he's also
supporting moving them out. We can resolve and you can
take an action to do it.
tantek: I can live either way. We are shipping it. I can't speak
to the certainty.
fantasai: We just discussed recently changing fallback.
Rossen: Sounds like the rest is stable.
tantek: Who else is shipping?
Rossen: We're not.
jensimmons: Sounds like there's no one from Chrome/Webkit here.
tantek: Does Edge like the design? DO you plan to ship?
Rossen: I can't comment.
tantek: That's fine.
<dbaron> I think we're shipping the whole ' <content-distribution>
|| [ <overflow-position>? && <content-position>' bit of
align-content and justify-content
Rossen: Let's get back to the proposal. And SteveZ pointed out we
were trying to resolve on if we allow two values for that
property.
Rossen: Sounds like if we move this the resolution can happen
later on.
<dbaron> We also wouldn't need to have this discussion if we
resolve to use / in the place-* shorthands...
Rossen: Do we have objections to moving this to the next level?
jensimmons: I'm a bit confused what we're talking about, but issue
595 on github we have consensus on everything on this
issue.
fantasai: We resolved on that.
fantasai: This is the align-content property there's two values.
I'm suggesting we reduce the long hand options to just
the single values. Just so we can have this. We may sort
this out, but to reduce the amount of stuff looking for
cases to switch the syntax or other concerns,
particularly with expressing them in shorthand.
fantasai: We're clear on baseline where first/last keyword has to
go first. Beyond that we need to check the syntaxes work
the way we want them to and work with the shorthand.
fantasai: That's my concern. I'm happy to defer. The stable things
I feel are single values on longhands.
dbaron: I feel like we're opening up a lot of issues because the
resolution we just took. If we reconsider the slash then
we don't have to open all these other things.
Rossen: That's reasonable as well.
Rossen: I want to close on this today and get to CSS 2.2. If we
don't resolve on moving this forward, fantasai what do you
feel will hold up the spec?
fantasai: In terms...assuming we go with these resolutions what
will hold the spec is I have to go through a bunch of
edits and we can publish next week. There's a handful of
stuff I think should drop. The legacy value in
justify-items that needs more work. The stuff I know is
stable is the single keyword values that are directly
analogous to flexbox. If we cut out the rest it will be
stable.
fantasai: There's problems with things that derive from combining
keywords. Syntactic and also this thing is not well
define.
fantasai: I don't think it'll take long to figure this out, but I
want to ship tomorrow I would recommend do the single
values.
Rossen: You'd recommend for not a single value?
fantasai: I would recommend to drop any features in css align that
require > 1 keyword in the longhand.
Rossen: Thanks.
fantasai: There's several features in that. safe|unsafe is
probably okay.
Rossen: If we set the spec it gives us more reasons to stall. I'd
rather not defer work to just defer work if we can in a
reasonable time frame think through those issues.
fantasai: Because there's a grid dependency I think the smartest
thing to do is...we've shipped a bunch of stuff in
flexbox and there's a lot that's directly analogous. We
can't change the syntax there the definitions are
straight forward. There's nothing to change. Those are
stable. As a let's ship now for grid that's a good
subset to pick. If we want something out tomorrow let's
cut down to that set.
fantasai: We know it works and we have impl experience with that
set.
Rossen: Let's put it to the group. Objections on resolving to move
all the features to level 4 in favor of shipping a stable
subset that's interoperable with flex and will allow grid
to be fairly interoperable?
dbaron: I'd like to have a better understanding of what's shipping
today.
fantasai: All the positional values, baseline and last baseline
with the resolution that changed them.
<fantasai> https://drafts.csswg.org/css-align/#positional-values
<fantasai> https://drafts.csswg.org/css-align/#baseline-values
section with last- replaced with [first|last]? per
previous resolution
<fantasai> https://drafts.csswg.org/css-align/#distribution-values
astearns: I think dbaron wants to know what's in the browsers.
fantasai: Oh. I don't know.
dbaron: I think we should know what's shipping, not just guess.
fantasai: We can discuss next week. I don't know.
Rossen: I don't know either.
jensimmons: That sounds right. To go find out and come back next
week and make a resolution.
Rossen: We're at the top of the hour anyway.
Rossen: We've been going back and forth for 14 minutes which
indicates we're not ready.
Rossen: I want to give the last minute to fantasai to list what's
remaining in level 3.
Rossen: You mentioned position and baseline?
fantasai: All properties would stay. position, alignment keyword,
baseline keywords with first/last prefix and distributed
alignment keywords. But no combination of those in
level 3.
<fantasai> Single-keyword values only, for longhands.
Rossen: We have this in the minutes. If we read this before next
week we can resolve on keep or move.
fantasai: And I'm happy to pull things in and ship level 4 in
February. In terms of what's set to go today it's the
single keyword stuff.
Rossen: Thanks everyone. Have a good rest of the day and talk to
you next week.
Received on Thursday, 24 November 2016 02:46:31 UTC