SVG Working Group Teleconference -- 06 Sep 2010

<trackbot> Date: 06 September 2010

ISSUE-2368

<cyril> ISSUE-2368?

<trackbot> ISSUE-2368 -- Problems with grammars for numbers -- raised

<trackbot> 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 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> 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 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 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> http://dahlström.net/svg/css3/transitions/

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> 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 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 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 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 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 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 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> 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 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 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

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 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 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 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> 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 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> 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: 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> xhttp://www.w3.org/2010/03/11-fx-minutes.html

<ed> 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> http://www.w3.org/2010/05/17-fx-minutes.html

<ed> 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 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

- DRAFT -

SVG Working Group Teleconference

06 Sep 2010

Attendees

Contents