22:26:50 <RRSAgent> RRSAgent has joined #svg
22:26:50 <RRSAgent> logging to http://www.w3.org/2015/02/11-svg-irc
22:26:52 <trackbot> RRSAgent, make logs public
22:26:52 <Zakim> Zakim has joined #svg
22:26:54 <trackbot> Zakim, this will be GA_SVGWG
22:26:54 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:26:55 <trackbot> Meeting: SVG Working Group Teleconference
22:26:55 <trackbot> Date: 11 February 2015
22:27:20 <heycam> Meeting: SVG Sydney F2F 2015 day 1
22:27:24 <heycam> Chair: Cameron
22:28:06 <heycam> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
22:29:01 <jet> jet has joined #svg
22:29:50 <birtles> scribe: birtles
22:29:53 <birtles> scribenick: birtles
22:30:27 <birtles> topic: Publication of the Accessibility mapping document
22:30:28 <stakagi> stakagi has joined #svg
22:30:32 <heycam> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html
22:30:47 <birtles> heycam: some of you would have gone to the telcon with the accessibility tf a couple of weeks ago to review the publication
22:30:57 <birtles> ed: I went to the telcon and sent some review comments
22:31:18 <shepazu> +1 to publication
22:31:18 <birtles> ... it describes how to represent SVG markup in an accessible way
22:31:30 <birtles> ... it's outside of SVG so it doesn't affect our spec so much
22:31:38 <birtles> ... there's a table in the SVG spec at the moment
22:31:46 <birtles> heycam: so that would be replaced by a reference to this document?
22:31:50 <birtles> ed: I suppose so
22:32:01 <BogdanBrinza> BogdanBrinza has joined #svg
22:32:02 <shepazu> (well, it describes the mapping of SVG elements to the underlying platform accessibility APIs
22:32:10 <birtles> krit: I think we should keep the table to make sure that everyone knows that accessibility is important to us
22:33:13 <Tav> Tav has joined #svg
22:33:13 <heycam> Zakim, room for 4?
22:33:14 <Zakim> ok, heycam; conference Team_(svg)22:33Z scheduled with code 26631 (CONF1) for 60 minutes until 2333Z
22:33:37 <Zakim> Team_(svg)22:33Z has now started
22:33:46 <Zakim> +Doug_Schepers
22:34:06 <Zakim> + +61.2.933.6.aaaa
22:34:31 <birtles> heycam: shepazu, did you attend the call with the accessibility tf
22:34:34 <birtles> shepazu: yes, I attend them all
22:34:41 <birtles> ... I wanted to be clear about what the doc is for
22:34:50 <birtles> ... it doesn't describe how to make SVG accessible
22:35:00 <birtles> ... it says which parts of SVG map to which parts of the accessibility API
22:35:09 <birtles> ... e.g. links, groups elements, what do they actually do
22:35:17 <birtles> ... as you can expect, there are very few native mappings
22:35:32 <birtles> ... because SVG doesn't have the kind of rich interaction modes that HTML has: forms, headings etc.
22:35:48 <Zakim> +Rich_Schwerdtfeger
22:35:58 <birtles> ... but this is a good first step, lays the the groundwork for how accessibility APIs should map to SVG
22:36:51 <birtles> ... the document says, of the features that are in SVG, what are the interaction modes with the native accessibility APIs
22:37:24 <birtles> richardschwerdtfeger: every platform that supports accessibility has an API for exposing different items
22:38:02 <birtles> ... what this document does is it says that when you put this (SVG) content in your web page, this is how you expose it to those APIs so that the accessibility technology
22:38:10 <birtles> ... can interact with it like any other software applicaiton
22:38:26 <birtles> ... so this spec is actually an extension to a core specification for all browsers
22:39:19 <birtles> ... we're doing the same thing for HTML but it just happens that the SVG one is getting out ahead of the HTML one because I happened to work on this first
22:39:29 <birtles> shepazu: I forgot the detail about the accessible name computation
22:39:43 <birtles> ... for example, that will give you the title
22:39:47 <birtles> ... so there's a name and a description?
22:39:50 <birtles> richardschwerdtfeger: correct
22:40:02 <birtles> ... each of the APIs has a method that will correlate to an SVG element
22:40:14 <birtles> ... and that will give you more information like descriptions
22:40:22 <birtles> shepazu: for example, if you're using a screen reader
22:40:40 <birtles> ... you have 5 circles, each has a title, the screen reader would go through them in document order
22:40:45 <birtles> ... each of them represents a different thing
22:40:57 <birtles> ... it would go through, and say, in document order, the title for each one
22:41:10 <birtles> ... if you had a description it might also, e.g. beep, to tell you there's more information
22:41:18 <birtles> ... so you can say, "I want more information"
22:41:31 <birtles> ... so it would read the title, but not the description unless you ask for it
22:41:42 <birtles> heycam: richardschwerdtfeger, you're looking to publish this as FPWD right?
22:41:44 <birtles> richardschwerdtfeger: correct
22:41:54 <birtles> krit: are there any issues that need to be discussed?
22:41:59 <birtles> richardschwerdtfeger: I don't think so
22:42:12 <birtles> ... there are a couple of issues we need to address about *not* mapping things
22:42:19 <birtles> ... but they are already issues in the spec
22:42:32 <birtles> shepazu: this is just a FPWD, but it's pretty complete
22:42:38 <birtles> heycam: do we agree to publish a FPWD?
22:42:42 <birtles> krit: agree
22:42:45 <shepazu> +1
22:42:45 <shepazu> +1
22:42:50 <richardschwerdtfeger> +1
22:42:56 <birtles> RESOLUTION: SVGWG agrees to publish the accessibility mappings document as a FPWD
22:43:10 <birtles> shepazu: thanks for all your work richardschwerdtfeger
22:44:01 <birtles> topic: Adding new integer enum values in light of not going ahead with new SVG DOM
22:44:13 <Zakim> -Doug_Schepers
22:44:39 <birtles> heycam: we made a decision a little while ago to stop adding new numeric constants to the DOM
22:44:45 <birtles> ... today it's considered a bit of an anti-pattern
22:44:50 <birtles> ... new APIs use strings as their enum values
22:44:55 <birtles> ... HTML does that
22:45:04 <birtles> ... the original SVG DOM has a lot of numeric values for enums
22:45:21 <heycam> Zakim, who is on the call?
22:45:21 <Zakim> On the phone I see +61.2.933.6.aaaa, Rich_Schwerdtfeger
22:45:31 <birtles> ... that consists of a property that takes a number and a bunch of numeric constants defined on that interface
22:45:43 <birtles> ... we decided to not propagate any more usage of this
22:45:50 <birtles> ... by saying that any new enums should use strings
22:45:51 <krit> Zakim, who is noisy?
22:46:10 <Zakim> krit, listening for 10 seconds I heard sound from the following: +61.2.933.6.aaaa (79%)
22:46:13 <birtles> ... but also by saying that for enums that we extend, we won't add any new numeric values
22:46:31 <birtles> ... but represent those using the zero value
22:46:45 <birtles> ... and we'd introduce a new DOM to fix this later
22:47:07 <birtles> ... but since we're probably not going ahead with that new API perhaps we should add numeric constants for the new values
22:47:18 <birtles> ... I think we shouldn't squash all those new values into the zero value
22:47:36 <birtles> ed: so just new numbers or new constants too?
22:47:48 <cyril> cyril has joined #svg
22:47:51 <birtles> heycam: adding new numbers would fix the implementation difficulty but not the authoring difficulty
22:48:12 <birtles> ed: I'm concerned with maintaining the list of numbers
22:48:20 <birtles> ... both in spec terms and implementation terms
22:48:34 <jun> jun has joined #svg
22:48:43 <birtles> ... I don't think we can keep up with all the new units etc. that get coined
22:48:56 <birtles> s/ed: I'm concerned with maintaining the list of numbers/krit: I'm concerned with maintaining the list of numbers/
22:49:09 <birtles> heycam: so krit you're not in favour?
22:49:13 <birtles> krit: not really
22:49:28 <birtles> ed: I'd prefer to drop the enum values and add some other method of using the strings
22:49:49 <birtles> ... I don't think we have useage counters for the methods that do take the numeric values
22:50:39 <birtles> krit: could we move the whole section about the SVG DOM to a separate document?
22:50:59 <birtles> heycam: but a lot of the SVG DOM stuff is reflecting things defined only in the SVG spec
22:51:07 <cyril> cyril has changed the topic to: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
22:51:16 <ed> s/ed: I'd prefer to drop the enum values and add some other method of using the strings/ ed: I'd prefer to drop the enum values and add some other method of using the new units (eg passing strings into methods that take those enums currently)/
22:51:30 <cyril> RRSAgent, pointer
22:51:30 <RRSAgent> See http://www.w3.org/2015/02/11-svg-irc#T22-51-30
22:52:03 <cyril> RRSAgent, this meeting spans midnight
22:52:07 <birtles> heycam: if people aren't enthusiastic with my proposal I'm happy with sticking with the status quo
22:52:34 <birtles> krit: if we keep the SVG DOM, then it will get used more and more and become harder to change
22:52:54 <birtles> ed: is it worth changing the methods that take these values into taking a string, for example
22:53:09 <birtles> krit: you could try to disable certain APIs, not the whole API, but just one API at a time
22:53:26 <birtles> heycam: I thought you (krit) were going to try that already?
22:53:34 <birtles> krit: I was going to, but don't have time
22:53:52 <birtles> ed: we do have usage counters for things like the animated types, suspendRedraw etc.
22:54:09 <birtles> heycam: we want to know specifically for things like getAnimVal etc.
22:54:18 <birtles> ... we're not going to remove getBBox() for example
22:54:30 <birtles> krit: it's probably safe to just map animVal to baseVal since IE does it
22:54:59 <birtles> ed: the use of the SVG DOM is 0.04%
22:55:37 <birtles> TabAtkins: 0.04% is still high but it would worth breaking down those numbers to find out which parts we could remove
22:56:04 <birtles> ed: I've added use counters for path segment interfaces and those are very low
22:56:30 <birtles> ... we can certainly add more use counters but we need to know what to measure
22:56:56 <birtles> heycam: the most important to me is the animVal interfaces
22:57:22 <birtles> ed: SVGAnimatedTransformList.baseVal usage is very low
22:57:29 <birtles> krit: what is used then?
22:57:44 <birtles> ... if not paths or transforms
22:58:00 <birtles> ed: probably animated lengths
22:58:43 <birtles> krit: everyone uses animVal
22:59:18 <birtles> ... I think we should just map animVal to baseVal
22:59:33 <birtles> shane: I think could remove baseVal
22:59:42 <birtles> krit: I'm not sure
23:00:10 <birtles> ... did MS get any complaints about not supporting animVal?
23:00:29 <birtles> (some discussion about which is used more commonly, animVal or baseVal)
23:00:50 <birtles> heycam: it would be helpful to get some usage countes on animVal / baseVal
23:00:57 <birtles> s/countes/counters/
23:01:51 <Zakim> -Rich_Schwerdtfeger
23:02:13 <birtles> ACTION: ed to add usage counters to blink to measure usage of animVal / baseVal
23:02:14 <trackbot> Created ACTION-3701 - Add usage counters to blink to measure usage of animval / baseval [on Erik Dahlström - due 2015-02-18].
23:02:34 <Zakim> - +61.2.933.6.aaaa
23:02:35 <Zakim> Team_(svg)22:33Z has ended
23:02:35 <Zakim> Attendees were Doug_Schepers, +61.2.933.6.aaaa, Rich_Schwerdtfeger
23:02:48 <birtles> topic: Avoiding new camelcase names
23:03:00 <birtles> heycam: this is something we already agreed to do
23:03:16 <birtles> ... but we still have newish names in the spec that use camelCase
23:03:52 <birtles> Tav: we have meshGradient and I think it should match linearGradient and radialGradient
23:04:22 <birtles> heycam: that's the question: consistency with existing things vs awkwardness of updating the HTML parser
23:04:38 <birtles> shane: I think consistency argument is a strong one
23:04:42 <birtles> ed: I agree
23:04:57 <birtles> ... but for new attributes that don't need to be consistent with anything they should be lowercase
23:05:19 <birtles> heycam: I think <meshGradient> could be just <mesh> since it can render by itself
23:05:47 <birtles> Tav: in Inkscape it was easy to implement meshGradient based on existing gradient code
23:05:56 <birtles> ... implementing rendering by itself could take some time
23:06:46 <birtles> krit: if meshes can be a shape then I think the argument for renaming to <mesh> is strong
23:07:00 <birtles> heycam: there's still the child elements, <meshRow> etc.
23:07:04 <birtles> roc: they could be lowercase
23:07:13 <birtles> ed: do we want to rename it to <mesh>?
23:07:15 <birtles> roc: yes
23:07:17 <birtles> TabAtkins: yes
23:07:34 <birtles> nikos: can you choose to fill it with something other than a gradient?
23:07:42 <birtles> (no)
23:07:58 <birtles> heycam: I checked the HTML spec and it doesn't have these names in it yet
23:08:37 <birtles> nikos: you could have a paint server that defines the gradient and normal SVG shapes that define the mesh
23:08:44 <birtles> krit: would that simplify things?
23:08:48 <birtles> Tav: that complicates things
23:09:00 <birtles> heycam: I think it's going to be pretty common to want to use the same geometry
23:09:18 <birtles> heycam: Tav, what do you think about renaming to <mesh> and renaming the child elements to make them lowercase
23:09:46 <birtles> Tav: I'm not going to jump and down, but I guess it's ok
23:10:47 <birtles> krit: I think it's confusing that linearGradient by itself doesn't render, but a meshGradient does--so renaming makes sense
23:10:55 <birtles> Tav: so the children would be mesh-row
23:11:02 <birtles> (no, dashes are reserved)
23:11:14 <birtles> (some discussion about using <row> and about it being to generic)
23:11:34 <birtles> krit: I think we agree we don't want camelCase within the mesh
23:12:03 <birtles> RESOLUTION: Rename <meshGradient> to <mesh> and make the child element names lowercase
23:12:42 <birtles> heycam: the remaining new camelCase names are the hatch ones (hatchPath)
23:12:55 <birtles> Tav: so that would become lowercase
23:13:20 <birtles> krit: can we just use normal paths...
23:13:34 <birtles> Tav: we talked about that before and decided this was best
23:13:57 <birtles> RESOLUTION: Rename <hatchPath> to <hatchpath>
23:14:12 <birtles> heycam: the other new camelCase element name is solidColor
23:14:56 <birtles> ... I'm not thrilled by this element but Tav's argument is that implementing variables is more overhead
23:15:09 <birtles> ... you can also get the same effect with a gradient with a single stop
23:15:19 <birtles> Tav: but that's really ugly in the code
23:16:08 <birtles> heycam: assuming that element stays, can we lowercase it?
23:16:15 <birtles> Tav: I don't care
23:16:24 <birtles> RESOLUTION: Rename <solidColor> to <solidcolor>
23:16:43 <birtles> ed: attribute names? camelCased?
23:16:53 <birtles> ... we have a bunch of them and we should try and avoid them if we can
23:17:17 <birtles> ... I found playbackOrder and timelineBegin
23:17:33 <birtles> heycam: attribute names and attribute values are slightly different
23:17:48 <birtles> ... attribute names have to be handled in the HTML parser
23:17:56 <birtles> ... attribute values are more of just an aesthetic thing
23:18:33 <birtles> ... I think it would be better to make them lowercase
23:18:58 <birtles> ed: we have a hatchTransform attribute
23:19:13 <birtles> Tav: that follows the patternTransform and gradientTransform attribute
23:19:27 <birtles> krit: gradientTransform maps transform so we shouldn't make that mistake again
23:19:39 <birtles> ... we should just use transform
23:19:50 <birtles> RESOLUTION: Rename hatchTransform to transform
23:20:43 <birtles> ed: there are other ones like hatchContentUnits and hatchUnits
23:22:07 <birtles> ACTION: ed to write up a list of all new camelCase attributes with a proposal of how to handle them (e.g. rename, keep etc.)
23:22:07 <trackbot> Created ACTION-3702 - Write up a list of all new camelcase attributes with a proposal of how to handle them (e.g. rename, keep etc.) [on Erik Dahlström - due 2015-02-18].
23:22:24 <birtles> topic: Attribute parsing overhaul
23:22:42 <birtles> heycam: my most recent change to the spec is to unify the parsing of attributes and how their grammars are defined
23:23:07 <birtles> ... previously there was a bit of a mish-mash of "this attribute is defined in terms of CSS meta-syntax, this one is EBNF etc."
23:23:21 <birtles> ... of those I think the CSS syntax is the nicest so I converted all of the attributes to use that
23:23:31 <birtles> ... so using [] for grouping, referencing CSS types etc.
23:23:39 <birtles> ... which meant I was able to remove a lot of the types chapter
23:23:50 <heycam> https://svgwg.org/svg2-draft/types.html#syntax
23:23:51 <birtles> ... which defined a lot of the re-useable types
23:24:14 <birtles> ... I replaced the section that defined things like length, list of strings etc., with this section
23:24:39 <birtles> ... most of these are using CSS now, a couple still use EBNF because they reference other specs, or path data which is quite complex
23:24:48 <birtles> ... I've updated lists to use CSS
23:25:15 <birtles> ... one important change is that I'm not sure that we want to call into the CSS parser without flags...
23:25:34 <birtles> ... should we allow comments, escapes etc.?
23:25:51 <birtles> ... or should I make Tab add flags to the CSS parser to disable these features?
23:26:10 <birtles> TabAtkins: unless you think it will cause problems, I think we should allow comments, CSS escapes etc.
23:26:19 <birtles> ed: which attributes does this affect? presentation attributes?
23:26:34 <birtles> heycam: presentation attributes already map to CSS so allow those things
23:27:07 <birtles> ... the reason I hesitate about allowing those things elsewhere is it means implementations have to update to call the CSS parser for these attributes
23:27:17 <TabAtkins> <path d> is basically impossible to convert to CSS grammar anyway. "h10v10" is a single <ident-token>, for example. Disentangling that is super hard.
23:28:03 <TabAtkins> I did it for An+B and <urange>, and it was terrible both times, and <path d> will be *much worse*.
23:28:05 <birtles> cyril: how did you test that the new grammar matches the old?
23:28:11 <birtles> heycam: most of them are pretty simple
23:28:18 <birtles> cyril: are there any hard ones?
23:28:35 <birtles> heycam: the ones that are either space or comma separates--I think I got them right
23:28:55 <birtles> ... it's not a common pattern in CSS
23:29:22 <birtles> (discussion about whether heycam got the grammar right, seems like he probably did)
23:30:10 <heycam> https://svgwg.org/svg2-draft/shapes.html#DataTypePoints
23:30:23 <TabAtkins> To do a list of <foo> that is comma-or-whitespace, do <foo>+#?
23:30:48 <birtles> heycam: this looks weird for CSS syntax but I think it's right
23:30:53 <heycam> https://svgwg.org/svg2-draft/text.html#TextElementXAttribute
23:31:29 <birtles> heycam: this might need to change, particularly because we have the new x/y properties
23:32:06 <birtles> krit: can you remove the number from [<length> | <percentage> | <number>]
23:32:21 <birtles> ... because it is implicitly allowed for attributes
23:32:27 <birtles> heycam: is that right?
23:32:39 <birtles> ... properties that can take lengths can also take numbers in SVG
23:33:02 <birtles> ... during this conversion I made this explicit by adding in <number>
23:33:21 <birtles> TabAtkins: you can also use quirky-length
23:33:28 <birtles> ... it's length or number with number meaning pixels
23:33:52 <birtles> heycam: I'd like to make it explicit
23:34:10 <birtles> ... regarding percentages which krit brought up recently
23:34:35 <birtles> ... I haven't gone through it properly yet but I've tried to add in percentages
23:35:07 <birtles> shane: we're exposing the path syntax in CSS with the Motion Path module
23:35:13 <birtles> krit: but there's it's a string, it's not parsed
23:35:27 <birtles> heycam: so is this conversion ok?
23:35:43 <birtles> (question about formatting of attribute formatting--text chapter is yet to be done)
23:36:50 <roc> roc has joined #svg
23:58:04 <jdaggett> jdaggett has joined #svg
23:58:11 <krit> scribeNick: krit
23:58:27 <krit> Topic: What to do with the embedded content chapter
23:58:34 <heycam> https://svgwg.org/svg2-draft/embedded.html
23:58:53 <krit> heycam: this is about iframe, video, audio
23:59:07 <krit> heycam: we had objections from ppl about that approach for at least the iframe
23:59:23 <krit> heycam: ppl didn't like adding them to the SVG NS and we should solve these in other ways
23:59:45 <krit> heycam: This has to do how we merge NS or get rid of them but that is a long term goal
23:59:51 <krit> heycam: what do we do in the spec now?
00:00:17 <krit> heycam: it is possible to use these futures with foreignObject
00:00:28 <krit> heycam: is that maybe sufficient enough?
00:00:43 <krit> heycam: We could add notes that this is a way to get video and others
00:00:58 <krit> heycam: and describe how video and audio could work in SVG later
00:01:29 <krit> birtles: I would be interested in <box> as a light weighted version of <foreignObject>
00:02:00 <birtles> specifically, <box> also shrink-wraps its contents
00:02:07 <birtles> see discussion from TPAC last year: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_integration_again
00:02:19 <krit> BogdanBrinza: We implement foreingObject and box would just be a special case of fO
00:02:48 <krit> heycam: do you want it in SVG2 or is it ok for SVG3?
00:03:03 <krit> birtles: With a rapid release cycle I am ok with defer
00:03:34 <krit> heycam: so box would take width and height
00:03:37 <krit> birtles: right
00:03:44 <krit> roc: it is actually inline
00:04:02 <krit> heycam: do you have a proposal for box?
00:04:51 <krit> birtles: I was pesismisitic about the 2 experiments around october
00:05:25 <birtles> TPAC discussion: http://www.w3.org/2014/10/31-svg-minutes.html#item09
00:06:39 <krit> birtles: I am starting to lean more to <box> than the alternatives
00:07:20 <krit> roc: so you have a preferred intrinsic width
00:07:37 <krit> roc: you have a min width and the intrinsic with and this is the width you actually get
00:08:12 <krit> roc: you need to have some way of controlling the box element some kind of idea what the width
00:08:25 <krit> krit: why can
00:08:34 <krit> t that be the intrinsic width?
00:08:50 <krit> heycam: what happens abs pos?
00:09:02 <krit> s/happens/happens on/
00:09:10 <krit> roc: it comes from the containing block
00:09:35 <krit> krit: could box create a initial containing block
00:09:45 <krit> roc: not initial but definitely a containing block
00:10:04 <krit> roc: for relative positioning
00:10:13 <krit> roc: it would still need a width constrain
00:10:26 <krit> roc: otherwise it is flying of the page what you don't want
00:10:41 <krit> roc: so you need to come up with a reasonable default
00:10:55 <krit> heycam: we can do that. I like <box>
00:11:36 <krit> roc: is it really so hard to get iframe, video, audio and element with intrinsic with to be a direct part of a SVG container
00:12:00 <krit> roc: i didn't like to have a iframe element that was different than the one in HTML
00:12:25 <krit> heycam: what about the NS?
00:12:30 <krit> roc: would be HTML
00:12:43 <krit> ed: what about the XML parser?
00:12:53 <shepazu> +1 to just use the HTML elements for iframe, audio, video, etc
00:13:00 <krit> heycam: you can't SVG image in and SVG context
00:13:15 <krit> roc: it could be sag/xml
00:13:24 <krit> roc: that does not require XML parsing
00:13:41 <krit> roc: you gonna not have a iframe video and an SVG image
00:14:11 <krit> roc: you could do all the things in XML as well, just put more code on it
00:14:37 <krit> ed: how do we proceed
00:14:47 <shepazu> (is it feasible to remove namespaces from browsers at this point? how much would it break?)
00:14:51 <shepazu> (I mean in an HTML/SVG context)
00:14:51 <krit> krit: do we do that for SVG2 or SVG3?
00:15:03 <krit> heycam: there are a lot of details we need to discuss
00:15:13 <krit> TabAtkins: we don't have to worry about this
00:15:50 <krit> TabAtkins: we don't have to care about an SVG image in an HTML document now
00:16:23 <krit> TabAtkins: allowing HTML parser for the SVG images makes it easy to use video and audio but we don't have to care about that
00:16:40 <krit> TabAtkins: all JS functions can create HTML element by adding the NS
00:16:48 <krit> TabAtkins: we can do SVG in HTML later
00:17:01 <krit> TabAtkins: and use a limited set of THML element into SVG now
00:17:32 <krit> heycam: so we only need to this parser change and state in the spec what an HTML element means in the SVG NS
00:17:50 <krit> birtles: if we can do that approach than this is enough for SVG2
00:18:36 <krit> birtles: we still need to add the x,y presentation attributes on the iframe element and Ian doesn't want to do that
00:18:44 <krit> roc: we should force this issue
00:18:58 <krit> roc: we should stick to replaced element
00:19:55 <krit> birtles: that would be a good start
00:20:33 <cyril> s/sag/svg/
00:20:55 <krit> krit: replace elements means allowing object and embed as well
00:21:04 <krit> roc: well yes, we don't want to do that
00:21:24 <krit> roc: we should limit the list to a fixed set of elements and allow replaced elements later
00:22:05 <krit> krit: we would still depend onHTML parser changes and the x,y attributes
00:22:14 <krit> roc: we will need CSS terms
00:22:25 <krit> roc: like some kind of containing block
00:22:33 <krit> TabAtkins: would be the nearest SVG viewport
00:22:53 <krit> roc: we need to say if they are display: block or inline
00:23:10 <krit> TabAtkins: everything is implicitly position in SVG so it would be block
00:23:14 <krit> roc: that is fine
00:25:36 <krit> RESOLUTION: Allow HTML NSed elements audio, video, canvas, iframe in an SVG subtree as a child of a container element with the containing block being the nearest SVG viewport and blockyfied
00:26:28 <krit> ACTION: heycam to change embedded content chapter to allow these things from resolution: Allow HTML NSed elements audio, video, canvas, iframe in an SVG subtree as a child of a container element with the containing block being the nearest SVG viewport and blockyfied
00:26:29 <trackbot> Created ACTION-3703 - Change embedded content chapter to allow these things from resolution: allow html nsed elements audio, video, canvas, iframe in an svg subtree as a child of a container element with the containing block being the nearest svg viewport and blockyfied [on Cameron McCormack - due 2015-02-19].
00:26:41 <krit> ACTION: TabAtkins write the SVG layout spec
00:26:41 <trackbot> Created ACTION-3704 - Write the svg layout spec [on Tab Atkins Jr. - due 2015-02-19].
00:27:20 <krit> ed: there is an issue with the width and height properties take integers
00:27:34 <krit> krit: you mean the problem is a specified viewBox
00:27:36 <krit> ed: yes
00:27:53 <krit> roc: you can style with CSS
00:28:04 <krit> heycam: but you don't want to have half pixels in Canvas
00:28:15 <krit> heycam: but it is probably a rare situation anyway
00:28:33 <krit> roc: I don't think there is any reason to handle video any specific way
00:28:37 <krit> roc: Canvas is special
00:29:14 <krit> roc: width and height map to CSS and nothing else happens but in Canvas these attributes also set the backing store
00:29:59 <krit> krit: it might be confusing that width/height are no presentation attributes but users know that from HTML already
00:32:17 <krit> ACTION: TabAtkins convince Hixie to make the HMTL parser changes + x/y presentation attributes on the canvas,... elements for SVG
00:32:18 <trackbot> Created ACTION-3705 - Convince hixie to make the hmtl parser changes + x/y presentation attributes on the canvas,... elements for svg [on Tab Atkins Jr. - due 2015-02-19].
00:33:53 <krit> ACTION: TabAtkins Allow templates in SVG which needs HTML parser changes
00:33:54 <trackbot> Created ACTION-3706 - Allow templates in svg which needs html parser changes [on Tab Atkins Jr. - due 2015-02-19].
00:35:20 <krit> heycam: we should also get <link> to work in SVG
00:35:27 <krit> ed: They might in browsers already
00:35:44 <heycam> ACTION: Cameron to investigate which HTML elements like <link> we might want to also allow in SVG
00:35:45 <trackbot> Created ACTION-3707 - Investigate which html elements like <link> we might want to also allow in svg [on Cameron McCormack - due 2015-02-19].
00:35:46 <krit> krit: not sure that is the case. It didn't work for standalone SVG for me
00:36:12 <krit> ed: I'll test
00:36:19 <shepazu> +1 to letting <link> work in SVG... what about <meta> too?
00:36:22 <shepazu> http://schepers.cc/css-link-hack-in-svg
00:37:26 <krit> heycam: <meta> I want too
00:37:27 <heycam> sounds good to me; I'll gather a list of likely HTML elements to allow with my action
00:37:57 <krit> topic: What is going to happen to the SVG DOM
00:38:06 <krit> nikos: have nothing specific about that
00:38:20 <krit> nikos: we talked half about that in the previous session
00:39:16 <krit> heycam: we do the investigations with the use counters and drop SVG DOM interfaces over time
00:39:35 <krit> TabAtkins: most of the CSS OM stuff is going to work with SVG as well
00:40:20 <krit> Topic: Requiring foreignObject HTML behavior
00:40:35 <krit> heycam: we need to make spec say that HTML content in fO gets rendered
00:40:58 <krit> ed: I don't think we want to have the hasFeature for fO at all
00:41:15 <ed> hasFeature/requiredFeatures
00:42:09 <krit> heycam: we willhave a conformance class that will require HTML and another that doesn't
00:42:43 <krit> heycam: the sizing of fO containing block should be in sVG2
00:42:48 <BogdanBrinza_> BogdanBrinza_ has joined #svg
00:43:33 <krit> roc: agree, there is a bunch of not clarified stuff
00:44:04 <krit> ACTION: Reference integration spec and update conformance class for HTML support on foreignObject
00:44:04 <trackbot> Error finding 'Reference'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
00:44:15 <krit> ACTION: heycam Reference integration spec and update conformance class for HTML support on foreignObject
00:44:15 <trackbot> Created ACTION-3708 - Reference integration spec and update conformance class for html support on foreignobject [on Cameron McCormack - due 2015-02-19].
00:44:39 <krit> topic: Requiring style sheet support
00:45:39 <krit> Tav: we do support stylesheets but no fancy selectors
00:45:46 <AmeliaBR> AmeliaBR has joined #svg
00:45:49 <krit> heycam: oh, that is what I want to require
00:46:08 <krit> heycam: should we add a new conformance class maybe?
00:46:26 <krit> krit: no, we should require style sheet support
00:46:43 <krit> krit: authoring tools need to update at some part
00:47:01 <krit> Tav: we rely on someone else's library
00:48:03 <krit> ACTION: hey cam add stylesheet requirements to the spec
00:48:03 <trackbot> Error finding 'hey'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
00:48:10 <krit> ACTION: heycam add stylesheet requirements to the spec
00:48:10 <trackbot> Created ACTION-3709 - Add stylesheet requirements to the spec [on Cameron McCormack - due 2015-02-19].
00:48:47 <krit> topic: Drop xml:base/land/space attributes
00:48:58 <krit> ed: I have a test case that works the same way in all browsers
00:48:59 <heycam> s/land/lang/
00:49:33 <ed> <svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
00:49:34 <ed>     <link xmlns="http://www.w3.org/1999/xhtml" rel="stylesheet" type="text/css" href="data:text/css,circle { fill:green; }"/>
00:49:34 <ed>     <circle cx="50" cy="50" r="25" fill="red"/>
00:49:34 <ed> </svg>
00:49:44 <krit> ed: the test case adds a <link> element and it works in all browsers I tested
00:50:21 <TabAtkins> http://www.xanthir.com/etc/svg.php?width=100&height=100&svg=%3Clink+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+rel%3D%22stylesheet%22+type%3D%22text%2Fcss%22+href%3D%22data%3Atext%2Fcss%2Ccircle+%7B+fill%3Agreen%3B+%7D%22%2F%3E%0D%0A%3Ccircle+cx%3D%2250%22+cy%3D%2250%22+r%3D%2225%22+fill%3D%22red%22%2F%3E
00:51:25 <krit> ed: this was to one of the previous topics
00:51:32 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/dropxmlattributes
00:52:00 <krit> ed: I split the proposal into several parts
00:52:20 <krit> ed: [explains more of the proposal as written in the document]
00:52:23 <ed> https://www.chromestatus.com/metrics/feature/timeline/popularity/580
00:53:07 <krit> ed: the usage of xml:base is 0
00:53:19 <krit> krit: and xml:lang?
00:53:57 <krit> heycam: so we do not support the IDL properties for those
00:54:22 <krit> ed: I would like to remove the IDL properties
00:54:29 <krit> krit: fine with me
00:55:17 <krit> RESOLUTION: Remove xml:base/space/lang from spec
00:55:34 <krit> s/from spec/from the SVG DOM interface/
00:56:00 <krit> ACTION: ed Remove xml:base/space/lang from the SVG DOM interface
00:56:00 <trackbot> Created ACTION-3710 - Remove xml:base/space/lang from the svg dom interface [on Erik Dahlström - due 2015-02-19].
00:56:24 <krit> ed: the 2nd part is remove xml:base entirely
00:56:46 <krit> ed: and describe how the others work with the non-NSed versions
00:56:55 <krit> ed: this is a breaking change
00:57:01 <krit> krit: do you have data for that?
00:57:18 <krit> ed: no, but I still think we want to clean up the XML database
00:57:53 <Zakim> Zakim has left #svg
00:58:28 <heycam> RRSAgent, pointer?
00:58:28 <RRSAgent> See http://www.w3.org/2015/02/11-svg-irc#T00-58-28
01:00:28 <krit> ACTION; Write tests and come back to the SVG for xml:base
01:00:38 <krit> ACTION: Write tests and come back to the SVG for xml:base
01:00:39 <trackbot> Error finding 'Write'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
01:01:05 <krit> ACTION: heycam  Write tests and come back to the SVG for xml:base
01:01:06 <trackbot> Created ACTION-3711 -  write tests and come back to the svg for xml:base [on Cameron McCormack - due 2015-02-19].
01:01:31 <krit> ed: I want to drop xml:line in favor for HTML line
01:01:43 <krit> heycam: we discussed in Swiss
01:01:57 <krit> heycam: lets remove it
01:02:28 <krit> RESOLUTION: Remove xml:lang in favor for HMTL lang
01:02:37 <krit> ACTION: ed Remove xml:lang in favor for HMTL lang
01:02:38 <trackbot> Created ACTION-3712 - Remove xml:lang in favor for hmtl lang [on Erik Dahlström - due 2015-02-19].
01:02:48 <krit> ACTION: ed Write tests and come back to the SVG for xml:base
01:02:49 <trackbot> Created ACTION-3713 - Write tests and come back to the svg for xml:base [on Erik Dahlström - due 2015-02-19].
01:03:08 <krit> ed: define xml:space and space
01:03:25 <krit> s/Swiss/Switzerland/
01:03:39 <ed> s/and space/in terms of the white-space property/
01:04:07 <krit> heycam: elika agreed to add to CSS3 Text a value for whitespace with the same behavior as xml:space=preserve
01:04:37 <krit> heycam: we should do all the mapping to whitespace property
01:05:12 <krit> REOSOLUTION: Map xml:space to whitespace property values in CSS3 Text
01:05:22 <krit> RESOLUTION: Map xml:space to whitespace property values in CSS3 Text
01:06:05 <krit> ACTION: ed Map xml:space to whitespace property values in CSS3 Text
01:06:05 <trackbot> Created ACTION-3714 - Map xml:space to whitespace property values in css3 text [on Erik Dahlström - due 2015-02-19].
01:06:35 <heycam> Scribe: Cameron
01:06:40 <heycam> ScribeNick: heycam
01:06:50 <heycam> Topic:  Proposal: drop the SVGPathSeg* interfaces and related methods/attributes
01:07:08 <ed> https://www.chromestatus.com/metrics/feature/timeline/popularity/568
01:07:14 <heycam> ed: I added a use counter for any use of the SVGPathSeg* interfaces
01:07:18 <heycam> ... any thing that creates or uses those objects
01:07:26 <heycam> ... it's currently 0
01:07:33 <heycam> ... I'm proposing we just drop those
01:07:42 <heycam> Tav: sure it's not a bug in the use counter?
01:07:52 <heycam> krit: it's interesting
01:08:21 <heycam> ed: people typically just build path strings
01:08:26 <heycam> ... the DOM interfaces are so verbose
01:08:39 <heycam> ... I don't know if we want to consider adding a new lightweight interface for manipulating path data
01:09:25 <heycam> dmitry: I remember when trying to use this interface internally in Snap I ended up just using the string
01:09:30 <heycam> ... there was a reason why, don't remember what it was
01:09:35 <heycam> ... something was missing on the API
01:09:48 <heycam> ed: there are other issues around it
01:09:58 <heycam> ... if we want to keep the interface, we need to add ones for the new path commands
01:10:10 <heycam> roc: sounds great
01:11:18 <heycam> shane: I'd like to consider a lightweight interface to share with CSS
01:11:22 <heycam> krit: yeah
01:11:39 <heycam> shane: because CSS is going to be defining new CSS value objects
01:12:52 <iank> iank has joined #svg
01:13:03 <heycam> krit: there's also the canvas Path object
01:15:13 <birtles> http://parapara-editor.mozlabs.jp/sandbox
01:18:22 <heycam> RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies the use counter values are correct
01:18:41 <heycam> ACTION: Erik to verify that the SVGPathSeg interface use counter values are correct and to drop the interfaces if they are
01:18:42 <trackbot> Created ACTION-3715 - Verify that the svgpathseg interface use counter values are correct and to drop the interfaces if they are [on Erik Dahlström - due 2015-02-19].
01:19:31 <heycam> Topic: camelcased attributes
01:19:33 <heycam> https://lists.w3.org/Archives/Public/www-svg/2015Feb/0024.html
01:19:50 <heycam> ed: I went over the attribute appendix
01:19:58 <heycam> ... looking for new attributes we added to SVG 2 that are camelcased
01:20:00 <heycam> ... I found a couple
01:20:09 <heycam> ... first are canvasWidth/canvasHeight/frameWidth/etc.
01:20:14 <heycam> ... they already have an open issue in the spec
01:20:21 <heycam> ... I think we should rename them to width/height or just make them lowercase
01:21:07 <heycam> heycam: I think for canvas we should do it like HTML, with width/height attributes giving backing store size and width/height properties for the visual size
01:21:21 <heycam> ... the other ones (frameWidth etc.) should just be dropped
01:21:34 <heycam> ... as we'll just keep the same attribute that are allowed on the HTML elements
01:22:21 <heycam> ... this is already covered by the previous resolution
01:22:36 <heycam> ed: meshGradient has gradientTransform, let's just make it transform
01:22:41 <heycam> ... also meshGradient just got renamed to mesh
01:23:34 <heycam> nikos: this would affect things when you use the mesh as a paint server
01:23:40 <heycam> ... gradientTransform is different from transform
01:23:57 <heycam> krit: we can still make them the same thing, transform
01:24:54 <heycam> ... also the other gradients use the transform property for this
01:25:07 <heycam> RESOLUTION: gradientTransform on mesh is renamed to transform
01:25:15 <heycam> ed: next is hatchContentUnits
01:25:18 <heycam> ... I propose to keep it as is
01:25:29 <heycam> ... to match the other paint server Units attributes
01:25:36 <heycam> ... same for hatchUnits as well
01:26:50 <heycam> TabAtkins: we could switch to units="" and contentunits=""
01:27:09 <shepazu> shepazu has joined #svg
01:27:53 <heycam> heycam: will they be used commonly on hatches?
01:27:54 <heycam> Tav: yes
01:28:20 <heycam> RESOLUTION: keep current namign of hatchUnits and hatchContentUnits
01:28:34 <heycam> ed: next, hatch has hatchTransform
01:28:41 <heycam> ... we should make that transform
01:28:44 <heycam> Tav: yep
01:28:56 <heycam> RESOLUTION: rename hatchTransform to transform
01:29:03 <heycam> ed: next is playbackOrder on <svg>
01:29:18 <heycam> ... I propose that we make it lowercase
01:29:22 <heycam> ... either with a dash between or not
01:29:28 <heycam> krit: I agree to check with web animations first
01:29:32 <heycam> ... would be good to use the same keyword values
01:29:54 <ed> https://svgwg.org/svg2-draft/struct.html#SVGElementPlaybackOrderAttribute
01:30:18 <heycam> birtles: I don't have any intention of adding that to web animations currently
01:30:39 <heycam> ... I prefer we don't add new animation features to SVG 2
01:30:48 <heycam> krit: I don't like that we have it in SVG
01:31:00 <heycam> birtles: but that other spec doesn't exist yet [SVG Animation Elements spec]
01:31:29 <heycam> birtles: playbackOrder, discard, timelineBegin; I would kind of prefer to stick them in a different spec, which describes SVG's animation features in terms of web animations
01:31:34 <heycam> cyril: I would agree, but it doesn't exist
01:31:55 <heycam> birtles: I don't know how important it is to have them in SVG 2
01:32:08 <heycam> cyril: the discard element is pretty independent
01:32:20 <heycam> ed: the timelineBegin thing, is that something that would be supported in web animations?
01:32:25 <heycam> ... beacuse that's a common feature request
01:32:26 <heycam> birtles: yes
01:32:33 <heycam> ed: people want to start animations while the document is loading
01:32:37 <heycam> ... for animated spinners etc.
01:32:43 <heycam> birtles: so there's no compatibility issue there
01:32:47 <heycam> ... but there's no keyword you could borrow there either
01:32:57 <heycam> ed: but you could define it so that it starts the timeline right away
01:33:01 <heycam> birtles: that always happens
01:33:11 <heycam> ... it'd be just defining a dependent timeline to handle those two modes
01:33:17 <heycam> cyril: playbackOrder is a hint
01:33:22 <heycam> ... it's not that important
01:33:27 <heycam> krit: timelineBegin?
01:33:29 <heycam> cyril: that's improtant
01:33:33 <heycam> ... and it maps to web animations
01:33:40 <heycam> birtles: do whatever you like with attribute names
01:33:48 <heycam> ... it doesn't have names to match up with web animations
01:33:55 <heycam> krit: I'm fine with lowercasing
01:34:04 <heycam> ... onLoad and onStart are not good keywords though
01:34:09 <heycam> ed: they're very unspecific
01:34:12 <heycam> cyril: that could be changed
01:34:21 <heycam> ed: I'd like something that maps to event names
01:34:32 <heycam> cyril: I think they were originally designed to map to SAX names
01:34:38 <heycam> ed: but definitely let's not camelcase them
01:36:44 <heycam> heycam: how about just lowercase the names for now and see if anyone has better keyword ideas
01:36:47 <heycam> ed: ok
01:37:07 <heycam> RESOLUTION: timelineBegin attribute name and keywords are lowercased
01:37:22 <heycam> RESOLUTION: playbackOrder becomes playbackorder
01:38:09 <heycam> ACTION: Erik to do the attribute lowercasing
01:38:10 <trackbot> Created ACTION-3716 - Do the attribute lowercasing [on Erik Dahlström - due 2015-02-19].
01:38:16 <heycam> -- lunch break --
01:44:31 <shepazu> shepazu has joined #svg
02:05:59 <stakagi> stakagi has joined #svg
02:07:04 <AmeliaBR> AmeliaBR has joined #svg
02:15:27 <jun> jun has joined #svg
02:27:38 <jun> jun has joined #svg
02:31:25 <shane> ScribeNick: shane
02:32:15 <shane> Topic: Open issues that require discussion
02:33:02 <shane> heycam: let's start with introduction chapter. Cyril - were there things in the introduction that need discussion?
02:33:05 <shane> cyril: not really
02:33:29 <shane> cyril: I looked at 1.1. Not entirely sure HTML5 needs to be mentioned given that it's in 1.4
02:33:38 <shane> cyril: I edited 1.2 to remove mention of Macintosh file types
02:33:44 <shane> cyril: old, not needed any more
02:34:12 <shane> ... 1.4 was edited to reduce size. Didn't touch 1.5. 1.6: Moving terms & definitions to the chapter that first uses them.
02:34:25 <shane> ... will continue doing that. A few commits not pushed yet. Doesn't need more work.
02:34:26 <jun> jun has joined #svg
02:34:40 <shane> ed: do we really want to say that XVG is a language for describing 2D graphics _in XML_?
02:34:49 <shane> cyril: XML or other languages?
02:34:58 <shane> krit: markup?
02:35:04 <shane> cyril: SVG _is_ XML, right?
02:35:06 <shane> ed: sometimes
02:35:15 <shane> cyril: maybe can say that it can be integrated with a looser syntax?
02:35:30 <shane> ... or just want to say it's a language for describing 2D graphics.
02:35:36 <shane> krit, ed: a markup language
02:35:55 <shane> heycam: the issues all seem like small tweaks
02:36:14 <shane> cyril: ISSUE 2: should we mention .svg.gz?
02:36:33 <shane> various: no, yes, maybe
02:36:37 <shane> consensus: yes
02:37:13 <shane> BogdanBrinza_: do we all agree that we want to move forwards to publication?
02:37:24 <shane> cyril: no objection
02:37:38 <shane> heycam: are you saying we should be a bit ruthless to get to that point?
02:37:49 <shane> ... should see if there are any issues that really need to be solved
02:37:59 <shepazu> (SVG in HTML is not XML, and that is the biggest use of SVG at this point
02:38:10 <shepazu> s/ at this point/ at this point)/
02:38:21 <shane> cyril: would like confirmation that it's OK to move the definitions
02:38:30 <shane> heycam: I like the idea of that. Don't like massive list of definitions
02:38:36 <shepazu> why not call it markup and leave it at that?
02:38:38 <shane> ed: I think it makes sense
02:38:59 <shane> ACTION: Cyril don't stop
02:38:59 <trackbot> Created ACTION-3717 - Don't stop [on Cyril Concolato - due 2015-02-19].
02:39:27 <shane> (correction - we won't mention .svg.gz)
02:39:34 <heycam> shepazu, I think calling it "markup" is fine
02:39:50 <shane> cyril: when I see duplicate definitions I merge and raise if there's a problem.
02:39:57 <shane> ... e.g. bounding box
02:40:29 <shane> ed: different definitions of whitespace in animations and elsewhere. Fixed though.
02:40:44 <shane> ... moving to CSS fixes it
02:41:01 <shane> krit: chapter 2
02:41:08 <shane> ... I did some cleanup but I don't remember what
02:41:32 <shane> cyril: should move towards whole page in white and unclear areas in red
02:41:47 <shane> heycam: bit of work to make that change.
02:41:57 <shane> krit: isn't just stylesheet. Also requires markup changes
02:42:05 <shane> heycam: Who's editing this chapter?
02:42:22 <shane> nikos: done a fair few but not for a while. Not much here.
02:42:38 <shane> ed: some important definitions in this chapter, but would be OK to merge into a different chapter.
02:42:45 <shane> cyril: be careful, some definitions will move into this
02:43:05 <shane> heycam: wanted this chapter to be strict definition of how to paint an SVG subtree. Want references to CSS stacking order etc.
02:43:40 <shane>  nikos: makes sense. At the moment only references SVG things, so seems a bit redundant. With external references it makes sense to capture all that in one place.
02:43:54 <shane> heycam: want to rework this chapter to do that then?
02:43:56 <shane> nikos: yes.
02:44:13 <shane> heycam: probably the right place to mention clip paths, masks, filters, blending
02:44:44 <shane> ACTION: nikos to rework chapter 2 and incorporate references to external specifications
02:44:44 <trackbot> Created ACTION-3718 - Rework chapter 2 and incorporate references to external specifications [on Nikos Andronikos - due 2015-02-19].
02:45:00 <shane> ed: want to mention knockout?
02:45:07 <shane> Tav: what's knockout?
02:45:17 <shane> nikos: compositing mode. Removed from spec
02:45:31 <shane> ... still a description but no controls
02:45:46 <shane> heycam: I was going to add z-index
02:45:54 <shane> krit: I will do clipping, masking and filters
02:46:00 <shane> nikos: I don't mind having a first go at it
02:46:20 <shane> ... probably best if I do it all as a first pass then we can clean it up
02:46:37 <shane> ... is z-index mentioned anywhere else in SVG2 atm?
02:47:01 <shane> krit: how elements are rendered (2.5) - does this require mention of blending?
02:47:08 <shane> ... seems we should merge 2.5 into 2.7-2.9
02:47:31 <shane> ACTION: nikos to merge 2.5 into 2.7-2.9
02:47:31 <trackbot> Created ACTION-3719 - Merge 2.5 into 2.7-2.9 [on Nikos Andronikos - due 2015-02-19].
02:48:18 <shane> krit: we want to remove the section about clipping, masking and filtering, but some of it needs to move to other sections. e.g. overflow
02:48:30 <shane> ... changed behaviour to be more like CSS. Do we need to describe it?
02:48:45 <shane> ... visible by default. Some browsers already do this.
02:49:35 <shane> heycam: clipping and masking should still be referenced here.
02:49:50 <shane> krit, nikos: yeah, clipping and masking chapter should be merged into this.
02:50:03 <shane> Tav: would like an example of each in this spec
02:50:17 <shane> ... so people can see what it's like without looking at the linked spec
02:50:21 <shane> krit, nikos: disagree
02:50:44 <shane> nikos: lot's of issues on overflow
02:50:51 <shane> s/lot's/lots/
02:51:00 <shane> heycam: Chapter 3
02:51:07 <shane> ... I've been touching this most recently
02:51:20 <shane> ... attribute syntax summary, discussed that
02:51:35 <shane> ... Issue 1 is resolved.
02:51:46 <shane> krit: issue 2 (reference discussion about lacuna values)
02:51:57 <shane> ed: also need to go through spec to check we have lacuna values for everything
02:52:15 <shane> ACTION: heycam to resolve issue 2 in Chapter 3
02:52:16 <trackbot> Created ACTION-3720 - Resolve issue 2 in chapter 3 [on Cameron McCormack - due 2015-02-19].
02:52:30 <shane> krit Issue 3: wat?
02:52:47 <shane> heycam: needs some general wording about ???
02:52:52 <shane> krit
02:52:56 <shane> krit: Issue 4
02:53:05 <heycam> general wording about reflecting attributes
02:53:08 <shane> ... blink removed this already (classname)
02:53:13 <shane> ... didn't blink remove it already?
02:53:15 <shane> ed: don't think so
02:53:39 <shane> krit: do we want to remove this, or deprecate it?
02:53:49 <shane> ed: recommend classlist, don't know if we want to deprecate.
02:53:55 <shane> krit: I want to get rid of it.
02:53:59 <shane> heycam: me too
02:54:07 <shane> ... have we already added a use counter for this?
02:54:32 <shane> ed: it's 0.32%.
02:54:46 <shane> krit: this might just be checking for SVG
02:54:54 <shane> ... seen it used for this.
02:55:02 <shane> ... so we just deprecate?
02:55:09 <shane> heycam: let's do that
02:55:35 <shane> ACTION: heycam to mark classname as deprecated (issue 4 in chapter 3)
02:55:36 <trackbot> Created ACTION-3721 - Mark classname as deprecated (issue 4 in chapter 3) [on Cameron McCormack - due 2015-02-19].
02:55:52 <shane> krit: Issue 5. Should just reference HTML
02:56:01 <shane> heycam: yeah, just need to clean up the wording
02:56:07 <shane> krit: HTML5 or live spec?
02:56:15 <shane> heycam: whatever the W3C people make us do
02:56:35 <shane> ed: need some definition on what focus means. So need to reference one.
02:57:14 <jun> jun has joined #svg
02:57:44 <shane> heycam: Interface SVGLength. This is a long standing issue.
02:58:13 <shane> ... SVGLength objects can convert between different units, one of which is percentages based on viewport size. If that's 0, what does it mean to convert a non-zero length to a percentage?
02:58:27 <shane> TabAtkins: whelp, it's infinity
02:58:44 <shane> heycam: just decide on some behaviour. Either 0, or throw exception, something
02:58:51 <shane> TabAtkins: or NaN
02:59:01 <shane> shane: NaN isn't right
02:59:21 <shane> heycam: don't really want to use NaN or infinity
02:59:30 <shane> shane: I think exception because you can't really use the values anyway
03:00:06 <shane> heycam: so throw exception if converting into % units in this case?
03:00:51 <shane> ACTION: Heycam to specify that convertToSpecifiedUnits should throw an exception if converting to percentage with 0-sized viewport.
03:00:51 <trackbot> Created ACTION-3722 - Specify that converttospecifiedunits should throw an exception if converting to percentage with 0-sized viewport. [on Cameron McCormack - due 2015-02-19].
03:01:17 <shane> krit: accessors for ch, rem, vw, vh, vmin, vmax
03:01:39 <shane> heycam: this is related to the slight DOM improvements we made, so you can do things like circle.cx.px (but also for new CSS units)
03:01:52 <shane> ... if we reference CSS3 Values then there are more units. Should add accessors for those too.
03:02:06 <shane> shane: CSS is going to be doing this anyway.
03:02:14 <shane> krit: right, plus if you have to use animVal...
03:02:23 <shane> heycam: but you don't need to use animVal
03:03:19 <shane> shane: given there will be a spec that gives nice access to these, shouldn't add them
03:03:24 <shane> heycam: so what should we do?
03:03:38 <shane> TabAtkins/krit: remove them for now, ask CSS to prioritize
03:03:42 <shane> TabAtkins: actually it's TC39
03:04:06 <shane> RESOLVED: remove unit accessors on SVGAnimatedLength
03:04:22 <shane> RESOLUTION: remove unit accessors on SVGAnimatedLength
03:05:05 <shane> heycam: issue 11 is whether to add string accessor. Skip that too?
03:05:19 <shane> krit: especially because most of these length values are CSS properties now
03:05:44 <shane> heycam: hopefully people start to implement stuff in the CSSOM to make it easier to get at this stuff without using getComputedStyle()
03:07:25 <shane> heycam: next issue (SVGGraphicsElement) - need wording to say that transform now looks up something to do with the property
03:07:29 <shane> ed: what do you mean?
03:07:49 <shane> krit: transform now stored in CSS so no DOM access. Need to reflect SVGAnimatedTransformList somehow.
03:08:14 <shane> heycam: discussed this years ago.
03:09:10 <shane> ... transform's baseVal should reflect the presentation attribute for transform, and the animVal (if we can't lose it) should reflect the computed value of the transform property on the element
03:09:23 <shane> krit: should put this in the presentation attribute section
03:09:45 <shane> ACTION: heycam to put this in the presentation attribute section
03:09:46 <trackbot> Created ACTION-3723 - Put this in the presentation attribute section [on Cameron McCormack - due 2015-02-19].
03:10:00 <shane> krit: why deprecate nearestViewportElement?
03:10:11 <shane> ed: both nearest and furthest show very little usage
03:10:20 <shane> krit: is the peak on the graph an error? Seems strange
03:10:26 <shane> ... doesn't fit.
03:10:31 <shane> ed: I've never seen this used.
03:10:35 <shane> heycam: let's nuke it
03:10:49 <shane> krit: could be useful for the video element?
03:10:58 <shane> ed: pretty simple to walk up and get the element you're interested in
03:11:19 <shane> RESOLUTION: remove  nearestViewportElement and farthestViewportElement
03:12:19 <shane> krit: next issue is difficult (call getCTM on an 'svg' element).
03:12:37 <shane> ... svg element has scale and translate (currentTranslate, currentScale). How does that get reflected in getCTM?
03:12:50 <shane> ed: resolved inside outside thing
03:13:21 <shane> ... I think the example linked from there shows different results in different browsers
03:13:30 <shane> krit: then just pick the one that makes the most sense
03:14:03 <shane> ed: example doesn't use currentScale. Different results even with transform and viewport
03:14:08 <shane> heycam: needs more testing offline
03:14:30 <shane> ACTION: krit to do testing around currentScale, CTM, transform, viewport, etc. on 'svg' element
03:14:30 <trackbot> Created ACTION-3724 - Do testing around currentscale, ctm, transform, viewport, etc. on 'svg' element [on Dirk Schulze - due 2015-02-19].
03:14:57 <shane> heycam: getTransformToElement. Was wondering what happens if one element is in an iframe?
03:15:04 <shane> heycam: getGeometry does this
03:15:15 <shane> s/heycam/roc/
03:15:20 <shane> roc: does anyone use this?
03:15:22 <shane> ed: nah
03:15:59 <shane> roc: why don't we move this to geometry utils and do it for all elements?
03:16:15 <shane> heycam: who owns that spec?
03:16:17 <shane> roc: Simon
03:16:28 <shane> heycam: People will want this with HTML anyway.
03:16:32 <shane> roc: it's actually a pain to use.
03:16:44 <shane> ... we have conversion methods. More convenient than getting the matrix.
03:16:47 <shane> ... so what's this used for?
03:16:56 <shane> ... whatever it is, it's probably good for HTML as well.
03:17:03 <shane> heycam: converting points, e.g. from events
03:17:10 <shane> roc: we actually have better methods
03:17:17 <shane> ed: move elements around in the DOM tree
03:17:29 <shane> roc: geometryUtils has more convenient methods for that too
03:17:45 <shane> ... so maybe see if it's being used, and remove it if not. If it's used, see if the usage makes sense then move.
03:18:03 <shane> krit: for SVG 2 we'll leave it in for now. Can deprecate it.
03:18:13 <shane> ed: will measure it. Can leave it in but with issue.
03:18:23 <shane> roc: who implements this?
03:18:38 <shane> ...oh. we do. Damn
03:19:17 <shane> ACTION: ed to measure usage
03:19:18 <trackbot> Created ACTION-3725 - Measure usage [on Erik Dahlström - due 2015-02-19].
03:19:24 <gregwhitworth> gregwhitworth has joined #svg
03:19:42 <shane> krit: that doesn't solve the issue
03:19:47 <shane> heycam: true, if we decide to keep it
03:19:59 <shane> ... a minimal thing is to test what impls are doing and spec that for now.
03:20:56 <shane> heycam: so we'll just update definition to fragment and move to GeometryUtils later, if we can't drop it.
03:21:13 <shane> heycam: hasExtension.
03:21:50 <shane> ed: Gecko and WebKit check for XHTML, MathML. Blink always returns false.
03:21:58 <shane> krit: according to discussion on WhatWG
03:22:06 <shane> heycam: related to hasFeature which is what was discussed
03:22:10 <shane> ed: not sure it's very useful
03:22:19 <shane> heycam: I'd be surprised if people are calling this function
03:22:27 <shane> krit: let's just return false.
03:22:31 <shane> heycam: or remove it?
03:22:39 <shane> ... don't think anyone is using it.
03:23:17 <shane> RESOLUTION: remove hasExtension
03:23:54 <shane> CHAPTER 4
03:24:22 <shane> heycam: this is ed's chapter
03:24:36 <shane> ed: first issue, namespaces in XML. Do we need all of it?
03:24:54 <shane> heycam: should have some wording about syntax. Should there be such a big focus on embedding in foreign XML namespaces?
03:25:04 <shane> ed: not sure what to put there, but maybe more about HTML?
03:26:03 <shane> ed: issue 2. Value column doesn't match new attribute syntax
03:26:09 <shane> heycam: need to figure out consistent formatting
03:26:15 <shane> ... across the spec
03:26:45 <shane> ed: next. When zero is used on an outer 'svg' element, does this disable rendering? (for width, height)
03:26:58 <shane> heycam: good question.
03:27:18 <shane> ed: doesn't disable rendering. Overflow could be rendered.
03:27:32 <shane> heycam: is that only if you don't have a viewbox?
03:27:37 <shane> ed: good question.
03:27:47 <shane> krit: probably a special case.
03:28:25 <shane> ed: currently says it disables rendering. Not a change from 1.1. Let's keep it this way.
03:28:32 <shane> heycam: consistent with rectangles and other things
03:28:54 <shane> ... question before: if you've got borders or backgrounds on the outer SVG, do they keep rendering?
03:29:06 <shane> ... probably should keep rendering the box stuff and the content is disabled.
03:29:36 <shane> ... maybe just add a note saying that the boxy stuff still renders
03:29:52 <shane> krit: one issue, it's not the specified value but the computed value that counts.
03:30:22 <shane> heycam: what happens in CSS if you have a 0 width box, and box-sizing that lets the borders appear outside?
03:30:42 <shane> ... if you set the width of a box to 0 can things still render?
03:30:48 <shane> TabAtkins: yup
03:31:05 <shane> ... box sizing still floors out at 0, so even if borders are internal they still render.
03:32:05 <shane> ed: issue 4 is a bout playbackOrder. Already decided to make it lowercase. How can we harmonize with Web Animations
03:32:18 <shane> krit: this is the one we could defer to L3, right?
03:33:31 <shane> shane: would like to talk about this with Brian as we have a similar problem in WA (talked about it yesterday)
03:33:43 <shane> krit: if we defer then you have time to figure a solution out.
03:34:37 <shane> ed: next issue, can we define seeking backwards so that there is no undefined behaviour?
03:36:08 <shane> shane: if we can figure out playbackOrder as part of Web Animations then there won't be undefined behaviour.
03:36:12 <shane> ed: can just link to it from here then.
03:36:31 <shane> ed: next issue already resolved.
03:36:54 <shane> ed: next, timelineBegin. Resolved on this. Should just link to Web Aniamtions.
03:36:59 <shane> s/Aniamtions/Animations/
03:37:23 <shane> ed: next. What about when SVG fragment is within an XHTML document? Is there a single timeline for the whole document? When does it start?
03:38:16 <AmeliaBR> AmeliaBR has joined #svg
03:38:54 <heycam> RRSAgent, pointer?
03:38:54 <RRSAgent> See http://www.w3.org/2015/02/11-svg-irc#T03-38-54
03:40:17 <shane> ACTION: birtles to specify something simple and consistent for timeline start in Web Animations.
03:40:17 <trackbot> Created ACTION-3726 - Specify something simple and consistent for timeline start in web animations. [on Brian Birtles - due 2015-02-19].
03:40:31 <shane> RESOLUTION: adopt whatever Web Animations behaviour is specced and link to it from here.
03:41:05 <shane> ed: some paragraphs are out of place.
03:41:32 <shane> ... svg handles same events as body.
03:41:41 <shane> krit: doesn't seem out of place as we're talking about svg here
03:41:52 <shane> heycam: I think these should be in the interaction chapter but it isn't important
03:41:56 <shane> RESOLUTION: Leave 'em
03:42:23 <shane> ed: next issue, about accessibility
03:43:01 <shane> krit: could add a note that these will be handled by a WG note in the future.
03:43:16 <shane> heycam: what's happening with the a11y appendix? It also contains waffle language like this.
03:43:31 <shane> krit: had an external document before. Very old though.
03:44:24 <shane> ed: what should we do?
03:44:30 <shane> heycam: this paragraph is very superficial
03:44:35 <shane> krit: can we just remove the section?
03:44:50 <shane> RESOLUTION: Drop the paragraph
03:45:11 <shane> ed: next issue. Let's drop the <g> example
03:45:15 <shane> RESOLUTION: Drop the <g> example
03:46:09 <shane> heycam: next issue. Not clear what 'Any element that is not contained within a 'g' is treated as if it were in its own group' means.
03:46:20 <shane> nikos: maybe to do with blending and compositing
03:46:51 <shane> heycam: can just remove this sentence
03:47:00 <shane> nikos: any specific point can be made in rendering chapter
03:47:11 <shane> RESOLUTION: remove this sentence
03:47:29 <shane> ed: next issue, accessibility in 4.3.1
03:47:38 <shane> heycam: should remove this paragraph too.
03:47:48 <shane> s/paragraph/sentence/
03:48:33 <shane> krit: should just make it a note
03:48:36 <shane> heycam: ed can choose
03:48:46 <shane> ed: next issue. Term for definition elements?
03:48:53 <shane> heycam: things like filter, clippath, etc.
03:49:05 <shane> heycam: actually, changed it. This issue doesn't apply any more.
03:49:27 <shane> ed: next issue, in 4.3.2 (defs).
03:49:50 <shane> ... paragraph not needed
03:49:55 <shane> krit: example can go too
03:50:02 <shane> RESOLUTION: remove paragraph and example
03:50:28 <TabAtkins> ScribeNick:TabAtkins
03:50:52 <TabAtkins> ed: Issue 17, the discard element. Move that to animation chapter?
03:51:00 <TabAtkins> heycam: It's pretty animation-y to me.
03:51:02 <TabAtkins> ed: Agree.
03:51:22 <TabAtkins> cyril: Yeah, sure.
03:51:37 <TabAtkins> shane: We should be able to describe <discard> in terms of Web Anim.
03:51:46 <TabAtkins> krit: The IDL is missing for that?
03:52:06 <TabAtkins> cyril: I couldn't figure out how to do it.
03:52:17 <TabAtkins> ACTION cyril to add the IDL for <discard> and move it to animation chapter.
03:52:18 <trackbot> Created ACTION-3727 - Add the idl for <discard> and move it to animation chapter. [on Cyril Concolato - due 2015-02-19].
03:52:36 <TabAtkins> ed: Issue 19, also on the discard element
03:52:41 <tantek> tantek has joined #svg
03:52:44 <TabAtkins> ed: Something about the attribute syntax needs fixing.
03:53:01 <TabAtkins> heycam: It's the list syntax thing.  I'll fix it.
03:54:07 <TabAtkins> ed: Issue 20, I'll figure out if we need to import any text.
03:54:33 <TabAtkins> krit: Issue 21
03:54:53 <TabAtkins> heycam: There's a sentence in the paragraph about rendering <title> with a stylesheet, but I don't think it's easy, or maybe even possible.
03:55:25 <TabAtkins> RESOLVED: Drop the offending sentence about styling <title>.
03:55:30 <tantek> I for one think <title> ought to be optional.
03:55:50 <TabAtkins> ed: Issue 22, lang needs to be defined.
03:56:08 <TabAtkins> heycam: <glyph> got removed, and lang links down to xml:lang. AS part of updating xml:lang to lang, should hopefully jsut work.
03:56:15 <TabAtkins> RESOLVED: Remove issue 22.
03:57:04 <TabAtkins> RESOLUTION: Remove issue 22.
03:57:17 <TabAtkins> RESOLUTION: Drop the offending sentence about styling <title>.
03:57:31 <TabAtkins> heycam: Issue 23 is about foreign namespace content inside of <desc>. Who does that?
03:57:36 <TabAtkins> ed: I'm in favor of removing the example.
03:58:18 <TabAtkins> RESOLUTION: Remove the example about foreign-namespace content in <desc>.
03:59:04 <TabAtkins> heycam: I'll look into Issue 24.
03:59:35 <TabAtkins> ed: I guess both 24 & 25 would be described by a11y
03:59:53 <TabAtkins> ACTION ed to talk to Rich about issues 24/25 (terminology around title/desc/aria stuff)
03:59:54 <trackbot> Created ACTION-3728 - Talk to rich about issues 24/25 (terminology around title/desc/aria stuff) [on Erik Dahlström - due 2015-02-19].
04:00:29 <TabAtkins> <br dur=15m>
04:05:58 <shane> tantek: no worries, any time :)
04:19:26 <Rossen_SYD> Rossen_SYD has joined #svg
04:25:21 <heycam> Scribe: Cameron
04:25:24 <heycam> ScribeNick: heycam
04:25:31 <heycam> ed: structure chapter issue 27
04:25:56 <heycam> ... not sure what it means
04:26:00 <heycam> ... talks about templated elements
04:26:50 <heycam> heycam: it's kind of true, but maybe templates is not the best way of describing it
04:26:58 <heycam> ed: I'll figure out a way to describe it
04:27:04 <heycam> ed: issue 29
04:27:22 <heycam> s/29/28/
04:27:31 <heycam> ... defining use in terms of web components
04:27:38 <heycam> krit: I talked with pdr and dmitri
04:27:42 <heycam> ... but I forgot what they said
04:28:01 <heycam> ... maybe Tab when you're back you can talk with pdr and dmitri and figure out how to do it?
04:28:02 <heycam> TabAtkins: ok
04:28:10 <heycam> shane: has use changed?
04:28:18 <heycam> ed: we do refer to web components for event propagation
04:28:22 <heycam> krit: and web components works a bit differently
04:28:39 <heycam> shane: my naive understanding of old use is that you couldn't define it in terms of web components
04:28:48 <heycam> krit: true it's still a special case
04:28:54 <heycam> Tav: what are the differences?
04:29:00 <heycam> krit: I think at least because it's isolated
04:29:26 <heycam> TabAtkins: we've changed how web components work a bit too since this was written
04:29:54 <heycam> ed: would be nice to get someone to detailed review how to do it with web components
04:30:09 <heycam> Tav: what's the gain?
04:30:14 <heycam> TabAtkins: reducing the number of spec concepts
04:30:21 <heycam> ... use is almost a web component, but not exactly, so that's weird
04:30:30 <heycam> Tav: any change in behaviour?
04:30:37 <heycam> TabAtkins: maybe minor changes in behaviour which we'd try to minimise
04:30:49 <heycam> krit: in blink it is implemented in terms of web components
04:30:58 <heycam> TabAtkins: allt he major behaviours should be preserved
04:31:53 <heycam> ACTION: TabAtkins to talk with pdr and dmitri about how to describe <use> with web components
04:31:53 <trackbot> Created ACTION-3729 - Talk with pdr and dmitri about how to describe <use> with web components [on Tab Atkins Jr. - due 2015-02-19].
04:32:09 <heycam> ed: next, issue 29
04:32:36 <heycam> ... does display prevent shadow trees from being created?
04:32:37 <heycam> TabAtkins: no
04:32:43 <heycam> ... it'll just prevent layout/rendering
04:32:46 <heycam> ... but shadow tree is a dom concept
04:33:18 <heycam> ... depending on exactly how we define stuff, script will not run in instances?
04:34:09 <heycam> ed: agree script doesn't run in instances?
04:34:09 <heycam> heycam: yes
04:34:11 <heycam> TabAtkins: yes
04:34:19 <heycam> ed: what about audio elements?
04:34:22 <heycam> TabAtkins: they should run just fine
04:34:28 <heycam> ... in the <template> based approach, they're inactive in there
04:34:38 <heycam> ... <use> doesn't do that, since you're pointing to an arbitrary element
04:34:43 <heycam> ... but yes once stamped out they wil run
04:34:45 <heycam> s/wil/will/
04:34:55 <heycam> ed: issue 33
04:35:01 <heycam> "How should @media rules work when an external resource is referenced?"
04:35:20 <heycam> ed: I don't think SVG is clear whether there is a defined viewport when you reference something external
04:35:28 <heycam> ... some CSS things depend on having a window/size
04:35:32 <heycam> TabAtkins: what's an example?
04:35:38 <heycam> ed: the <img> element pointing to something?
04:35:43 <heycam> s/ed/TabAtkins/
04:35:48 <heycam> ed: no, <use> pointing to something external
04:36:36 <heycam> ed: we load the external document in something that's not a frame
04:36:40 <heycam> ... so some style stuff would crash on that
04:36:46 <heycam> ... we should say how that works
04:36:55 <heycam> roc: I think the logical thing is to treat it as a display none iframe
04:37:00 <heycam> ... I hope that's what we do
04:37:17 <krit> scribeNick: krit
04:37:33 <krit> ed: can we resolve on roc's proposal?
04:38:51 <krit> krit: does it follow the rules of the dimension of an iframe if there is no intrinsic size or intrinsic ratio
04:39:08 <krit> roc: we need to define it
04:39:48 <krit> krit: think we should explicitly define a default intrinsic size if there is none
04:39:59 <krit> roc: we just need to define something
04:40:40 <krit> ACTION: ed Define viewport for external document when an element references an element in this document
04:40:41 <trackbot> Created ACTION-3730 - Define viewport for external document when an element references an element in this document [on Erik Dahlström - due 2015-02-19].
04:41:21 <krit> krit: it does also effect other elements like paint servers that reference external paint servers
04:41:36 <krit> ed: we should define it in a special section then. Loading maybe.
04:42:05 <krit> ed: animation in external resources should they run?
04:42:35 <krit> roc: we do run animations
04:42:53 <krit> roc: you want a model for external resources that we want to use for images
04:43:13 <krit> roc: images support animations so should external resources with the same rules
04:44:20 <krit> BogdanBrinza_: if scripts get images with external resources is that a problem?
04:44:28 <krit> roc: an image can not load other resources
04:45:14 <krit> roc: I think there is a strong requirement to do what external images with animations do
04:45:49 <krit> RESOLUTION: Animations in external resources should run
04:46:33 <krit> ed: next: should switch elements effect if a child element applies?
04:46:49 <krit> ed: you don't can't toggle style with a switch element
04:47:00 <krit> RESOLUTION: switch does not effect style
04:47:22 <krit> ed: next: does it make sense to implement view CSS and document CSS?
04:47:32 <krit> ed: they should I think
04:48:14 <krit> RESOLUTION: ViewCSS should be on window and DocumentCSS on document
04:48:22 <krit> TabAtkins: it is already defined on window
04:48:32 <krit> ed: we should remove the sentence in SVG
04:49:16 <krit> RESOLUTION: Remove ViewCSS and DocumentCSS
04:49:46 <krit> ed: next: pixelUnitsToPx/Em....
04:50:13 <krit> ed: they are useless and we should remove them
04:50:16 <krit> heycam: agree
04:50:32 <krit> RESOLUTION: Remove pixelUnitTo....
04:51:09 <krit> ed: next: pauseNaimations and onPauseAnimations do they use WebAnimations
04:51:16 <krit> ed: do they apply to web animations?
04:51:19 <krit> birtles: they don't
04:51:27 <krit> ed: should we deprecte them?
04:51:34 <krit> birtles: they are useful
04:52:05 <krit> ACTION: birtles pauseNaimations and onPauseAnimations do not effect CSS animations
04:52:05 <trackbot> Created ACTION-3731 - Pausenaimations and onpauseanimations do not effect css animations [on Brian Birtles - due 2015-02-19].
04:52:23 <krit> ed: next: getElementById
04:52:38 <krit> ed: we should remove it
04:52:41 <krit> heycam: agree
04:52:57 <krit> RESOLUTION: Remove getElementById on SVGSVGElement
04:53:29 <krit> topic: chapter styling
04:53:55 <krit> heycam: presentaion attributes on every property we explicitly support?
04:54:29 <krit> heycam: they were maybe a bad decision in the first place but it would be confusing if some exist and some don't?
04:55:20 <krit> roc: the confusion exists but it is not practical to solve it for every property
04:55:29 <krit> heycam: in SVG it is general coding style
04:55:57 <krit> krit: I would be careful with adding more presentation attributes
04:56:25 <krit> ed: I agree it comes with a cost
04:56:34 <krit> heycam: go back to the set of SVG 1.1 then?
04:56:46 <krit> krit: we added more already. Like transform-origin
04:57:03 <krit> ed: we should do it by case by case basis
04:57:30 <krit> heycam: then we should have a list in the spec
04:57:41 <krit> heycam: we have a blue table with these attributes
04:59:35 <krit> krit: we should update the table with the new presentation attributes like x, y, width and height
04:59:39 <krit> heycam: and paint-order
05:00:56 <krit> heycam: I will come up with a new set of all properties
05:01:19 <krit> ACTION: heycam update presentation property table
05:01:19 <trackbot> Created ACTION-3732 - Update presentation property table [on Cameron McCormack - due 2015-02-19].
05:01:58 <heycam> https://svgwg.org/svg2-draft/styling.html#UAStyleSheet
05:02:01 <krit> heycam: next: UA style sheet (section 5.14)
05:02:20 <krit> heycam: this is the overflow hidden thing
05:02:33 <krit> heycam: the svg root part should disappear
05:02:38 <krit> heycam: same for image
05:04:11 <krit> ed: the overflow for pattern is explicitly undefined since SVG 1.1SE
05:04:20 <krit> heycam: so we can remove this problem
05:05:08 <krit> TabAtkins: if we remove it, you run into visible all the time while now you run into it by accident
05:05:25 <TabAtkins> s/TabAtkins/Tav/
05:07:00 <krit> heycam: ok, can you apply a clip-path on a pattern? It is kind of a similar thing as applying overflow on the pattern
05:08:03 <krit> Tav: can we make the overflow visible to default?
05:08:23 <krit> krit: then we can not explicitly allow it in the future with defined behavior. So we should keep hidden
05:08:27 <krit> heycam: I agree
05:08:50 <krit> RESOLUTION: first rule on UA style: remove svg and image
05:09:31 <krit> RESOLUTION: remove 2nd rule on UA style since width and height are presentation attributed
05:09:49 <krit> s/attributed/attributes/
05:10:18 <heycam> Scribe: cameron
05:10:21 <heycam> ScribeNick: heycam
05:10:26 <heycam> roc: style, script, symbol { display: none; }
05:11:10 <heycam> ... you could override that to display:inline?
05:12:00 <heycam> heycam: what about defs?
05:12:08 <heycam> roc: related to referring to display:none things
05:12:12 <heycam> ... that's an issue to discuss later
05:12:20 <heycam> roc: next is transform-origin
05:12:32 <heycam> ... a non-outermost-<svg> element has transform-origin: top left
05:12:55 <krit> https://www.irccloud.com/pastebin/pnDoiyiy
05:13:33 <heycam> *:not(svg),
05:13:33 <heycam> *:not(foreignObject) > svg {
05:13:33 <heycam>   transform-origin:0 0;
05:13:33 <heycam> }
05:14:54 <heycam> roc: it's slightly different from the WebKit rule
05:15:24 <heycam> krit: for foreignObject you would have to put an html child
05:15:31 <heycam> roc: you don't have, you could have an <svg> child of <foreignObject>
05:15:56 <heycam> krit: do we need to define this part?
05:16:01 <heycam> ... we have some more rules too
05:16:34 <heycam> we have svg:root { width: 100%; height: 100%; }
05:16:41 <heycam> s/we have/... we have/
05:16:53 <heycam> ... this might be because we have width/height being a presentation attribute
05:17:15 <heycam> ... in Gecko, you can set width/height attributes differently from width/height properties
05:17:18 <heycam> ... or is that not true any more
05:17:24 <heycam> roc: we don't have width/height reflected into CSS
05:17:26 <heycam> krit: we do
05:17:45 <heycam> roc: so for the root element you need to override those so that the root element is displayed across the entire viewport
05:17:47 <heycam> ... ok
05:18:55 <krit> https://www.irccloud.com/pastebin/tpiC8eFU
05:19:32 <heycam> krit: so this makes inner <svg> overflow:hidden
05:19:45 <heycam> roc: we also have a rule that is specific to SVG used in a font
05:22:17 <heycam> http://mcc.id.au/temp/overflow.svg
05:22:25 <heycam> if you see a quarter circle, then overflow:hidden is set for inner svg
05:26:30 <heycam> RESOLUTION: svg:not(:root) { overflow: hidden; } goes in the UA style sheet
05:28:58 <jdaggett_> jdaggett_ has joined #svg
05:29:01 <heycam> ACTION: Cameron to investigate whether |symbol { overflow: hidden }| UA style sheet rule is needed
05:29:01 <trackbot> Created ACTION-3733 - Investigate whether |symbol { overflow: hidden }| ua style sheet rule is needed [on Cameron McCormack - due 2015-02-19].
05:31:35 <heycam> trackbot: end telcon
05:31:35 <trackbot> Zakim, list attendees
05:31:43 <trackbot> RRSAgent, please draft minutes
05:31:43 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/11-svg-minutes.html trackbot
05:31:44 <trackbot> RRSAgent, bye
05:31:44 <RRSAgent> I see 34 open action items saved in http://www.w3.org/2015/02/11-svg-actions.rdf :
05:31:44 <RRSAgent> ACTION: ed to add usage counters to blink to measure usage of animVal / baseVal [1]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T23-02-13
05:31:44 <RRSAgent> ACTION: ed to write up a list of all new camelCase attributes with a proposal of how to handle them (e.g. rename, keep etc.) [2]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T23-22-07
05:31:44 <RRSAgent> ACTION: heycam to change embedded content chapter to allow these things from resolution: Allow HTML NSed elements audio, video, canvas, iframe in an SVG subtree as a child of a container element with the containing block being the nearest SVG viewport and blockyfied [3]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-26-28
05:31:44 <RRSAgent> ACTION: TabAtkins write the SVG layout spec [4]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-26-41
05:31:44 <RRSAgent> ACTION: TabAtkins convince Hixie to make the HMTL parser changes + x/y presentation attributes on the canvas,... elements for SVG [5]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-32-17
05:31:44 <RRSAgent> ACTION: TabAtkins Allow templates in SVG which needs HTML parser changes [6]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-33-53
05:31:44 <RRSAgent> ACTION: Cameron to investigate which HTML elements like <link> we might want to also allow in SVG [7]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-35-44
05:31:44 <RRSAgent> ACTION: Reference integration spec and update conformance class for HTML support on foreignObject [8]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-44-04
05:31:44 <RRSAgent> ACTION: heycam Reference integration spec and update conformance class for HTML support on foreignObject [9]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-44-15
05:31:44 <RRSAgent> ACTION: hey cam add stylesheet requirements to the spec [10]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-48-03
05:31:44 <RRSAgent> ACTION: heycam add stylesheet requirements to the spec [11]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-48-10
05:31:44 <RRSAgent> ACTION: ed Remove xml:base/space/lang from the SVG DOM interface [12]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T00-56-00
05:31:44 <RRSAgent> ACTION: Write tests and come back to the SVG for xml:base [13]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-00-38
05:31:44 <RRSAgent> ACTION: heycam  Write tests and come back to the SVG for xml:base [14]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-01-05
05:31:44 <RRSAgent> ACTION: ed Remove xml:lang in favor for HMTL lang [15]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-02-37
05:31:44 <RRSAgent> ACTION: ed Write tests and come back to the SVG for xml:base [16]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-02-48
05:31:44 <RRSAgent> ACTION: ed Map xml:space to whitespace property values in CSS3 Text [17]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-06-05
05:31:44 <RRSAgent> ACTION: Erik to verify that the SVGPathSeg interface use counter values are correct and to drop the interfaces if they are [18]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-18-41
05:31:44 <RRSAgent> ACTION: Erik to do the attribute lowercasing [19]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T01-38-09
05:31:44 <RRSAgent> ACTION: Cyril don't stop [20]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T02-38-59
05:31:44 <RRSAgent> ACTION: nikos to rework chapter 2 and incorporate references to external specifications [21]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T02-44-44
05:31:44 <RRSAgent> ACTION: nikos to merge 2.5 into 2.7-2.9 [22]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T02-47-31
05:31:44 <RRSAgent> ACTION: heycam to resolve issue 2 in Chapter 3 [23]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T02-52-15
05:31:44 <RRSAgent> ACTION: heycam to mark classname as deprecated (issue 4 in chapter 3) [24]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T02-55-35
05:31:44 <RRSAgent> ACTION: Heycam to specify that convertToSpecifiedUnits should throw an exception if converting to percentage with 0-sized viewport. [25]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T03-00-51
05:31:44 <RRSAgent> ACTION: heycam to put this in the presentation attribute section [26]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T03-09-45
05:31:44 <RRSAgent> ACTION: krit to do testing around currentScale, CTM, transform, viewport, etc. on 'svg' element [27]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T03-14-30
05:31:44 <RRSAgent> ACTION: ed to measure usage [28]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T03-19-17
05:31:44 <RRSAgent> ACTION: birtles to specify something simple and consistent for timeline start in Web Animations. [29]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T03-40-17
05:31:44 <RRSAgent> ACTION: TabAtkins to talk with pdr and dmitri about how to describe <use> with web components [30]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T04-31-53
05:31:44 <RRSAgent> ACTION: ed Define viewport for external document when an element references an element in this document [31]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T04-40-40
05:31:44 <RRSAgent> ACTION: birtles pauseNaimations and onPauseAnimations do not effect CSS animations [32]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T04-52-05
05:31:44 <RRSAgent> ACTION: heycam update presentation property table [33]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T05-01-19
05:31:44 <RRSAgent> ACTION: Cameron to investigate whether |symbol { overflow: hidden }| UA style sheet rule is needed [34]
05:31:44 <RRSAgent>   recorded in http://www.w3.org/2015/02/11-svg-irc#T05-29-01
05:32:15 <jun> jun has left #svg