IRC log of svg on 2015-06-12

Timestamps are in UTC.

07:25:29 [RRSAgent]
RRSAgent has joined #svg
07:25:29 [RRSAgent]
logging to http://www.w3.org/2015/06/12-svg-irc
07:26:33 [ed]
chair: Erik
07:26:47 [ed]
Meeting: Linköping F2F day 4
07:27:01 [ed]
Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals
07:27:11 [heycam]
Scribe: Cameron
07:27:14 [heycam]
ScribeNick: heycam
07:27:27 [BogdanBrinza]
BogdanBrinza has joined #svg
07:27:47 [heycam]
Topic: Whether writing-mode should have a presentation attribute
07:28:48 [heycam]
heycam: adding a presentation attribute would violate our rule of not adding any new presentation attributes
07:28:56 [heycam]
Tav: I think it should have one
07:29:13 [heycam]
krit: it shouldn't be a problem implementation wise
07:29:25 [heycam]
ed: I would prefer having it, for consistency
07:30:34 [heycam]
heycam: text-orientation is the third one that works together with direction and writing-mode
07:31:37 [heycam]
Tav: add that too then
07:32:46 [heycam]
Tav: we treat everything as presentation attribtues anyway
07:32:57 [heycam]
krit: for us it's a white list so we would need to add these things to a list
07:34:48 [heycam]
heycam: a middle point would be to add presentation attributes for all properties that have an effect on SVG elements
07:35:02 [Tav]
Tav has joined #svg
07:35:02 [heycam]
... but we'd need to go through all properties to decide
07:36:14 [heycam]
Rossen: I would prefer not having presentation attribute for witing-mode
07:36:30 [heycam]
... if we have a white list of allowed presentation attributes, I'd like that to be defined in an automated way
07:36:46 [heycam]
... so that if CSS gains new properties we don't need to update the list of presentation attributes
07:37:09 [heycam]
... doing one off things seems random, but having all properties as presentation attributes seems like overkill
07:39:55 [heycam]
Tav: we need something in the spec now
07:40:27 [heycam]
heycam: yes I plan to add a list to the Styling chapter
07:40:36 [BogdanBrinza]
BogdanBrinza has joined #svg
07:41:18 [heycam]
ACTION: Cameron to present a few different ways of defining the list of presentation attributes to support
07:41:18 [trackbot]
Created ACTION-3806 - Present a few different ways of defining the list of presentation attributes to support [on Cameron McCormack - due 2015-06-19].
07:41:34 [heycam]
Topic: shadow trees on text content elements and text positioning attributes
07:42:26 [heycam]
heycam: we had a bug filed with something putting x and y attributes on a text and a shadow tree on a tspan
07:42:37 [heycam]
... do the x and y attributes apply to the shadow tree contents?
07:42:46 [heycam]
ed: was there a test case?
07:43:37 [heycam]
heycam: can't find the test right now
07:43:43 [heycam]
ed: don't know how blink would deal with this
07:45:10 [stakagi]
stakagi has joined #svg
07:48:56 [heycam]
ed: you could also put the text positioning attributes on shadow tree contents
07:50:20 [heycam]
heycam: maybe that argues for assigning the x/y to the shadow tree characters
07:50:33 [heycam]
Tav: you do have take the shadow tree contents into account when say text-anchor:middle centering
07:51:01 [heycam]
Tav: would there be a place where you replace the content?
07:52:11 [heycam]
... I guess we just have to define a default behaviour and let the user figure it out
07:52:39 [heycam]
heycam: OK I will make the x/y apply to characters in the shadow tree as I write up the text layout algorithm
07:53:06 [heycam]
ACTION: Cameron to attempt to make text positioning attributes apply to shadow tree content
07:53:06 [trackbot]
Created ACTION-3807 - Attempt to make text positioning attributes apply to shadow tree content [on Cameron McCormack - due 2015-06-19].
07:53:32 [heycam]
Topic: how textPath works with path seg lists
07:53:42 [heycam]
ed: SVG 2 has added a d attribute to textPath
07:53:45 [heycam]
... previously you could only link to a path
07:53:57 [heycam]
... and I think the spec currently says that if you have both href and d that it picks the d
07:54:15 [heycam]
... it's implementing SVGAnimatedPathData now too, which is where the pathSegList accessors are
07:54:30 [heycam]
... the spec says that if you href to a path, it should be exposed through those APIs
07:54:33 [heycam]
... and I don't think that's a good idea
07:54:42 [heycam]
... if you really want the other path element that defines the textPath, you can just go grab that
07:54:46 [heycam]
... and use the same methods there
07:54:50 [heycam]
... instead of trying to make some magic here
07:55:11 [heycam]
... so I think textPath should only return the d attribute and nothing else
07:55:13 [heycam]
heycam: I agree
07:55:16 [heycam]
nikos: yep
07:55:19 [heycam]
Tav: sounds good
07:55:41 [heycam]
RESOLUTION: pathSegList on textPath should only reflect the d attribute, not the href'ed path
07:55:53 [ed]
https://svgwg.org/svg2-draft/text.html#TextPathElementDAttribute
07:56:00 [heycam]
ACTION: Erik to make pathSegList on textPath only reflect the d attribute, not the href'ed path
07:56:00 [trackbot]
Created ACTION-3808 - Make pathseglist on textpath only reflect the d attribute, not the href'ed path [on Erik Dahlström - due 2015-06-19].
07:56:24 [heycam]
Topic: adding pathLength to textPath
07:56:34 [heycam]
ed: if you link to a path, then that path can have pathLength
07:56:45 [heycam]
... not sure if we have other cases where we have d attributes and pathLength?
07:56:54 [heycam]
krit: is it really required to have pathLength on path?
07:57:00 [heycam]
ed: it's not required, just asking if we should have it
07:57:11 [heycam]
ed: if you want, you can link to a path element, and that works
07:57:18 [heycam]
krit: yes, if you want it, you can do that
07:57:21 [heycam]
... I wouldn't add it
07:57:41 [heycam]
Tav: if you want to align something exactly you can always reference a <path>
07:58:00 [heycam]
RESOLUTION: We won't add pathLength to <textPath>
07:58:25 [heycam]
Topic: Add x/y/dx/dy to textPath
07:58:32 [heycam]
Tav: if we're not adding the others, no reason to add this
07:58:38 [heycam]
ed: I thought it was already possible to do this?
07:59:02 [heycam]
heycam: you can put them on a parent tspan, and it has the expected effect, but you can't have them on the textPath
08:00:02 [heycam]
Tav: you can already do this effect on tspan parent, so just leave it at that
08:00:13 [heycam]
heycam: I agree. let's not try to improve these text positioning attributes any more.
08:00:35 [heycam]
RESOLUTION: We won't add text positioning attributes to textPath
08:01:36 [heycam]
Topic: transform-origin on SVG elements
08:01:47 [heycam]
https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html
08:01:56 [heycam]
heycam: that's my proposed spec wording to handle this -- using a UA style rule
08:02:17 [heycam]
krit: so for SVG elements you'll get a default value of 0 0
08:02:29 [heycam]
heycam: for non-outer-<svg> SVG elements
08:03:59 [heycam]
krit: WebKit and Blink already use UA style rules to do this
08:04:05 [heycam]
... our rules might not be fully correct
08:04:13 [heycam]
... the one that Cameron posted should be OK
08:04:36 [heycam]
Rossen: and leave the initial value as it is?
08:04:38 [heycam]
heycam: yes
08:06:26 [heycam]
Rossen: the other way to do this is auto
08:06:35 [heycam]
... which is the usual way the CSS WG handles this kind of thing
08:07:03 [heycam]
heycam: I don't mind auto either
08:07:08 [heycam]
Rossen: we'll discuss this in CSS
08:07:24 [jun]
jun has joined #svg
08:07:48 [heycam]
Topic: Impact of CSS Transforms Level 2 on SVG
08:07:57 [heycam]
ed: there's some implementation work going on in Blink for this
08:08:30 [heycam]
krit: the Transforms 2 spec just adds the rotate, translate, scale properties and defines how they interact with transform
08:08:45 [heycam]
ed: right now the spec says that percentages are resolved according to the containing block, is that what we want in SVG?
08:08:50 [heycam]
krit: border box in SVG is complicated
08:08:58 [heycam]
... we have the transform-box property which lets you switch between bounding box and viewport
08:09:02 [heycam]
ed: doesn't say anything about that here
08:09:05 [heycam]
krit: that's in Transforms 1
08:09:37 [heycam]
ed: whether or not these properties should be made presentation attributes, too
08:09:46 [heycam]
ed: rotate would clash with rotate on text
08:10:05 [heycam]
krit: transform and transform-origin are presentation attributes
08:10:21 [heycam]
heycam: I don't think we support transform-origin as a presentation attribute
08:10:26 [heycam]
krit: but in WebKit/Blink we do
08:12:14 [heycam]
krit: I do not expect any problems with SVG here
08:12:21 [heycam]
... it's a good question to ask whether to make these presentation attributes
08:12:44 [heycam]
Tav: if you have transform and rotate? ti's determined what happens?
08:12:48 [heycam]
krit: yes, the order is fixed
08:12:54 [heycam]
... rotate is always applied before transform
08:13:22 [heycam]
heycam: I would say don't add presentation attributes for these right now
08:13:32 [heycam]
... and otherwise I don't think any other SVG considerations apply
08:13:52 [heycam]
Topic: definitions in Transforms Level 1
08:15:55 [heycam]
heycam: I spoke with takagi-san yesterday about this
08:16:15 [heycam]
... he has prepared some diffs to the Transforms spec for the definitions needed for reference
08:16:29 [heycam]
... he has prepared some diffs to the Transforms spec for the definitions needed for reference from the non-scaling features of SVG
08:16:57 [heycam]
... he wanted to know whether they should go in Transforms Level 1 or 2
08:17:00 [heycam]
krit: it should be 2
08:17:17 [heycam]
heycam: I suggest then to email Tab with the definitions, and a reminder of the discussions we had in Sydney, and he can add them to that spec
08:17:22 [heycam]
... then we can reference them from SVG
08:17:32 [heycam]
http://svg2.mbsrv.net/devinfo/devstd/CSS_Transforms_Diff/
08:19:38 [heycam]
Tav: there's an issue with preserve-3d in there
08:19:39 [heycam]
Tav: suppose you have a box, you rotate the box, the vector-effect would make each of those sides the same, you flatten it, you can't do anything after that
08:19:54 [heycam]
krit: there is a term in the spec for applying effects until the point that you flatten
08:20:05 [heycam]
... vector-effect is not intended for use with 3D transforms
08:21:16 [heycam]
Topic: SVGTransformList
08:21:19 [krit]
file:///Users/dschulze/Documents/svgwg/build/publish/coords.html#InterfaceSVGAnimatedTransformList
08:21:25 [heycam]
krit: I added a bit of normative text to SVGAnimatedTransformList
08:21:45 [krit]
https://svgwg.org/svg2-draft/coords.html#InterfaceSVGAnimatedTransformList
08:22:10 [heycam]
krit: we have the transform animVal and baseVal
08:22:13 [heycam]
... for the transfom attribute
08:22:26 [heycam]
... now that we have the transform property, the question is what do you get if you get/set baseVal
08:22:43 [heycam]
... what I wrote here is that the SVGTransformList always just reflects the attribute
08:22:45 [heycam]
... not the style value
08:23:06 [heycam]
heycam: we discussed this before and that's the behaviour we agreed on
08:24:25 [heycam]
-- fika --
08:56:04 [jun]
jun has joined #svg
08:58:18 [stakagi_]
stakagi_ has joined #svg
09:01:17 [BogdanBrinza]
BogdanBrinza has joined #svg
09:01:24 [heycam]
Topic: Coordinates chapter
09:01:35 [heycam]
krit: in this chapter we have some definitions that need updates
09:01:50 [heycam]
... the first is "canvas", which says there's a physical space with a virtual infinite bounds that things can be drawn on
09:01:56 [heycam]
... and "SVG canvas" is an instance of "canvas"
09:02:01 [heycam]
... but that definition doesn't add any value
09:02:09 [heycam]
... the problem here is really "SVG viewport"
09:02:19 [heycam]
"The viewport within the SVG canvas which defines the rectangular region into which SVG content is rendered. See the discussion of the SVG viewport in the chapter on Coordinate Systems, Transformations and Units."
09:02:24 [heycam]
... which implies the content is clipped to the bounds
09:02:30 [heycam]
... especially if you have overflow visible, that's not the case
09:02:42 [heycam]
... the question is how do we define "SVG viewport" and what does it do
09:02:53 [heycam]
... as in CSS, it's something like a containing block, that is a reference for sizing some content
09:03:03 [heycam]
Rossen: can't you define it as a rectangle for clipping if overflow is set appropriately
09:03:10 [heycam]
krit: there's also another definition "initial clip path"
09:03:19 [heycam]
Rossen: that's pretty much your viewport then
09:03:26 [heycam]
nikos: what about the rectangular region that maps to the view box
09:03:33 [heycam]
krit: vice versa
09:03:36 [heycam]
nikos: it's just defining that space
09:03:50 [heycam]
krit: the change to make across the spec is to only use "SVG viewport", not "viewport"
09:04:09 [heycam]
... if you define viewport as a boundary, that can be used for clipping if overflow:hidden, or gives the boundaries for overflow:scroll
09:04:19 [heycam]
... it's the rectangle viewBox is mapped to
09:04:26 [heycam]
... and it's the box that percentages are resolved against
09:04:32 [heycam]
... is that something we can agree on?
09:04:36 [heycam]
Rossen: does need to be rectangular?
09:04:38 [ed]
ed has joined #svg
09:04:40 [heycam]
krit: that's the current definition
09:04:42 [heycam]
Rossen: currently
09:04:50 [heycam]
krit: so currently it has to have width/height
09:04:56 [heycam]
... so I would define it as a rectangular boundary
09:05:04 [heycam]
Rossen: at some point we're going to have to deal with round displays
09:05:23 [heycam]
krit: right. that would still, even for round displays, have an a width/height extent
09:05:32 [heycam]
nikos: round with a different coordinate system?
09:05:42 [heycam]
krit: CSS WG is talking about that, with polar coordinates; just for positioning
09:05:49 [heycam]
nikos: so the polar coordinates just map to a position
09:05:53 [heycam]
nikos: yes, still a cartesian coordinate system
09:06:01 [heycam]
... but positions are mapped from polar coordinates
09:06:06 [heycam]
s/nikos/krit/
09:06:20 [heycam]
krit: any objection to remove the term "canvas"?
09:06:29 [heycam]
nikos: there are a lot of areas in the spec where you want to say something that you're rendering on to
09:06:36 [heycam]
Tav: and to make it clear that it extends infinitely
09:06:47 [heycam]
krit: do we need this reference to physical media and computer memory?
09:06:54 [heycam]
nikos: make it more abstract than that
09:07:18 [heycam]
krit: the spec generally only references canvas and viewport, not SVG canvas and SVG viewport
09:07:32 [heycam]
... I think the idea here was to have ad istinction between host rendering and SVG rendering, but nowadays that doesn't matter
09:07:44 [heycam]
nikos: wasn't to distinguish from HTML <canvas>?
09:07:51 [heycam]
heycam: no that was before this text was written
09:07:55 [heycam]
Rossen: the spec doesn't reference SVG canvas
09:08:07 [heycam]
krit: the SVG viewport defines initial clipping for overflow property
09:08:19 [heycam]
... do I need to mention specific values of overflow?
09:08:20 [heycam]
Rossen: no
09:08:31 [ed]
s/the spec/other specs
09:08:32 [heycam]
krit: then we have a definition of viewport coordinate system and user coordinate system
09:08:48 [heycam]
... and that viewport space = viewport coordinate system, and user space = user coordinate system
09:08:53 [heycam]
... we should just have single terms for these things
09:09:06 [heycam]
... the Transforms spec uses "local coordinate system", which I'd actually prefer
09:09:11 [heycam]
ed: is there a difference?
09:09:12 [heycam]
krit: no
09:09:15 [heycam]
ed: I'd prefer local too, then
09:09:37 [heycam]
Tav: the term "user units" is used a lot everywhere
09:09:48 [heycam]
... there's a history of using that term, even outside the spec
09:10:05 [heycam]
krit: would you suggest Erik replacing all user * things with local *?
09:10:25 [heycam]
ed: user sounds custom, local coordinate system sounds pretty clear
09:10:35 [heycam]
nikos: local is generally the term that's used, I think
09:10:50 [heycam]
krit: can we agree to change?
09:11:03 [heycam]
nikos: I agree in theory but we do have keywords like userSpaceOnUse
09:11:41 [heycam]
krit: CSS transforms already defines user coordinate system = local coordinate system
09:13:18 [heycam]
krit: there is some wording about establishing viewports and the "viewport coordinate system"
09:13:34 [heycam]
... for me, that's redundant, you map the coordinate system between parents and children
09:13:48 [heycam]
Tav: aren't percentages are in terms of viewport coordinate system?
09:14:00 [heycam]
... throughout the spec if you say percentages of the viewport, you don't need the term "viewport coordinate system"
09:14:22 [heycam]
krit: my guess is that it wants to distinguish between transforms that apply to content, and transforms that apply to the host document
09:14:43 [heycam]
Tav: is that term used anywhere else in the document?
09:14:54 [heycam]
krit: yes, introduction, painting, coords
09:15:30 [heycam]
nikos: in the vector-effects section, you could just say nested viewports couldn't you
09:15:37 [heycam]
krit: I'll work something out for that section and propose it
09:15:45 [heycam]
krit: next, the Initial coordinate system
09:15:59 [heycam]
... it says there is a viewport coordinate system and a user coordinate system and they are initially identical, and origin is at the top left
09:16:05 [heycam]
... not sure if this should be part of the rendering chapter, or to keep it here
09:16:13 [heycam]
... these definitions could do with some trimming
09:16:20 [heycam]
nikos: I think it makes sense to have it there
09:16:27 [heycam]
krit: I'd still like to reduce the text, it's a bit verbose
09:16:36 [heycam]
... and now, the "initial viewport"
09:16:48 [heycam]
krit: we have a few use cases of SVG, as a root document, or embedded, or inline, ...
09:16:56 [heycam]
... all these scenarios need to be specified somehow
09:17:06 [heycam]
... didn't find what viewport units means for a root document
09:17:24 [heycam]
... if width/height are auto, we don't have intrinsic size/ratio
09:17:33 [heycam]
... what's the size of the viewport then. usually it's the size of the window, right?
09:17:45 [heycam]
... which brings us to the initial of not defining what the initial containing block is
09:17:51 [heycam]
... vw and vh units need that to resolve against
09:18:21 [heycam]
... the containing block is usually the size of the window, when you test it
09:18:29 [heycam]
... how does CSS define the size of the ICB?
09:18:44 [heycam]
Rossen: it's defined as the first fragment, whether it's a page in a print media, or the size of the window, in a continuous media
09:18:52 [heycam]
... we can just refer to the same things as CSS
09:18:57 [heycam]
... I think it's section 9.5 or something
09:20:11 [heycam]
... the initial value of width/height properties are auto, which will resolve to 100% of the ICB
09:20:24 [heycam]
krit: when we have intrinsic ratio, and no sizing, that would also resolve against the ICB, yes?
09:20:25 [heycam]
Rossen: yes
09:21:20 [heycam]
krit: if you have intrinsic sizing, then the viewport would definted by the intrinsic sizing, which is not necessarily the same size as the ICB
09:21:31 [heycam]
... now, we come to the section about embedding SVG content
09:21:56 [heycam]
... the "establishing an ew SVG viewport" section, and "intrinsic sizing properties" section, which both try to define this but fail
09:22:06 [heycam]
... I would keep "establishing a new SVG viewport', which just says which elements do that
09:22:25 [heycam]
... "initial viewport" should reference an algorithm we define in the "intrinsic sizing properties" section
09:22:37 [heycam]
... plus of course everything for the root SVG, in case of not being hosted in a document
09:22:41 [heycam]
ed: because it's duplicated information?
09:22:52 [heycam]
krit: at the moment, embedded content is defined in multiple places
09:22:58 [heycam]
... I just want to put all the sizing information in the one place
09:23:20 [heycam]
... now, for embedding
09:23:28 [heycam]
... we had the presentation from David Vest in Leipzig
09:23:32 [heycam]
... which I won't go through now
09:23:35 [heycam]
... it's pretty simple generally
09:23:50 [heycam]
... you always have the containing block, which defines the sizing (or not) depending on the value of width/height on the root
09:25:30 [heycam]
[shows some examples]
09:33:52 [heycam]
krit: if you have an intrisic ratio, but no width/height, what should happen?
09:33:58 [heycam]
... it falls back to the replaced element algorithm?
09:36:19 [heycam]
Tav: can you work offline with Rossen on this?
09:36:20 [heycam]
krit: sure
09:38:44 [heycam]
Topic: pAR defer
09:38:46 [heycam]
http://mcc.id.au/temp/defer.svg
09:40:51 [heycam]
heycam: so in Edge, defer is not supported, in Firefox it is, in Blink the effect is basically "always defer"
09:41:04 [heycam]
... i.e. pAR on <image> is ignored when referencing an SVG image
09:41:30 [heycam]
krit: if you have an image with pAR on it, Blink and WebKit would follow it, but not the overriding one on the <image>
09:44:33 [heycam]
ed: I think defer is kind of useless
09:44:39 [heycam]
krit: I think the whole negotiation process is useless
09:46:20 [heycam]
ed: defer is ignored in all pARs other than on <image>
09:46:50 [ed]
https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute
09:48:26 [heycam]
heycam: removing defer altogether, and making it a parse error, is probably safe
09:48:28 [heycam]
ed: I agree
09:49:04 [heycam]
krit: I don't care, removing it or not
09:49:10 [heycam]
ed: the bug fixes that would be needed are unrelated to defer
09:50:43 [heycam]
RESOLUTION: We will refer the defer keyword from pAR; encountering it would be a parse error.
09:50:50 [heycam]
ACTION: Cameron to remove pAR's defer keyword.
09:50:50 [trackbot]
Created ACTION-3809 - Remove par's defer keyword. [on Cameron McCormack - due 2015-06-19].
09:52:18 [heycam]
Topic: blending with backdrop of multiple fill/stroke
09:52:29 [heycam]
krit: I looked at what photoshop, illustrator, and some other tools are doing
09:52:40 [heycam]
... they support multiple fills and strokes, they will be drawn on top of each other
09:52:43 [heycam]
... can also support a blend mode
09:52:47 [heycam]
... but they also blend with the backdrop
09:52:51 [heycam]
... where we said we would isolate them
09:52:58 [heycam]
... so I would suggest that we remove this isolation requirement
09:53:01 [heycam]
Tav: how does that work?
09:53:22 [heycam]
... render the second blended with the backdrop that already has the first fill blended into it?
09:54:08 [heycam]
... and if you isolate it?
09:54:16 [heycam]
nikos: you only blend among the fills
09:54:23 [heycam]
s/you/then you/
09:54:31 [heycam]
... if you specify opacity on the shape at all, it will become isolated
09:54:36 [heycam]
krit: yes normal isolation requirements apply
09:55:58 [heycam]
nikos: is there a way to control the isolation within the fills?
09:55:59 [heycam]
krit: no
10:00:52 [krit]
Rossen: http://dev.w3.org/fxtf/compositing-1/#csscompositingrules_CSS
10:01:42 [jun]
jun has joined #svg
10:02:21 [heycam]
RESOLUTION: Multiple fills and strokes are not isolated; they are all blended with the backdrop
10:02:49 [heycam]
ACTION: Dirk to update the Painting chapter about multiple fills/strokes not isolating
10:02:49 [trackbot]
Created ACTION-3810 - Update the painting chapter about multiple fills/strokes not isolating [on Dirk Schulze - due 2015-06-19].
10:03:12 [heycam]
Topic: publishing another WD of SVG 2
10:04:17 [heycam]
heycam: let's publish another WD after this week of edits
10:04:18 [heycam]
all: ok
10:04:30 [heycam]
RESOLUTION: Publish a new WD of SVG 2 next week
10:04:36 [heycam]
ACTION: Cameron to organise another SVG 2 WD publication
10:04:37 [trackbot]
Created ACTION-3811 - Organise another svg 2 wd publication [on Cameron McCormack - due 2015-06-19].
10:05:00 [heycam]
Topic: F2F planning
10:05:16 [heycam]
ed: Google are hosting CSS in Sydney
10:05:24 [heycam]
... they asked us whether we would like to meet there too
10:05:45 [heycam]
Rossen: there will most likely be a Houdini meeting next to it
10:06:16 [heycam]
... the feedback from the CSS WG that's worth pulling forward is that there were a number of members found travelling to Australia expensive
10:06:23 [heycam]
... especially those travelling on smaller (or their own) budget
10:06:27 [heycam]
... that was the one pushback
10:06:43 [heycam]
... Shane as one of the organizers put a number of hotels in the planning wiki
10:06:48 [heycam]
... it's worth looking and booking in advance, especially for hotels
10:07:50 [heycam]
nikos: we were thinking that if you were coming to Sydney, we'd (Canon) would offer too
10:07:53 [heycam]
... but Shane got in first
10:08:06 [heycam]
... I don't know how convenient that would be if people are already going to Google
10:08:12 [heycam]
... our office which is a 20 minutes train ride out of the city
10:08:38 [heycam]
Rossen: unless Google has a problem to host this for the extra couple of SVG days, I don't see why we'd change location
10:08:41 [heycam]
... it's very nice of you to offer
10:08:51 [heycam]
... but since they have offered, and we are already there
10:09:19 [heycam]
krit: are the dates fixed already?
10:09:35 [heycam]
Rossen: we at least resolved on the week
10:09:56 [Rossen]
https://wiki.csswg.org/planning/sydney-2016
10:10:04 [heycam]
Jan 19-21
10:10:16 [heycam]
s/Jan 19-21//
10:10:27 [heycam]
Feb 1-5
10:11:08 [heycam]
heycam: so SVG would be just before or after the weekend around that
10:12:16 [heycam]
Rossen: would prefer to meet on the weekend, to avoid extending the trip further
10:13:31 [heycam]
so either Jan 30-31, or Feb 6-7
10:13:39 [heycam]
depend on which end of the week houdini is meeting
10:15:28 [heycam]
Tav: would prefer a third SVG meeting day
10:15:31 [heycam]
... to make it worthwhile coming
10:16:31 [heycam]
RESOLUTION: Tentative resolution that we meet for 3 days either right before or right after the CSS/Houdini meetings in Sydney
10:16:51 [heycam]
Topic: Upcoming TPAC meeting
10:17:02 [heycam]
ed: unless I have some funding I probably won't come
10:17:07 [heycam]
Tav: I'm definitely not going
10:17:25 [heycam]
... as it'd only be a day and a half of SVG, based on prior experience, everyone's tired by the end of Friday
10:18:27 [shane]
Houdini Jan 30-31 I think.
10:19:37 [heycam]
heycam: I probably can't come now
10:19:47 [heycam]
krit: I won't be there
10:20:11 [heycam]
Rossen: so without the chairs, and half of the regulars not there
10:20:21 [heycam]
ed: do we want to have a meeting somewhere/somewhen else?
10:20:29 [heycam]
Tav: another option could be Paris, after CSS
10:20:33 [heycam]
Rossen: for me that's a hard no
10:20:40 [heycam]
... I've got CSS, Houdini, then vacation
10:20:43 [heycam]
... which is already planned
10:21:14 [heycam]
Rossen: this time CSS is meeting Tue-Thu, not sure why that is, then Houdini is Fri/Sat
10:21:33 [Rossen]
https://wiki.csswg.org/planning
10:21:35 [heycam]
Rossen: so Aug 25-27, followed by Houdini 28-29
10:21:53 [heycam]
krit: I will be at both of those
10:22:00 [heycam]
krit: I could attend an SVG meeting before then
10:22:47 [heycam]
krit: first, the Australians/Japanese, would you be able to attend?
10:23:02 [heycam]
stakagi_: for me no problem
10:23:09 [jun]
jun has joined #svg
10:23:15 [stakagi]
stakagi has joined #svg
10:23:28 [heycam]
ed: could also do Pittsburgh? though there would be more people in Paris.
10:23:35 [stakagi__]
stakagi__ has joined #svg
10:23:59 [ed]
ed has joined #svg
10:24:00 [heycam]
nikos: I couldn't get there before 25th
10:24:53 [heycam]
krit: I couldn't go to Pittsburgh, as I have to fly to the US two weeks later
10:25:00 [heycam]
Rossen: we could organise something in Seattle?
10:25:08 [heycam]
krit: my trip might not be flexible
10:26:58 [heycam]
krit: so in Paris would be Aug 22-24?
10:27:09 [heycam]
ed: I'm booked that weekend
10:28:43 [heycam]
krit: we could just have a spec hacking session
10:28:55 [heycam]
heycam: so right after Houdini seems like the dates best for most people, except Rossen
10:29:57 [heycam]
Rossen: so that would be Aug 31 - Sep 2
10:32:42 [heycam]
RESOLUTION: We cancel the TPAC 2015 SVG meeting.
10:33:59 [ed]
ed has joined #svg
10:34:20 [Tav]
Tav has joined #svg
10:34:30 [jun]
jun has joined #svg
10:34:43 [fs]
fs has joined #svg
10:35:09 [heycam]
RESOLUTION: We will tentatively try to meet in Paris after CSS/Houdini in Aug/Sep.
10:36:35 [heycam]
-- lunch --
10:36:43 [heycam]
RRSAgent: remind me in 4 hours to do something
10:36:43 [RRSAgent]
I'm logging. I don't understand 'remind me in 4 hours to do something', heycam. Try /msg RRSAgent help
10:36:51 [stakagi]
stakagi has joined #svg
11:03:30 [ed_work_]
ed_work_ has joined #svg
11:15:33 [ed_work__]
ed_work__ has joined #svg
11:24:22 [ed_work__]
ed_work__ has joined #svg
11:44:06 [jun]
jun has joined #svg
12:15:10 [stakagi]
stakagi has joined #svg
12:28:30 [jun]
jun has joined #svg
12:39:08 [BogdanBrinza]
BogdanBrinza has joined #svg
12:41:49 [ed]
ed has joined #svg
12:52:54 [BogdanBrinza]
To test IE11 on Mac/Linux go to http://dev.modern.ie/ and then Tools > RemoteIE
12:57:24 [krit]
BogdanBrinza: it is just so much easier to ask you to check it :P
13:06:06 [AmeliaBR]
AmeliaBR has joined #svg
13:09:48 [krit]
heycam: Does FF nightly use the UA style sheet rule for transform-origin currently?
13:11:10 [krit]
found it
13:11:14 [krit]
: svg.css:57;
13:11:14 [krit]
: :not(svg)0px 0px 0px;
13:21:17 [shepazu]
ACTION: Amelia to look at SVG spec for references to <use> element, to make sure there is no confusion about implementation/accessibility.
13:21:17 [trackbot]
Created ACTION-3812 - Look at svg spec for references to <use> element, to make sure there is no confusion about implementation/accessibility. [on Amelia Bellamy-Royds - due 2015-06-19].
13:31:09 [ed]
https://github.com/w3c/svgwg/issues/18
13:35:39 [ed]
https://github.com/w3c/svgwg/issues/20
13:36:00 [ed]
^ would like these two resolved
14:00:21 [ed]
https://github.com/w3c/svgwg/graphs/commit-activity
14:04:10 [Rossen]
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Embedded_Content_.28Bogdan.29_.5Breadiness_4.5D
14:04:38 [Rossen]
https://github.com/w3c/svgwg/graphs/commit-activity
14:39:03 [Tavmjong]
Tavmjong has joined #svg
14:58:12 [nikos]
Trackbot, ACTION-3724?
14:58:12 [trackbot]
ACTION-3724 -- Dirk Schulze to Do testing around currentscale, ctm, transform, viewport, etc. on 'svg' element -- due 2015-02-19 -- OPEN
14:58:12 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/actions/3724
15:16:04 [heycam]
RRSAgent: make logs public
15:16:23 [heycam]
RRSAgent: make minutes
15:16:23 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/06/12-svg-minutes.html heycam
15:17:29 [heycam]
Present: Rossen, Bogdan, Nikos, Cameron, Frederick, Dirk, Erik, Tav, Satoru, Jun
15:17:31 [heycam]
Chair: Erik
15:17:49 [heycam]
RRSAgent: make minutes
15:17:49 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/06/12-svg-minutes.html heycam
15:36:13 [jun]
jun has joined #svg
16:10:01 [Tavmjong]
Tavmjong has joined #svg