Minutes 17 january 2013 SVG WG Telcon

http://www.w3.org/2013/01/17-svg-minutes.html

and in plain text here:



W3C
- DRAFT -
SVG Working Group Teleconference
17 Jan 2013

Agenda

See also: IRC log
Attendees

Present
Regrets
Chair
     Cameron
Scribe
     Cyril

Contents

     Topics
         Combining SVGLocatableElement and SVGTransformableElement in SVG 2
         Should SVGTextContentElement inherit from SVGGraphicsElement or 
SVGGeometryElement?
         Should SVGClipPathElement inherit from SVGElement?
         Percentage values for basic shapes on 'clip-path' relative to 
objectBoundingBox or strokeRect
         Review request of CSS Masking spec before going to LC
         text-shadow on <text>, <tspan>, <tref>, etc.
         getStrokeBBox behaviour and naming
     Summary of Action Items

<trackbot> Date: 17 January 2013

<scribe> scribe: Cyril

<scribe> scribeNick: Cyril

heycam: F2F is coming up
... bring your agenda requests for the week

<birtles> 
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013/Agenda_proposals

<richardschwerdtfeger> need to add an agenda item on applying aria 
attributes to attribute reference.

cyril: alex said there is no special rate with the hotel indicated on 
the wiki page

brian: have we decided which half-day will be off

heycam: I imagine we will be working in the morning and the afternoon is off
Combining SVGLocatableElement and SVGTransformableElement in SVG 2

<heycam> 
https://docs.google.com/drawings/d/1DjmqGOk71JATh5ysZtnFe0Nxvox-g6mZ-M02jLA9aOc/edit?pli=1

dirk: left side is SVG 1.1 inheritance tree and right one is SVG 2
... the circle shows that SVG 2 has the locatable only has transformable 
as child

heycam: in SVG 1.1 the SVGElement was locatable but not transformable
... we changed that in sVG 2 so that you could put transform on it
... so there is no longer a concrete element that inherits just from 
locatable element
... I'm fine with combining those 2
... we have someone at mozilla converting SVG interfaces to WebIDL

<pdr> [not on call] for implementation reasons, the presentation editor 
uses paths for text

heycam: is there any concern in combining these 2 interfaces ?

cyril: what's the benefit ?

heycam: one less prototype object to go up when you look at properties

dirk: simplifies implementation also
... you would combine them anyway in a implementation

ed: I agree it would be simpler

heycam: ok hearing no objection

resolution: SVG 2 will combine the SVGLocatable and SVGTransformable 
interfaces
Should SVGTextContentElement inherit from SVGGraphicsElement or 
SVGGeometryElement?

heycam: graphics is for things that render, in the normal rendering 
tree, that includes g, shapes and images ...
... geometry is for elements that define a shape
... we've added some DOM methods on SVG Geometry elements to determine 
if the click is inside the fill or the stroke
... my thinking is that it make sense to call that on geometry elements, 
including text
... to see if the click is in the glyph or not

dirk: the font rendering is out of the rendering system in WebKit, due 
to Core Graphics restriction
... to emulate that that would make it very slow

heycam: there is no other functionality in SVG that require to have 
access to the glyph ?

dirk: I would be unhappy to block the feature but some port of WebKit 
(Safari) would not support that
... you don't get the details of the glyph

heycam: I'll be ok with having SVG Text elements inherit from SVG 
graphical elements

ed: how is it different from pointer events handling on text ?

dirk: this is not implemented that way on Safari
... right now you just get the bounding box

heycam: right, the spec does not require you to get the acual shape of 
the glyph for pointer events

ed: that's right, it's only the character cell according to the spec
... in that case, that's fine not to have those additional methods for text

dirk: I would be ok with having a note saying that they might apply on 
text in the future
... we could also formulate it with a "should"
... that would allow implementation that can't do it to do something 
different

heycam: it might make the methods not useful if you can't rely on them
... I am ok with having them on shapes at the moment

resolution: SVG text elements will inherit from graphical elements
... and ispointonfill or ispointonstroke won't be called on text
Should SVGClipPathElement inherit from SVGElement?

