W3C home > Mailing lists > Public > www-style@w3.org > February 2018

[CSSWG] Minutes Telecon 2018-02-7 [css-typed-om] [css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 Feb 2018 21:26:24 -0500
Message-ID: <CADhPm3sJYn_PfSUgwNwtuf0ht3gdioU2y4jUJ=aEvtmjjSQ3vw@mail.gmail.com>
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)


  - 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)


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0006.html

  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

  Angelo Cano
  Tantek Çelik
  Chris Lilley
  Manuel Rego

Scribe: dael


  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

  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
  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
  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
  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

  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
  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
  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

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
  <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

  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
  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
  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

  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} ]? &&

  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
  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
  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
  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
  Rossen: Can we talk about MQ?

How do media queries with calc() where it can be resolved early
  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

This archive was generated by hypermail 2.3.1 : Thursday, 8 February 2018 02:27:20 UTC