IRC log of svg on 2016-02-05

Timestamps are in UTC.

00:00:00 [birtles]
<break 15min>
00:20:02 [nikos]
AmeliaBR: ping we're back
00:21:31 [heycam]
ScribeNick: heycam
00:22:10 [heycam]
Topic: SVG Integration spec
00:22:18 [heycam]
nikos: Bogdan will be an editor of this spec
00:22:31 [heycam]
BogdanBrinza: there are a few issues that might be worth discussing and knocking out
00:22:39 [heycam]
... might be more of an FYI
00:23:01 [BogdanBrinza]
https://svgwg.org/specs/integration/
00:23:22 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue1
00:23:37 [heycam]
... first issue is all the different scenarios of SVG integration
00:23:41 [heycam]
... foreignObject, CSS context
00:24:15 [heycam]
... the thing that is mostly concerned for CSS/SVG implementaors is sizing SVG documents in CSS, sizing HTML content in foreignObject
00:24:24 [heycam]
... can you give me a sense of the relative priority of other things?
00:24:39 [heycam]
... metadata?
00:24:43 [heycam]
heycam: not important, focus on the sizing
00:24:54 [heycam]
BogdanBrinza: so with initial containing block with foreignObject viewport, I don't think this is an issue
00:25:03 [heycam]
... for CSS sizing I have half of the change in progress, still working on that
00:25:10 [heycam]
... don't think anything else in issue 1 needs talking now
00:25:15 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue2
00:25:36 [heycam]
... issue 2, this talks about referencing the Fetch algorithm
00:26:18 [heycam]
heycam: this is about CORS etc.
00:26:29 [heycam]
BogdanBrinza: not sure how this applies to referencing modes though
00:27:23 [heycam]
heycam: sounds like it might be better to reference the Fetch spec from different places in the SVG spec then, e.g. in the <image> definition etc.
00:27:31 [heycam]
ed: agreed
00:27:43 [heycam]
AmeliaBR: maybe we'd want to use Anonymous mode for resource documents for example
00:27:56 [heycam]
BogdanBrinza: sounds likes an extension of the referencing mode rather than something about the Fetch algorithm
00:28:16 [heycam]
AmeliaBR: I don't think we have any referencing modes where Anonymous mode is explicitly mentioned
00:29:37 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue3
00:29:40 [heycam]
BogdanBrinza: issue #3 now
00:29:47 [heycam]
AmeliaBR: animations in resource documents
00:30:22 [heycam]
BogdanBrinza: just looking at the issue and the context around the issue, I don't think anything int he current wording suggests they shouldn't run
00:30:41 [heycam]
AmeliaBR: an example is using content from another file, and that file has declarative animations, then should your reused copy of that reflect those animations
00:30:51 [heycam]
BogdanBrinza: why not?
00:30:57 [heycam]
AmeliaBR: I don't see an issue
00:31:05 [heycam]
BogdanBrinza: so you define the resource, as part of the definition there are some animations
00:31:14 [heycam]
... saying there shouldn't be any animations running doesn't make sense to me
00:32:00 [heycam]
AmeliaBR: one issue that has come up before which we have waffle language in SVG 2 about is that resource documents don't have a medium, so has problems with media queries, resolving percentages
00:32:44 [heycam]
Rossen: 300x150!
00:32:48 [heycam]
heycam: yes, why not
00:33:26 [heycam]
BogdanBrinza: so if the resource references percentages how do they get resolved
00:33:27 [heycam]
ed: right
00:33:53 [heycam]
BogdanBrinza: similar to background-image?
00:33:56 [heycam]
AmeliaBR: this is SVG resources
00:34:17 [heycam]
ed: say you referenced an external gradient file
00:34:25 [heycam]
... fill: url(externalfile.svg#gradient)
00:34:46 [heycam]
Rossen: how is this different frmo use?
00:34:51 [heycam]
ed: it's not, but it's not defined well there
00:35:15 [heycam]
AmeliaBR: percentages come up in use elements. in same document use elements, percentages are resolved on the original document not the referncing element
00:35:17 [heycam]
Rossen: not for us
00:36:24 [heycam]
AmeliaBR: right now if you have an SVG file with nested viewBoxes, and you want to reuse content into the local viewBox, it doesn't adjust to the local definition of what 100% is
00:36:30 [heycam]
Rossen: is this based on implemnetations or spec?
00:36:39 [heycam]
AmeliaBR: I'm pretty sure it's in the spec, not necessarily intentionally
00:36:45 [heycam]
... but it is consistent everywhere we tested it
00:37:14 [heycam]
... the other thing is that most implementations don't run CSS in resource documents, so if you have a <style> they don't have any effect on the reused content
00:37:27 [heycam]
... again that's not specced, just what implementations do
00:37:41 [heycam]
ed: do you see it as an external document or as nodes being cloned?
00:37:50 [heycam]
Rossen: use is basically copy-on-write
00:37:58 [heycam]
... you have a hosting context
00:38:24 [heycam]
... if your <g> element everything inside depends on where it's being hosted, with percentages, if you need to recreate/restyle/recalc the subtree that's in the g element, then you only do it in those contexts
00:38:34 [heycam]
... for external referenced documents I wouldn't expect different behaviour
00:38:42 [heycam]
... at the very least in terms of sizing and percentages
00:38:51 [heycam]
... it's a separate discussion about animations/transitions running
00:39:20 [heycam]
... so in CSS we have two separate cases where people may or may not expect aniamtions to run
00:39:41 [heycam]
... there is the case of something that is not visible on the screen and do run, and there is the case where it's not on the screen that they don't run
00:39:53 [heycam]
... that's the difference between display:none subtree, with animations suppressed, and visibility:hidden, in which animations do run
00:40:16 [heycam]
... so to compare the question we have at hand here, we should ask whether we're considering external documents as display:none case or similar to visibility:hidden case
00:41:15 [heycam]
heycam: for me I don't think about it as a display:none document
00:41:17 [heycam]
Rossen: in general we try to load and run as few things as possible, for perf and power
00:41:27 [heycam]
... running animations would be wasteful
00:41:40 [heycam]
... I don't want to make this problem worse
00:41:53 [heycam]
Rossen: so if we can help it, I'd be in support of not running animations
00:42:11 [heycam]
BogdanBrinza: then the style example maps nicely to that. if you have <style> in your referenced resources you don't want them to affect the outer document
00:42:19 [heycam]
... the more I think about it the more I think it makes sense to think about them as display:none
00:43:13 [AmeliaBR]
Worth looking at our current text in SVG 2: https://svgwg.org/svg2-draft/struct.html#UseElement Starting "The element referenced by ‘use’ may be in a separate document."
00:44:37 [heycam]
AmeliaBR: a good compromise would be resolving styles in that resource document, they only apply to that document, but that document does not have an animation timeline
00:44:46 [heycam]
... and the other issue was if you're resolving styles you need to resolve media queries
00:45:00 [heycam]
... the logical approach is set a default size, or to say use the media dimensions of the referencing element
00:45:18 [heycam]
Rossen: that would apply you'd need to resolve properties twice
00:45:23 [heycam]
... once in the lwoer document and once in the host document
00:45:26 [heycam]
... and that would be bad
00:46:23 [heycam]
... you could go a step further and say resolving styles shouldn't happen, but that would prevent sharing too
00:46:31 [heycam]
shepazu: I'm sympathetic to what Rossen said
00:46:37 [heycam]
... I think it seems most consistent/performant
00:46:48 [heycam]
... I think we should make clear what things are referenceable, what are not
00:46:55 [heycam]
... if animations can'tb e expected to be run, authors should understand why that is
00:47:27 [heycam]
heycam: I'd love to see tests but happy to go with not running animations for now
00:47:55 [heycam]
AmeliaBR: for styles and CSS animations afaik nobody resolves styles except inline styles on external use
00:48:17 [heycam]
BogdanBrinza: the way to spec is that things that are context dependent, we just don't have the context for the referenced document
00:48:24 [heycam]
... when did the timeline start?
00:49:10 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue4
00:49:11 [heycam]
BogdanBrinza: next one, issue 4
00:49:20 [heycam]
RESOLUTION: Animations do not run in resource documents.
00:49:53 [heycam]
BogdanBrinza: should CSS Variables that map palette colours be mapped into the document here too?
00:50:10 [heycam]
... issue suggests removing this issue, so let's do that
00:50:14 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue5
00:50:25 [heycam]
... issue 5, this one I've made the changes to this section
00:50:42 [heycam]
... the changes I made are something Cameron mentioned earlier, CORS applying
00:51:24 [heycam]
... the current state of things is that as far as I tried, Chrome does apply CORS, Edge has same domain restriction, Firefox allows any reference
00:51:53 [heycam]
heycam: I'd be happy for that to be tightened up
00:51:54 [AmeliaBR]
q+ to add a new issue re the "font document" section
00:52:05 [heycam]
BogdanBrinza: this would be a good test case
00:52:15 [nikos]
ack AmeliaBR
00:52:15 [Zakim]
AmeliaBR, you wanted to add a new issue re the "font document" section
00:52:36 [heycam]
AmeliaBR: it's not currently marked as an issue but there's a lot of stuff in that font document section that uses these context-* values, which we're no logner defining in SVG 2
00:54:10 [heycam]
heycam: context-fill,stroke are in the SVG 2 spec, context-value might not be though
00:54:24 [heycam]
... I'll figure out where those other things should be defined, since the OpenType spec is referencing this for the UA style sheet
00:54:40 [heycam]
BogdanBrinza: so that's a requirement and it sounds like the course of action is to ask the OT people to update this?
00:58:41 [heycam]
heycam: I'll write up some text for this
00:59:00 [heycam]
BogdanBrinza: we have this issue about protecting infinite reference cycles
00:59:10 [heycam]
... Chrome/Edge/Safari limit to one level
00:59:16 [heycam]
... Firefox has no limit
00:59:34 [heycam]
heycam: happy to align on the same number of levels
00:59:44 [heycam]
BogdanBrinza: I think ti's the interoperable behaviour we'd want anyway
01:01:08 [heycam]
... the other part is the URL standard reference, it's just editorial
01:01:13 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue6
01:01:26 [heycam]
... issue 6 is about "Animated mode", should we remove this
01:01:37 [AmeliaBR]
This is the section of SVG 2 that currently defines which resources may be in external elements: https://svgwg.org/svg2-draft/linking.html#processingURL
01:01:50 [heycam]
... oh I propose changing "external references" to "references to external resources"
01:02:38 [heycam]
heycam: it's not being referenced by anything, so let's remove it
01:03:43 [heycam]
nikos: does the OT spec still reference "secure animated mode"?
01:03:45 [heycam]
heycam: maybe
01:04:51 [heycam]
BogdanBrinza: soudns like there was some attempt to address the CORS concerns
01:05:08 [heycam]
AmeliaBR: to clarify, the "secure" modes are currently used
01:05:18 [heycam]
... when you embed SVG as an image, you're using this "secure animated mode"
01:05:27 [heycam]
... we don't have uses where no scripts, but do support external files
01:05:36 [heycam]
... so 3.3 Animated mode there aren't any uses of that
01:05:49 [heycam]
BogdanBrinza: sounds fair
01:06:07 [heycam]
... there are static renderers that do support external references, so there's a benefit for recognising that his extists
01:06:12 [heycam]
... don't know if it's needed in this context
01:06:26 [heycam]
s/... there are/AmeliaBR: there are/
01:06:50 [heycam]
BogdanBrinza: for external resources, you only have a single level of depth, and there is no script in those resources
01:07:01 [heycam]
... it sounds like we're talking about policies, rather than modes
01:07:09 [heycam]
... and the modes references policies
01:07:15 [heycam]
shepazu: that's what it's doing
01:07:23 [heycam]
BogdanBrinza: there is some slight different
01:07:27 [heycam]
shepazu: sounds fine to fix that
01:07:55 [heycam]
AmeliaBR: the purpose of having these modes is that other specs can reference these and clearly say that e.g. HTML can SVGs will run in "secure animated mode", and this spec defines that
01:08:20 [heycam]
... so some other spec for some XML format could reference a static mode where the image is static, animations don't run, but external fonts and other embeds are allowed
01:08:37 [heycam]
... I don't see anything wrong with efining all the different combiantoisn and giving them names
01:08:46 [heycam]
... so that other specs can clearly reference them and have a clear definition
01:08:49 [heycam]
BogdanBrinza: that is what I propose
01:09:11 [heycam]
... they should be defined as single entities, but currently modes try to explain more than just the policies, but they should be purely about the policies
01:09:20 [heycam]
... if needed we can expand with new policies, but still keep the same modes
01:10:13 [heycam]
RESOLUTION: Keep the modes, define them in terms of policies, basically as a table mapping modes to specific policies.
01:10:24 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue7
01:10:29 [heycam]
BogdanBrinza: next, issue 7
01:10:30 [heycam]
AmeliaBR: that's the same
01:10:32 [BogdanBrinza]
https://svgwg.org/specs/integration/#issue8
01:10:46 [heycam]
BogdanBrinza: issue 8 and 9 are about HTML in foreignObject
01:10:50 [heycam]
... issue 9 is editorial, add examples
01:11:05 [heycam]
... issue 8 I'm not sure I understand it. "what should we say about when to rasterize the content?"
01:11:11 [heycam]
... pixellated form controls?
01:11:18 [heycam]
AmeliaBR: I think that's an obsolete issue
01:11:32 [heycam]
... this was like transforms/filters applied to SVG content with forms in foreignObject
01:11:41 [heycam]
... but now we have transforms/filters applied to HTML content
01:12:06 [BogdanBrinza]
https://jsfiddle.net/pscu8wLq/
01:12:24 [heycam]
BogdanBrinza: looks like implementations don't pixellate now
01:12:40 [heycam]
BogdanBrinza: last issue, 10, this is a todo for defining SVG in foreignObject
01:13:49 [heycam]
AmeliaBR: I think I'd like to see here, in general to HTML/SVG/MathML, a sentence that says what the effect of viewport is on child content, but that's not quite correct (it's not a separate document)
01:14:36 [heycam]
... but that's where it becomes an issue, what's the parent size / coordinate system that that foreignObject creates, and just to have a sentence about the content of the foreignObject being drawn into a container that has the width/height and coordinate system established by the foreignObject
01:14:43 [heycam]
BogdanBrinza: sounds like this is defined in section 4.1
01:14:52 [heycam]
AmeliaBR: that's part of it
01:15:00 [paradisaeidae]
paradisaeidae has joined #svg
01:15:09 [heycam]
BogdanBrinza: so SVG viewports establish the containing block for HTML, and vice versa -- using SVG in HTML context, then the containing block establishes the viewport
01:15:25 [heycam]
AmeliaBR: so maybe generalise that rule and not make it specific to HTML, for one thing it's anything CSS-styled content that could be some other XML language who knows
01:15:36 [heycam]
BogdanBrinza: yes that's CSS context, not HTML
01:15:56 [heycam]
AmeliaBR: then if you put an <svg> inside a <foreignObject> then we can treat the <svg> has having a CSS box parent
01:15:59 [heycam]
BogdanBrinza: yes
01:16:09 [heycam]
... there's nothing special about <svg> in <foreignObject> that we need to specify
01:16:11 [heycam]
ed: right
01:16:22 [paradisaeidae]
Wow, had never though of such a thing: <svg> inside a <foreignObject>
01:16:42 [heycam]
AmeliaBR: the key thing is that a foreignObject creates a CSS box, and any content you put inside it that requires a CSS box layout concept of a container/parent would then use that
01:16:52 [heycam]
BogdanBrinza: I have a feeling we discussed this in Paris for some of the other chapters, coords?
01:16:58 [heycam]
... we talked about interactions between viewports and containing lbocks
01:17:03 [heycam]
... I think that's the same as we're discussing right now
01:17:14 [heycam]
AmeliaBR: are you ok with rewriting this just to make a single generic description?
01:17:28 [heycam]
BogdanBrinza: I'd imagine we have something somewhere in SVG 2?
01:17:31 [heycam]
... to point to
01:17:39 [heycam]
ed: the initial continaing block?
01:17:46 [heycam]
BogdanBrinza: how ICB maps to viewport and vice versa
01:17:48 [heycam]
ed: section 4.1
01:18:14 [nikos]
https://jsfiddle.net/dodgeyhack/nnztjw7s/
01:18:22 [heycam]
nikos: just going back, this example is pixellated in firefox
01:19:15 [AmeliaBR]
I think this is the section Bogdan is referring to: https://svgwg.org/svg2-draft/coords.html#ViewportSpace
01:19:45 [heycam]
heycam: don't think it's an issue that needs to be in the spec
01:21:26 [heycam]
Topic: coordinate precision in generated content
01:21:33 [heycam]
stakagi: this was an issue Chris Little brought up
01:21:52 [heycam]
... he wanted content for technical drawings, maps. I prepared a wiki page
01:21:59 [heycam]
... with current implementation status
01:22:34 [heycam]
... in this wiki page, in the Conformance chapter of SVG 2 I think that there is no requirement to add normative language
01:22:42 [AmeliaBR]
Wiki page: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation#Improving_Significant_Figures_by_Transformation_and_Tiling
01:23:05 [heycam]
... but for more convenience for content creators I want to add an explanation from this wiki page
01:23:29 [heycam]
AmeliaBR: it's been an issue we brought up a couple of times
01:23:42 [heycam]
... that people are ignored when they translate data and come up agains the single precision flaot numeric precision
01:23:53 [heycam]
... and for perf reasons nobody wants to require better than single precision floats
01:24:13 [heycam]
... so it's a nice compromise to have authoring (tool) guidance on how to deal with the limitations of the single precision coord system
01:24:27 [heycam]
... whether that's a separate authoring guidance spec or an appendix I don't mind
01:25:15 [AmeliaBR]
s/people are ignored/people are annoyed/
01:26:34 [heycam]
stakagi: one point, I added Conformance Criteria, the viewer must use double for CTMs, but the TM itself need only be single
01:27:03 [stakagi]
https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers
01:28:24 [heycam]
heycam: is there an existing appendix where it would make sense?
01:29:22 [heycam]
AmeliaBR: maybe in Conform where we have conformance class for authoring tools?
01:30:21 [heycam]
ACTION: stakagi to add non-normative authoring guidance about content precision to conform.html
01:30:21 [trackbot]
Created ACTION-3836 - Add non-normative authoring guidance about content precision to conform.html [on Satoru Takagi - due 2016-02-12].
01:30:48 [heycam]
Topic: SVG stroke/corner demo
01:30:52 [ed]
http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/simplerect.html
01:31:01 [heycam]
ed: I wanted to experiment with this from the SVG Strokes module
01:31:10 [heycam]
... I created a simple polyfill using dash arrays to emulate corner behaviour
01:31:31 [heycam]
... if you look at this link, which should work in any browser, you see I've highlighted the corners using this feature
01:31:44 [heycam]
... the first polyfill version doesn't handle rounded rect corners, which turned out to be a bit more difficult
01:31:49 [heycam]
... but the spec has noted this as an issue
01:32:06 [heycam]
... where corners should be drawn, all over the arcs?
01:32:32 [heycam]
... this does depend on path length computation methods
01:32:42 [heycam]
... but it does show a way to do a polyfill that could work before browsers implement this
01:32:45 [shepazu]
q+
01:32:56 [heycam]
... I also went ahead and did a second demo, where you can specify several corner lengths
01:33:02 [ed]
http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/multidash.html
01:33:22 [heycam]
shepazu: what is the shape with the rectangle with something in it?
01:33:24 [heycam]
ed: that's a polyline
01:33:48 [heycam]
... I chose not to draw corners on each side, just highlighting the corners not the end points
01:34:00 [heycam]
shepazu: why wouldn't this work in Edge?
01:34:04 [heycam]
AmeliaBR: it's an XHR error
01:34:21 [heycam]
ed: in the second demo I use multiple lengths for the different corners
01:34:33 [heycam]
... in the middle rect, you can see two corners have longer dashing
01:34:42 [heycam]
... and looking at the star I used more different lengths
01:35:02 [heycam]
... so with multiple corners you repeat similarly to dasharrays
01:35:18 [heycam]
shepazu: how does stroke-dashcorner array with stroke-dasharray?
01:35:22 [heycam]
Tav: [stole my question!]
01:35:26 [heycam]
ed: hopefully should be defined in the spec
01:35:36 [heycam]
... I didn't mix in the dasharrays that might exist on elements in this demo
01:35:42 [heycam]
... the way it's meant to work is you spread the dasharray between the corners
01:35:50 [heycam]
... and adjust the gaps so that it looks nice, with stroke-dashadjust
01:35:56 [shepazu]
q+
01:36:09 [heycam]
AmeliaBR: the way we spec it is you dash the corners first, then dash each line segment independnetly with these extra properties to make it look properly
01:36:52 [heycam]
shepazu: what it sounds a bit like with this collection of features that it's approaching shorrthands/longhands
01:36:55 [heycam]
... might be good to think about it like that
01:37:06 [shepazu]
q+ shane
01:37:10 [shepazu]
q-
01:37:15 [heycam]
Tav: this deals with corners, what about paths? drawing a map, when you want to have intersections with 3 different regions look nice
01:37:31 [heycam]
ed: in this first simple impl, this uses the new path api polyfill
01:37:40 [heycam]
... it provides you with getting the normalized path seg data out from the path
01:37:44 [heycam]
... I'm just looking for lineto elements
01:38:11 [shane]
q-
01:38:23 [heycam]
heycam: I think something else would be needed to solve the map intersection case
01:38:30 [heycam]
ed: there are a few issues in the Strokes spec I noted down
01:38:44 [heycam]
... one is issue 8, which says that the points at which the dashcorner are painted include the start/end points of every segment
01:38:46 [heycam]
... I think we shouldn't do that
01:38:53 [ed]
https://svgwg.org/specs/strokes/#issue8
01:39:35 [heycam]
... another thing I noticed is that one thing that makes it hard to polyfill is that dasharrays start over again for new subpaths
01:39:45 [heycam]
... it's difficult to get the dasharrays positioned properly
01:39:53 [heycam]
... you have to break it apart into several path elements
01:40:01 [heycam]
... if the dahsarray starts over, then you can't do anything custom for that one
01:40:08 [heycam]
AmeliaBR: as in your might need a half dash?
01:40:17 [heycam]
ed: you want a new dasharray per subpath
01:40:24 [heycam]
AmeliaBR: your polyfill will have to define every single dash in the whole path
01:40:35 [heycam]
ed: I know we decided that's the way it works
01:40:40 [heycam]
... I think you can still break up the element if you need to
01:40:56 [heycam]
heycam: pretty sure dashing works like that everywhere
01:41:10 [heycam]
AmeliaBR: if the worst we can say is that the polyfill is less performant that's ok
01:42:49 [heycam]
Topic: Future F2Fs
01:43:17 [heycam]
nikos: TPAC is in September, Graphical Web is early November
01:43:22 [heycam]
... CSSWG is meeting in May 2nd week in US
01:43:39 [heycam]
... I feel like we're a bit constrained by Invited Experts who might not be able to travel far/often
01:43:44 [heycam]
... so we should try to go where they are instead
01:43:52 [heycam]
shepazu: meeting with CSS is usually productive
01:44:00 [heycam]
... I would hope that Amelia could attend in the US?
01:44:08 [heycam]
AmeliaBR: I can't make promises unless someone finds a grant for me
01:44:25 [heycam]
shepazu: Tav, could you travel in May to the US?
01:44:29 [heycam]
Tav: might be difficult
01:44:41 [heycam]
... I'll have some money, have a designated budget, but it would exhaust it
01:44:58 [heycam]
shepazu: I think it would be useful to have a F2F with CSS but I understand the constraints
01:45:51 [heycam]
shepazu: do we need to schedule a F2F?
01:46:02 [heycam]
nikos: lots of us can only dedicate time to SVG around F2Fs
01:46:14 [heycam]
nikos: it's more a case of where and when
01:46:23 [heycam]
... so TPAC and Graphical Web are close together, a month apart
01:46:28 [heycam]
... we've been invited to meet at Graphical Web
01:46:36 [heycam]
Tav: that would be much more practical for two reasons
01:46:53 [heycam]
... one, for me, the one time I attended TPAC the day and a half we spent wasn't much
01:46:56 [heycam]
... a long way to go for 1.5 days
01:47:20 [heycam]
... two, I will probably be going to Graphical Web
01:47:27 [heycam]
... so it would be a small incremental cost to stay for a WG meeting
01:47:31 [heycam]
nikos: I feel similarly about TPAC
01:47:42 [heycam]
... quite short, good but we tend to get more done at other dedicated WG meetings
01:47:50 [heycam]
shepazu: I think the point of TPAC is to coordinate with other WGs
01:48:02 [heycam]
... and if we don't find we need to coorindate with groups other than CSS...
01:48:47 [heycam]
Rossen: I agree that meeting with CSS is awesome, whenever we have the opportunity to do it
01:49:03 [heycam]
... the one other thing I wanted to put on the table, would we having any specific goals in May or whenever?
01:49:15 [heycam]
... one of the specific goals we had as a WG from Linkoping, was to come here and be ready to have CR
01:49:24 [heycam]
... we are underdelivering on that goal
01:49:46 [heycam]
... one thing reasonated with me is that nobody is putting efforts outside of F2Fs, so if F2Fs are a forcing function for spec writing, then I would be in favour of meeting
01:49:50 [heycam]
... as long as we can find a place and time
01:50:00 [heycam]
... but I'm trying to explore options where we can still make progress without needing to meet F2F
01:50:13 [heycam]
shepazu: I think Rossen raises a great point
01:50:51 [heycam]
... I think we should set a goal for May, if we thought that we're close enough to get something done by May it might indicate some dedicated speccing days-- we've tried to do that in the past, it's only worked sometimes
01:51:00 [heycam]
... having weekly goals towards May
01:51:03 [heycam]
... since that's not far away
01:51:15 [heycam]
... regarding Graphical Web vs TPAC, I'm really busy at TPAC
01:51:44 [heycam]
... as much as I would like to have SVG at TPAC, pragmatically it's not practical for me to do all my WG stuff at TPAC
01:51:53 [heycam]
nikos: a crazy idea might be to meet sooner than May
01:52:17 [heycam]
AmeliaBR: there is the April Libre Graphics conference
01:52:22 [heycam]
... there's a chance I'll be there but can't promise
01:52:25 [heycam]
... that's London early April
01:52:32 [heycam]
... 15-18 April
01:52:41 [heycam]
Tav: I will most likely be there
01:52:46 [heycam]
... Inkscape will have a hackfest before that
01:52:52 [shepazu]
http://libregraphicsmeeting.org/2016/
01:53:00 [heycam]
Rossen: if we're organising around community engagement opportunities, it would be cool we could brag about shipping SVG 2
01:53:23 [heycam]
... the other thing, attracting implementor interest
01:53:36 [heycam]
... if and when we're done with this CR stage, it would be great to start talking about where we go next
01:53:40 [heycam]
... and how do we rev all the impls
01:53:54 [heycam]
... I've stated this before, as an implementor I am waiting for this to be stable and rubber stamped before I put resources onto this
01:54:11 [heycam]
Tav: that confuses me a little, as you're talking about modularization with CSS
01:54:16 [heycam]
Rossen: and I'm waiting for this module to be done
01:54:24 [heycam]
... I think I made some attempts to modularize other things out of it
01:54:37 [heycam]
... and yes I want to see what will happen with the next modules
01:54:55 [heycam]
Tav: you would consider implementing some of the stable parts?
01:55:03 [heycam]
Rossen: if it's in a stable SVG 2? yes
01:55:24 [heycam]
... I cannot commit on implementations/releases of products, what I can say is: if/when the spec is stable, we'll have a lot better chance of attracting implementation
01:55:40 [heycam]
... much easier to implement, particuarly if it's a gap, against a stable spec that's not going to keep going back/forth
01:56:23 [heycam]
Rossen: so, when are we going to ship?
01:56:34 [heycam]
... if F2F is a forcing function, I would be in favour of having it whenever/whereever
01:56:49 [heycam]
... but there needs to be more -- to justify the expense -- we need more data to say that's actually going to happen
01:57:00 [heycam]
... or if we're pretty much there and just need to nail down a few things
01:57:04 [heycam]
... which was our assumption coming here
01:57:19 [heycam]
nikos: part of the issue with this F2F is that's early in the year and with Christmas/breaks people weren't spending time on it
01:57:45 [heycam]
AmeliaBR: so the question is, if another F2F is set up in April/May, can people commit to working for the next few months to get a publication ready spec
01:58:02 [heycam]
nikos: so Text and Cooridnates need to get fixed
01:58:10 [heycam]
Tav: I would hope to get Text done in a month
01:58:29 [heycam]
nikos: so is it worth having a F2F at Libre Graphics?
01:58:33 [heycam]
AmeliaBR: if you organise it I will come
01:58:46 [heycam]
nikos: for me I could get there if it's after Libre Graphics
01:58:53 [heycam]
ed: it would be easier for me, being there
02:00:58 [heycam]
Rossen: my vote would certainly be May since I'll be at CSS/Houdini
02:01:03 [heycam]
... could I come in April? don't know
02:03:21 [heycam]
BogdanBrinza: it would be challening for me to attend in April
02:03:41 [heycam]
nikos: one advantage to getting a few people together, we could VC with other people if any issues come up for discussion
02:04:10 [heycam]
nikos: for May...
02:04:19 [heycam]
shane: 9-11 CSS, 12-13 Houdini?
02:04:24 [heycam]
s/?//
02:04:33 [heycam]
... need to let us know as soon as possible if SVG wants to meet there
02:05:46 [heycam]
Rossen: if the goal of meeting is to write specs, perhaps you should go with April, the people most involved in spec work can summit
02:05:55 [heycam]
... that's good for Erik, Tav, Amelia can maybe attend too
02:06:14 [heycam]
... other option is: if we're meeting as a WG, if we need to work on open issues, then you want a bigger quorum. seems like May in US is a better option for that.
02:06:51 [heycam]
shepazu: a hybrid option is to have an editor's meeting at Libre Graphics and then have a F2F in May with CSS
02:07:19 [heycam]
AmeliaBR: so April will be clean everything up so in May we have a document we agree with shipping?
02:07:28 [heycam]
nikos: I could come to both, if that's what needs to be done
02:07:42 [heycam]
... I think if we got together in London, it would be pretty productive
02:07:57 [heycam]
... if people could commit to telcons until then for talking about issues, we'll have a lot of stuff ticked off to get finished at that spec meeting
02:09:30 [birtles]
scribenick: birtles
02:09:37 [birtles]
Rossen: SF will be busy at that time
02:10:15 [birtles]
nikos: we'll go with April and discuss May after the break
02:10:43 [birtles]
<lunch break 1h>
02:39:35 [AmeliaBR]
AmeliaBR has joined #svg
03:03:59 [stakagi]
stakagi has joined #svg
03:07:36 [nikos]
AmeliaBR: we're mostly back
03:12:22 [heycam]
ScribeNick: heycam
03:13:18 [heycam]
nikos: I think if we have a meeting in April, and Tav, myself, Amelia and maybe Erik get together, that would be a productive meeting
03:13:24 [heycam]
... in terms of reviewing and finishing off the spec text
03:13:28 [heycam]
... not for talking about issues
03:14:43 [heycam]
... if we meet in May it's in the US, where we're likely to have Rossen, myself, Shane, Bogdan maybe
03:15:37 [heycam]
nikos: if we get the spec done at the April meeting, issues will start getting raised as we make our way through the test suite
03:16:47 [heycam]
nikos: if we met in May even without the April meeting, what would be on the agenda for May?
03:16:57 [heycam]
... so meeting later than May, to discuss issues that arose from test writing sounds better
03:17:18 [heycam]
nikos: so let's have the small meet in April to get the spec finished, then plan a meet mid-year once we've had some time to work on tests and collecting issues from that
03:17:44 [heycam]
... so something like July, don't know where though
03:19:28 [heycam]
RESOLUTION: Spec editors will meet in April adjacent to Libre Graphics, no meeting in May, organising SVG meeting July or so later.
03:20:33 [heycam]
Topic: SVG feature interest from implementors
03:21:12 [heycam]
shane: as an implementor, best bet for getting new SVG features in browsers is to make them relevant
03:21:19 [heycam]
... so they need to integrate well with HTML
03:21:41 [heycam]
... I don't have any specific advice, but the extent to which SVG interopates well with HTML will affect how likely it is these are implemented
03:21:48 [heycam]
AmeliaBR: some of these features are make SVG behave more like HTML
03:22:22 [heycam]
Tav: there are a variety of things that already work in HTML, and we just need to make sure they work in SVG
03:22:39 [heycam]
... like text-orientation, the font features, so we just have to make sure when they're implemented for HTML they work in SVG too
03:22:46 [heycam]
... the filter shorthands for example work in HTML in Chrome but not in SVG
03:22:51 [heycam]
ed: that's right
03:22:57 [heycam]
Tav: so that should be low hanging fruit to pick up
03:23:13 [heycam]
shane: that might be low hanging fruit, but there has to be demand
03:23:24 [heycam]
... if you want to think like an implementor, they're going to be looking at what the general webdev public demands
03:23:36 [heycam]
... if there's no demand from authors then it won't be prioritised
03:23:43 [heycam]
Tav: it's a chicken and egg problem
03:24:03 [heycam]
... what I'm going to do, is I'll start enabling some things in Inkscape output
03:24:10 [heycam]
nikos: we could start tracking what features are actually implemented
03:24:19 [heycam]
... so we can get a handle on what is starting to be implemented
03:24:45 [heycam]
Rossen: also, as an implementor, I want something that is stable
03:24:50 [heycam]
... if it's not stable I'm not going to look atit
03:25:45 [heycam]
... when I talk to my management, they don't want to know about SVG until there's something which you can print and you don't have reprint many times
03:25:51 [heycam]
... it's the door-opener
03:26:08 [heycam]
... I have spoken to some other implementations that have large adoption, and they have similar feedback
03:26:32 [heycam]
shepazu: so you're saying stabilise, then we'll pay attention
03:26:39 [heycam]
Rossen: yes, that's what I've been saying for 15 months
03:26:55 [heycam]
shepazu: because SVG is a large spec, is stabilising chapters a reasonable thing? or it has to be the whole thing?
03:27:04 [heycam]
Rossen: can we break these chapters into their own modules and say this thing is CR?
03:27:16 [heycam]
AmeliaBR: at this point that would slow things down
03:27:40 [heycam]
Rossen: it seems like the spec is going in the right direction though
03:27:49 [heycam]
... here's a simple kind of conversation that will happen in a company like ours
03:28:08 [heycam]
... you look at the history you see a spec that has been in development for the last 12 years, in order to have faith in this work you need to see the rubber stamp
03:28:16 [heycam]
... as an implementor I want to go and do that work, but can't, because I'm resource bound
03:28:32 [heycam]
... when someone looks at a spec that has been going on for that long, how do they know it's not going to keep going for another 13 years?
03:28:40 [heycam]
... that the message this WG must be able to send, to say it's done
03:28:48 [heycam]
... to say it's stable and ready for implementation
03:28:56 [heycam]
... it's just this really long timeline that is holding us back
03:29:02 [heycam]
... we did the same thing with CSS, at least in IE
03:29:13 [heycam]
... until 2.1 was stable there wasn't a good reason to go and implement it
03:29:25 [heycam]
alex: from Chrome's PoV, my experience in SVG and standards I agree with Rossen
03:29:40 [heycam]
... with the 1.2T timeframe, JSR226, there are other standards bodies that want a stable spec before looking at it
03:29:56 [heycam]
... from Chrome's impl PoV it's irrelevant, but from a standards PoV yes
03:30:27 [heycam]
birtles: I think what I'd be interested in is if SVG 2 feels like a lot, if there were some sort of subsets of low hanging fruit or things other implementors agreed or community votes, smaller packages of work available, that might be an easier sell
03:30:40 [heycam]
Rossen: but this is what CR is for
03:30:49 [heycam]
birtles: not talking about the process
03:31:14 [heycam]
... we hate html5tests, it just counts the number of APIs you implement, but if you have things like that it's a package of work to say it's a goal to get this to pass
03:31:20 [heycam]
... saying the goal is "SVG 2" is a big sell
03:31:20 [AmeliaBR]
q+ to recast discussion: which parts of the spec are stable enough to start building tests?
03:31:31 [heycam]
alex: I think the point of W3C process, CR is the thing to get things out the door
03:31:55 [heycam]
birtles: nothing to do with standardisation, I'm saying if someone else as an independent effort to say we think these 3 features are the most important ones out of SVG 2, we're going to make up a matrix...
03:32:09 [heycam]
Rossen: sure, but at this point how do you know these will be the same features by the time the spec is in CR?
03:32:15 [heycam]
... there's a Rec process for a reason
03:32:27 [heycam]
... so going out there and saying that you know these features are going to be the way they are...
03:32:54 [heycam]
... there is a formalised standardisation process which serves at least one thing that's good, which is "this is a stable spec"
03:33:18 [shepazu]
q+
03:33:21 [heycam]
birtles: I'm just saying, as an implementor something that would be helpful is, after CR, to narrow the scope of what we do first
03:33:26 [heycam]
Rossen: prioritisation?
03:33:26 [heycam]
birtles: yes
03:33:38 [heycam]
... trying to say "lets do all of SVG 2" is an overwhelmingly big task
03:33:51 [heycam]
... if someone wants to prioitise and agree on how to prioritise that's an easier sell
03:34:03 [heycam]
Rossen: then you get into 80/20 problem
03:34:24 [shepazu]
q-
03:34:31 [nikos]
ack AmeliaBR
03:34:31 [Zakim]
AmeliaBR, you wanted to recast discussion: which parts of the spec are stable enough to start building tests?
03:34:32 [heycam]
AmeliaBR: these all sound like good points, and I think Rossen has clearly argued that it's no use asking for impls until we get the rubber stamp
03:35:56 [heycam]
... but for our own purposes, we can still start breaking things down into individual components as Brian was saying, certain things are going to be different priority for users
03:35:56 [heycam]
... and the other thing is testing
03:35:57 [heycam]
... even if some of us are still rewriting the Text chapter, if another chapter is stable and people have time to write tests they can move ahead with that
03:35:57 [heycam]
... and so that from that perspective it's still useful to have a matrix of our own to keep track of which new features have been introduced and we're confident it's not going to change
03:36:02 [heycam]
nikos: the other topic is marking features at risk for CR
03:36:05 [heycam]
... i don't really know the process for that sort of thing
03:36:20 [heycam]
alex: I think you just get implementor feedback about what things are likely to be implemented
03:37:24 [heycam]
shepazu: we mark features at risk if we feel they're not going to be implemented
03:37:36 [heycam]
... with the new process, going back to CR which used to be more painful, is streamlined
03:37:45 [heycam]
... so Process2015 streamlines with how you iterate on a spec
03:37:54 [heycam]
... It hink we should be resonbile without we try to portray issues
03:39:38 [heycam]
shepazu: it's not as useful to identify these at risk features before CR now with the new process
03:41:23 [heycam]
BogdanBrinza: I might repeat Rossen's view in a pragmatic way
03:41:45 [heycam]
... there have been features implemented in other browsers, Inkscape; we'll gladly implement things we feel we need to implement
03:41:50 [heycam]
... features that are being used out there
03:42:01 [heycam]
... support in other browsers is great, and it shows the pipeline
03:42:31 [heycam]
... we're #3 or #4 browser now, so we're under no pressure to implement
03:42:38 [heycam]
... we will show our interest and implement things we have to
03:43:08 [heycam]
nikos: at the April editor's meeting we can enumerate all the SVG 2 feature, as a basis for tracking implementation, what needs tests, and as a communication tool with implementors
03:43:24 [heycam]
... for now let's just get the text in coords/text chapters finished
03:45:17 [heycam]
Topic: SVGZoomEvent
03:45:43 [nikos]
https://github.com/w3c/svgwg/issues/21
03:45:59 [heycam]
nikos: the question was raised by chromium folks, about whether SVGZoomEvent is needed
03:46:02 [heycam]
... whether anyone uses it
03:46:10 [heycam]
... it wasn't clear to them from reading the spec how it should work
03:46:18 [heycam]
... when currentScale changes the event should be fired, I think
03:46:38 [heycam]
... there was some history with Opera Presto which had a control to scale SVG content within the page
03:46:50 [heycam]
ed: apparently SVGZoomEvent doesn't work in Chrome
03:46:56 [heycam]
... so I think they're looking to see whether they can drop it
03:47:08 [heycam]
... not sure if people are trying to dependent on this
03:47:13 [heycam]
BogdanBrinza: are there use counters?
03:47:17 [heycam]
nikos: no mention of them
03:47:25 [paradisaeidae]
Please don't drop SVGZoomEvent
03:47:38 [heycam]
AmeliaBR: I suspect it's very poorly used just because there no active implementations right now have user controlled pan and zoom options
03:47:49 [heycam]
... so I'm not sure whether anybody fires this event for pinch zoom etc.
03:47:58 [heycam]
... so it's certainly an edge case
03:48:05 [paradisaeidae]
Use counters are not potentialUseContersWhenUseIsUnderstoodCounters
03:48:11 [heycam]
Rossen: was the zoom event raised on user zoom or pinch zoom?
03:48:49 [heycam]
AmeliaBR: SVG used to have zoomAndPan, which users coul use to zoom in/out
03:48:59 [paradisaeidae]
This is an area I did not have time to put to the panel last night.
03:49:02 [heycam]
... and then authors could listen to this event to respond to these zooms
03:49:49 [heycam]
Rossen: you say there's interactivity where the user is interacting with SVG content, based on which other SVG content...
03:49:56 [heycam]
AmeliaBR: the idea was the browser would show zoom UI
03:49:58 [heycam]
... but nobody does that
03:50:06 [heycam]
... (since Opera Presto was dropped)
03:50:29 [heycam]
Rossen: today we're hiding the interaction between pinch zooming and viewport more and more
03:50:32 [paradisaeidae]
SVGZoomEvent can signal the level of detail to be rendered.
03:50:46 [heycam]
... so that you can implement efficient zooming in the GPU
03:51:06 [heycam]
shepazu: there's a difference between optical zoom and functional zoom. we're not talking about making the thing bigger, talking about drilling down into more details
03:51:42 [heycam]
Rossen: these things work well today in response to touch events, etc.
03:51:56 [heycam]
... zooming is a user instantiated action which is controlled on the app layer most of the time
03:52:01 [heycam]
... in that case, you know how your application should behave
03:52:14 [heycam]
... there's no reason to have another event to say the user did a pinch gesture
03:52:29 [heycam]
... this is your app, you know what that gesture means
03:52:54 [heycam]
... without needing another event which means your zooming
03:53:13 [heycam]
... what Amelia said makes sense, if the browser was allowing zoom in a script-undetectable way, then it makes sense
03:53:27 [paradisaeidae]
is pinch the only way zooming can be signalled?
03:53:31 [heycam]
shepazu: there's any number of ways users can initiate these things
03:53:47 [heycam]
... however they did it, it's like an INDIE UI thing
03:53:55 [heycam]
... letting the page know that the user zoomed, the page reacts
03:54:06 [heycam]
Rossen: if this is the case, why doesn't HTML have the same thing?
03:54:18 [stakagi]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail#Events_for_start.2C_end_and_during_transition_of_zooming_and_panning.
03:54:39 [heycam]
shepazu: the kinds of apps you build with HTML are different
03:54:55 [heycam]
Rossen: we have a semantic zoom to say you can double tap to different menus, categories, different levels of HTML layers
03:55:00 [heycam]
... nothing to do with CSS
03:55:10 [heycam]
... so I'm questioning the need for the necessity for this event
03:55:24 [heycam]
alex: should put a use counter on it
03:55:33 [stakagi]
Regardless of SVG, the event about zoom on web browsers is made confused.
03:55:35 [heycam]
nikos: according to the bug it's not implemented but it can be feature detected
03:55:46 [heycam]
AmeliaBR: it was implemented in the Adobe viewer which had those controls
03:56:04 [heycam]
... I would argue against what some of what Rossen said, I'd love to see a semantic zoom event
03:56:18 [heycam]
... the user did an input which normally means zoom on their system, but I don't see the use of having an SVG specific event
03:56:37 [heycam]
BogdanBrinza: looking at Chromium source it's declared but not used
03:57:26 [heycam]
nikos: sounds like there might be good use cases for this but it's not specced properly
03:57:47 [heycam]
AmeliaBR: we could for wording tie it into the znp control wording
03:58:08 [shepazu]
q+
03:58:16 [heycam]
nikos: sounds like this could be removed and looked at in a wholistic way later on
03:59:08 [heycam]
shepazu: just noting that INDIE UI hasn't been updated in a year or so, they seem to have something called zoomrequest but dropped in interest of spec speed
04:00:21 [heycam]
RESOLUTION: Remove SVGZoomEvent from SVG 2.
04:10:10 [ed]
RRSAgent, pointer?
04:10:10 [RRSAgent]
See http://www.w3.org/2016/02/05-svg-irc#T04-10-10
04:13:08 [nikos]
RRSAgent, make minutes
04:13:08 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/02/05-svg-minutes.html nikos
04:30:00 [nikos]
scribenick: nikos
04:30:17 [nikos]
Topic: Exclusion shapes for text
04:31:47 [nikos]
Tav: The spec right now uses shape-outside
04:31:58 [nikos]
... It doesn't really match the CSS concept of shape-outside
04:32:08 [nikos]
... which is to specify a region that an object is shrunk by
04:32:54 [nikos]
Rossen: Here's a scenario: you have a text element. The number one thing you want to do is say wrap this text inside a shape (e.g. circle)
04:33:30 [nikos]
... and here are two or three other shapes, that if they intercept with the shape inside, they subtract geometry from the shape
04:34:00 [nikos]
... a nice term for describing this might be shape-subtract, or shape-exclude
04:34:49 [nikos]
... shape-subtract further changes the shape specified fro shape-inside if there's an intersection
04:36:51 [ed]
BogdanBrinza, heycam: do you both agree with https://svgwg.org/svg2-draft/interact.html#issue6 suggestion not to list events from DOM Events / HTML?
04:39:00 [nikos]
... shape-outside was confusing and the wrong thing to use because of it's ability to change the geometry of the shape that is used for the exclusion (as opposed to the shape that is rendered)
04:41:33 [nikos]
... we can use shape-outside in SVG 2 in the future but we have to use it for the exact same purpose as in CSS, and that's not the case with the current description of shape-outside
04:43:08 [nikos]
RESOLUTION: Rename shape-outside to shape-subtract to reflect that the way it is specified is different than shape-outside in CSS.
04:43:17 [nikos]
RRSAgent, make minutes
04:43:17 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/02/05-svg-minutes.html nikos
04:47:32 [heycam]
Rossen, fyi I just did this for the presentation attribute change: https://github.com/w3c/svgwg/commit/bb87c6d1a8fdb448e2313cebd9fddbe1708438c7
05:34:47 [nikos]
https://github.com/w3c/svgwg/issues/42
06:07:51 [nikos]
trackbot, close action-3831
06:07:51 [trackbot]
Closed action-3831.
06:36:30 [ed]
heycam, BogdanBrinza: I dropped most of the events from the table in the interactivity chapter, feel free to review... wondering if we really need to keep sections 14.10.1 - 14.10.3 (https://svgwg.org/svg2-draft/interact.html#OnLoadEvent)
06:49:28 [Tav]
http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/
10:26:36 [Tav]
Tav has joined #svg