<ericwilligers> I suggested a few topics: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3AAgenda%2B
<scribe> scribe: liam
[Dirk and Eric discuss testing on preview versions of various browsers]
Dirk: i've implemented more SVG behaviour in Webkit
Eric: CSS will have min, max, divisions, so if a pathlength is zero we'll have to resulve to a number, so any percentage will have to be zero
<AmeliaBR> gitHub: https://github.com/w3c/svgwg/pull/485
[are we on 485 or https://github.com/w3c/svgwg/issues/383? ]
AmeliaBR, in most cases differences in path length adjustment will cancel out, but we have a special rule about handling path length of zero
and for a +ve length you go to the end of the path instead of the beginning
so the only change is to say that doesn't affect percentage length values
Eric: any +ve non-% length goes to the end of the path
Dirk: if that's implemnt behaviour it's fine with be
AmeliaBR: Eric - are there tests for the changes?
Eric: there were non-percent path lengths,haven't done zero with % but i'll add them now
AmeliaBR: need a review, ok with me
<ericwilligers> Any positive non-percentage lengths goes to the end of the path.
Eric: new proposal (see preceding IRC line)
<ericwilligers> Percentages resolve to 0 when pathLength is 0
Dirk: for 0 you'd get the end of the path but percentages resolve to zero
<ericwilligers> 0 is always the start of the path.
AmeliaBR: these are all edge cases anyway
Eric: I'll send a new pr and tests.
<ericwilligers> https://github.com/w3c/svgwg/issues/484
Github: https://github.com/w3c/svgwg/issues/484
Eric: we'll fix blink so it follows the spec if you have, if there's no rx but you specified ry
(if there's auto)
Dirk: it's a presentation at so computing to something
AmeliaBR: this comes up for issues that came up after chome & webkit implementations shipped, so rx and ry on rectangles have had this weird matching behavioursince SVG 1...
but that was not initially implemented when adding the CSS version
so we added in the new auto value for compatibility on rectangles, but that ended up adding it for ellipses
so the current spec is designed to match the rectangle behaviour as close as made sense
Eric: ew'll fix Blink so it does what yuo're aiming for.
Dirk: agreed
since this means don't change the spec but open issues to get browsers to fix
AmeliaBR: and getting tests to look good
Dirk: Animated Points
AmeliaBR: only issue there is aliasing, i'd call that a browser bug
Eric: what about AnimatedString, AnimatedLength?
Dirk: they'd link to the base value and not live. AnimatedPoints now readable in ff
ff changed behaviour, not sure exactly
so we need to keep open
AmeliaBR: should be looked at in context of the other AnimVal/BaseVal things ...
and if none of the browsers have implemented the sort of....
Dirk: recently lots of [changes] in Webkit
let's go back to this next week.
Eric: OK
Github: https://github.com/w3c/svgwg/issues/486
AmeliaBR: 2 issues here. We don't have browser support for multi-line text, and some of these only apply to that;
second, some of these properties are from other css specs and have no browser support at all
so this isn't only testing SVG rendering but whether they're supported in browsers at all
Eric: so unless there are browsers planning to implement them...
i don't think th epoint of SVG s to say, browsers you must support this property, and i dont' think authoring tools should use gglyph-orientation-vertical
AmeliaBR: there's a standard CSS way to do vertical text [and it's not this]
I agree that it's already spec'd in CSS, it's an SVG legacy feature, should just point to CSS
Eric; we should just say to use text orientation in tools
Dirk: what about text-align-all and text-space-collapse, i don't think Illustrator does
Tav: Inkscape doesn't
AmeliaBR: we could say, if the UA supports the property then it should apply to SVG text
and that way we can make it clear we don't want browsers adding support for CSS & not adding it to SVG
Dirk: i'd rather deprecate them
AmeliaBR: I'm talking about the new features too, e.g. text-align-all, 'cos different specs complete at different times
Dirk: should be in css text, not svg
AmeliaBR: we have this list (1) to say that non-browser svg environments, thisis the relevant subset of css, and (2) if browsers are implementing it these also apply to SVG
Dirk: {it's at risk though, we can drop it]
AmeliaBR: or make it an informative note, to say, when implemented they should also apply to svg
Dirk: that's up to CSS text
Eric: i want to go with Amelia's suggestion, a note; i can't write a test for it but it makes sense
Tav: i think we could just drop these two properties as being required for SVG
[Liam and Dirk have brief aside about whether SVG should identify relevant CSS properties & say how they apply or whether CSS must say it for all specs]
Dirk: i'd rather have any issues against it fixed in CSS not SVG
and even something informative can't be tested, and isn't helping
Decision: drop text-align-all and text-space-collapse
AmeliaBR: for the rest of this list, are there any objections, any other ways to handle?
Eric: gglyph-orientation-vertical
Tav: didn't we keep that because of Adobe?
Eric: SVG 2 is about new content not legacy
Tav: people don't expect their files ot break
AmeliaBR: we don't want anyone to remove support, but user agents that never had support for the legacy property shouldn't be required to add it in; CSS lists it as optional
krit: i just checked and we support it because there's no CSS replacement for glyph-orientation-vertical yet in some cases
so there's a requirement tosupport this
ericwilligers: right-angles only?
krit: yes
... fine with dropping once there's an alternative but so far
we can't export everything as SVG using CSS
Tav: in CSS can only do sideways one way
Dirk: so no way to vertically align letters below one another [in a pile] without rotating glyphs
Amelia: can do this but not upside down
<AmeliaBR> https://www.w3.org/TR/css-writing-modes-3/#glyph-orientation
so the CSS spec only supports some values, auto 0 and 90, but not 180 and 270
Eric: so shouldn't we raise this against CSS?
Dirk: I did but it was rejected by the WG
AmeliaBR: we're not saying glyph-orientation-vertical should be banned; Eric's proposing to take it out of the list of required features, and even there we only require it as defined in css writing modes 3
but if the SVG1 glyph-orientation-vertical needs to be supported for legacy then we really do need to talk with CSS
Dirk: not sure how to resolve
Liam: can mark as optional and sounds like it has impln's so won't block us
Dirk ideally would move to CSS text, i can take it up there
AmeliaBR: i can't support saying, use the definition from css 1 and not the definition from css 3
Liam: difficulty might be CSS treats rotated glyphs for i18n purposes not drawing
AmeliaBR: SVG has other ways to draw upside down piles of glyphs, bt if Adobe s/w is still outputting content that expects the SVG 1 def to be supported, that's for Dirk to raise an issue on CSS
as far as what we should do, i still think we should make it clear that we're deferring to css writing modes, and right ow css writing modes says, even for the modes still supported, old property names are an optional feature
Dirk: CSS WG deprecated properties in the past & have specialized others, so ideally it'd move to a text alignment spec
i'll take it up with the CSS WG
AmeliaBR: all other props have 2 implementations
so not process blockers
Github: https://github.com/w3c/svgwg/issues/483
Eric: we think it's a nice feature but have not implemented it
any plans to implement?
Tav: inkscape does not support this
AmeliaBR: it's for interactive use & accessibility
Dirk: browsers prefer css transforms
AmeliaBR: very strong demand but no browser implementation
Eric: even though it's a valueable feature i don't thinkwe should block SVG for it
AmeliaBR: +1
still something i want for 2.1
Liam: defer?
eric: yup
Tav: +1
RESOLUTION: defer z-index to 2.1
Eric: we need similar issues for other chapters, with changes and tests, and i think that should be our focus
[Liam: +1]
eric: i don't know how long the tests for the other chapters will take
AmeliaBR: things can be done if
we have people able to work
... going tp ut in an hour ot two thisafternoon with issues for
other chapters in the same structure Eric used
"these are the new features in this chapter" so maybe htat'll make it easier to understand the scop
David Story did careful review of the IDL changes but we have lots of other changes
and that'll help us make time estimates
Eric: thank you, that'll be very
valuable
... if people can review path commands pthat'd be good]
Dirk: next week probably i'll have some time
<ericwilligers> please review https://github.com/w3c/svgwg/pull/398
[adjourned]
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/MISSED/percentage length values/ Succeeded: s/that was initially/that was not initially/ Succeeded: s/local/vertical/ Succeeded: s/lyph-orientation-vertical/glyph-orientation-vertical/g Succeeded: s/Dvid/David/ Default Present: AmeliaBR, krit, liam, ericwilligers, stakagi, Tav_ Present: AmeliaBR krit liam ericwilligers stakagi Tav_ Found Scribe: liam Inferring ScribeNick: liam WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 09 Jul 2018 People with action items: 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]