SV_MEETING_TITLE -- 05 Feb 2016

<nikos> AmeliaBR: ping we're back

<heycam> ScribeNick: heycam

SVG Integration spec

nikos: Bogdan will be an editor of this spec

BogdanBrinza: there are a few issues that might be worth discussing and knocking out
... might be more of an FYI

<BogdanBrinza> https://svgwg.org/specs/integration/

<BogdanBrinza> https://svgwg.org/specs/integration/#issue1

BogdanBrinza: first issue is all the different scenarios of SVG integration
... foreignObject, CSS context
... the thing that is mostly concerned for CSS/SVG implementaors is sizing SVG documents in CSS, sizing HTML content in foreignObject
... can you give me a sense of the relative priority of other things?
... metadata?

heycam: not important, focus on the sizing

BogdanBrinza: so with initial containing block with foreignObject viewport, I don't think this is an issue
... for CSS sizing I have half of the change in progress, still working on that
... don't think anything else in issue 1 needs talking now

<BogdanBrinza> https://svgwg.org/specs/integration/#issue2

BogdanBrinza: issue 2, this talks about referencing the Fetch algorithm

heycam: this is about CORS etc.

BogdanBrinza: not sure how this applies to referencing modes though

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.

ed: agreed

AmeliaBR: maybe we'd want to use Anonymous mode for resource documents for example

BogdanBrinza: sounds likes an extension of the referencing mode rather than something about the Fetch algorithm

AmeliaBR: I don't think we have any referencing modes where Anonymous mode is explicitly mentioned

<BogdanBrinza> https://svgwg.org/specs/integration/#issue3

BogdanBrinza: issue #3 now

AmeliaBR: animations in resource documents

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

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

BogdanBrinza: why not?

AmeliaBR: I don't see an issue

BogdanBrinza: so you define the resource, as part of the definition there are some animations
... saying there shouldn't be any animations running doesn't make sense to me

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

Rossen: 300x150!

heycam: yes, why not

BogdanBrinza: so if the resource references percentages how do they get resolved

ed: right

BogdanBrinza: similar to background-image?

AmeliaBR: this is SVG resources

