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

[CSSWG] Minutes Seattle F2F 2017-01-11 Part I: FX Breakout - Transforms, Whitespace in a custom property in a variable reference, Geometry Interfaces

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:18:42 -0500
Message-ID: <CADhPm3sLnkid9z8DnOxkU9q2mAeeTTkq5wAXMMog+Q18HyBADw@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.

FX Track


  - The references to 4x4 matrices will stay in L1.
  - There was agreement that transforms should apply to flex and
  - The spec will clarify that transform-origin's resolved value is used.
  - RESOLVED: add transform-origin-x/y/z to transforms levels 1 and
              (for z) 2, to address
  - Chrome just committed a patch which resolves the issue titled
      'transform-origin: 0% not equivalent to 0px is confusing'
  - RESOLVED: Add identity transform function to transforms level 2,
              interpolates with anything, to address
  - shane to add use counter to Chrome to collect frequency data on
      compatibility of change for
  - The group had three proposed resolution to the transforms
interpolation issue
      a. Run the transitions
      b. Define canonicalization and use the general available
         transform list and determine if to trigger a transition
      c. Similar to 2 but moves it to transitions
      - There was originally a leaning to get author feedback to
          decide between a and c, but it was discovered that
          browsers are interoperable on a.
      - Author feedback will still be sought in case there's
          overwhelming consensus that c would be the expected
  - RESOLVED: Resolve issue 38 on option A (run the transitions)
              from above.
  - RESOLVED: matrix() and matrix3d() should be the same primitive
              in https://drafts.csswg.org/css-transforms-1/#transform-primitives
  - RESOLVED: Perspective will interpolate to perspective, rather
              than to matrix, interpolated by the reciprocals of the
  - RESOLVED: Follow the spec and match FF which means perspective
              with a value of 0 is invalid.
  - RESOLVED: UAs must introduce near 0 clamping for perspective.

Whitespace in a custom property in a variable reference

  - TabAtkins will create an example in the custom props
      specification so that everyone is parsing out the whitespace
      in a custom property as defined by the syntax specification.

Geometry Interfaces

  - DomPointReadOnly will stay as-is for now.
  - smfr brought up a few questions/ideas around DOM Quads, but
      there wasn't time for a real discussion.


Agenda: https://wiki.csswg.org/planning/seattle-2017

  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  David Baron, Mozilla
  Bert Bos (W3C)
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Simon Fraser, Apple
  David Grogan, Google
  Koji Ishii, Google
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Simon Pieters, Opera Software
  Naina Raisinghani, Google
  Melanie Richards, Microsoft
  Hiroshi Sakakibara (BPS, Beyond Perspective Solutions)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Surma, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft
  Steve Zilles, Adobe

Note: The group split the morning of the 11 January on two
      tracks: FX and Text.

Scribe: dbaron

