SVG Working Group Teleconference -- 11 Jun 2015

<trackbot> Date: 11 June 2015

<nikos> scribe: nikos

<scribe> scribenick: nikos

defer in preserveAspectRatio

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

heycam: should be self explanatory
... works in FF. Not in Safari, Chrome, Opera or IE
... but test shows that Safari and Chrome do support it
... so maybe the test is wrong
... will come back later with a better test

SVGSVGlement.currentView and SVGSVGElement.useCurrentView

https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals

heycam: this property is meant to reflect the current view, if you linked with a fragment then it reflects the closest ancestor values for preserveAspectRatio, transform, etc
... if you link to a view element then it's supposed to expose attributes from the view element
... and there's a few variations on where the values come from

<heycam> http://mcc.id.au/temp/viewspec.html

heycam: FF doesn't support this at all
... expected result is for viewbox string to have all values other than zero
... if the first has zeros it may mean linking to view elements isn't supported
... sorry, the first one should reflect viewbox on root svg element
... when you don't link to anything in particular, that's what should be reflected
... expected result should be 0,0,100,100
... second one should be 25,25,100,100
... third 0,0,2,2,
... last 5,6,7,8

krit: first and third are zeros in webkit and blink

Rossen: IE doesn't support the object at all

heycam: so is this a useful thing to keep around? considering it's implemented a bit spotily and not everyone implements it
... I've never seen it used

ed: there's some implementation details that need to stay, but exposing is not strictly neccessary

heycam: so remove .currentView and .useCurrentView?

ed: if we drop them, I'm sure implementation can be simplified
... but don't know how high in priority this is

krit: it's just on SVGSVGElement

RESOLUTION: remove currentView and useCurrentView properties on SVGSVGElement and remove SVGViewSpec interface

