See also: IRC log
<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
<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
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
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
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
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
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
<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
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]