IRC log of svg on 2014-02-20

Timestamps are in UTC.

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