minutes, SVG WG Sydney F2F 2015, day 1 from Cameron McCormack on 2015-02-12 (www-svg@w3.org from February 2015)

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 12 Feb 2015 16:35:09 +1100
To: www-svg@w3.org
Message-ID: <20150212053509.GA28590@wok.mcc.id.au>

http://www.w3.org/2015/02/11-svg-minutes.html

[1]W3C

[1] http://www.w3.org/

- DRAFT -

SVG Working Group Teleconference

11 Feb 2015

[2]Agenda

[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals

See also: [3]IRC log

[3] http://www.w3.org/2015/02/11-svg-irc

Attendees

Present
Doug_Schepers, +61.2.933.6.aaaa, Rich_Schwerdtfeger

Regrets
Chair
Cameron

Scribe
birtles, Cameron

Contents

* [4]Topics
1. [5]Publication of the Accessibility mapping document
2. [6]Adding new integer enum values in light of not
going ahead with new SVG DOM
3. [7]Avoiding new camelcase names
4. [8]Attribute parsing overhaul
5. [9]What to do with the embedded content chapter
6. [10]What is going to happen to the SVG DOM
7. [11]Requiring foreignObject HTML behavior
8. [12]Requiring style sheet support
9. [13]Drop xml:base/lang/space attributes
10. [14]Proposal: drop the SVGPathSeg* interfaces and
related methods/attributes
11. [15]camelcased attributes
12. [16]Open issues that require discussion
13. [17]chapter styling
* [18]Summary of Action Items
__________________________________________________________

<trackbot> Date: 11 February 2015

<heycam> Meeting: SVG Sydney F2F 2015 day 1

<birtles> scribe: birtles

<scribe> scribenick: birtles

Publication of the Accessibility mapping document

<heycam>
[19]http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

[19] http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

heycam: some of you would have gone to the telcon with the
accessibility tf a couple of weeks ago to review the
publication

ed: I went to the telcon and sent some review comments

<shepazu> +1 to publication

ed: it describes how to represent SVG markup in an accessible
way
... it's outside of SVG so it doesn't affect our spec so much
... there's a table in the SVG spec at the moment

heycam: so that would be replaced by a reference to this
document?

ed: I suppose so

<shepazu> (well, it describes the mapping of SVG elements to
the underlying platform accessibility APIs

krit: I think we should keep the table to make sure that
everyone knows that accessibility is important to us

heycam: shepazu, did you attend the call with the accessibility
tf

shepazu: yes, I attend them all
... I wanted to be clear about what the doc is for
... it doesn't describe how to make SVG accessible
... it says which parts of SVG map to which parts of the
accessibility API
... e.g. links, groups elements, what do they actually do
... as you can expect, there are very few native mappings
... because SVG doesn't have the kind of rich interaction modes
that HTML has: forms, headings etc.
... but this is a good first step, lays the the groundwork for
how accessibility APIs should map to SVG
... the document says, of the features that are in SVG, what
are the interaction modes with the native accessibility APIs

richardschwerdtfeger: every platform that supports
accessibility has an API for exposing different items
... 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
... can interact with it like any other software applicaiton
... so this spec is actually an extension to a core
specification for all browsers
... 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

shepazu: I forgot the detail about the accessible name
computation
... for example, that will give you the title
... so there's a name and a description?

richardschwerdtfeger: correct
... each of the APIs has a method that will correlate to an SVG
element
... and that will give you more information like descriptions

shepazu: for example, if you're using a screen reader
... you have 5 circles, each has a title, the screen reader
would go through them in document order
... each of them represents a different thing
... it would go through, and say, in document order, the title
for each one
... if you had a description it might also, e.g. beep, to tell
you there's more information
... so you can say, "I want more information"
... so it would read the title, but not the description unless
you ask for it

heycam: richardschwerdtfeger, you're looking to publish this as
FPWD right?

richardschwerdtfeger: correct

krit: are there any issues that need to be discussed?

richardschwerdtfeger: I don't think so
... there are a couple of issues we need to address about *not*
mapping things
... but they are already issues in the spec

shepazu: this is just a FPWD, but it's pretty complete

heycam: do we agree to publish a FPWD?

krit: agree

<shepazu> +1

<richardschwerdtfeger> +1

RESOLUTION: SVGWG agrees to publish the accessibility mappings
document as a FPWD

shepazu: thanks for all your work richardschwerdtfeger

Adding new integer enum values in light of not going ahead with new
SVG DOM

heycam: we made a decision a little while ago to stop adding
new numeric constants to the DOM
... today it's considered a bit of an anti-pattern

<scribe> ... new APIs use strings as their enum values

UNKNOWN_SPEAKER: HTML does that
... the original SVG DOM has a lot of numeric values for enums
... that consists of a property that takes a number and a bunch
of numeric constants defined on that interface
... we decided to not propagate any more usage of this
... by saying that any new enums should use strings
... but also by saying that for enums that we extend, we won't
add any new numeric values
... but represent those using the zero value
... and we'd introduce a new DOM to fix this later
... but since we're probably not going ahead with that new API
perhaps we should add numeric constants for the new values
... I think we shouldn't squash all those new values into the
zero value

ed: so just new numbers or new constants too?

heycam: adding new numbers would fix the implementation
difficulty but not the authoring difficulty

krit: I'm concerned with maintaining the list of numbers
... both in spec terms and implementation terms
... I don't think we can keep up with all the new units etc.
that get coined

heycam: so krit you're not in favour?

krit: not really

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)
... I don't think we have useage counters for the methods that
do take the numeric values

krit: could we move the whole section about the SVG DOM to a
separate document?

heycam: but a lot of the SVG DOM stuff is reflecting things
defined only in the SVG spec
... if people aren't enthusiastic with my proposal I'm happy
with sticking with the status quo

krit: if we keep the SVG DOM, then it will get used more and
more and become harder to change

ed: is it worth changing the methods that take these values
into taking a string, for example

krit: you could try to disable certain APIs, not the whole API,
but just one API at a time

heycam: I thought you (krit) were going to try that already?

krit: I was going to, but don't have time

ed: we do have usage counters for things like the animated
types, suspendRedraw etc.

heycam: we want to know specifically for things like getAnimVal
etc.
... we're not going to remove getBBox() for example

krit: it's probably safe to just map animVal to baseVal since
IE does it

ed: the use of the SVG DOM is 0.04%

TabAtkins: 0.04% is still high but it would worth breaking down
those numbers to find out which parts we could remove

ed: I've added use counters for path segment interfaces and
those are very low
... we can certainly add more use counters but we need to know
what to measure

heycam: the most important to me is the animVal interfaces

ed: SVGAnimatedTransformList.baseVal usage is very low

krit: what is used then?
... if not paths or transforms

ed: probably animated lengths

krit: everyone uses animVal
... I think we should just map animVal to baseVal

shane: I think could remove baseVal

krit: I'm not sure
... did MS get any complaints about not supporting animVal?

(some discussion about which is used more commonly, animVal or
baseVal)

heycam: it would be helpful to get some usage counters on
animVal / baseVal

<scribe> ACTION: ed to add usage counters to blink to measure
usage of animVal / baseVal [recorded in
[20]http://www.w3.org/2015/02/11-svg-minutes.html#action01]

<trackbot> Created ACTION-3701 - Add usage counters to blink to
measure usage of animval / baseval [on Erik Dahlström - due
2015-02-18].

Avoiding new camelcase names

heycam: this is something we already agreed to do
... but we still have newish names in the spec that use
camelCase

Tav: we have meshGradient and I think it should match
linearGradient and radialGradient

heycam: that's the question: consistency with existing things
vs awkwardness of updating the HTML parser

shane: I think consistency argument is a strong one

ed: I agree
... but for new attributes that don't need to be consistent
with anything they should be lowercase

heycam: I think <meshGradient> could be just <mesh> since it
can render by itself

Tav: in Inkscape it was easy to implement meshGradient based on
existing gradient code
... implementing rendering by itself could take some time

krit: if meshes can be a shape then I think the argument for
renaming to <mesh> is strong

heycam: there's still the child elements, <meshRow> etc.

roc: they could be lowercase

ed: do we want to rename it to <mesh>?

roc: yes

TabAtkins: yes

nikos: can you choose to fill it with something other than a
gradient?

(no)

heycam: I checked the HTML spec and it doesn't have these names
in it yet

nikos: you could have a paint server that defines the gradient
and normal SVG shapes that define the mesh

krit: would that simplify things?

Tav: that complicates things

heycam: I think it's going to be pretty common to want to use
the same geometry
... Tav, what do you think about renaming to <mesh> and
renaming the child elements to make them lowercase

Tav: I'm not going to jump and down, but I guess it's ok

krit: I think it's confusing that linearGradient by itself
doesn't render, but a meshGradient does--so renaming makes
sense

Tav: so the children would be mesh-row

(no, dashes are reserved)

(some discussion about using <row> and about it being to
generic)

krit: I think we agree we don't want camelCase within the mesh

RESOLUTION: Rename <meshGradient> to <mesh> and make the child
element names lowercase

heycam: the remaining new camelCase names are the hatch ones
(hatchPath)

Tav: so that would become lowercase

krit: can we just use normal paths...

Tav: we talked about that before and decided this was best

RESOLUTION: Rename <hatchPath> to <hatchpath>

heycam: the other new camelCase element name is solidColor
... I'm not thrilled by this element but Tav's argument is that
implementing variables is more overhead
... you can also get the same effect with a gradient with a
single stop

Tav: but that's really ugly in the code

heycam: assuming that element stays, can we lowercase it?

Tav: I don't care

RESOLUTION: Rename <solidColor> to <solidcolor>

ed: attribute names? camelCased?
... we have a bunch of them and we should try and avoid them if
we can
... I found playbackOrder and timelineBegin

heycam: attribute names and attribute values are slightly
different
... attribute names have to be handled in the HTML parser
... attribute values are more of just an aesthetic thing
... I think it would be better to make them lowercase

ed: we have a hatchTransform attribute

Tav: that follows the patternTransform and gradientTransform
attribute

krit: gradientTransform maps transform so we shouldn't make
that mistake again
... we should just use transform

RESOLUTION: Rename hatchTransform to transform

ed: there are other ones like hatchContentUnits and hatchUnits

<scribe> 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.) [recorded in
[21]http://www.w3.org/2015/02/11-svg-minutes.html#action02]

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

Attribute parsing overhaul

heycam: my most recent change to the spec is to unify the
parsing of attributes and how their grammars are defined
... 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."
... of those I think the CSS syntax is the nicest so I
converted all of the attributes to use that
... so using [] for grouping, referencing CSS types etc.
... which meant I was able to remove a lot of the types chapter

<heycam> [22]https://svgwg.org/svg2-draft/types.html#syntax

[22] https://svgwg.org/svg2-draft/types.html#syntax

heycam: which defined a lot of the re-useable types
... I replaced the section that defined things like length,
list of strings etc., with this section
... most of these are using CSS now, a couple still use EBNF
because they reference other specs, or path data which is quite
complex
... I've updated lists to use CSS
... one important change is that I'm not sure that we want to
call into the CSS parser without flags...
... should we allow comments, escapes etc.?
... or should I make Tab add flags to the CSS parser to disable
these features?

TabAtkins: unless you think it will cause problems, I think we
should allow comments, CSS escapes etc.

ed: which attributes does this affect? presentation attributes?

heycam: presentation attributes already map to CSS so allow
those things
... the reason I hesitate about allowing those things elsewhere
is it means implementations have to update to call the CSS
parser for these attributes

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

<TabAtkins> I did it for An+B and <urange>, and it was terrible
both times, and <path d> will be *much worse*.

cyril: how did you test that the new grammar matches the old?

heycam: most of them are pretty simple

cyril: are there any hard ones?

heycam: the ones that are either space or comma separates--I
think I got them right
... it's not a common pattern in CSS

(discussion about whether heycam got the grammar right, seems
like he probably did)

<heycam>
[23]https://svgwg.org/svg2-draft/shapes.html#DataTypePoints

[23] https://svgwg.org/svg2-draft/shapes.html#DataTypePoints

<TabAtkins> To do a list of <foo> that is comma-or-whitespace,
do <foo>+#?

heycam: this looks weird for CSS syntax but I think it's right

<heycam>
[24]https://svgwg.org/svg2-draft/text.html#TextElementXAttribut
e

[24] https://svgwg.org/svg2-draft/text.html#TextElementXAttribute

heycam: this might need to change, particularly because we have
the new x/y properties

krit: can you remove the number from [<length> | <percentage> |
<number>]
... because it is implicitly allowed for attributes

heycam: is that right?
... properties that can take lengths can also take numbers in
SVG
... during this conversion I made this explicit by adding in
<number>

TabAtkins: you can also use quirky-length
... it's length or number with number meaning pixels

heycam: I'd like to make it explicit
... regarding percentages which krit brought up recently
... I haven't gone through it properly yet but I've tried to
add in percentages

shane: we're exposing the path syntax in CSS with the Motion
Path module

krit: but there's it's a string, it's not parsed

heycam: so is this conversion ok?

(question about formatting of attribute formatting--text
chapter is yet to be done)

<krit> scribeNick: krit

What to do with the embedded content chapter

<heycam> [25]https://svgwg.org/svg2-draft/embedded.html

[25] https://svgwg.org/svg2-draft/embedded.html

heycam: this is about iframe, video, audio
... we had objections from ppl about that approach for at least
the iframe
... ppl didn't like adding them to the SVG NS and we should
solve these in other ways
... This has to do how we merge NS or get rid of them but that
is a long term goal
... what do we do in the spec now?
... it is possible to use these futures with foreignObject
... is that maybe sufficient enough?
... We could add notes that this is a way to get video and
others
... and describe how video and audio could work in SVG later

birtles: I would be interested in <box> as a light weighted
version of <foreignObject>

<birtles> specifically, <box> also shrink-wraps its contents

<birtles> see discussion from TPAC last year:
[26]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_
integration_again

[26] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_integration_again

BogdanBrinza: We implement foreingObject and box would just be
a special case of fO

heycam: do you want it in SVG2 or is it ok for SVG3?

birtles: With a rapid release cycle I am ok with defer

heycam: so box would take width and height

birtles: right

roc: it is actually inline

heycam: do you have a proposal for box?

birtles: I was pesismisitic about the 2 experiments around
october

<birtles> TPAC discussion:
[27]http://www.w3.org/2014/10/31-svg-minutes.html#item09

[27] http://www.w3.org/2014/10/31-svg-minutes.html#item09

birtles: I am starting to lean more to <box> than the
alternatives

roc: so you have a preferred intrinsic width
... you have a min width and the intrinsic with and this is the
width you actually get
... you need to have some way of controlling the box element
some kind of idea what the width

krit: why can

t that be the intrinsic width?

heycam: what happens on abs pos?

roc: it comes from the containing block

krit: could box create a initial containing block

roc: not initial but definitely a containing block
... for relative positioning
... it would still need a width constrain
... otherwise it is flying of the page what you don't want
... so you need to come up with a reasonable default

heycam: we can do that. I like <box>

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
... i didn't like to have a iframe element that was different
than the one in HTML

heycam: what about the NS?

roc: would be HTML

ed: what about the XML parser?

<shepazu> +1 to just use the HTML elements for iframe, audio,
video, etc

heycam: you can't SVG image in and SVG context

roc: it could be svg/xml
... that does not require XML parsing
... you gonna not have a iframe video and an SVG image
... you could do all the things in XML as well, just put more
code on it

ed: how do we proceed

<shepazu> (is it feasible to remove namespaces from browsers at
this point? how much would it break?)

<shepazu> (I mean in an HTML/SVG context)

krit: do we do that for SVG2 or SVG3?

heycam: there are a lot of details we need to discuss

TabAtkins: we don't have to worry about this
... we don't have to care about an SVG image in an HTML
document now
... allowing HTML parser for the SVG images makes it easy to
use video and audio but we don't have to care about that
... all JS functions can create HTML element by adding the NS
... we can do SVG in HTML later
... and use a limited set of THML element into SVG now

heycam: so we only need to this parser change and state in the
spec what an HTML element means in the SVG NS

birtles: if we can do that approach than this is enough for
SVG2
... we still need to add the x,y presentation attributes on the
iframe element and Ian doesn't want to do that

roc: we should force this issue
... we should stick to replaced element

birtles: that would be a good start

krit: replace elements means allowing object and embed as well

roc: well yes, we don't want to do that
... we should limit the list to a fixed set of elements and
allow replaced elements later

krit: we would still depend onHTML parser changes and the x,y
attributes

roc: we will need CSS terms
... like some kind of containing block

TabAtkins: would be the nearest SVG viewport

roc: we need to say if they are display: block or inline

TabAtkins: everything is implicitly position in SVG so it would
be block

roc: that is fine

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

<scribe> 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 [recorded in
[28]http://www.w3.org/2015/02/11-svg-minutes.html#action03]

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

<scribe> ACTION: TabAtkins write the SVG layout spec [recorded
in [29]http://www.w3.org/2015/02/11-svg-minutes.html#action04]

<trackbot> Created ACTION-3704 - Write the svg layout spec [on
Tab Atkins Jr. - due 2015-02-19].

ed: there is an issue with the width and height properties take
integers

krit: you mean the problem is a specified viewBox

ed: yes

roc: you can style with CSS

heycam: but you don't want to have half pixels in Canvas
... but it is probably a rare situation anyway

roc: I don't think there is any reason to handle video any
specific way
... Canvas is special
... width and height map to CSS and nothing else happens but in
Canvas these attributes also set the backing store

krit: it might be confusing that width/height are no
presentation attributes but users know that from HTML already

<scribe> ACTION: TabAtkins convince Hixie to make the HMTL
parser changes + x/y presentation attributes on the canvas,...
elements for SVG [recorded in
[30]http://www.w3.org/2015/02/11-svg-minutes.html#action05]

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

<scribe> ACTION: TabAtkins Allow templates in SVG which needs
HTML parser changes [recorded in
[31]http://www.w3.org/2015/02/11-svg-minutes.html#action06]

<trackbot> Created ACTION-3706 - Allow templates in svg which
needs html parser changes [on Tab Atkins Jr. - due 2015-02-19].

heycam: we should also get <link> to work in SVG

ed: They might in browsers already

<heycam> ACTION: Cameron to investigate which HTML elements
like <link> we might want to also allow in SVG [recorded in
[32]http://www.w3.org/2015/02/11-svg-minutes.html#action07]

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

krit: not sure that is the case. It didn't work for standalone
SVG for me

ed: I'll test

<shepazu> +1 to letting <link> work in SVG... what about <meta>
too?

<shepazu> [33]http://schepers.cc/css-link-hack-in-svg

[33] http://schepers.cc/css-link-hack-in-svg

heycam: <meta> I want too

<heycam> sounds good to me; I'll gather a list of likely HTML
elements to allow with my action

What is going to happen to the SVG DOM

nikos: have nothing specific about that
... we talked half about that in the previous session

heycam: we do the investigations with the use counters and drop
SVG DOM interfaces over time

TabAtkins: most of the CSS OM stuff is going to work with SVG
as well

Requiring foreignObject HTML behavior

heycam: we need to make spec say that HTML content in fO gets
rendered

ed: I don't think we want to have the hasFeature for fO at all

<ed> hasFeature/requiredFeatures

heycam: we willhave a conformance class that will require HTML
and another that doesn't
... the sizing of fO containing block should be in sVG2

roc: agree, there is a bunch of not clarified stuff

<scribe> ACTION: Reference integration spec and update
conformance class for HTML support on foreignObject [recorded
in [34]http://www.w3.org/2015/02/11-svg-minutes.html#action08]

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

[35] http://www.w3.org/Graphics/SVG/WG/track/users

<scribe> ACTION: heycam Reference integration spec and update
conformance class for HTML support on foreignObject [recorded
in [36]http://www.w3.org/2015/02/11-svg-minutes.html#action09]

<trackbot> Created ACTION-3708 - Reference integration spec and
update conformance class for html support on foreignobject [on
Cameron McCormack - due 2015-02-19].

Requiring style sheet support

Tav: we do support stylesheets but no fancy selectors

heycam: oh, that is what I want to require
... should we add a new conformance class maybe?

krit: no, we should require style sheet support
... authoring tools need to update at some part

Tav: we rely on someone else's library

<scribe> ACTION: hey cam add stylesheet requirements to the
spec [recorded in
[37]http://www.w3.org/2015/02/11-svg-minutes.html#action10]

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

[38] http://www.w3.org/Graphics/SVG/WG/track/users

<scribe> ACTION: heycam add stylesheet requirements to the spec
[recorded in
[39]http://www.w3.org/2015/02/11-svg-minutes.html#action11]

<trackbot> Created ACTION-3709 - Add stylesheet requirements to
the spec [on Cameron McCormack - due 2015-02-19].

Drop xml:base/lang/space attributes

ed: I have a test case that works the same way in all browsers

[40] http://www.w3.org/2000/svg

[41] http://www.w3.org/1999/xhtml

ed: the test case adds a <link> element and it works in all
browsers I tested

<TabAtkins>
[42]http://www.xanthir.com/etc/svg.php?width=100&height=100&svg
=%3Clink+xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml%22+r
el%3D%22stylesheet%22+type%3D%22text%2Fcss%22+href%3D%22data%3A
text%2Fcss%2Ccircle+%7B+fill%3Agreen%3B+%7D%22%2F%3E%0D%0A%3Cci
rcle+cx%3D%2250%22+cy%3D%2250%22+r%3D%2225%22+fill%3D%22red%22%
2F%3E

[42] 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

ed: this was to one of the previous topics

<ed>
[43]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/dropxmlat
tributes

[43] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/dropxmlattributes

ed: I split the proposal into several parts
... [explains more of the proposal as written in the document]

<ed>
[44]https://www.chromestatus.com/metrics/feature/timeline/popul
arity/580

[44] https://www.chromestatus.com/metrics/feature/timeline/popularity/580

ed: the usage of xml:base is 0

krit: and xml:lang?

heycam: so we do not support the IDL properties for those

ed: I would like to remove the IDL properties

krit: fine with me

RESOLUTION: Remove xml:base/space/lang from the SVG DOM
interface

<scribe> ACTION: ed Remove xml:base/space/lang from the SVG DOM
interface [recorded in
[45]http://www.w3.org/2015/02/11-svg-minutes.html#action12]

<trackbot> Created ACTION-3710 - Remove xml:base/space/lang
from the svg dom interface [on Erik Dahlström - due
2015-02-19].

ed: the 2nd part is remove xml:base entirely
... and describe how the others work with the non-NSed versions
... this is a breaking change

krit: do you have data for that?

ed: no, but I still think we want to clean up the XML database

ACTION; Write tests and come back to the SVG for xml:base

<scribe> ACTION: Write tests and come back to the SVG for
xml:base [recorded in
[46]http://www.w3.org/2015/02/11-svg-minutes.html#action13]

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

[47] http://www.w3.org/Graphics/SVG/WG/track/users

<scribe> ACTION: heycam Write tests and come back to the SVG
for xml:base [recorded in
[48]http://www.w3.org/2015/02/11-svg-minutes.html#action14]

<trackbot> Created ACTION-3711 - write tests and come back to
the svg for xml:base [on Cameron McCormack - due 2015-02-19].

ed: I want to drop xml:line in favor for HTML line

heycam: we discussed in Switzerland
... lets remove it

RESOLUTION: Remove xml:lang in favor for HMTL lang

<scribe> ACTION: ed Remove xml:lang in favor for HMTL lang
[recorded in
[49]http://www.w3.org/2015/02/11-svg-minutes.html#action15]

<trackbot> Created ACTION-3712 - Remove xml:lang in favor for
hmtl lang [on Erik Dahlström - due 2015-02-19].

<scribe> ACTION: ed Write tests and come back to the SVG for
xml:base [recorded in
[50]http://www.w3.org/2015/02/11-svg-minutes.html#action16]

<trackbot> Created ACTION-3713 - Write tests and come back to
the svg for xml:base [on Erik Dahlström - due 2015-02-19].

ed: define xml:space in terms of the white-space property

heycam: elika agreed to add to CSS3 Text a value for whitespace
with the same behavior as xml:space=preserve
... we should do all the mapping to whitespace property

REOSOLUTION: Map xml:space to whitespace property values in
CSS3 Text

RESOLUTION: Map xml:space to whitespace property values in CSS3
Text

<scribe> ACTION: ed Map xml:space to whitespace property values
in CSS3 Text [recorded in
[51]http://www.w3.org/2015/02/11-svg-minutes.html#action17]

<trackbot> Created ACTION-3714 - Map xml:space to whitespace
property values in css3 text [on Erik Dahlström - due
2015-02-19].

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Proposal: drop the SVGPathSeg* interfaces and related
methods/attributes

<ed>
[52]https://www.chromestatus.com/metrics/feature/timeline/popul
arity/568

[52] https://www.chromestatus.com/metrics/feature/timeline/popularity/568

ed: I added a use counter for any use of the SVGPathSeg*
interfaces
... any thing that creates or uses those objects
... it's currently 0
... I'm proposing we just drop those

Tav: sure it's not a bug in the use counter?

krit: it's interesting

ed: people typically just build path strings
... the DOM interfaces are so verbose
... I don't know if we want to consider adding a new
lightweight interface for manipulating path data

dmitry: I remember when trying to use this interface internally
in Snap I ended up just using the string
... there was a reason why, don't remember what it was
... something was missing on the API

ed: there are other issues around it
... if we want to keep the interface, we need to add ones for
the new path commands

roc: sounds great

shane: I'd like to consider a lightweight interface to share
with CSS

krit: yeah

shane: because CSS is going to be defining new CSS value
objects

krit: there's also the canvas Path object

<birtles> [53]http://parapara-editor.mozlabs.jp/sandbox

[53] http://parapara-editor.mozlabs.jp/sandbox

RESOLUTION: Drop the SVGPathSeg* interfaces if Erik verifies
the use counter values are correct

<scribe> ACTION: Erik to verify that the SVGPathSeg interface
use counter values are correct and to drop the interfaces if
they are [recorded in
[54]http://www.w3.org/2015/02/11-svg-minutes.html#action18]

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

camelcased attributes

[55]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0024.h
tml

[55] https://lists.w3.org/Archives/Public/www-svg/2015Feb/0024.html

ed: I went over the attribute appendix
... looking for new attributes we added to SVG 2 that are
camelcased
... I found a couple
... first are canvasWidth/canvasHeight/frameWidth/etc.
... they already have an open issue in the spec
... I think we should rename them to width/height or just make
them lowercase

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
... the other ones (frameWidth etc.) should just be dropped
... as we'll just keep the same attribute that are allowed on
the HTML elements
... this is already covered by the previous resolution

ed: meshGradient has gradientTransform, let's just make it
transform
... also meshGradient just got renamed to mesh

nikos: this would affect things when you use the mesh as a
paint server
... gradientTransform is different from transform

krit: we can still make them the same thing, transform
... also the other gradients use the transform property for
this

RESOLUTION: gradientTransform on mesh is renamed to transform

ed: next is hatchContentUnits
... I propose to keep it as is
... to match the other paint server Units attributes
... same for hatchUnits as well

TabAtkins: we could switch to units="" and contentunits=""

heycam: will they be used commonly on hatches?

Tav: yes

RESOLUTION: keep current namign of hatchUnits and
hatchContentUnits

ed: next, hatch has hatchTransform
... we should make that transform

Tav: yep

RESOLUTION: rename hatchTransform to transform

ed: next is playbackOrder on <svg>
... I propose that we make it lowercase
... either with a dash between or not

krit: I agree to check with web animations first
... would be good to use the same keyword values

<ed>
[56]https://svgwg.org/svg2-draft/struct.html#SVGElementPlayback
OrderAttribute

[56] https://svgwg.org/svg2-draft/struct.html#SVGElementPlaybackOrderAttribute

birtles: I don't have any intention of adding that to web
animations currently
... I prefer we don't add new animation features to SVG 2

krit: I don't like that we have it in SVG

birtles: but that other spec doesn't exist yet [SVG Animation
Elements spec]
... 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

cyril: I would agree, but it doesn't exist

birtles: I don't know how important it is to have them in SVG 2

cyril: the discard element is pretty independent

ed: the timelineBegin thing, is that something that would be
supported in web animations?
... beacuse that's a common feature request

birtles: yes

ed: people want to start animations while the document is
loading
... for animated spinners etc.

birtles: so there's no compatibility issue there
... but there's no keyword you could borrow there either

ed: but you could define it so that it starts the timeline
right away

birtles: that always happens
... it'd be just defining a dependent timeline to handle those
two modes

cyril: playbackOrder is a hint
... it's not that important

krit: timelineBegin?

cyril: that's improtant
... and it maps to web animations

birtles: do whatever you like with attribute names
... it doesn't have names to match up with web animations

krit: I'm fine with lowercasing
... onLoad and onStart are not good keywords though

ed: they're very unspecific

cyril: that could be changed

ed: I'd like something that maps to event names

cyril: I think they were originally designed to map to SAX
names

ed: but definitely let's not camelcase them

heycam: how about just lowercase the names for now and see if
anyone has better keyword ideas

ed: ok

RESOLUTION: timelineBegin attribute name and keywords are
lowercased
... playbackOrder becomes playbackorder

<scribe> ACTION: Erik to do the attribute lowercasing [recorded
in [57]http://www.w3.org/2015/02/11-svg-minutes.html#action19]

<trackbot> Created ACTION-3716 - Do the attribute lowercasing
[on Erik Dahlström - due 2015-02-19].

-- lunch break --

<shane> ScribeNick: shane

Open issues that require discussion

heycam: let's start with introduction chapter. Cyril - were
there things in the introduction that need discussion?

cyril: not really
... I looked at 1.1. Not entirely sure HTML5 needs to be
mentioned given that it's in 1.4
... I edited 1.2 to remove mention of Macintosh file types
... old, not needed any more
... 1.4 was edited to reduce size. Didn't touch 1.5. 1.6:
Moving terms & definitions to the chapter that first uses them.
... will continue doing that. A few commits not pushed yet.
Doesn't need more work.

ed: do we really want to say that XVG is a language for
describing 2D graphics _in XML_?

cyril: XML or other languages?

krit: markup?

cyril: SVG _is_ XML, right?

ed: sometimes

cyril: maybe can say that it can be integrated with a looser
syntax?
... or just want to say it's a language for describing 2D
graphics.

krit, ed: a markup language

heycam: the issues all seem like small tweaks

cyril: ISSUE 2: should we mention .svg.gz?

various: no, yes, maybe

consensus: yes

BogdanBrinza_: do we all agree that we want to move forwards to
publication?

cyril: no objection

heycam: are you saying we should be a bit ruthless to get to
that point?
... should see if there are any issues that really need to be
solved

<shepazu> (SVG in HTML is not XML, and that is the biggest use
of SVG at this point)

cyril: would like confirmation that it's OK to move the
definitions

heycam: I like the idea of that. Don't like massive list of
definitions

<shepazu> why not call it markup and leave it at that?

ed: I think it makes sense

<scribe> ACTION: Cyril don't stop [recorded in
[58]http://www.w3.org/2015/02/11-svg-minutes.html#action20]

<trackbot> Created ACTION-3717 - Don't stop [on Cyril Concolato
- due 2015-02-19].

(correction - we won't mention .svg.gz)

<heycam> shepazu, I think calling it "markup" is fine

cyril: when I see duplicate definitions I merge and raise if
there's a problem.
... e.g. bounding box

ed: different definitions of whitespace in animations and
elsewhere. Fixed though.
... moving to CSS fixes it

krit: chapter 2
... I did some cleanup but I don't remember what

cyril: should move towards whole page in white and unclear
areas in red

heycam: bit of work to make that change.

krit: isn't just stylesheet. Also requires markup changes

heycam: Who's editing this chapter?

nikos: done a fair few but not for a while. Not much here.

ed: some important definitions in this chapter, but would be OK
to merge into a different chapter.

cyril: be careful, some definitions will move into this

heycam: wanted this chapter to be strict definition of how to
paint an SVG subtree. Want references to CSS stacking order
etc.

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.

heycam: want to rework this chapter to do that then?

nikos: yes.

heycam: probably the right place to mention clip paths, masks,
filters, blending

<scribe> ACTION: nikos to rework chapter 2 and incorporate
references to external specifications [recorded in
[59]http://www.w3.org/2015/02/11-svg-minutes.html#action21]

<trackbot> Created ACTION-3718 - Rework chapter 2 and
incorporate references to external specifications [on Nikos
Andronikos - due 2015-02-19].

ed: want to mention knockout?

Tav: what's knockout?

nikos: compositing mode. Removed from spec
... still a description but no controls

heycam: I was going to add z-index

krit: I will do clipping, masking and filters

nikos: I don't mind having a first go at it
... probably best if I do it all as a first pass then we can
clean it up
... is z-index mentioned anywhere else in SVG2 atm?

krit: how elements are rendered (2.5) - does this require
mention of blending?
... seems we should merge 2.5 into 2.7-2.9

<scribe> ACTION: nikos to merge 2.5 into 2.7-2.9 [recorded in
[60]http://www.w3.org/2015/02/11-svg-minutes.html#action22]

<trackbot> Created ACTION-3719 - Merge 2.5 into 2.7-2.9 [on
Nikos Andronikos - due 2015-02-19].

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
... changed behaviour to be more like CSS. Do we need to
describe it?
... visible by default. Some browsers already do this.

heycam: clipping and masking should still be referenced here.

krit, nikos: yeah, clipping and masking chapter should be
merged into this.

Tav: would like an example of each in this spec
... so people can see what it's like without looking at the
linked spec

krit, nikos: disagree

nikos: lots of issues on overflow

heycam: Chapter 3
... I've been touching this most recently
... attribute syntax summary, discussed that
... Issue 1 is resolved.

krit: issue 2 (reference discussion about lacuna values)

ed: also need to go through spec to check we have lacuna values
for everything

<scribe> ACTION: heycam to resolve issue 2 in Chapter 3
[recorded in
[61]http://www.w3.org/2015/02/11-svg-minutes.html#action23]

<trackbot> Created ACTION-3720 - Resolve issue 2 in chapter 3
[on Cameron McCormack - due 2015-02-19].

krit Issue 3: wat?

heycam: needs some general wording about ???

krit

krit: Issue 4

<heycam> general wording about reflecting attributes

krit: blink removed this already (classname)
... didn't blink remove it already?

ed: don't think so

krit: do we want to remove this, or deprecate it?

ed: recommend classlist, don't know if we want to deprecate.

krit: I want to get rid of it.

heycam: me too
... have we already added a use counter for this?

ed: it's 0.32%.

krit: this might just be checking for SVG
... seen it used for this.
... so we just deprecate?

heycam: let's do that

<scribe> ACTION: heycam to mark classname as deprecated (issue
4 in chapter 3) [recorded in
[62]http://www.w3.org/2015/02/11-svg-minutes.html#action24]

<trackbot> Created ACTION-3721 - Mark classname as deprecated
(issue 4 in chapter 3) [on Cameron McCormack - due 2015-02-19].

krit: Issue 5. Should just reference HTML

heycam: yeah, just need to clean up the wording

krit: HTML5 or live spec?

heycam: whatever the W3C people make us do

ed: need some definition on what focus means. So need to
reference one.

heycam: Interface SVGLength. This is a long standing issue.
... 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?

TabAtkins: whelp, it's infinity

heycam: just decide on some behaviour. Either 0, or throw
exception, something

TabAtkins: or NaN

shane: NaN isn't right

heycam: don't really want to use NaN or infinity

shane: I think exception because you can't really use the
values anyway

heycam: so throw exception if converting into % units in this
case?

<scribe> ACTION: Heycam to specify that convertToSpecifiedUnits
should throw an exception if converting to percentage with
0-sized viewport. [recorded in
[63]http://www.w3.org/2015/02/11-svg-minutes.html#action25]

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

krit: accessors for ch, rem, vw, vh, vmin, vmax

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)
... if we reference CSS3 Values then there are more units.
Should add accessors for those too.

shane: CSS is going to be doing this anyway.

krit: right, plus if you have to use animVal...

heycam: but you don't need to use animVal

shane: given there will be a spec that gives nice access to
these, shouldn't add them

heycam: so what should we do?

TabAtkins/krit: remove them for now, ask CSS to prioritize

TabAtkins: actually it's TC39

RESOLUTION: remove unit accessors on SVGAnimatedLength

heycam: issue 11 is whether to add string accessor. Skip that
too?

krit: especially because most of these length values are CSS
properties now

heycam: hopefully people start to implement stuff in the CSSOM
to make it easier to get at this stuff without using
getComputedStyle()
... next issue (SVGGraphicsElement) - need wording to say that
transform now looks up something to do with the property

ed: what do you mean?

krit: transform now stored in CSS so no DOM access. Need to
reflect SVGAnimatedTransformList somehow.

heycam: discussed this years ago.
... 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

krit: should put this in the presentation attribute section

<scribe> ACTION: heycam to put this in the presentation
attribute section [recorded in
[64]http://www.w3.org/2015/02/11-svg-minutes.html#action26]

<trackbot> Created ACTION-3723 - Put this in the presentation
attribute section [on Cameron McCormack - due 2015-02-19].

krit: why deprecate nearestViewportElement?

ed: both nearest and furthest show very little usage

krit: is the peak on the graph an error? Seems strange
... doesn't fit.

ed: I've never seen this used.

heycam: let's nuke it

krit: could be useful for the video element?

ed: pretty simple to walk up and get the element you're
interested in

RESOLUTION: remove nearestViewportElement and
farthestViewportElement

krit: next issue is difficult (call getCTM on an 'svg'
element).
... svg element has scale and translate (currentTranslate,
currentScale). How does that get reflected in getCTM?

ed: resolved inside outside thing
... I think the example linked from there shows different
results in different browsers

krit: then just pick the one that makes the most sense

ed: example doesn't use currentScale. Different results even
with transform and viewport

heycam: needs more testing offline

<scribe> ACTION: krit to do testing around currentScale, CTM,
transform, viewport, etc. on 'svg' element [recorded in
[65]http://www.w3.org/2015/02/11-svg-minutes.html#action27]

<trackbot> Created ACTION-3724 - Do testing around
currentscale, ctm, transform, viewport, etc. on 'svg' element
[on Dirk Schulze - due 2015-02-19].

heycam: getTransformToElement. Was wondering what happens if
one element is in an iframe?

roc: getGeometry does this
... does anyone use this?

ed: nah

roc: why don't we move this to geometry utils and do it for all
elements?

heycam: who owns that spec?

roc: Simon

heycam: People will want this with HTML anyway.

roc: it's actually a pain to use.
... we have conversion methods. More convenient than getting
the matrix.
... so what's this used for?
... whatever it is, it's probably good for HTML as well.

heycam: converting points, e.g. from events

roc: we actually have better methods

ed: move elements around in the DOM tree

roc: geometryUtils has more convenient methods for that too
... 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.

krit: for SVG 2 we'll leave it in for now. Can deprecate it.

ed: will measure it. Can leave it in but with issue.

roc: who implements this?
... oh. we do. Damn

<scribe> ACTION: ed to measure usage [recorded in
[66]http://www.w3.org/2015/02/11-svg-minutes.html#action28]

<trackbot> Created ACTION-3725 - Measure usage [on Erik
Dahlström - due 2015-02-19].

krit: that doesn't solve the issue

heycam: true, if we decide to keep it
... a minimal thing is to test what impls are doing and spec
that for now.
... so we'll just update definition to fragment and move to
GeometryUtils later, if we can't drop it.
... hasExtension.

ed: Gecko and WebKit check for XHTML, MathML. Blink always
returns false.

krit: according to discussion on WhatWG

heycam: related to hasFeature which is what was discussed

ed: not sure it's very useful

heycam: I'd be surprised if people are calling this function

krit: let's just return false.

heycam: or remove it?
... don't think anyone is using it.

RESOLUTION: remove hasExtension

CHAPTER 4

heycam: this is ed's chapter

ed: first issue, namespaces in XML. Do we need all of it?

heycam: should have some wording about syntax. Should there be
such a big focus on embedding in foreign XML namespaces?

ed: not sure what to put there, but maybe more about HTML?
... issue 2. Value column doesn't match new attribute syntax

heycam: need to figure out consistent formatting
... across the spec

ed: next. When zero is used on an outer 'svg' element, does
this disable rendering? (for width, height)

heycam: good question.

ed: doesn't disable rendering. Overflow could be rendered.

heycam: is that only if you don't have a viewbox?

ed: good question.

krit: probably a special case.

ed: currently says it disables rendering. Not a change from
1.1. Let's keep it this way.

heycam: consistent with rectangles and other things
... question before: if you've got borders or backgrounds on
the outer SVG, do they keep rendering?
... probably should keep rendering the box stuff and the
content is disabled.
... maybe just add a note saying that the boxy stuff still
renders

krit: one issue, it's not the specified value but the computed
value that counts.

heycam: what happens in CSS if you have a 0 width box, and
box-sizing that lets the borders appear outside?
... if you set the width of a box to 0 can things still render?

TabAtkins: yup
... box sizing still floors out at 0, so even if borders are
internal they still render.

ed: issue 4 is a bout playbackOrder. Already decided to make it
lowercase. How can we harmonize with Web Animations

krit: this is the one we could defer to L3, right?

shane: would like to talk about this with Brian as we have a
similar problem in WA (talked about it yesterday)

krit: if we defer then you have time to figure a solution out.

ed: next issue, can we define seeking backwards so that there
is no undefined behaviour?

shane: if we can figure out playbackOrder as part of Web
Animations then there won't be undefined behaviour.

ed: can just link to it from here then.
... next issue already resolved.
... next, timelineBegin. Resolved on this. Should just link to
Web Animations.
... next. What about when SVG fragment is within an XHTML
document? Is there a single timeline for the whole document?
When does it start?

<scribe> ACTION: birtles to specify something simple and
consistent for timeline start in Web Animations. [recorded in
[67]http://www.w3.org/2015/02/11-svg-minutes.html#action29]

<trackbot> Created ACTION-3726 - Specify something simple and
consistent for timeline start in web animations. [on Brian
Birtles - due 2015-02-19].

RESOLUTION: adopt whatever Web Animations behaviour is specced
and link to it from here.

ed: some paragraphs are out of place.
... svg handles same events as body.

krit: doesn't seem out of place as we're talking about svg here

heycam: I think these should be in the interaction chapter but
it isn't important

RESOLUTION: Leave 'em

ed: next issue, about accessibility

krit: could add a note that these will be handled by a WG note
in the future.

heycam: what's happening with the a11y appendix? It also
contains waffle language like this.

krit: had an external document before. Very old though.

ed: what should we do?

heycam: this paragraph is very superficial

krit: can we just remove the section?

RESOLUTION: Drop the paragraph

ed: next issue. Let's drop the <g> example

RESOLUTION: Drop the <g> example

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.

nikos: maybe to do with blending and compositing

heycam: can just remove this sentence

nikos: any specific point can be made in rendering chapter

RESOLUTION: remove this sentence

ed: next issue, accessibility in 4.3.1

heycam: should remove this sentence too.

krit: should just make it a note

heycam: ed can choose

ed: next issue. Term for definition elements?

heycam: things like filter, clippath, etc.
... actually, changed it. This issue doesn't apply any more.

ed: next issue, in 4.3.2 (defs).
... paragraph not needed

krit: example can go too

RESOLUTION: remove paragraph and example

<TabAtkins> ScribeNick:TabAtkins

ed: Issue 17, the discard element. Move that to animation
chapter?

heycam: It's pretty animation-y to me.

ed: Agree.

cyril: Yeah, sure.

shane: We should be able to describe <discard> in terms of Web
Anim.

krit: The IDL is missing for that?

cyril: I couldn't figure out how to do it.

ACTION cyril to add the IDL for <discard> and move it to
animation chapter.

<trackbot> Created ACTION-3727 - Add the idl for <discard> and
move it to animation chapter. [on Cyril Concolato - due
2015-02-19].

ed: Issue 19, also on the discard element
... Something about the attribute syntax needs fixing.

heycam: It's the list syntax thing. I'll fix it.

ed: Issue 20, I'll figure out if we need to import any text.

krit: Issue 21

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.

RESOLUTION: Drop the offending sentence about styling <title>.

<tantek> I for one think <title> ought to be optional.

ed: Issue 22, lang needs to be defined.

heycam: <glyph> got removed, and lang links down to xml:lang.
AS part of updating xml:lang to lang, should hopefully jsut
work.

RESOLUTION: Remove issue 22.

RESOLUTION: Remove issue 22.
... Drop the offending sentence about styling <title>.

heycam: Issue 23 is about foreign namespace content inside of
<desc>. Who does that?

ed: I'm in favor of removing the example.

RESOLUTION: Remove the example about foreign-namespace content
in <desc>.

heycam: I'll look into Issue 24.

ed: I guess both 24 & 25 would be described by a11y

ACTION ed to talk to Rich about issues 24/25 (terminology
around title/desc/aria stuff)

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

<shane> tantek: no worries, any time :)

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

ed: structure chapter issue 27
... not sure what it means
... talks about templated elements

heycam: it's kind of true, but maybe templates is not the best
way of describing it

ed: I'll figure out a way to describe it
... issue 28
... defining use in terms of web components

krit: I talked with pdr and dmitri
... but I forgot what they said
... maybe Tab when you're back you can talk with pdr and dmitri
and figure out how to do it?

TabAtkins: ok

shane: has use changed?

ed: we do refer to web components for event propagation

krit: and web components works a bit differently

shane: my naive understanding of old use is that you couldn't
define it in terms of web components

krit: true it's still a special case

Tav: what are the differences?

krit: I think at least because it's isolated

TabAtkins: we've changed how web components work a bit too
since this was written

ed: would be nice to get someone to detailed review how to do
it with web components

Tav: what's the gain?

TabAtkins: reducing the number of spec concepts
... use is almost a web component, but not exactly, so that's
weird

Tav: any change in behaviour?

TabAtkins: maybe minor changes in behaviour which we'd try to
minimise

krit: in blink it is implemented in terms of web components

TabAtkins: allt he major behaviours should be preserved

<scribe> ACTION: TabAtkins to talk with pdr and dmitri about
how to describe <use> with web components [recorded in
[68]http://www.w3.org/2015/02/11-svg-minutes.html#action30]

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

ed: next, issue 29
... does display prevent shadow trees from being created?

TabAtkins: no
... it'll just prevent layout/rendering
... but shadow tree is a dom concept
... depending on exactly how we define stuff, script will not
run in instances?

ed: agree script doesn't run in instances?

heycam: yes

TabAtkins: yes

ed: what about audio elements?

TabAtkins: they should run just fine
... in the <template> based approach, they're inactive in there
... <use> doesn't do that, since you're pointing to an
arbitrary element
... but yes once stamped out they will run

ed: issue 33

"How should @media rules work when an external resource is
referenced?"

ed: I don't think SVG is clear whether there is a defined
viewport when you reference something external
... some CSS things depend on having a window/size

TabAtkins: what's an example?
... the <img> element pointing to something?

ed: no, <use> pointing to something external
... we load the external document in something that's not a
frame
... so some style stuff would crash on that
... we should say how that works

roc: I think the logical thing is to treat it as a display none
iframe
... I hope that's what we do

<krit> scribeNick: krit

ed: can we resolve on roc's proposal?

krit: does it follow the rules of the dimension of an iframe if
there is no intrinsic size or intrinsic ratio

roc: we need to define it

krit: think we should explicitly define a default intrinsic
size if there is none

roc: we just need to define something

<scribe> ACTION: ed Define viewport for external document when
an element references an element in this document [recorded in
[69]http://www.w3.org/2015/02/11-svg-minutes.html#action31]

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

krit: it does also effect other elements like paint servers
that reference external paint servers

ed: we should define it in a special section then. Loading
maybe.
... animation in external resources should they run?

roc: we do run animations
... you want a model for external resources that we want to use
for images
... images support animations so should external resources with
the same rules

BogdanBrinza_: if scripts get images with external resources is
that a problem?

roc: an image can not load other resources
... I think there is a strong requirement to do what external
images with animations do

RESOLUTION: Animations in external resources should run

ed: next: should switch elements effect if a child element
applies?
... you don't can't toggle style with a switch element

RESOLUTION: switch does not effect style

ed: next: does it make sense to implement view CSS and document
CSS?
... they should I think

RESOLUTION: ViewCSS should be on window and DocumentCSS on
document

TabAtkins: it is already defined on window

ed: we should remove the sentence in SVG

RESOLUTION: Remove ViewCSS and DocumentCSS

ed: next: pixelUnitsToPx/Em....
... they are useless and we should remove them

heycam: agree

RESOLUTION: Remove pixelUnitTo....

ed: next: pauseNaimations and onPauseAnimations do they use
WebAnimations
... do they apply to web animations?

birtles: they don't

ed: should we deprecte them?

birtles: they are useful

<scribe> ACTION: birtles pauseNaimations and onPauseAnimations
do not effect CSS animations [recorded in
[70]http://www.w3.org/2015/02/11-svg-minutes.html#action32]

<trackbot> Created ACTION-3731 - Pausenaimations and
onpauseanimations do not effect css animations [on Brian
Birtles - due 2015-02-19].

ed: next: getElementById
... we should remove it

heycam: agree

RESOLUTION: Remove getElementById on SVGSVGElement

chapter styling

heycam: presentaion attributes on every property we explicitly
support?
... they were maybe a bad decision in the first place but it
would be confusing if some exist and some don't?

roc: the confusion exists but it is not practical to solve it
for every property

heycam: in SVG it is general coding style

krit: I would be careful with adding more presentation
attributes

ed: I agree it comes with a cost

heycam: go back to the set of SVG 1.1 then?

krit: we added more already. Like transform-origin

ed: we should do it by case by case basis

heycam: then we should have a list in the spec
... we have a blue table with these attributes

krit: we should update the table with the new presentation
attributes like x, y, width and height

heycam: and paint-order
... I will come up with a new set of all properties

<scribe> ACTION: heycam update presentation property table
[recorded in
[71]http://www.w3.org/2015/02/11-svg-minutes.html#action33]

<trackbot> Created ACTION-3732 - Update presentation property
table [on Cameron McCormack - due 2015-02-19].

<heycam>
[72]https://svgwg.org/svg2-draft/styling.html#UAStyleSheet

[72] https://svgwg.org/svg2-draft/styling.html#UAStyleSheet

heycam: next: UA style sheet (section 5.14)
... this is the overflow hidden thing
... the svg root part should disappear
... same for image

ed: the overflow for pattern is explicitly undefined since SVG
1.1SE

heycam: so we can remove this problem

Tav: if we remove it, you run into visible all the time while
now you run into it by accident

heycam: ok, can you apply a clip-path on a pattern? It is kind
of a similar thing as applying overflow on the pattern

Tav: can we make the overflow visible to default?

krit: then we can not explicitly allow it in the future with
defined behavior. So we should keep hidden

heycam: I agree

RESOLUTION: first rule on UA style: remove svg and image
... remove 2nd rule on UA style since width and height are
presentation attributes

<heycam> Scribe: cameron

<heycam> ScribeNick: heycam

roc: style, script, symbol { display: none; }
... you could override that to display:inline?

heycam: what about defs?

roc: related to referring to display:none things
... that's an issue to discuss later
... next is transform-origin
... a non-outermost-<svg> element has transform-origin: top
left

<krit> [73]https://www.irccloud.com/pastebin/pnDoiyiy

https://www.irccloud.com/pastebin/pnDoiyiy

*:not(svg),

*:not(foreignObject) > svg {

transform-origin: 0 0;

}

roc: it's slightly different from the WebKit rule

krit: for foreignObject you would have to put an html child

roc: you don't have, you could have an <svg> child of
<foreignObject>

krit: do we need to define this part?
... we have some more rules too
... we have svg:root { width: 100%; height: 100%; }
... this might be because we have width/height being a
presentation attribute
... in Gecko, you can set width/height attributes differently
from width/height properties
... or is that not true any more

roc: we don't have width/height reflected into CSS

krit: we do

roc: so for the root element you need to override those so that
the root element is displayed across the entire viewport
... ok

<krit> [74]https://www.irccloud.com/pastebin/tpiC8eFU

[74] https://www.irccloud.com/pastebin/tpiC8eFU

krit: so this makes inner <svg> overflow:hidden

roc: we also have a rule that is specific to SVG used in a font

[75]http://mcc.id.au/temp/overflow.svg

[75] http://mcc.id.au/temp/overflow.svg

if you see a quarter circle, then overflow:hidden is set for
inner svg

RESOLUTION: svg:not(:root) { overflow: hidden; } goes in the UA
style sheet

<scribe> ACTION: Cameron to investigate whether |symbol {
overflow: hidden }| UA style sheet rule is needed [recorded in
[76]http://www.w3.org/2015/02/11-svg-minutes.html#action34]

<trackbot> Created ACTION-3733 - Investigate whether |symbol {
overflow: hidden }| ua style sheet rule is needed [on Cameron
McCormack - due 2015-02-19].

trackbot: end telcon

Summary of Action Items

[NEW] ACTION: birtles pauseNaimations and onPauseAnimations do
not effect CSS animations [recorded in
[77]http://www.w3.org/2015/02/11-svg-minutes.html#action32]
[NEW] ACTION: birtles to specify something simple and
consistent for timeline start in Web Animations. [recorded in
[78]http://www.w3.org/2015/02/11-svg-minutes.html#action29]
[NEW] ACTION: Cameron to investigate whether |symbol {
overflow: hidden }| UA style sheet rule is needed [recorded in
[79]http://www.w3.org/2015/02/11-svg-minutes.html#action34]
[NEW] ACTION: Cameron to investigate which HTML elements like
<link> we might want to also allow in SVG [recorded in
[80]http://www.w3.org/2015/02/11-svg-minutes.html#action07]
[NEW] ACTION: Cyril don't stop [recorded in
[81]http://www.w3.org/2015/02/11-svg-minutes.html#action20]
[NEW] ACTION: ed Define viewport for external document when an
element references an element in this document [recorded in
[82]http://www.w3.org/2015/02/11-svg-minutes.html#action31]
[NEW] ACTION: ed Map xml:space to whitespace property values in
CSS3 Text [recorded in
[83]http://www.w3.org/2015/02/11-svg-minutes.html#action17]
[NEW] ACTION: ed Remove xml:base/space/lang from the SVG DOM
interface [recorded in
[84]http://www.w3.org/2015/02/11-svg-minutes.html#action12]
[NEW] ACTION: ed Remove xml:lang in favor for HMTL lang
[recorded in
[85]http://www.w3.org/2015/02/11-svg-minutes.html#action15]
[NEW] ACTION: ed to add usage counters to blink to measure
usage of animVal / baseVal [recorded in
[86]http://www.w3.org/2015/02/11-svg-minutes.html#action01]
[NEW] ACTION: ed to measure usage [recorded in
[87]http://www.w3.org/2015/02/11-svg-minutes.html#action28]
[NEW] 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.) [recorded in
[88]http://www.w3.org/2015/02/11-svg-minutes.html#action02]
[NEW] ACTION: ed Write tests and come back to the SVG for
xml:base [recorded in
[89]http://www.w3.org/2015/02/11-svg-minutes.html#action16]
[NEW] ACTION: Erik to do the attribute lowercasing [recorded in
[90]http://www.w3.org/2015/02/11-svg-minutes.html#action19]
[NEW] ACTION: Erik to verify that the SVGPathSeg interface use
counter values are correct and to drop the interfaces if they
are [recorded in
[91]http://www.w3.org/2015/02/11-svg-minutes.html#action18]
[NEW] ACTION: hey cam add stylesheet requirements to the spec
[recorded in
[92]http://www.w3.org/2015/02/11-svg-minutes.html#action10]
[NEW] ACTION: heycam Write tests and come back to the SVG for
xml:base [recorded in
[93]http://www.w3.org/2015/02/11-svg-minutes.html#action14]
[NEW] ACTION: heycam add stylesheet requirements to the spec
[recorded in
[94]http://www.w3.org/2015/02/11-svg-minutes.html#action11]
[NEW] ACTION: heycam Reference integration spec and update
conformance class for HTML support on foreignObject [recorded
in [95]http://www.w3.org/2015/02/11-svg-minutes.html#action09]
[NEW] 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 [recorded in
[96]http://www.w3.org/2015/02/11-svg-minutes.html#action03]
[NEW] ACTION: heycam to mark classname as deprecated (issue 4
in chapter 3) [recorded in
[97]http://www.w3.org/2015/02/11-svg-minutes.html#action24]
[NEW] ACTION: heycam to put this in the presentation attribute
section [recorded in
[98]http://www.w3.org/2015/02/11-svg-minutes.html#action26]
[NEW] ACTION: heycam to resolve issue 2 in Chapter 3 [recorded
in [99]http://www.w3.org/2015/02/11-svg-minutes.html#action23]
[NEW] ACTION: Heycam to specify that convertToSpecifiedUnits
should throw an exception if converting to percentage with
0-sized viewport. [recorded in
[100]http://www.w3.org/2015/02/11-svg-minutes.html#action25]
[NEW] ACTION: heycam update presentation property table
[recorded in
[101]http://www.w3.org/2015/02/11-svg-minutes.html#action33]
[NEW] ACTION: krit to do testing around currentScale, CTM,
transform, viewport, etc. on 'svg' element [recorded in
[102]http://www.w3.org/2015/02/11-svg-minutes.html#action27]
[NEW] ACTION: nikos to merge 2.5 into 2.7-2.9 [recorded in
[103]http://www.w3.org/2015/02/11-svg-minutes.html#action22]
[NEW] ACTION: nikos to rework chapter 2 and incorporate
references to external specifications [recorded in
[104]http://www.w3.org/2015/02/11-svg-minutes.html#action21]
[NEW] ACTION: Reference integration spec and update conformance
class for HTML support on foreignObject [recorded in
[105]http://www.w3.org/2015/02/11-svg-minutes.html#action08]
[NEW] ACTION: TabAtkins Allow templates in SVG which needs HTML
parser changes [recorded in
[106]http://www.w3.org/2015/02/11-svg-minutes.html#action06]
[NEW] ACTION: TabAtkins convince Hixie to make the HMTL parser
changes + x/y presentation attributes on the canvas,...
elements for SVG [recorded in
[107]http://www.w3.org/2015/02/11-svg-minutes.html#action05]
[NEW] ACTION: TabAtkins to talk with pdr and dmitri about how
to describe <use> with web components [recorded in
[108]http://www.w3.org/2015/02/11-svg-minutes.html#action30]
[NEW] ACTION: TabAtkins write the SVG layout spec [recorded in
[109]http://www.w3.org/2015/02/11-svg-minutes.html#action04]
[NEW] ACTION: Write tests and come back to the SVG for xml:base
[recorded in
[110]http://www.w3.org/2015/02/11-svg-minutes.html#action13]

[End of minutes]

--
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 12 February 2015 05:35:40 UTC