- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 28 Apr 2016 01:08:01 +0000
- To: www-svg <www-svg@w3.org>
Minutes from day two are at:
https://www.w3.org/2016/04/21-svg-minutes.html
And as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
20 Apr 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/04/20-svg-irc
Attendees
Present
Amelia, Chaals, LJWatson, Tav, nikos, stakagi
Regrets
Chair
nikos
Scribe
nikos, chaals, ?
Contents
* [3]Topics
1. [4]Introduction chapter
2. [5]Rendering chapter
3. [6]Chapter 3
4. [7]chapter 4 https://svgwg.org/svg2-draft/struct.html
5. [8]Defining use in terms of Shadow DOM
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<scribe> Scribe: nikos
<scribe> Scribenick: nikos
<chaals> Meeting: SVG
Introduction chapter
[11]https://svgwg.org/svg2-draft/intro.html
[11] https://svgwg.org/svg2-draft/intro.html
[12]https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=label%
3A%22London+2016%22+
[12] https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=label%3A%22London+2016%22+
<LJWatson> In the sentence that starts "Sophisticated
applications of ...", should the word "the" be inserted before
the link to "SVG Document Object Model (DOM"?
<chaals> change "mixed with HTML5, it uses the HTML5 syntax ["
to "SVG code is used inside HTML documents it uses the HTML
syntax ["
<chaals> 1.2, list item 2, s/document/documents/
<chaals> 1.2 last item s/is compatible with W3C work on Web
Accessibility/provides support for making accessible graphics./
nikos: Do you have the updated links to DOM specs?
<AmeliaBR> This is the new CSSOM, still a working draft:
[13]https://www.w3.org/TR/cssom-1/
[13] https://www.w3.org/TR/cssom-1/
<chaals> proposed last para replacement for 1.1: SVG is useful
for rich graphical presentation of information, including a
number of _accessibility features that, used correctly_, ensure
the content can be used by the widest possible audience. But a
direct link to source data, where possible, is helpful for many
people to understand the content provided.
<LJWatson> +1 Chaals.
<chaals> ( _underlined stuff_ links to accessibility chapter,
which is going to get some more things in it…)
<chaals> in 1.1 p3 s/such as
‘[14]https://svgwg.org/svg2-draft/interact.html#EventAttributes
’ and
‘[15]https://svgwg.org/svg2-draft/interact.html#EventAttributes
’ //
[14] https://svgwg.org/svg2-draft/interact.html#EventAttributes
[15] https://svgwg.org/svg2-draft/interact.html#EventAttributes
<chaals> and s/Because of its
[16]https://svgwg.org/svg2-draft/intro.html#W3CCompatibility,
features like//
[16] https://svgwg.org/svg2-draft/intro.html#W3CCompatibility,
<chaals> and change the rest of the sentence to "In a Web page,
the same scripts can work on SVG and HTML elements."
<chaals> "terminology" is definitions, and these are scattered
throughout. The RFC 2119 para is about "Conformance" - an maybe
should be part of something more about the topic.
<chaals> Don't sweat the links to DOM, but references will need
to be updated as a final pass…
<chaals> [Nikos committed changes]
Rendering chapter
chaals: paragraph 3 of 2.2 isn't strictly true
... there are manipulations that you can make in terms of event
handlers and changing styling
... I'd remove that paragraph
[Removed last sentence: However, they are always reflections of
the original element, and are not directly manipulable by
script or user interaction. ]
chaals: Is z-index implemented anywhere for svg?
AmeliaBR: no
chaals: Should remove it from the spec then, or mark it at risk
<AmeliaBR> Could encourage authors to put pressure on
implementers, too.
<LJWatson> Suggest changing "The elements in an SVG document
are each either rendered or non-rendered at a given point in
time." to "At any given time, an SVG element is either rendered
or non-rendered."
<chaals> 2.7.1 para 5 should add "or vice versa", or just have
the first bit up to "operations;" put at the beginning of para
4 and the rest thrown away.
<LJWatson> Suggest changing "Non-rendered elements likewise
have no counterpart in an accessible alternative view of the
document." to "Non-rendered elements are not represented in the
document accessibility tree."
<chaals> proposal for first section:
<chaals> Implementations of SVG are must implement the
rendering model as described in this chapter, as modified in
the appendix on conformance requirements which describes
situations where an implementation may deviate.
<chaals> In practice variability is allowed based on
limitations of the output device (e.g. only a limited range of
colors might be supported) and because of practical limitations
in implementing a precise mathematical model (e.g. for
realistic performance curves are approximated by straight
lines, the approximation need only be sufficiently precise to
match the conformance requirements).
<chaals> err, s/are must/must/
<AmeliaBR> S 2.4 is problematic, confuses z-axis and z-index,
which is quite different from z-axis in 3D transforms
<chaals> Need to explicitly write in "a shape can have filters
applied, then clips applied, then masks"
<Tav> S 2.7 s/shapes/Shapes/
<chaals> please s/UA/User Agent/g#exceptWhereItDoesn'tMeanThat
<chaals> (e.g. note as lat para in this chapter)
<AmeliaBR> Need to more clearly describe each aspect of
rendering process as an order of operations. And re-arrange if
necessary, e.g. "how groups are rendered" should come after the
"painting shapes & text" / "images" section
<AmeliaBR> Hi stakagi, feel free to follow along, we're doing a
chapter-by-chapter review, just wrapping up Ch2
<stakagi> Thanks Amelia!
<chaals> [break. back at 10 past whatever is next]
<AmeliaBR> ACTION Amelia to review rendering chapter text re
z-index to make compatible with 3D transforms
<trackbot> Created ACTION-3838 - Review rendering chapter text
re z-index to make compatible with 3d transforms [on Amelia
Bellamy-Royds - due 2016-04-27].
<chaals> scribe: chaals
<nikos> nikos: Regarding issue 13 in the rendering chapter,
this may be nice to have but not essential for CR, so I'm going
to file a github issue and remove the issue from the spec
CMN: at the end of sections that describe e.g. filling and
stroking and markers are independent and ordered according to
X, there should be a "user agents must …" statement, that can
be tested.
<nikos> nikos: Added issue for user agent implementation
requirements language -
[17]https://github.com/w3c/svgwg/issues/106
[17] https://github.com/w3c/svgwg/issues/106
Chapter 3
CMN: 3.3 needs a pointer to what IEE finitie single presicions
values are.
ABR: Do we use both EBNF and ABNF?
... language tag references ABNF
NA: We use EBNF
ABR: In path data…
... would be nice to reduce the number of ways we describe
things.
NA: Think the annotation in 3.4.2 is "done" - we have methods.
CMN: What is the status of annotation 1 in 3.5.4?
[discussion about whether to use MathML, LaTeX or both…]
[conclusion: have MathML+mathjax for rendering, keep pointers
to the LaTeX to simplify editing]
<nikos> transformToElement removal discussion
[18]https://www.w3.org/2015/06/09-svg-minutes.html#item01
[18] https://www.w3.org/2015/06/09-svg-minutes.html#item01
ABR: What happened to that
... thought we were going to add a warning about Dragons in
implementations and hope CSS would solve it. Seems that they
just got tossed out.
NA: Yes we have done the making SVGList* nicer. So status to
"done"
<nikos> Tav: Here's previous discussion about marker:overflow
remaining hidden -
[19]https://www.w3.org/2015/08/25-svg-minutes.html#item06
[19] https://www.w3.org/2015/08/25-svg-minutes.html#item06
CMN: need to s/IDL attribute _reflects_/IDL attribute must
_reflect_/g as a User Agent requirement
... I'll add that to #106
... IEEE link -
[20]https://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#ieee754
??
... I mean
[21]http://standards.ieee.org/findstds/standard/754-1985.html -
and you can buy this. Maybe we should use an altenative
reference, or write this out in full?
[20] https://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#ieee754
[21] http://standards.ieee.org/findstds/standard/754-1985.html
TB: Everyone will use what their computer implements as single
arithmetic.
CMN: So let's say that's OK and be done, no?
TB: sure.
CMN: raised as #109 [22]https://github.com/w3c/svgwg/issues/109
[22] https://github.com/w3c/svgwg/issues/109
ABR: 3.4.3 is where the path methods were moved. There should
be a statement about Path or Equivalent path.
... I'm going to come up with an edit now.
<AmeliaBR> Remove "text" from 1st para of 3.4.3. Add sentence
at end "For basic shapes, calculations use the equivalent
path."
chapter 4 [23]https://svgwg.org/svg2-draft/struct.html
[23] https://svgwg.org/svg2-draft/struct.html
CMN: Overview should note that standalone SVG must be XML.
[discussion about multiple svg elements]
ABR: the confusing bit is where you have foreignObject and
inside that an svg element - that creates a new SVG fragment.
CMN: SVG-in-HTML example should have html tags to make it
clearer ...
... in 4.1.2
... status of annotation 1- transform on svg element?
ABR: there are bugs
Tav: Only on non-standalone.
... is marker a structural element?
[no]
LJW: the "show" expansion thing doesn't play nicely with the
screenreader.
ABR: Will raise an issue for that.
CMN: 4.3, annotation 2, should be status "done"
<AmeliaBR> Make first para: "An SVG document fragment consists
of an ‘svg’ element and descendent content that uses the SVG
layout model. Each SVG document fragment is rooted by an 'svg'
element that is either the root element of the document or a
child of an element that is not in the SVG namespace."
Tav: should we remove "svg-enabled browsers only"?
[yes]
CMN: 4.4.1 refers to RFC3987 but the intro says we use whatwg
URL for urls.
... defs are pumped out to the accessibility tree in
implementations, and should not be.
... spec bug or implementation issue?
ABR: implementation bug - SVG AAM says the right thing.
<LJWatson> Suggest adding "can be" into the following sentence:
"The attribute 'lang’ *can be* added to allow
internationalization of the..."
[discussion of issue-63]
RESOLUTION: If you want something taht's not SVG to render, put
it in foreignObject. Otherwise it doesn't - like the spec says
already.
RATIONALE: defining anything else gets messy and painful for no
known value.
Tav: what about properties on such elements? They don't render
so who cares?
NA: If you have an unknown element with style attributes, are
those inherited by children that are SVG?
CMN: What do implementations do here?
Tav: think we were going to define an explicit set of things
that would work.
ABR: One reason for the question was to enable adding new
elements without having documents fail.
NA: FF doesn't treat unknown elements as a group.
ABR: We describe lists of attributes that you can use anywhere.
Can we have generic language that says any allowed SVG
attributes can be applied.
CMN: which is the point of treating unknown elements as g
Tav: if we treat an unknown element as a g, they are a
container.
NA: doesn't talk about interfaces, just tagnames.
CMN: what is the practical impact of the decision?
NA: We talk about container elements…
ABR: Think treating unknown elements as g does this
[agreed]
NA: simple thing is "replace the element name with a g". any
downside to that?
... do we want to tell people not to make things up?
CMN: No, at some point we will have custom elements…
LJW: What's the story about tooltips on title?
ABR: I have an oustanding action to chase that up.
<nikos> [24]https://github.com/w3c/svgwg/issues/101
[24] https://github.com/w3c/svgwg/issues/101
ABR: as part of dealing with title, desc, …
... empty titles and descs are a pain. We'd like to have an
authoring fail for doing that.
... needs to be must not for authoring tools.
CMN: That is in ATAG already, right?
ABR: another issue is for unknown or no language for title/desc
content.
... e.g. <title lang="en">smile</title><title
lang="fr">sourire</title><title lang="">:)</title>
<LJWatson> 4.5.1: "assistive technologies" should be "assistive
technology" in the following sentence: "An author may also
expose a hidden label on an element to an assistive
technologies through..."
CMN: can we please put the elements defined in these blocks on
the left, with the other text
NA: We probably need to do a rewrite to bikeshed and clean up
the markup all over the place.
... Are annotation 4/5 on markers done?
CMN: seems so.
<Tav>
[25]https://www.w3.org/TR/2004/WD-SVG12-20041027/applications.h
tml Tooltips
[25] https://www.w3.org/TR/2004/WD-SVG12-20041027/applications.html
<nikos> [26]https://github.com/w3c/svgwg/issues/102
[26] https://github.com/w3c/svgwg/issues/102
[remove issue-20 marker. SVG 1.2 isn't the source of
information we were looking for]
ABR: I'll edit the title of the issue to make it the more
general one.
... Annotation 6 on use elements has been done.
Tav: What about issue-23, including namespaced content in desc?
CMN: The use case is to allow for structured content in a desc
- e.g. an overall description of a substantial image, which
can't be well-described with flat text.
... but there isn't much implementation support. The
alternative is to have the structure as part of the SVG itself
so the desc strings are just the leaf nodes at the end of that.
ABR: Should be a warning about what happens when you add things
- only plain-text content gets used in e.g. AAM
<scribe> ACTION: chaals to write up desc nodes being leaves in
a structure that can be explored, since they are really only
being exposed as plain text. [recorded in
[27]http://www.w3.org/2016/04/20-svg-minutes.html#action01]
[27] http://www.w3.org/2016/04/20-svg-minutes.html#action01]
<trackbot> Created ACTION-3839 - write up desc nodes being
leaves in a structure that can be explored, since they are
really only being exposed as plain text. [on Charles McCathie
Nevile - due 2016-04-27].
CMN: to return to Amelia's question, are we going to define use
in terms of web components/shadow DOM in the SVG2 timeline
[metadata elements. They are useful as scatterable, but why
only one in a specific place?]
ABR: We don't define what metadata *does* so why do we tell you
where to put it?
... no reason to recommend one way or the other.
RESOLUTION: stop telling people where they should or shouldn't
put metadata.
[lunch: Just going out. We may be some time]
<scribe> scribe: ?
<nikos> scribe: nikos
Defining use in terms of Shadow DOM
AmeliaBR: One of the benefits of the shadow dom architecture is
that it's divided into many modules
... so we can have an SVG specific definition and then
synchronised sections that use the other specs
... The way the shadow dom is created and the way that it is
live linked to mutations in the source is SVG unique
... However, once we define a use element as being a shadow dom
host, and the repeated content as the shadow dom
... then we can start using some of the CSS rules and some of
the event handling rules
... and DOM interfaces
... For CSS, this helps address some of the issues we've had
with defining what to do with styles in an external file
... Think currently we say this is undefined in the spec.
... So we treat files in the external file similarly to styles
scoped within a web component
... The question is does that make sense.
... Ok so this might not work, in the CSS shadow dom scoping,
rules defined in the main document override rules defined in
the source content
... as far as matching actual shadow dom elements goes
<AmeliaBR> Shadow DOM spec:
[28]https://www.w3.org/TR/2015/WD-shadow-dom-20151215/
[28] https://www.w3.org/TR/2015/WD-shadow-dom-20151215/
<AmeliaBR> CSS Scoping / Shadow Encapsulation:
[29]https://drafts.csswg.org/css-scoping/#shadow-dom
[29] https://drafts.csswg.org/css-scoping/#shadow-dom
<AmeliaBR> pinging @TabAtkins if you're online yet, we'd love a
translation of the shadow encapsulation cascading rules
AmeliaBR: maybe it just means that objects with the deep
combinator match, but if it means that all do then that's a
problem
<chaals>
->[30]http://chaals.github.io/testcases/svg-multi-lang-title-ma
nual.html testing for multilingual titles]
[30] http://chaals.github.io/testcases/svg-multi-lang-title-manual.html
<AmeliaBR> Chrome (which supports width/height as presentation
attributes) currently treats non-auto values on <symbol> the
same as they would on a re-used SVG.
[31]https://jsbin.com/cunabarimu/edit?html,css,output
[31] https://jsbin.com/cunabarimu/edit?html,css,output
<AmeliaBR> I recommended standardizing that behavior,
re-writing that section (under use element s4.8) to refer to
content that has a (default or specified) viewBox and non-auto
values of width/height
<AmeliaBR> Firefox also renders the same, but probably for
different reasons inside the implementation.
AmeliaBR: I don't think we can define use in terms of web
components now, but we should add a note stating that it may be
done in future
<TabAtkins> AmeliaBR: I have a significant rewrite of the
Shadow DOM section of CSS Scoping, which I'm just doing final
fixup of right now.
<TabAtkins> It'll be available today.
<TabAtkins> Do *not* depend on the current spec; it's based on
the 2+ year-old version of Shadow DOM.
<AmeliaBR> OK. Do you think it will be compatible with <use>?
<AmeliaBR> Specifically, selectors in the main doc never match
content the re-used content.
<TabAtkins> AmeliaBR: Yes, that's def true.
<TabAtkins> And inheritance goes thru the shadow boundary.
<AmeliaBR> TabAtkins: OK, text in
[32]https://drafts.csswg.org/css-scoping/#shadow-cascading
wasn't clear, since it talks about rules from outer document
taking precedence over rules from inside the shadow. But I
guess that was in reference to "deep" selectors.
[32] https://drafts.csswg.org/css-scoping/#shadow-cascading
<TabAtkins> Correct.
<AmeliaBR> That's fine, then. Not breaking backwards-compat
<TabAtkins> There's still some ways that rules in different
trees can compete with each other, but they're specialized -
like something in the light dom that is pulled into the shadow
via <slot>.
<AmeliaBR> Makes sense. But again, not a deal-breaker for
<use>. Now just need to figure out whether we can make sense of
the event-handling/-retargetting rules.
<TabAtkins> Yeah, those are questions for annevk in
Freenode#whatwg.
Reagent, make minutes
Summary of Action Items
[NEW] ACTION: chaals to write up desc nodes being leaves in a
structure that can be explored, since they are really only
being exposed as plain text. [recorded in
[33]http://www.w3.org/2016/04/20-svg-minutes.html#action01]
[33] http://www.w3.org/2016/04/20-svg-minutes.html#action01
Summary of Resolutions
1. [34]If you want something taht's not SVG to render, put it
in foreignObject. Otherwise it doesn't - like the spec says
already.
2. [35]stop telling people where they should or shouldn't put
metadata.
[End of minutes]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 28 April 2016 01:08:34 UTC