- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Mon, 06 Sep 2010 18:05:00 +0200
- To: www-svg <www-svg@w3.org>
http://www.w3.org/2010/09/06-svg-minutes.html [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 06 Sep 2010 See also: [2]IRC log [2] http://www.w3.org/2010/09/06-svg-irc Attendees Present Regrets Chair SV_MEETING_CHAIR Scribe Cyril, anthony, Jonathan Watt Contents * [3]Topics 1. [4]ISSUE-2368 2. [5]CSS Transitions and Animations 3. [6]paint servers 4. [7]Demos 5. [8]Font description features 6. [9]HTML + SVG in no-HTML User Agents 7. [10]Shape path 8. [11]Path on a path 9. [12]Spiros 10. [13]2D-transforms 11. [14]Connectors 12. [15]SVG points * [16]Summary of Action Items _________________________________________________________ <trackbot> Date: 06 September 2010 ISSUE-2368 <cyril> ISSUE-2368? <trackbot> ISSUE-2368 -- Problems with grammars for numbers -- raised <trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2368 [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2368 <cyril> CC: I think the BNF grammar for points and paths has a bug <cyril> ... missing '?' after the exponent <cyril> ... and also is not correclty aligned with the <number> datatype <cyril> ... which does not allow integer followed by just a '.' without digits <cyril> ... I propose to merge the datatype definitions <cyril> ED: agreed <cyril> ACTION: Cyril to propose new wording for the spec for ISSUE-2368 [recorded in [18]http://www.w3.org/2010/09/06-svg-minutes.html#action01] <trackbot> Created ACTION-2843 - Propose new wording for the spec for ISSUE-2368 [on Cyril Concolato - due 2010-09-13]. <cyril> scribe: Cyril <scribe> scribenick: Cyril CSS Transitions and Animations ED: let's start with transitions DS: that's a higher priority ED: Mozilla implements transitions on SVG properties ... ? ... Can you do paint server animations ? gradient interpolations ? JW: WE implement animation on anything that's a CSS properties I would think ... we cannot animate attributes that are not CSS DS: we should ask the CSS WG to consider transitions to apply to attributes in SVG <ed> [19]http://dev.w3.org/csswg/css3-transitions/ [19] http://dev.w3.org/csswg/css3-transitions/ ED: there is a transition-property property, maybe there should be a transition-attribute property <ed> DS: or perhaps the transition-property should handle both attributes and properties <scribe> ACTION: Doug to contact the CSS WG about a transition-attribute property or equivalent [recorded in [20]http://www.w3.org/2010/09/06-svg-minutes.html#action02] <trackbot> Created ACTION-2844 - Contact the CSS WG about a transition-attribute property or equivalent [on Doug Schepers - due 2010-09-13]. CC: Can you start a CSS transition interactively ? ED: sort of ... ... you'd have to change the class name based on a click ... the CSS animation module spec is a bit more advanced, covers more functionnality ... we need to spell out somewhere how the CSS transition/animation model fits with the SMIL sandwich model <scribe> ACTION: Erik to see what implementations are doing with regards to CSS transitions and SMIL sandwich models [recorded in [21]http://www.w3.org/2010/09/06-svg-minutes.html#action03] <trackbot> Created ACTION-2845 - See what implementations are doing with regards to CSS transitions and SMIL sandwich models [on Erik Dahlström - due 2010-09-13]. ED: I have examples mixing CSS animations/transitions and SMIL animations AD: we treat the CSS animation/transition as a single interval in the SMIL timing sandwich model ... when the CSS animation begins it goes on top of the sandwich CC: what about the additive behavior AD: we have to pick a default behavior for CSS animations ... probably additive CC: what happens when a property is animated on a g element with CSS and is inherited by a child element ... does it behave as if it was animated using SVG animations JW: Mozilla does not support CSS transitions of CSS gradients <ed> [22]http://dahlström.net/svg/css3/transitions/ [22] http://dahlstr/ ED: CSS transitions of CSS gradients is complex because you have to fetch gradients and do the animation properly if they have the same number of stops DS: I'm worried about the schedule of implementations ... I wouldn't be surprised if the next versions of browsers include transitions ... we need to check this issue carrefully ... but there doesn't seem to be recent editing activity ... implementations seem to be moving forward regardless of the progress of the spec on the Rec track ... so this is problematic from a coordination view point because unless the spec is updated the implementations will only match the current draft not what is the best for SVG and HTML AD: I created an ISSUE-2369 ISSUE-2369? <trackbot> ISSUE-2369 -- Define CSS3+SMIL behaviour for 'inherit' -- raised <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2369 [23] http://www.w3.org/Graphics/SVG/WG/track/issues/2369 JW: it may not be problematic for mozilla's implementation because we use a moz prefix DS: it depends on how quickly you can update that ... we should schedule an FX call on this issue ED: we need to prepare a clear agenda and material DS: we need 1) an analysis of transitions and how it should affect SVG, we need to publish that on a wiki ... 2) pointing the CSS WG to that and then make an FX call ... Who's prepared to make this analysis ... ? CC: there are 2 points: the timing issue and the inherit issue ED: I'm interested into it <scribe> ACTION: Erik to prepare a draft about the relationships between CSS transitions and SVG [recorded in [24]http://www.w3.org/2010/09/06-svg-minutes.html#action04] <trackbot> Created ACTION-2846 - Prepare a draft about the relationships between CSS transitions and SVG [on Erik Dahlström - due 2010-09-13]. DS: I don't think CSS animations is that urgent ED: I don't know well enough about it paint servers TB: we would like to see mesh gradients ... matching the PDF version so that you can export easily AD: that is a good idea ED: me too TB: we don't have a spec yet ... The litterature has 4 types of mesh gradients ... one of them is Coons patch ... the formula's in the Adobe spec AD: I see the Coons patch was formulated in 1967 ... is a great candidate for inclusion in SVG CC: VRML also has a mesh gradients, it was specified in 1997 ED: everyone agrees that it's nice to have AD: yes ... we need a draft of specification (syntax ...) <scribe> ACTION: Tav to draft report on Coons patches [recorded in [25]http://www.w3.org/2010/09/06-svg-minutes.html#action05] <trackbot> Created ACTION-2847 - Draft report on Coons patches [on Tavmjong Bah - due 2010-09-13]. DS: I always wanted to have a gradient along a path (spline interpolated gradient) ... this is a precursor for diffusion curves TB: someone wanted to have a spiral gradient AD: what is the use case ? who would use it ? AG: I see a use case for a black to white gradient along a path AD: once you have the idea for spline interpolation, you can use the whole path syntax ... you're actually talking about a gradient that is normal to the tangent of the path TB: what do you do at sharp corners AD: there are also issues when the path is self intersecting and if there are are many tangents at a given point of the path ... someone has to do some research on these aspects DS: from an authoring view point, it would be cool and useful for diffusion curves AG: Tav, did you have feedback on diffusion curves from the Inkscape community TB: not that I have seen on the mailing list, but there are other forums that I don't monitor ISSUE: Investigate gradients along a path for SVG 2 <trackbot> Created ISSUE-2370 - Investigate gradients along a path for SVG 2 ; please complete additional details at [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2370/edit . [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2370/edit AG: we are still looking at the diffusion curves and I'll have some report soon DS: CSS allows image as a paint server AD: I would like to have a video as a paint server CC: that's called texture mapping ED: currently, we could do it with a pattern but we could extend it or change it so that if a fill points to an image or video element, you basically generate that as a pattern AD: it could be using object bouding box ED: but we have to look at image or video at the native resolution DS: SVG introduced a bad designed by forcing everything that is referenced to use an element (marker, clipPath ...) ... use and symbol break this design and that's good ... those specialized element give you only the viewpoint ... but that could be defined generally AD: in XPS there is a concept of a brush ... the brush can be an image, a gradient, a video ... ... GDI works the same DS: that's a good idea ISSUE: Allow paint servers to reference images and videos <trackbot> Created ISSUE-2371 - Allow paint servers to reference images and videos ; please complete additional details at [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2371/edit . [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2371/edit TB: we also talked briefly about the hatching ... some inkscape users would be interested into that ... patterns have problems in the connecting of two patterns AD: Andreas Neumann mentionned some interesting hatching used in HP-GL ... I have open sourced an implementation of HP-GL on the web DS: is the technology royalty free AD: HP-GL is more than 20 years old ISSUE: Investigate hatching for SVG 2 <trackbot> Created ISSUE-2372 - Investigate hatching for SVG 2 ; please complete additional details at [28]http://www.w3.org/Graphics/SVG/WG/track/issues/2372/edit . [28] http://www.w3.org/Graphics/SVG/WG/track/issues/2372/edit AD: www.ishtek.com/hpgl2.htm <anthony> Scribe: anthony <scribe> ScribeNick: anthony Demos DS: Andrew Matseevesky ... showed me this demo ... during the conference I showed catmull-ron curves ... and he suggested an alternative way to do the curves ... This is a basic thing ... [Shows demo using Andrew's drawing tool] ... He calculates the control points on the spline itself AD: What's the technique? DS: Squares are the end points ... and the circles are control points CC: What order? AD: Is it putting an artificial point on a path ... looks like knots TB: The control points can't be on the path DS: Sorry, the handles are on the path ... he suggested instead of catmull-ron curves ... that you could basically break up a path into ... multiple points ... other people understood the maths ... I couldn't understand the maths ... other thing I wanted to show ... was his method of painting gradients ... first click fills the area ... second click adds colour to the original fill to create the gradient ... subsequent clicks adds a new colour ... not sure if that is approximating something ... This is sort of like a mesh gradient CL: Seems to be building one up on the fly DS: Not sure if it's interesting from an SVG point of view JW: I'm not getting it from the point of view of an author how you would predict it's behaviour AG: Particularly for animation ... you lay these things down ... then animate it ... might get an unknown result AD: Need to figure out what editors export and draw ... and support those ... things like diffusion curves are really neat but might be able to do the same things using other technologies DS: Thing is you can't have hit testing on diffusion curves because they make up a shape CL: I always thought of them as a paint server ... just seemed easier to clip ... much easier to cut out the shape than keep inside the line DS: It's a singular paint server for a single element ... mesh gradients can be applied to multiple points AG: Could use SVG point for mesh gradient <scribe> ACTION: Alex to Implement trimesh gradients using phong shading model [recorded in [29]http://www.w3.org/2010/09/06-svg-minutes.html#action06] <trackbot> Created ACTION-2848 - Implement trimesh gradients using phong shading model [on Alex Danilo - due 2010-09-13]. Font description features CL: Related to CSS3 ... how the changes between CSS effects us ... and what things you'll be able to do and not be able to do anymore and stuff ... So CSS2 had 3 things you could with fonts ... you could intelligently match on their characteristics rather than the name ... the second one was synthesis ... i.e. make me a font with certain characteristics ... the third one was download ... SVG 1 dropped the first two ... and just supported download ... CSS2.1 dropped all of them ... CCS3 makes the same choices that SVG did ... i.e. only supports download ... but does make some changes ... the way that small caps are specified ... has changed ... all the implementations faked up small caps ... CSS3 talks about platform limitations ... that need to be taken into account ... which is the weight of the fonts ... One of the Windows APIs (GDI) insist that all fonts have two weights ... instead of multiple weights ... so if you have a font with 6 weights, you will still only get two JW: Does DirectWrite support more than two weights? AD: Yes CL: Firefox has a new font engine that's currently switched off ... One of the changes in CSS3 fonts is when you write an @font-face weight, the weight gets used ... [show's demo] ... Notice that this is a font with four different weights ... and this is Windows XP CC: Viewer? CL: Firefox minefield ... this font family has the weights ... CSS says how you handle the weights ... it's allocated the weights ... that's using @font-face ... so using the fonts used on my system ... only get two weights ... instead of four ... so we should align with this ... exactly and completely DS: To that end, should we simply reference that? CL: We have an XML syntax ... but we could do some sort of normative reference ... Straight into stylistic sets now ... same font with same text ... have different style types on the letters ... it's an OpenType feature ... still searchable ... still the same text ... and the fall back is the same line ... this is discretionary ligatures ... here is one where there are small letters tucked into other letters ... Swash forms ... when it has more space it does different swash ... the fall back is again the top line CC: What is the syntax? CL: Syntax is currently under discussion in the CSS Working Group at the moment TB: Mozilla supports ligatures? CL: Yes TB: Inkscape puts the ligatures in, but they don't come up JW: We should look into that DS: Could be a bug. I know cases where ligatures disappear when you put them on a path. Even on straight path CL: My proposal is we align completely with what CSS3 Fonts says ... I'd be prepared to do any editing work necessary DS: This is for SVG 2 or 1.1? CL: Just SVG 2 AG: I'm happy with it AD: Ok, makes sense DS: ooo and ahhhhh ... Enthusiastic agreement RESOLUTION: We agree that in SVG 2 we will completely align with CSS 3 Fonts HTML + SVG in no-HTML User Agents DS: There are three basic ideas: ... one is SVG shouldn't have text wrapping ... second position should have basic word wrapping ... third is SVG should not rely on HTML to do any word wrapping CL: The second point could be broken up ... it was more about the formatting ... rather than the markup JW: Might be time to rethink the box model ... need be able to handle shapes that are not box model ... need to talk to people in Mozilla AD: One thing is need to think about the pure SVG world ... such as IPTV ... where they want wrapping ... but they don't want to pull in another names space CL: We had wrapping text in a shape, but we couldn't do two paragraphs ... it was basically, here's some text, here's a shape and fit it DS: If we want deeply structured text ... there should be some HTML involved here ... paragraphs, tables ... should be able to pull in a subset CL: Couldn't restrict it AD: All you're doing is replacing invisible GIF with the ability to fill text into a shape ... that's the join that is the most useful from a design point of view DS: From a specification point of we shouldn't limit HTML ... but from best practices point of view CL: I see two classes of UAs ... Pure SVG UAs and one that knows about HTML and other standards ... I'm not seeing a third class ... that can do SVG and bits of other things DS: Do we have to assume that all aspects of the box model will apply AD: The only reason we never went with it ... was we could never solved the margin problem ... so those problems were two hard to solve with complex shapes ... which is why we said drop margins ... and we said if you're using an odd polygon, don't use padding and margins ... we thought about stand alone SVG ... the work should be revisited ... in light of SVG being in HTML ... bringing complex wrapping to SVG, offered things that other standards couldn't ... we were address use cases where the shape was not a box DS: This comes back to a concern that TB had ... we're talking about aligning more closely with HTML ... and this is great for some UAs ... but a problem with other UAs ... we need to be careful that we don't abandon pure SVG UAs ... TextArea was poorly named ... I would suggest we break here with SVG Tiny 1.2 on this scribe: I suggest we have a mechanism, where we have something called a text shape ... you would reference a shape and say wrap to this shape AD: So we have clipPath ... so we can reference textShape JW: Putting aside SVG only UAs ... the sensible thing to do is the ability in HTML to reference an SVG ... the whole flowing concept wouldn't exist in SVG ... it would exist in HTML ... the shape comes from SVG ED: That would be useful in SVG as well JW: In SVG you have a coordinate system AD: Unless you have an anonymous block ... it has it's own coordinate system that moves inside the block JW: Taking an SVG element that's implicit DS: You're suggesting that the syntax is like flow-shape ... as property ... that you apply ... I think that it should take multiple values ... a comma separated list of shapes AD: You'd have to address what happens when you the shapes fill up ... we've addressed what happens when you have donut shapes and self intersecting paths <tbah> [30]http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Text-Flow.html [30] http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Text-Flow.html JW: Cameron looked into flow stuff at some length CL: As part of constraints TB: Inkscape implemented this SVG Full 1.2 feature ... Inkscape still exports this CL: Batik implemented this DS: Here is one suggestion for Inkscape. If we did this type of text flow, it would be very easy to take old Inkscape content ... and convert it to this sytnax ... that would work ... CSS WG and XSL-FO WG are already interested in this ... we could tell them that we are considering a property AD: Would be nice to have use case and requirements ... I can see so much merit in saying, here's a complex polygon and fill it with your HTML content ... so image and tables would be treated as rectangular blocks ... and if they look really tiny, they look really tiny JW: And you could say how much overlap and colouring outside the lines you could do DS: People shouldn't wrap images and iFrames AD: Need to keep it simple ... not everyone has access to optical kerning for example <jwatt> AD: a lot of the problems were worked out in the now retired SVG 1.2 Full draft [31]http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html [31] http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html <scribe> ACTION: Doug to Start a write up page on shape-flow-container-galley property [recorded in [32]http://www.w3.org/2010/09/06-svg-minutes.html#action07] <trackbot> Created ACTION-2849 - Start a write up page on shape-flow-container-galley property [on Doug Schepers - due 2010-09-13]. AD: What do you do with the HTML if you're just in SVG ... So the text between the tags is shown in HTML but not show in SVG ... what does SVG do with the mixed content DS: Would a solution about the text container flow discussion ... that we have a property that can be applied to SVG or HTML content ... which passes the id of one or more shapes ... to which the text is wrapped TB: As long as you have the SVG text there covered ... then that's fine DS: It would be easy for people to author in Inskcape and hand code the HTML that they wanted to use CC: I think this would work, but with a small note ... when you're doing Tiny on embedded platforms ... the computation might be too hard AD: I've done the flow text for any platform ... it's not very expensive at all CC: I think it's a nice trick DS: Do we take into account stroke? AD: Have to decide, might find it harder to do it to the stroke ... Going to back to my question about what happens to unrecognised content DS: So I did up this test <shepazu> <svg xmlns="[33]http://www.w3.org/2000/svg"> [33] http://www.w3.org/2000/svg <shepazu> <circle id="circle_1" cx="75" cy="25" r="20" fill="orange" stroke="red" /> <shepazu> <foo stroke="green"> <shepazu> <rect id="rect_1" x="75" y="25" width="40" height="40" fill="lime" /> <shepazu> </foo> <shepazu> <ellipse id="ellipse_1" cx="115" cy="65" rx="25" ry="12" fill="indigo" stroke="indigo"/> <shepazu> </svg> DS: Most user agents do not render the rectangle ... Firefox does render the rectangle AD: I actually prefer your behaviour DS: And so do I ... for an extensibility mechanism ... for elements not in the SVG name space ... they essentially act as groups ... in the SVG name space ... but if you do understand the element you render ... as it suppose to be AD: This is useful for the case in geo mapping ... where the is a global geo transform ... currently they have to make it a sibling of the SVG to make it work ... and do these horrible hacks for it work ... where as if it were a parent ... wouldn't have to do these hacks JW: Seems like you could get bitten doing this DS: From an accessibility point of view ... if you had a connector and it had a child path ... if the UA didn't understand connector ... you'd still get the path nested inside the connector ... so a UA like inkscape could output connector for example ... and it would work in firefox AD: Rather than using meta data in inkscape ... where groups are overloaded as layers ... could have a <layer> and it would just work ED: opera cuts off subtrees that are rooted by unknown elements (in both svg and other namespaces) ... more efficient than walking the tree to find something you understand DS: So things not in the SVG name space it is ignored ED: It's not going to work in the deployed UAs but it's a nice idea ... This kind of proposal will work fine DS: Inkscape will not have to change CC: What about text ... what if you had a <foo> with text content inside and this <foo> is child of <text> ED: So it's an unknown text element AD: Just decide if it is displayed or not ED: Have you tried that test? AG: So is this going to work for pure SVG UAs only? ... or this is not going to apply to UAs that understand HTML + SVG DS: The element might be put in the HTML namespace ... shouldn't cause any problems but wouldn't be ideal ED: I think it would take someone to write a proposal first ... from this discussion it doesn't seem too hard DS: I could write something up in integration ... right now in SVG 1.1 it says to "ignore" them and doesn't define what "ignore" means ... SVG Tiny 1.2 "ignore" is defined AD: Don't think it'd be a problem ... most of it is done as controlled deployment space <scribe> ACTION: Doug to Add the idea of processing children of unknown elements in the SVG namespaces to the integration specification [recorded in [34]http://www.w3.org/2010/09/06-svg-minutes.html#action08] <trackbot> Created ACTION-2850 - Add the idea of processing children of unknown elements in the SVG namespaces to the integration specification [on Doug Schepers - due 2010-09-13]. Shape path <ChrisL> OT [35]http://www.w3.org/2010/09/SVGmeetup-Paris.html [35] http://www.w3.org/2010/09/SVGmeetup-Paris.html ED: Text on a path is laying out text on a path ... so putting shapes on a path is similar CL: What do you do with the varying shape sizes ... and their x & y positions? ... does that mean you need a 'g' like element ... that gathers together a collection ... and puts it on a path ... if you have a container you reference the container DS: Would we create a new container? ... or would it be a property on <g>? CL: You wouldn't use an SVG for each one DS: Then there's a question of orientation of a marker ... do you honour the x & y, the cx & cy CL: The x & y would be ignored AD: What's the use case? DS: The people who have already been doing this with fonts <ChrisL> avoiding misusing text (text on a path) for decorative shapes DS: if you wanted to have a pattern along a line ... might be a good substitute for markers AD: Cartographers might like this CL: For markers you want to give an explicit x & y position ED: If there was an implementation that did full SVG fonts you'd already do that ... but it's not the right way to do it DS: Next step is to draw the use case and requirements CL: It's shapes repeated along a path DS: We hadn't decided if this was for laying out existing shapes or creating a pattern AG: Maybe that's what the x & y of a shape mean ... it's an offset from the tangent and the normal AD: You need a positioning mechanism DS: I think we need to go to a use case and requirements document ... this is different to shape path ... because it didn't have repetition ... if you were doing a train or a train track you wouldn't want all these elements in the DOM ... maybe it's a pattern in that sense CL: Who's pushing for this and who is going to write it up? DS: I expect the Mapping Taskforce ED: I think that's a good starting point <scribe> ACTION: Doug to Talk to Andreas about shapes on path and stroke patterns about drawing up use case and requirements [recorded in [36]http://www.w3.org/2010/09/06-svg-minutes.html#action09] <trackbot> Created ACTION-2851 - Talk to Andreas about shapes on path and stroke patterns about drawing up use case and requirements [on Doug Schepers - due 2010-09-13]. Path on a path TB: This is about using a path to deform an object ... this is useful for varying the stroke using a shape or a path ... [shows a demo] DS: How would it work on a syntactic level? TB: You'd define a shape ... Right now Inkscape does a whole bunch of things with live path effects CL: So if the mathematics in the deformation defined on how it works? TB: If you want the formula I can extract it <tbah> [37]http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffec ts.html [37] http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects.html ED: Would be nice to have a full description DS: Do people like the idea? CL: It's a different way to how we thought about doing variable stroke width <scribe> ACTION: Tav to Extract the maths from Inkscape for path on path and write a report [recorded in [38]http://www.w3.org/2010/09/06-svg-minutes.html#action10] <trackbot> Created ACTION-2852 - Extract the maths from Inkscape for path on path and write a report [on Tavmjong Bah - due 2010-09-13]. Spiros CL: At the type con I was talking about Spiro. I was shown code that did only one iteration until it reached a result ... but I was told that you only need three or even one iteration ... the only thing is you might get slight angles that don't match correctly ... but it's very slight ... the algorithm might be something worth considering <ChrisL> shown code/shown code by Raph Levein/ DS: I propose we do some shape that takes the same syntax as path ... but has new shape types in it <ChrisL> polycurve element. like polyline but ... curved <ChrisL> worried that path is too entrenched, cost of changing it is too high DS: that's where we'd put the catmull-ron curves as well <jwatt> scribe: Jonathan Watt <jwatt> scribenick: jwatt 2D-transforms <anthony> [39]http://dev.w3.org/cvsweb/~checkout~/Graphics-FX/modules/2D-trans forms/spec/2DTransforms.html?rev=1.1 [39] http://dev.w3.org/cvsweb/~checkout~/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html?rev=1.1 AG: I've got proposed changes marked by red (remove) and green (add) ... should "transform affect" just be "transform property" for SVG as well as CSS? CL: the default value for 'transform' in CSS is 'none" <ed> just for the comparison, here's the latest css3 2d transforms spec: [40]http://dev.w3.org/csswg/css3-2d-transforms/ [40] http://dev.w3.org/csswg/css3-2d-transforms/ CL: we would need to make clear how that interacts with transforms on parent and child elements JW: surely it would just act as the identity matrix for matrix concatenation for the purposes of working out the CTM TB: there's a lot of discussion on the cairo mailing list for adding perspective transforms to cairo AG: so what I've done is my rough pass at merging the two specs, and now we need to tidy it up DS: so this adds transform-origin ED: we talked about how transform-origin needs to be fixed for backwards compat ... in a previous telcon <ed> x[41]http://www.w3.org/2010/03/11-fx-minutes.html [41] http://www.w3.org/2010/03/11-fx-minutes.html <ed> [42]http://www.w3.org/2010/03/11-fx-minutes.html [42] http://www.w3.org/2010/03/11-fx-minutes.html <ed> [back from break] AG: I can't see minuting of a resolution for transform-origin in those minutes ED: it could have been a different telcon <ed> [43]http://www.w3.org/2010/05/17-fx-minutes.html [43] http://www.w3.org/2010/05/17-fx-minutes.html <ed> [44]http://www.w3.org/2010/05/03-fx-minutes.html [44] http://www.w3.org/2010/05/03-fx-minutes.html ED: what do we need to align with CSS 2D transforms? DS: there are some things we should have, such as transform based on an arbitrary point CL: I don't believe CSS 2D transforms allows *arbitrary* points <ChrisL> we need to add the transform-origin (including auto centre) from CSS to our attribute syntax ED: the spec should say that it applies to SVG content, and how ... and there should be an authoring note saying that if you use the new 2D transforms features it may not work as an attribute ... but I don't think we need to put the new wording in any other spec than this one ... so hopefully we can then implement and get something working quicker, without waiting for SVG 2 ... it means we get the transform-origin attribute as well CL: we're reusing the 'transform' name? ED: yes CL: I think SVG 2.0 should clearly mark what is new to make it easier for authors to decide what to use if they're concerned with backwards compat Connectors CC: connectors as Doug proposes have two parts: the semantics, and the graphical ... I would prefer to have a path element with connecting semantics on it ... if you need to change the drawing when two points move, I'd prefer to have a drawing operator ... so have a path that contains connector elements ... instead of having connectors with drawing semantics ... the main difference is that UAs that don't understand connectors would still draw the path, at least initially ... if the points need to move then it wouldn't be fixed up automatically of course DS: I think that's a reasonable syntax ... I've suggest a connector with a path fallback instead CL: put in an editorial comment explaining the alternative and the pros and cons of each resolution: publish connectors spec with alternative proposal DS: I'm also going to publish a usecases and requirements spec ... it's not ready for first public working draft yet ... we don't want comments yet until we've progressed it further ourselves SVG points TB: what is the orientation? ... can we have that as a property? DS: x-axis <ChrisL> rotations of the marker would be about that point. need syntax for that? or does 'auto' cover it already? DS: there's a general question of orientation around a point ... markers are one ... text are another ... you may want it to be independent of transform ... or dependent on the orientation of the device AD: depending on orientation of the device could go wrong ... things could end up crossing in weird ways ... probably you want script rather than magic auto reorientation ... I wonder about the usability from an authoring perspective DS: you can always do it using script if you don't want the auto behavior resolution: add SVG point to the connectors spec, to possibly be moved later <scribe> ACTION: Doug to spec out SVG point [recorded in [45]http://www.w3.org/2010/09/06-svg-minutes.html#action11] <trackbot> Created ACTION-2853 - Spec out SVG point [on Doug Schepers - due 2010-09-13]. <anthony> We are concluded for the day <ChrisL> adjourned trackbot: end telcon Summary of Action Items [NEW] ACTION: Alex to Implement trimesh gradients using phong shading model [recorded in [46]http://www.w3.org/2010/09/06-svg-minutes.html#action06] [NEW] ACTION: Cyril to propose new wording for the spec for ISSUE-2368 [recorded in [47]http://www.w3.org/2010/09/06-svg-minutes.html#action01] [NEW] ACTION: Doug to Add the idea of processing children of unknown elements in the SVG namespaces to the integration specification [recorded in [48]http://www.w3.org/2010/09/06-svg-minutes.html#action08] [NEW] ACTION: Doug to contact the CSS WG about a transition-attribute property or equivalent [recorded in [49]http://www.w3.org/2010/09/06-svg-minutes.html#action02] [NEW] ACTION: Doug to spec out SVG point [recorded in [50]http://www.w3.org/2010/09/06-svg-minutes.html#action11] [NEW] ACTION: Doug to Start a write up page on shape-flow-container-galley property [recorded in [51]http://www.w3.org/2010/09/06-svg-minutes.html#action07] [NEW] ACTION: Doug to Talk to Andreas about shapes on path and stroke patterns about drawing up use case and requirements [recorded in [52]http://www.w3.org/2010/09/06-svg-minutes.html#action09] [NEW] ACTION: Erik to prepare a draft about the relationships between CSS transitions and SVG [recorded in [53]http://www.w3.org/2010/09/06-svg-minutes.html#action04] [NEW] ACTION: Erik to see what implementations are doing with regards to CSS transitions and SMIL sandwich models [recorded in [54]http://www.w3.org/2010/09/06-svg-minutes.html#action03] [NEW] ACTION: Tav to draft report on Coons patches [recorded in [55]http://www.w3.org/2010/09/06-svg-minutes.html#action05] [NEW] ACTION: Tav to Extract the maths from Inkscape for path on path and write a report [recorded in [56]http://www.w3.org/2010/09/06-svg-minutes.html#action10] [End of minutes] _________________________________________________________ Minutes formatted by David Booth's [57]scribe.perl version 1.135 ([58]CVS log) $Date: 2010/09/06 16:01:07 $ _________________________________________________________ [57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [58] http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at [59]http://dev.w3.org/cvsweb/~checkout~/2002 /scribe/ [59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/CSS properties/CSS properties I would think/ Succeeded: s/support animations of gradients/support CSS transitions of CSS gradients/ Succeeded: s/there is no active editor/there doesn't seem to be recent editing activity/ Succeeded: s/PDF/The litterature/ Succeeded: s/this aspects/these aspects/ Succeeded: s/shap/shape/ Succeeded: s/APIs/APIs (GDI)/ Succeeded: s/arrrr/ahhhhh/ Succeeded: s/srapping/wrapping/ Succeeded: s/We tried to walk into subtrees we don't understand/opera c uts off subtrees that are rooted by unknown elements (in both svg and o ther namespaces)/ Succeeded: s/did an/did only one/ Succeeded: s/list far/list for/ Succeeded: s/minuting of/minuting of a resolution for/ Succeeded: s/orientation/orientation of a marker/ Found Scribe: Cyril Inferring ScribeNick: cyril Found ScribeNick: Cyril Found Scribe: anthony Inferring ScribeNick: anthony Found ScribeNick: anthony Found Scribe: Jonathan Watt Found ScribeNick: jwatt Scribes: Cyril, anthony, Jonathan Watt ScribeNicks: cyril, anthony, jwatt WARNING: No "Present: ... " found! Possibly Present: AD AG CC CL ChrisL DS ISSUE JW TB anthony cyril cyril _ ed joined jwatt left scribenick shepazu svg tbah trackbot xhttp You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Sep 2010 Guessing minutes URL: [60]http://www.w3.org/2010/09/06-svg-minutes.html People with action items: alex cyril doug erik tav [60] http://www.w3.org/2010/09/06-svg-minutes.html End of [61]scribe.perl diagnostic output] [61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 6 September 2010 16:05:28 UTC