SVG Working Group Teleconference -- 25 Aug 2015

<heycam> krit, FX topics will be right after the agenda rearrangement discussion this morning

<krit> heycam: will call in around 10am

<krit> heycam: will there be a video conference?

<heycam> krit, there will -- you'll need to use the link that simon provided in his mail, rather than the link I gave

<krit> K, thanks

<heycam> krit, FX is moving to Thursday morning now, sorry

<heycam> so that Dean can be here

<heycam> so we'll be in the usual room after all

<SimonSapin> krit: ping me when you want to call in

<birtles> I'm waiting to see what the agenda is for CSS for today before I decide if I should stay or not

<birtles> I also realised I didn't send the minutes from yesterday

<heycam> birtles, ok

<heycam> there is a special url to go to generate a previous day's minutes

<birtles> heycam: cheers

<heycam> birtles, yeah so you go to say http://www.w3.org/2015/08/24-svg-irc,minutes

<heycam> so the IRC log url plus ",minutes"

<heycam> I don't know whether that will upload the generated minutes to the expected URL though

<ed_work_> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/svg/SVGSVGElement.cpp&l=102 (for SVGSVGElement.viewport)

<birtles> yeah, I can't manage to get the minutes to be uploaded

<heycam> birtles, ok; maybe just attach the HTML to the mail, then, so it still has some URL

<birtles> heycam, I can't get the regular plain text version so I was just going to make up my own plain text version that is similar to the usual one... but is that going to break your tool that scrapes the minutes emails?

<heycam> birtles, no it'll be fine

<ed_work_> just add ,text to the end of the minutes url, should work?

<heycam> but good point; the tool will expect the normal minutes url so I guess it'll miss them

<heycam> I'll do something manual to add it after you send it

<birtles> yeah, adding ,text doesn't work

<krit> SimonSapin: ping

<SimonSapin> krit: Do you wanna join CSS or SVG?

<krit> no FX today?

<heycam> krit, it got moved to Thursday

<krit> ok, SVG then

<krit> birtles: Do you know what Animations 2 will be?

<krit> birtles: on the agenda of CSS WG tomorro

<krit> birtles: on the agenda of CSS WG tomorrow

<birtles> krit: I think it ended up being Wednesday afternoon

<krit> birtles: yes, but what is it? WebAnimation 2 or CSS Animations 2?

<birtles> krit: https://wiki.csswg.org/planning/paris-2015#wednesday

<birtles> krit: CSS Animations 2

<krit> birtles: who suggested it? Is there a draft?

<birtles> krit: Shane and I. Yes.

<birtles> krit: https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html

<TabAtkins> https://drafts.csswg.org/css-animations-2/

<krit> thanks

<shane> krit: Tab's link is wrong.

<birtles> TabAtkins: the one we want to ask about tomorrow is a later version than that

<krit> k

<TabAtkins> birtles: You should be pushing it!

<birtles> TabAtkins: pushing it?

<TabAtkins> To the repo

<birtles> TabAtkins: I want to get the ok that this approach is ok