dirk: right now SVG clip path element inherits from SVGTransformable 
element to allow the transform attribute
... the problem is that SVG Transformable Element inherits from SVG 
Locatable element
... which allows methods like getScreenCTM on clipPath elements but 
that's not the case for gradients, ...
... why is it the case for clipPaths ?

heycam: my guess is that the clipPath transform attribute is just called 
transform
... but mask isn't transformable
... gradients have gradientTransform not the standard transform attribute
... it's a bit weird to call getScreenCTM on the clipPAth because the 
transform on the parent of the clipPath don't matter
... does it make sense to call getBBox on the clipPath

dirk: no it doesn't make sense

ed: yes it's a bit strange
... on the one hand it's like a g (a container) but it's also linked to 
where it is used

heycam: what else is on SVGLocatable ?

<heycam> 
https://svgwg.org/svg2-draft/types.html#InterfaceSVGLocatableElement

heycam: Bounding box, CTM, transform
... all these methods only make sense on elements that exist in their 
parent coordinate space
... I would be alright with having clipPath elements inherit from SVGElement

<heycam> 
https://svgwg.org/svg2-draft/types.html#InterfaceSVGTransformableElement

<heycam> still need to have that one IDL attribute on SVGClipPathElement

<heycam> which gives DOM access to transform=""

heycam: we are keeping the ability to have the transform attribute on 
the clipPath element
... we could just copy the transform attribute on the element that use it
... is everybody happy not to have the locatable thing?

resolution: SVG 2 will make SVGClipPathElement inherit from SVGElement 
and give it its own IDL attribute to access the transform
Percentage values for basic shapes on 'clip-path' relative to 
objectBoundingBox or strokeRect

heycam: are they relative to the object bounding box or the stroke rect

<krit> 
https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-clip-path

dirk: we have the new short-hand for clip paths

rect, circle, ellipse ...

but they take % values

scribe: do they get resolved according to the stroke or object
... at the previous F2F we were not sure
... we did not decide

heycam: currently Webkit is relative to the object bounding box

dirk: right

heycam: it would be a bit strange to have some new bounding box 
rectangles just for this clipPath property because we don't have it on 
other elements
... maybe it would be useful on other elements

dirk: we could add a property in the future to indicate which bounding 
box you use
... in the next level

heycam: when you don't use %, are they user space length

dirk: lenght of 0 is 0px which is different from 0% ?

heycam: I think this way is probably the way we should have done from 
the beginning

<krit> <rect x="20" y="20" widyh="200" height="200"/>

dirk: 0% 0% is resolved to 20px 20px
... but 0 0 is resolved to 0px 0px

heycam: I'll be ok with deferring to the next level the control to which 
bounding box it's relative to

ed: yes that would make sense to have the control in CSS

