minutes, 26 January 2012 SVG WG telcon

Hello, please find below the minutes from the SVG WG telcon.

http://www.w3.org/2012/01/26-svg-minutes.html

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

26 Jan 2012

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/01/26-svg-irc

Attendees

   Present
          +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Tav,
          ChrisL, [Microsoft]

   Regrets
   Chair
          ed

   Scribe
          cabanier

Contents

     * [4]Topics
         1. [5]CSS Transforms and the behavior of SVG DOM
         2. [6]OpenType and SVG
         3. [7]SVG2 Requirements
         4. [8]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
            _Input#text-align
         5. [9]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
            _Input#xml:id
         6. [10]role, rel, rev, about, content, datatype, property,
            resource, typeof
         7. [11]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirement
            s_Input#display-align
         8. [12]buffered rendering
     * [13]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 26 January 2012

   <krit> Zakim: and me?

   <krit> Zakim: who's here

   <scribe> scribenick: cabanier

CSS Transforms and the behavior of SVG DOM

   <ed>
   [14]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issue
   s

     [14] http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues

   krit: I'm working on the merged css transform specification

   <krit> [15]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms

     [15] http://www.w3.org/Graphics/fx/wiki/Merged_Transforms

   krit: I found some possible SVG DOM issues
   ... issue 11

   Issue 11: Interaction of SVG DOMs SVGTransformList and SVGTransform
   to the CSS property

   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

   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.

   krit: how can SVG DOM work with CSS?
   ... my proposal is to add a new stylesheet

   <krit> Follow other presenattion attributes with transform

   <krit> Creating new Author style sheet

   <krit> the hierarchy of the author style sheet is after UA style
   sheets and before other author style sheets

   <krit> SVG DOM should reflect the new created style sheet

   heycam: this is just make the SVG DOM expose the stylesheet

   <heycam> the style sheet for the presentation attributes (the low
   specificity one) that is

   heycam: on first reading this sounds reasonable
   ... people might be confused that CSS rules are not reflected in SVG
   DOM
   ... we had a discussion that make the base value the initial value

   <ed> it was "inline style" not "initial value", no?

   <ChrisL> yes

   heycam: reading out the value would get you the animated transform

   chrisl: animval is the computed val?

   <ChrisL> so the base value reflects the presentation attribute and
   the animval reflects the computed value

   heycam: basevalue and animval can reflect different thing

   krit: animval is the computed value

   ed: that makes most sense but I'm concerned about whether that means
   a flattened matrix, or if it's a list of matrices

   krit: that is not defined at the moment
   ... it makes most sense to have a list of animated values as well

   <ChrisL> agree a tranfrom list is more useful

   heycam: it is more useful to inspect to have a list of transform
   item rather than a flat matrix

   chrisl: you can always create a matrix, but no the other way round

   cyril: why is this so different?
   ... is it because of the cascade?

   kris: yes, the transform property has the cascade

   heycam: transform is now becoming a presentation attribute and we
   have to figure out what that means for the SVG DOM
   ... there is no access to the CSS dom from SVG. There is no .fill
   attribute

   krit: there is no animval/baseval to fill

   heycam: I agree with Dirk's proposal. It matches what I was thinking
   of.

   <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.

   heycam: it also works with the animval
   ... by having animval reflect the computed style, it will looks the
   same as before

   cyril: does patrick's proposal to turn some attributes into
   properties has the same problem ? If so, is the current solution
   also applicable?

   heycam: yes, we would want a consistent solution

   ed: what does 'works with animval' mean?

   <ChrisL> yes we do

   <ed> issue 12

   krit: can we do 3d transform on SVGTransformList?
   ... we would need new interfaces for perspective, etc

   <ChrisL> yes, we would

   krit: do we want to extend SVG interfaces to access 3d transforms?
   ... we would have to specify everything that is in CSS, in SVG as
   well

   heycam: I don't think it's that much work, since it pretty simple
   ... otherwise we would have to specify what happens when you read
   out the transformlist

   krit: I would specify that it's unresolvable. SVG DOM would just
   return undefined
   ... you would access everything with CSS and this would make things
   backward compatible

   heycam: I guess we'll have similar issue with other issues
   ... ie by using 'calc' in css

   krit: yes, it is a general issue
   ... I would not develop SVG DOM for these use cases

   heycam: yes, maybe we'll use the CSSOM to manipulate
   ... if we improve the SVG DOM, should we target transform or should
   we do that in CSS?

   krit: just do it in CSS

   heycam: ie accessing width/height of a rectangle

   krit: if you have SVG length, you can drop the 'px' but not in CSS
   ... I think the group should work on allowing that in CSS

   heycam: in CSS you can using units, while in SVG you can't
   ... ie you can use '%' in CSS while in SVG you can't

   krit: maybe we should resolve % to pixel in SVG

   heycam: that would be possible
   ... I'm OK with returning unknown type

   ed: in practice, people will use the CSSOM
   ... since if you use the CSS feature, you will want to use that
   interface anyway
   ... we should try to make the CSSOM as good as possible

   krit: yes
   ... I would like to have the same features in CSSOM that we have in
   SVG now
   ... make the CCSS interface such as transformlist live

   heycam: does the combined transforms spec define any CSSOM
   interfaces?

   krit: we have not specified transformlist but have css matrix

   heycam: so if you use getcomputedstyle you will get them back?

   krit: changes to cssmatrix are reflected in css transform as well.
   ... css transforms are more complicated than other css features

   heycam: this is more a question for the CSS people

   chrisl: it's not clear who is editing that.

   heycam: glenn is supposed to be editing that

   resolution: for issue 11 and 12, we will accept the recommended
   solutions (see:
   [16]http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_iss
   ues)

     [16] http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_issues)

