- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Thu, 17 Jan 2013 23:39:18 +0100
- To: "www-svg@w3.org" <www-svg@w3.org>
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