See also: IRC log
<trackbot> Date: 06 September 2010
<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
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
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
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].
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
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
<shepazu> <svg xmlns="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 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].
<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].
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].
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
<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
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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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 cuts off subtrees that are rooted by unknown elements (in both svg and other 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: http://www.w3.org/2010/09/06-svg-minutes.html People with action items: alex cyril doug erik tav[End of scribe.perl diagnostic output]