OpenType and SVG

   krit: the problem are not willing to implement SVG fonts

   chrisl: I proposed that we implement only WOFF
   ... it's very clear that mozilla and microsoft are not going to
   implement this
   ... there is a proposal to add SVG fonts to OpenType
   ... my feeling is that is longer term than SVG2

   heycam: we have an intern working on this.
   ... SVG glyphs inside OpenType

   chrisl: there is no consensus how this format will look like

   <krit> [17]https://wiki.mozilla.org/SVGOpenTypeFonts

     [17] https://wiki.mozilla.org/SVGOpenTypeFonts

   heycam: let me give you a link to the bug

   <heycam> [18]https://bugzilla.mozilla.org/show_bug.cgi?id=719286

     [18] https://bugzilla.mozilla.org/show_bug.cgi?id=719286

   heycam: I have never seen that page before

   chrisl: me neither

   heycam: this looks more like brainstorming

   chrisl: this page should be updated with pointers to mailing lists,
   etc

   heycam: the idea for the intern is to see how this works and report
   back

   chrisl: I'm worried that the message will be that we already figured
   it out
   ... experimentation is great though. I'm very pleased
   ... sairus from Adobe is working on this

   cabanier: I believe Sairus has a proposal. I can ping him.

   <heycam> [19]http://www.w3.org/community/svgopentype/

     [19] http://www.w3.org/community/svgopentype/

   dirk: we need to find a way to have a public discussion ie by a
   mailing list

   chrisl: I started the community group because people were emailing
   many groups

   <heycam> [20]http://lists.w3.org/Archives/Public/public-svgopentype/

     [20] http://lists.w3.org/Archives/Public/public-svgopentype/

   chrisl: have a central location that is archived is important
   ... woff encapsulates OpenType
   ... CSS3 also mandates OT
   ... we are also going that way

   <ChrisL> so if opentype adds this, svg will use it. discussion
   should be on the community group

   resolution: any discussion should happen on the SVG OpenType group
   ([21]http://www.w3.org/community/svgopentype/)

     [21] http://www.w3.org/community/svgopentype/)

SVG2 Requirements

   <ed>
   [22]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

     [22] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

   cyril: I will edit the wiki page

   <cyril>
   [23]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#t
   he_.3CsolidColor.3E_element

     [23] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3CsolidColor.3E_element

   [24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#s
   olid-color

     [24] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#solid-color

   chrisl: it's a single element gradient
   ... it's for paint servers, that are pointed to by a url

   krit: can't this be done with CSS right now?

   <ed> <solidColor id="solidMaroon" solid-color="maroon"
   solid-opacity="0.7"/> <rect fill="url(#solidMaroon)" .../>

   chrisl: not sure. by having the same class and style rule

   chris: css animation would select a class, right?

   krit: yes
   ... if you use a selector that is less specific, does the animation
   not happen?
   ... regardless of using this in CSS, people today are working around
   this with gradients.

   tav: inkscape has a horrible patch to do this with a one stop
   gradient

   chrisl: a solid color is really what you want to do. SVG 1.1 had it
   in there. It seems like a solid feature

   <ChrisL> and 1.2T had it too

   tav: inkscape would have a much simpler solution if it was in there

   <ChrisL> and inkscape needs it

   cyril: could inkscape define a color palette with CSS classes?

   <ed> so essentially it transforms <linearGradient><stop
   stop-color="foobar"/></linearGradient> into <solidColor solid-color
   and solid-opacity property="foobar"/>...

   tav: inkscape doesn't do classes

   <heycam> I think it you couldn't just do this 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.

   heycam: CSS variables seems to be solving the same use case

   chrisl: having named colors

   is one of the primary reason for them. This is a very useful
   feature.

   <ChrisL> it regularises the syntax so that you can use a paint
   server for solid as well as radient and pattern fills.

   heycam: CSS variables is still far away but it would be good to
   avoid the same feature twice

   <ChrisL> also, you can animate the url to go from a solid to a
   gradient ad back

   <ChrisL> its very flexible

   ed: this is very simple to implement. It doesn't add much code

   resolution: we will add solidColor element to SVG2

[25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text
-align

     [25] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#text-align

   <cyril>
   [26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#x
   ml:id

     [26] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id

[27]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:
id

     [27] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id

   chrisl: we should drop it

   everyone: agreed

   resolution: drop XML:id

role, rel, rev, about, content, datatype, property, resource, typeof

   chrisl: was added to support RDFa and microdate, but hasn't seen
   much use but it is used in HTML

   heycam: doesn't exactly match with what HTML5 has since they start
   with item

   krit: I think it's great but should match HTML5

   heycam: HTML5 doesn't require RDFA and microdata
   ... microdata came with a set of DOM interfaces that we want to
   support

   chrisl: yes

   heycam: scanning the HTML5 spec, I don't see where RDFA is required.
   ... maybe there is a seperate spec

   chrisl: RDFlite is I believe
   ... it could be that the spec hasn't been updated

   resolution: for RDFa and microdata follow what HTML does

[28]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#disp
lay-align

     [28] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#display-align

   <ed> this depends on <textArea>

   chrisl: this is moot since we're following CSS
   ... not textarea

   <ChrisL> its tied to f the 'textArea' element. which we are not
   using

   resolution: we won't display-align since we won't have textarea

buffered rendering

   [29]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#b
   uffered-rendering

     [29] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering

   ed: it's a hint to cache as much as possible
   ... it's not a requirement

   cabanier: this is very useful

   krit: I'm fine with it

   heycam: I'm concerned about these hints
   ... like filter-region

   ed: I agree

   <ed> s/agree/share your concern about misuse of this property, but
   it's sometimes needed for specific devices/scenarios/

   resolution: after implementor feedback, we agree that buffer
   rendering hints are needed

   heycam: with CSS transform, you can get pixelated buffers
   ... would we have a requirement that they should rerender

   ed: in most cases you don't want pixels

Summary of Action Items

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [30]scribe.perl version 1.136
    ([31]CVS log)
    $Date: 2012/01/26 21:38:29 $
     _________________________________________________________

     [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [31] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [32]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/priority/specicicity/
Succeeded: s/specicicity/specificity/
Succeeded: s/baseline/base value/
Succeeded: s/that makes most sense/that makes most sense but I'm concer
ned about whether that means a flattened matrix, or if it's a list of m
atrices/
Succeeded: s/patrick's proposal has the same proplem/does patrick's pro
posal to turn some attributes into properties has the same problem ? If
so, is the current solution also applicable?/
Succeeded: s/on SVG as well/on SVGTransformList/
Succeeded: s/stop developing/not develop/
Succeeded: s/do it will/define a color palette with/
Succeeded: s/wouldn't work with CSS/you couldn't just do this with CSS/
Succeeded: s/solid-color/solidColor/
Succeeded: s/solid-color/solid-color and solid-opacity property/
Succeeded: s/hasn't seen much use/was added to support RDFa and microda
te, but hasn't seen much use/
Succeeded: s/scannig/scanning/
WARNING: Bad s/// command: s/agree/share your concern about misuse of t
his property, but it's sometimes needed for specific devices/scenarios/
Succeeded: s/we should/would we have/
Succeeded: s/have have/have/
Succeeded: s/get/want/
Found ScribeNick: cabanier
Inferring Scribes: cabanier
Default Present: +1.206.734.aaaa, ed, cabanier, heycam, krit, cyril, Ta
v, ChrisL, [Microsoft]
Present: +1.206.734.aaaa ed cabanier heycam krit cyril Tav ChrisL [Micr
osoft]
Agenda: [33]http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMa
r/0038.html
Found Date: 26 Jan 2012
Guessing minutes URL: [34]http://www.w3.org/2012/01/26-svg-minutes.html
People with action items:

     [33] http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html
     [34] http://www.w3.org/2012/01/26-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


   End of [35]scribe.perl diagnostic output]

     [35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm