See also: IRC log
<trackbot> Date: 30 September 2009
<ChrisL> scribenick: chrisl
(cam draws on whiteboard)
cm: to be published soon
1.1se, integration, color, filters
a bit later - transforms, compositing, vector effects
cm: need to find out status on
mae and pin to clip
... params
... fonts on back burner for now, point to 1.1se
ds: no recent changes to
params
... ds: pinned clip is miniscule, should be folded into
something else
... (explains pinned clip for video)
ag: should go in clipping and masking
cm: do they participate in
compositing?
... layout, no recent change but doing some prototyping
software, kind of like spings and flexbox
ag: want to take stuff out of the
normal painters flow for transforms
... by default its painters
cl: 3d transformed stuff is taken
into a different tendering pass
... same as z-order actually
<shepazu> Pinned Clip spec -> http://dev.w3.org/SVG/modules/pinnedclip/publish/SVGpinnedClip.html
cl: also the result of the main
render pass has to be held as rgba since z-order passes could
be behind as well as in front of it
... same mechanism could do z-order and 3d transform
ag: think of a preserve-3d attribute that says when to pull it out of ther main flow
cm: (draws example on board with interleaved z index)
ds: andrew emmons had a ssystem
which only allows z to be set on groups
... layered g only allowed reordering within that group
... dont want to allow arbitrary setting of z throughout the
document
cm: (tries to understand css stacking context. fails)
cl: (tries to explain it. fails)
z-index: no one understands me!
<shepazu> z-index: (tries to be consistent. fails)
zaki, mute z-index
ds: there is an accessibility
interest here. for well structured documents, if we allow
people to mix then grouping all labels and all objects does not
work
... so putting all the text labels, one level up
... logical order vs. rendering order
cm: html docs have reasing order
and rendering order tightly coupled
... not the same in svg due to rendering and transforms,
grouping is different
ag: so how would transforms affect z-index
ds: want to talk about the connector element, i have an early proposal
cm: z-index is an ordering, not an absolute distance
ds: good to talk to emmons on layerd-g vs z-index. constrained and performant solution
cm: when you get the z index you
store them and then work from lowest to highest index
... and keep track of which z index are not used or are
empty
ag: will fold this into the transforms spec, helps with describing the rendering model
ds: suppose it was called z-transform
<heycam> cm: z-index is different in that it just changes layering of rendering, while the z-transform would place it somewhere in z space
<heycam> ... and thus become larger or smaller
<heycam> ... so i think they're pretty much orthogonal
<heycam> ... i would specify z-index as part of the rendering model in the base svg spec
<heycam> ... the 3d transforms spec wouldn't need to worry about it then
ds: lets not use css z-index
cl: and if ours has a different name, we also need to explain why z-index was not applicable to our rendering model
ds: explain exactly how it
differs
... that way, they search o=for z-index and find z-layer
cm: who will write up the proposal
<scribe> ACTION: anthony to work with chris to write up a z-layer and 3d transform tendering proposal [recorded in http://www.w3.org/2009/09/30-svg-minutes.html#action01]
<trackbot> Created ACTION-2678 - Work with chris to write up a z-layer and 3d transform tendering proposal [on Anthony Grasso - due 2009-10-07].
ag: should we match up our names to the css names? theirs have changed
cm: css wg did not seem willing to change theirs
ag: happy to keep svg transforms moving forward
cm: their perspective tx could occur multiple times which was odd
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
DS: last i remember anthony was
going to write up a description of why our 3d matrix transforms
have only 12 values and the css one has 16
... and about the compatibility with OpenVG
AG: to use theirs with openvg you'd need to do a bit more work
DS: is it a case where we have to
choose to be compatible with openvg or opengl?
... and if so, and there's an easy translation from one to the
other, is there really any incompatibility at all?
... and if there is, which one should we go with?
... it's obvious why they went with opengl, because of the
hardware
... which one is a more compelling target in terms of market
penetration?
... if we can only pick one or the other
... or is it easy to translate from one to the other?
AG: in the editor's draft that was updated a while ago i did put the equations that go from the 3x4 matrix to the 3x3, to pass to openvg
CM: and the extra three values from the 3x4 matrix just encode the perspective transform, which is supplied to openvg outside of the regular transform pipeline, right?
AG: right
... openvg is a 2d renderer, opengl is a 3d renderer
... so in one you need to preserve z information, in the other
you don't
DS: so compatibility with opengl is the one we should go for?
CM: but you can't do as many
strange transformations, right?
... if you just stay with the 3x4 one?
AG: i want to know what the use
cases are for multiple perspective points
... the also allow perspective transforms to be strung together
in the transform string, which doesn't really make sense
either
<scribe> ACTION: Anthony to write up 3d transforms for svg model vs css model [recorded in http://www.w3.org/2009/09/30-svg-minutes.html#action02]
<trackbot> Created ACTION-2679 - Write up 3d transforms for svg model vs css model [on Anthony Grasso - due 2009-10-07].
close action-2472
<trackbot> ACTION-2472 Fill in the currentTranslate/currentScale erratum to explicitly make using those attributes on inner <svg> elements undefined closed
issue-2001?
<trackbot> ISSUE-2001 -- Prose describing <font> content model does not match DTD -- CLOSED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2001
close action-2415
<trackbot> ACTION-2415 Check the Tiny 1.2 Chapter to see if there is any text in there that can be used for ISSUE-2001 closed
close action-2635
<trackbot> ACTION-2635 Add wording to both 1.1 2nd and the filters module that clarifies the usage of optional numbers for kernal unit length closed
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
ISSUE: Inheritance of properties into SVG font glyphs not liked by all
<trackbot> Created ISSUE-2298 - Inheritance of properties into SVG font glyphs not liked by all ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2298/edit .
ED: this is from the 'use' element:
<ed_> The effect of a 'use' element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the 'use' element and its attributes. The SVG DOM does not show the referenced element's contents as children of 'use' element.
<ed_> For user agents that support Styling with CSS, the conceptual deep cloning of the referenced element into a non-exposed DOM tree also copies any property values resulting from the CSS cascade ([CSS2], chapter 6) on the referenced element and its contents. CSS2 selectors can be applied to the original (i.e., referenced) elements because they are part of the formal document structure. CSS2 selectors cannot be applied to the (conceptually) cloned DOM tree because its cont
<ed_> Property inheritance, however, works as if the referenced element had been textually included as a deeply cloned child of the 'use' element. The referenced element inherits properties from the 'use' element and the 'use' element's ancestors. An instance of a referenced element does not inherit properties from the referenced element's original parents.
<ed_> http://dev.w3.org/SVG/profiles/1.1F2/publish/struct.html#UseElement
<ed_> http://dev.w3.org/SVG/profiles/1.1F2/publish/fonts.html#GlyphElement
CM: there's a lot to reword
... to avoid talking about cloning trees
CL: that's why we said
"conceptual clone"
... it's not an actual clone
JW: i agree with what roc saying
it says clone, then you're better off actually implementing it
as a clone because you'll find over time that doing it some
other way will cause problems in the future
... that's been my observation as well
ED: but i don't see why that will be, since it's a non-exposed tree
JW: sure, but you have to
synthesize cloning
... the spec says to pretend to clone, but not actually
clone
... but if you've not got an actual clone, then there's always
a risk that what you have won't behave like a clone would
... and various parts of the spec can rely on it being a
clone
ED: we want to avoid clones
JW: if you're htinking of removing the word "clone", then specify exactly how it should behave, then it would solve the issue
ED: you still have the original
subtree
... depending on how you represent the use, it's implementation
specific
... the original nodes are there, but it doens't just work, you
have to do other things like inheriting the style in
CL: if we say it's a clone, you
have to say it's a clone and then do some other stuff
... "conceptually" implies it's not exactly
JW: if the spec says it has to behave like a clone, then you'll find bugs and coming to the conclusion that it would be an actual clone
CM: perhaps it'd be better to
talk about it in terms of the element instance tree, nodes of
which then behave like the nodes they're pointing to
... because you don't actually want clone-like behaviour
... you want to essentially clone all state about the
referenced nodes, and then keep them in sync afterwards
JW: if you don't have a clone you
don't have the overhead of restyling the referenced elements
every time you paint it
... with clones you don't
ED: but with actual clones it has worse memory requirements
JW: probably restyling outweighs that
ED: i don't think that's
true
... for the glyph case, i could maybe see that it would be
better to not have the property inheritance into the shadow
tree
... for use, on the other hand, i think that helps
... it would break content if we stopped doing that
... wouldn't be hard to see what opera is doing wrt memory
usage
... e.g. creating some use elements with huge subtrees
... and see the memory usage of each
... i don't know exactly how they compare, but i'd imagine it
would be quite a difference
<scribe> ACTION: cameron send out proposal for limited prefix processing in text/html [recorded in http://www.w3.org/2009/09/30-svg-minutes.html#action03]
<trackbot> Created ACTION-2680 - Send out proposal for limited prefix processing in text/html [on Cameron McCormack - due 2009-10-07].
CL: [explains the glyph inheritance problem to dbaron]
DB: my reaction is sort of that
authors have expectations about how something called a "font"
performs
... and they expect that to get accelerated by things like
generating the bitmap for a glyph once per size
... essentially being what windows or osx does with a native
font, in terms of performance
CL: right if you make an abritrarily complex thing with lots of content then it's going to be slower
DB: even for things like this, if
you have to inherit stroke-width then it becomes a lot more
complicated
... compared to if you could convert the svg font to an
opentype font
CL: we have an optimization for
that, the d="" attribute on <glyph>
... but if you've actually gone to produce a multicoloured
glyph then it's going to be slower
DS: we understand that the
landscape has shifted since we started with svg fonts
... in ASV that was pretty much the only way you could deliver
a font for SVG content
... you would convert an otf into an svg font and use
that
... but now we're going to have WOFF, etc.
... so the kinds of use cases you're going to use svg fonts for
are different from those for woff etc.
... things such as richly styled glyphs
... so we're cool with giving people copious warnings about how
what they're doing is going to affect performance
DB: i'd almost be more comfortable talking about it as a glyph replacement mechanism instead of a font mechanism
CL: postscript type 3 fonts also
could have arbitrary power
... you got the benefits and the drawbacks of that
DS: authors should know why
they're using svg fonts, what the implications of inheritng the
style etc. are
... within that context, i don't feel that it makes sense to
limit how somebody can style/inherit from the text element into
font glyphs
... then it becomes less useful
JW: roc had a proposal for a
magic value for color, that would reference back up out to the
text element to resolve to the colour of the text referencing
the font
... so there'd be no style resolution each time you painted the
glyph
DS: that wouldn't work with existing content/UAs, but...
DB: there are ways we can optimize that we don't do now
DS: what if you wanted the stroke
to be thicker or thinner? or not there at all?
... you just wanted fill and not stroke?
... what if you wanted to change whether the stroke was rounded
on the corners or square?
... you can do that with any svg shape with 'use'
ED: i wonder how many of those
real svg fonts with arbitrary child content and what they're
using
... whether they actually use inherited property values
DS: james deering did a lot of
stuff with fonts
... around 2003
... it'd be good to talk to people who work with svg fonts to
find out uses
ED: point them to the wiki page
too
... on the IG wiki
DB: the thing that seems
difficult to me in svg fonts is how without svg fonts you have
a nice layered system with css and markup up here, and they
pass a bunch of information down to a graphics system that does
fonts and font matching
... and what fonts you want to use
... svg fonts require a back thing reverses the normal layering
of the system
CL: the reason we did that is
because the people realised that others don't have the fonts
they are using
... so they can either fall back to system fonts and break the
layout
... or convert to curves (not text any more)
... so turning into a font left it as text
... interesting use cases are also manipulating the font in the
dom
DB: one question is whether yo
udo it for eveyr paint or whether you store that
information
... andi f you're storing it, how much memory does it take
up
... and if you're doing it for every paint, then how much time
is it taking
... if we did the restyling efficiently, it probably wouldn't
be a huge problem
... i don't know how long it takes to draw an svg shape
compared to style computation
... so it's hard for me to say
DS: seems to me that most svg
content using svg fonts is not going to be dynamically chanigng
much of the svg content
... a lot of fonts people are going to be using are going to be
woff, for the average text
... there are many optimizations you could do
... not like they're going to be changing the colour of every
other glyph
DB: the amount we optimize
something depends on the amount it's going to be used
... the assumption for svg fonts is that they're not going to
be used much, so we're not going to worry about it
... so the main reason would be for acid3
... maybe this isn't the case but i wouldn't be surprised if we
did whatever subset is needed for that and then stopped
CM: which is just woff-style fonts
DB: has webkit implemented more
than that?
... given the other capabilities that are available, with
opentype or woff, it seems like the rest of the use cases would
be solved by having a mechanism for saying that a particular
part of a graphic represents a certain piece of text
... rather than a piece of text representing the fonts
... it doesn't involve going backwards through the layers of
the font system business
DS: for a system for building
fonts in a web application, being able to use an inbrowser
drawing program to draw a font
... so making the font editable is a use case
... animated fonts too, perhaps
DB: in terms of building a piece
of software to do this, do you implement that by making the
entire font matching system happen outside the graphics
layer?
... so you don't need this layering violation?
... basically all of the features become harder when you're
expecting it to be drawn at this weird time when you don't have
the change to store the information
DS: i think it'd help us to have a diagram explaining how mozilla currently works, wrt this layering feedback
DB: it's changed substantially in the last couple of releases, and it's going to change more
DS: it'd be nice to understand the constraints under which we are working
DB: roc's probably a better person to talk to about this
JW: the other thing i wanted to
talk about, related, is the 'use' element
... in mozilla we create an anonymous clone
... which is not how some other implementations do it
DB: there is stuff we could do to
make the clone restyling faster
... the style rule matching for rule aiui is that they inherit
from something different
... we could make it skip running selector matching
JW: it seems like you were saying that it shouldn't
DB: usemaps in html have similar
issues in mozilla
... came up with a neat solution, which i think found it's way
into html5
... where we do use one property on the area elements
... and that property is 'cursor'
... so we do the same thing that svg does with inheritance, for
the cursor property, into imgmap areas
... so you can style the cursor on the area and you can style
it on the img
... but that's relatively easy to implement, we can resolve
style whenever we need it
... we can even do that for every mouse movement -- it's just
one style property resolution
JW: but you're saying it how opera's implement would be a lot harder
DB: maybe
... right now we have this "multiple presentaitons" thing
... we sort of don't have a mapping from content nodes to
frames (i.e., rendering objects)
... except we do, stuck off into a hash table
... so you need it per use mapping instead of per presentation
mapping
... and stuffing pointers in the content elements
CM: could you specialise for just use?
DB: what you need is per use, not per presentation
[more talking about mozilla's internal style resolution]
scribe: our style data
computation happens using what i've sometimes heard as a
"lexicographic tree'< but not sure that's the right
term
... optimizes strongly for a bunch of cases that are common in
css
... i.e. relatively few properties are specified per rule
... so a css rule is in the abstract something that provides
values for some small set of properties
... the thing that maintains the style data for an element we
call a StyleContext
... there's this additional object in between them in the rule
tree
... a node in the rule tree represents the sequence of rules
the element matches
... each style context points to a node in the tree
... the path from the root of the tree to the node represents
the rules that style context matches
... in cascading order, where each node points to a single
rule
... then, beyond that, we group all the css properties into a
bunch of structs
... we do a related group of properties at a time
... so e.g. all the ones in the font shorthand are in a single
group
... then the structs can end up getting cached in the rule tree
or in the style context tree
... if the values in the struct have no dependencies on
inherited values, they can be cached in the rule tree
... e.g. no em units, no inheritance, etc.
... in the property groups, every group consists of all
inherited or all non-inherited properties
... in the case of "nothing specified", the structs of
non-inherited properties will get cached in the rule tree
... and shared between nodes
... in the edge case of inherited properties, they'll get
shared between parent and child style contexts
... in both cases they use the same struct
... in the style context case, it'll copy pointers down the
tree, since inheritance can be pretty deep
... but in the rule tree case we walk up the tree every time we
need it
DS: [mentions an object oriented
css proposal]
... [nicole sullivan]
CL: if you're cloning whole trees, you can take all of their style contexts?
DB: we would make a new style
context in the clones, but point to the same rule node
... since the selector matching won't change
... so we get data sharing for many cases
CL: so the inheritance changes, since it has a new parent, which doesn't affect selcetors, but there's a ne wsource for inherited values
DB: when changing a value, we
make new style contexts
... rule nodes and style contexts are immutable
... which provides good comparison when things change
... so if an element goes into :hover, and there are :hover
selectors that might or might not match, we'll re-run selector
matching on that element and its descendant
... this was a big problem IE/5/6/7 only handled hover on
links
... when we started supporting hover on everything, other
elements would colour on hover
DS: could pageX and pageY,
offsetX and offsetY be defined usefully within svg?
... if so they should be generalised out and put in dom 3
events
<shepazu> http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface
http://www.w3.org/mid/20090830055001.GD27340@wok.mcc.id.au
ED: i don't think value should preserve the units
CM: i think you always want to rely on assigning to .value working
ED: yes
JW: i agree
ED: allowing an invalid length in the middle of a length list seems strange
CM: yeah, i'll propose something else
JW: is opera looking at ref tests?
ED: yes, looks good
... not sure about writing our own ones yet, but using the
existing ones
CM: will you provide a public harness to run the tests?
ED: i suspect so, but don't know
JW: there's a runner, written by
Sylvain Pasche, it pretty much works in any
implementation
... that you can run on a desktop
... so you should be able to test it
... it'll be slow, slower than mozilla's harness
... but it will give people the flexibility to run the tests in
the release builds, and check results, rather than relying on
vendors reporting their results
... there's a fair bit of work still to do on it
... from my pov the testing project that started at the
hackathon week, that doug, plh, fantasai, mikesmith and myself
were at, is now mainly waiting on mozilla to actually figure
out how best to push their tests into w3c's repositroy
... quite tricky problems to be worked out there
... such as there are existing tests that we're running on a
per-commit basis
... so we don't want to remove them from our tree, move them to
w3c's, then start running the w3c tree
... the question is how can we keep them in both places and
synchronize them?
... changes in moz local ones should propagate to the w3c one,
and vice versa
... especially complicated when renaming and moving tests
around
... we've also got to get consensus internally in moz on how to
do this
... figure out how to, first, technical issues on getting the
w3c test suite automatically run on our build machines
... then figure out how to sync up on that
... people responsible for doing this
... figuring out which failures that then crop up, what the
causes are, what should be done about them
... an ongoing process, fair bit of work
... unclear how that should proceed
... all this sort of stuff that makes it not straightforward to
chuck our tests in the w3c repository
... apart from the fact we haven't resolved whether we are
using svn or hg, but probably we will end up using svn
... i believe we're also waiting for plh to source a more
robust server for an actual public facing site
... instead of a testing server
... the things that came out of the meeting included that
basically we won't go with a centralized system for running
tests at the w3c
... simply because the resources that are needed for that are
immense
... once you start to multiply all the OSes, browsers, versions
of browsers, plugins installed, etc.
... it's a large number of different combinations you can
have
... probably more atractive to have a test swarm type
system
... external volunteers will run batches of tests
... so they might point the test harness to 20-30 tests
... which it will run, and send the results back to the w3c's
results gathering thing
... then get another batch, etc.
... on a conversation with roc, doug, plh and myself, roc
considered that it was a very low priority, especially at this
stage for the w3c to be gathering results
... and creating the test swarm system to do this
... and given that there would be a w3c runner that could run
the tests on end browsers, there'd be transparency for the
results
... we could then rely on vendors being honest about their
results
... which would save the whole complexity about the
decentralized crowdsourced solution
DS: my take on it is
twofold
... yes, transparency would help
... that would decrease the load, people could report their own
results
... but one, we need to collect these results anyway
... part of our conformance testing
... and second, roc had proposed that they could post them on
their own sites, which is fine, but then there's no way of
harvesting that
... people should be able to trust the canonical results on the
w3c site rather than individuals' sites
... who might have another agenda
... so we need them anyway for our (w3c's) processes
... third, people shouldn't have to search for results all over
the web when they could come to a single place to find the
results
JW: i'm sympathetic to having the
w3c collect results, but at this stage it's not high priority
for me personally
... once all this conference stuff is over i can get back to
looking at testing
... figuring out a system for moz to move their tests to w3c,
and running them, is the first big issue that needs to be
tackled
DS: we don't need to solve all these things at once
JW: so there are still some
things to be worked out
... about the test formats
... a lot of moz specific stuff in the tests
... and the formats rely on a few mozilla features, e.g.
invalidation tests
... they require you to paint the window after everything is
loaded/rendered
... so we have a specific event for that, not based on a timer,
since that would make it very slow
... our tests have that sort of thing in it
... so the w3c versions might want to have that, plus a timer
to fall back on
... or we may want to standardize that event
... changes would be required to the test formats which is
another thing that needs to be worked out, what needs to be
compatible with other browsers, and what moz needs
internally
DS: there's a whole second part
of this
... there's another set of problems
... MS submitted 7000 css 2.1 tests
... it's appreciated, but at the same time all those tests need
to be reviewed
... the tests could be erroneous
... not actually testing the thing they mean to test
... they could accidentally align with some expected behaviour
that's seen in IE that isn't per spec
... it could be that something about the test points out an
ambiguity in the spec itself
JW: also the issue that that many tests, to be practical, need to be in an automated format
DS: the csswg cannot review all
these tests
... it's time consuming doing review
... the part fantasai and i were specficialy working on was a
tes treview system
... we have volunteers to do parts of the test suite, but using
email, so it's hard for tracking
... couldn't say which were reviewed, which needed review,
which had priority, etc.
... without doing a lot digging
... she was interested in creating a system so that volunteers
could review tests systematically
CM: from the wider community?
DS: more within a company
... if we're making this system anyway, we should make it crowd
sourceable
... so anyone can come in and review tests
... we could give them the more tests they reviewed and were
accurate about, we could give them scores
... also, since we're doing that, providng an interface so that
people could submit tests for what they think are
undertested
... the review system would track the tests through different
revisions
... a revision could have comments on it, when a new rev was
uploaded, people could look at the diff as part of their
review
... being able to move a test is good, since one test may apply
to different test blocks
CL: the current way of doing it
in css has multiple occurrences of a test in different parts of
the report
... their report is the type of thing that should be
generated
DS: we have similar
problems
... the version is located in the test slide, e.g.
... which causes no end of problems
... we found we didn't know if the image had been updated or
not
... having the metadata part of the image is worse than having
a system that keeps a track of this
... the review system would also be a test submission
system
... we wouldn't get the bulk through this, but parts of the
spec people are interested in would get interest
... that tells us that people are trying to use specific
features
... part of the goal of the crowdsouring review system is to
connect more directly with the community, and get them involved
in the process
JW: to become an actual accepted
w3c official test, the reviewer needs to have his competence
known
... it's still useful for random community people to do some
sort of review
... if their pre-reviews of a consistently high quality, then
that's a way to get people in later
... if two people say a test is bad, then it's likely it needs
looking at
... if 5 people say it looks good, then it can have percolated
up to one of the official reviewers
DS: so is this group willing to
go to reftests for the bulk of its tests?
... if so, jwatt should write up exactly what we want
JW: for those people not familiar
with those, they should become so
... that is partly waiting on me
... there's some docs in the wiki, but concrete examples are
necessary
... the w3c testing wiki needs a lot of work
... overall i think the test hackathon rocked, a major step
forward
... the conformance testing is important, but the huge step
forward is the interop testing
... in one or two years from now we can get all the major
browser vendors running each others' tests
DS: it also saves each browser
vendor reinventing the wheel with tests
... it decreases costs, since they don't need as many people
just dedicated to runnign tests
JW: as long as everyone pulls
their weight
... re too many tests, it's important that wide coverage and
deep coverage is good
... but need to minimize duplication
... the length of time they take to run is a big factor in how
useful they are
... it impacts their development cycles quite
substantially
... the bigger the testing time, the bigger window there is to
find regressions
AG: once the reftests have been reviewed, there'll be some process to package them up for members to get?
JW: they'd be in the
repository
... we could create zips too
RESOLUTION: we'll move to using reftests as soon as is feasible
DS: we have in the past talked
about this
... i want to briefly go over some use cases for
connectors
... and details
... we've avoided connectors because you can graphically
represent something connecting something else
... but it doesn't have a logical connection
... there are a lot of use cases for things that are logically
connected
... circuit diagrams, flow chart diagrams, any kind of
node-edge graph
... we've avoided them in the same way as avoiding default
symbols
... so connectors could also be used for representing roads, or
any kinds of routes through some thing
... i think the class of uses for these things is large
ED: xlink:href on every element?
DS: there are a number of
approaches
... i think the basic idea is that there are two aspects to
it
... one, a logical connection, between two elements which
represent two different objects
... and one is a physical connection
... an obvious thing people would like to do is [draws on
board]
... [two circles connected by a line, moving one circle should
make the line follow it]
... that could be done in the very simplest case, but i don't
think people are going to want to do something where the line
has to wrap around another shape, for example
... implementors aren't going to want to solve that case
... edge routing
... but i think there is still a lot of utility in straight
line connections
... in the future, potentially allowing the author to say "go
through this point" when routing
CL: this needs to be a new curve type?
DS: could be just straight
lines
... solve many use cases, not all
CL: curves that pass through particular points we've come up against before, so perhaps we want to add them
DS: making a rendering element is
one aspect of the problem
... making a logical one is another aspect
... so are these connections directed, undirected?
... that's part of the logical aspect of it
... another part is "what is the relationship itself"
... e.g. does that mean parent--child relationship, or
what
... that might be represented as a form of metadata, like
rdf
... or it might be, for a UI, some textual equivalent of that
equivalent
... if i'm following a map, so you walk from the subway stop to
the building
... maybe the metadata is "walk from from subway stop to
building"
... how would you express that? maybe you'd have a
<title> element
... how do you represent the connector
... i'm positing that we need a 'connector' element
... what characterstics does it have?
... it has a from and a to
... so a connector, as i see it, is a special form of path that
doesn't have a fill
... what i'm thinking is that it would take path syntax so that
if you wanted to do your own routing, you could say this is
what it looks like
... another way i thought of doing this would be to have
role="connector" on a path
... and that would mean logically that it is a connector
... if connector weren't implemented, you could represent it as
a path
... what is the role of a connector? either as a separate
element or a path
... it's to present to a user to go from one thing to
another
... pretend we are in a flow chart, and we're navigating around
it
[draws on board]
scribe: if you're in one node,
and you want to navigate to another node that is connected from
that one
... the tilte of connectors could be read out, for
example
... and the user could choose
... or maybe it's a popup that lets the user see what the
relationship is
... in terms of navigating documents in a logical order, a
blind person could query the connector to find out where it's
going
... so they could step through a complex diagram
... one use case i've seen for this is that they wanted to have
all of their wiring diagrams for cars as svg files
... apparently in japan, wiring diagrams for cars are done in
svg
... so when a mechanic is trying to sort out "is this circuit
live or not", we set up a little animation to show them if they
clicked a button which connectors are active
... so in this scenario you might write a state machine and
enable/disable certain connectors
... it would be an accessible way to present these
diagrams
... right now, if i were navigating these elements, in 1.2T we
could use the nav-* properties
... but they only solve a physical case
... with the connectors they define implicit navigation
options
... maybe its role would indicate the direction of the
connector
... so there's also a visual aspect of the problem
... we should reuse existing path syntax, so if a person wants
to do custom routing they can
... failing that, it would just be a direct line
... but when they use a direct line, dragging this element, the
line would follow
... so either you would take advantage of the auto routing,
which would be a straight line in the first version, or you
would write your own path
... but you always get the logical connection
... in later versions you could provide some way to tell it to
do routing
... there are two problems with diagrams like this
... one is the line routing
... the second is the node placement
... we're also not going to solve that, unless it gets solved
in the bounds of some layout algorithm
... e.g. cameron's layout might take care of that
CL: you're not just going to point at an object, but then you to say i'm going from this point to this other point
AG: you could specify the endpoints as bounding box percentages
DS: i'm not sure that's going be
satisfying
... e.g. on a diamond shape, you don't want connecting lines
going to one of its sides
... so not necessarily the shortest path
... we've already thought of the idea of svg point
elements
... it could act as an anchor point
... so what if we defined the anchor points of children of the
element
AG: how do you associate the
connectors with an object?
... i was thinking they might be a child
DS: can't be a child of two
elements though
... they can be in their own block somewhere
... you can name the point you want to connect to
... the default might be to choose the shortest path between
the possible anchor points on the shapes
... you could name these anchors and identify them
explicitly
AG: could you have free floating svg:points?
DS: in future versions
AG: many-to-many connections?
DS: no, just one-to-one connections
CM: i wonder if you ever want navigation that is different from what the connections indicate
<shepazu> as far as semantics of relationships, you should be able to extract a triple from this diagram
<shepazu> as far as navigation goes, they don't ahve to render, might be a better way to define meaningful navigation with titles/descs
<shepazu> rather than using nav-next/-prev attributes
RESOLUTION: We'll consider the connector proposal
<scribe> ACTION: Doug to write up the connector proposal [recorded in http://www.w3.org/2009/09/30-svg-minutes.html#action04]
<trackbot> Created ACTION-2681 - Write up the connector proposal [on Doug Schepers - due 2009-10-08].
CL: our charter expires in
april
... we have 6 months charter period left
... we need to see what we will have achieved by that
time
... usually the aim is for a charter to be circulated before
the current one ends
... it's coming to the point where we show what we did during
the charter period
... also we have the roadmap document that needs a refresh
DS: we've talked about major
revisions to the language
... we've helped direct the discussion for svg in html
CL: we've engaged more browser vendors
DS: we've already talked about
planning on doing the modules until CR, parking them, making
sure they integrate together, then publishing independent
modules as they are applicable to 1.1 or 1.2T
... and folding them in to svg 2.0
... as a single spec
... so i think that's something we can talk about to people at
svg open
... whenever we publish something, we should update the
timetable on the wiki
... we need to make the home page better
CM: should we go back to two telcons per week?
DS: we could try one hour on one day another 1.5 hours on another day
CM: maybe not two telcons per week but one followed by working time
<shepazu> Resolution: we will update the timeline in the wiki whenever we publish a new WD
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/c:/cm:/ Succeeded: s/then/thing/ Succeeded: s/in i/in it/ Succeeded: s/sylvain pasche/Sylvain Pasche/g Succeeded: s/potentially in/in the future, potentially/ Succeeded: s/prev/prev attributes/ WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> ... Found ScribeNick: chrisl Found Scribe: Cameron Found ScribeNick: heycam Found Scribe: Cameron Found ScribeNick: heycam ScribeNicks: chrisl, heycam WARNING: No "Present: ... " found! Possibly Present: AG CL ChrisL DB ISSUE JW cm ds ed ed_ fat_tony heycam joined jwatt left scribenick shepazu svg trackbot z-index 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: 30 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/30-svg-minutes.html People with action items: anthony cameron doug[End of scribe.perl diagnostic output]