<chris> I heard krit but not myles
<scribe> scribeNick: krit
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
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
<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: 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.
trackbot, end telcon
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/zoomon/zooming/ Succeeded: s/to/too/ Succeeded: s/AmeliaBR: ok/krit: ok/ Succeeded: s/SVGUniteTypes/SVGUnitTypes/ Succeeded: s/topic: [svg-native] Which CSS concepts should be supported in presentation attributes?// Succeeded: s/it would be useful/it wouldn't be necessary/ Succeeded: s/view/viewBox/ Succeeded: s/ on the outer SVG element/ on the element in the outer document that is embedding the SVG file/ Default Present: AmeliaBR, krit, stakagi, chris, myles Present: AmeliaBR krit stakagi chris myles Found ScribeNick: krit Inferring Scribes: krit Found Date: 01 Jul 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]