09:45:24 <RRSAgent> RRSAgent has joined #svg
09:45:24 <RRSAgent> logging to http://www.w3.org/2015/08/27-svg-irc
09:45:26 <trackbot> RRSAgent, make logs public
09:45:26 <Zakim> Zakim has joined #svg
09:45:28 <trackbot> Zakim, this will be GA_SVGWG
09:45:28 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
09:45:29 <trackbot> Meeting: SVG Working Group Teleconference
09:45:29 <trackbot> Date: 27 August 2015
09:45:37 <heycam> Chair: Cameron
09:45:39 <heycam> Scribe: Cameron
09:45:42 <heycam> ScribeNick: heycam
09:45:49 <heycam> Present: Cyril, Cameron, Bogdan, Erik, Tav, Nikos
09:48:09 <cyril> cyril has joined #svg
09:49:08 <heycam> Topic: Embedded content chapter
09:49:19 <ed_paris__> ed_paris__ has joined #svg
09:49:21 <heycam> cyril: I wanted to fix a few things in this chapter
09:49:31 <heycam> ... adding examples, making it clear that the video element has to be in the HTML namespace
09:49:39 <heycam> ... but there are a few sentences that were not very clear to me
09:50:27 <heycam> ... the linked to section for the placement of video etc. doesn't actually talk about placement
09:50:41 <heycam> ... it talks about viewport
09:50:51 <heycam> ... why is there a link to that section that has x/y/width/height defined
09:51:03 <heycam> ... does this mean that x/y/width/height are on the video element? I don't think that is the intent
09:51:20 <heycam> ... there's also a sentence that says the HTML5 elements contribute to bounding box calculations
09:51:36 <heycam> ... and if you look at the bbox computations it talks about video's x/y/width/height
09:51:48 <heycam> ... so iframe/etc is not touched compare HTML?
09:51:50 <heycam> heycam: yes
09:51:55 <heycam> cyril: so the bbox calculations should be fixed
09:52:06 <heycam> nikos: is the intention that you put it in a group so you can place it?
09:52:31 <heycam> heycam: that, or transform, or top/left/width/height properties
09:54:50 <heycam> ACTION: Cameron to update the bbox section for HTML video etc. elements
09:54:50 <trackbot> Created ACTION-3817 - Update the bbox section for html video etc. elements [on Cameron McCormack - due 2015-09-03].
09:55:11 <heycam> cyril: if we agree that audio/video/canvas/iframe don't have x/y/width/height defined by SVG, then the section needs to be updated
09:55:16 <tkonno_> tkonno_ has joined #svg
09:55:31 <heycam> ... there are currently subsections like 11.5, 11.6, for each of the four elements, and they're all exactly the same text
09:55:36 <heycam> ... I don't think it's necessary
09:55:47 <heycam> ... having just one section that describes these elements overall is sufficient
09:55:57 <heycam> ... I started adding what Erik said, being explicit that these elements render
09:56:06 <heycam> ... but we don't say anything about the fallback content
09:56:25 <heycam> ... if you have an HTML element in the HTML namespace, like a <p>, inside the <video>, acting as fallback content, should it render?
09:56:32 <heycam> heycam: that is a good question
09:56:57 <heycam> cyril: seems like we have everything there for that to work
09:57:16 <heycam> ed: which spec should defined what should happen
09:57:54 <heycam> ... the unknown element handling doesn't cover this case
09:58:06 <heycam> ... it covers only unknown elements that you find as direct children of an SVG namespaced element
09:58:33 <heycam> cyril: I'll leave it as an issue in the spec
09:58:47 <tkonno> tkonno has joined #svg
09:59:11 <heycam> Tav: suppose I have Inkscape with a video element in it
09:59:16 <heycam> ... what are would the video cover?
10:00:29 <TabAtkins> Do you want me to go ahead and write up the SVG Layout spec?
10:00:39 <heycam> cyril: from what we said earlier, it would be given by the top/left/width/height CSS properties
10:01:05 <heycam> heycam: [explains how width/height of auto values and the width/height attributes on video etc. work]
10:14:29 <heycam> cyril: do we agree "Placement of the referenced resource" which defines x/y/width/height, is only applicable to the image element?
10:14:30 <heycam> BogdanBrinza: yes
10:14:35 <heycam> cyril: ok, I'll move that to the image element
10:19:08 <heycam> Rossen: I would expect that people will either use transform, just a regular CSS transform, to offset the video element to where they want it to be
10:19:19 <heycam> ... so <video style="transform: translate(10,20)">
10:19:31 <heycam> ... and sizing will be handled by width/height/min-width/min-height properties etc.
10:19:46 <heycam> ... the rest of the box model, margins and top/left/right/bottom, which are positioning properties, I'm seeing a harder time how those can be used
10:19:57 <heycam> ... in CSS, the positioning properties are also sometimes used to drive layout
10:20:07 <heycam> ... if you have width:auto;left:0;right:0, it will stretch the size of the element
10:20:12 <heycam> ... I don't think there's such a concept in SVG
10:20:20 <heycam> nikos: it would with the current definition
10:20:26 <heycam> BogdanBrinza: SVG only has explicit positioning
10:20:51 <heycam> cyril: since we defined the containing block is the viewport, it would just work
10:20:54 <heycam> cyril: don't know if we want that though
10:20:57 <heycam> Tav: I don't want that
10:21:08 <heycam> cyril: we could say CSS positioning properties do not apply in an SVG context
10:21:12 <heycam> ... and only use transform
10:21:39 <heycam> Rossen: if you want to minimize the imapct of CSS to SVG, to its bare minimum, then you have to ignore all of the positioning
10:21:52 <heycam> ... you'll need sizing, so width/height/min-width/etc.
10:22:20 <heycam> ... positioning in CSS is very contextual. if you depend on left/right, then what about grid columns and rows, they're also positinioing properties
10:22:26 <heycam> ... I'd prefer to reduce the set of properties that apply
10:22:41 <heycam> ... because there seems to be missing x/y for positioning of the element, the easy way is to use transform
10:22:48 <heycam> BogdanBrinza: or wrap it in a <g> or <svg>
10:23:15 <heycam> Rossen: I would avoid element explosion, I wouldn't want to see empty elements created just for the sake of positioning
10:23:20 <heycam> ... transform should just work
10:24:14 <heycam> heycam: ok, I am fine with that
10:26:18 <heycam> RESOLUTION: video etc. are positioned only with transform, not with top/left properties, but still sized with width/height properties
10:27:51 <heycam> RESOLUTION: Fallback content in video etc. should work, just as it does in HTML.
10:28:05 <heycam> cyril: the last bit is the namespace
10:28:14 <heycam> ... the HTML elements are required to use a namespace prefix when it's an XML parser
10:28:19 <heycam> ... when it's an HTML parser, that prefix is not needed
10:29:42 <heycam> heycam: it won't work in inline SVG in HTML
10:29:48 <heycam> ... until we ask for the HTML parser to be updated
10:30:07 <heycam> cyril: I'll add a note too that adding it using the DOM APIs will work
10:31:42 <heycam> Topic: bounding boxes of empty elements
10:31:56 <heycam> http://jsbin.com/qapopukifi/edit?html,output
10:32:12 <heycam> Rossen: the problem is getBBox and the way it works in different implementations at the moment
10:32:15 <heycam> ... it's non-interoperable
10:32:33 <heycam> ... current spec text is weak in defining exactly what happens, when you have zero area rect
10:32:45 <heycam> ... so there a couple ways of handling this
10:32:56 <heycam> ... the way of following normal geometric logic, or completely ignoring it
10:33:01 <heycam> ... and doing something more performant
10:33:17 <heycam> ... based on the example that I have, I see that Firefox is taking the "performant" path, which is to ignore geometry
10:33:24 <heycam> ... and if you have a zero area rectangle, just return a (0,0,0,0) rect
10:33:38 <heycam> ... which means you lose position, and potentially one dimension that is non-zero
10:33:44 <heycam> ... <rect x=10 y=10 width=100 height=0>
10:33:51 <heycam> ... Firefox returns (0,0,0,0) for its bbox
10:33:59 <heycam> ... Chrome is doing something similar
10:34:23 <heycam> ... the argument for following simply geometry, a rect is a rect, regardless if it's empty or not, has positinon and two dimensions which may or may not be zero
10:34:38 <heycam> ... this helps editors, etc., you always want to know where the rectangle is
10:35:01 <heycam> ... for browsers, which are basically able to determine that this is not going to render, during paint, then you can just ignore the whole thing
10:35:09 <heycam> ... not allocate any data for such elements, and always return the (0,0,0,0) for getBBox
10:35:26 <heycam> ... the main question is, first, which of these do we want
10:35:39 <heycam> ... then, it would be good to have concrete spec describing what needs to happen
10:35:51 <heycam> ... my selfish preference is to take the path of returning (0,0,0,0)
10:36:09 <ed_paris__> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
10:36:21 <heycam> Tav: what is useful for the user?
10:37:09 <heycam> Rossen: you can make further arguments and say from the OM point of view, if you're making some kind of collision detection with these non-zero width or non-zero height elements, I may decide that there's still a collision there
10:37:24 <heycam> ... I'm not arguing against geometry, but I also see the perf benefits
10:37:36 <heycam> nikos: what do you see getBBox used for
10:37:52 <heycam> Rossen: we have interop behaviour when the area is non-zero
10:44:57 <heycam> Rossen: I want consistency
10:44:59 <heycam> ... either way
10:45:12 <heycam> ... but prefer the (0,0,0,0)
10:46:01 <heycam> ed: the spec right now says the position should be included in the bounding box, afaict
10:46:09 <ed_paris__> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
10:47:40 <heycam> heycam: don't feel too strongly, slightly prefer returning "useful" values
10:47:48 <heycam> Rossen: authors will surely want that
10:48:02 <heycam> Rossen: if you position an empty div somehwere and get bounding rect, you'll get an empty rect at that place
10:49:43 <heycam> heycam: and if the zero sized shape is in a group and you get the bbox of the group, it's included?
10:49:50 <heycam> Rossen: yes
10:55:38 <ed_paris__> the bbox algo should probably say to use the x,y,width,height properties, not attributes (for <image> for example)
10:56:22 <heycam> RESOLUTION: bbox of SVG graphical elements must include the position and maybe one non-zero dimension if its area is zero. and this includes <text x y> with no content.
10:56:50 <heycam> ACTION: Cameron to fix bbox for this.
10:56:50 <trackbot> Created ACTION-3818 - Fix bbox for this. [on Cameron McCormack - due 2015-09-03].
10:57:12 <heycam> ACTION: Cameron review bbox algorithm for the new geometry properties
10:57:12 <trackbot> Created ACTION-3819 - Review bbox algorithm for the new geometry properties [on Cameron McCormack - due 2015-09-03].
10:58:23 <heycam> ACTION: Cameron to verify that "parse a declaration" is the right thing for the style attribute
10:58:23 <trackbot> Created ACTION-3820 - Verify that "parse a declaration" is the right thing for the style attribute [on Cameron McCormack - due 2015-09-03].
10:59:15 <heycam> Topic: Structure chapter status
10:59:16 <ed_paris__> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Document_Structure_.28Erik.29_.5Breadiness_3.5D
10:59:29 <heycam> ed: I've stricken out the things I've done
10:59:41 <heycam> ... down to 13 open issues, maybe the count went up a bit, I added some for the unknown elements
10:59:44 <heycam> ... but I think we're closer now
10:59:54 <heycam> ... a bunch of these are issues related to animation, so those will be closed soon
11:00:05 <heycam> birtles: I'm working on those animation ones now
11:00:17 <heycam> ed: so mostly it's issues around <use> and unknown elements
11:00:25 <heycam> ... the rest I think is editorial work, and in fairly good shape
11:00:35 <heycam> ... so maybe we could say that it's a 4 now
11:49:55 <Zakim> Zakim has left #svg
12:18:34 <cyril> cyril has joined #svg
12:19:20 <tantek> tantek has joined #svg
12:26:00 <heycam> Topic: promoting d to a property
12:26:14 <heycam> heycam: upstairs in the FXTF meeting people were in favour of going ahead with it
12:26:40 <heycam> ... thought we might already have had a resolution on this, but it seems not
12:27:01 <heycam> ... this would be using the same property syntax as used in Motion Path, i.e. path("M 0,0 ...")
12:27:12 <heycam> ... and explicitly not supporting other CSS Shapes just yet
12:28:48 <heycam> RESOLUTION: Promote d to a property, using path() functions, keeping the current syntax for the presentation attribute.
12:29:02 <heycam> ACTION: Cameron to promote d to a property
12:29:02 <trackbot> Created ACTION-3821 - Promote d to a property [on Cameron McCormack - due 2015-09-03].
12:37:20 <heycam> Topic: display:none on markers
12:37:31 <heycam> nikos: according to the spec, display doesn't apply to <marker>
12:37:54 <heycam> ... firefox does apply it
12:37:57 <heycam> ... chrome and safari don't
12:38:14 <heycam> ... since it seems to apply to most group elements, seems like it would be reasonable to include
12:38:59 <heycam> heycam: for Gecko I think it's easier to pay attention to display:none on the marker
12:39:05 <heycam> ... because we don't build frames for it
12:42:26 <heycam> birtles: we should just fix this bug in Firefox
12:42:42 <heycam> ... a lot of illustrator output doesn't work because of referencing display:none symbols
12:42:54 <heycam> ... illustrator has been updated and doesn't do that now, but there probably still is existing content out there
12:44:49 <heycam> Topic: SVG 2 chapter status update
12:45:46 <heycam> heycam: Cyril's Introduction chapter is basically done
12:45:51 <heycam> ... just one editorial issue remaining
12:45:55 <heycam> ... let's count it as a 5
12:46:13 <heycam> heycam: next is the Type chapter
12:46:29 <heycam> s/Type/Rendering/
12:46:32 <heycam> nikos: that's a 5 now
12:46:41 <heycam> ... one issue that Dirk added, which I don't understand
12:46:50 <heycam> ... it just says that in SVG 1.1, the definition for clip and something else followed on here
12:47:03 <heycam> ... so maybe if someone else could see if you can work out if there's an issue there
12:47:07 <heycam> ... and if not I'll just remove the issue
12:47:39 <nikos> file:///Users/nikos/svg/w3c/svgwg.tidyforpublication/build/publish/render.html#issue11
12:48:29 <nikos> https://svgwg.org/svg2-draft/render.html#issue11
12:49:21 <heycam> heycam: just remove it
12:49:28 <heycam> ... the chapter already talks about clipping and overflow
12:49:36 <heycam> heycam: next chapter is Types
12:50:47 <heycam> ... did a lot of rewriting of SVG DOM stuff
12:50:56 <heycam> ... reworded to making methods/attributes more concise too
12:51:14 <heycam> heycam: document struct, erik gave his update before
12:51:21 <heycam> heycam: next, Styling
12:51:57 <heycam> ... I've done about 2/3 of the rewrite
12:52:04 <heycam> ... should be able to finish this this afternoon
12:53:07 <heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes
12:53:15 <heycam> ... two main changes to get review from other people for
12:53:27 <heycam> ... one is the choice of which properties get presentation attributes, and on which elements they're supported
12:53:29 <heycam> ... see the link above
12:53:39 <heycam> ... second is the set of properties that are required to be supported in an SVG 2 user agent
12:53:53 <heycam> https://svgwg.org/svg2-draft/styling.html#RequiredProperties
12:55:50 <heycam> Tav: yesterday I was talking about the new font-variant properties, and font-feature-settings
12:56:00 <heycam> heycam: ok I'll add that
12:56:01 <jdaggett> jdaggett has joined #svg
12:56:41 <heycam> heycam: next is Geometry Properties
12:57:00 <heycam> ... that was already a 5 I think
12:57:07 <heycam> ... next is coords
12:57:22 <heycam> nikos: I think it's better than  2
12:57:26 <heycam> ... only 5 unresolved issues
12:57:35 <heycam> ... I think there was concern about viewport/canvas term use being inconsistent
12:57:41 <heycam> ... so that would be a bit of effort to go over
12:58:08 <heycam> ... most issues left are around bbox section
12:58:19 <heycam> heycam: they're my issues, so I'll look at them
12:58:23 <heycam> nikos: I'd at least put it up to a 3
12:58:40 <heycam> heycam: next is Paths
12:58:53 <heycam> ... that's already a 5
13:00:05 <heycam> ... next is Shapes
13:00:14 <heycam> ... still a 5
13:01:09 <heycam> ... next is Text
13:01:22 <heycam> ... a lot of work has been done, but a lot still needs to be done
13:01:46 <heycam> ... Tav and I came up with a plan for the chapter and an organisation we agree with
13:02:11 <heycam> Tav: currently there are no normative issues for discussion, but some might come up
13:02:27 <heycam> ... also some specs we're referring to are changing, like css-inline, writing-modes
13:03:19 <heycam> BogdanBrinza: sounds more than 2 then
13:03:23 <heycam> Tav: certainly not more than 3
13:03:25 <heycam> ... 3 if you round up
13:03:37 <heycam> ... I plan on working on it a lot this month, so should be above a 3 by then
13:03:57 <heycam> heycam: next is Embedded Content, ready for review
13:04:00 <heycam> ... cyril started review
13:04:14 <heycam> BogdanBrinza: biggest issue was placement of elements
13:04:16 <heycam> ... rest is editorial
13:04:24 <heycam> ... so I would leave it at 5
13:04:42 <heycam> heycam: after that is Painting
13:05:06 <heycam> ... I haven't done much on this chapter
13:05:58 <heycam> ... but there are no normative issues to discuss
13:06:03 <heycam> ... just write some examples, clarify some wording
13:06:25 <heycam> ... next is Paint Servers
13:06:35 <heycam> Tav: IDLs have been taken care of
13:06:41 <heycam> ... I've taken care of most of the issues
13:06:47 <heycam> ... to be sure it's a 5 I'd have to have a read through
13:07:43 <heycam> heycam: let's list it as 5 now
13:07:51 <heycam> ... I'll go through the hatch content model issue with you after this
13:08:00 <heycam> ... next, Scripting and Interactivity
13:08:35 <heycam> BogdanBrinza: was 4, probably similar
13:09:24 <heycam> heycam: next is Linking
13:09:29 <heycam> BogdanBrinza: ready for review
13:09:40 <heycam> ... biggest issues were Media Fragments, and we discussed them this week
13:25:14 <heycam> heycam: let's aim for all 5s by around TPAC, that will give us 3 months before the Sydney F2F at which we'll publish a CR
13:25:26 <heycam> ... if Text has trouble reaching 5 by October, we can help out at that point
13:25:39 <heycam> ... those 3 months we'll use for reviewing the spec as a whole, cleaning up wording, etc.
15:24:07 <nikos> http://paris.ilovebuvette.com
15:24:28 <heycam> RRSAgent: make minute
15:24:28 <RRSAgent> I'm logging. I don't understand 'make minute', heycam.  Try /msg RRSAgent help
15:24:29 <heycam> RRSAgent: make minutes
15:24:29 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/27-svg-minutes.html heycam
17:08:02 <Tav> Tav has joined #svg