SVG Working Group Teleconference -- 01 Jul 2019

<chris> I heard krit but not myles

<scribe> scribeNick: krit

Decide what to do with zoom and pan

GitHub: https://github.com/w3c/svgwg/issues/56

AmeliaBR: zoom and pan is an attribute from SVG 1 that never got fully implemented by browsers
... last implementation was the Adobe SVG Plugin
... issue resurfaces last month when it was mentioned that there is interaction with other features
... with some that are implemented on the DOM level and we got feedback from UAs what does and does not work
... Blink does have some panning and zooming and it is buggy in the edge cases. Not sure if it counts as an implementation that needs preserving
... unfortunately they don't have metrics
... it works for standalone SVGs and embedded SVGs.
... but it is not intecreted with zooming
... my proposal is to drop the attribtue
... but keep the DOM properties but define them better in a way that interacts with other features like viewBox and the SVG view behaviour.
... but it still needs work to figure out what the redefinition would look like
... but that can be discussed separately

krit: what are the alternatives used today?

chris: manipulate the viewBox using script or apply transform using script

AmeliaBR: zoom and pan is about telling the browther to use its own zoom and pan with defaults and an attribute to disable that

<chris> it seems fine to me to drop the attr

AmeliaBR: since most browsers don't use zoom and pan features, ppl are not using the attribute to disable it. So if browsers would start implementing it it would break things too.

myles: removing it makes sense to remove it

chris: Agree. It gives control over a not implemented feature.

AmeliaBR: I'd like to have an opt-in for a browser zoom and pan feature but it probably wouldn't work this way.

myles: If there is a new proposal we can have a clean cut

proposal: remove zoomAndPan attribute and expectation for zoom and pan feature.

RESOLUTION: remove zoomAndPan attribute and expectation for zoom and pan feature.

krit: 2nd part is the redefinition of the DOM features

<AmeliaBR> https://svgwg.org/svg2-draft/struct.html#__svg__SVGSVGElement__currentScale

AmeliaBR: there is a currentScale and currentRotate DOM properties on the SVGSVGelement

krit: for that we need to define in which cascade they apply?

AmeliaBR: yeah. They need to get redefined as something that is independent from the zoomAndPan attribute and how they interact with things like getCTM()

krit: Do we know in which order it applies to in combination with viewBox and transform attribute?

AmeliaBR: haven't looked into it.

krit: so there are more actions needed how the properties interact with other coordinate system manipulating attributes and functions like getCTM()
... should we open a new issue for that?

AmeliaBR: might make sense to have a new issue but we can leave it for now and I take an. action to start the edit and see how much work it is.

krit: ok, so leave the issue open and AmeliaBR gets back to the group

Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript

GitHub: https://github.com/w3c/svgwg/issues/291

AmeliaBR: This isn't really about zoom and pan but DOM enumerations.
... But one example is for zoomAndPan which is no longer relevant with the last resolution
... but the question still remains for SVGUnitTypes
... Should the interface that defines the constants should also be available as class that can be referenced. This would be consistent with other SVG DOM definitions.

myles: for implementations that do not implement zoomAndPan.. do they implement the DOM representation?

AmeliaBR: yes, they implement the DOM but not the functionality.

myles: how much JS is there that uses the APIs and what happens if we remove these properties

<AmeliaBR> https://chromestatus.com/metrics/feature/timeline/popularity/1102

AmeliaBR: 2 questions: Can we safely remove the properties and how much harm would it take.
... there are use counters

myles: if we remove it those would turn to exceptions and the world breaks down

AmeliaBR: if the usage of the IDL property comes form enumerating on an element, there is no risk of deleting it
... no idea why anyone would access the value of the attribute in any meaningful way since it has no functionality

myles: in other groups one UA is volunteering to go first. WebKit would likely not do it on this one. Can we ask Erik

Eric?

<myles> Willingers

krit: Try to involve him in the discussion. He is still around on github

AmeliaBR: I will followup with him.
... back to this issue

krit: anything else than SVGUnitTypes and zoomAndPan?

AmeliaBR: I think SVGUnitTypes might be the only other one where the interface is not accessible (NoInterface object)

<AmeliaBR> https://www.w3.org/TR/2016/CR-SVG2-20160915/types.html#InterfaceSVGUnitTypes

AmeliaBR: this is userSpaceOnUse vs objetBoundingBox
... currently the constants are the same across all of these... as defined in the spec, SVGUnitTypes isn't exposed. In Blink it is exposed.
... have to check what all the other browsers do
... SVGUnitTypes.<constant> so it is its own interface.
... we should make the browsers match.