FX Track


  smfr: There was a decision in Lisbon to move 3d transforms to L2.
  smfr: I have changes to do this in a local branch on csswg-drafts.
  smfr: I can merge soon, maybe this week.
  smfr: Most of it is fairly straightforward. 1 or 2 issues a little
        more complex.

  smfr: There's some math referencing 4x4 matrices in the draft.
  smfr: Not sure to move all references to level 2 or leave them in
        level 1
  smfr: i.e., not sure whether to purge all 3d math from level 1.
  smfr: A little awkward for L2 to insert pieces into the prose
        every time there's pieces in matrix math.
  shane: Also maybe a consistency argument -- if referencing same
  smfr: So arguing to leave 4x4 matrices in l1.
  shane: Yes.

  smfr: Think the L1 draft is in pretty good shape, but L2 is a mess.
  smfr: Copying and pasting chunks into L2.
  Rossen: Link to repo?
  smfr: Haven't pushed it yet.
  smfr: Can I just go ahead and merge in?
  Rossen: Absolutely.
  Rossen: And we already have resolution from Lisbon.
  Rossen: Once you have L1 spec -- is it pretty much ready to go?
  Rossen: Belief was that L1 could go to CR-PR-REC quickly.
  smfr: Transform, transform-origin, SVG related stuff, 2d transform
        functions, stuff about interpolating matrices and mismatched
        function lists is still there, but without 3d functions, so
        think it's fairly uncontentious.

  Rossen: Any open issues?
  smfr: Some of this list will be 3d stuff... haven't looked at this
        issues list yet
  [projecting https://drafts.csswg.org/css-transforms-1/issues-wd-2013 ]
  Rossen: Do you need any WG time for any of these issues?

Application of transform to inlines

  smfr: One is #7, application of transforms to inlines
  dbaron: I think we support transforms on flex and grid.
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2014Feb/0382.html
  smfr: Is "atomic inline-level elements" enough?
  dbaron: We support on everything except non-atomic inline, ruby
          base container, ruby text container... and on tables we
          support on wrapper
  dbaron: and I think the other ruby stuff derives from inline.
  dbaron: My main concern is that the definition in the spec seems
          to say transforms don't apply to flex and grid
  dbaron: and I think they should.
  smfr: testcase in the issue is dubious.

  Rossen: Do we need a resolution?
  dbaron: We should also test table rows, etc.
  TabAtkins: Flex and grid count as "block-level", so I think this
             is probably right... though specs may not be hooked up
             exactly right.
  [fantasai's note: flex and grid items are not “block-level”]

  Follow-up in https://github.com/w3c/csswg-drafts/issues/908

  smfr: There are some SVG-related issues that I'm not sure we have
        the right people for (#10, #17).
  TabAtkins: and #18
  smfr: and #23
  smfr: and #25
  smfr: we can discuss #27 and #29
  Rossen: let's discuss #27

Specs disagree on whether transform-origin's resolved value is used
    or computed

  <dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-27
  <dbaron> https://github.com/w3c/csswg-drafts/issues/392#issuecomment-238494067
  TabAtkins: We're fine with it being used value; just a matter of
             lining up wording between om and transforms
  TabAtkins: with resolved value being used value.
  smfr: Why are there these special properties?
  TabAtkins: Originally in CSS2, because definition of computed
             value was different and we changed it in 2.1
  TabAtkins: and a handful of properties in newer specs are
             implemented with bad computed value behavior.
  dbaron: Although some value in getComputedStyle being consistent
          between properties.
  TabAtkins: Like grid-templates use used value.
  smfr: So this seems like it's more editorial rather than needing
  TabAtkins: Yeah, om should specify it can be extended.
  TabAtkins: OM's list of properties that use the used value as
             resolved value should be specified as extensible by
             other specs.
  zcorpan: Sure, everything should be extensible by other specs.
  ACTION zcorpan to edit CSSOM

Add transform-origin-x/y?

  <dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29
  TabAtkins: We don't see strong usecase for -x and -y but other
             position things have them
  TabAtkins: Already in webkit and blink.
  smfr: One implication of spec splitting is that transform-origin
        takes 2 arguments in level 1 but 3 in level 2.
  dbaron: Do webkit and blink implement transform-origin-z?
  smfr: I think so... let me check.
  shane & Tab: We implement -webkit-transform-origin-x/y/z
  smfr: Webkit has it unprefixed.

  RESOLVED: add transform-origin-x/y/z to transforms levels 1 and
            (for z) 2, to address

transform-origin: 0% not equivalent to 0px is confusing

  smfr: Issue 30... SVG one
  Rossen: https://github.com/w3c/csswg-drafts/issues/856 was called
          out in agenda
  gregwhitworth: Chrome just committed a patch to match spec, so
                 we're fine.
  gregwhitworth: It was about single-argument scale()
  smfr: Just the scale property, not the function.
  shans: Makes sense to extend with 1s rather than repeating because
         you don't want to extend the argument to 3d scale.
  shans: so better to extend to 2 1 1 than 2 2 1 (which is

  TabAtkins & smfr: Issue #33 is a 3d transform issue; definition of
                    SLERP ends up with 0 divisor in one case

Add null transform as placeholder for animations?

  <dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-36
  smfr: Issue #36
  TabAtkins: To make transforms easier to interpolate
  smfr: Spec already talks about neutral transform functions.
  shans: Talking about the problem of being somewhat difficult to
         match up transform lists when doing complicated animations.
  shans: From minutes of Paris F2F looks like we talked about 2
         ideas, but viable one was having null transform in the list.
  smfr: And UA would expand to identify with ...?
  shans: Wouldn't want to expand it, e.g., in a keyframe between 2
         others it might match different things on each side.
  smfr: The intent is to provide a way to avoid falling back to
        matrix interp when you have mismatched function lists. So
        author would insert 'null'?
  TabAtkins: Yes.
  smfr: It's an identity that matches the function type?
  shans: Pretty well defined -- if it only matches one function.
  [smfr on whiteboard:
      @keyframes {
          from { transform: rotate(10deg) scale(2) null }
          50% { transform: rotate(2deg) null translate(10px, 20px) }
          to { transform: null scale(1) translate(0, 0) }
  [smfr on whiteboard:
      @keyframes {
          from { transform: rotate(10deg) scale(2) id() }
          50% { transform: rotate(720deg) id() translate(10px, 20px) }
          to { transform: id() id() id() }
  smfr: Should we do in level 1? Not a behavior change for existing
        content, but a new feature.
  shans: I think it's fine in level 2, esp. now that we have a path
         to getting implementations of level 2 out.

  RESOLVED: Add identity transform function to transforms level 2,
            interpolates with anything, to address

Smarter interpolation of truncated transform lists

  smfr: May address 37 as well?
  TabAtkins: Helps with 37, but not...
  shans: Idea of 37 was... say you didn't have this translate():
  [shans on whiteboard:
      @keyframes {
          from { transform: rotate(10deg) scale(2) translate(10px) }
          50% { transform: rotate(720deg)
          to { transform: id() id() id()
  shans: Issue 37 is saying the 50% line should pad at end with
         identity transform in cases where first transform functions
  shans: This is just an extension of what happens with none.
  smfr: Slightly magical
  smfr: behavior change, a little worrisome.
  [ somebody mentioned something there about end-matching too ]

  shans: One approach we could take which wouldn't be a behavior
         change, but a little less useful, saying you have to put
         one id() at the end and then it would expand out.
  shans: If anything, it's more magical.
  Rossen: That's a lot more error prone.
  Rossen: If there's magic I'd rather keep it in the engine.
  smfr: But you'd be willing to live with behavior change?
  TabAtkins: Is the behavior change what people would have intended?
  shans: The behavior change is rarely going to be worse.
  smfr: People often ship things where they meant one thing, but not
        what they looked at or debugged...
  shans: A few years ago implementations often differed, but not
         sure if that's still the case.
  shans: Risk of behavior change would be how many pages it changes
         behavior on.

  [ some discussion about whether somebody wants to try the behavior
      change and see if it breaks things]

  ACTION shane to add use counter to Chrome to collect frequency
         data on compatibility of change for
  <trackbot> Created ACTION-93

Transform interpolation problem

  scribe: dbaron & gregwhitworth

  <dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-38
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2014Jul/0017.html
  [Tab explains issue]
  dbaron: I'm suspicious of the section on function equality stuff...
  TabAtkins: Still a level 1 issue with translateX() and
             translate(x, y)
  dbaron: I think this might be ok though before the edits, but
          might have been broken after the edits.
  <dbaron> not sure though.
  smfr: We probably need some concept of equivalence in transitions
        and animations.
  dbaron: Transforms are the hardest interpolation unit by far.

  TabAtkins: We do currently fire transitions for this case.
  smfr: Or we could just say it's too bad -- is it bad that you run
        a transition that doesn't have visual impact?
  dbaron: So there are cases where if you interrupt a transition
          midway, you mouse in and mouse out.
  dbaron: You want the interpolation result to use transform list
          interpolation with the endpoints.
  dbaron: I never suggested implementing these gecko because I
          thought this would cause these matrices interpolation
  <dbaron> (we're sort of moving into 39 -

  smfr: Options for #38 are either (a) run transitions anyway or (b)
        talk about equivalency.
  dbaron: One of the problems that you have with the interpolation
          rules is that you have 100% of A and 0% of B you'll have
          something that is not A.
  TabAtkins: I think we all serialize computed values to a matrix.
  smfr: We do too.
  Rossen: So do we.
  dbaron: matrix3d and perspective don't interpolate between one
          another so it causes all sorts of problems.
  dbaron: that's my belief that this edit was never fully finished.
  shans: I think there's also a third option which is to run
         interpolation as part of the transitions spec.
  shans: That would be option (c)

      1/a. Run the transitions
      2/b. Define canonicalization and use the general available
           transform list and determine if to trigger a transition
      3/c. Similar to 2 but moves it to transitions

  shans/dbaron: (c) is like (b) but piggybacking on the
                interpolation rules.
  shans: This would say that when you want to see whether to
         transition from A to B, you define A' as interpolate(A, B,
         0%) and B' as interpolate(A, B, 100%), and then compare A'
         and B' to see whether you run a transition.
  smfr: I have a concern about compat, because we've definitely see
        content break when we don't fire transition events.
  smfr: It wouldn't surprise me if people wrote content that tried
        to interpolate between translateX() and translate(x, y)
  shans: I know we've seen people frustrated about lack of
         transition events when they accidentally set the same value
  shans: And I could see this feeding into that.
  dbaron: Maybe ok to do (a), although I'm a little worried there
          might be reversing issues.
  shans: We could collect data on the frequency this happens.
  gregwhitworth: Is it worth the work to implement?
  shans?: [ (a) if nobody uses it because it's not worth doing, or
          also (a) because everybody uses it and a compat risk ]

  Rossen: What do you think Rachel?
  RachelNabors: I think I could go either way, but I'd prefer to
                reach out to authors for their opinion.

  scribe: gregwhitworth

  smfr: But people expect a transition if they change the value.
  dbaron: But it's already computed values rather than specified.
  TabAtkins: Yeah, it's worth sharing the color example as well (eg:
             red -> rgb(255,0,0)).
  shane: Color isn't going to change.
  TabAtkins: Talking to people just about this issue and transforms
             and then also showing them other areas where this also
             already occurs, would they want to change.
  smfr: It's primarily about the events, because you won't see
        anything on the screen - you'll only get an event or not.

  RachelNabors: Do we have any test cases?
  smfr: No, but we could make them easily.
  <smfr> RachelNabors: https://jsfiddle.net/ayn25zgj/ (feel free to
         clean up to not alert())

  Rossen: So if we had to pick one, it seems everyone likes c, but
          from implementation point of view - c is most worrying.
  shane: c and b is very similar in terms of risk.
  shane: To put it to a vote, you're voting against a or b/c
  Rossen: I think we can get rid of b, because it's the same risk
          but not as elegant.
  Rossen: If we have to do it today, option A or option B.
  RachelNabors: My gut is C, but I'd like to ask the community.
  Rossen: That would be a great data point.
  Rossen: From impl point of view, c is risky.

  shane: There all kind of people triggering on events.
  Rossen: What I was going to propose if we can get someone to
          experiment with it to determine how much risk is actually
  shane: Without manual inspection, you're not going to know if
         there was a behavior change.
  shane: We could figure out how many are firing off of these events
         but not if they will break.
  dbaron: What you could do, is add a tracker that is looking for
          when you wouldn't fire for option C
  dbaron: some of this isn't really interoperable
  dbaron: so - people may not be using this.

  [everyone looks at test, all browsers run the transition]
  shane: I don't think we should mess with this.
  Rossen: So, I don't disagree that we don't have good interop here
  Rossen: It would be a great data point.
  Rossen: We would then need to still consider it based on compat
  <shane> wait so Rossen does disagree that we do have good interop?
  <dbaron> I'm inclined to agree with shane that maybe we do need to
           stick with (a)

  Rossen: We can resolve on A today and then when we have more data
          we could change to take C
  shane: Okay
  shane: I don't want Rachel/Surma don't to do a bunch of wasted
  smfr: Another thing to consider with C is to think about filters.
  <RachelNabors> I'll also reach out to the popular animation
                 library authors and see if they're using A as a

  RESOLVED: Resolve issue 38 on option A from above

Interpolated values don't interpolate well with original start/end

  dbaron: Moving on to issue 39
  dbaron: It might be specific to 3d, it's an issue where we're not
  dbaron: We found out about it due to Gecko not doing what IE/
          Chrome did
  dbaron: I investigated it and we match the spec, but I don't think
          the spec makes some sense.
  dbaron: It was interpolating from things you can't mix.
  dbaron: In section 20 it says ".... reads spec...."
  <dbaron> The transform functions matrix(), matrix3d() and
           perspective() get converted into 4x4 matrices first and
           interpolated as defined in section Interpolation of
           Matrices afterwards.
  dbaron: That means when you interrupt the transition in the middle
          and reverse it you get matrix interpolation.
  smfr: I'm a bit confused.
  dbaron: Are you trying to read the spec? Of course you're confused.
  smfr: What I would expect is that you would end up with matrix3d
        blah to interpolate to matrix3d blah.
  TabAtkins: But matrix3d and perspective are not supposed to work
  dbaron: You could make them all use the same primitive.
  shane: ahhhh, but they don't.
  dbaron: You could do this by doing it on the interpolation lists.
  TabAtkins: Why is perspective special?
  dbaron: Maybe webkit and blink still do this.
  dbaron: Maybe dirk made these edits.
  smfr: I'm not sure why perspective doesn't just interpolate like
        everything else.

  dbaron: Going back to the primitive thing, I think that matrix and
          matrix3d should be the same primitive.
  TabAtkins: Yeah.
  Rossen: We could resolve on that.
  <dbaron> can we resolve that matrix() and matrix3d() should be the
           same primitive in
https://drafts.csswg.org/css-transforms-1/#transform-primitives ?
  shane: Maybe there is something with linearly interpolating the
  TabAtkins: The null value could be infinite.
  TabAtkins: If I recall there are actually problems with that in
             the spec.
  smfr: With this issue, we should see what interop is like, and
        define something that aligns with that.
  Rossen: dbaron said that there isn't good interop
  <dbaron> https://bug977311.bmoattachments.org/attachment.cgi?id=8382580
  dbaron: But it seems IE/Webkit do.
  dbaron: I don't think it's about the flip, I think the behavior is
          subtle - it's about whether it does multiple rotations,
          not that it just flips.
  shane: I think TabAtkins and I figured out why the way it is,
         because there is no null perspective, but now in level two
         we plan to have id() or null to do this
  [looking at testcase...]

  smfr: since this is a level two thing I think we can punt on this.
  dbaron: I would really like to get 3d interoperable though.
  shane: I think we should look at the math for the interpolation
         and then say perspective function does *this*.
  dbaron: One way is doing linear interpolation of the reciprocals.
  Rossen: So are we ok then punting on this for now?
  dbaron: Do we want to resolve on matrix and matrix3d should be
          equivalent primitives?
  shane: We don't get perspective until we get id()
  Rossen: With these two it will fix dbaron issue entirely.
  dbaron: Yeah I think that's fine.

  RESOLVED: matrix() and matrix3d() should be the same primitive in

  dbaron: We would need a resolution that perspective interpolates
          to a perspective rather than a matrix.
  smfr: [Explains how webkit does it]
  smfr: This probably why Dirk wrote the spec the way that he did.
  smfr: In that case - are you ok with that resolution that
        perspective interpolates to perspective.
  smfr: It's certainty true that we don't convert the perspective
        function to a matrix.
  RESOLVED: Perspective will interpolate to perspective, rather than
            to matrix, interpolated by the reciprocals of the



  TabAtkins: Can we deal with perspective(0)?
  TabAtkins: The perspective function is defined to expect a
             positive number.
  TabAtkins: It allows 0.
  TabAtkins: This allows a 0 divisor allowing infinite warping which
             is not good.
  TabAtkins: All UAs do perspective infinity which is the largest
             discontinuity in CSS.
  TabAtkins: There are also some odd NAN issues.
  TabAtkins: The standard way we deal with these types of exploding
             issues is we decide on a floor.
  TabAtkins: It would be nice to have a defined way.

  Rossen: The proposal is to have UA defined clamping near 0.
  jet: I think we already do that because we've had bugs similar to
  TabAtkins: So we should clamp the perspective length to close to 0
             rather than blowing up to infinity and then doing
  smfr: I think people expect perspective 0 should be like scale 0.
  TabAtkins: Maybe that's why it is the way it is, it's not
             mathematically incorrect and the transitions are
             stupid, and a few other things.
  TabAtkins: The perspective property doesn't allow you to
             transition for you to transition from none to something
  TabAtkins: So we could have 0 be like none
  <TabAtkins> 1. Spec what currently exists - 0 has inf behavior,
                 but interpolable.
  <TabAtkins> 2. Spec that perspective(0) == perspective(inf), but
                 not interpolable (like perspective:none doesn't
                 interpolate with numeric values).
  <TabAtkins> 3. Clamp the perspective value to a UA-defined >0

  [everyone begins building testcases]
  <smfr> https://jsfiddle.net/qs17okua/5/
  <gregwhitworth> https://jsfiddle.net/qs17okua/6/show/
  <smfr> https://jsfiddle.net/qs17okua/10/
  smfr: I think FF throws the perspective away if it's below a
  smfr: If we all change to perspective(0) what happens?
  TabAtkins: [discusses what he thinks FF is doing]

  smfr: So what do we do?
  Rossen: So if we clamp .05 down to 0 - this will get rid of the
  smfr: What do you do for perspective(0)?
  smfr: That doesn't solve the discontinuity issue.
  Rossen: thoughts?

  Rossen: Shane what would you all think?
  shane: I don't like the discontinuity but I don't think there is a
         better option.
  smfr: Have you seen this issue?
  TabAtkins: Even if they are, it's going to be a screwed up issue.

  Rossen: Let's say you're transitioning between 5 -> 0 [does
          interpretation of animation with hands]
  shane: If you transition that same thing, you'll be transition
         from 5 -> infinity
  <smfr> https://jsfiddle.net/qs17okua/11/
  shane: That behavior smfr we already do.

  TabAtkins: We're going to need to special case it.
  TabAtkins: Currently we all differ, so let's define a good
  Rossen: If we throw 0 away how do you transition.
  TabAtkins: Negative values are already not allowed.
  TabAtkins: My preferred option is still the clamping because we
             have a closed range.
  Rossen: When does FF actually clamp?
  TabAtkins: With actual 0.
  TabAtkins: You may hit it if you put in like 400 0s you'll hit
             their clamp.
  Rossen: So Tab's proposal is to introduce the clamping that is
          near 0 becomes none.
  smfr: When you say none, you mean the identity matrix.
  Rossen: Yes.
  TabAtkins: So we stop interpolating when it's none.
  smfr: So do we stop interpolating completely for others.
  TabAtkins: No, you can do a 50% flip.
  shane: That is a major change.
  smfr: We can do what FF does or what the other browsers do, it
        does have discontinuity but we haven't seen that issue in
        the wild.

  surma: If we don't treat 0 as infinity, is there anything bad with
  TabAtkins: I would rather add an inf keyword than keep that.
  shane: What we're saying is that FF is more correct, but we should
         match what other browsers do.

  Rossen: So, we've been spending a bit of time on this topic, let's
          close on it.
  Rossen: It doesn't sound like we're ready to resolve on it.
  jet: Our behavior is to not let it happen, there is one to clamp
  Rossen: There is one, but we'll probably reject that, but the one
          is you get the bizarro issue but it's one probably not hit
          in the wild.

  smfr: A couple of things, the spec says that anything below 0
        should be rejected - so FF is doing that. Maybe we should
        match FF.
  zcorpan: Even with calc?
  TabAtkins: Yeah, let's match FF - then define that there is a UA
             defined minimum.
  Rossen: Again, that makes in FF case it not interporable.
  TabAtkins: Only in the case that you don't have an end point to
             interpolate to.

  RESOLVED: Follow the spec and match FF which means perspective
            with a value of 0 is invalid.
  RESOLVED: UAs must introduce near 0 clamping for perspective.

Whitespace in a custom property in a variable reference

  <smfr> https://github.com/w3c/csswg-drafts/issues/881
  jet: [explains the issue, we should probably define this so that
        this works]
  TabAtkins: This should be defined at the syntax level.
  jet: Maybe something that prettifies it.
  surma: When does the whitespace actually matter.
  TabAtkins: Never.
  zcorpan: So if you were round-tripping in CSSOM and the
           serialization adds the space after the colon, for each
           round trip you'll get an extra space - correct?
  zcorpan: The current CSSOM spec adds in a space.
  shane: I would really like for us to adopt FF behaviour so that
         whatever you put in is what we get out.
  Rossen: I'm sympathetic with that as well.
  Rossen: So we just kept it.
  Rossen: I remember chatting with Tab on this and he wasn't too
          worried about this.
  Rossen: So would you be ok with this?

  TabAtkins: [reads out as a parser the text on the screen]
  Rossen: Do we need to make any change to this?
  shane: I'd like to make a note in the spec to make it clear.
  Rossen: Sure.
  TabAtkins: The syntax spec covers this.
  Rossen: Do not make changes to syntax spec but add an example and
          make sure implementors follow syntax.

  ACTION TabAtkins make an example in the custom props so everyone
         knows how to do this
  <trackbot> Created ACTION-94
  ACTION TabAtkins create an example in the custom props
         specification so that everyone is parsing out the
         whitespace in a custom property as defined by the syntax
  <trackbot> Created ACTION-95

Geometry Interfaces

  <smfr> https://www.w3.org/TR/geometry-1/#DOMPoint
  <smfr> https://www.w3.org/TR/geometry-1/#dom-dompoint-dompoint-point
  smfr: L1 of the geometry interfaces has an API that takes a
        dictionary and it's weird that it's not on DOMPoint ReadOnly.
  zcorpan: It hasn't been shipped in Chrome it's behind a flag.
  <zcorpan> https://bugzilla.mozilla.org/show_bug.cgi?id=1186265#c3
  smfr: I'm curious if the removal of this is web compatible.
  zcorpan: In httparchive I couldn't find any instances.
  <zcorpan> https://bugzilla.mozilla.org/show_bug.cgi?id=1186265#c3
  Rossen: The non read only version?
  zcorpan: The non-read only.
  zcorpan: It's not shipped in Edge nor Chrome.

  jet: Did you look for webkit-point?
  zcorpan: I don't think webkit takes a dictionary.
  smfr: I think this is useful for authors.
  zcorpan: There is from point?
  zcorpan: This can produce confusing results.
  zcorpan: Especially due to overloads, like DOMMatrix.
  zcorpan: This seemed like a saner design.
  smfr: I'm fine keeping this in the editors draft if this seems
        like the better future forward approach.
  zcorpan: And I think that with the web compat, we should try and
           ship the editors draft and see what happens.
  Rossen: Do we need a resolution?
  smfr: I don't think so.

  smfr: My second issue is with DOM Quads
  <smfr> https://drafts.fxtf.org/geometry/#DOMQuad
  smfr: I suspect I'm going to get shut down.
  smfr: It's written in such a way that authors can get a point in
        the dom quad
  <smfr> var quad = fromQuad(…..)
  <smfr> var p = quad.p1;
  <smfr> dosomething(p);
  <smfr> p.x = 100
  smfr: If dosomething() were to change that point, the rest of quad
        would be modified as well.
  smfr: A couple questions, DOMQuad doesn't have readonly versions.
  smfr: We could make the points more explicit by making the points
  surma: Currently DOMQuad are marked as readonly.
  smfr: Yes, but they return a mutable point.
  smfr: One proposal here would be to have the attr of DOMQuad not
        be readonly but the points of them readonly.
  zcorpan: So you can assign.
  smfr: Yes.
  TabAtkins: I still stand by this is how JS works, the larger
             object sees the mutation.
  surma: Inversely if we change it - people may be confused that
         they can't modify it.
  zcorpan: So if you want to pass on those points over to someone
           else you need to make a copy yourself.

  <break type=lunch><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Tuesday, 14 February 2017 01:19:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC