- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 12 Jun 2015 03:06:57 +1000
- To: www-svg@w3.org
http://www.w3.org/2015/06/11-svg-minutes.html
[1]W3C
[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
Attendees
Present
Rossen, Jun, Satoru, Tav, Erik, Dirk, Frederick,
Cameron, Nikos, Bogdan
Regrets
Chair
Cameron
Scribe
nikos, Cameron
Contents
* [3]Topics
1. [4]defer in preserveAspectRatio
2. [5]SVGSVGlement.currentView and
SVGSVGElement.useCurrentView
3. [6]SVGLength/SVGAngle constructors
4. [7]Should the SVGAnimatedPathData interface be a
[NoInterfaceObject]
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
[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
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
[18]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
[19]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
[20]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> [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
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>
[22]http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-wid
th
[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
[23]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>
[24]https://github.com/w3c/web-platform-tests/tree/master/svg
[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
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
[25]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> <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
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>
[26]http://dev.w3.org/csswg/css-logical-props/#logical-dimensio
n-properties
[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
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> 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
[27]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>
[28]https://svgwg.org/svg2-draft/coords.html#ObjectBoundingBoxU
nits
[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:
file:///Users/dschulze/Documents/svgwg/build/publish/coords.htm
l#IntrinsicSizing ?
<krit> oops
<krit>
[30]https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing
[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/1POUiroOBbLmXYlQKf0p
IR8zVkHWH9jRVN-w8A4aNsIk/edit#slide=id.g1e19b0d66_2126
[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
[32]http://www.w3.org/2015/06/11-svg-minutes.html#action05]
[NEW] ACTION: Cameron to remove currentView, useCurrentView and
SVGViewSpec [recorded in
[33]http://www.w3.org/2015/06/11-svg-minutes.html#action01]
[NEW] ACTION: Erik to make SVGAnimatedPathData a
[NoInterfaceObject] [recorded in
[34]http://www.w3.org/2015/06/11-svg-minutes.html#action03]
[NEW] ACTION: Erik to remove constructors from SVG data type
interfaces and note deprecation of create methods [recorded in
[35]http://www.w3.org/2015/06/11-svg-minutes.html#action02]
[NEW] ACTION: Rossen to update "lacuna value" to "initial
value" [recorded in
[36]http://www.w3.org/2015/06/11-svg-minutes.html#action06]
[NEW] ACTION: Rossen to update spec to say what auto means for
each element that uses it [recorded in
[37]http://www.w3.org/2015/06/11-svg-minutes.html#action04]
[End of minutes]
__________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 11 June 2015 17:07:28 UTC