<scribe> ACTION: Cameron to remove currentView, useCurrentView and SVGViewSpec [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3800 - Remove currentview, usecurrentview and svgviewspec [on Cameron McCormack - due 2015-06-18].

SVGLength/SVGAngle constructors

ed: what are we doing with the constructors in svg 2?
... think for each object we have several constructors, some take unsigned short enums, but we decided also not to add new ones for new unit types
... so I'm wondering if we should have those constructors at all

heycam: we don't implement them in FF yet

krit: nor in webkit

ed: do we want actual enums in idl, or domstring?

heycam: Amelia brings up the point that these objects aren't so useful if you can't resolve percentages with these things
... by setting what they resolve again
... is it useful to be able to create these objects?

ed: yes, right now you have to find SVGSVGElement and create all from there
... it would be useful to be able to use new

heycam: what are people creating these objects for?

ed: transforming from user space to screen space and things like that

krit: dom matrix has a constructor
... so that solves that use case

ed: question is can we drop this particular construct?

krit: I don't see value in the new constructors
... geometry spec covers this

heycam: back to what people are using these things for
... transforming points with matrices - I've done that a lot
... so having an easy way to do that would be good
... maybe geometry utils in css should be used instead
... how do you transform a point with a matrix in the geometry interface?

krit: either DomMatrix or DomPoint
... you can new a DomPoint
... SVGPoint is an alias for DomPoint

heycam: I think the SVGLength and SVGAngle are a lot less useful than the point and matrix stuff
... so I wouldn't mind if we didn't go ahead with their constructors for now
... don't want to remove the create methods

krit: I suggest deprecating them
... keep them in the spec but note that you should use the constructors - for the ones where constructors are available

heycam: do you have a view on the default constructor and the one that takes a string?

ed: don't have a strong opinion

krit: I'd prefer them removed

ed: just for those interfaces? or all that define constructors?

heycam: that would include SVGNumber, SVGTransform as well

krit: we hoped that CSSOM would go ahead with defining that, but it doesn't seem to be happening

heycam: Do you think that if we had constructors it would prompt people to use these and make it harder to switch to CSSOM later?

krit: no

heycam: Anyone else have a strong opinion?

others: no

heycam: the only use for SVGNumber is rotate on text element. SVGLength is probably the only one that provides extra functionality that you might want to create these objects for, that's unit conversions

ed: I'm leaning to keeping them

krit: I'd prefer remove - no one is likely to implement them in WebKit

heycam: since there's no strong opinion, the least work is to leave them in the spec for now

BogdanBrinza: why keep them, if we don't have a strong opinion?

heycam: thought people would use them

krit: new content doesn't rely on SVGOM usually

BogdanBrinza: so is there any value in keeping them?

heycam: in practice, it allows you to create objects without doing document.create blah blah
... I think they have marginal utility
... sounds like you'd prefer removal?

BogdanBrinza: yes

ed: I'm ok with removal

RESOLUTION: remove constructors from SVG data type interfaces
... Deprecate createSVGMatrix, createSVGRect, and createSVGPoint and recommend the Geometry constructors are used instead

<scribe> ACTION: Erik to remove constructors from SVG data type interfaces and note deprecation of create methods [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action02]

<trackbot> Created ACTION-3801 - Remove constructors from svg data type interfaces and note deprecation of create methods [on Erik Dahlström - due 2015-06-18].

Should the SVGAnimatedPathData interface be a [NoInterfaceObject]

heycam: think it shouldn't
... the only time should be when they're mixin interfaces

ed: it's kind of a mixin
... contains pathSeg accessors

heycam: then I change my mind - it should be

ed: it never was exposed on the window and this isn't new to svg 2

RESOLUTION: SVGAnimatedPathData interface should be a [NoInterfaceObject]

<scribe> ACTION: Erik to make SVGAnimatedPathData a [NoInterfaceObject] [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action03]

<trackbot> Created ACTION-3802 - Make svganimatedpathdata a [nointerfaceobject] [on Erik Dahlström - due 2015-06-18].

What should image { width:auto } result in?

ed: if you put width or height auto on image element, what should happen?

krit: that's the default if you don't specify a width or height

ed: we wanted to use the intrinsic size of the iamge

krit: but would you break content?

ed: maybe

heycam: didn't we add auto sizing behaviour to the spec? My feeling was we were going to use the keyword auto in thea ttributes for that, which conflicts with auto in the property

krit: are you suggesting auto default to zero?
... if you don't specify width or height it shouldn't render, so auto should default to zero

heycam: if we did plan auto to mean intrinsic size we couldn't do that

ed: we had resolution that size should be taken from the image
... I think risk it and see if we get feedback

krit: add a note asking for implementor feedback

BogdanBrinza: makes sense for auto to take intrinsic size as in HTML

heycam: there are rules when an image has no intrinsic size
... there's a risk of content relying on no width or height disabling rendering

BogdanBrinza: I haven't seen that done
... as a common technique

krit: do we also support max width and height?

BogdanBrinza: pretty common to specify that with no width or height - at least in HTML

heycam: is that for doing something like - I want image to be at least 200px wide but dont' want it to go wider than the viewport width?

BogdanBrinza: yes

heycam: I'm leaning to trying the change then
... change no width or height on image to use intrinsic size of the image

ed: the spec currently suggests that

Rossen: we just spent some time re-implementing our intrinsic widths
... I remember the last discussion we had in Seattle in 2013, we agreed that we are going to follow IEs behaviour for a lot of these cases
... then a following discussion in Leipzig

krit: don't think this has anything to do with that - we're talking about the SVG image element

ed: this came from a bug report in chrome
... someone thought that a css rule that set auto shouldn't apply - but it does in Blink
... they were asking if they should pick the attribute value

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

ed: but now there's presentation attributes for the properties it's clear

krit: we currently have the issue in illustrator/photoshop - what setting should we use for copy/paste the code into html
... e.g. style classes may overwrite each other
... same for presentation attributes
... so safest thing would be to use the style attribute to set these values
... but still doesn't protect against !important

heycam: so original question - the result is that we just need to explain how width auto works

ed: yes, and think there should be a note saying we've changed from SVG 1.1 which was zero default

krit: same for rectangle - should default to 0,0

heycam: so you want to point out that auto is intial value and how it relates to shapes and things with intrinsic size

Rossen: what about foreignObject?

heycam: interesting one - you could get dimensions out of the object

krit: foreignObject should be like iframe

Rossen: and video

heycam: if we keep it in svg namespace
... do we think it's safe to change foreignObjects lack of width/height behaviour?
... to shrinkwrap or whatever?

Rossen: I wouldn't do that - I'd default to 300x150

heycam: wouldn't shrink wrapping be more useful?

bogdan: it's unpredictable

heycam: I think of FO as like a div

Rossen: no, think of it as an iframe
... there's a reason we don't have shrink to fit on iframes

ed: I'd say making it the size of the svg is more useful

heycam: you're not always going to have it at (0,0)

ed: 300x150 is a bit arbitrary and not that useful either

Rossen: but it's familiar to HTML users
... and it's predictable

ed: but svg usually have viewboxes and 300x150 may not mean the same thing

heycam: same with image though
... this is for inline content though - foreignObject with some child html things
... I don't see it the same as an iframe
... iframe is a contained thing
... a completely separate document
... i you implement foreignObject with href on it, it's like an iframe
... but if you have inline contents it's much more like a div

Rossen: if I have a fixed position element in a foriegnObject - where would it be positioned?

heycam: talked about this in London - answer was to make a foreignObject initial containing block

krit: which would affect viewport units
... did you test and did it work in all browsers?

Rossen: not in Blink - it's very buggy

krit: inline svg has same content units as parent. But foreignObject changes this

heycam: if you have inner svg and you use vw and vh, what does it get resolved against?

Rossen: the foreignObject

heycam: I wonder if people would be surprised if vw and vh resolve against something different in a foreignObject?

Rossen: I don't think so
... otherwise you're taking dependency on something way up the ancestor chain
... and you have to go and invalidate things that may be hidden inside some foreignObject - it's a broken model
... I think 300x150 is the most consistent and easy to explain
... people are not going to like it, but it's very easy to fix

krit: removes a lot of complexity regarding size negotiations

heycam: would there be any way to opt in to a shrink wrap type thing?

Rossen: we had an internal object that was like an iframe but did shrink to fit. It's an unstable model so we moved away from it.

heycam: ok. Guess there's other ways to get that behaviour if you want it
... so 300x150 for foreignObject, video, iframe

krit: what is the css viewport for the foreignObject? The containing block defined by the foreignObject?

Rossen: yes

heycam: what happens if you have auto as one width or height and non auto for the other?
... resolve against the aspect ratio?

Rossen: only thing with intrinsic ratio that we respect are images
... everything else falls back to default value of one or the other
... if one or the other is not specified it just uses the default - 300 for width, 150 for height

RESOLUTION: for width and height on foreignObject, video, and iframe - auto means 300x150

ed: do we want to special case svg images?

heycam: no
... we want to behave just like html image

Rossen: what happens for SVG as an image?

heycam: if you don't have intrinsic info then you get 300x150

Rossen: you might want to check on that
... we spent some time on this recently - had a giant table of all the permutations

krit: but that's a requirement for the integration spec
... don't see any special behaviour for svg

heycam: those issues apply to HTML referencing SVG as well
... presumably there's a term in a CSS spec that defines the algorithm for intrinsic size/ratio, etc

Rossen: Probably in css 21 Section 10.3

ed: so the svg image element is not laid out by CSS so therefore we need to make sure it's handled the same way as if it was an image element in CSS

element in CSS/element in HTML

<Rossen> http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width

RESOLUTION: SVG image elements with no width or height is sized just like HTMLs image element

<scribe> ACTION: Rossen to update spec to say what auto means for each element that uses it [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action04]

<trackbot> Created ACTION-3803 - Update spec to say what auto means for each element that uses it [on Rossen Atanassov - due 2015-06-18].

Testing

[Cameron presents how to create at test]

heycam: we'll use web platform tests repository

<heycam> https://github.com/w3c/web-platform-tests/tree/master/svg

heycam: I added all svg 1.1 test files to the repo
... they're in the import directory
... I'd like us to convert these to the webplatform expected format - it's probably easier than writing new tests
... that would be ref tests
... so ideally chapter owners would work on the tests from their chapter
... I've done a couple and I've got some PRs for those that haven't been merged yet

[shows old format vs new format]

scribe: these old ones are manual tests
... I turned this one test into many smaller tests - thought it would be preferable
... metadata is just like CSS repo metadata
... here I've compared an SVG rect against a CSS rect

Rossen: not sure about that approach
... theoretically if there's no match, you don't know if it's because HTML or SVG is wrong

krit: ref tests make the assumption that your reference is always working

Rossen: in CSS we depend on images for such basic features

heycam: there's no harness to run tests automatically

Tavmjong: this relies on HTML - what do I do?

heycam: if I change reference to a png, that would solve that problem
... I added some html refs for rounded corners - but I'm not sure about that. Some browsers may not use the same shape for both
... I also added a scripted test - SVGElement.ownerSVGElement-01.html
... use the testharness.js framework
... that framework has a test() function that you pass your testing function to
... inside that you have lots of asserts
... one issue is that testharness.js doesn't work if the outer document is an svg document
... this is only for scripted tests so hopefully doesn't preclude any user agents

Tavmjong: would be nice to separate the types of tests so I can easily skip script tests?

Rossen: would like to separate by chapter, then within that by refs and dynamic tests

heycam: how do you distinguish between which are scripted and which are ref tests?

Rossen: that's why we have two different folders

heycam: so how about we do that at the top level?

Rossen: think putting them inside is better - you might have some that have only ref tests and not scripted tests
... we should be vigorous in establishing the right patterns from the start
... enforce naming and structure

heycam: how about e.g. shapes/reftests/rect-blah-01.html for ref tests
... and types/scripted/SVGElement.ownerSVGElement-01.html for script tests
... I'll write up an initial style guide and put it in the repository
... think it's a good idea to have chapter owners in charge of the tests for that chapter
... we're going to find a lot of deficiencies in our chapters as we write tests

Tav: reference pngs should be the same width and height as the svg image to make visual comparison easy

heycam: we need to take care when converting to ensure that tests are still relevant and correct for SVG 2
... think only for fundamental tests like rectangle and path should we use png references
... then once we've established the fundamental functionality, tests should be svg vs svg

ed: there's rel="match", is there a no match?

heycam: documentation for that is all on testthewebforward.org

ed: other question, is it possible to have two reference images and both must match?

heycam: apparently rel="match" means match against one thing, so if you want to test against more than one thing you need to duplicate the test
... what about for text? I feel that could use html for the references

you could use ahemfont

heycam: the procedure for submitting tests is to fork repository, make branch with changes, make a pull request and somebody will comment or merge. There's information about that procedure on testthewebforward.org

animVal and baseVal

heycam: think Brian felt there should be ways of getting values for things that aren't going to be CSS properties
... but I don't want to make some API that is going to duplicate what web animations will cover

RESOLUTION: animVal will alias baseVal

krit: then animVal would not be read only anymore

heycam: I take it to mean it's the very same object
... don't think it would be too hard to make one of them read only

krit: we need to change every chapter - it's spread out over the whole spec

<scribe> ACTION: Cameron to make animVal change to all chapters [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action05]

<trackbot> Created ACTION-3804 - Make animval change to all chapters [on Cameron McCormack - due 2015-06-18].

Logical block-size and inline-size properties and svg/rect width/height

heycam: if you do that - you get a rectangle that is 10px wide and 20px high
... because of the way logical properties are a way of setting the actual properties
... it's a bit weird, but it's a result of having them as properties

krit: is rectangle even a block?

heycam: doesn't matter
... it's what you'd expect, but maybe a bit funny

Changing <text> attribute 'extent' to 'measure'

TabAtkins: Tab pointed out that extent and measure were once upon a time defined in CSS
... they're no longer being used, but we were using extent where the proper print term is measure
... shall we switch to measure?

Rossen: how about inline and block?

heycam: what happens if you specify inline and block size?
... answer is you don't do anything with the block size

<Rossen> http://dev.w3.org/csswg/css-logical-props/#logical-dimension-properties

heycam: we decided not to introduce any new presentation attributes for new properties that we invent or new css properties that we apply to svg content
... this would be one of those cases
... so you'd need to do style=

krit: we don't need to be so strict
... for certain things we could have presentation attributes

heycam: I'd like to define the rules of when we do, which would be tricky

Tav: this is a geometry thing, which could make sense for a presentation attribute
... where as something like font-variant is completely a style thing

heycam: depends how you look at it - x,y,width and height are presentation attributes so inline-size could be
... but they're only presentation attributes because they used to be properties

Rossen: for this particular one I feel favourable to making an exception
... this is perhaps the first and maybe only case where SVG comes really close to CSS in terms of layout
... of text
... it's pretty much CSS
... and making those closely bound by terminology and everything that is being specified will make it easier to bridge those two things
... just for the naming
... since these attributes already exist, I think this could be considered a rename

heycam: width and height already exist you're saying, so the logical equivalents should also exist as presentation attributes?

Rossen: use cases where people use SVG as the bullet image for list items (say an arrow), when writing mode changes the direction of the arrow usually changes as well
... style is a nice way to modify that
... using a logical property

heycam: there's no way to inherit writing-mode and direction from the outer document to your image document though yet
... your general point of writing-mode agnostic graphics is a reasonable use case though
... I'm happy having a presentation attribute then

RESOLUTION: Rename text attribute 'extent' to inline-size and it's a presentation attribute for that logical property

<heycam> RRSAgent: make minutes

<heycam> RRSAgent: make logs public

<heycam> RRSAgent: make minutes

<heycam> ScribeNick: heycam

<scribe> Scribe: Cameron

lacuna values

Rossen: I don't know the history behind the term, but anyone I speak to is confused about the term
... if we can agree on a more standard name
... so I know that there was a problem with using the term default
... but initial would make sense
... so I propose that we call these initial values

ed: would initial potentially be confusing, especially if we promote properties later?

heycam: I am fine with initial

ed:

s/met oo//

ed: me too

RESOLUTION: Replace "lacuna value" with "initial value"

<scribe> ACTION: Rossen to update "lacuna value" to "initial value" [recorded in http://www.w3.org/2015/06/11-svg-minutes.html#action06]

<trackbot> Created ACTION-3805 - Update "lacuna value" to "initial value" [on Rossen Atanassov - due 2015-06-18].

<krit> https://svgwg.org/svg2-draft/coords.html#ObjectBoundingBoxUnits

<Rossen> trackbot, close ACTION-3805

<trackbot> Closed ACTION-3805.

<ed> http://www.bistrofolke.se/

<krit> ed: heycam: Was it that that we discussed in Leipzig: file:///Users/dschulze/Documents/svgwg/build/publish/coords.html#IntrinsicSizing ?

<krit> oops

<krit> https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing

<ed> krit: I remember that we discussed the sizing things in Leipzig, but don't quite recall all the aspects

<krit> ed: no, not talking about details

<krit> ed: did we discuss SVG as image or the embed case?

<ed> krit: I think we mostly discussed the inline svg case, but that it mapped well to the other cases

<ed> see https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/edit#slide=id.g1e19b0d66_2126

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

11 Jun 2015

Attendees

Contents