ed: say you referenced an external gradient file
... fill: url(externalfile.svg#gradient)

Rossen: how is this different frmo use?

ed: it's not, but it's not defined well there

AmeliaBR: percentages come up in use elements. in same document use elements, percentages are resolved on the original document not the referncing element

Rossen: not for us

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

Rossen: is this based on implemnetations or spec?

AmeliaBR: I'm pretty sure it's in the spec, not necessarily intentionally
... but it is consistent everywhere we tested it
... 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
... again that's not specced, just what implementations do

ed: do you see it as an external document or as nodes being cloned?

Rossen: use is basically copy-on-write
... you have a hosting context
... 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
... for external referenced documents I wouldn't expect different behaviour
... at the very least in terms of sizing and percentages
... it's a separate discussion about animations/transitions running
... so in CSS we have two separate cases where people may or may not expect aniamtions to run
... 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
... that's the difference between display:none subtree, with animations suppressed, and visibility:hidden, in which animations do run
... 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

heycam: for me I don't think about it as a display:none document

Rossen: in general we try to load and run as few things as possible, for perf and power
... running animations would be wasteful
... I don't want to make this problem worse
... so if we can help it, I'd be in support of not running animations

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
... the more I think about it the more I think it makes sense to think about them as display:none

<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."

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
... and the other issue was if you're resolving styles you need to resolve media queries
... the logical approach is set a default size, or to say use the media dimensions of the referencing element

Rossen: that would apply you'd need to resolve properties twice
... once in the lwoer document and once in the host document
... and that would be bad
... you could go a step further and say resolving styles shouldn't happen, but that would prevent sharing too

shepazu: I'm sympathetic to what Rossen said
... I think it seems most consistent/performant
... I think we should make clear what things are referenceable, what are not
... if animations can'tb e expected to be run, authors should understand why that is

heycam: I'd love to see tests but happy to go with not running animations for now

AmeliaBR: for styles and CSS animations afaik nobody resolves styles except inline styles on external use

BogdanBrinza: the way to spec is that things that are context dependent, we just don't have the context for the referenced document
... when did the timeline start?

<BogdanBrinza> https://svgwg.org/specs/integration/#issue4

BogdanBrinza: next one, issue 4

RESOLUTION: Animations do not run in resource documents.

BogdanBrinza: should CSS Variables that map palette colours be mapped into the document here too?
... issue suggests removing this issue, so let's do that

<BogdanBrinza> https://svgwg.org/specs/integration/#issue5

BogdanBrinza: issue 5, this one I've made the changes to this section
... the changes I made are something Cameron mentioned earlier, CORS applying
... 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

heycam: I'd be happy for that to be tightened up

BogdanBrinza: this would be a good test case

<Zakim> AmeliaBR, you wanted to add a new issue re the "font document" section

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

heycam: context-fill,stroke are in the SVG 2 spec, context-value might not be though
... I'll figure out where those other things should be defined, since the OpenType spec is referencing this for the UA style sheet

BogdanBrinza: so that's a requirement and it sounds like the course of action is to ask the OT people to update this?

heycam: I'll write up some text for this

BogdanBrinza: we have this issue about protecting infinite reference cycles
... Chrome/Edge/Safari limit to one level
... Firefox has no limit

heycam: happy to align on the same number of levels

BogdanBrinza: I think ti's the interoperable behaviour we'd want anyway
... the other part is the URL standard reference, it's just editorial

<BogdanBrinza> https://svgwg.org/specs/integration/#issue6

BogdanBrinza: issue 6 is about "Animated mode", should we remove this

<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

BogdanBrinza: oh I propose changing "external references" to "references to external resources"

heycam: it's not being referenced by anything, so let's remove it

nikos: does the OT spec still reference "secure animated mode"?

heycam: maybe

BogdanBrinza: soudns like there was some attempt to address the CORS concerns

AmeliaBR: to clarify, the "secure" modes are currently used
... when you embed SVG as an image, you're using this "secure animated mode"
... we don't have uses where no scripts, but do support external files
... so 3.3 Animated mode there aren't any uses of that

BogdanBrinza: sounds fair

AmeliaBR: there are static renderers that do support external references, so there's a benefit for recognising that his extists
... don't know if it's needed in this context

BogdanBrinza: for external resources, you only have a single level of depth, and there is no script in those resources
... it sounds like we're talking about policies, rather than modes
... and the modes references policies

shepazu: that's what it's doing

BogdanBrinza: there is some slight different

shepazu: sounds fine to fix that

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
... 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
... I don't see anything wrong with efining all the different combiantoisn and giving them names
... so that other specs can clearly reference them and have a clear definition

BogdanBrinza: that is what I propose
... 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
... if needed we can expand with new policies, but still keep the same modes

RESOLUTION: Keep the modes, define them in terms of policies, basically as a table mapping modes to specific policies.

<BogdanBrinza> https://svgwg.org/specs/integration/#issue7

BogdanBrinza: next, issue 7

AmeliaBR: that's the same

<BogdanBrinza> https://svgwg.org/specs/integration/#issue8

BogdanBrinza: issue 8 and 9 are about HTML in foreignObject
... issue 9 is editorial, add examples
... issue 8 I'm not sure I understand it. "what should we say about when to rasterize the content?"
... pixellated form controls?

AmeliaBR: I think that's an obsolete issue
... this was like transforms/filters applied to SVG content with forms in foreignObject
... but now we have transforms/filters applied to HTML content

<BogdanBrinza> https://jsfiddle.net/pscu8wLq/

BogdanBrinza: looks like implementations don't pixellate now
... last issue, 10, this is a todo for defining SVG in foreignObject

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)
... 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

BogdanBrinza: sounds like this is defined in section 4.1

AmeliaBR: that's part of it

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

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

BogdanBrinza: yes that's CSS context, not HTML

AmeliaBR: then if you put an <svg> inside a <foreignObject> then we can treat the <svg> has having a CSS box parent

BogdanBrinza: yes
... there's nothing special about <svg> in <foreignObject> that we need to specify

ed: right

<paradisaeidae> Wow, had never though of such a thing: <svg> inside a <foreignObject>

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

BogdanBrinza: I have a feeling we discussed this in Paris for some of the other chapters, coords?
... we talked about interactions between viewports and containing lbocks
... I think that's the same as we're discussing right now

AmeliaBR: are you ok with rewriting this just to make a single generic description?

BogdanBrinza: I'd imagine we have something somewhere in SVG 2?
... to point to

ed: the initial continaing block?

