20:28:42 <RRSAgent> RRSAgent has joined #svg
20:28:43 <RRSAgent> logging to http://www.w3.org/2014/02/20-svg-irc
20:28:45 <trackbot> RRSAgent, make logs public
20:28:45 <Zakim> Zakim has joined #svg
20:28:47 <trackbot> Zakim, this will be GA_SVGWG
20:28:47 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)3:30PM scheduled to start in 2 minutes
20:28:48 <trackbot> Meeting: SVG Working Group Teleconference
20:28:48 <trackbot> Date: 20 February 2014
20:29:12 <Zakim> GA_SVGWG(SVG1)3:30PM has now started
20:29:19 <Zakim> +[IPcaller]
20:29:21 <heycam> Zakim, [ is me
20:29:21 <Zakim> +heycam; got it
20:29:26 <heycam> Chair: Cameron
20:29:33 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0101.html
20:30:08 <Zakim> +[IPcaller]
20:30:27 <ed> Zakim, [IP is me
20:30:27 <Zakim> +ed; got it
20:30:31 <Zakim> +krit
20:30:47 <Zakim> +[IPcaller]
20:30:49 <Zakim> +??P3
20:31:00 <birtles> Zakim, [ is me
20:31:00 <Zakim> +birtles; got it
20:31:10 <nikos> nikos has joined #svg
20:31:12 <stakagi> zakim, ??P3 is me
20:31:12 <Zakim> +stakagi; got it
20:31:30 <Zakim> +??P5
20:32:06 <Zakim> +[IPcaller]
20:32:22 <cabanier_> zakim, IPcaller is me
20:32:22 <Zakim> +cabanier_; got it
20:33:40 <Zakim> +Tav
20:35:03 <birtles> scribenick: birtles
20:35:19 <birtles> topic: Update on Leipzig meeting venue
20:35:35 <birtles> krit_: I spoke with the director of the faculty of computer science
20:35:43 <birtles> ... it won't be possible to get the venue for free
20:35:49 <birtles> ... because it's not an event of the university
20:36:01 <birtles> ... I looked if there was space after the LGM meeting
20:36:16 <birtles> ... but it's not possible because classes start after that
20:36:23 <birtles> ... I checked before the meeting but no reply
20:36:41 <birtles> Tav: I checked as well
20:37:09 <birtles> krit_: there may be a response in a few days but I don't think the response will be any different
20:37:13 <birtles> ... there was another venue?
20:37:18 <birtles> Tav: some sort of hackerspace
20:37:32 <birtles> ... but I'm not sure it's suitable enough, may not be large enough
20:37:40 <birtles> heycam: do you have a name for it?
20:37:50 <birtles> krit_: I didn't check yet if there would be a hotel with a rooom
20:37:56 <Tav> http://sublab.org/raeume
20:37:58 <birtles> ... but then we'd need to rent it if there was a room
20:38:06 <birtles> s/rooom/room/
20:38:19 <birtles> Tav: it's more a place for mucking around with electronics
20:38:29 <birtles> ... doesn't look suitable from the pictures
20:38:42 <birtles> heycam: what should we do then
20:38:51 <birtles> krit_: I can check some hotels but it won't be free
20:38:57 <birtles> Tav: how much do you think?
20:39:01 <birtles> krit_: not sure
20:39:28 <birtles> ... university would be EUR100 per day
20:39:50 <birtles> heycam: that's for accommodation not meeting space?
20:40:06 <birtles> krit_: it was for the meeting space + Internet etc.
20:40:27 <birtles> heycam: that's not too bad, but if it's not available
20:40:34 <birtles> krit_: yes, it's not available after LGM
20:40:42 <birtles> nikos: what about Mozilla in Paris?
20:40:54 <birtles> heycam: yes, we have an office in Paris and a small space in Berlin
20:41:06 <birtles> ... I'm not sure how big it is but I can look into it
20:41:13 <birtles> Tav: Paris would be convenient for Cyril and I
20:41:30 <birtles> ... but the cost of moving between Leipzig and Paris greater than the cost of renting a space
20:41:40 <birtles> nikos: I'm not going to LGM so it wouldn't affect me
20:41:43 <birtles> heycam: who's going?
20:41:50 <birtles> Tav: I'm going, Chris...
20:41:53 <birtles> ed: not sure yet
20:42:11 <birtles> heycam: it might be good to hear from Chris then since we want to limit trips for him
20:42:29 <birtles> ... so it might depend if meeting in Paris counts as a second trip or not
20:43:14 <birtles> Tav: getting from Leipzig to Paris by train is a day's travel
20:43:20 <birtles> krit_: there's a non-stop flight
20:43:37 <birtles> heycam: is it worth looking into Berlin or Paris?
20:44:00 <Zakim> +Doug_Schepers
20:44:31 <birtles> krit_: I'll look into getting a hotel room in Leipzig then we can compare next week
20:44:45 <birtles> topic: Should linking.html#processingIRI allow references to elements not in the document tree?
20:44:53 <ed> https://svgwg.org/svg2-draft/linking.html#processingIRI
20:45:03 <birtles> ed: this came up in a bug report recently
20:45:33 <birtles> ... I think someone was saying it's not clear if you have a <rect> that references a gradient and that gradient is removed from the document... does that rect still have the gradient fill?
20:45:43 <birtles> ... or is it removed when the gradient is removed from the document
20:45:58 <birtles> ... the link itself might still be there since the gradient is reference
20:46:20 <birtles> krit_: is the link internal/external
20:46:27 <birtles> ed: either but I was thinking about internal
20:46:44 <birtles> heycam: what about the other way, if you start off with a gradient that is not in the document that you add an ID to and reference?
20:47:00 <shepazu> (+1 to heycam)
20:47:30 <birtles> ed: in that part of the spec, does "a node that exist" mean elements that are outside the document?
20:47:42 <birtles> ... I'm guessing it should but this should be more clear
20:47:53 <birtles> krit_: do you mean an element that is not in the DOM tree?
20:48:10 <ed> s/that exist/doesn't exist
20:48:11 <shepazu> q+
20:48:20 <birtles> ... how do you compute the style then if it is not in the DOM?
20:48:30 <birtles> ... I think that was an issue in the past
20:48:40 <ed> <rect fill="url(#foo)"> then remove the #foo element
20:48:47 <birtles> heycam: I have a feeling that specs now define the computed style for an element that is outside the tree
20:48:50 <birtles> ... it's not just a null
20:49:13 <birtles> krit_: what do implementations do? do they allow referencing elements that are outside the tree?
20:49:32 <birtles> ed: I didn't do cross-browser testing but I think it would make sense to break reference when you remove elements from the document tree
20:49:47 <birtles> krit_: so you would like elements to be valid only if they are in the DOM tree?
20:50:01 <heycam> ack shepazu
20:50:44 <birtles> shepazu: in the past SVG allowed you to reference external resources
20:50:53 <ed> and equally, when inserting a #foo element into the document, the fill=url(#foo) would magically be resolved... and if there are duplicate ids it would still be recomputed according to the normal getElementByID behavior
20:51:05 <birtles> ... but I think Mozilla didn't allow that for a long time, has that changed
20:51:18 <birtles> heycam: yes, you can do that... as long as it's not from an iframe
20:51:25 <birtles> birtles: you have been able to do that for a long time
20:51:25 <heycam> s/not from/from/
20:52:07 <birtles> shepazu: where does that document live?
20:52:52 <birtles> shepazu: but it's not available for scripting etc.
20:53:20 <birtles> ... if I were defining it today I would say it imports the external document into some resource shadow dom for resources
20:53:26 <birtles> ... so you're not relying on some external document
20:53:44 <birtles> ... but it's in a shadow document
20:53:48 <birtles> krit_: how does that help?
20:54:22 <birtles> shepazu: it unifies the behavior, it demystifies what is going on
20:54:34 <birtles> ... I think it's relevant to the conceptual idea of what is going on
20:54:55 <birtles> ... once a resource is removed from the document...
20:55:20 <birtles> krit_: there's a reason we load it in this way... for security, so there are no references from other domains
20:55:34 <birtles> shepazu: I don't think we want to change those things but just to define how those things are done
20:56:06 <birtles> ... with regards to simple document without external resources where you're referencing an internal gradient, the only gotcha is, what if that fragment is moved?
20:56:21 <birtles> ... I assume that would behave the same
20:56:54 <birtles> heycam: I suspect that things aren't define to this level of detail to know if during the small amount of time during with the element is moved would create a visible result
20:57:03 <birtles> shepazu: is it worth defining that?
20:57:05 <thorton> thorton has joined #svg
20:57:17 <birtles> heycam: I suspect that since I think UAs will repaint at the end of the script block
20:57:32 <birtles> s/I suspect that/I suspect not/
20:57:54 <birtles> heycam: so do we agree about whether the link is broken...
20:58:46 <birtles> heycam: if an element that is referenced as a gradient (and similar) is removed from the document, it is no longer able to be referenced
20:59:03 <birtles> RESOLUTION: if an element that is referenced as a gradient (and similar) is removed from the document, it is no longer able to be referenced
20:59:21 <birtles> heycam: did someone want to look into HTML imports to see if that can be re-used to define this?
20:59:30 <birtles> ... who had the action for looking into shadow dom?
20:59:39 <birtles> krit_: I had the action but I'm not sure what you mean
20:59:43 <birtles> heycam: you'll find out
21:00:09 <birtles> ed: for element insertion, can we define the same so that you re-resolve all references with some given ID?
21:00:15 <birtles> heycam: I think that's fine
21:00:27 <birtles> RESOLUTION:
21:01:34 <birtles> RESOLUTION: upon element insertion, elements with IDs become referenceable
21:02:13 <birtles> ACTION: update the spec to clarify behavior of references to elements when they are removed/added from the document
21:02:13 <trackbot> Error finding 'update'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
21:02:26 <birtles> ACTION: ed to update the spec to clarify behavior of references to elements when they are removed/added from the document
21:02:26 <trackbot> Created ACTION-3594 - Update the spec to clarify behavior of references to elements when they are removed/added from the document [on Erik Dahlström - due 2014-02-27].
21:02:50 <birtles> topic: Define if attribute values are allowed to have leading and/or trailing whitespace (ISSUE-2447)
21:03:10 <birtles> ed: I think we've discussed this previously, I was hoping we could resolve on this
21:03:12 <ed> ISSUE-2447?
21:03:12 <trackbot> ISSUE-2447 -- Define if attribute values (in particular numerical attributes) are allowed to have leading and/or trailing whitespace (e.g x=" 10" interpreted as 10 and not as an error) -- raised
21:03:12 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2447
21:03:16 <birtles> ... I had a look at what HTML5 does for this
21:03:28 <birtles> ... it seems that for numeric values leading/trailing whitespace is allowed
21:03:36 <birtles> ... for most attributes it is allowed but is stripped out
21:03:50 <birtles> ... some attributes don't allow it: enumerated values and boolean values
21:03:56 <birtles> ... but most other attributes do allow it
21:04:14 <birtles> heycam: we previously resolved that for presentation attributes we will use the CSS parser to parse the attributes
21:04:20 <birtles> ... so whitespace would be allowed in those ones
21:04:35 <birtles> ed: that's probably right but I don't think we have anything in the spec to say that
21:05:22 <birtles> ... and that wouldn't define what we do for numeric attributes
21:05:23 <ed> http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#keywords-and-enumerated-attributes
21:05:33 <birtles> shepazu: what is an example of an enumerated attribute?
21:05:46 <birtles> ... why does HTML not allow whitespace for that?
21:05:51 <birtles> ed: I don't know
21:06:03 <birtles> ... if you follow the link above you'll find lots of parsing rules
21:06:21 <birtles> shepazu: for example, wouldn't stroke-linecap be an enumerated value?
21:06:26 <birtles> ... aren't most of our values enumerated?
21:06:40 <birtles> ed: the most frequently used are numerical
21:07:03 <birtles> heycam: stroke-linejoin would be enumerated but if we've decided they are parsed with the CSS parser then whitespace would be allowed
21:07:17 <birtles> krit_: could someone find out why whitespace is not allowed in HTML?
21:07:30 <birtles> ed: one example is the "dir" (bidi) attribute
21:07:45 <birtles> shepazu: on the whole I'd rather follow what HTML does but in this case that seems overly respective
21:08:52 <birtles> krit_: but there might be a good reason for that
21:08:52 <birtles> ed: one example is the "dir" (bidi) attribute
21:09:18 <ed> http://www.w3.org/html/wg/drafts/html/master/index.html#attributes-1 - the list of html attributes and how they parse their value(s)
21:09:58 <birtles> heycam: I agree it seems strange that numbers allow whitespace but keywords wouldn't
21:10:06 <birtles> shepazu: at the same time, I'd rather defer to HTML
21:10:14 <birtles> ... not sure it's worth our deviating
21:10:26 <birtles> ed: it would be nice to use the exact same number parsers as the HTML ones
21:10:34 <birtles> ... unless we have a strong reason otherwise
21:10:49 <birtles> heycam: we don't have many attributes that only take a number, except some in filters
21:11:12 <birtles> ... I would be fine with not allowing whitespace for enumerated values in order to align with HTML
21:11:49 <birtles> ed: I think this came up from a bug report about one of the SVG attributes that takes a bunch of different values including a matrix
21:11:59 <birtles> ... sometimes it's easier to markup the content by adding extra whitespace
21:12:07 <birtles> ... might have been feConvolveMatrix|values ?
21:12:37 <birtles> heycam: for this attribute you need to allow whitespace to separate the values
21:12:53 <birtles> ed: but it's not defined if you allow whitespace at the start/end
21:13:03 <birtles> Tav: I like to line up values by adding spaces
21:13:24 <birtles> ... e.g. <rect width=" 50"... >, <rect width="150" ... >
21:13:28 <ed> <feConvolveMatrix values="    0 1 1 0 0 ... linebreak ... more values"/>
21:14:06 <birtles> heycam: I think attributes that are white-space separated, it should allow whitespace at the start and end
21:14:18 <birtles> Tav: that doesn't cover the width attribute
21:14:32 <birtles> ... and I think Firefox and Chrome don't allow that
21:14:49 <birtles> krit_: we've had bug reports about this
21:15:09 <birtles> ... for the opposite, making it more conformant to the spec
21:15:48 <birtles> ed: apart from the enumerated types, any others in HTML that don't allow start/end whitespace
21:15:58 <birtles> s/ed: apart/heycam: apart/
21:16:01 <birtles> ed: boolean
21:16:13 <birtles> ... don't think we have anything quite the same in SVG
21:16:27 <birtles> ... URLs I think are sometimes allowed to be surrounded by whitespace?
21:16:37 <birtles> heycam: that's tricky because URLs can contain space
21:17:26 <birtles> ed: if we want to allow HTML5, everything should allow whitespace except the enumerated values
21:18:42 <ed> s/URLs I think are sometimes allowed to be surrounded by whitespace?/URLs in html attributes always allow surrounding whitespace
21:18:44 <birtles> birtles: I think when I implemented animation I allowed whitespace before/after enumerated values because I think I was looking at XML whitespace normalization which said to do that
21:19:13 <birtles> heycam: I'd like to see a list of the attributes we have and see what kind of attributes we have
21:19:30 <birtles> ACTION: ed to summarise the kinds of attributes we have and proposed handling of leading/trailing whitespace
21:19:32 <trackbot> Created ACTION-3595 - Summarise the kinds of attributes we have and proposed handling of leading/trailing whitespace [on Erik Dahlström - due 2014-02-27].
21:19:43 <birtles> topic: paint-order
21:19:57 <birtles> krit_: I wrote a mail...
21:20:18 <birtles> ... I was looking at implementing it and came up with 3 issues, 2 of which are resolved
21:20:28 <birtles> ... the remaining issue is the order of specifying key values
21:20:36 <heycam> http://lists.w3.org/Archives/Public/www-svg/2014Feb/0042.html
21:20:37 <birtles> ... right now it's stroke, fill, markers
21:20:43 <birtles> ... this is the opposite order of other properties we have
21:20:46 <birtles> ... I think this is confusing
21:20:54 <birtles> heycam: I find the background layer order confusing
21:20:57 <birtles> krit_: I don't disagree
21:21:02 <birtles> ... but I think we should be compatible
21:21:08 <birtles> ... not just background but also masking
21:21:39 <birtles> ... and fill and stroke
21:21:40 <birtles> heycam: all of those things are modeled after background layers
21:21:48 <birtles> krit_: I think they are comparable but...
21:21:58 <birtles> heycam: they do all specify things that need to get painted in a particular order
21:22:08 <birtles> ... do we have any other properties that define things that need to get painted
21:22:18 <birtles> ed: the filter property in filter effects
21:22:36 <birtles> ... it can take a list of filters and follows the order you specify it
21:22:52 <birtles> krit_: that's more chain order, but yes, there is inconsistency with other properties
21:23:16 <birtles> ed: my opinion is that the current order is fine, it's the most logical
21:23:18 <birtles> Tav: I agree
21:23:21 <birtles> nikos: I also agree
21:23:43 <birtles> krit_: then we need to note that this is the opposite order to background, and give an example too
21:24:11 <birtles> ed: but I don't see how they are connected... they don't relate to the background
21:24:17 <birtles> krit_: I meant the fill and stroke
21:24:40 <birtles> heycam: I agree with Erik that they are different enough things: paint-order and background layers
21:24:46 <birtles> ... so we don't need to use the same ordering
21:24:59 <birtles> ... so since the current ordering, left-to-right, is more sensible, we should keep that
21:25:10 <Zakim> -Tav
21:25:40 <birtles> heycam: krit_, what do you think?
21:26:03 <birtles> krit_: I don't think there needs to be a consensus... if there is a majority
21:26:09 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
21:26:09 <birtles> ... I guess I can live with it
21:26:34 <Zakim> +Tav
21:26:42 <birtles> RESOLUTION: Keep the current order of paint-order even though it is different to background layers
21:26:46 <Zakim> +Rich_Schwerdtfeger
21:27:05 <birtles> krit_: with regards to implementing features
21:27:16 <birtles> ... how can implementations move forward if the specification of SVG2 does not
21:27:24 <birtles> heycam: I would be fine with bringing up features in telcon meetings
21:27:37 <birtles> ... to see if people think a given feature is mature and if its ok to ship it
21:27:53 <birtles> ... I don't think we have to wait for the whole spec to reach CR before shipping any of it
21:28:57 <birtles> ... we don't need a formal consensus, but informally seeing if there any objections should be enough
21:29:13 <birtles> krit_: what if the feature still has issues
21:29:24 <birtles> heycam: if there are issues in the spec that affect the behavior of the feature
21:29:45 <birtles> ... I would expect people to take that into account when deciding if they should ship something
21:30:03 <birtles> ... I think we should rely on people acting in good faith when they decide if they should ship something or not
21:30:12 <birtles> shepazu: especially since we can't enforce this process anyway
21:30:37 <birtles> heycam: I don't think we've seen examples of SVG2 features being shipped prematurely yet
21:31:07 <birtles> ... if people want to ship features, bring them up in a telcon and get a feel for what other people think
21:32:10 <thorton> thorton has joined #svg
21:32:18 <birtles> heycam: were you ok with the other issues in that thread about future-proofing?
21:32:25 <birtles> krit_: I think I'm ok with that
21:32:53 <birtles> Tav: I'd be interested in knowing what parts of SVG2 people are working on
21:33:01 <birtles> heycam: yeah, that would be interesting to know
21:33:19 <birtles> ... I implemented some small stuff, started working on markers but then moved on
21:33:27 <birtles> krit_: for me its filters, transforms
21:33:36 <krit_> masking
21:33:55 <Zakim> -stakagi
21:33:56 <Zakim> -heycam
21:33:57 <Zakim> -cabanier_
21:33:58 <birtles> RRSAgent: make minutes
21:33:58 <RRSAgent> I have made the request to generate http://www.w3.org/2014/02/20-svg-minutes.html birtles
21:33:58 <Zakim> -??P5
21:33:58 <Zakim> -Doug_Schepers
21:33:59 <Zakim> -Tav
21:33:59 <Zakim> -ed
21:34:01 <Zakim> -krit
21:34:06 <Zakim> -Rich_Schwerdtfeger
21:34:08 <Zakim> -birtles
21:34:09 <Zakim> GA_SVGWG(SVG1)3:30PM has ended
21:34:09 <Zakim> Attendees were heycam, ed, krit, birtles, stakagi, cabanier_, Tav, Doug_Schepers, Rich_Schwerdtfeger
21:57:55 <thorton> thorton has joined #svg
21:58:30 <heycam> RRSAgent, set logs world-visible
21:58:45 <heycam> RRSAgent, make minutes
21:58:45 <RRSAgent> I have made the request to generate http://www.w3.org/2014/02/20-svg-minutes.html heycam
22:48:19 <birtles> oh, I already generated them?
22:49:57 <birtles> did I do it wrong?
23:18:09 <heycam> birtles, I think if you don't do "trackbot, end telcon" it won't tell RRSAgent to make the logs public
23:18:20 <Zakim> Zakim has left #svg
23:18:47 <heycam> birtles, also half an hour after the end of our call is when GMT switches to a new day, and if you tell RRSAgent to make minutes after that it'll make an empty minutes page for the new day
23:23:14 <birtles> heycam: gotcha--I remembered to make the minutes but not to end the telcon