dirk: CSS has something like that for boxes but they are not applicable 
to SVG (

heycam: but it's not the same property

<ed> I meant for e.g clipPathUnits, that we could have 
clipPathUnits="strokedBoundingBox"

<ed> and that there would be something reflected in CSS

heycam: I would say at this level it's objectBoundingBox because that's 
the only one we have in SVG

dirk: clipPathUnits can just be applied on the clipPath element, not on 
the property

heycam: disagreement ?

resolution: the shape in the clip-path property will have percentages 
resolved against the object bounding box

<heycam> background-clip

heycam: what is the default box used for percentages resolution in 
background-clip

<krit> 
https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-clip

<heycam> https://developer.mozilla.org/en-US/docs/CSS/background-clip

dirk: the border box, which is the same as the layout box which is the 
same as the stroke
... it should be the painting box but it's not yet define
... the exclusion specification uses the border box
... it might make sense to have the stroke box for compatibility reasons

<cabanier> * I think it's just you :-) *

tav: it is possible to have the masking behavior changed

<krit> krit: We could modify the UA style sheet to use content-box on SVG

tav: that would make sense to me

<krit> krit: Then the default value on mask-clip does not need to change

heycam: that would still lead to some inconsistentcies

dirk: what do you think is less inconsistent

heycam: maybe to have clippath default to including the stroke
... we could add a new value in the units attribute

<heycam> I am happy with clip-path defaulting to stroke bounding box if 
we add strokeBoundingBox or similar values to maskContentUnits="", 
gradientUnits="" etc.

<heycam> so that there is not a new bounding box that clip-path uses 
that all our other definition elements can't use.

<heycam> Then clip-path's default matches the default of mask-clip, 
background-clip, etc.

tav: it's strange in SVG that the clipPath changes if you change the 
stroke width
... changing the style shouldn't change what's being clipped

dirk: I think I agree with tav

heycam: yes, changing any style does not change now the clipping, but it 
could be useful, if it's not the default

tav: useful, but that's not what I would naturally expect

heycam: any concern with the consistency of other property

tav: I have to think about it

heycam: I'm not that unhappy to have it be objectBoundingBox
... I think it's probably ok
... dirk, you have it implemented, did you try with some content

tav: how would you handle different kinds of line join

dirk: we rely on the graphics library to get the bounding box
... this is not done by WebKit

ed: objectBoundingBox is not affected by the line join right?

dirk: no, strokeBoundingBox is

heycam: yes, maybe strokeBoundingBox needs more thoughts
Review request of CSS Masking spec before going to LC

dirk: I asked the same request in the CSS WG
... it would be great to have review early
... the review I had from CSS was that the spec should rely on the 
background spec as much as possible
... I will rewrite the spec
... and get feedback from the group, for instance during the F2F

heycam: when do you want to get it to LC

dirk: when the review is finished
text-shadow on <text>, <tspan>, <tref>, etc.

heycam: dirk said text-shadow should apply to text

dirk: I think text-decoration should apply to text

<krit> http://www.w3.org/TR/css-text-decor-3/

tav: SVG has different colors

<heycam> http://dev.w3.org/csswg/css-text-decor-3/

tav: how does that this apply
... I agree it's better to have unification
... I don't know if there is a problem with text-decoration

heycam: I think we should have the same rules as HTML elements

<Tav> http://www.w3.org/Graphics/SVG/Test/20110816/svg/text-deco-01-b.svg

dirk: we already use these properties
... it's really a matter of normative reference

tav: and it handles the variation of colors

dirk: we already have stroke and fill on HTML text

tav: text-shadow does it apply to text-decoration ?

dirk: good question, CSS WG is still discussing it

ed: how text-decorations affect the boundingbox is not defined yet

tav: I would expect that the shadow apply on the decoration

heycam: I like the idea of text-shadow applying to SVG text in general

resolution: in SVG 2, text-shadow will apply to svg text
getStrokeBBox behaviour and naming

<heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0057.html

heycam: we have getStrokeBBox in the DOM, the definition is slightly off 
in the text
... it include the stroke in the marker but not the fill which is a bit 
strange
... but the real issue is the name 'stroke' if it includes the marker as 
well

<heycam> getBBox({ fill: true, stroke: false, markers: true })

heycam: the dictionnary BBoxOption means that you can pass an object

dirk: if you put two values to true, then you would get the union of both

heycam: yess

dirk explaining an example of the strokebbox being smaller than the fillbox

with the use of dashes not present at corners

tav: dashes should not matter for the bbox

dirk: I think the style doesn't matter on the stroke box

tav: what's useful is having the 3 options and having them additive

heycam: perhaps three different methods
Summary of Action Items
[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-01-17 22:37:15 $
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/which day will be half a day/which half-day will be off/
Succeeded: s/heycam:/dirk:/
Succeeded: s/it's a bit/it's a bit weird/
Succeeded: s/ not very well defined yet/how text-decorations affect the 
boundingbox is not defined yet/
Found Scribe: Cyril
Inferring ScribeNick: Cyril
Found ScribeNick: Cyril

WARNING: No "Present: ... " found!
Possibly Present: Cyril IPcaller Rich aaaa birtles brian cabanier dirk 
ed glenn heycam https joined krit nikos pdr plinss richardschwerdtfeger 
scribeNick shepazu stearns svg tav thorton trackbot
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Agenda: 
http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0015.html
Found Date: 17 Jan 2013
Guessing minutes URL: http://www.w3.org/2013/01/17-svg-minutes.html
People with action items:

[End of scribe.perl diagnostic output]

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/

Received on Thursday, 17 January 2013 22:39:40 UTC