W3C home > Mailing lists > Public > www-svg@w3.org > June 2015

minutes, Linköping 2015 SVG F2F Day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 12 Jun 2015 03:06:57 +1000
To: www-svg@w3.org
Message-ID: <20150611170657.GA17609@wok.mcc.id.au>


      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

11 Jun 2015

   See also: [2]IRC log

      [2] http://www.w3.org/2015/06/11-svg-irc


          Rossen, Jun, Satoru, Tav, Erik, Dirk, Frederick,
          Cameron, Nikos, Bogdan


          nikos, Cameron


     * [3]Topics
         1. [4]defer in preserveAspectRatio
         2. [5]SVGSVGlement.currentView and
         3. [6]SVGLength/SVGAngle constructors
         4. [7]Should the SVGAnimatedPathData interface be a
         5. [8]What should image { width:auto } result in?
         6. [9]Testing
         7. [10]animVal and baseVal
         8. [11]Logical block-size and inline-size properties and
            svg/rect width/height
         9. [12]Changing <text> attribute 'extent' to 'measure'
        10. [13]lacuna values
     * [14]Summary of Action Items

   <trackbot> Date: 11 June 2015

   <nikos> scribe: nikos

   <scribe> scribenick: nikos

defer in preserveAspectRatio

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

     [15] 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


     [16] 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> [17]http://mcc.id.au/temp/viewspec.html

     [17] 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
   ... 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

   <trackbot> Created ACTION-3800 - Remove currentview,
   usecurrentview and svgviewspec [on Cameron McCormack - due

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

   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

   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

   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

   <scribe> ACTION: Erik to remove constructors from SVG data type
   interfaces and note deprecation of create methods [recorded in

   <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

   <scribe> ACTION: Erik to make SVGAnimatedPathData a
   [NoInterfaceObject] [recorded in

   <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

   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
   ... 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> [21]http://mcc.id.au/temp/image.svg

     [21] 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

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

   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

   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
   ... everything else falls back to default value of one or the
   ... 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


     [22] 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

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


   [Cameron presents how to create at test]

   heycam: we'll use web platform tests repository


     [24] 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
   ... I added some html refs for rounded corners - but I'm not
   sure about that. Some browsers may not use the same shape for
   ... I also added a scripted test -
   ... 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
   ... 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

   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

   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

   <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

   <heycam> <rect style="writing-mode: vertical-tb; block-size:
   10px; inline-size: 20px"/>

   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

   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


     [26] 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

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

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


   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

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


     [28] https://svgwg.org/svg2-draft/coords.html#ObjectBoundingBoxUnits

   <Rossen> trackbot, close ACTION-3805

   <trackbot> Closed ACTION-3805.

   <ed> [29]http://www.bistrofolke.se/

     [29] http://www.bistrofolke.se/

   <krit> ed: heycam: Was it that that we discussed in Leipzig:
   l#IntrinsicSizing ?

   <krit> oops


     [30] 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

     [31] https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/edit#slide=id.g1e19b0d66_2126

   RRSAgent: make minutes

Summary of Action Items

   [NEW] ACTION: Cameron to make animVal change to all chapters
   [recorded in
   [NEW] ACTION: Cameron to remove currentView, useCurrentView and
   SVGViewSpec [recorded in
   [NEW] ACTION: Erik to make SVGAnimatedPathData a
   [NoInterfaceObject] [recorded in
   [NEW] ACTION: Erik to remove constructors from SVG data type
   interfaces and note deprecation of create methods [recorded in
   [NEW] ACTION: Rossen to update "lacuna value" to "initial
   value" [recorded in
   [NEW] ACTION: Rossen to update spec to say what auto means for
   each element that uses it [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 11 June 2015 17:07:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:01 UTC