- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Nov 2013 18:35:09 -0500
- To: www-style@w3.org
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