IRC log of svg on 2009-09-30

Timestamps are in UTC.

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