krit: do we know if it is in other browsers as well?

AmeliaBR: I know it is in Firefox, not sure about WebKit

<myles> interface SVGUnitTypes

AmeliaBR: so we get consistent browser behavior
... it is also not implemented as a mixin

proposal: Change SVGUnit

<myles> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/SVGUnitTypes.idl

proposal: Change SVGUnitTypes interface from NoInterface to an actual interface to match UA implementation behavior

RESOLUTION: Change SVGUnitTypes interface from NoInterface to an actual interface to match UA implementation behavior

<myles> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/SVGZoomAndPan.idl

<myles> NoInterfaceObject

krit: so constant are not accessible for ZoomAndPan
... lets get back to SVGZoomAndPan after AmeliaBR talked to Eric

<AmeliaBR> github-got, end topic

[svg-native] Which CSS concepts should be supported in presentation attributes?

<AmeliaBR> github-bot, end topic

GitHub: https://github.com/w3c/svgwg/issues/681

myles: there are a couple of things we can discuss and resolve on but some should get more implementer feedback
... 2 issues: which graphical elements we use and which CSS concepts we support for presentation attributes
... we should talk about relative units.

krit: relative units that are relative to font metrics and percentage values

myles: lets discuss them in isolation
... myles relatives units make no sense in SVG like the font metrics depending units. then there are viewport relative units. the viewport is a little bit confusing in fonts.
... I am also not sure if it is valuable for authoring tools.
... as far as I understand the author would create a graphic that is relative to an artboard.
... I am not sure if the relative length to the viewport dimension is relavant for authoring tools.

AmeliaBR: for SVG fonts, the viewport would be the em square of the font glyph
... It is not well defined and we do not have good support in browsers
... ... in all SVG viewers
... for the default dimensions on the outer SVG element, the width and height attribute set the default dimensions. In that case it would be great if the context would say that the dimension is 1em x 1em and then it wouldn't be necessary to have relative units within the SVG element. But even then it is not essential. You could still set the image dimension on the element in the outer document that is embedding the SVG file
... (1em instead of 60px as default sizing)

krit: you would not object to myles proposal in general still?

AmeliaBR: just saying that this is the one use case.
... especially when viewBox is required, there is no need of relative units inside

myles: no need to make it required.
... If the author wants to use relative dimensions then the author could simply specify a viewBox

proposal: SVG Native will not support relative units that are relative to either font metrics or the viewport.

RESOLUTION: SVG Native will not support relative units that are relative to either font metrics or the viewport.

krit: lets go on to percentage values

myles: percentages are mostly the same arguments.
... I am only familiar with authoring tools that create images as standalone items
... having elements move around as the containing document stretches doesn't sound useful.

AmeliaBR: benefit is for hand editing
... allows hand editing w/o repeating yourself even within a viewBox
... when you don't have a viewbox and want things to be flexible in how they stretch
... 2nd use case would be eleminated if we require viewBox
... it is a matter what are the priorities: Is SVG Native an export format only? Then we don't need percentage.

myles: one of the stated assumption is that they are not prioritising hand editing
... I still don't think viewBox should be a requirement if we see it as a scaling image as long as the implementation has access to the dimension.

<myles> https://docs.microsoft.com/en-us/windows/win32/api/d2d1_3/nf-d2d1_3-id2d1devicecontext5-createsvgdocument

myles: The implementation could know what the viewBox could be based on the extra attribute. So viewBox doesn't need to come from the inside as long as the implementation knows what it is going to be.

AmeliaBR: that may limit the optimisations you could do.

myles: We can state that implementations act as if a viewBox was defined but it doesn't actually need to be in the SVG file.

AmeliaBR: if we put it on the implementation, what is the constrains on the document?
... if not viewBox, then width and height could be good enough. And when not defined there is a fallback size.
... in all browsers with html elements you don't need a viewBox if you have a width and height on the SVG file.
... if you have a 50%/100% relative width/height then it scales to a predefined preset

myles: most font implementations don't need this information since it is specified somewhere else within the font

AmeliaBR: with the aggement that SVG Native is not expected to be a hand edited document we can decide against percentage and discuss viewBox later.

RESOLUTION: SVG Native does not support percentage length values.

end

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

01 Jul 2019

Attendees

Contents

Decide what to do with zoom and pan

Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript

[svg-native] Which CSS concepts should be supported in presentation attributes?

end

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output