<birtles> (also I don't have write access to the css repo)

<TabAtkins> Shane does!

<shane> we wanted to talk about whether we could stop being a delta specification first, I think?

<birtles> yeah, I wanted to ask how I should write it with regards to linking to Web Animations

<krit> birtles: shane: So version 2 will mostly be set up CSS Animations on top of WebAnimation and add animation-composite

<birtles> krit: yeah, basically + animationcancel I think

<shane> birtles: were we going to propose a simple exposure of groups too?

<birtles> and any other features that get added along the way... e.g. there are some discussions about extending timing-functions recently

<shane> or hmm I guess not as that isn't in a WebAnim WD yet...

<birtles> yeah, maybe not, depends on the timeframe for animations-2

<krit> could you add a simple example for 4.5. Animation composite order please?

<krit> (to the draft)

<birtles> krit: yes, of course

<krit> looks great. Not necessarily easy to understand right away from reading it but this is editorial

<heycam> (krit, you can call in whenever you want)

<krit> heycam: is there an agenda for today?

<heycam> krit, yes there are a few topics on the wiki

<heycam> krit, we can discuss them whenever

<heycam> trackbot, start telcon

<trackbot> Date: 25 August 2015

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

SVGSVGElement.viewport

<ed_work_> https://svgwg.org/svg2-draft/struct.html#issue62

ed: issue 62 in the structure chapter is about SVGSVGElement.viewport
... currently Blink is just returning an SVGRect filled with zeroes
... Firefox does not implement it
... my proposal would be to drop the attribute

krit: did you check the usage of it?
... I thought I saw it was used

ed: I've seen people try to use it but then use fallbacks to get the information another way
... using innerHeight etc.

Tav: if it were implemented, would it be useful?

heycam: it's never been clear to me what viewport should return, so I don't know

ed: yes, so figuring out what it's supposed to return is a question
... the problem in Blink was that it was hard to get the right values at the right time
... so you could return something but it might not be the correct values

heycam: Edge does return a rectangle with some values in it

BogdanBrinza: if it were useful I think we would have heard about it

<ed_work_> https://code.google.com/p/chromium/issues/detail?id=395838

<ed_work_> https://bugzilla.mozilla.org/show_bug.cgi?id=503855

krit: not implemented in WebKit

cyril: if you animate the viewBox would you expect to see the values in .viewport?

heycam: I think it's an open question what viewport was intended to return
... it's not clear

[some discussion about what viewport might mean]

Tav: so is this related to pAR?

krit: with pAR the viewBox size is different from the viewport size
... I think the point where it would be useful is if you want to put say a background rectangle covering the window

heycam: testing in Edge, the .viewport.{width,height} just return whatever value would be returned by .{width,height}.baseVal

<krit> https://www.irccloud.com/pastebin/38EnSIQu/

krit: what does Edge return for .viewport for the inner <svg>?

<BogdanBrinza> http://jsfiddle.net/boggydigital/mh0tgwn7/2/

heycam: so currently you can get all this information by looking up x/y/width/height property in the SVG DOM
... and for exposing the size of the window that the outer <svg> is fit into, you can look up window.innerWidth/innerHeight
... and I can't think of any other useful values to return. so I suggest just removing it.

RESOLUTION: We will remove SVGSVGElement.viewport.

<scribe> ACTION: Erik to remove SVGSVGElement.viewport. [recorded in http://www.w3.org/2015/08/25-svg-minutes.html#action01]

<trackbot> Created ACTION-3815 - Remove svgsvgelement.viewport. [on Erik Dahlström - due 2015-09-01].

Filtering elements when creating use shadow trees

<ed_work_> https://svgwg.org/svg2-draft/struct.html#issue58

ed: right now, you can point a <use> to pretty much anything, and it will just clone that subtree with anything that's in it
... Blink is currently filtering out some elements from when it builds the shadow trees
... so foreignObject is not included, for example
... my question is should this be something that we specify?

Tav: so you can't have clones of video playing

ed: right now I know if you have video inside foreignObejct, you get the wrong position

heycam: what's the reason for disallowing these elements?

ed: first, not all aspects of what cloning means is still not clear
... whether the clones are "linked" somehow
... and the spec was not clear on what should happen
... if you have some kind of interaction, would that update all instances?

heycam: I think this will fall out of how we define use in terms of shadow trees
... so it will be clear what's meant to happen, though not sure if that will be the desirable behaviour or not

ed: Blink builds the cloned tree, then strips out the disallowed elements

heycam: so that could affect how CSS selectors match things in the tree?

ed: yes

heycam: so maybe force them display:none instead?
... when we define in terms of web components it's very likely these will be independent cloned subtrees
... since shadow dom doesn't support the kind of unified tree that SVG tried to have
... if that's the case, then the videos etc. will all be independent, and there should be no problems

ed: ok. in that case I'll just remove the issue, and reword it to mention expected behaviour with independent clones

cyril: I saw a small issue about unknown elements -- in embedded content it has a mention of not rendering unknown elements

Media fragments issues

<BogdanBrinza> sample: http://jsfiddle.net/boggydigital/gcthq51u/show/

BogdanBrinza: I'd like to discuss each of these issues

<BogdanBrinza> chapter: https://svgwg.org/svg2-draft/linking.html

BogdanBrinza: no discussion needed for issues 4 and 5 in the chapter

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue6

BogdanBrinza: currently transforms on svgView does something weird
... in Chrome/Edge it's consistent, and looks like it's scaling from the 0,0 of the original image
... in Firefox it looks like it's applying from the 0,0 point of the viewBox transformed image
... in the sample I've pasted, it's the third picture

heycam: the question then is what's the order of the viewBox transform and transform attribute transform?

BogdanBrinza: yes

heycam: I would expect the order to be the same as if you had <svg viewBox="..." style="transform: ..."> in the document itself

BogdanBrinza: I think Firefox's behaviour makes more sense
... the spec also doesn't mention anything about transform-origin
... that's issue 7

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue7

BogdanBrinza: without transform-origin, the usefulness of this is limited
... harder to get the transform you want
... so I think we should support transformOrigin at least in the view spec
... if we do want to continue allowing transform(), I suggest we should bring along those other features like transform-origin

heycam: if you don't specify in transform-origin, would it be relative to 50% 50%

BogdanBrinza: yes I would say it should match what happens on the root <svg> element, so 50% 50%
... the other one is perspective
... I would say either add transform-origin/perspective, or remove transform

heycam: supporting perspective here sounds a bit more complex

BogdanBrinza: with my implementor hat on, I would be worried about that complexity
... I would be fine with the current set of view spec features, so not adding transform-origin/perspective for now
... unless we hear demand for it

RESOLUTION: We won't add transform-origin/perspective values for view specs.

yet

RESOLUTION: viewspec's transform applies after performing the viewbox transform

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8

BogdanBrinza: this says spaces are not allowed, and semicolons separate fragments "may" be URL escaped
... it looks like spaces are accepted in the browsers
... at least in Firefox/Blink/Edge
... for URL escaping, it doesn't work in Blink but does in Firefox and Edge

heycam: I think we don't need to talk about escaping
... that happens at a layer before the spec cares about it
... I'm fine with allowing spaces since everyone does

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue8

scroll down from that to the second issue 5

BogdanBrinza: xywh allows pixels (default) or percents
... how do these map to SVG units?

heycam: I think xywh applies at the CSS image level
... so percentages should resolve against whatever size of image that CSS is going to tile/position/etc. from the background-* properties
... not sure what the right term is

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue9

BogdanBrinza: when referencing a specific view, the spec talks about getting the view of the closest ancestor SVG element displayed in the viewport
... what is the expected effect if the closest ancestor svg is not the root element?

heycam: I'm not sure just updating the inner <svg>'s viewBox etc. attributes gives you useful behaviour

BogdanBrinza: it's a bit confusing that it applies to the inner <svg>. the position of the <view> element in the document would affect what's happening

RESOLUTION: The view element always applies to the outermost <svg>, even when inside an inner <svg>.

<BogdanBrinza> https://svgwg.org/svg2-draft/linking.html#issue10

heycam: this about whether missing viewspec values get set to their initial value, or whether the document's value is used

ed: I think you get strange results if you blow away everything
... I think you don't want to do that usually
... and you just want to override one of them
... if you blow off the viewBox for example it's going to be very strange

BogdanBrinza: looks like we agree that it should override specific attributes then

RESOLUTION: Missing viewspec values use the values specified in the document, not resetting them back to their defaults.

<ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg

<ed_work_> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg

TabAtkins, where is it defined that url() values in properties are resolved against the document's base (as given by <base>)? and does this apply to every property that takes a url()?

<BogdanBrinza> http://pastebin.com/vpYSzfZm

<scribe> ScribeNick: heycam

zoom media features

<tkonno> http://rawgit.com/satakagi/mediaQueryZoom/master/index.html

tkonno: this presentation will udpate you on the proposal for zoom features for media queries
... Takagi-san sent an email to www-style with this draft spec

<TabAtkins> heycam: https://drafts.csswg.org/css-values/#relative-urls

tkonno: for changing style and contents according to zoom ratio
... we've written a polyfill
... we'd like to bring this initial draft to an editor's draft
... let's go through some use cases
... two use cases here: mapping, and high resolution photos
... at KDDI we're interested in mapping using SVG
... for mapping, when the map is zoomed out, the user wants to know only the overview of that area
... otoh, when the map is zoomed in, the user wants to know the detail of the area, such as some landmarks
... as you know, map content is made up from different layers
... base map, plus other layers on top
... if the content layers are switched according to zoom, the user can get the appropriate information
... the function to switch the content layer is essential for mapping
... second use case is high resolution photos
... here's an example from MS
... this is a smoothly zoomable high resolution image
... when zoomed in, it uses a high resolution image
... currently, these use cases are realized by massive.js or standards other than web standards
... so we'd like to realize these use cases using web standards
... so how can we do this?
... the min-zoom feature is a new media feature
... its value (ZoomRatio) is a threshold

[see presentation for example code]

scribe: I'll explain what's meant by "zoom" here
... zoom functionality is divided into two types: one is the UA native zoom, and the other is the web app's zoom
... UA native page zoom affects the initial viewport size
... pinch zoom is also something controlled by the UA, but this doesn't affect the viewport size
... it behaves like a magnifying glass
... as for the web app's zoom, CSS Transforms can control the scale of the contents
... so the zoom should be represented as a combination of UA's zoom and the web app's zoom

[formula in the presentation relating the device pixel size and all these zooms]

tkonno: not sure whether all 6 of the types of zooms I've listed in the presentation are useful
... for the mapping use case, document-zoom is the useful one
... for the other zoom types depends on the use cases

heycam: and for the high resolution image use case?

tkonno: document-zoom too
... the zoom property has already been included in the CSS Device Adaptation spec

<cyril> http://www.w3.org/TR/css-device-adapt/

heycam: not sure if people implement CSS Device Adaptation, so not sure I would worry about compatibility with it

tkonno: so I think only document-zoom is needed for our use case
... so that includes pinch zoom and CSS Transforms

cyril: what about currentScale?

heycam: I imagine that, viewBox transform, etc. would all be included, since you're including transform property

tkonno: so why do we need document-zoom feature?
... a web page might have map content in an iframe. the user might zoom in the whole web site, not just transform the embedded element
... but the user could also just scale the iframe's contents
... so I'd like to know if the concept is acceptible, and whether the document-zoom feature proposal specifically is acceptable?

BogdanBrinza: at the last F2F, we had some private discussions about the use cases here. we agree the use cases are valuable.
... the way we've been thinking about this is focussed on the performance
... for the zoom features, you want to have this as late in the pipeline as possible
... at the display level, if possible
... in terms of types of zoom feature, I'm not sure I agree we need more than one type
... the resulting content, in any form, would have the transform available on it
... either you transform the whole document, or an iframe, or just one element -- the content you care about will have a transform available
... so I don't think we need many zoom types
... so selecting the zoom for a specific element itself

birtles: in the proposal, document-zoom is the only one needed
... the only reason for proposing (1) was for consistency with CSS Device Adaptation, but per discussion, that's not important

BogdanBrinza: the other comment is that there are various other display time conditions you might want to target
... inertia of scroll, for example; hide elements based on the speed you're panning currently

birtles: that'd be an orthogonal media feature?

BogdanBrinza: yes. there might be others.
... but yes, we find it acceptable to discuss this further

birtles: konno-san previously summarised discussion up to now in a wiki page, at TPAC 2 years ago there was an action on someone to think about all the different types of zooming

<nikos> scribenick: nikos

<scribe> Scribe: Nikos

Behaviour of getCTM on root svg element

heycam: one of the two remaining open issues in types chapter is what getCTM should do whne called on root svg element

and what getScreenCTM should do altogether

scribe: it's really the same issue
... getCTM gives transform from current element to closest ancestor svg or viewport establishing element (maybe)
... though not clear what happens if you call it on outermost svg element
... you have viewbox, transform property, etc
... all of these things may or may not be intended to be included in the result
... I made some test cases
... linked on the agenda page
... first is when svg element has no attributes

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015/Agenda

<heycam> http://mcc.id.au/temp/ctm.svg

<heycam> http://mcc.id.au/temp/ctm-viewbox.svg

<heycam> http://mcc.id.au/temp/ctm-transform.svg

<heycam> http://mcc.id.au/temp/ctm-currentScale.svg

scribe: FF returns null when you call getCTM on root element
... all others return something, but differ on what transforms are included
... first example in Chrome returns identity, in IE11 identity, same in Safari I think
... that's the simple case - no features that would have a transform
... so at least we're getting a reasonable result there
... second example - with viewBox attribute
... Chrome appears to give transform that implements the viewBox - incorporates pAR
... Safari also gives useful values
... so I think all the browsers that implement it are including the viewBox
... next one is with the transform property applied
... I think some browsers don't do transform as a presentation attribute on svg elements
... Chrome doesn't included it, Edge is the same
... Safari is also identity matrix
... so no one is including the transform property
... but the transform property is kind of new and getCTM is old
... finally, the currentScale value, Chrome also doesn't included that
... but Edge and IE11 do
... Safari does not
... are there any other transforms that I've forgotten about? that work on the root element?
... perhaps the ones that come from the view fragment.

BogdanBrinza: CSS zoom property?

heycam: don't think we implement that
... thought it wasn't clear what zoom was supposed to do

BogdanBrinza: legacy IE and Chrome supports it

heycam: So what thing should be included in the getCTM?
... is the answer all of these things?
... if you think about what getCTM means for other elements in the document. It means give me the transform up to some thing
... so my feeling is that including all of the viewBox and transform properties would make sense
... transform is the one that no one includes currently, but I think it makes sense to include it

BogdanBrinza: doesn't make sense to include all others but not transform

cyril: I guess you want it to be consistent if you copy the SVG into another file
... there's localisation of the transform

<heycam> https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getCTM

heycam: One way I was considering dealing with getScreenCTM was to take all the transforms from viewport establishing elements and multiply them together to give the screenCTM

BogdanBrinza: when would you want to use this?

heycam: one thing might be with mouse events - transform clientX,clientY by getScreenCTM should give you window co-ordinates right?

BogdanBrinza: that's done by screenX,screenY
... I really can't imagine a scenario

heycam: one thing I've done before is create some UIs
... and have some content that is at a fixed size and position in the window irrespective of zoom and pan, etc
... these days you'd probably take that out of the svg document and use position:fixed

BogdanBrinza: I can't see why you would want to keep something in the SVG file that must be relative to the screen
... any scenarios in InkScape?

Tav: ... can't think of anything

heycam: I think the only two viable options are to return a matrix that includes all the transforms, or none of the transforms
... talking about getCTM here
... getScreenCTM has a more clear meaning
... I haven't done testing with getScreenCTM to ensure all these transforms are included

BogdanBrinza: I would argue for having all of the transforms
... the transforms have meaning and that's what would be expected from getCTM

heycam: I agree

<heycam> RESOLUTION: getCTM will return a matrix with viewBox, transform property and currentScale/currentTranslate included

cyril: If you take an svg element with a viewBox and nest it within another svg element with the same attributes, the CTM is the same for the inner and outer SVG
... I just tested this
... in Chrome

<heycam> ScribeNick: heycam

<scribe> Scribe: Cameron

changing overflow behaviour of markers in UA style sheet

nikos: as much as I hate bringing up old conversations.
... previously we said marker { overflow:hidden } would be removed from the UA style sheet
... creating markers around (0,0) seems useful
... the issue is how much content would that break? do we want to go ahead with this?

Tav: I think the decision was a bit wishy-washy

heycam: and overflow:hidden is uniformly applied to markers in implementation?

nikos: yes

heycam: perhaps let's not tempt fate then

nikos: so keeping overflow:hidden for markers and symbol, not the nicest option, but should be the one to go with
... we talked about this for symbols recently -- since we have refX/refY, that helps

heycam: and you can always stick overflow:visible on

Tav: Chris was for it, at the time

heycam: I'm happy to leave it as it is

RESOLUTION: We will leave overflow:hidden in the UA style shet for marker and symbol

initial clipping path

nikos: there's a section in the Rendering chapter defining the "initial clipping path", as being on the <svg> element as a result of overflow:hidden
... the term doesn't get used anywhere really
... there's one reference to it in the coords chapter
... but it doesn't say much

Tav: was that to avoid a huge clipping path?

nikos: no, it's just a term that's defined that isn't used

heycam: just get rid of it

base and xml:base

<ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/base/base.svg

ed: here's an example showing HTML <base> element applying inside an SVG file
... it shows a selection of SVG element using some kind of URL resource
... we have <image>, the first example

if it says "base" it is using the base to resolve the url

scribe: for the textPath example, it will show upside down text if base is applied
... for the a element, just look at the URL if it has "resources" in it it's using base
... for the last one, green means using base

ed: so Firefox support <base> for all of these cases
... for Blink, it works in some cases, not all -- textPath is not using base
... there might be a bug for the fills, it should show red if base is not applied, but it's showing blank

https://drafts.csswg.org/css-values/#relative-urls

heycam: so according to the spec, all url() values resolve against the document's base (if inline style sheet), or the style sheet url (if external style sheet)

<TabAtkins> No, against the *element's* base (for inline)

<TabAtkins> (which usually is the document's base)

ok. yeah, considering xml:base.

<TabAtkins> yeah

TabAtkins, does CSS have any value syntax that means "reference to element with an ID in the document"?

to use in place of url(#x)?

like element(x)?

<TabAtkins> element() takes an id selector in the first place

<TabAtkins> element(#x)

ooh

<TabAtkins> But it's an <image> value.

<TabAtkins> Not for arbitrary usage.

<ed_paris> http://stackoverflow.com/questions/1889076/is-it-recommended-to-use-the-base-html-tag/1889898#1889898

<cyril> https://tools.ietf.org/html/rfc3986#page-28

<cyril> the important section is section 5

BogdanBrinza: does anybody disagree with just following the existing CSS rules for resolving relative URLs?

heycam: no, that's the behaviour I would prefer. I don't want special behaviour for SVG properties.

<ed_paris> https://svgwg.org/svg2-draft/struct.html#issue61

[Bogdan shows an example of background-image:url(#) resolving against a base URL that points to a PNG]

RESOLUTION: fill:url(#something) is resolved against the base URL, just like other CSS properties.

<scribe> ACTION: Erik to add a note to the spec for authors to beward of url(#localid) resolving against the base URL. [recorded in http://www.w3.org/2015/08/25-svg-minutes.html#action02]

<trackbot> Created ACTION-3816 - Add a note to the spec for authors to beward of url(#localid) resolving against the base url. [on Erik Dahlström - due 2015-09-01].

ed: next is xml:base

<ed_paris> http://xn--dahlstrm-t4a.net/svg/structure/xmlbase/xmlbase.svg

ed: this is more inconsistent across browsers
... Blink doesn't seem to apply xml:base anywhere

BogdanBrinza: Edge is the same as Chrome

ed: Firefox is applying it everywhere

<birtles> https://code.google.com/p/chromium/issues/detail?id=341854

heycam: I would be happy to remove it

birtles: from Anne's comments in there, since Blink has already removed it, it sounds like it should be removed from DOM/HTML

<birtles> specifically comment 12

RESOLUTION: Remove xml:base.

<TabAtkins> +1

<BogdanBrinza> pasting example we've used to check CSS # resource resolution: http://pastebin.com/AZmNc7EC (uncomment placehold.it and comment svg to switch between the two)

<BogdanBrinza> http://pastebin.com/AZmNc7EC

<ed_paris> https://css-tricks.com/tight-fitting-svg-shapes/

<scribe> Meeting: SVG Working Group Paris F2F 2015, day 2

<scribe> Chair: Cameron

<scribe> Scribe: Cameron, Nikos

- DRAFT -

SVG Working Group Teleconference

25 Aug 2015

Attendees

Contents