IRC log of svg on 2012-01-26
Timestamps are in UTC.
- 19:59:55 [RRSAgent]
- RRSAgent has joined #svg
- 19:59:55 [RRSAgent]
- logging to http://www.w3.org/2012/01/26-svg-irc
- 19:59:57 [trackbot]
- RRSAgent, make logs public
- 19:59:57 [Zakim]
- Zakim has joined #svg
- 19:59:59 [trackbot]
- Zakim, this will be GA_SVGWG
- 19:59:59 [Zakim]
- ok, trackbot, I see GA_SVGWG(SVG1)3:00PM already started
- 20:00:00 [trackbot]
- Meeting: SVG Working Group Teleconference
- 20:00:00 [trackbot]
- Date: 26 January 2012
- 20:01:03 [Zakim]
- +??P3
- 20:01:10 [ed]
- Zakim, ??P3 is me
- 20:01:10 [Zakim]
- +ed; got it
- 20:02:28 [cyril]
- cyril has joined #svg
- 20:03:06 [cabanier]
- cabanier has joined #svg
- 20:03:29 [cabanier]
- zakim, +1.206.734.aaa is me
- 20:03:29 [Zakim]
- +cabanier; got it
- 20:03:37 [krit]
- Zakim: and me?
- 20:03:50 [Zakim]
- + +29805aabb
- 20:04:13 [krit]
- Zakim: who's here
- 20:04:15 [cyril]
- zakim, Olivier_Goldman is krit
- 20:04:15 [Zakim]
- sorry, cyril, I do not recognize a party named 'Olivier_Goldman'
- 20:04:18 [Zakim]
- +??P5
- 20:04:20 [heycam]
- Zakim, ??P5 is me
- 20:04:20 [Zakim]
- +heycam; got it
- 20:04:22 [cyril]
- zakim, Oliver_Goldman is krit
- 20:04:22 [Zakim]
- +krit; got it
- 20:04:27 [ed]
- Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html
- 20:05:06 [ed]
- Chair: ed
- 20:05:31 [cyril]
- zakim, +29805aabb is me
- 20:05:31 [Zakim]
- +cyril; got it
- 20:05:33 [ed]
- Zakim, pick a victim?
- 20:05:33 [Zakim]
- I don't understand your question, ed.
- 20:05:40 [ed]
- Zakim, pick a scribe
- 20:05:40 [Zakim]
- Not knowing who is chairing or who scribed recently, I propose heycam
- 20:06:01 [cabanier]
- scribenick: cabanier
- 20:06:20 [Zakim]
- +Tav
- 20:06:39 [cabanier]
- topic: CSS Transforms and the behavior of SVG DOM
- 20:06:44 [ed]
- http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues
- 20:07:01 [cabanier]
- krit: I'm working on the merged css transform specification
- 20:07:05 [krit]
- http://www.w3.org/Graphics/fx/wiki/Merged_Transforms
- 20:07:23 [cabanier]
- krit: I found some possible SVG DOM issues
- 20:07:25 [plinss]
- plinss has joined #svg
- 20:07:35 [cabanier]
- krit: issue 11
- 20:07:58 [cabanier]
- Issue 11: Interaction of SVG DOMs SVGTransformList and SVGTransform to the CSS property
- 20:08:04 [cabanier]
- On transforming the SVG attribute transform' to a presentation attribute, the interaction of SVG DOM with CSSOM must be clarified. While an SVG attribute has a one-dimensional hierarchy where the value can just be influenced by the unique SVGTransformList, CSS had different cascading. Like described for CSSOm above, it is difficult to map cascading to the one-dimensional hierarchy, since different
- 20:08:04 [cabanier]
- style sheets can affect the style of an element and there for can have different affects to computed style. Computed itself style doesn't allow modifications.
- 20:08:42 [cabanier]
- krit: how can SVG DOM work with CSS?
- 20:10:01 [cabanier]
- krit: my proposal is to add a new stylesheet
- 20:10:20 [krit]
- Follow other presenattion attributes with transform
- 20:10:22 [ChrisL]
- ChrisL has joined #svg
- 20:10:28 [krit]
- Creating new Author style sheet
- 20:11:08 [Zakim]
- +ChrisL
- 20:11:15 [krit]
- the hierarchy of the author style sheet is after UA style sheets and before other author style sheets
- 20:11:29 [krit]
- SVG DOM should reflect the new created style sheet
- 20:12:24 [cabanier]
- heycam: this is just make the SVG DOM expose the stylesheet
- 20:12:41 [heycam]
- the style sheet for the presentation attributes (the low priority one) that is
- 20:13:01 [ChrisL]
- s/priority/specicicity/
- 20:13:04 [cabanier]
- heycam: on first reading this sounds reasonable
- 20:13:25 [ChrisL]
- s/specicicity/specificity/
- 20:13:27 [cabanier]
- heycam: people might be confused that CSS rules are not reflected in SVG DOM
- 20:14:16 [cabanier]
- heycam: we had a discussion that make the baseline the initial value
- 20:14:45 [cyril]
- s/baseline/base value/
- 20:15:19 [ed]
- it was "inline style" not "initial value", no?
- 20:15:28 [ChrisL]
- yes
- 20:15:38 [cabanier]
- heycam: reading out the value would get you the animated transform
- 20:16:02 [cabanier]
- chrisl: animval is the computed val?
- 20:16:26 [ChrisL]
- so the base value reflects the presentation attribute and the animval reflects the computed value
- 20:16:36 [cabanier]
- heycam: basevalue and animval can reflect different thing
- 20:16:44 [cabanier]
- krit: animval is the computed value
- 20:16:51 [cabanier]
- ed: that makes most sense
- 20:17:12 [cabanier]
- krit: that is not defined at the moment
- 20:17:29 [cabanier]
- krit: it makes most sense to have a list of animated values as well
- 20:17:40 [ChrisL]
- agree a tranfrom list is more useful
- 20:18:10 [cabanier]
- heycam: it is more useful to inspect to have a list of transform item rather than a flat matrix
- 20:18:21 [ed]
- s/that makes most sense/that makes most sense but I'm concerned about whether that means a flattened matrix, or if it's a list of matrices/
- 20:18:32 [cabanier]
- chrisl: you can always create a matrix, but no the other way round
- 20:18:57 [cabanier]
- cyril: why is this so different?
- 20:19:21 [cabanier]
- cyril: is it because of the cascade?
- 20:19:36 [cabanier]
- kris: yes, the transform property has the cascade
- 20:20:11 [cabanier]
- heycam: transform is now becoming a presentation attribute and we have to figure out what that means for the SVG DOM
- 20:20:51 [cabanier]
- heycam: there is no access to the CSS dom from SVG. There is no .fill attribute
- 20:21:06 [cabanier]
- krit: there is no animval/baseval to fill
- 20:21:23 [cabanier]
- heycam: I agree with Dirk's proposal. It matches what I was thinking of.
- 20:21:52 [cabanier]
- cabanier has joined #svg
- 20:22:43 [heycam]
- I prefer Dirk's suggestion because if you don't use transform in style="" or in CSS style sheets, then the SVG DOM for transform works the same as it always has.
- 20:23:01 [cabanier]
- heycam: it also works with the animval
- 20:23:41 [cabanier]
- heycam: by having animval reflect the computed style, it will looks the same as before
- 20:24:23 [cabanier]
- cyril: patrick's proposal has the same proplem
- 20:24:38 [cabanier]
- heycam: yes, we would want a consistent solution
- 20:25:41 [cabanier]
- ed: what does 'works with animval' mean?
- 20:25:45 [cyril]
- s/patrick's proposal has the same proplem/does patrick's proposal to turn some attributes into properties has the same problem ? If so, is the current solution also applicable?/
- 20:26:43 [ChrisL]
- yes we do
- 20:26:45 [ed]
- issue 12
- 20:26:53 [cabanier]
- krit: can we do 3d transform on SVG as well?
- 20:27:09 [cabanier]
- krit: we would need new interfaces for perspective, etc
- 20:27:17 [ChrisL]
- yes, we would
- 20:27:49 [cabanier]
- krit: do we want to extend SVG interfaces to access 3d transforms?
- 20:27:53 [heycam]
- s/on SVG as well/on SVGTransformList/
- 20:28:29 [cabanier]
- krit: we would have to specify everything that is in CSS, in SVG as well
- 20:28:57 [cabanier]
- heycam: I don't think it's that much work, since it pretty simple
- 20:29:25 [cabanier]
- heycam: otherwise we would have to specify what happens when you read out the transformlist
- 20:30:04 [cabanier]
- krit: I would specify that it's unresolvable. SVG DOM would just return undefined
- 20:30:25 [cabanier]
- krit: you would access everything with CSS and this would make things backward compatible
- 20:30:50 [cabanier]
- heycam: I guess we'll have similar issue with other issues
- 20:31:02 [cabanier]
- heycam: ie by using 'calc' in css
- 20:31:12 [cabanier]
- krit: yes, it is a general issue
- 20:31:49 [cabanier]
- krit: I would stop developing SVG DOM for these use cases
- 20:32:13 [cabanier]
- s/stop developing/not develop
- 20:32:46 [cabanier]
- heycam: yes, maybe we'll use the CSSOM to manipulate
- 20:33:42 [cabanier]
- heycam: if we improve the SVG DOM, should we target transform or should we do that in CSS?
- 20:33:51 [cabanier]
- krit: just do it in CSS
- 20:34:33 [cabanier]
- heycam: ie accessing width/height of a rectangle
- 20:36:30 [cabanier]
- krit: if you have SVG length, you can drop the 'px' but not in CSS
- 20:36:48 [cabanier]
- krit: I think the group should work on allowing that in CSS
- 20:36:51 [glenn]
- glenn has joined #svg
- 20:37:12 [cabanier]
- heycam: in CSS you can using units, while in SVG you can't
- 20:37:32 [cabanier]
- heycam: ie you can use '%' in CSS while in SVG you can't
- 20:38:00 [cabanier]
- krit: maybe we should resolve % to pixel in SVG
- 20:38:09 [cabanier]
- heycam: that would be possible
- 20:38:57 [cabanier]
- heycam: I'm OK with returning unknown type
- 20:39:11 [cabanier]
- ed: in practice, people will use the CSSOM
- 20:39:43 [cabanier]
- ed: since if you use the CSS feature, you will want to use that interface anyway
- 20:39:54 [cabanier]
- ed: we should try to make the CSSOM as good as possible
- 20:40:00 [cabanier]
- krit: yes
- 20:40:19 [cabanier]
- krit: I would like to have the same features in CSSOM that we have in SVG now
- 20:40:57 [cabanier]
- krit: make the CCSS interface such as transformlist live
- 20:41:26 [cabanier]
- heycam: does the combined transforms spec define any CSSOM interfaces?
- 20:41:54 [cabanier]
- krit: we have not specified transformlist but have css matrix
- 20:42:10 [cabanier]
- heycam: so if you use getcomputedstyle you will get them back?
- 20:43:25 [cabanier]
- krit: changes to cssmatrix are reflected in css transform as well.
- 20:43:54 [cabanier]
- krit: css transforms are more complicated than other css features
- 20:44:14 [cabanier]
- heycam: this is more a question for the CSS people
- 20:44:28 [cabanier]
- chrisl: it's not clear who is editing that.
- 20:44:39 [cabanier]
- heycam: glenn is supposed to be editing that
- 20:46:56 [cabanier]
- resolution: for issue 11 and 12, we will accept the recommended solutions (see: http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_issues)
- 20:48:29 [cabanier]
- topic: OpenType and SVG
- 20:48:55 [cabanier]
- krit: the problem are not willing to implement SVG fonts
- 20:49:13 [cabanier]
- chrisl: I proposed that we implement only WOFF
- 20:49:40 [cabanier]
- chrisl: it's very clear that mozilla and microsoft are not going to implement this
- 20:50:33 [cabanier]
- chrisl: there is a proposal to add SVG fonts to OpenType
- 20:50:35 [plinss_]
- plinss_ has joined #svg
- 20:50:47 [cabanier]
- chrisl: my feeling is that is longer term than SVG2
- 20:51:07 [cabanier]
- heycam: we have an intern working on this.
- 20:51:41 [cabanier]
- heycam: SVG glyphs inside OpenType
- 20:52:01 [cabanier]
- chrisl: there is no consensus how this format will look like
- 20:52:07 [krit]
- https://wiki.mozilla.org/SVGOpenTypeFonts
- 20:52:12 [cabanier]
- heycam: let me give you a link to the bug
- 20:52:16 [heycam]
- https://bugzilla.mozilla.org/show_bug.cgi?id=719286
- 20:52:36 [cabanier]
- heycam: I have never seen that page before
- 20:52:44 [cabanier]
- chrisl: me neither
- 20:53:14 [cabanier]
- heycam: this looks more like brainstorming
- 20:53:44 [cabanier]
- chrisl: this page should be updated with pointers to mailing lists, etc
- 20:54:16 [cabanier]
- heycam: the idea for the intern is to see how this works and report back
- 20:54:50 [cabanier]
- chrisl: I'm worried that the message will be that we already figured it out
- 20:55:08 [cabanier]
- chrisl: experimentation is great though. I'm very pleased
- 20:55:49 [cabanier]
- chrisl: sairus from Adobe is working on this
- 20:56:19 [cabanier]
- cabanier: I believe Sairus has a proposal. I can ping him.
- 20:56:59 [heycam]
- http://www.w3.org/community/svgopentype/
- 20:57:04 [cabanier]
- dirk: we need to find a way to have a public discussion ie by a mailing list
- 20:57:37 [cabanier]
- chrisl: I started the community group because people were emailing many groups
- 20:57:51 [heycam]
- http://lists.w3.org/Archives/Public/public-svgopentype/
- 20:57:52 [cabanier]
- chrisl: have a central location that is archived is important
- 20:59:01 [cabanier]
- chrisl: woff encapsulates OpenType
- 20:59:13 [cabanier]
- chrisl: CSS3 also mandates OT
- 20:59:30 [cabanier]
- chrisl: we are also going that way
- 21:00:15 [ChrisL]
- so if opentype adds this, svg will use it. discussion should be on the community group
- 21:00:34 [cabanier]
- resolution: any discussion should happen on the SVG OpenType group (http://www.w3.org/community/svgopentype/)
- 21:01:56 [Zakim]
- +[Microsoft]
- 21:02:24 [cabanier]
- cabanier has joined #svg
- 21:02:44 [cabanier]
- topic: SVG2 Requirements
- 21:02:45 [ed]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
- 21:03:07 [cabanier]
- cyril: I will edit the wiki page
- 21:03:44 [cyril]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3CsolidColor.3E_element
- 21:03:56 [Zakim]
- -ChrisL
- 21:04:45 [Zakim]
- +ChrisL
- 21:05:00 [cabanier]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#solid-color
- 21:05:27 [cabanier]
- chrisl: it's a single element gradient
- 21:05:31 [cyril]
- zakim, pointer
- 21:05:31 [Zakim]
- I don't understand 'pointer', cyril
- 21:05:38 [cyril]
- rrsagent, pointer
- 21:05:38 [RRSAgent]
- See http://www.w3.org/2012/01/26-svg-irc#T21-05-38
- 21:05:44 [Zakim]
- -Tav
- 21:06:21 [cabanier]
- chrisl: it's for paint servers, that are pointed to by a url
- 21:06:28 [Zakim]
- -[Microsoft]
- 21:06:38 [Zakim]
- +Tav
- 21:06:52 [cabanier]
- krit: can't this be done with CSS right now?
- 21:06:54 [plinss]
- plinss has joined #svg
- 21:06:59 [ed]
- <solidColor id="solidMaroon" solid-color="maroon" solid-opacity="0.7"/> <rect fill="url(#solidMaroon)" .../>
- 21:07:12 [cabanier]
- chrisl: not sure. by having the same class and style rule
- 21:08:21 [cabanier]
- chris: css animation would select a class, right?
- 21:08:25 [cabanier]
- krit: yes
- 21:09:18 [cabanier]
- krit: if you use a selector that is less specific, does the animation not happen?
- 21:09:43 [cabanier]
- krit: regardless of using this in CSS, people today are working around this with gradients.
- 21:10:04 [cabanier]
- tav: inkscape has a horrible patch to do this with a one stop gradient
- 21:10:45 [cabanier]
- chrisl: a solid color is really what you want to do. SVG 1.1 had it in there. It seems like a solid feature
- 21:11:43 [ChrisL]
- and 1.2T had it too
- 21:11:47 [cabanier]
- tav: inkscape would have a much simpler solution if it was in there
- 21:11:48 [ChrisL]
- and inkscape needs it
- 21:12:19 [cabanier]
- cyril: could inkscape do it will CSS classes?
- 21:12:22 [ed]
- so essentially it transforms <linearGradient><stop stop-color="foobar"/></linearGradient> into <solidColor solid-color="foobar"/>...
- 21:12:28 [cabanier]
- tav: inkscape doesn't do classes
- 21:13:04 [heycam]
- I think it wouldn't work with CSS, since you either need to have various different style rules for different properties, so you lose the ability to change the colour in a single place.
- 21:13:09 [cyril]
- s/do it will/define a color palette with/
- 21:13:23 [heycam]
- s/wouldn't work with CSS/you couldn't just do this with CSS/
- 21:14:13 [cabanier]
- heycam: CSS variables seems to be solving the same use case
- 21:14:27 [cabanier]
- chrisl: having named colors
- 21:14:53 [cabanier]
- is one of the primary reason for them. This is a very useful feature.
- 21:15:17 [ChrisL]
- it regularises the syntax so that you can use a paint server for solid as well as radient and pattern fills.
- 21:15:29 [cabanier]
- heycam: CSS variables is still far away but it would be good to avoid the same feature twice
- 21:15:32 [ChrisL]
- also, you can animate the url to go from a solid to a gradient ad back
- 21:15:38 [ChrisL]
- its very flexible
- 21:15:59 [cabanier]
- ed: this is very simple to implement. It doesn't add much code
- 21:16:53 [cabanier]
- resolution: we will add solid-color element to SVG2
- 21:17:25 [ed]
- s/solid-color/solidColor/
- 21:17:35 [cabanier]
- s/solid-color/solid-color and solid-opacity property
- 21:18:41 [cabanier]
- topic: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text-align
- 21:19:09 [cyril]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id
- 21:19:29 [cabanier]
- topic: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id
- 21:19:35 [cabanier]
- chrisl: we should drop it
- 21:19:42 [cabanier]
- everyone: agreed
- 21:19:50 [cabanier]
- resolution: drop XML:id
- 21:20:17 [cabanier]
- topic: role, rel, rev, about, content, datatype, property, resource, typeof
- 21:20:30 [cabanier]
- chrisl: hasn't seen much use but it is used in HTML
- 21:20:50 [cabanier]
- heycam: doesn't exactly match with what HTML5 has since they start with item
- 21:21:31 [cabanier]
- krit: I think it's great but should match HTML5
- 21:21:54 [cabanier]
- heycam: HTML5 doesn't require RDFA and microdata
- 21:22:23 [cabanier]
- cabanier has joined #svg
- 21:22:24 [ChrisL]
- s/hasn't seen much use/was added to support RDFa and microdate, but hasn't seen much use/
- 21:22:58 [cabanier]
- heycam: microdata came with a set of DOM interfaces that we want to support
- 21:23:03 [cabanier]
- chrisl: yes
- 21:23:52 [cabanier]
- heycam: scannig the HTML5 spec, I don't see where RDFA is required.
- 21:24:04 [cabanier]
- heycam: maybe there is a seperate spec
- 21:24:19 [cabanier]
- s/scannig/scanning
- 21:24:45 [cabanier]
- chrisl: RDFlite is I believe
- 21:25:04 [cabanier]
- chrisl: it could be that the spec hasn't been updated
- 21:25:33 [cabanier]
- resolution: for RDFa and microdata follow what HTML does
- 21:26:10 [cabanier]
- topic: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#display-align
- 21:27:03 [ed]
- this depends on <textArea>
- 21:27:10 [cabanier]
- chrisl: this is moot since we're following CSS
- 21:27:23 [cabanier]
- chrisl: not textarea
- 21:27:30 [ChrisL]
- its tied to f the 'textArea' element. which we are not using
- 21:27:39 [cabanier]
- resolution: we won't display-align since we won't have textarea
- 21:28:56 [cabanier]
- topic: buffered rendering
- 21:29:09 [cabanier]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering
- 21:29:40 [plinss_]
- plinss_ has joined #svg
- 21:29:40 [cabanier]
- ed: it's a hint to cache as much as possible
- 21:29:48 [cabanier]
- ed: it's not a requirement
- 21:30:05 [cabanier]
- cabanier: this is very useful
- 21:30:12 [cabanier]
- krit: I'm fine with it
- 21:30:24 [cabanier]
- heycam: I'm concerned about these hints
- 21:30:38 [cabanier]
- heycam: like filter-region
- 21:30:50 [cabanier]
- ed: I agree
- 21:32:07 [ed]
- s/agree/share your concern about misuse of this property, but it's sometimes needed for specific devices/scenarios/
- 21:33:29 [cabanier]
- resolution: after implementor feedback, we agree that buffer rendering hints are needed
- 21:34:47 [cabanier]
- heycam: with CSS transform, you can get pixelated buffers
- 21:35:13 [cabanier]
- heycam: we should have a requirement that they should rerender
- 21:36:10 [heycam]
- s/we should/would we have/
- 21:36:19 [heycam]
- s/have have/have/
- 21:36:23 [cabanier]
- ed: in most cases you don't get pixels
- 21:36:36 [cabanier]
- s/get/want
- 21:37:03 [Zakim]
- -Tav
- 21:37:58 [Zakim]
- -ed
- 21:38:00 [Zakim]
- -krit
- 21:38:00 [Zakim]
- -heycam
- 21:38:02 [Zakim]
- -ChrisL
- 21:38:06 [Zakim]
- -cabanier
- 21:38:13 [ChrisL]
- zakim, list attendees
- 21:38:13 [Zakim]
- As of this point the attendees have been +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Tav, ChrisL, [Microsoft]
- 21:38:24 [ChrisL]
- rrsagent, make minutes
- 21:38:24 [RRSAgent]
- I have made the request to generate http://www.w3.org/2012/01/26-svg-minutes.html ChrisL
- 21:39:02 [cabanier]
- thanks!
- 21:39:25 [Zakim]
- -cyril
- 21:39:26 [Zakim]
- GA_SVGWG(SVG1)3:00PM has ended
- 21:39:27 [Zakim]
- Attendees were +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Tav, ChrisL, [Microsoft]
- 21:39:27 [krit]
- krit has joined #svg
- 21:43:54 [cabanier]
- cabanier has joined #svg
- 21:45:36 [cyril]
- cyril has joined #svg
- 21:47:33 [cyril]
- 118/180 requirements
- 22:02:56 [cabanier]
- cabanier has joined #svg
- 23:17:51 [thorton]
- thorton has joined #svg