BogdanBrinza: how ICB maps to viewport and vice versa

ed: section 4.1

<nikos> https://jsfiddle.net/dodgeyhack/nnztjw7s/

nikos: just going back, this example is pixellated in firefox

<AmeliaBR> I think this is the section Bogdan is referring to: https://svgwg.org/svg2-draft/coords.html#ViewportSpace

heycam: don't think it's an issue that needs to be in the spec

coordinate precision in generated content

stakagi: this was an issue Chris Little brought up
... he wanted content for technical drawings, maps. I prepared a wiki page
... with current implementation status
... in this wiki page, in the Conformance chapter of SVG 2 I think that there is no requirement to add normative language

<AmeliaBR> Wiki page: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation#Improving_Significant_Figures_by_Transformation_and_Tiling

stakagi: but for more convenience for content creators I want to add an explanation from this wiki page

AmeliaBR: it's been an issue we brought up a couple of times
... that people are annoyed when they translate data and come up agains the single precision flaot numeric precision
... and for perf reasons nobody wants to require better than single precision floats
... so it's a nice compromise to have authoring (tool) guidance on how to deal with the limitations of the single precision coord system
... whether that's a separate authoring guidance spec or an appendix I don't mind

stakagi: one point, I added Conformance Criteria, the viewer must use double for CTMs, but the TM itself need only be single

<stakagi> https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers

heycam: is there an existing appendix where it would make sense?

AmeliaBR: maybe in Conform where we have conformance class for authoring tools?

