IRC log of svg on 2015-06-11

Timestamps are in UTC.

09:22:15 [RRSAgent]
RRSAgent has joined #svg
09:22:15 [RRSAgent]
logging to
09:22:17 [trackbot]
RRSAgent, make logs public
09:22:17 [Zakim]
Zakim has joined #svg
09:22:18 [heycam]
Chair: Cameron
09:22:19 [trackbot]
Zakim, this will be GA_SVGWG
09:22:19 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
09:22:20 [trackbot]
Meeting: SVG Working Group Teleconference
09:22:21 [trackbot]
Date: 11 June 2015
09:22:40 [nikos]
scribe: nikos
09:22:43 [nikos]
scribenick: nikos
09:23:00 [nikos]
Topic: defer in preserveAspectRatio
09:23:01 [BogdanBrinza]
BogdanBrinza has joined #svg
09:23:01 [heycam]
09:23:12 [nikos]
heycam: should be self explanatory
09:23:34 [jun]
jun has joined #svg
09:23:46 [nikos]
heycam: works in FF. Not in Safari, Chrome, Opera or IE
09:24:46 [nikos]
... but test shows that Safari and Chrome do support it
09:24:52 [nikos]
... so maybe the test is wrong
09:25:02 [nikos]
... will come back later with a better test
09:26:31 [nikos]
Topic: SVGSVGlement.currentView and SVGSVGElement.useCurrentView
09:26:38 [nikos]
09:27:24 [nikos]
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
09:28:01 [nikos]
heycam: if you link to a view element then it's supposed to expose attributes from the view element
09:28:17 [nikos]
... and there's a few variations on where the values come from
09:28:42 [heycam]
09:29:03 [nikos]
heycam: FF doesn't support this at all
09:29:40 [nikos]
heycam: expected result is for viewbox string to have all values other than zero
09:29:54 [nikos]
... if the first has zeros it may mean linking to view elements isn't supported
09:30:16 [nikos]
... sorry, the first one should reflect viewbox on root svg element
09:30:25 [nikos]
... when you don't link to anything in particular, that's what should be reflected
09:30:44 [nikos]
... expected result should be 0,0,100,100
09:30:51 [nikos]
... second one should be 25,25,100,100
09:31:01 [nikos]
... third 0,0,2,2,
09:31:11 [nikos]
... last 5,6,7,8
09:31:35 [nikos]
krit: first and third are zeros in webkit and blink
09:31:47 [nikos]
Rossen: IE doesn't support the object at all
09:32:09 [nikos]
heycam: so is this a useful thing to keep around? considering it's implemented a bit spotily and not everyone implements it
09:32:13 [nikos]
... I've never seen it used
09:32:35 [nikos]
ed: there's some implementation details that need to stay, but exposing is not strictly neccessary
09:32:52 [nikos]
heycam: so remove .currentView and .useCurrentView?
09:33:29 [nikos]
ed: if we drop them, I'm sure implementation can be simplified
09:33:36 [nikos]
... but don't know how high in priority this is
09:34:04 [nikos]
krit: it's just on SVGSVGElement
09:34:30 [nikos]
RESOLUTION: remove currentView and useCurrentView properties on SVGSVGElement and remove SVGViewSpec interface
09:35:22 [nikos]
ACTION: Cameron to remove currentView, useCurrentView and SVGViewSpec
09:35:22 [trackbot]
Created ACTION-3800 - Remove currentview, usecurrentview and svgviewspec [on Cameron McCormack - due 2015-06-18].
09:35:53 [nikos]
Topic: SVGLength/SVGAngle constructors
09:36:01 [nikos]
ed: what are we doing with the constructors in svg 2?
09:36:18 [nikos]
... 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
09:36:25 [nikos]
... so I'm wondering if we should have those constructors at all
09:36:37 [nikos]
heycam: we don't implement them in FF yet
09:36:40 [nikos]
krit: nor in webkit
09:36:51 [nikos]
ed: do we want actual enums in idl, or domstring?
09:37:20 [nikos]
heycam: Amelia brings up the point that these objects aren't so useful if you can't resolve percentages with these things
09:37:24 [nikos]
... by setting what they resolve again
09:37:31 [nikos]
... is it useful to be able to create these objects?
09:37:44 [nikos]
ed: yes, right now you have to find SVGSVGElement and create all from there
09:37:52 [nikos]
... it would be useful to be able to use new
09:37:57 [nikos]
heycam: what are people creating these objects for?
09:38:07 [nikos]
ed: transforming from user space to screen space and things like that
09:38:12 [nikos]
krit: dom matrix has a constructor
09:38:17 [nikos]
... so that solves that use case
09:38:37 [nikos]
ed: question is can we drop this particular construct?
09:38:45 [nikos]
krit: I don't see value in the new constructors
09:39:04 [nikos]
... geometry spec covers this
09:39:16 [nikos]
heycam: back to what people are using these things for
09:39:22 [nikos]
... transforming points with matrices - I've done that a lot
09:39:28 [nikos]
... so having an easy way to do that would be good
09:39:35 [nikos]
... maybe geometry utils in css should be used instead
09:39:59 [nikos]
heycam: how do you transform a point with a matrix in the geometry interface?
09:40:07 [nikos]
krit: either DomMatrix or DomPoint
09:40:19 [nikos]
... you can new a DomPoint
09:40:29 [nikos]
... SVGPoint is an alias for DomPoint
09:40:48 [nikos]
heycam: I think the SVGLength and SVGAngle are a lot less useful than the point and matrix stuff
09:40:56 [nikos]
... so I wouldn't mind if we didn't go ahead with their constructors for now
09:41:03 [nikos]
... don't want to remove the create methods
09:41:10 [nikos]
krit: I suggest deprecating them
09:41:33 [nikos]
... keep them in the spec but note that you should use the constructors - for the ones where constructors are available
09:41:51 [nikos]
heycam: do you have a view on the default constructor and the one that takes a string?
09:41:57 [nikos]
ed: don't have a strong opinion
09:42:05 [nikos]
krit: I'd prefer them removed
09:42:23 [nikos]
ed: just for those interfaces? or all that define constructors?
09:42:57 [nikos]
heycam: that would include SVGNumber, SVGTransform as well
09:43:11 [nikos]
krit: we hoped that CSSOM would go ahead with defining that, but it doesn't seem to be happening
09:43:40 [nikos]
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?
09:43:43 [nikos]
krit: no
09:43:55 [nikos]
heycam: Anyone else have a strong opinion?
09:44:04 [nikos]
others: no
09:45:46 [nikos]
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
09:45:50 [nikos]
ed: I'm leaning to keeping them
09:46:40 [nikos]
krit: I'd prefer remove - no one is likely to implement them in WebKit
09:47:07 [nikos]
heycam: since there's no strong opinion, the least work is to leave them in the spec for now
09:47:29 [nikos]
BogdanBrinza: why keep them, if we don't have a strong opinion?
09:47:40 [nikos]
heycam: thought people would use them
09:47:49 [nikos]
krit: new content doesn't rely on SVGOM usually
09:47:58 [nikos]
BogdanBrinza: so is there any value in keeping them?
09:48:10 [nikos]
heycam: in practice, it allows you to create objects without doing document.create blah blah
09:48:38 [nikos]
heycam: I think they have marginal utility
09:48:45 [nikos]
heycam: sounds like you'd prefer removal?
09:48:47 [nikos]
BogdanBrinza: yes
09:48:50 [nikos]
ed: I'm ok with removal
09:49:03 [nikos]
RESOLUTION: remove constructors from SVG data type interfaces
09:49:35 [nikos]
RESOLUTION: Deprecate createSVGMatrix, createSVGRect, and createSVGPoint and recommend the Geometry constructors are used instead
09:49:58 [nikos]
ACTION: Erik to remove constructors from SVG data type interfaces and note deprecation of create methods
09:49:58 [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].
09:50:17 [nikos]
Topic: Should the SVGAnimatedPathData interface be a [NoInterfaceObject]
09:50:24 [nikos]
heycam: think it shouldn't
09:50:31 [nikos]
... the only time should be when they're mixin interfaces
09:50:34 [nikos]
ed: it's kind of a mixin
09:50:40 [nikos]
... contains pathSeg accessors
09:51:05 [nikos]
heycam: then I change my mind - it should be
09:51:17 [nikos]
ed: it never was exposed on the window and this isn't new to svg 2
09:51:37 [nikos]
RESOLUTION: SVGAnimatedPathData interface should be a [NoInterfaceObject]
09:51:44 [nikos]
ACTION: Erik to make SVGAnimatedPathData a [NoInterfaceObject]
09:51:45 [trackbot]
Created ACTION-3802 - Make svganimatedpathdata a [nointerfaceobject] [on Erik Dahlström - due 2015-06-18].
09:52:05 [nikos]
Topic: What should image { width:auto } result in?
09:52:20 [nikos]
ed: if you put width or height auto on image element, what should happen?
09:52:26 [nikos]
krit: that's the default if you don't specify a width or height
09:52:31 [nikos]
ed: we wanted to use the intrinsic size of the iamge
09:52:35 [nikos]
krit: but would you break content?
09:52:37 [nikos]
ed: maybe
09:53:01 [nikos]
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
09:53:13 [nikos]
krit: are you suggesting auto default to zero?
09:53:26 [nikos]
... if you don't specify width or height it shouldn't render, so auto should default to zero
09:53:37 [nikos]
heycam: if we did plan auto to mean intrinsic size we couldn't do that
09:54:00 [nikos]
ed: we had resolution that size should be taken from the image
09:54:10 [nikos]
ed: I think risk it and see if we get feedback
09:54:17 [nikos]
krit: add a note asking for implementor feedback
09:54:50 [nikos]
BogdanBrinza: makes sense for auto to take intrinsic size as in HTML
09:55:03 [nikos]
heycam: there are rules when an image has no intrinsic size
09:55:21 [nikos]
... there's a risk of content relying on no width or height disabling rendering
09:55:41 [nikos]
BogdanBrinza: I haven't seen that done
09:55:47 [nikos]
... as a common technique
09:55:57 [nikos]
krit: do we also support max width and height?
09:56:09 [nikos]
BogdanBrinza: pretty common to specify that with no width or height - at least in HTML
09:56:27 [nikos]
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?
09:56:31 [nikos]
BogdanBrinza: yes
09:56:37 [nikos]
heycam: I'm leaning to trying the change then
09:56:47 [nikos]
... change no width or height on image to use intrinsic size of the image
09:57:13 [nikos]
ed: the spec currently suggests that
09:57:39 [nikos]
Rossen: we just spent some time re-implementing our intrinsic widths
09:58:07 [nikos]
... 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
09:58:16 [nikos]
... then a following discussion in Leipzig
09:58:28 [nikos]
krit: don't think this has anything to do with that - we're talking about the SVG image element
10:00:31 [nikos]
ed: this came from a bug report in chrome
10:00:44 [nikos]
... someone thought that a css rule that set auto shouldn't apply - but it does in Blink
10:01:05 [nikos]
... they were asking if they should pick the attribute value
10:01:16 [heycam]
10:01:17 [nikos]
... but now there's presentation attributes for the properties it's clear
10:01:41 [nikos]
krit: we currently have the issue in illustrator/photoshop - what setting should we use for copy/paste the code into html
10:01:49 [nikos]
... e.g. style classes may overwrite each other
10:01:54 [nikos]
... same for presentation attributes
10:02:06 [nikos]
... so safest thing would be to use the style attribute to set these values
10:02:15 [nikos]
... but still doesn't protect against !important
10:02:30 [nikos]
heycam: so original question - the result is that we just need to explain how width auto works
10:02:49 [nikos]
ed: yes, and think there should be a note saying we've changed from SVG 1.1 which was zero default
10:03:04 [nikos]
krit: same for rectangle - should default to 0,0
10:03:25 [nikos]
heycam: so you want to point out that auto is intial value and how it relates to shapes and things with intrinsic size
10:03:40 [nikos]
Rossen: what about foreignObject?
10:03:52 [nikos]
heycam: interesting one - you could get dimensions out of the object
10:03:59 [nikos]
krit: foreignObject should be like iframe
10:04:03 [nikos]
Rossen: and video
10:04:08 [nikos]
heycam: if we keep it in svg namespace
10:04:35 [nikos]
heycam: do we think it's safe to change foreignObjects lack of width/height behaviour?
10:04:41 [nikos]
... to shrinkwrap or whatever?
10:04:49 [nikos]
Rossen: I wouldn't do that - I'd default to 300x150
10:05:02 [nikos]
heycam: wouldn't shrink wrapping be more useful?
10:05:10 [nikos]
bogdan: it's unpredictable
10:05:27 [nikos]
heycam: I think of FO as like a div
10:05:32 [nikos]
Rossen: no, think of it as an iframe
10:05:45 [nikos]
... there's a reason we don't have shrink to fit on iframes
10:05:56 [nikos]
ed: I'd say making it the size of the svg is more useful
10:06:10 [nikos]
heycam: you're not always going to have it at (0,0)
10:06:36 [nikos]
ed: 300x150 is a bit arbitrary and not that useful either
10:06:42 [nikos]
Rossen: but it's familiar to HTML users
10:06:48 [nikos]
... and it's predictable
10:07:10 [nikos]
ed: but svg usually have viewboxes and 300x150 may not mean the same thing
10:07:15 [nikos]
heycam: same with image though
10:07:36 [nikos]
heycam: this is for inline content though - foreignObject with some child html things
10:07:41 [nikos]
... I don't see it the same as an iframe
10:07:46 [nikos]
... iframe is a contained thing
10:07:50 [nikos]
... a completely separate document
10:08:00 [nikos]
... i you implement foreignObject with href on it, it's like an iframe
10:08:07 [nikos]
... but if you have inline contents it's much more like a div
10:08:33 [nikos]
Rossen: if I have a fixed position element in a foriegnObject - where would it be positioned?
10:08:58 [nikos]
heycam: talked about this in London - answer was to make a foreignObject initial containing block
10:09:03 [nikos]
krit: which would affect viewport units
10:09:10 [nikos]
... did you test and did it work in all browsers?
10:09:26 [nikos]
Rossen: not in Blink - it's very buggy
10:10:43 [nikos]
krit: inline svg has same content units as parent. But foreignObject changes this
10:10:57 [nikos]
heycam: if you have inner svg and you use vw and vh, what does it get resolved against?
10:11:01 [nikos]
Rossen: the foreignObject
10:11:35 [nikos]
heycam: I wonder if people would be surprised if vw and vh resolve against something different in a foreignObject?
10:11:57 [nikos]
Rossen: I don't think so
10:12:09 [nikos]
... otherwise you're taking dependency on something way up the ancestor chain
10:12:48 [nikos]
... and you have to go and invalidate things that may be hidden inside some foreignObject - it's a broken model
10:13:46 [nikos]
... I think 300x150 is the most consistent and easy to explain
10:13:54 [nikos]
... people are not going to like it, but it's very easy to fix
10:14:19 [nikos]
krit: removes a lot of complexity regarding size negotiations
10:14:28 [nikos]
heycam: would there be any way to opt in to a shrink wrap type thing?
10:15:04 [nikos]
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.
10:15:32 [nikos]
heycam: ok. Guess there's other ways to get that behaviour if you want it
10:15:46 [nikos]
heycam: so 300x150 for foreignObject, video, iframe
10:16:08 [nikos]
krit: what is the css viewport for the foreignObject? The containing block defined by the foreignObject?
10:16:10 [nikos]
Rossen: yes
10:16:30 [nikos]
heycam: what happens if you have auto as one width or height and non auto for the other?
10:16:37 [nikos]
... resolve against the aspect ratio?
10:16:46 [nikos]
Rossen: only thing with intrinsic ratio that we respect are images
10:16:53 [nikos]
... everything else falls back to default value of one or the other
10:17:08 [nikos]
... if one or the other is not specified it just uses the default - 300 for width, 150 for height
10:17:27 [nikos]
RESOLUTION: for width and height on foreignObject, video, and iframe - auto means 300x150
10:17:41 [nikos]
ed: do we want to special case svg images?
10:17:43 [nikos]
heycam: no
10:18:05 [nikos]
heycam: we want to behave just like html image
10:18:23 [nikos]
Rossen: what happens for SVG as an image?
10:18:33 [nikos]
heycam: if you don't have intrinsic info then you get 300x150
10:18:37 [nikos]
Rossen: you might want to check on that
10:18:55 [nikos]
... we spent some time on this recently - had a giant table of all the permutations
10:19:11 [nikos]
krit: but that's a requirement for the integration spec
10:19:17 [nikos]
... don't see any special behaviour for svg
10:19:27 [nikos]
heycam: those issues apply to HTML referencing SVG as well
10:19:43 [nikos]
... presumably there's a term in a CSS spec that defines the algorithm for intrinsic size/ratio, etc
10:20:19 [nikos]
Rossen: Probably in css 21 Section 10.3
10:20:44 [BogdanBrinza]
BogdanBrinza has joined #svg
10:20:48 [nikos]
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
10:21:00 [nikos]
element in CSS/element in HTML
10:21:10 [Rossen]
10:21:50 [nikos]
RESOLUTION: SVG image elements with no width or height is sized just like HTMLs image element
10:27:01 [nikos]
ACTION: Rossen to update spec to say what auto means for each element that uses it
10:27:01 [trackbot]
Created ACTION-3803 - Update spec to say what auto means for each element that uses it [on Rossen Atanassov - due 2015-06-18].
10:27:14 [nikos]
Topic: Testing
10:28:25 [nikos]
[Cameron presents how to create at test]
10:29:34 [nikos]
heycam: we'll use web platform tests repostiroy
10:29:43 [heycam]
10:29:44 [nikos]
... I added all svg 1.1 test files to the repo
10:29:51 [nikos]
10:30:24 [nikos]
... they're in the import directory
10:30:47 [nikos]
... I'd like us to convert these to the webplatform expected format - it's probably easier than writing new tests
10:30:53 [nikos]
... that would be ref tests
10:31:03 [nikos]
... so ideally chapter owners would work on the tests from their chapter
10:31:16 [nikos]
... I've done a couple and I've got some PRs for those that haven't been merged yet
10:32:47 [nikos]
[shows old format vs new format]
10:32:59 [nikos]
... these old ones are manual tests
10:33:23 [nikos]
... I turned this one test into many smaller tests - thought it would be preferable
10:33:39 [nikos]
... metadata is just like CSS repo metadata
10:34:23 [nikos]
... here I've compared an SVG rect against a CSS rect
10:34:32 [nikos]
Rossen: not sure about that approach
10:34:45 [nikos]
... theoretically if there's no match, you don't know if it's because HTML or SVG is wrong
10:35:04 [nikos]
krit: ref tests make the assumption that your reference is always working
10:35:14 [nikos]
Rossen: in CSS we always use images
10:36:22 [Rossen]
s/always use images/depend on images for such basic features/
10:37:00 [nikos]
heycam: there's no harness to run tests automatically
10:37:15 [nikos]
Tavmjong: this relies on HTML - what do I do?
10:37:22 [nikos]
heycam: if I change reference to a png, that would solve that problem
10:39:34 [nikos]
heycam: 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
10:40:42 [nikos]
heycam: I also added a scripted test - SVGElement.ownerSVGElement-01.html
10:40:50 [nikos]
... use the testharness.js framework
10:41:07 [nikos]
... that framework has a test() function that you pass your testing function to
10:41:16 [nikos]
... inside that you have lots of asserts
10:41:38 [nikos]
... one issue is that testharness.js doesn't work if the outer document is an svg document
10:42:16 [nikos]
... this is only for scripted tests should hopefully doesn't preclude any user agents
10:42:32 [nikos]
s/should hopefully/so hopefully
10:43:14 [nikos]
Tavmjong: would be nice to separate the types of tests so I can easily skip script tests?
10:43:39 [nikos]
Rossen: would like to separate by chapter, then within that by refs and dynamic tests
10:43:52 [nikos]
heycam: how do you distinguish between which are scripted and which are ref tests?
10:43:58 [nikos]
Rossen: that's why we have two different folders
10:44:23 [nikos]
heycam: so how about we do that at the top level?
10:44:34 [nikos]
Rossen: think putting them inside is better - you might have some that have only ref tests and not scripted tests
10:45:02 [nikos]
... we should be vigorous in establishing the right patterns from the start
10:45:19 [nikos]
... enforce naming and structure
10:45:41 [nikos]
heycam: how about e.g. shapes/reftests/rect-blah-01.html for ref tests
10:46:06 [nikos]
... and types/scripted/SVGElement.ownerSVGElement-01.html for script tests
10:46:17 [nikos]
... I'll write up an initial style guide and put it in the repository
10:46:41 [nikos]
... think it's a good idea to have chapter owners in charge of the tests for that chapter
10:47:12 [nikos]
... we're going to find a lot of deficiencies in our chapters as we write tests
10:48:06 [tbah]
tbah has joined #svg
10:48:50 [nikos]
Tav: reference pngs should be the same width and height as the svg image to make visual comparison easy
10:49:34 [nikos]
heycam: we need to take care when converting to ensure that tests are still relevant and correct for SVG 2
10:49:53 [nikos]
... think only for fundamental tests like rectangle and path should we use png references
10:50:07 [nikos]
... then once we've established the fundamental functionality, tests should be svg vs svg
10:50:24 [nikos]
ed: there's rel="match", is there a no match?
10:50:46 [nikos]
heycam: documentation for that is all on
10:52:31 [nikos]
ed: other question, is it possible to have two reference images and both must match?
10:52:45 [nikos]
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
10:52:56 [nikos]
heycam: what about for text? I feel that could use html for the references
10:55:46 [BogdanBrinza]
BogdanBrinza has joined #svg
10:55:56 [nikos]
you could use ahemfont
10:55:58 [nikos]
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
10:58:42 [nikos]
Topic: animVal and baseVal
10:59:23 [nikos]
heycam: think Brian felt there should be ways of getting values for things that aren't going to be CSS properties
10:59:32 [nikos]
... but I don't want to make some API that is going to duplicate what web animations will cover
10:59:49 [nikos]
RESOLUTION: animVal will alias baseVal
11:00:10 [nikos]
krit: then animVal would not be read only anymore
11:00:22 [nikos]
heycam: I take it to mean it's the very same object
11:00:49 [nikos]
... don't think it would be too hard to make one of them read only
11:01:06 [nikos]
krit: we need to change every chapter - it's spread out over the whole spec
11:01:18 [nikos]
ACTION: Cameron to make animVal change to all chapters
11:01:19 [trackbot]
Created ACTION-3804 - Make animval change to all chapters [on Cameron McCormack - due 2015-06-18].
11:02:25 [nikos]
Topic: Logical block-size and inline-size properties and svg/rect width/height
11:02:45 [heycam]
<rect style="writing-mode: vertical-tb; block-size: 10px; inline-size: 20px"/>
11:02:58 [nikos]
heycam: if you do that - you get a rectangle that is 10px wide and 20px high
11:03:08 [nikos]
... because of the way logical properties are a way of setting the actual properties
11:03:15 [nikos]
... it's a bit weird, but it's a result of having them as properties
11:03:27 [nikos]
krit: is rectangle even a block?
11:03:31 [nikos]
heycam: doesn't matter
11:03:47 [nikos]
... it's what you'd expect, but maybe a bit funny
11:06:52 [nikos]
Topic: Changing <text> attribute 'extent' to 'measure'
11:07:03 [nikos]
TabAtkins: Tab pointed out that extent and measure were once upon a time defined in CSS
11:07:17 [nikos]
... they're no longer being used, but we were using extent where the proper print term is measure
11:07:30 [nikos]
... shall we switch to measure?
11:09:56 [nikos]
Rossen: how about inline and block?
11:10:41 [nikos]
heycam: what happens if you specify inline and block size?
11:10:43 [BogdanBrinza]
BogdanBrinza has joined #svg
11:10:58 [nikos]
heycam: answer is you don't do anything with the block size
11:11:17 [Rossen]
11:12:03 [nikos]
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
11:12:08 [nikos]
... this would be one of those cases
11:12:17 [nikos]
... so you'd need to do style=
11:12:23 [nikos]
krit: we don't need to be so strict
11:12:33 [nikos]
... for certain things we could have presentation attributes
11:12:50 [nikos]
heycam: I'd like to define the rules of when we do, which would be tricky
11:12:57 [stakagi]
stakagi has joined #svg
11:13:06 [nikos]
Tav: this is a geometry thing, which could make sense for a presentation attribute
11:13:15 [nikos]
... where as something like font-variant is completely a style thing
11:13:41 [nikos]
heycam: depends how you look at it - x,y,width and height are presentation attributes so inline-size could be
11:13:53 [nikos]
... but they're only presentation attributes because they used to be properties
11:14:02 [nikos]
Rossen: for this particular one I feel favourable to making an exception
11:14:16 [nikos]
... this is perhaps the first and maybe only case where SVG comes really close to CSS in terms of layout
11:14:19 [nikos]
... of text
11:14:26 [nikos]
... it's pretty much CSS
11:14:53 [nikos]
... and making those closely bound by terminology and everything that is being specified will make it easier to bridge those two things
11:15:00 [nikos]
... just for the naming
11:15:12 [nikos]
... since these attributes already exist, I think this could be considered a rename
11:15:40 [nikos]
heycam: width and height already exist you're saying, so the logical equivalents should also exist as presentation attributes?
11:16:51 [nikos]
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
11:16:59 [nikos]
... style is a nice way to modify that
11:17:07 [nikos]
... using a logical property
11:17:24 [nikos]
heycam: there's no way to inherit writing-mode and direction from the outer document to your image document though yet
11:17:39 [nikos]
... your general point of writing-mode agnostic graphics is a reasonable use case though
11:17:45 [nikos]
heycam: I'm happy having a presentation attribute then
11:18:34 [nikos]
RESOLUTION: Rename text attribute 'extent' to inline-size and it's a presentation attribute for that logical property
11:19:00 [jun]
jun has joined #svg
11:39:56 [Zakim]
Zakim has left #svg
14:52:30 [RRSAgent]
RRSAgent has joined #svg
14:52:30 [RRSAgent]
logging to
14:52:46 [heycam]
RRSAgent: make minutes
14:52:46 [RRSAgent]
I have made the request to generate heycam
14:53:16 [heycam]
RRSAgent: make logs public
14:53:23 [heycam]
RRSAgent: make minutes
14:53:23 [RRSAgent]
I have made the request to generate heycam
14:53:56 [heycam]
Present: Rossen, Jun, Satoru, Tav, Erik, Dirk, Frederick, Cameron, Nikos, Bogdan
14:54:01 [heycam]
RRSAgent: make minutes
14:54:01 [RRSAgent]
I have made the request to generate heycam
14:58:19 [jun]
jun has joined #svg
14:58:38 [stakagi]
stakagi has joined #svg
15:15:42 [heycam]
ScribeNick: heycam
15:15:45 [heycam]
Scribe: Cameron
15:15:48 [heycam]
Topic: lacuna values
15:16:05 [heycam]
Rossen: I don't know the history behind the term, but anyone I speak to is confused about the term
15:16:29 [heycam]
... if we can agree on a more standard name
15:16:43 [stakagi]
stakagi has joined #svg
15:16:51 [heycam]
... so I know that there was a problem with using the term default
15:16:57 [heycam]
... but initial would make sense
15:16:58 [shepazu]
shepazu has joined #svg
15:17:04 [tbah]
tbah has joined #svg
15:17:07 [ed]
ed has joined #svg
15:17:35 [jun]
jun has joined #svg
15:18:00 [fs]
fs has joined #svg
15:19:06 [heycam]
... so I propose that we call these initial values
15:19:25 [BogdanBrinza]
BogdanBrinza has joined #svg
15:20:08 [heycam]
ed: would initial potentially be confusing, especially if we promote properties later?
15:22:08 [heycam]
heycam: I am fine with initial
15:22:10 [heycam]
ed: met oo
15:22:12 [heycam]
s/met oo/
15:22:13 [heycam]
s/met oo//
15:22:51 [tbah]
tbah has joined #svg
15:22:56 [heycam]
ed: me too
15:23:10 [heycam]
RESOLUTION: Replace "lacuna value" with "initial value"
15:23:18 [heycam]
ACTION: Rossen to update "lacuna value" to "initial value"
15:23:19 [trackbot]
Created ACTION-3805 - Update "lacuna value" to "initial value" [on Rossen Atanassov - due 2015-06-18].
15:25:32 [Tav]
Tav has joined #svg
15:28:24 [krit]
15:33:56 [Rossen]
trackbot, close ACTION-3805
15:33:56 [trackbot]
Closed ACTION-3805.
15:55:07 [ed]
16:37:56 [krit]
ed: heycam: Was it that that we discussed in Leipzig: file:///Users/dschulze/Documents/svgwg/build/publish/coords.html#IntrinsicSizing ?
16:37:59 [krit]
16:38:21 [krit]
16:40:11 [ed]
krit: I remember that we discussed the sizing things in Leipzig, but don't quite recall all the aspects
16:45:35 [krit]
ed: no, not talking about details
16:45:49 [krit]
ed: did we discuss SVG as image or the embed case?
16:48:20 [ed]
krit: I think we mostly discussed the inline svg case, but that it mapped well to the other cases
16:48:23 [ed]
17:05:37 [heycam]
RRSAgent: make minutes
17:05:37 [RRSAgent]
I have made the request to generate heycam
17:22:26 [stakagi]
stakagi has joined #svg