W3C

- DRAFT -

SVG Working Group Teleconference

21 May 2018

Attendees

Present
liam, dstorey, BogdanBrinza, AmeliaBR, ChrisL
Regrets
Dirk
Chair
SV_MEETING_CHAIR
Scribe
liam

Contents


Publishing updated CR for SVG 2.0 and FPWD for SVG 2.1

[ https://www.w3.org/2018/Process-20180201/#revised-cr is what the process says about revising a CR ]

<chris> https://www.w3.org/TR/2016/CR-SVG2-20160915/

https://www.w3.org/Guide/transitions?profile=CR&cr=substantive has the steps to follow in more detail, useful for team, editors & chairs

RESOLUTION: Publish updated CR and FPWD of SVG 2.1

RESOLUTION: Publish updated CR for SVG 2.0 and FPWD for SVG 2.1, pending WG review of the issues opened since the last published CR (September 2016)

<chris> could we have a slightly more precise resolution

<chris> ok good

<scribe> ACTION: BogdanBrinza to review list of participants & editors for SVG 2.0 CR

<trackbot> Created ACTION-3868 - Review list of participants & editors for svg 2.0 cr [on Bogdan Brinza - due 2018-05-28].

<scribe> ACTION: BogdanBrinza to review github issues against SVG 2.0 and mark them for 2.1 where approriate, open/closed, post resulting list to WG

Review remaining items “at risk”

<trackbot> Created ACTION-3869 - Review github issues against svg 2.0 and mark them for 2.1 where approriate, open/closed, post resulting list to wg [on Bogdan Brinza - due 2018-05-28].

<BogdanBrinza> https://onedrive.live.com/view.aspx?cid=fd9e7123283f274c&page=view&resid=FD9E7123283F274C!594647&parId=FD9E7123283F274C!103&app=Excel

<AmeliaBR> https://github.com/w3c/svgwg/issues/363

Amelia: we've pretty much agreed shadow trees should be closed, so there's no use having these shadow properties, as they're about inspectring the shadow element, which are not inspectable

RESOLUTION: use closed shadow DOM and remove correspondingElement and correspondingUseElement

dstorey: ShadowAnimation is for CSS animations, right?

ChrisL; sounds like a great feature but doesn't sound fully-baked or implemented so maybe not for 2.0?

AmeliaBR: well, we need to say what should happen for use elements. [Impl'n dependent] would accurately reflect reality!

chris: doesn't sound 2.0-ish

it's a well-articulated feature that deserves to be in SVG

AmeliaBR: the SVG 1.1 section of the spec is even less close to reality than what we have here

could say, Interaction between "use" and animations will be defined in a later spec

chris: sounds reasonable to me for 2.0, and we could continue to develop the spec in the 2.1 draft

AmeliaBR: also, Web Animations spec isn't at CR yet

BogdanBrinza: we don't have any implementations of this feature, so we'll have to remove it for 2.0 in any case

AmeliaBR: i think the wording is, if you implement Web Animations then this is how the use element is done

So the idea is to take it out of 2.0, replace with a short "not yet defined" warning, and continue work in 2.1

RESOLUTION: Remove ShadowAnimation from SVG 2.0, keep in 2.1 - replace with a note that <use> element animations tbd in 2.1+

<AmeliaBR> I can make the edits specifically re ShadowAnimation, but it's related to the previous resolution about closed shadow trees, which will need a lot more editing work: affects many details of the spec. If anyone wants to tackle that, it would be helpful.

getBBox Extended

AmeliaBR: this is so you can get a bbox tha tinclude the stroke area, or markers, or produced by any clipping, or any combination

Much requested, very useful, but no implementations

BogdanBrinza: not fair to discuss this one without Dirk

isPointInFill

dstorey: we have two implementations

liam: do we have tests?

AmeliaBR: probably not & there are some open issues about details

but within the range of things we want to clean up & get interoperable rather than defer

BogdanBrinza: isPointinFill & stroke, might have tests that were submitted by Google but not yet accepted

RESOLUTION: keep isPointInFill & isPointInStroke in SVG2

cross-origin

dstorey: ff supports CO-script, anotherbrowser supports co-image

AmeliaBR: so this is at risk

chris: can't imagine browsers would say, we're not going to do that

AmeliaBR: got to get implementers looking at it in case there are details where they want spec changes

dstorey: might want just to point to the HTML spec

AmeliaBR: the details already reference HTML

RESOLUTION: keep cross-Origin features but mark them at risk

<BogdanBrinza> RESOLVED at-risk crossOrigin on image and script elements

AVGAElement/rel

dstorey: oops, it's in the wrong order

Marker

AmeliaBR: error in this table, orient is implemented, but exposing the new values isn't, and we resolved recently to allow them to be exposed via the DOM, so no implementations of this new resolution not-yet in the spec :) but we do of the rendering impact
... as part of any edits relating to exposing new attribute values in DOM, this should be marked as at risk

but the attribute value is not at risk

BogdanBrinza: those are content attributes, not IDL, right?

[Amelia, Chris] yes

dstorey: so want to make the IDL attribute at risk?

AmeliaBR: it's not being exposed when you set it to a new value

chris: seems reasonable that the implementations would expose the new value since they compute it

AmeliaBR: I see this as a bug in the spec that we're fixing

<AmeliaBR> https://github.com/w3c/svgwg/issues/424

RESOLUTION: keep orient attribute but set to at-risk

<AmeliaBR> (At-risk details only with respect to unimplemented IDL enum values)

[dstory agrees to update the spreadsheet to mark Edge and ff as having intent & change description to say it's only the UDL for orient]

SVGAElement properties

attributes on A element

<BogdanBrinza> RESOLVED keep the new SVGAElement attributes and set to At-Risk

RESOLUTION: the 4 attributes rel, download, relList, type, are kept but at risk

hyperlink mixin

Amelia: same as the last one as far as decision?

The feature in our spec is including that mixin in SVG. We are hoping that, if it's implemented, it'll be done as a package deal, everything from the mixin at once, but whether it's included at all is the question.

dstorey: v. similar to the ones above. so makes sense to keep it

RESOLUTION: keep HTMLHyperlinkElementUtils mixin and set to at-risk

DocumentAnd ElementEventHandlers mixin

dstory: we just implemented this in Edge

[may be some interop issues]

AmeliaBR, we can just leave it and deal with it by testing

dstory: we already have 2 implementations anyway

[so not at risk]

RESOLUTION: keep DocumentAndElementEventHandlers mixin in SVG 2

any other things at risk to review?

AmeliaBR: there are others. You were looking at changes to interfaces, and lots of rendering things don't necessarily get exposed in interfaces

z-index is biggest one for me that's still at risk

dstory: I think those are all marked at risk already

AmeliaBR: Multiple title and desc for localizations, no implementations, might be worth deferring

Zoom and pan is an SVG 1.0 feature

liam: don't have to worry about svg 1.x features here right now, only changes since 1.1

AmeliaBR: Nested Links - may want to defer cleaning up current interop problems

similarly, guidance on hw to handle unknown elements & creating an interface for that

do we want to consider that as a compat thing or as a new feature that can be deferred?

and vector-effect options other than non-scaling-stroke might need to be deferrred as not heard of implementations

BogdanBrinza: from implementors' pov i'd say none of those things are real problems we're going to solve any time soon

and for vector effect, stroke is the only one we're interested in based on feedback from authors

AmeliaBR: i think we can resolve to defer vector-effect, multi-lingual title & desc.

z-index is harder to defer as parts of hte spec get into the interaction with css & boxes, so would need a lot of editing work to remove

and unknown elements & nested links, not sure we can come up with a good enough spec that's interoperable

dstorey: need to find out what all the browsers do

liam: as long as they're marked at sisk, as they are, we can remove them/defer them right at the end of the CR eriod if necessary, don't need to resolve now

BogdanBrinza: next few meetings probably spent on reviewing issues, and we'll go from there

AmeliaBR: it'd really help to know which issues are resolved but where the spec isn't yet changed.

[adjourned]

Summary of Action Items

[NEW] ACTION: BogdanBrinza to review github issues against SVG 2.0 and mark them for 2.1 where approriate, open/closed, post resulting list to WG
[NEW] ACTION: BogdanBrinza to review list of participants & editors for SVG 2.0 CR
 

Summary of Resolutions

  1. Publish updated CR and FPWD of SVG 2.1
  2. Publish updated CR for SVG 2.0 and FPWD for SVG 2.1, pending WG review of the issues opened since the last published CR (September 2016)
  3. use closed shadow DOM and remove correspondingElement and correspondingUseElement
  4. Remove ShadowAnimation from SVG 2.0, keep in 2.1 - replace with a note that <use> element animations tbd in 2.1+
  5. keep isPointInFill & isPointInStroke in SVG2
  6. keep cross-Origin features but mark them at risk
  7. keep orient attribute but set to at-risk
  8. the 4 attributes rel, download, relList, type, are kept but at risk
  9. keep HTMLHyperlinkElementUtils mixin and set to at-risk
  10. keep DocumentAndElementEventHandlers mixin in SVG 2
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/05/21 19:30:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Publish/Publish updated CR and FPWD of SVG 2.1/
Succeeded: s/BogdanBrinza,/BogdanBrinza:/
Succeeded: s/to be resolved/to be exposed via the DOM/
Succeeded: s/DECISION/RESOLVED/
Succeeded: s/title, desc/multi-lingual title & desc/
Default Present: liam, dstorey, BogdanBrinza, AmeliaBR, ChrisL
Present: liam dstorey BogdanBrinza AmeliaBR ChrisL
Regrets: Dirk
No ScribeNick specified.  Guessing ScribeNick: liam
Inferring Scribes: liam

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 21 May 2018
People with action items: bogdanbrinza

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]