SVG Working Group Teleconference -- 20 Feb 2014

<trackbot> Date: 20 February 2014

<scribe> scribenick: birtles

Update on Leipzig meeting venue

krit_: I spoke with the director of the faculty of computer science
... it won't be possible to get the venue for free
... because it's not an event of the university
... I looked if there was space after the LGM meeting
... but it's not possible because classes start after that
... I checked before the meeting but no reply

Tav: I checked as well

krit_: there may be a response in a few days but I don't think the response will be any different
... there was another venue?

Tav: some sort of hackerspace
... but I'm not sure it's suitable enough, may not be large enough

heycam: do you have a name for it?

krit_: I didn't check yet if there would be a hotel with a room

<Tav> http://sublab.org/raeume

krit_: but then we'd need to rent it if there was a room

Tav: it's more a place for mucking around with electronics
... doesn't look suitable from the pictures

heycam: what should we do then

krit_: I can check some hotels but it won't be free

Tav: how much do you think?

krit_: not sure
... university would be EUR100 per day

heycam: that's for accommodation not meeting space?

krit_: it was for the meeting space + Internet etc.

heycam: that's not too bad, but if it's not available

krit_: yes, it's not available after LGM

nikos: what about Mozilla in Paris?

heycam: yes, we have an office in Paris and a small space in Berlin
... I'm not sure how big it is but I can look into it

Tav: Paris would be convenient for Cyril and I
... but the cost of moving between Leipzig and Paris greater than the cost of renting a space

nikos: I'm not going to LGM so it wouldn't affect me

heycam: who's going?

Tav: I'm going, Chris...

ed: not sure yet

heycam: it might be good to hear from Chris then since we want to limit trips for him
... so it might depend if meeting in Paris counts as a second trip or not

Tav: getting from Leipzig to Paris by train is a day's travel

krit_: there's a non-stop flight

heycam: is it worth looking into Berlin or Paris?

krit_: I'll look into getting a hotel room in Leipzig then we can compare next week

Should linking.html#processingIRI allow references to elements not in the document tree?

<ed> https://svgwg.org/svg2-draft/linking.html#processingIRI

ed: this came up in a bug report recently
... 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?
... or is it removed when the gradient is removed from the document
... the link itself might still be there since the gradient is reference

krit_: is the link internal/external

ed: either but I was thinking about internal

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?

<shepazu> (+1 to heycam)

ed: in that part of the spec, does "a node doesn't exist" mean elements that are outside the document?
... I'm guessing it should but this should be more clear

krit_: do you mean an element that is not in the DOM tree?
... how do you compute the style then if it is not in the DOM?
... I think that was an issue in the past

<ed> <rect fill="url(#foo)"> then remove the #foo element

heycam: I have a feeling that specs now define the computed style for an element that is outside the tree
... it's not just a null

krit_: what do implementations do? do they allow referencing elements that are outside the tree?

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

krit_: so you would like elements to be valid only if they are in the DOM tree?

shepazu: in the past SVG allowed you to reference external resources

<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

shepazu: but I think Mozilla didn't allow that for a long time, has that changed

heycam: yes, you can do that... as long as it's from an iframe

birtles: you have been able to do that for a long time

shepazu: where does that document live?
... but it's not available for scripting etc.
... if I were defining it today I would say it imports the external document into some resource shadow dom for resources
... so you're not relying on some external document
... but it's in a shadow document

krit_: how does that help?

shepazu: it unifies the behavior, it demystifies what is going on
... I think it's relevant to the conceptual idea of what is going on
... once a resource is removed from the document...

krit_: there's a reason we load it in this way... for security, so there are no references from other domains

shepazu: I don't think we want to change those things but just to define how those things are done
... 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?
... I assume that would behave the same

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

shepazu: is it worth defining that?

heycam: I suspect not since I think UAs will repaint at the end of the script block
... so do we agree about whether the link is broken...
... if an element that is referenced as a gradient (and similar) is removed from the document, it is no longer able to be referenced

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

heycam: did someone want to look into HTML imports to see if that can be re-used to define this?
... who had the action for looking into shadow dom?

krit_: I had the action but I'm not sure what you mean

heycam: you'll find out

ed: for element insertion, can we define the same so that you re-resolve all references with some given ID?

heycam: I think that's fine

RESOLUTION:
... upon element insertion, elements with IDs become referenceable

<scribe> ACTION: update the spec to clarify behavior of references to elements when they are removed/added from the document [recorded in http://www.w3.org/2014/02/20-svg-minutes.html#action01]

<trackbot> Error finding 'update'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: ed to update the spec to clarify behavior of references to elements when they are removed/added from the document [recorded in http://www.w3.org/2014/02/20-svg-minutes.html#action02]

<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].

Define if attribute values are allowed to have leading and/or trailing whitespace (ISSUE-2447)

ed: I think we've discussed this previously, I was hoping we could resolve on this

<ed> ISSUE-2447?

<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

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2447

ed: I had a look at what HTML5 does for this
... it seems that for numeric values leading/trailing whitespace is allowed
... for most attributes it is allowed but is stripped out
... some attributes don't allow it: enumerated values and boolean values
... but most other attributes do allow it

heycam: we previously resolved that for presentation attributes we will use the CSS parser to parse the attributes
... so whitespace would be allowed in those ones

ed: that's probably right but I don't think we have anything in the spec to say that
... and that wouldn't define what we do for numeric attributes

<ed> http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#keywords-and-enumerated-attributes

shepazu: what is an example of an enumerated attribute?
... why does HTML not allow whitespace for that?

ed: I don't know
... if you follow the link above you'll find lots of parsing rules

shepazu: for example, wouldn't stroke-linecap be an enumerated value?
... aren't most of our values enumerated?

ed: the most frequently used are numerical

heycam: stroke-linejoin would be enumerated but if we've decided they are parsed with the CSS parser then whitespace would be allowed

krit_: could someone find out why whitespace is not allowed in HTML?

ed: one example is the "dir" (bidi) attribute

shepazu: on the whole I'd rather follow what HTML does but in this case that seems overly respective

krit_: but there might be a good reason for that

ed: one example is the "dir" (bidi) attribute

<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)

