- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 21 Feb 2014 07:56:15 +0900
- To: 'www-svg' <www-svg@w3.org>
Minutes from the 20 February 2014 meeting are below.
http://www.w3.org/2014/02/20-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
20 Feb 2014
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0101.html
See also: [3]IRC log
[3] http://www.w3.org/2014/02/20-svg-irc
Attendees
Present
heycam, ed, krit, birtles, stakagi, cabanier_, Tav,
Doug_Schepers, Rich_Schwerdtfeger
Regrets
Chair
Cameron
Scribe
birtles
Contents
* [4]Topics
1. [5]Update on Leipzig meeting venue
2. [6]Should linking.html#processingIRI allow references
to elements not in the document tree?
3. [7]Define if attribute values are allowed to have
leading and/or trailing whitespace (ISSUE-2447)
4. [8]paint-order
* [9]Summary of Action Items
__________________________________________________________
<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> [10]http://sublab.org/raeume
[10] 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>
[11]https://svgwg.org/svg2-draft/linking.html#processingIRI
[11] 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
[12]http://www.w3.org/2014/02/20-svg-minutes.html#action01]
<trackbot> Error finding 'update'. You can review and register
nicknames at
<[13]http://www.w3.org/Graphics/SVG/WG/track/users>.
[13] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
<scribe> ACTION: ed to update the spec to clarify behavior of
references to elements when they are removed/added from the
document [recorded in
[14]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>
[15]http://www.w3.org/Graphics/SVG/WG/track/issues/2447
[15] 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>
[16]http://www.w3.org/html/wg/drafts/html/master/infrastructure
.html#keywords-and-enumerated-attributes
[16]
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>
[17]http://www.w3.org/html/wg/drafts/html/master/index.html#att
ributes-1 - the list of html attributes and how they parse
their value(s)
[17]
http://www.w3.org/html/wg/drafts/html/master/index.html#attributes-1
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" ... >
<ed> <feConvolveMatrix values=" 0 1 1 0 0 ... linebreak ...
more values"/>
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
[18]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>
[19]http://lists.w3.org/Archives/Public/www-svg/2014Feb/0042.ht
ml
[19] 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
Summary of Action Items
[NEW] ACTION: ed to summarise the kinds of attributes we have
and proposed handling of leading/trailing whitespace [recorded
in [20]http://www.w3.org/2014/02/20-svg-minutes.html#action03]
[NEW] ACTION: ed to update the spec to clarify behavior of
references to elements when they are removed/added from the
document [recorded in
[21]http://www.w3.org/2014/02/20-svg-minutes.html#action02]
[NEW] ACTION: update the spec to clarify behavior of references
to elements when they are removed/added from the document
[recorded in
[22]http://www.w3.org/2014/02/20-svg-minutes.html#action01]
[End of minutes]
Received on Thursday, 20 February 2014 22:56:50 UTC