[CSSWG] Minutes TPAC F2F 2013-11-12 Tues III: Filter Effects, CSS Transforms, Geometry API Spec

Filter Effects
--------------

  - RESOLVED: CSS/SVG agree to publish a new WD of Filter Effects

CSS Transforms
--------------

  - RESOLVED: We will publish a new WD of CSS Transforms.

Geometry API Spec
-----------------

  - The group discussed if SVGPoint.matrixTransform should be retained
         and it was decided to get a better sense of how much it's used
         before making the remove/retain decision.
  - They also investigated ways of creating intersections between
         shapes.
  - A question was raised about if rect should be mutable or unmutable.
         Krit requested that this issue (and others) be raised on
         public-script-coord.

=====FULL MINUTES BELOW======

Filter Effects
--------------
  ScribeNick: heycam

 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#security
  krit: Last time we talked about having a security issues section.
  krit: Roc had some concerns about the security model we had,
  krit: He asked me to write it.
  krit: This is not just for custom filters,
  krit: But also some other issues, such as element() function.

  krit: SVG filters have an issue where you can get certain data about
        the pixels that you filter.
  krit: That leds to timing attacks,
  krit: With normal SVG filter functions
  krit: feDisplacementMap you can cause different timing behaviors
        depending on pixel values you get.
  krit: We came up with that we taint certain filter primitives that
        have references to user data.
  krit: With feImage, all of the filter sources like SourceGraphic,
  krit: All of these primitives that take pixel color that can be
        affected by the color property are tainted.
  krit: Once feDisplacementMap takes such an input, it is tainted.

  krit: Some people already reviewed this section, some people at Google
        and Mozilla.
  krit: Roc and heycam kind of looked at it,
  krit: Steven White from Google.
  krit: I think the security section as it is now is OK, but I would
        like wider review, so I'd like to publish a new WD.
  krit: Do both WGs support publishing a new WD?
  ed: Any objections to publishing a new WD?
  [none]

  RESOLVED: CSS/SVG agree to publish a new WD of Filter Effects

  ed: Can we limit this to tainting only when use use the color
         property, or does it have to be for elements in any case?
  krit: It's not easy to determine where you get the color from,
  krit: So I'd rather be more restrictive.
  krit: There are some issues in the spec, SVG specific -- we can
        discuss them in the SVG WG meeting.

CSS Transforms
--------------

  krit: For CSS Transforms, the one thing missing is the property
        definitions.
  krit: We did not specify what the value of these properties means.
  krit: This is now in the Transforms spec.
  krit: A lot of things were clarified, e.g. with transform-origin and
        perspective.
  krit: There are still some open issues, especially with 3D transforms.
  <ed> http://dev.w3.org/csswg/css-transforms/
  krit: smfr is reviewing some of my tests.
  krit: I would like to write more tests, and discuss them in January.

  krit: Also new in the spec is a new decomposing model for matrices.
  krit: dbaron found that matrix decomposing works differently between
        Safari and other browsers.
  krit: dino took an action to review the source code, and I've added
        the decomposing code to the spec.
  krit: Again I would like wider review of these things, so I would like
        a new WD of CSS Transforms
  ed: any objections to publishing a WD?
  [None]

  RESOLVED: We will publish a new WD of CSS Transforms.

