IRC log of svg on 2012-01-12

Timestamps are in UTC.

22:21:25 [RRSAgent]
RRSAgent has joined #svg
22:21:25 [RRSAgent]
logging to
22:21:32 [heycam]
RRSAgent, this meeting spans midnight
22:21:41 [heycam]
Meeting: SVG WG Sydney 2012 F2F day 3
22:22:41 [heycam]
Chair: Erik
22:24:52 [cabanier]
cabanier has joined #svg
22:25:09 [cabanier]
scribenick: cabanier
22:25:23 [cabanier]
topic: alpha mask proposal
22:25:26 [heycam]
22:25:57 [cabanier]
cm: mask are currently unintuive since they use luminance
22:26:16 [cabanier]
cm: it is quite confusing
22:26:31 [cabanier]
cm: we opened an issue where you can use the alpha values
22:26:52 [cabanier]
cm: I opened a small proposal where you can specify luminance or alpha
22:27:50 [cabanier]
cm: there were a proposal where you could combine the 2 by having a seperate property for each mask type
22:28:05 [cabanier]
rc: are alpha values currently ignored?
22:28:21 [cabanier]
cm: no they contribute to the luminance.
22:28:30 [cabanier]
rc: this is similar to what PDF
22:28:50 [cabanier]
rc: except noone uses the alpha version
22:30:18 [stakagi]
stakagi has joined #svg
22:30:40 [cabanier]
bb: there seems to be some confusion in the spec about what mask apply to
22:32:00 [cabanier]
it seems pretty unlikely for a given mask mask element that it can be use for both luminance and alpha
22:32:24 [cabanier]
rc: why is that?
22:33:18 [cabanier]
cm: it's unlikely that you use the same element but then use it with alpha in one place and luminance in the other
22:33:22 [birtles]
(re the confusion in the spec, specifically says the mask property can refer to "another graphical object", not just a <mask>. That restriction appears earlier in the prose.)
22:34:52 [ed]
another way could be mask: <funciri> | none | alpha(<funciri>) | luminance(<funciri>)
22:35:24 [ed]
replace those <funciri> in the last two with <iri> I guess though
22:36:24 [ed]
that would make it rather easy to do fallbacks because old useragents would fail parsing the css
22:37:53 [cabanier]
bb: it would be nice if you wouldn't have to create id's
22:38:16 [cabanier]
cm: not everyone puts masks in the defs
22:38:32 [cabanier]
cm: that does seem handy
22:38:52 [cabanier]
bb: very often you have to write a unique id generator to create the id's
22:39:03 [cabanier]
cm: maybe we can raise an issue
22:39:29 [cabanier]
ed: people have asked for this for gradients
22:40:04 [heycam]
ISSUE: Consider allowing <mask>, <clipPath>, etc. as direct children of elements they'd apply to, to avoid IDs
22:40:05 [trackbot]
Created ISSUE-2431 - Consider allowing <mask>, <clipPath>, etc. as direct children of elements they'd apply to, to avoid IDs ; please complete additional details at .
22:40:49 [cabanier]
bb: this does impace how it impacts alpha and luminance
22:42:37 [cabanier]
cm: you can have new keywords for mask: 'mask: child' and then if there is a mask element child that that is using it as a child.
22:43:41 [cabanier]
ed: having a keyword like that because we don't always traverse into an element. this keyword would tell us to examine the element.
22:46:05 [cabanier]
ed: I have no problems with the functionality itself
22:46:13 [cabanier]
ed: I think that's what we want
22:48:01 [cabanier]
cm: bb do you want to investigate this further?
22:48:20 [cabanier]
bb: yes, I would like to look into this further to make sure there are no issues
22:49:29 [cabanier]
action birtles to investigate issue 2431
22:49:30 [trackbot]
Created ACTION-3205 - Investigate issue 2431 [on Brian Birtles - due 2012-01-19].
22:50:16 [cabanier]
action heycam to proposal a final syntax on alpha mask after Brian investigate 2431
22:50:16 [trackbot]
Created ACTION-3206 - Proposal a final syntax on alpha mask after Brian investigate 2431 [on Cameron McCormack - due 2012-01-19].
22:50:48 [cabanier]
resolution: we will add alpha mask functionality to SVG 2
22:55:34 [ed]
22:55:55 [cabanier]
ed: until the break we will work on some open actions
22:56:25 [ed]
22:57:24 [cyril]
cyril has joined #svg
22:58:29 [cyril]
RRSAgent, pointer
22:58:29 [RRSAgent]
22:59:36 [heycam]
-- doing actions until morning tea break --
23:00:13 [thorton_]
thorton_ has joined #svg
23:00:19 [thorton_]
thorton_ has joined #svg
23:18:05 [shepazu]
agenda+ SVG in HTML head
23:30:56 [ed]
-- <tbreak dur="15min"/> --
23:58:05 [heycam]
scribenick: heycam
23:58:08 [heycam]
Topic: SVG in HTML <head>
23:58:25 [cyril]
cyril has joined #svg
23:58:32 [ed]
previous discussion of this:
00:00:12 [heycam]
DS: there's strong resistance from browser vendors to add elements to the HTML <head>
00:00:20 [heycam]
… because it breaks backwards compat, and requires changes to the parser
00:00:27 [heycam]
… the parser is pretty much set in stone at this point
00:00:56 [heycam]
CL: I don't think we need to put things in head
00:01:03 [heycam]
… our <defs> is like a <div> with display:none
00:01:07 [heycam]
… so you can stick whatever you want there
00:01:11 [heycam]
… there's no need to put it in the <head>
00:01:32 [heycam]
… the only thing we do have that maybe belongs in the head is the <meta> element, though our <metadata> is structured
00:01:37 [heycam]
… in SVG you can nest elements in <metadata>
00:01:42 [heycam]
… so it really doesn't belong in <head> either
00:01:58 [heycam]
DS: I do think it's not unreasonable for people to think they should add things to the head
00:02:03 [heycam]
CL: at first sight it's very reasonable
00:02:26 [heycam]
DS: I think our best course of action is not to follow up on hixie's recommendation to define our elements as metadata content
00:02:32 [heycam]
… rather to simply to educate people that you can't do that
00:03:01 [heycam]
… I think it's very unusual that hixie would recommend this course of action
00:03:47 [heycam]
… I will respond to the original commenter
00:04:41 [heycam]
RESOLUTION: SVG will not allow elements to be put in HTML <head>
00:05:33 [heycam]
Topic: shorthand properties as presentation attributes
00:05:45 [ed]
00:06:19 [birtles]
ScribeNick: birtles
00:08:22 [birtles]
CL: CM's proposal on the wiki where you put the shorthands before all the properties in doc order satisifies my earlier concerns
00:08:36 [birtles]
CM: proposal is to allow pres attr for properties which are shorthands
00:08:51 [birtles]
... at the moment you can't write marker="" b/c marker is a shorthand
00:09:03 [birtles]
... creates confusion for authors
00:09:20 [birtles]
... don't understand why they need to use marker-start etc. if they're using pres attr
00:09:26 [birtles]
... with style you can just use "marker"
00:09:46 [birtles]
... last time this issue came up was in context of when CSS properties get split and orig becomes a shorthand
00:09:53 [birtles]
... e.g. overflow becoming overflow-x and overflow-y
00:09:59 [birtles]
... overflow is now a shorthand
00:10:08 [birtles]
CL: likewise whitespace might go that way
00:10:23 [birtles]
CM: we want to allow overflow to continue to be a pres attr
00:10:29 [birtles]
... even if it becomes a shorthand
00:10:49 [birtles]
... original reluctance was you have multiple attr targetting the same property
00:11:53 [birtles]
... and override behaviour was not clear since attr are unordered
00:12:03 [birtles]
... unlike styles where you have doc order
00:12:20 [birtles]
... but the proposal addresses that by taking shorthands first
00:12:52 [birtles]
ED: so you if have marker-mid before marker (as attributes) then marker will override marker
00:13:02 [birtles]
ED: so you if have marker-mid before marker (as attributes) then marker will override marker-mid
00:13:43 [cabanier_]
cabanier_ has joined #svg
00:14:17 [birtles]
CL: it's something we're going to have to address with properties being split up and becoming shorthands
00:16:38 [birtles]
CL: any comments from implementors?
00:16:49 [birtles]
ED: it's probably fine but I need to check the code
00:17:22 [birtles]
... it would be pretty simple to verify if there were some test cases
00:18:59 [birtles]
CM: I think it should be ok
00:21:28 [birtles]
... is there a difference between animating the style or the presentation attribute
00:21:45 [birtles]
CL: attributeType is just for disambiguation when the attribute name and property name overlap and are not the same thing
00:21:56 [birtles]
... not to provide different behaviour
00:25:59 [birtles]
RESOLUTION: We will allow shorthand properties to be used as presentation attributes (ISSUE-2430) according to Cameron's proposal
00:27:06 [birtles]
ACTION: Cameron to describe using shorthand properties as presentation attributes in spec
00:27:06 [trackbot]
Created ACTION-3207 - Describe using shorthand properties as presentation attributes in spec [on Cameron McCormack - due 2012-01-20].
00:27:23 [birtles]
ED: is there an order normally to style
00:27:24 [heycam]
00:27:24 [trackbot]
ACTION-3207 Describe using shorthand properties as presentation attributes in spec notes added
00:27:38 [birtles]
CL: yes, if it's in a stylesheet (incl style attr)
00:27:54 [birtles]
ED: if you start modifying the element by script, then the order is not guaranteed
00:28:05 [birtles]
CL: the assertion was attributes are unordered
00:28:19 [vhardy]
vhardy has joined #svg
00:28:22 [birtles]
CM: the stylesheet is not exposed to script though right?
00:28:33 [birtles]
... you can getComputedStyle but there's no order requirement there
00:28:45 [birtles]
ED: if it's just for when it's parsed then it's ok
00:29:12 [birtles]
CM: even if you're modifying the attr then you still need the shorthand first
00:29:37 [birtles]
... if you're actually creating stylesheets you could create two (one for shorthands)
00:29:42 [birtles]
... might be simpler than managing the order
00:31:42 [birtles]
ED: what about font? you have to use CSS rules such as requiring units
00:31:46 [birtles]
... isn't that confusing?
00:31:53 [birtles]
... for all shorthands you have to use units
00:31:59 [birtles]
... whereas elsewhere you don't
00:32:08 [birtles]
CL: it's only really for lengths where we have this different
00:32:15 [birtles]
... where you don't need units in SVG
00:32:20 [birtles]
... marker etc. are ok
00:32:26 [birtles]
... it's only really 'font'
00:33:03 [birtles]
... so it would be a rule that shorthands have to use CSS rules which includes using units (and excluding scientific notation)
00:33:12 [birtles]
CM: what if we came up with our own shorthand
00:33:25 [birtles]
... that wasn't ambiguous
00:33:31 [birtles]
CL: that would be confusing to use a different notation
00:33:56 [birtles]
... and might outweigh the benefit of using shorthands
00:34:17 [birtles]
... because you'd add syntax to disambiguate
00:34:41 [birtles]
CM: so we'll just require CSS parsing for shorthand presentation attributes
00:34:49 [birtles]
ED: I think that would be ok, better than adding quirks
00:35:03 [birtles]
CM: what about new CSS properties?
00:35:18 [birtles]
... we have font-size in SVG so we can explicitly allow unitless lengths
00:35:46 [birtles]
CM: do we want to revisit scientific notation in SVG 2?
00:35:57 [birtles]
... because perhaps it's not used?
00:36:24 [birtles]
CM: many scripts default to using exponential notation
00:36:32 [birtles]
s/CM: do we/CL: do we/
00:36:51 [birtles]
CL: we were originally expecting much more use of the world coord system with very large numbers
00:37:00 [birtles]
... but in practice you actually run into precision problems
00:37:43 [birtles]
Topic: SVG2 Requirements
00:38:46 [ChrisL]
ChrisL has joined #svg
00:39:29 [birtles]
Up to:
00:40:45 [cyril]
we should also deal with
00:41:31 [birtles]
deciding on time containers depends on me finishing action-3202
00:43:56 [birtles]
BB: not sure what this means
00:44:22 [birtles]
CM: I guess it's about addressing differences
00:44:27 [birtles]
BB: what are the differences?
00:44:34 [birtles]
CM: underlying value is fixed, reversing
00:45:05 [birtles]
BB: my guess is reversing?
00:45:14 [birtles]
VH: we should find out what is specificallly required here
00:46:21 [birtles]
ACTION: Cameron to contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions
00:46:22 [trackbot]
Created ACTION-3208 - Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions [on Cameron McCormack - due 2012-01-20].
00:46:45 [birtles]
00:46:45 [trackbot]
ACTION-2308 Draft an email response for the second half of ISSUE-2089 notes added
00:47:09 [birtles]
00:47:09 [trackbot]
ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added
00:48:54 [birtles]
CL: we are going to have transitions anyway based on Patrick's proposal to allow using SVG's attributes in CSS
00:49:18 [cyril]
RESOLUTION: SVG 2 will allow CSS-transitions-like animations
00:49:32 [cyril]
RRSAgent pointer
00:49:35 [cyril]
RRSAgent, pointer
00:49:35 [RRSAgent]
00:49:47 [heycam]
ACTION-3208: Say to Olaf we have interpreted his request in this way, and we agree, but if he means something else please explain
00:49:47 [trackbot]
ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added
00:50:01 [ChrisL]
rrsagent, make logs public
00:50:31 [birtles]
next, Transitions for discretely animated properties, text-anchor in particular
00:52:06 [ChrisL]
commenter wants to smoothly animate from
00:52:08 [ChrisL]
00:52:08 [ChrisL]
00:52:08 [ChrisL]
00:52:09 [ChrisL]
00:52:19 [ChrisL]
00:52:19 [ChrisL]
00:52:19 [ChrisL]
00:52:41 [birtles]
ED: even though text-anchor-end animation is discrete it would be possible to provide linear interpolation
00:52:55 [birtles]
CM: it is a bit of a violation of the model and the idea of "discrete"
00:53:18 [ChrisL]
I think that breaks the modelof animation. at all points in the animation, the value of the animated property has to be one of the actual values
00:53:52 [birtles]
VH: there's a difference between calcMode="discrete" and calcMode="linear" that falls back to discrete
00:54:28 [birtles]
CM: if we wanted it to work for text-anchor we could allow it to take numeric values
00:54:33 [ChrisL]
we could imaging a mapping with for example-100% as start, 0 as middle,100% as end
00:54:36 [birtles]
... e.g. -100 to 100
00:55:11 [birtles]
CL: we could spec it fairly easily
00:55:50 [birtles]
... I think it's ok if we're just talking about calcMode="linear" that falls back
00:55:56 [birtles]
... as opposed to calcMode="discrete"
00:56:08 [birtles]
CM: but I often rely on that fallback behaviour
00:56:16 [birtles]
... and don't specify calcMode="discrete"
00:56:42 [birtles]
CL: if we did this change and people are relying on the discrete behaviour they might get a surprise
00:57:23 [ChrisL]
butthey could fix it by adding calcmode discrete to keep the old behaviour
00:59:12 [birtles]
BB: so you have to modify the definition of those attributes to allow numeric values
01:00:26 [birtles]
CL: the approach is to make attributes that take discrete values to be shorthand for those that take numeric values
01:00:55 [birtles]
CM: in font-weight, some of the keywords are synonyms for numbers
01:01:04 [birtles]
CL: but it's an ordered series
01:01:35 [birtles]
CM: what happens when you getComputedStyle---which do you get? the keyword or the number?
01:02:17 [birtles]
... likewise what will happen here if we use getComputedStyle on the new text-anchor etc. that takes numeric values
01:02:38 [birtles]
CL: I'm proposing promoting some values so that can take *continuous* values
01:02:47 [birtles]
... so font-weight would not be an example
01:07:44 [birtles]
RESOLUTION: SVG2 will allow linear interpolation for properties which were previously discrete
01:08:21 [birtles]
ACTION: Chris to write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly
01:08:22 [trackbot]
Created ACTION-3209 - Write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly [on Chris Lilley - due 2012-01-20].
01:09:08 [birtles]
ACTION: Brian to look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric)
01:09:08 [trackbot]
Created ACTION-3210 - Look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric) [on Brian Birtles - due 2012-01-20].
01:10:37 [birtles]
next, animateTransform with matrix-decomposed like CSS
01:10:46 [ed]
01:11:13 [birtles]
CM: diff between animateTransform and CSS Animations with transform property, is CSS considers the whole transform list, but SVG Animations does one transform at a time and post-multiplies
01:11:29 [birtles]
... request is to add a new type to animateTransform that matches CSS Animations
01:11:58 [birtles]
... but we could just <animate> to get that behaviour
01:12:26 [birtles]
... <animate attributeName="transform" values="scale(...) rotate(...); scale(...) rotate(...)"/>
01:12:29 [birtles]
... it overrides the whole list
01:13:31 [birtles]
... need to define how additive works with whole lists of items
01:17:01 [birtles]
VH: so how does animateTransform add to the end of the list?
01:17:11 [birtles]
BB: it differs between browsers
01:17:49 [birtles]
... if you inspect the animVal in the DOM some browsers will just append a matrix transform, some will try to preseve the animateTransform's type, others just replace the whole list with a matrix
01:19:21 [birtles]
VH: even if we deal with lists we already have a model for adding that to the underlying transform, it doesn't change the model
01:19:37 [birtles]
CC: it doesn't change the post-multiplication
01:20:20 [birtles]
... it doesn't change the final value
01:20:25 [birtles]
... but it does change the animVal
01:20:51 [birtles]
VH: but given the way the requirement is worded I think it wouldn't change
01:22:51 [birtles]
VH: we want to allow <animate attributeName="transform">
01:22:54 [birtles]
CM: I agree
01:23:28 [birtles]
RESOLUTION: We will support animation using a transform-list
01:24:48 [birtles]
01:27:42 [birtles]
01:29:19 [birtles]
BB: Addition of transforms is a bit unusual (see above link)
01:29:44 [birtles]
... we can rely on CSS Transform's behviour for interpolation but we need to specify how addition works for transform lists
01:30:24 [birtles]
CM: this difference is specific to animateTransform
01:30:38 [birtles]
... so if we go to using animate, do we want to just use the default behaviour?
01:31:03 [birtles]
.... which would mean adding the transform components rather than post-multiplication
01:33:43 [birtles]
ACTION: Cyril to investigate different methods for adding transform in animation
01:33:44 [trackbot]
Created ACTION-3211 - Investigate different methods for adding transform in animation [on Cyril Concolato - due 2012-01-20].
01:33:55 [birtles]
01:33:56 [trackbot]
ACTION-3211 Investigate different methods for adding transform in animation notes added
01:35:16 [birtles]
---break 1hr for lunch---
01:35:48 [vhardy]
01:49:18 [patrickdengler_]
Sorry, I didn't catch the end of this discussion, and I hope you had a good lunch :)
01:49:36 [patrickdengler_]
When we talk about adding a new element, such as animateTransform, are we consulting with the HTML group as well?
02:31:49 [patrickdengler_]
Not animateTransform but any *new* element (sorry)
02:49:50 [ChrisL]
scribeNick: ChrisL
02:49:58 [ChrisL]
topic: Milestones and Planning
02:50:58 [ed]
02:50:59 [ChrisL]
heycam: need some target dates
02:51:21 [vhardy]
vhardy has joined #svg
02:51:33 [ed]
02:52:23 [heycam]
02:52:27 [ChrisL]
heycam: was supposed to add stuff back into the wiki page from the separate document
02:52:55 [ChrisL]
ChrisL: and people were to add explanation for the accepted items
02:53:20 [jun]
jun has joined #svg
02:53:37 [ChrisL]
vhardy: whatabout use cases?
02:53:44 [ChrisL]
heycam: should be in the wiki page
02:54:08 [ChrisL]
... if its useful we can continue working on a /TR requirements doc
02:54:50 [ChrisL]
ChrisL: want oto avoid work that is of no beefit. wiki page is more easily updated
02:55:09 [ChrisL]
ed: easier to update wikipage
02:55:20 [ChrisL]
heycam: easier to read a published doc though
02:55:34 [ChrisL]
cyril: we have 90 left to do
02:55:46 [ChrisL]
... out of 180 at the start
02:55:47 [stakagi]
stakagi has joined #svg
02:56:08 [ChrisL]
... wereat 40% after tpac
02:56:25 [ChrisL]
vhardy: think its a big effort to migrate to a new document
02:57:19 [ChrisL]
ChrisL: people do not read reqts top to tail, they drill down on a particular issue
02:58:20 [ChrisL]
... still feasible to do by end of this f2f?
02:59:26 [ChrisL]
cyril: we have 2/3 by scrollbar
02:59:40 [ChrisL]
birtles: doc gets longer as we edit
03:00:30 [ChrisL]
ChrisL: earlier ones were more vague and we took a lot of time to understand the comments. later ones are specced features from 1.2T so its either in or out
03:02:58 [ChrisL]
ChrisL: next, whatdo we have in fpwd - lots or a little (ipp implications)
03:05:50 [heycam]
CM: the other question is whether we go forward with this grand refactoring of the document that we talked about before
03:06:19 [cabanier]
cabanier has joined #svg
03:06:57 [heycam]
… I think it would be better to not do that upfront
03:07:17 [heycam]
… instead we just add the features/changes according to the existing structure
03:07:24 [heycam]
… so we can get drafts published with them
03:07:41 [heycam]
… rather than having the first couple of working drafts just consist of reorganisation of existing text, with no other changes
03:08:57 [ChrisL]
ChrisL: would prioritise documenting new features over refactoringexisting ones
03:11:16 [ChrisL]
ChrisL: patent exclusions are at fpwd and last call, and are per-feature
03:11:37 [ChrisL]
... so its better to at least list a feature even if the spec is incomplete or the syntax not stable
03:12:17 [ChrisL]
ChrisL: want to see tests early
03:12:32 [ChrisL]
heycam: so when new feature is added, add tests as well
03:13:41 [ChrisL]
ChrisL (explains how automatic test assertion annotation is added)
03:14:03 [ChrisL]
ed: good to get some tests using the new harness, to see how it works
03:16:26 [ChrisL]
ChrisL: we need to decide link mechanisms. WOFF used this new mechanism (but the files were mostly html)
03:16:47 [ChrisL]
action: chris to continue to work on test suite linking mechanism for new harness
03:16:47 [trackbot]
Created ACTION-3212 - Continue to work on test suite linking mechanism for new harness [on Chris Lilley - due 2012-01-20].
03:17:21 [ChrisL]
ed: we can update the milestones to add this testsuite item
03:18:48 [cyril]
03:19:55 [ChrisL]
birtles: good reftests use lime green for pass and red for fail
03:20:33 [ChrisL]
that is not the right link
03:20:34 [ChrisL]
03:22:32 [ChrisL]
ChrisL (walks through the new reporting framework)
03:25:49 [ChrisL]
heycam: need stubs for ecery new feature for fpwd. say 3 months after the editors draft
03:26:11 [ChrisL]
... so July
03:26:21 [ChrisL]
then another in October for TPAC
03:26:30 [ChrisL]
s/then/... then/
03:27:09 [ChrisL]
vhardy: who can lead the spec editing effort
03:27:53 [ChrisL]
cyril: needs someone who already has ssh mercurial access
03:28:10 [ChrisL]
ed: tav has done most of the editing so far
03:28:38 [ChrisL]
03:29:17 [ChrisL]
heycam: last entry depends on the feature owners
03:30:20 [ChrisL]
vhardy: in reqts we have big sections then a lot of tiny ones
03:31:02 [ChrisL]
heycam: as we go through the list we can allocate owners
03:31:32 [ChrisL]
vhardy: we need to triage the requirements to prioritise the most important ones
03:31:58 [ChrisL]
heycam: we did not do that, so we accepted a lot of requirements some of which might not be for 2.0
03:32:12 [ChrisL]
vhardy: need priority on all the accepted requirements
03:33:10 [ChrisL]
cyril: once we have commitments for the popular features this will lead to priorities. if no-one commits its low priority
03:33:20 [ChrisL]
heycam: and if that is loo long we can cut it
03:33:35 [ChrisL]
cyril: up to individuals how many new features to take on
03:33:59 [cabanier]
cabanier has joined #svg
03:34:07 [ChrisL]
vhardy: priority needs to be decided before fpwd
03:34:24 [ChrisL]
... march is better
03:36:03 [ChrisL]
action: erik to remind people early March 2012 about prioritisation
03:36:03 [trackbot]
Created ACTION-3213 - Remind people early March 2012 about prioritisation [on Erik Dahlström - due 2012-01-20].
03:36:59 [ChrisL]
heycam: looks good for the milestones
03:37:22 [ChrisL]
vhardy: management nightmare to weigh the priorities
03:37:31 [ChrisL]
heycam: happy to make a form for that
03:37:55 [ChrisL]
action: heycam to make a form for priorities
03:37:56 [trackbot]
Created ACTION-3214 - Make a form for priorities [on Cameron McCormack - due 2012-01-20].
03:41:18 [ChrisL]
ChrisL: goot time for lc would be after tpac so (with holidays) jan would be good, finished by May/June and CR in August depending on need for a second LC
03:42:16 [ChrisL]
vhardy: for selecting requirements we could update - things thatare broken, graphical features
03:43:10 [ChrisL]
vhardy: for 2.1 2.2 etc we could put the theme that adds value for each iteration, nt too ambitious each time
03:44:44 [ChrisL]
vhardy: first priority could be graphical features, with animation and dom refactoring left for a dot release
03:45:06 [ChrisL]
heycam: seem to have a range of killer things that do not fit those themes
03:45:29 [ChrisL]
cyril: this discussion is easier when we have a prioritised list
03:45:42 [ChrisL]
vhardy: main point is to limit the scope to what is acheivable
03:46:02 [ChrisL]
heycam: ok so lets aim for LC in January 2013
03:48:50 [ChrisL]
Topic: GetBBoxOf
03:49:27 [heycam]
03:49:47 [ChrisL]
03:50:08 [ChrisL]
heycam: this is getting the bbox in a different elements coordinate system
03:50:14 [ChrisL]
... often want to do this
03:51:24 [ChrisL]
... proposal is to add getBBoxOf that you call in the element whith the desired coord system and you apss the element you want the bbox of
03:51:38 [ChrisL]
... need not be a descendent
03:52:11 [ChrisL]
cyril: bbox is always axis aligned?
03:52:15 [ChrisL]
heycam: yes
03:52:28 [ChrisL]
ed: its like getScreenBox in Tiny
03:52:49 [ed]
03:53:36 [ChrisL]
cyril: (points out an error in the proposal, this and element are transposed
03:53:47 [ChrisL]
vhardy: do we want a rect or a swt of points?
03:53:49 [ed]
03:53:53 [ChrisL]
03:54:06 [ChrisL]
vhardy: (draws on whiteboard)
03:54:53 [ChrisL]
ed: agrees with vhardy, you want four points for a non axis aligned bbox
03:55:05 [ChrisL]
vhardy: want the points, or an option to get the points
03:55:24 [ChrisL]
cyril: last step is trivial, min maxso return the points
03:56:10 [ChrisL]
ChrisL: getBBoxCorners ?
03:56:24 [ChrisL]
birtles: what will people do more often?
03:56:39 [ChrisL]
vhardy: adding handles is common so the points would be better there
03:57:14 [ChrisL]
cabanier: illustrator gives the full bbox
03:57:37 [ChrisL]
heycam: we don't want to multiply the number of methods unecessarily
03:57:56 [ChrisL]
cabanier: if you miter corners and transform, miter will go further
03:58:42 [ChrisL]
ChrisL: recall that we also wanted to have an inked bbox that includes stroke and markers
03:59:17 [ChrisL]
... so for this one which is geometric, stroke mitering does notaffect it
04:00:29 [fat_tony]
fat_tony has left #svg
04:02:08 [ChrisL]
vhardy: bbox is d=for dirty areas, editing
04:02:14 [ChrisL]
birtles: hit testing
04:02:31 [cyril]
04:03:43 [ChrisL]
ChrisL: for painted bbox we would need the analog of this (get painted bbox in another coord system)
04:04:08 [ChrisL]
cabanier: if transformed, miters would become sharper
04:04:18 [ChrisL]
vhardy: we do pre-transform stroking
04:04:39 [ChrisL]
... illustrator gives you both
04:05:14 [ChrisL]
vhardy: non scaling stroke strokes the transformedgeometry
04:05:41 [ChrisL]
heycam: so maybe instead give a much easier way to get quads and then transform them to another coordsys
04:05:51 [ChrisL]
vhardy: like the quad idea
04:06:13 [ChrisL]
getBoundingQuad and then transform and getBBox on that
04:06:47 [ChrisL]
action: heycam to revise getBBoxof proposal based on this discussion
04:06:47 [trackbot]
Created ACTION-3215 - Revise getBBoxof proposal based on this discussion [on Cameron McCormack - due 2012-01-20].
04:08:59 [ChrisL]
Topic: Auto sized image
04:09:04 [vhardy]
04:09:43 [birtles]
04:11:12 [ChrisL]
cyril: is it auto size or auto scale
04:11:51 [ChrisL]
heycam: (rapidly corrects proposal)
04:12:15 [ChrisL]
heycam: its the same rules css uses for intrinsic aspect ratio
04:13:04 [ChrisL]
vhardy: the initiial viewport is there is there is no bbox
04:13:46 [ChrisL]
... defaults to 100% 100% and the width is known
04:14:00 [ChrisL]
heycam: so you dont use any 150 300 ratio
04:14:36 [ChrisL]
cyril: like the idea to not give w & h if you don't want
04:14:47 [ChrisL]
... do no t want to break backwards compat
04:15:06 [vhardy]
vhardy: at the end of the day, we need to align with the CSS 2.1 behavior.
04:15:37 [ChrisL]
heycam: prefer 1 over 2 but itdoes change existing meaning
04:15:44 [ChrisL]
... second one doesn't
04:16:27 [ChrisL]
heycam: in old viewers, missing attrs gives zero so no display - do that all the time
04:17:12 [ChrisL]
vhardy: if you have w h and viewbox there is enough to work out the aspect ratio
04:18:33 [ChrisL]
ChrisL: people depend on missed attrs going to zero, so I prefer the second option
04:20:17 [ChrisL]
vhardy: common case of images with same width and variable height
04:20:26 [ChrisL]
cyril: so that leads to proposal 2
04:23:58 [ChrisL]
cyril: how aboutsizing="intrinsic"
04:24:45 [ChrisL]
ed: seen lots of js driven stuff that fills out w and h later and it does not render if zero
04:24:54 [ChrisL]
cyril: used for image preload
04:25:08 [ChrisL]
birtles: is the preload specced?
04:25:40 [ChrisL]
(we think not)
04:25:50 [ed]
s/seen lots of js driven stuff that fills out w and h later and it does not render if zero/i've seen some (rather complex) js driven frameworks that fill out w and h later and it does not want it to render if zero/
04:26:10 [ChrisL]
vhardy: to display an unknown image you load by script just to calculate the w and h
04:26:31 [ChrisL]
1 - two
04:26:43 [ChrisL]
2 - four
04:26:56 [ChrisL]
ppl voting 1 can live with 2
04:28:09 [ChrisL]
resolution: image resizing will use option 2 with sizing="intrinsic" as an attr not a property
04:28:19 [ChrisL]
04:46:39 [cyril]
scirbe: Cyril
04:46:43 [cyril]
scribe: Cyril
04:46:46 [cyril]
ScribeNick: cyril
04:47:45 [cyril]
Topic: test suite
04:48:09 [cyril]
CM: are we only having ref tests or scripted tests?
04:48:17 [cyril]
CL: they are not mutually exclusive
04:48:25 [cyril]
CM: yes
04:48:56 [cyril]
BB: the scripted tests have the advantage of finding the reason for a failure easily
04:49:00 [cyril]
... you don't have to dig
04:49:18 [cyril]
CM: there is the CSS thing (ref test) and the testharness.js
04:49:50 [cyril]
ED: James Graham worked on making sure it works with our existing test harness
04:50:16 [cyril]
... so it is possible to use the existing test suite if we had script snippets
04:50:34 [cyril]
... but I' mot sure that's the best way to convert the tests
04:50:56 [cyril]
... I don't know if the existing test set is the best test
04:51:40 [cyril]
... Opera is working on publishing the existing animation tests for SMIL but scripted so that we don't have to look at the output
04:52:07 [cyril]
... it has some requirements on the API: pauseAnimation, and setCurrentTime
04:53:36 [ChrisL]
04:53:46 [cyril]
CC: at TPAC, the break out on testing was explaining how to use the harness
04:54:04 [ChrisL]
04:54:50 [ChrisL]
04:57:46 [cyril]
ACTION: Erik to check in an example on how to use the testharness.js
04:57:47 [trackbot]
Created ACTION-3216 - Check in an example on how to use the testharness.js [on Erik Dahlström - due 2012-01-20].
04:58:15 [cyril]
CL: the current tests, we only have the image patches in the case where Batik does not pass
04:58:26 [cyril]
... now we want one of all
04:58:35 [cyril]
... and they need to be a lot simpler
04:59:00 [cyril]
VH: that could be a real time sink
04:59:13 [cyril]
... I would like to say that we don't touch the old tests
04:59:20 [cyril]
CL: that's a good comment
04:59:37 [cyril]
ED: apart the animation tests, that should be fine for the others
05:00:01 [cyril]
VH: especially with the new Browser API, is there anything to do screen capture
05:00:29 [cyril]
CL: it has been proposed as modal and for the specific purpose of testing
05:00:58 [ChrisL]
but not enabled by default, for security
05:01:14 [cyril]
VH: do we agree to keep the old test suite
05:01:24 [cyril]
... as is and work on a new one
05:01:26 [cyril]
CL: yes
05:01:28 [cyril]
ED: yes
05:01:42 [cyril]
CL: we can copy over if needed
05:02:16 [cyril]
CM: we would need to annotate the old tests for the coverage evaluation
05:02:29 [cyril]
CL: the current annotation does not have the granularity
05:02:34 [cyril]
... that we need
05:03:05 [cyril]
... you need an id and a class, the test points to that id
05:03:30 [cyril]
... I did that with the WOFF spec and it's quite simple
05:03:45 [cyril]
... an id on each assertion and a class for viewers, authoring tools ....
05:04:28 [cyril]
Topic: Spec review requests
05:04:38 [cyril]
CM: we got two requests to review CSS specs
05:04:54 [cyril]
... we need to assign actions so that that gets done
05:05:03 [cyril]
VH: a third one is shadow dom
05:05:17 [cyril]
CL: CSS Values and Replaced Content
05:05:24 [ChrisL]
Title: CSS Image Values and Replaced Content Module Level 3
05:05:24 [ChrisL]
Temporary URL:
05:05:39 [ChrisL]
Title: CSS Basic User Interface Module Level 3:
05:05:39 [ChrisL]
Editor's draft:
05:06:40 [cyril]
RC: the first one has gradients
05:06:48 [cyril]
CM: UI has pointer events and cursor
05:07:04 [cyril]
... UI is meant to be reviewed by 14th of Feb
05:07:13 [cyril]
... Image Values byt the 17th
05:07:59 [cyril]
ACTION: Vincent to review the Shadow DOM draft
05:07:59 [trackbot]
Created ACTION-3217 - Review the Shadow DOM draft [on Vincent Hardy - due 2012-01-20].
05:08:22 [cyril]
CM: it told dmitry we will find in the SVG spec, where shadow dom is useful
05:08:47 [cyril]
... I didn't give him a timeline
05:09:19 [cyril]
ACTION: Chris to review CSS UI
05:09:20 [trackbot]
Created ACTION-3218 - Review CSS UI [on Chris Lilley - due 2012-01-20].
05:09:52 [cyril]
ACTION: Erik to review the 3 specs
05:09:52 [trackbot]
Created ACTION-3219 - Review the 3 specs [on Erik Dahlström - due 2012-01-20].
05:10:20 [cyril]
ACTION: Cyril to review CSS Image Values and Replaced Content Module Level 3
05:10:21 [trackbot]
Created ACTION-3220 - Review CSS Image Values and Replaced Content Module Level 3 [on Cyril Concolato - due 2012-01-20].
05:10:31 [cabanier]
cabanier has joined #svg
05:11:19 [cabanier]
cabanier has joined #svg
05:12:42 [vhardy]
ScribeNick: vhardy
05:13:00 [heycam]
Shadow DOM spec:
05:13:34 [vhardy]
Topic: CSS Compositing
05:16:11 [cyril]
05:16:58 [vhardy]
ag: last time we edited the spec, I started putting in parts for CSS so that the document could apply to CSS and SVG, both.
05:17:05 [Anthony]
Anthony has joined #svg
05:17:10 [vhardy]
... I do not remember how far we went, and there is more work to be done.
05:18:06 [cyril]
05:18:36 [vhardy]
rc: did you send a pointer.
05:18:43 [vhardy]
(group looking for the draft).
05:20:07 [vhardy]
ag: the wording was changed, for example, on enable-background, to be generic and talk about 'host language' and use SVG as 'an example host language'. The document in dev is doing that migration.
05:20:21 [vhardy]
... same for knockout and compop
05:20:40 [vhardy]
rc: do you remember why did you add Porter Duff.
05:21:58 [vhardy]
ag: filters were not enough because when you use the compositing operators in filters, they include the background twice and so you get an incorrect result. This is why we added the PD operators in the spec.
05:22:44 [vhardy]
cyril: I have dug up in previous documents/proposals, one of the reasons was that filters require a filter region, but for PD, you can do it while rasterizing and you do not need a region.
05:22:58 [vhardy]
... I'll send a link to a document created by Craig Brown.
05:23:50 [vhardy]
... if you have a set of elements that are composited with the painter's algorithm, and you want to make one compositing change on one element, you would have to completely modify the DOM (if using filters).
05:23:57 [vhardy]
rc: I would like to see an example to understand.
05:24:05 [cyril]
05:24:08 [cyril]
<?xml version="1.0" encoding="utf-8"?>
05:24:09 [cyril]
05:24:11 [cyril]
<path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,26.863-60,
05:24:12 [cyril]
05:24:14 [cyril]
05:24:16 [cyril]
<path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
05:24:17 [cyril]
<path fill="#00FF00" stroke="#000000" d="M223,69.5l-51,58l-76-97L223,69.5z"/>
05:24:19 [cyril]
05:24:34 [cyril]
you want to modify to the third object to be composed with multiply
05:24:50 [cyril]
<?xml version="1.0" encoding="utf-8"?>
05:24:52 [cyril]
05:24:54 [cyril]
05:24:55 [cyril]
<g id="BoverA">
05:24:57 [cyril]
<path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,
05:24:59 [cyril]
05:25:00 [cyril]
05:25:02 [cyril]
<path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
05:25:03 [cyril]
05:25:05 [cyril]
<filter id="X" filterUnits="objectBoundingBox" x="-50" y="-50"
05:25:08 [cyril]
width="100" height="100">
05:25:08 [cyril]
<feImage xlink:href="#BoverA" result="blah"/>
05:25:10 [cyril]
<feComposite in="SourceGraphic" in2="blah" operator="multiply"/>
05:25:11 [cyril]
05:25:13 [cyril]
05:25:15 [cyril]
this introduces the filter element
05:25:18 [cyril]
05:25:20 [cyril]
<?xml version="1.0" encoding="utf-8"?>
05:25:21 [cyril]
05:25:23 [cyril]
<path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,26.863-60,60-60c33.137,0,60,26.863,60,60s-
05:25:24 [cyril]
05:25:26 [cyril]
05:25:28 [cyril]
<path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
05:25:29 [cyril]
<path fill="#00FF00" stroke="#000000" comp-op="multiply" d="M223,69.5l-51,58l-76-97L223,69.5z"/>
05:25:31 [cyril]
05:25:33 [cyril]
is much closer to the original
05:25:49 [vhardy]
rc: ok, so the argument is that it is easier to use.
05:26:34 [vhardy]
ag: thre is more than an ease of use issue, there are functional limitation, the background is included twice.
05:27:00 [cyril]
Note that
05:27:02 [cyril]
using feBackground has the effect of the background being used twice – once
05:27:03 [cyril]
as an input in the filter – and a second time as the result being drawn onto….
05:27:05 [cyril]
If the background is not initially opaque this causes strange effects.
05:28:06 [vhardy]
rc: I have proposed to separate the spec. in two. For PD, you never need the background.
05:34:45 [vhardy]
rc: explains the way PD happens within a group and does not effect anything outside the group.
05:34:57 [vhardy]
05:35:03 [vhardy]
<rect id="r1">
05:35:06 [vhardy]
05:35:12 [vhardy]
<rect id="r2">
05:35:16 [vhardy]
<rect id="r3">
05:35:17 [vhardy]
05:35:59 [vhardy]
No matter what the compositing operator is on r3, it only composites with the content of <g> at the time it is rendered. In this example, only with r2. There is no compositing done with r1 when rendering r3.
05:36:18 [vhardy]
The rendering of <g> will then composite with r1.
05:38:02 [Anthony]
06:07:12 [vhardy]
Discussion on enable-background and compositing, looking at the examples in section 8 of
06:07:13 [vhardy]
There is agreement that compositing is done between a src and dst and that following the painter's algorithm, the default dst would be the content of the parent group at the time an element is rendered (i.e., the rendering of the element's previous siblings in the parent group). There might be use cases for compositing with the a destination that contains the rendering of the parent group's siblings. In the preceding example, it means that r3 would
06:07:13 [vhardy]
composite with either the content of its parent group (r2 only) or, in a different mode, with the content of r1 and what is already in it's parent group (r2).
06:08:06 [vhardy]
ag: the reason for the naming of new/accumulate is that it describes the initialization of the group buffer used with compositing.
06:11:00 [vhardy]
ACTION: cyril to work with Rik and discuss with Alex to resolve whether, for the purpose of compositing only, we need a control to select the destination used for the compositing operation.
06:11:00 [trackbot]
Created ACTION-3221 - Work with Rik and discuss with Alex to resolve whether, for the purpose of compositing only, we need a control to select the destination used for the compositing operation. [on Cyril Concolato - due 2012-01-20].
06:11:35 [vhardy]
Moving on to blending.
06:11:43 [vhardy]
(discussion about enable-background in blending context).
06:12:04 [vhardy]
06:12:10 [vhardy]
<rect id="r1">
06:12:11 [vhardy]
06:12:16 [vhardy]
<rect id="r2">
06:12:17 [vhardy]
06:12:22 [vhardy]
r2 is multiply
06:12:52 [vhardy]
g is is enable-background: accumulate
06:29:23 [vhardy]
Agreement that in both compositing and blending, the behavior and controls for enable-background are the same. In both cases, the need is to control how the 'group' buffer is initialized before it is used as an input in the blending or compositing operation.
06:31:11 [Anthony]
Anthony has joined #svg
06:39:59 [vhardy]
(demo of compositing, blending and knockout groups in a popular illustration authoring tool)
06:40:22 [ed]
RRSAgent, make minutes
06:40:22 [RRSAgent]
I have made the request to generate ed
06:41:16 [cabanier]
example of knockout and enable-background:
06:41:51 [vhardy]
RESOLUTION: the group agrees to separate compositing from blending in the specification. The group agrees to add the missing blend modes. The group agrees to have the default blend mode to be 'normal'.
06:42:37 [vhardy]
ACTION: rik to resolve issues on clip-to-self, enable-background on compositing and knock-out.
06:42:38 [trackbot]
Created ACTION-3222 - Resolve issues on clip-to-self, enable-background on compositing and knock-out. [on Rik Cabanier - due 2012-01-20].
06:43:17 [ed]
RRSAgent, make minutes
06:43:17 [RRSAgent]
I have made the request to generate ed