<scribe> ACTION: stakagi to add non-normative authoring guidance about content precision to conform.html [recorded in http://www.w3.org/2016/02/05-svg-minutes.html#action01]

<trackbot> Created ACTION-3836 - Add non-normative authoring guidance about content precision to conform.html [on Satoru Takagi - due 2016-02-12].

SVG stroke/corner demo

<ed> http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/simplerect.html

ed: I wanted to experiment with this from the SVG Strokes module
... I created a simple polyfill using dash arrays to emulate corner behaviour
... if you look at this link, which should work in any browser, you see I've highlighted the corners using this feature
... the first polyfill version doesn't handle rounded rect corners, which turned out to be a bit more difficult
... but the spec has noted this as an issue
... where corners should be drawn, all over the arcs?
... this does depend on path length computation methods
... but it does show a way to do a polyfill that could work before browsers implement this
... I also went ahead and did a second demo, where you can specify several corner lengths

<ed> http://xn--dahlstrm-t4a.net/svg/experimental/svg-dashcorner/examples/multidash.html

shepazu: what is the shape with the rectangle with something in it?

ed: that's a polyline
... I chose not to draw corners on each side, just highlighting the corners not the end points

shepazu: why wouldn't this work in Edge?

AmeliaBR: it's an XHR error

ed: in the second demo I use multiple lengths for the different corners
... in the middle rect, you can see two corners have longer dashing
... and looking at the star I used more different lengths
... so with multiple corners you repeat similarly to dasharrays

shepazu: how does stroke-dashcorner array with stroke-dasharray?

Tav: [stole my question!]

ed: hopefully should be defined in the spec
... I didn't mix in the dasharrays that might exist on elements in this demo
... the way it's meant to work is you spread the dasharray between the corners
... and adjust the gaps so that it looks nice, with stroke-dashadjust

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

shepazu: what it sounds a bit like with this collection of features that it's approaching shorrthands/longhands
... might be good to think about it like that

Tav: this deals with corners, what about paths? drawing a map, when you want to have intersections with 3 different regions look nice

ed: in this first simple impl, this uses the new path api polyfill
... it provides you with getting the normalized path seg data out from the path
... I'm just looking for lineto elements

heycam: I think something else would be needed to solve the map intersection case

ed: there are a few issues in the Strokes spec I noted down
... one is issue 8, which says that the points at which the dashcorner are painted include the start/end points of every segment
... I think we shouldn't do that

<ed> https://svgwg.org/specs/strokes/#issue8

ed: another thing I noticed is that one thing that makes it hard to polyfill is that dasharrays start over again for new subpaths
... it's difficult to get the dasharrays positioned properly
... you have to break it apart into several path elements
... if the dahsarray starts over, then you can't do anything custom for that one

AmeliaBR: as in your might need a half dash?

ed: you want a new dasharray per subpath

AmeliaBR: your polyfill will have to define every single dash in the whole path

ed: I know we decided that's the way it works
... I think you can still break up the element if you need to

heycam: pretty sure dashing works like that everywhere

AmeliaBR: if the worst we can say is that the polyfill is less performant that's ok

Future F2Fs

nikos: TPAC is in September, Graphical Web is early November
... CSSWG is meeting in May 2nd week in US
... I feel like we're a bit constrained by Invited Experts who might not be able to travel far/often
... so we should try to go where they are instead

shepazu: meeting with CSS is usually productive
... I would hope that Amelia could attend in the US?

AmeliaBR: I can't make promises unless someone finds a grant for me

shepazu: Tav, could you travel in May to the US?

Tav: might be difficult
... I'll have some money, have a designated budget, but it would exhaust it

shepazu: I think it would be useful to have a F2F with CSS but I understand the constraints
... do we need to schedule a F2F?

nikos: lots of us can only dedicate time to SVG around F2Fs
... it's more a case of where and when
... so TPAC and Graphical Web are close together, a month apart
... we've been invited to meet at Graphical Web

Tav: that would be much more practical for two reasons
... one, for me, the one time I attended TPAC the day and a half we spent wasn't much
... a long way to go for 1.5 days
... two, I will probably be going to Graphical Web
... so it would be a small incremental cost to stay for a WG meeting

nikos: I feel similarly about TPAC
... quite short, good but we tend to get more done at other dedicated WG meetings

shepazu: I think the point of TPAC is to coordinate with other WGs
... and if we don't find we need to coorindate with groups other than CSS...

Rossen: I agree that meeting with CSS is awesome, whenever we have the opportunity to do it
... the one other thing I wanted to put on the table, would we having any specific goals in May or whenever?
... one of the specific goals we had as a WG from Linkoping, was to come here and be ready to have CR
... we are underdelivering on that goal
... 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
... as long as we can find a place and time
... but I'm trying to explore options where we can still make progress without needing to meet F2F

shepazu: I think Rossen raises a great point
... 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
... having weekly goals towards May
... since that's not far away
... regarding Graphical Web vs TPAC, I'm really busy at TPAC
... 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

nikos: a crazy idea might be to meet sooner than May

AmeliaBR: there is the April Libre Graphics conference
... there's a chance I'll be there but can't promise
... that's London early April
... 15-18 April

Tav: I will most likely be there
... Inkscape will have a hackfest before that

<shepazu> http://libregraphicsmeeting.org/2016/

Rossen: if we're organising around community engagement opportunities, it would be cool we could brag about shipping SVG 2
... the other thing, attracting implementor interest
... if and when we're done with this CR stage, it would be great to start talking about where we go next
... and how do we rev all the impls
... 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

Tav: that confuses me a little, as you're talking about modularization with CSS

Rossen: and I'm waiting for this module to be done
... I think I made some attempts to modularize other things out of it
... and yes I want to see what will happen with the next modules

Tav: you would consider implementing some of the stable parts?

Rossen: if it's in a stable SVG 2? yes
... 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
... much easier to implement, particuarly if it's a gap, against a stable spec that's not going to keep going back/forth
... so, when are we going to ship?
... if F2F is a forcing function, I would be in favour of having it whenever/whereever
... but there needs to be more -- to justify the expense -- we need more data to say that's actually going to happen
... or if we're pretty much there and just need to nail down a few things
... which was our assumption coming here

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

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

nikos: so Text and Cooridnates need to get fixed

Tav: I would hope to get Text done in a month

nikos: so is it worth having a F2F at Libre Graphics?

AmeliaBR: if you organise it I will come

nikos: for me I could get there if it's after Libre Graphics

ed: it would be easier for me, being there

Rossen: my vote would certainly be May since I'll be at CSS/Houdini
... could I come in April? don't know

BogdanBrinza: it would be challening for me to attend in April

nikos: one advantage to getting a few people together, we could VC with other people if any issues come up for discussion
... for May...

shane: 9-11 CSS, 12-13 Houdini
... need to let us know as soon as possible if SVG wants to meet there

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
... that's good for Erik, Tav, Amelia can maybe attend too
... 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.

shepazu: a hybrid option is to have an editor's meeting at Libre Graphics and then have a F2F in May with CSS

AmeliaBR: so April will be clean everything up so in May we have a document we agree with shipping?

nikos: I could come to both, if that's what needs to be done
... I think if we got together in London, it would be pretty productive
... 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

<birtles> scribenick: birtles

Rossen: SF will be busy at that time

nikos: we'll go with April and discuss May after the break

<nikos> AmeliaBR: we're mostly back

<heycam> ScribeNick: 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
... in terms of reviewing and finishing off the spec text
... not for talking about issues
... if we meet in May it's in the US, where we're likely to have Rossen, myself, Shane, Bogdan maybe
... if we get the spec done at the April meeting, issues will start getting raised as we make our way through the test suite
... if we met in May even without the April meeting, what would be on the agenda for May?
... so meeting later than May, to discuss issues that arose from test writing sounds better
... 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
... so something like July, don't know where though

RESOLUTION: Spec editors will meet in April adjacent to Libre Graphics, no meeting in May, organising SVG meeting July or so later.

SVG feature interest from implementors

shane: as an implementor, best bet for getting new SVG features in browsers is to make them relevant
... so they need to integrate well with HTML
... 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

AmeliaBR: some of these features are make SVG behave more like HTML

Tav: there are a variety of things that already work in HTML, and we just need to make sure they work in SVG
... like text-orientation, the font features, so we just have to make sure when they're implemented for HTML they work in SVG too
... the filter shorthands for example work in HTML in Chrome but not in SVG

ed: that's right

Tav: so that should be low hanging fruit to pick up

shane: that might be low hanging fruit, but there has to be demand
... if you want to think like an implementor, they're going to be looking at what the general webdev public demands
... if there's no demand from authors then it won't be prioritised

Tav: it's a chicken and egg problem
... what I'm going to do, is I'll start enabling some things in Inkscape output

nikos: we could start tracking what features are actually implemented
... so we can get a handle on what is starting to be implemented

Rossen: also, as an implementor, I want something that is stable
... if it's not stable I'm not going to look atit
... 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
... it's the door-opener
... I have spoken to some other implementations that have large adoption, and they have similar feedback

shepazu: so you're saying stabilise, then we'll pay attention

Rossen: yes, that's what I've been saying for 15 months

shepazu: because SVG is a large spec, is stabilising chapters a reasonable thing? or it has to be the whole thing?

Rossen: can we break these chapters into their own modules and say this thing is CR?

AmeliaBR: at this point that would slow things down

Rossen: it seems like the spec is going in the right direction though
... here's a simple kind of conversation that will happen in a company like ours
... 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
... as an implementor I want to go and do that work, but can't, because I'm resource bound
... 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?
... that the message this WG must be able to send, to say it's done
... to say it's stable and ready for implementation
... it's just this really long timeline that is holding us back
... we did the same thing with CSS, at least in IE
... until 2.1 was stable there wasn't a good reason to go and implement it

alex: from Chrome's PoV, my experience in SVG and standards I agree with Rossen
... with the 1.2T timeframe, JSR226, there are other standards bodies that want a stable spec before looking at it
... from Chrome's impl PoV it's irrelevant, but from a standards PoV yes

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

Rossen: but this is what CR is for

birtles: not talking about the process
... 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
... saying the goal is "SVG 2" is a big sell

alex: I think the point of W3C process, CR is the thing to get things out the door

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...

Rossen: sure, but at this point how do you know these will be the same features by the time the spec is in CR?
... there's a Rec process for a reason
... so going out there and saying that you know these features are going to be the way they are...
... there is a formalised standardisation process which serves at least one thing that's good, which is "this is a stable spec"

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

Rossen: prioritisation?

birtles: yes
... trying to say "lets do all of SVG 2" is an overwhelmingly big task
... if someone wants to prioitise and agree on how to prioritise that's an easier sell

Rossen: then you get into 80/20 problem

<Zakim> AmeliaBR, you wanted to recast discussion: which parts of the spec are stable enough to start building tests?

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
... 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
... and the other thing is testing
... 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
... 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

nikos: the other topic is marking features at risk for CR
... i don't really know the process for that sort of thing

alex: I think you just get implementor feedback about what things are likely to be implemented

shepazu: we mark features at risk if we feel they're not going to be implemented
... with the new process, going back to CR which used to be more painful, is streamlined
... so Process2015 streamlines with how you iterate on a spec
... It hink we should be resonbile without we try to portray issues
... it's not as useful to identify these at risk features before CR now with the new process

BogdanBrinza: I might repeat Rossen's view in a pragmatic way
... there have been features implemented in other browsers, Inkscape; we'll gladly implement things we feel we need to implement
... features that are being used out there
... support in other browsers is great, and it shows the pipeline
... we're #3 or #4 browser now, so we're under no pressure to implement
... we will show our interest and implement things we have to

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
... for now let's just get the text in coords/text chapters finished

SVGZoomEvent

<nikos> https://github.com/w3c/svgwg/issues/21

nikos: the question was raised by chromium folks, about whether SVGZoomEvent is needed
... whether anyone uses it
... it wasn't clear to them from reading the spec how it should work
... when currentScale changes the event should be fired, I think
... there was some history with Opera Presto which had a control to scale SVG content within the page

ed: apparently SVGZoomEvent doesn't work in Chrome
... so I think they're looking to see whether they can drop it
... not sure if people are trying to dependent on this

BogdanBrinza: are there use counters?

nikos: no mention of them

<paradisaeidae> Please don't drop SVGZoomEvent

AmeliaBR: I suspect it's very poorly used just because there no active implementations right now have user controlled pan and zoom options
... so I'm not sure whether anybody fires this event for pinch zoom etc.
... so it's certainly an edge case

<paradisaeidae> Use counters are not potentialUseContersWhenUseIsUnderstoodCounters

Rossen: was the zoom event raised on user zoom or pinch zoom?

AmeliaBR: SVG used to have zoomAndPan, which users coul use to zoom in/out

<paradisaeidae> This is an area I did not have time to put to the panel last night.

AmeliaBR: and then authors could listen to this event to respond to these zooms

Rossen: you say there's interactivity where the user is interacting with SVG content, based on which other SVG content...

AmeliaBR: the idea was the browser would show zoom UI
... but nobody does that
... (since Opera Presto was dropped)

Rossen: today we're hiding the interaction between pinch zooming and viewport more and more

<paradisaeidae> SVGZoomEvent can signal the level of detail to be rendered.

Rossen: so that you can implement efficient zooming in the GPU

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

Rossen: these things work well today in response to touch events, etc.
... zooming is a user instantiated action which is controlled on the app layer most of the time
... in that case, you know how your application should behave
... there's no reason to have another event to say the user did a pinch gesture
... this is your app, you know what that gesture means
... without needing another event which means your zooming
... what Amelia said makes sense, if the browser was allowing zoom in a script-undetectable way, then it makes sense

<paradisaeidae> is pinch the only way zooming can be signalled?

shepazu: there's any number of ways users can initiate these things
... however they did it, it's like an INDIE UI thing
... letting the page know that the user zoomed, the page reacts

Rossen: if this is the case, why doesn't HTML have the same thing?

<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.

shepazu: the kinds of apps you build with HTML are different

Rossen: we have a semantic zoom to say you can double tap to different menus, categories, different levels of HTML layers
... nothing to do with CSS
... so I'm questioning the need for the necessity for this event

alex: should put a use counter on it

<stakagi> Regardless of SVG, the event about zoom on web browsers is made confused.

nikos: according to the bug it's not implemented but it can be feature detected

AmeliaBR: it was implemented in the Adobe viewer which had those controls
... I would argue against what some of what Rossen said, I'd love to see a semantic zoom event
... 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

BogdanBrinza: looking at Chromium source it's declared but not used

nikos: sounds like there might be good use cases for this but it's not specced properly

AmeliaBR: we could for wording tie it into the znp control wording

nikos: sounds like this could be removed and looked at in a wholistic way later on

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

RESOLUTION: Remove SVGZoomEvent from SVG 2.

<nikos> scribenick: nikos

Exclusion shapes for text

Tav: The spec right now uses shape-outside
... It doesn't really match the CSS concept of shape-outside
... which is to specify a region that an object is shrunk by

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)
... and here are two or three other shapes, that if they intercept with the shape inside, they subtract geometry from the shape
... a nice term for describing this might be shape-subtract, or shape-exclude
... shape-subtract further changes the shape specified fro shape-inside if there's an intersection

<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?

Rossen: 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)
... 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

RESOLUTION: Rename shape-outside to shape-subtract to reflect that the way it is specified is different than shape-outside in CSS.

- DRAFT -

SV_MEETING_TITLE

05 Feb 2016

Attendees

Contents