Geometry API spec
-----------------

  <astearns> https://dvcs.w3.org/hg/FXTF/raw-file/tip/geometry/Overview.html
  krit: Simon Pieters added new types to the CSSOM View specs,
  krit: DOMPoint, DOMRect, DOMQuad and DOMRectList,
  krit: All these interfaces are now joined with DOMMatrix into the one
        spec.
  krit: If you look at the interfaces, you see them there in the draft.
  krit: We're not asking for FPWD at this point,
  krit: What I'd like to discuss or mention is the model of the
        interface structure.
  krit: We had long discussions about r/o interfaces, and ones which are
        r/w.
  krit: We had concerns on the mailing list about having interfaces that
        are sometimes readable, sometimes not.
  krit: The general agreement was not to have these kinds of interfaces
        in the future.
  krit: There was a need for DOMRect etc. to have read-only APIs for SVG
        DOM, and some CSSOM View APIs,
  krit: But we want to have them writable so you can do something useful
        with them.
  krit: There were different solutions on the mailing list.
  krit: None were really sufficient.

  krit: The one that was accepted was having a readable interface as a
        base interface, and a writable one inheriting from that.
  krit: Initially we called the parent interface DOM*ReadOnly, which is
        confusing.
  krit: Doing 'instanceof DOMRectReadOnly' would return true even for a
        writable DOMRect.
  krit: We discussed this in Web Apps WG yesterday, and we at least
        agreed that the inheritance structure is the best of the
        proposals we have so far.
  krit: I have some concerns about using "View" name.
  krit: Other than that, most people agreed on the naming scheme.
  krit: So this is what will be in the spec.

  krit: I'd also like to discuss some issues.
  krit: The first is with SVGPoint.
  krit: We mentioned before DOMRect, DOMRectList (which is needed in
        CSSOM View)
  zcorpan: CSSOM View references the Geometry spec for DOMRectList.
  krit: SVG has the SVGPoint interface which we'd like to replace with
        DOMPoint.
  krit: We also have an SVGPointList.
  krit: Compared to DOMRect, do we also want a DOMPoint list?
  krit: Or do we just recreate SVGPointList and keep that SVG-specific
        for now?

  <TabAtkins> zcorpan_: Yo, several of your IDL interface defs are
              linking back to CSSOM, which just says that they're
              defined in Geometry. To force Bikeshed to mark something
              up as a definition, add dfn-force='' to the <pre>.
  <TabAtkins> Like <pre class=idl dfn-force="DOMPoint DOMPointInit">
              ...</pre>
  <TabAtkins> Is DOMRectList actually needed, or is it just used in the
              existing IDL and we're keeping it?
  <TabAtkins> We should try to migrate it to an Array if possible.

  doug: Is there any evidence that people are using the SVGPointList
        interface in the wild?
  krit: No.
  krit: Well, that's not fully true.
  krit: There are libraries using the SVG DOM interfaces,
  krit: Snap SVG for example.
  krit: He's at least using SVG DOM. I'm not sure if he's using
        SVGPointList.
  doug: Could somebody at Adobe look into that?
  doug: I personally think we should de-SVG all the things.
  doug: I think we should do what makes more sense for long term, not
        for backwards compat with SVG.
  zcorpan: In general, when adding new list-y things, we try to use a JS
           Array.
  zcorpan: Which can be represented in several ways in WebIDL now.

  <slightlyoff> Why the hell aren't any of these things constructible?
  <slightlyoff> And why aren't they just JS arrays?
  <heycam> slightlyoff: It's our plan to.
  <heycam> slightlyoff: See also my SVG DOM improvement proposal.
  <slightlyoff> heycam`: Ok, that's good, 'cause this is depressing:
            http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGPointList
  <TabAtkins> slightlyoff: Don't want Points/etc to be just arrays. The
              Lists, yes, that's what I (and now zcorpan) just said.
  <astearns> No instances of SVGPointList in snap source
  <heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/
  <slightlyoff> TabAtkins: Yes, was referring to the lists.
  <slightlyoff> It'd be much better if there were an svg.* object
                instead of all of the SVG* prefixing = \
  <TabAtkins> slightlyoff: SVG.*. Uppercase for great justice! (And
              better author-collision avoidance.)
  <slightlyoff> TabAtkins: !?!!!?
  <slightlyoff> TabAtkins: Seriously...that's O_o
  <dbaron> So what happened regarding the third (immutable) rect type in
http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0045.html ?
  <TabAtkins> Um.
  <dbaron> Did that get dropped?
  <TabAtkins> We always uppercase interfaces.
  <slightlyoff> TabAtkins: I mean, eventually you'll want this this
stuff to be an ES6 module, right?
  <TabAtkins> Sure, yeah.
  <slightlyoff> TabAtkins: fine for the interfaces, but putting the
                interfaces in a single object instead of in the global.
  <TabAtkins> A namespacing interace is just a shitty module.
  <slightlyoff> TabAtkins: that was the "." in my "svg.*"
  <TabAtkins> ...I know.
  <TabAtkins> We already have window.CSS for the same thing.
  <slightlyoff> TabAtkins: beats the dihereah ya'll have going on here
  <TabAtkins> l2spell ^_^

  krit: Is SVGPointList already compatible with the new ideas in Web
        IDL?
  heycam: I didn't change anything with SVGPointList apart from adding
          indexed properties and length property,
  heycam: Which implementations already support.
  krit: So I think we should not create a new DOMPointList interface.
  doug: We should do whatever is best for the longer m, and not feel
        constrained by the previous specs,
  doug: Since SVGPointList is not really used.
  heycam: That depends on what we do with the grand SVG DOM rethinking.

  krit: I would like to remove the issue about clarifying whether
        DOMPointList is needed or not,
  krit: Because I think it's not.
  heycam: I agree.
  <TabAtkins> +1

  RESOLVED: Don't create a new DOMPointList; try to use Arrays if we
            need something like that.

  krit: Second I'd like to discuss is SVGPoint has a function,
        matrixTransform
  krit: We should we have that on DOMPoint.
  krit: You can pass a DOMMatrix into it, and it will transform the
        coordinates of the point and return a new one.

  zcorpan: Isn't that covered by the new Geometry stuff in CSS OM View?
  zcorpan: Oh, it's not the same - was thinking of convertPointFromNode.

  <TabAtkins> http://dev.w3.org/csswg/cssom-view
  krit: The Matrix that is already shipping in Safari/Blink/IE,
        prefixed, has a function transformPoint.
  krit: It's on DOMMatrix.
  krit: SVG put this function on SVGPoint,
  krit: It would be duplication to have in both places.

  krit: The question is should we have it for SVG, or can we live with
        removing it?
  ed: My guess is content would break if we remove it.
  dino: I think we should leave it off,
  dino: DOMPoint doesn't have any methods currently.
  ed: How do you suggest to resolve the SVGPoint issue? Not care about
      it?
  dino: Yeah.
  zcorpan: It might make sense to check how much the function is used in
           the wild.
  zcorpan: If it's used quite a bit, we might need to retain it as a
           quirk.
  zcorpan: Otherwise we should remove it.
  krit: How do we get this data?
  zcorpan: We could add in a use counter to blink,
  zcorpan: Or research content or something.

  <slightlyoff> why are all of these things marked readonly?
  <slightlyoff> http://dev.w3.org/fxtf/geometry/#DOMPoint

  dino: There are plenty of ways this API could break.
  krit: With the exception of this function, content would not break.
  krit: I would be fine with keeping this issue open while we're waiting
        for better data.
  krit: We could ask Blink people to check.

  ACTION: Erik to add a use counter for SVGPoint.matrixTransform
  <trackbot> Error finding 'Erik'. You can review and register nicknames
             at <http://www.w3.org/Style/CSS/Tracker/users>.
  * RRSAgent records action 3

  dino: D3 uses Point.matrixTransform

  <slightlyoff> again, why is all of this stuff readonly?
  * ed created https://www.w3.org/Graphics/SVG/WG/track/actions/3534 for
       the matrixTransform issue.
  <TabAtkins> slightlyoff: It's not readonly. There are readonly
              *variants* of the interfaces, for various uses in APIs.
  <TabAtkins> But they all have mutable versions too.
  <slightlyoff> TabAtkins: where are those?
  <TabAtkins> Right there, in the spec next to the other ones?
  <slightlyoff> TabAtkins: not seeing mutable version here:
                http://dev.w3.org/fxtf/geometry/#DOMPoint
  <slightlyoff> oooh...I see
  <TabAtkins> slightlyoff: The DOMPoint interface is mutable.

  <slightlyoff> What's the reason to have the readonly version at all?
  <TabAtkins> Because you need readonlys for APIs at various times.
              Plenty of times you're exposing a point on some interface,
              and it's not meant to be mutable, or mutating it won't do
              anything.
  <TabAtkins> In other words, same reason to have the "readonly" keyword
              in any situation?
  <TabAtkins> Hanging mutable-but-useless attributes off an interfaces
              is a bad idea. Should either be readonly, or should be a
              method that returns an object, or should be mutable and
              live. Pick one.
  <TabAtkins> (Apparently the last one is usually bad.)
  <slightlyoff> TabAtkins: I'm really unsure why "mutating it wouldn't
                do anything" is anything other than "it wasn't defiend
                with an accessor pair, so c'est la vie"
  <slightlyoff> TabAtkins: the idea that you should be locking things
                down is just odd
  <TabAtkins> slightlyoff: What happens when you mutate a point on a
              DOMRect? It magically becomes a DOMQuad? It just starts
              wildly violating rect-based assumptions?
  <TabAtkins> DOMRect has a mutation API - mutate x/y/width/height.
  <slightlyoff> TabAtkins: it's JavaScript? You document your
                assumptions.
  <TabAtkins> And your assumptions might be "this isn't how you mutate
              the object, it's just some useful info you can use.
              Accordingly, we're documenting it as readonly."
  <TabAtkins> I'm okay with accepting the looser SVG syntax, I think.
  <slightlyoff> TabAtkins: I'm really just unsure what the case for this
                is aside from pre-emptive invariant preservation
  <slightlyoff> TabAtkins: most JS objects are mutable and the world is
                not, yet, on fire.
  <TabAtkins> slightlyoff: Again, it's identical to making literally
              anything else readonly. If you'd expose "readonly
              attribute double x; readonly attribute double y;", you can
              instead just expose "readonly attribute DOMPointReadonly;"
  <slightlyoff> TabAtkins: that's not a case for *if* it's something you
                should do, which is what I'm questioning.
  <TabAtkins> slightlyoff: Had this dicussion on the list before. Live
              objects are discouraged API design (prefer mutating
              methods). If an object isn't live, it probably shouldn't
              be mutable either - better author affordance.
  <slightlyoff> TabAtkins: this is alien to most JS practice
  <TabAtkins> Otherwise, you mutate something, nothing happens, but now
              the attribute is lying.
  <slightlyoff> TabAtkins: so whatever you might prefer from some other
                perspective, it's just not something I think these WGs
                should be worrying too much about
  <TabAtkins> Sure, because readonly isn't easy to do in JS. Gotta screw
              around with getters.
  <TabAtkins> Part of having an interface description language is being
              able to abstract some of the difficulties of the
              underlying implementation language, when it's useful to do
              so.
  <slightlyoff> TabAtkins: that doesn't make this design any less alien
  <slightlyoff> TabAtkins: also, you don't need that, you only need a
                 property descriptor
  <TabAtkins> slightlyoff: Property descriptors are at least as fiddly
              as getters. ^_^
  <TabAtkins> slightlyoff: I don't think cleaving hard to the particular
              syntax affordances of JS is particularly important.

  doug: One thing I wanted from a Geometry API for 13 years is the
        ability to get intersections between shapes.
  doug: Have you put any thought into that?
  krit: No.
  doug: Please do.
  krit: I would like the community group to come up with some proposals.
  doug: Intersections are useful for a bunch of things.
  zcorpan: I would like to see use cases.
  doug: There is a script library out there that kind of does
        intersections.
  doug: It's by kevin lindsey.
  doug: I talked with him about that; he said many of the pieces are
        hacky and hard to do in JS.
  doug: You can't get certain kinds of intersections.

  dino: I disagree.
  dino: When we proposed the matrix API there was pushback from
        developers making a point that every time you cross the boundary
        from JS to native code, you get a performance hit.
  dino: In many cases you want to leave things in JS so people can pick
        the implementation they want.
  dino: With intersections, you want them for physics libraries or ...
  dino: And they're hand tuned.
  dino: It might be better to leave them to JS to see what comes up.
  dino: JS performance is good.
  dino: Getting fast access to geometry data of SVG could be useful.
  dino: Doing intersections in a physics library, you might want to
        intersect with approximations of a shape, not the accurate
        actual shapes.

  krit: There's no JS library that does it completely?
  krit: So it's less likely we can do it in a reasonable amount of time.
  heycam: I think it's just as easy/hard in JS as C++.
  doug: Is the cost between JS->native more expensive than doing the
        operations in JS itself?
  dino: I expect you'll be better off leaving it in JS.
  dino: There's also a cost of doing it in JS -- nobody else has done it
        other than Kevin since it's hard.
  rik: Raphael does it.

  doug: There's a download cost too.
  doug: Is it a common enough case to put it in the browser?
  doug: It's a CBA.
  doug: We should do that, rather than just assume it's better to do it
        in JS.
  doug: Kevin is on the hook to put a proposal to the CG.
  krit: Even if it's formalized in a draft, that'd be helpful.
  krit: Even if not implemented in a browser.

  krit: The last issue I want to discuss is Issue 5.
  krit: DOMMatrix takes a string,
  krit: From a CSS transform.
  krit: We agreed on this; only problem is whether this string needs to
        be strict CSS, or is a string from SVG transform="" attribute OK
        too?
  krit: e.g. "transform(20,20)" -- CSS needs units, SVG doesn't.
  krit: Would this string work passing it to DOMMatrix?
  dino: Yes.
  dbaron: I'm not crazy about implicit pixel units.
  dbaron: Where do these values go?
  krit: It's a parameter to DOMMatrix constructor.
  dbaron: I guess I'm ok with it.
  dbaron: It's reasonably isolated.

  krit: Do we need to time think about it more, or resolve?
  dino: Let's leave it in, but leave in text saying "speak up if you
        disagree."

  plinss: What's the point of this?
  krit: If you have SVG transform="" attribute, it doesn't require pixel
        units.
  plinss: But you're not using this in an SVG context?
  krit: You might.
  heycam: You could say to authors to get the transform values from CSS
          APIs, which will have the units in there.
  krit: Let's keep the issue in there for now.

  dbaron: One other question about the various rect types.
  dbaron: Earlier in the thread was a proposal for a type representing
          an immutable rect.
  dbaron: Did that go away?
  zcorpan: There is a mutable DOMMrect.
  dbaron: In the url I pasted earlier, there was a proposal for three
          types.
  dbaron: DOMRectView as a base type,
  dbaron: That you can't change, but may or may not be changing.
  dbaron: Two derived types,
  dbaron: One that you can change,
  dbaron: And one known not to be changing.
  zcorpan: That's what we have now, but the immutable is not used by
           anything.
  zcorpan: The View interface would get used for live reflections, but
           from script, read only.
  zcorpan: There are no objects known to be immutable.
  dbaron: But if there were you'd add a type?
  zcorpan: Yes.
  heycam: Or we could go down the road of having a frozen plain object
          for that.
  <slightlyoff> +1 to what heycam` said
  <TabAtkins> Yeah, more freezing.

  slightlyoff: Until someone presents a compelling use case for the read
               only versions of these interfaces, seems it better to
               have mutable versions.
  slightlyoff: Immutable is needed for perserving invariants the system
               is sensitive to.
  slightlyoff: But if not, preventing the user from modifying it doesn't
               seem useful,
  slightlyoff: Immutability isn't buying anything in those cases.
  slightlyoff: There's a generic argument here about it being a better
               documented pattern, but I think that's outside the bounds
               of how you'd write these things in plain JS.
  zcorpan: That's not a position that has been presented until today.
  zcorpan: It's good that you brought it up.
  zcorpan: The group might need more time to ponder.
  <TabAtkins> It buys us protection from "I'm reading these values, but
              they're not accurate!" (because somebody mistakenly
              mutated them before).

  dbaron: Alex is arguing against the third type?
  <TabAtkins> dbaron: Alex is arguing against all but the mutable types.
  slightlyoff: And the View type.
  dbaron: I think one issue that makes rects difficult is that there are
          multiple ways -- do people want x/y/width/height, top/left/
          bottom/right, or other ways of looking at it?
  dbaron: One factor is if you're not providing mutability, it's easier
          to provide those views,
  dbaron: But if it's mutable, you have to define what changing any of
          those views mean.

  slightlyoff: I don't think that's true.
  slightlyoff: You just have to define what the relationship between the
               objects is.
  slightlyoff: If an object vends a rect, does it have reln?
  slightlyoff: Or is it just a copy that it's handing out?
  slightlyoff: That's what you're implicitly talking about.
  dbaron: There are rect apis that you want a mutable rect that
          maintains a reln with the thing that handed it out.
  dbaron: One example is on a Quad.
  dbaron: You want the minimal rect that bounds the quad as a property
          on the object.
  dbaron: You want it to always give you the same object, otherwise it
          would be confusing.
  dbaron: So you want the object to maintain a reln with the quad that
          handed it out?
  dbaron: You don't want a new object each time you grab the property.

  plinss: If you mutate the rect do you get a new quad?
  dbaron: You can't mutate the rect.
  dbaron: There's no single mutation to the quad.
  plinss: So either you raise an exception, or it has no effect?
  dbaron: Right, so in this case, the design is that it would be a
          DOMRectView.
  plinss: And you try to mutate it?
  heycam: It'd throw a TypeError, no setter.
  <slightlyoff> I'm saying "just have setting the value do nothing in
                that case"

  plinss: What's the diff between it throwing an exception instead?
  zcorpan: Throwing an exception idea is what the spec had in first.
  zcorpan: A hidden flag that says "this object is read only."
  zcorpan: This is what TC39 folks were objecting against.
  slightlyoff: Now that we have getters/setters, with [[Writable]], it's
               easier to imagine plain JS coming up with this design.
  slightlyoff: I dunno if that means if it's a good/bad API.
  slightlyoff: Is this idiomatic JS?
  slightlyoff: If setting the value is nonsensical?
  slightlyoff: Why not have the property change in the background?
  slightlyoff: Why should we nail down the interfaces, when you wouldn't
               in JS?
  <TabAtkins> You can't have the object change in the background (in at
              least some cases). (Unless I'm misreading the minutes.)
  krit: It would be great if you could raise these issues on
        public-script-coord.

Received on Thursday, 21 November 2013 23:35:37 UTC