- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Feb 2018 21:26:24 -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.
=========================================
Typed OM
--------
- RESOLVED: typed OM values are wrapped in calc and then serialized
as normal calc rules apply in invalid cases (Houdini
issue #574)
- RESOLVED: Attempting to set any 3d attribute on a 2d transform
will throw. (Houdini issue #610)
Transforms
----------
- RESOLVED: In the 2d case a single value is in both x and y and in
3d the z is always 1 (option b) (Issue #2109)
- RESOLVED: No change for issue #2126 with clarification notes from
the issue
- RESOLVED: Grammar is rotate: none | [ x | y | z | <number>{3} ]?
&& <angle> (Issue #2130)
- RESOLVED: Specifying just an angle gives 2d, specifying any axis
gives 3d (Issue #2130)
- RESOLVED: % values of translate are serialized as percent for
computed values. Add note making the behavior explicit
(Issue #2124)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0006.html
Present:
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Brian Birtles
Alex Critchfield
Elika Etemad
Simon Fraser
Dael Jackson
Peter Linss
Myles Maxfield
Lian Quin
Naina Raisinghani
Melanie Richards
Florian Rivoal
Darren Shen
Eric Willigers
Regrets:
Angelo Cano
Tantek Çelik
Chris Lilley
Manuel Rego
Scribe: dael
Announcements/Agenda
====================
Rossen: It's a couple minutes past. Let's get started.
Rossen: As usual, I wanted to call for any additional items or
things people want to change about the agenda.
fantasai: I have an announcement. W3C and Jefferson University
Interaction Department are collaborating on a redesign of
our templates.
fantasai: Students are doing it as a semester long project and
they're starting a blog where they're asking for feedback.
fantasai: We should help them along and try and get them feedback
early to help them.
fantasai: Goal is to make a prototype by May and then work toward a
deployment later.
<fantasai> https://sites.philau.edu/dillardl/
fantasai: Here's the website link ^
fantasai: W3C will send an announcement soon.
Rossen: That is cool. Thank you.
<fantasai> Project scope / requirements at
https://www.w3.org/wiki/SpecProd/Restyle
Rossen: Anything else?
Rossen: I have a quick one.
Rossen: It is to draw your attention to the email from Vlad about
the hotel in Berlin. They have a fairly reasonable rate. If
you were considering staying there you might want to book
now.
Rossen: Details are in a member list email
Typed OM
========
What does lack of range restriction imply about serialization?
--------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/574
TabAtkins: dbaron raised an issue we hadn't thought of. Typed OM
allows certain values to enter abstract CSS value space.
Specifically things that are invalid based on grammar.
Like a width can't be negative value. It's rejected at
parse time.
TabAtkins: In Typed OM we say you can construct a numeric value
that's negative and assign it to width and that's not
invalid. That has implications on how to serialize based
on old string based. getComputedStyle.width() what do you
get?
TabAtkins: I believe this is an issue for cssom to define, though
typed om caused it.
dbaron: It's more relevant to other serialization. Of specified
style not computed.
TabAtkins: Yeah.
TabAtkins: So if you set attribute style map width to negative and
ask for .style.width what do you get?
TabAtkins: I am weakly of the opinion we should serialize as calc,
but I don't have a strong opinion and can go with easiest
for impl.
xidorn: Can we do something like if we assign we wrap in a calc
directly?
TabAtkins: Very possible. You're saying we turn it into a calc in
css value space immediately so when you read it back out
you'd get a calc or a CSSMathSum with a -5px. Right?
xidorn: Yeah.
TabAtkins: That would also be fine with me.
Rossen: In your current impl do you do anything at all? In your
current version you'll serialize negative?
TabAtkins: I have no idea.
Rossen: I know you guys are ahead of impl.
TabAtkins: But not publicly available. I think we do -5px and it's
invalid but we're not attached to that.
Rossen: I was just wondering if someone did something close to what
xidorn suggested.
shend: I'm doing Blink and I think currently we might reject the
value, but I'm not sure. We have to check.
<TabAtkins> (That's Darren Shen, our Typed Om implementor.)
TabAtkins: That's violating another part of the spec that's more
explicit.
Rossen: Sounds like options are we wrap values in calc if they're
not already a calc and let calc work as does today.
Rossen: That sounds good to me. Doesn't require much custom code to
handle this and it will be fairly easy to understand and
teach to anyone that's used calc. I'd be good with that one.
TabAtkins: sgtm
Rossen: dbaron what do you think?
dbaron: I'm fine with it. Is the plan to do what xidorn described?
Rossen: Yeah.
TabAtkins: Alternate the notion that when you pull it out if it's
invalid at that point. it gets calc wrapped at that point.
dbaron: xidorn's eager thing sounds easier. Might be worth a note
asking for impl feedback.
TabAtkins: Sure.
Rossen: Seems like we're leaning toward spec as xidorn proposed
wrapping a calc.
Rossen: Other options or objections?
RESOLVED: typed OM values are wrapped in calc and then serialized as
normal calc rules apply in invalid cases
Does the is2D design allow for inconsistent interpretation of
CSSTransformComponents?
-------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/610
TabAtkins: The issue is that there's a lot of different ways we
could represent 2d vs 3d split in transform functions. We
settled on all are combined to a single form so expose
the same api.
TabAtkins: There additionally is a 2d boolean flag. It's set true or
false and set via constructor but you can set yourself.
TabAtkins: dbaron's complaint is you can still set the z value to
something. If the 2d is set it'll serialize and the z
axis does nothing. It seems weird, but we decided that's
the way to do it.
TabAtkins: Alternately we could blank out the values in 3d when you
set the bool to true and fill them with null-ish things.
<AmeliaBR> +1 for making is2D = true make the z/w columns and rows
force to the identity matrix values
TabAtkins: More extreme is to split into 2 interfaces, but we didn't
want that because you can't write generic transform code.
TabAtkins: Question is, is the current design choice where z value
is ignored but can be set fine or should we go for a
different design where we replace z with a null and
ignore sets.
dbaron: I'd add one options is ignore set and the other is throw.
TabAtkins: Yes, sure. I had put them together because they're
similar in my mind.
Rossen: Is there impl experience in this area?
shend: Yes.
Rossen: Other opinions on this?
<AmeliaBR> +1 specifically for the ignore option; consistent with
how bad values are treated in most of the rest of CSS
dbaron: I don't know if my opinion was clear, but I'm not happy with
what's in the spec. I prefer ignore or throw with a slight
preference for throw. I think AmeliaBR said on IRC she
prefers ignore.
dbaron: I think throw because it's a bit more like if you have an
object that's just the 2d thing, but really you'd set an
expando property so maybe ignore is the right analog.
TabAtkins: I wouldn't treat js syntax as being necessarily
informative here. We throw eagerly in other places in the
OM when something is wrong.
Rossen: I think throwing would be a little easier to surface up to
devs and tools. It would give a little more ability for
those trying to use typed OM to fix their code. So I think
I'm with dbaron to prefer throwing or at least throw by spec
it throws. If it's a pain point we can fall back to ignore.
TabAtkins: I'm fine with that.
smfr: Would you throw when you assign any values to z or any that
makes it 3d?
TabAtkins: Any value because any value makes it 3d when it's 3d. A 0
value in 3d doesn't make it not 3d.
smfr: So the 2d rep it will serialize as 2d transform.
TabAtkins: Yes.
smfr: I could go throw or ignore.
TabAtkins: I'm fine with throw.
Rossen: Objections on throwing in cases when z index is spec on 2d
transforms?
TabAtkins: When you try and set any 3d related attribute of a
transform set in 2d.
smfr: Will you annotate 3d attr somehow?
TabAtkins: Yes.
TabAtkins: I'll have explicit setters for those attributes.
RESOLVED: Attempting to set any 3d attribute on a 2d transform will
throw.
CSS Transforms
==============
`scale` property behavior differs from `scale()` function
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2109
birtles: The summary is that the scale property takes 1 2 or 3
numbers. Question is what it should do when you spec 1
number. We have 4 possibilities.
<TabAtkins> scale:2, what does it expand to?
<TabAtkins> (a) scale: 2 1 1;
<TabAtkins> (b) scale: 2 2 1
<TabAtkins> (c) scale: 2 2 2;
<TabAtkins> (d) scale: 2 2, but add scale-3d:2 that expands into
scale-3d:2 2 2;
birtles: One is the remaining numbers become 1. That's current spec.
Very simple from syntax and consistent if doing 2d or 3d.
birtles: Disadvantage is it's inconsistent with scale from transform
property where if you only do 1 number scales in x or y and
it's quite unintuitive.
birtles: 2nd is to make the second value match the first and last
value be 1 so you don't scale in z. More complex for syntax
and inconsistent between 2d and 3d.
birtles: But I think it's intuitive in 2d case which is most common.
birtles: 3rd which we dismissed is make all numbers the same so
scale: 2 is scaling in x, y, and z
birtles: 4th is to make scale property only take 2 values and
possible introduce a scale 3d property.
birtles: I lean options 2 but 4 might be interesting.
Rossen: Can you expand on why #3 was ruled out? What was it
introducing in 3d. If you set scale in a single value that's
in all 3 dimensions.
birtles: In most impl as soon as there's a 3d component it makes it
an active layer. Changeable, but non-trivial.
TabAtkins: Other 2 transform properties follow principle that if you
spec less you get 2d and more you get 3d. Would be
confusing if scale worked differently.
dbaron: What about option of disallowing a single but allowing 2 or
3 values and determining 2d and 3d based on number of values.
TabAtkins: Reasonable option.
birtles: Reasonable but a little less then intuitive but also not
consistent with scale function so authors may assume it
will work.
fremy: When we started implementing in edge I found it confusing
that when you spec 1 value it only scales in 1 direction.
Seems reasonable to scale in 2 directions when specify one
value. I'm not sure why we care about 3d for these individual
transforms. I'm at a loss why we'd do 3d for these. Anyone
doing 3d will use transform not scale.
fremy: I'm in favor of matching scale.
TabAtkins: I strongly disagree where order is very important in 2d
as well as 3d. So you have to think about order no matter
what. 3d version is no less...the order is no less max
intuitive for 3d. It's still roughly the thing you want
to do if you're using them separate.
TabAtkins: It makes just as much sense in 2d or 3d and order matters
just as much so no reason to shut off 3d.
eric: I'm in favor of birtles suggestion.
* TabAtkins is really liking either (b) or David's option to make it
more explicit.
* smfr votes for (b)
* liam +1 to (b)
AmeliaBR: I agree with TabAtkins that we shouldn't turn off 3d.
Anyone working in 3d is working in all 3 values and if you
want to scale in 3 directions you have to say so
explicitly. Doesn't seem like a pain-point. Default
should be simpler 2d where scale: 2 means scale in both 2d
directions
<alex_antennahouse> +1 (b)
smfr: Can we resolve on b? anyone not like b?
Rossen: B is in the 2d case a single value is in both x and y and in
3d the z is always 1. Correct?
smfr: Yes.
Rossen: Any objections or opinions again?
RESOLVED: In the 2d case a single value is in both x and y and in 3d
the z is always 1 (option b)
Please remove from drafts: scale, translate, rotate CSS style etc.
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2126
ericwilligers: They are valuable. They have the full motion path and
can be independently animated.
ericwilligers: I think libraries will find it useful.
TabAtkins: They also let us capture the generally most intuitive
ordering without making authors remember it. translate
then scale then rotate
AmeliaBR: They're useful for [missed]
AmeliaBR: They're useful for animations, you can animate one factor.
And they're useful for different transformations assigned
with different classes or pseudo classes.
<TabAtkins> +1 to all that AmeliaBR is saying.
ericwilligers: There's an issue about preserve 3d from fremy but I
think that's a different issue.
fremy: Feel free to disregard mine.
ericwilligers: Can we resolve to keep properties?
Rossen: fremy you said you have your point in the issue...disregard
it? Is that what you wanted?
fremy: I agree it's a different issue and shouldn't be in that topic.
<birtles> The very popular GreenSock Animation (GSAP) also takes
this approach of a fixed order of transform components and
promotes it as one of its key usability benefits over CSS (
although it further breaks these components into x/y/z too)
smfr: I don't think anybody on this call agrees with the issue. I
think we're all okay with separate properties.
<fantasai> +1 to smfr
AmeliaBR: I did have a couple comments in there suggesting
clarifications in the spec.
Rossen: Does anyone support the issue to remove?
Rossen: Objections to resolve no change?
fantasai: No change add clarifying notes.
Rossen: Are the notes in the issue?
fantasai: Yes.
Rossen: Objections to no change with clarification notes from the
issue?
RESOLVED: No change with clarification notes from the issue
Named rotation axis
-------------------
github: https://github.com/w3c/csswg-drafts/issues/2130
ericwilligers: Current spec and suggestions:
<ericwilligers> Current spec: rotate: none | <number>{3}? <angle>
<ericwilligers> Suggestion by Amelia: rotate: none | [ 2d | x | y |
z | <number>{3} ]? && <angle>
<ericwilligers> Suggestion by Eric in #1269: none | <angle> &&
[ axis(<number>{3}) ]?
AmeliaBR: For most people the vector notation is more complicated
and all the shorthands have rotate-x,y,z. We do have
discussion in the issue my suggested keyword of 2d doesn't
parse as a keyword which is an issue.
AmeliaBR: Reason we have a separate keyword is we need to
distinguish between 2d and 3d transforms around z axis
which is simple math, but different in impl
ericwilligers: The difference could be if you spec the axes.
AmeliaBR: Yeah, that was one suggestion. We don't worry about a
keyword for 2d and if you don't spec axis it's 2d.
<fantasai> +1 to Amelia's suggestion
TabAtkins: I hadn't thought about the rotate functions having
rotateX,rotateY,rotateZ and I support allowing you to set
those instead of remembering the correct set up.
<TabAtkins> rotate: <angle> && [ x | y | z | <number>{3} ]?
AmeliaBR: Question is if we have those keywords is the unwrapped 3
numbers still acceptable or do people like function
notation?
fantasai: I'm opposed to function since we haven't used it in
similar situations like backgrounds. If we want longhands
at some point that makes it more difficult. Syntax as is
is fine. I don't know why people would want angle in the
middle.
TabAtkins: And rotate 3d takes an angle and 3 numbers so it's the
same syntax.
Rossen: We have a couple of people opposed to functional notation.
Rossen: Does that mean we want to go with first proposal?
<ericwilligers> rotate: none | <angle> && [ x | y | z | <number>{3}
]?
<AmeliaBR> rotate: none | [ x | y | z | <number>{3} ]? && <angle>
ericwilligers: You can use x y z, have 3 numbers, or leave them out.
And angle before or after axes.
TabAtkins: Yeah. I'm not sure why grammar has 3 numbers before, but
that was probably an accident.
smfr: Are unitless 0s allowed for the angle?
ericwilligers: Not allowed.
TabAtkins: Right. They're legacy feature you have to opt into and we
don't allow in new.
AmeliaBR: Final question. Even though we're allowing both to spec in
either order, do we want to stick with angle and then axis
to match transform?
dbaron: I think in rotate 3d the angle is at end.
TabAtkins: Oh. I think the order in the grammar matches order
serialized so we should have axis first to match rotate
3d.
Rossen: Current proposal is match rotate 3d syntax?
<AmeliaBR> https://drafts.csswg.org/css-transforms-2/#funcdef-rotate3d
TabAtkins: No. We should have the axis come first.
AmeliaBR: It's this one rotate: none | [ x | y | z | <number>{3} ]?
&& <angle>
AmeliaBR: ... for the serialization order
Rossen: Any objections?
* fantasai is confused
Rossen: fantasai you're confused.
fantasai: We're deciding to not match transform ordering?
TabAtkins: The rotate3d() takes axis first.
fantasai: Okay, sure. As long as trying to match.
<ericwilligers> We can close https://github.com/w3c/csswg-drafts/issues/1269
ericwilligers: I think we can also close this issue ^
RESOLVED: Grammar is rotate: none | [ x | y | z | <number>{3} ]? &&
<angle>
smfr: Which combo of axis numbers trigger 3d behavior?
TabAtkins: All
AmeliaBR: Any axis triggers 3d
smfr: Okay.
TabAtkins: If you do just an angle it's 2d.
smfr: That's fine as long as it's in the spec.
RESOLVED: Specifying just an angle gives 2d, specifying any axis
gives 3d
Serialization of the computed value of `translate` property
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2124
TabAtkins: It's if translate 50% serialized to pixel or percent. It
depends on layout information. Has to stay as a percent
right?
AmeliaBR: Because percentages are resolved against transform box
which are usually width and height of css box and is more
complex for svg
Rossen: I'm in favor to keep them as percent so we don't rely on
layout.
TabAtkins: And this is by default in the spec [reads]
Rossen: So it's editorial making it explicit?
TabAtkins: At best we could match what translate function says. No
need to do anything different.
AmeliaBR: It's for impl
ericwilligers: Perhaps it was Blink making it absolute for lack of
works?
birtles: The FF impl wanted to align with chromium but I said spec
said % so I wanted to clarify.
ericwilligers: I think we'd got a wpt that says % so we have to fix
blink and edge.
Rossen: % is easier, less work. I'm willing to make that change.
Rossen: Is blink okay?
smfr: Yeah.
Rossen: Webkit?
ericwilligers: I don't think they impl the property.
Rossen: Objections?
RESOLVED: % values of translate are serialized as percent for
computed values. Add note making the behavior explicit.
Media Queries
=============
Rossen: 2 minutes left. Anyone in APAC hae something that fits in 2
minutes?
Rossen: Can we talk about MQ?
How do media queries with calc() where it can be resolved early
serialize?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1968
florian: Had a resolution a while back. Turns out impl of MQ do
remove the calc when possible. Conflict between what we
said and what we're actually doing.
florian: No opinion on how we could and how we're doing it, there's
a mismatch, though.
Rossen: Is this a case of implementations catching up?
florian: I don't think so. It was not considering enough details
when we resolved. We may want to maintain resolution but
that's more changes. Maybe some people realized all the
changes, but some were caught off guard.
Rossen: People are starting to fall off, so let's push to next week.
It's on people's radar.
Rossen: If you want to book F2F hotel do so. Thank you all for
calling in we'll talk next Wednesday at usual time.
Received on Thursday, 8 February 2018 02:27:19 UTC