IRC log of svg on 2013-08-15

Timestamps are in UTC.

20:28:25 [RRSAgent]
RRSAgent has joined #svg
20:28:25 [RRSAgent]
logging to http://www.w3.org/2013/08/15-svg-irc
20:28:27 [trackbot]
RRSAgent, make logs public
20:28:27 [Zakim]
Zakim has joined #svg
20:28:29 [trackbot]
Zakim, this will be GA_SVGWG
20:28:29 [Zakim]
ok, trackbot, I see GA_SVGWG(SVG1)4:30PM already started
20:28:30 [trackbot]
Meeting: SVG Working Group Teleconference
20:28:30 [trackbot]
Date: 15 August 2013
20:28:31 [Zakim]
+krit
20:28:31 [Zakim]
-krit
20:28:32 [Zakim]
+krit
20:28:57 [Zakim]
+[IPcaller]
20:29:04 [heycam]
Zakim, [ is me
20:29:04 [Zakim]
+heycam; got it
20:29:30 [Zakim]
+cabanier
20:30:29 [heycam]
Chair: Cameron
20:30:33 [heycam]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0054.html
20:30:35 [heycam]
Regrets: Rich
20:32:17 [TabAtkins]
Dear SVG: Please kill your namespaces faster. Love, Tab.
20:35:57 [Zakim]
+nikos
20:37:04 [krit1]
TabAtkins: we would need to add the SVG elements to the HTML parser
20:37:04 [nikos]
scribenick: nikos
20:37:16 [TabAtkins]
krit1++
20:37:28 [TabAtkins]
But really it's the xlink that's killing me today.
20:37:36 [TabAtkins]
Which requires only local changes to the language.
20:37:36 [nikos]
Topic: Publishing and renaming CSSMatrix
20:37:41 [heycam]
Removing xlink is something we can do without a lot of the other stuff.
20:37:59 [cabanier]
I thought we already agree to killing that off
20:38:03 [krit]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
20:38:06 [TabAtkins]
Yeah, but it's not edited in yet. ^_^
20:38:23 [krit]
http://dev.w3.org/fxtf/matrix/
20:38:43 [nikos]
heycam: we haven't published this yet?
20:38:46 [nikos]
krit: correct
20:38:48 [nikos]
krit: 2 issues
20:38:55 [nikos]
krit: first is name. CSS WG doesn't want CSS prefix
20:39:11 [nikos]
heycam: dictionary ones don't matter since they're not exposed in script
20:39:21 [nikos]
... interfaces intended to be used outside probably shouldn't have css in the name
20:39:35 [nikos]
krit: suggestion was either TransformationMatrix or TransformMatrix
20:39:38 [nikos]
... I don't have others
20:39:58 [nikos]
heycam: if we named it Matrix, there might be a risk of conflicting with scripts that define Matrix already
20:40:06 [nikos]
krit: we also have conflict with other working groups
20:40:19 [nikos]
... was discussed on fxtf mailing list
20:40:31 [nikos]
... was suggested to name it Deprecated Matrix
20:40:34 [nikos]
heycam: ugly name!
20:40:41 [nikos]
cabanier: web gl want to have something more primitive
20:40:56 [nikos]
... not useful for authors. The reason we are doing this is to make operations easier for them
20:41:15 [nikos]
heycam: I'm not convinced by argument that we shouldn't have it becaues JS authors can write something that can run faster
20:41:29 [nikos]
... browsers can implement with native js behind the scenes and avoid the overhead
20:42:02 [TabAtkins]
I'm down with TransformMatrix.
20:42:29 [nikos]
krit: because Matrix is so generic, I don't think it's a bad idea to have a prefix
20:43:12 [nikos]
heycam: you said CSS WG has already resolved to publish? what was their final view on name? have an issue in the spec?
20:43:23 [nikos]
krit: we need the name for the url though so it's problematic to do that
20:43:40 [nikos]
heycam: I think it would be fine, even if we call it CSSMatrix or TranformMatrix to have the matrix as just url
20:43:51 [nikos]
s/matrix as just url/url as just matrix
20:44:04 [nikos]
heycam: I'm fine with publishing and including an issue
20:44:17 [nikos]
krit: CSS WG suggested SVG WG takes care of publication
20:44:28 [nikos]
heycam: couple of other issues open in the spec
20:44:40 [nikos]
... 1. w part of the point
20:44:46 [nikos]
krit: the main is whether we use float or doubles
20:45:28 [nikos]
krit: Mozilla wants floats. Apple wants double
20:45:44 [nikos]
krit: difference is 10 times on mobile
20:46:03 [nikos]
krit: javascript just uses double
20:46:11 [nikos]
... so it's just the internal calculation results
20:46:22 [nikos]
... currently I am using doubles in the spec
20:46:30 [nikos]
heycam: I don't think we need to resolve that before publishing
20:46:54 [nikos]
heycam: what is the plan for replacing SVGMatrix with CSSMatrix?
20:47:11 [nikos]
krit: The whole point of this is to replace SVGMatrix
20:47:35 [nikos]
heycam: so we'll just use CSSMatrix. Won't have any inheritance.
20:47:55 [nikos]
krit: It's backwards compatible, except the new matrix won't throw exceptions as SVGMatrix did
20:48:36 [nikos]
heycam: I also remember roc was concerned about the matrix object being used for 3d and 2d
20:48:45 [nikos]
... meaning you need the extra components
20:48:56 [nikos]
krit: I think he's ok with it now
20:49:10 [nikos]
heycam: I'll check with him
20:50:54 [nikos]
resolution: Publish first public working draft of new matrix specification
20:51:23 [nikos]
action: Cameron to organise FPWD publication of new matrix specification
20:51:24 [trackbot]
Created ACTION-3517 - Organise fpwd publication of new matrix specification [on Cameron McCormack - due 2013-08-22].
20:52:01 [nikos]
Topic: Progress on subregions hinting in SVG Filters
20:52:13 [krit]
http://www.w3.org/Graphics/fx/wiki/Filter_effects
20:52:43 [nikos]
krit: Erik put together an implementation matrix
20:53:12 [nikos]
krit: We need to specify exactly how subregions are calculated
20:53:27 [nikos]
... I would like feedback on the table
20:53:34 [nikos]
... especially where we have question marks
20:53:48 [nikos]
... we're not clear on how to calculate subregions for some filters at the moment
20:54:28 [nikos]
krit: it's important that the filter region doesn't clip things you don't want clipped
20:54:36 [nikos]
... a lot of people don't understand the 10% margin
20:54:45 [nikos]
heycam: I never liked it. It's not usually what you want
20:54:57 [nikos]
... are you suggesting to remove filter region primitive attribute?
20:55:08 [nikos]
krit: no
20:55:20 [nikos]
... if they are not present then the user agent should calculate automatically
20:55:28 [nikos]
heycam: so changing the default
20:55:34 [nikos]
krit: in a way that fixes content
20:55:38 [nikos]
heycam: I'd be in favour of that
20:55:54 [nikos]
krit: so we need to specify what unbound? is for each in the table
20:56:41 [nikos]
heycam: for filters like feFlood or feTurbulence that conceptually have infinite output, what would we define apart from 'implementation needs to work out how much of the final rendered element to keep'
20:56:59 [nikos]
krit: we could specify 120%. it's not nice though
20:57:13 [nikos]
heycam: can't we just state it needs to be large enough so that it doesn't affect filter output?
20:57:50 [nikos]
krit: If you use feFlood and it will fill the whole SVG file.
20:58:02 [nikos]
... could use the viewPort
20:58:07 [nikos]
heycam: feFlood is a special case though
20:58:42 [nikos]
... why can't we say something like 'minimal area based on how that filter primitive is used in the filter chain'
20:59:07 [nikos]
krit: Need to specify that content looks equal on all implementations
20:59:22 [nikos]
heycam: I think that can be achieved by saying the filter primitive is big enough so that it doesn't look different
21:00:17 [nikos]
... when the element is rendered, there will be some clipping at some point
21:00:31 [nikos]
... then you can determine the smallest rectangle based on how it is used in the filter chain
21:00:52 [nikos]
... we can require UAs to generate the filter primitive at the required siz
21:00:57 [nikos]
s/siz/size
21:01:03 [nikos]
krit: I agree. feFlood is still the problem though
21:01:33 [nikos]
heycam: If you didn't have any other clipping, then feFlood would fill the viewport
21:02:15 [nikos]
krit: Would have to check about breaking content
21:02:37 [nikos]
heycam: do you feel we need to specify how to calculate the area for that primitive?
21:02:41 [nikos]
krit: I think that's a good idea
21:02:51 [nikos]
... to ensure consistency between implementations
21:03:12 [nikos]
heycam: I'd be fine if we had something like that written down. Do you want to do that?
21:03:13 [nikos]
krit: yes
21:03:46 [nikos]
action: Dirk to specify how to calculate automatic filter region for unbounded primitives
21:03:47 [trackbot]
Created ACTION-3518 - Specify how to calculate automatic filter region for unbounded primitives [on Dirk Schulze - due 2013-08-22].
21:04:01 [nikos]
Topic: Collapsing CSS Filter functions and the problem of color clamping on
21:04:01 [nikos]
intermediate results
21:04:24 [nikos]
krit: a lot of filter effects short hands can be represented with a colour matrix
21:04:45 [nikos]
... ideally you can collapse the filter chain to a single operation on the matrix
21:04:57 [nikos]
... but we currently define that values should be clamped at each stage
21:05:23 [nikos]
... do we want to keep current behaviour or can we relax the specification to allow optimisation in this case?
21:05:48 [Zakim]
+Doug_Schepers
21:05:51 [nikos]
... it's a balance between performance and ease of authoring
21:06:19 [nikos]
heycam: is there a benefit to clamping at each filter? is that something authors would need or want?
21:07:10 [nikos]
heycam: there are similar thinks in CSS with colour values
21:07:32 [nikos]
... I can't remember where exactly but it talks about allowing values to go out of range and clamp in the final step
21:07:37 [nikos]
... so there might be precedence
21:08:27 [nikos]
nikos: I think it would be confusing for authors to get different results depending on whether a shorthand is used or not
21:08:53 [krit]
s/colour/color/g
21:08:54 [nikos]
heycam: my feeling is that we should allow intermediate results to go out of range and clamp at the end
21:08:55 [krit]
:D
21:10:04 [nikos]
krit: initially I was for clamping at the end. Now i'm not sure. There are cases where you can guarantee that you don't need to clamp
21:10:12 [nikos]
... so I support clamping at each step now
21:10:24 [nikos]
heycam: I can't see an author use for clamping each stage
21:10:35 [nikos]
... if there was one I think it would be better to have explicit control to opt in to that
21:10:54 [nikos]
krit: there is another case. contrast 200% then another filter primitive with contrast 50% and they wonder why they don't get the same result
21:11:12 [nikos]
...it's a corner case though. I don't think it's actually useful to do that.
21:11:57 [nikos]
heycam: I can imagine cases where an image has colour values that are almost fully bright and you apply a brightness filter and you want to clamp
21:12:51 [nikos]
heycam: I'm not sure which I prefer
21:12:55 [nikos]
krit: I think we should keep the clamping for now
21:13:50 [nikos]
shepazu: I've seen some pretty crazy stuff come out of authoring tools
21:14:15 [nikos]
heycam: I'm not sure how much performance benefit there is from collapsing down to a single operation on a colour matrix
21:14:47 [nikos]
... I think implementations often slow down with filters because they are creating lots of off-screen surfaces
21:15:03 [nikos]
... here that shouldn't matter as you can work on the same surface
21:16:28 [nikos]
resolution: maintain clamping colour matrices for filter effects at each step in the filter chain
21:16:43 [nikos]
Topic: Geometry API and Accessible SVG Community Groups
21:16:59 [nikos]
shepazu: there are 2 community groups you guys might be interested in
21:17:04 [nikos]
1. SVG accessibility
21:17:23 [shepazu]
http://www.w3.org/community/svga11y/
21:17:25 [shepazu]
http://www.w3.org/community/svga11y/2013/08/15/roadmap/
21:17:42 [nikos]
2. geometry API
21:18:18 [shepazu]
http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_Requirements
21:18:18 [shepazu]
http://www.w3.org/community/geometryapi/
21:18:19 [nikos]
use cases and requirements doc (in progress)
21:18:53 [nikos]
SVG accessibility is unclear. There's few normative requirements, a lot comes from the doc that Charles wrote about mapping and authoring guidelines
21:19:06 [nikos]
shepazu: very old. refers to SVG 1.0
21:19:31 [nikos]
... After talking to accessibility experts. The state of SVG is ok, but there's a lot of tests that need to be run
21:19:45 [nikos]
... so the whole point of this group is to write tests and write requirements
21:19:57 [nikos]
... we're going to have a workshop/hackathon
21:20:12 [nikos]
heycam: sounds good. for me I don't feel I have the knowledge to know what we need to change in SVG
21:20:20 [nikos]
krit: who would attend the workshop?
21:20:33 [nikos]
shepazu: there's about 16 people in the group now.
21:21:38 [nikos]
... we want: 1. Accessibility experts who can help us test. 2. People who use accessibility features. 3. SVG people
21:21:57 [nikos]
... and at least one 'testing' expert
21:23:05 [nikos]
... I gave a presentation about accessible data visualisation and people were really interested
21:23:10 [nikos]
... that's where this came from
21:23:41 [nikos]
... first step is to make a bunch of tests, run them and create an implementation report
21:26:07 [nikos]
nikos: what's the make up of the group. Who do you need?
21:26:31 [nikos]
shepazu: we have lots of interested accessibility experts.
21:26:43 [nikos]
... they should be able to find people who use accessibility features
21:27:13 [nikos]
... there's two or three people who are pretty good with SVG
21:27:18 [nikos]
... would be good to have Rich in the group
21:27:28 [nikos]
... looking for someone from Adobe
21:27:43 [nikos]
... I'm looking at September for the hackathon
21:29:18 [nikos]
... October at the graphical web would be good. Cyril, Tav, and Nikos will be there
21:30:35 [nikos]
... so we can chat about that and try to organise a time that is good for everyone
21:30:55 [nikos]
shepazu: The other group is the geometry API community group
21:31:06 [nikos]
... the goal there is to come up with a geometry api (SURPRISE!)
21:31:34 [nikos]
... we want to meet use cases for SVG primarily. But if we satisfies use cases for other web tech that's ok.
21:31:47 [nikos]
... I want to be able to do things like calculate intersection of shapes
21:35:57 [nikos]
cabanier: Dirk and I signed up
21:36:26 [nikos]
shepazu: If we can come out with a simple set of use cases and requirements that we might include in SVG 2
21:36:38 [nikos]
krit: should get some SKIA guys in the group
21:38:26 [nikos]
cabanier: is this part of SVG or is it just something that interfaces with SVG?
21:38:51 [nikos]
shepazu: I guess you could interact with other web tech
21:39:08 [nikos]
krit: it would be great to have a document that everyone could reference
21:39:53 [nikos]
shepazu: it would be good to have more people in the group to define the use cases that are important
21:40:18 [nikos]
... it would be good to have a matrix library (SKIA has), point and vector maths
21:40:23 [nikos]
... need to drive requirements on those
21:41:04 [nikos]
... in conclusion. It would be good to get people into the groups to drive the conversation and keep them going
21:41:23 [Zakim]
-cabanier
21:41:25 [Zakim]
-heycam
21:42:34 [Zakim]
-krit
21:43:27 [Zakim]
-nikos
21:43:28 [Zakim]
-Doug_Schepers
21:43:35 [nikos]
RRSAgent, make minutes
21:43:35 [RRSAgent]
I have made the request to generate http://www.w3.org/2013/08/15-svg-minutes.html nikos
21:46:59 [krit]
krit has joined #svg
21:47:50 [Zakim]
- +1.425.373.aaaa
21:47:51 [Zakim]
GA_SVGWG(SVG1)4:30PM has ended
21:47:51 [Zakim]
Attendees were +1.425.373.aaaa, krit, [IPcaller], heycam, cabanier, nikos, Doug_Schepers
23:17:49 [birtles]
birtles has joined #svg
23:22:23 [jaseg]
jaseg has joined #svg
23:50:08 [thorton]
thorton has joined #svg