See also: IRC log
<trackbot> Date: 26 January 2012
<krit> Zakim: and me?
<krit> Zakim: who's here
<scribe> scribenick: cabanier
<ed> http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues
krit: I'm working on the merged css transform specification
<krit> 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: http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#SVG_DOM_issues)
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> https://wiki.mozilla.org/SVGOpenTypeFonts
heycam: let me give you a link to the bug
<heycam> 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> 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> 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 (http://www.w3.org/community/svgopentype/)
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
cyril: I will edit the wiki page
<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3CsolidColor.3E_element
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
<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#xml:id
chrisl: we should drop it
everyone: agreed
resolution: drop XML:id
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
<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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at 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 concerned about whether that means a flattened matrix, or if it's a list of matrices/ Succeeded: 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?/ 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 microdate, but hasn't seen much use/ Succeeded: s/scannig/scanning/ WARNING: Bad s/// command: s/agree/share your concern about misuse of this 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, Tav, ChrisL, [Microsoft] Present: +1.206.734.aaaa ed cabanier heycam krit cyril Tav ChrisL [Microsoft] Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0038.html Found Date: 26 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/26-svg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]