heycam: I agree it seems strange that numbers allow whitespace but keywords wouldn't

shepazu: at the same time, I'd rather defer to HTML
... not sure it's worth our deviating

ed: it would be nice to use the exact same number parsers as the HTML ones
... unless we have a strong reason otherwise

heycam: we don't have many attributes that only take a number, except some in filters
... I would be fine with not allowing whitespace for enumerated values in order to align with HTML

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
... sometimes it's easier to markup the content by adding extra whitespace
... might have been feConvolveMatrix|values ?

heycam: for this attribute you need to allow whitespace to separate the values

ed: but it's not defined if you allow whitespace at the start/end

Tav: I like to line up values by adding spaces
... e.g. <rect width=" 50"... >, <rect width="150" ... >

heycam: I think attributes that are white-space separated, it should allow whitespace at the start and end

Tav: that doesn't cover the width attribute
... and I think Firefox and Chrome don't allow that

krit_: we've had bug reports about this
... for the opposite, making it more conformant to the spec

heycam: apart from the enumerated types, any others in HTML that don't allow start/end whitespace

ed: boolean
... don't think we have anything quite the same in SVG
... URLs in html attributes always allow surrounding whitespace

heycam: that's tricky because URLs can contain space

ed: if we want to allow HTML5, everything should allow whitespace except the enumerated values

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

heycam: I'd like to see a list of the attributes we have and see what kind of attributes we have

<scribe> ACTION: ed to summarise the kinds of attributes we have and proposed handling of leading/trailing whitespace [recorded in http://www.w3.org/2014/02/20-svg-minutes.html#action03]

<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].

paint-order

krit_: I wrote a mail...
... I was looking at implementing it and came up with 3 issues, 2 of which are resolved
... the remaining issue is the order of specifying key values

<heycam> http://lists.w3.org/Archives/Public/www-svg/2014Feb/0042.html

krit_: right now it's stroke, fill, markers
... this is the opposite order of other properties we have
... I think this is confusing

heycam: I find the background layer order confusing

krit_: I don't disagree
... but I think we should be compatible
... not just background but also masking
... and fill and stroke

heycam: all of those things are modeled after background layers

krit_: I think they are comparable but...

heycam: they do all specify things that need to get painted in a particular order
... do we have any other properties that define things that need to get painted

ed: the filter property in filter effects
... it can take a list of filters and follows the order you specify it

krit_: that's more chain order, but yes, there is inconsistency with other properties

ed: my opinion is that the current order is fine, it's the most logical

Tav: I agree

nikos: I also agree

krit_: then we need to note that this is the opposite order to background, and give an example too

ed: but I don't see how they are connected... they don't relate to the background

krit_: I meant the fill and stroke

heycam: I agree with Erik that they are different enough things: paint-order and background layers
... so we don't need to use the same ordering
... so since the current ordering, left-to-right, is more sensible, we should keep that
... krit_, what do you think?

krit_: I don't think there needs to be a consensus... if there is a majority
... I guess I can live with it

RESOLUTION: Keep the current order of paint-order even though it is different to background layers

krit_: with regards to implementing features
... how can implementations move forward if the specification of SVG2 does not

heycam: I would be fine with bringing up features in telcon meetings
... to see if people think a given feature is mature and if its ok to ship it
... I don't think we have to wait for the whole spec to reach CR before shipping any of it
... we don't need a formal consensus, but informally seeing if there any objections should be enough

krit_: what if the feature still has issues

heycam: if there are issues in the spec that affect the behavior of the feature
... I would expect people to take that into account when deciding if they should ship something
... I think we should rely on people acting in good faith when they decide if they should ship something or not

shepazu: especially since we can't enforce this process anyway

heycam: I don't think we've seen examples of SVG2 features being shipped prematurely yet
... if people want to ship features, bring them up in a telcon and get a feel for what other people think
... were you ok with the other issues in that thread about future-proofing?

krit_: I think I'm ok with that

Tav: I'd be interested in knowing what parts of SVG2 people are working on

heycam: yeah, that would be interesting to know
... I implemented some small stuff, started working on markers but then moved on

krit_: for me its filters, transforms

<krit_> masking

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

20 Feb 2014

Attendees

Contents

Update on Leipzig meeting venue

Should linking.html#processingIRI allow references to elements not in the document tree?

Define if attribute values are allowed to have leading and/or trailing whitespace (ISSUE-2447)

paint-order

Summary of Action Items

Scribe.perl diagnostic output