<scribe> ScribeNick: krit
krit: what is the current state?
AmeliaBR: 2 weeks ago we decided to publish. Last week Chris got approval and we were waiting for couple of CRs. They are in so we could go ahead.
present chris
AmeliaBR: we still have e the august branch open but we could open a new branch
chris: I'll look after the call.
Will check if we have some open things that need fixing
... We should get to a CR sooner rather than later that is
close to a PR if worst things happen.
... if we recharter we should focus on tests also.
AmeliaBR: I am working on a
couple of fixes for CR but it doesn't need to be in the
upcoming publication. We should make sure that the discussed
issues get in into the spec.
... we have 45 issues that need edits. Some are bigger than
others but they should be picked up.
chris: are there 2.1 issues as well?
AmeliaBR: There are 2.1 issues as well that need resolving earlier or later.
chris: testing issues should be on next charter
AmeliaBR: some of the issues are
feature requests from 5 years ago
... 50 issues total that we want for the next stage
chris: 12 that needs testing
AmeliaBR: we can create a
seperate milestone on Github
... SVG Testing 2.0
krit: we have one for testing. A specific one for 2.0?
AmeliaBR: we have labels and
milestones.
... Keep a smaller list of issues that we need to deal with
before we can declare the spec stable
<AmeliaBR> SVG 2 PR milestone: https://github.com/w3c/svgwg/milestone/4
krit: do we have a list of the required list?
AmeliaBR: that is the assignment to milestone list
krit: I can look over the list tomorrow, what about specifically?
AmeliaBR: separate milestone of
the list above that needs testing.
... and the other thing to look over is SVG 2.1 WD and look
over issues that do not have any milestones and in which list
they would end up
krit: Can do a look tomorrow and list issues that we should talk about before putting them into one of the lists for next call
<AmeliaBR> This is the 2.1 list. It should only include feature requests or issues on features we've agreed to defer. https://github.com/w3c/svgwg/milestone/5
krit: any help you need for verification before CR?
chris: No I think it is fine and make sure if gets published.
RESOLVE: Introduce SVG Testing 2.0 milestone list
GitHub: https://github.com/w3c/svgwg/issues/478
AmeliaBR: Robert filed it couple
of months ago and we forgot about it.
... it is a case where browsers do not match the spec and we
should decide if we change the spec.
krit: are browsers interoperable?
AmeliaBR: mostly. Chrome, Safari, Firefox seems consistent, Edge is a bit different but doesn't match the spec either.
krit: is there a proposal in the issue?
AmeliaBR: I've written up one in
a comment
... The setter algorithm for angle or length object needs to
convoluted to match the actual behavior
... based on current behaviours I'd recommend changing the spec
text.
... question is about the value properties. One can access the
length in the unit they are specified in or the units
directly.
... what happens when you set the angle value in implicit
degrees. Should that set units as well to the used unit? Or
should it do a backwards conversion to use the original
units?
... spec says to unset the unit, browsers preserve.
... Set a value in ems and you set it to 24, browsers would use
Unser units in converted with the previous units... for 24 it
would be 2ems
... for angles: should it treat the angle unites?
... all implementations do the backwards translation to the
original units
chris: seems reasonable
AmeliaBR: there could be issues
with fonts and ems
... anther is the UNKNOWN type
... especially with calc() function we have to define what
happens.
chris: we shouldn't
AmeliaBR: we define it for
attributes which we treat as unknown unit but we can not
translate it back
... that is the exception where we should reset the current
unit
... that is what Robert showed in his tests.
chris: just don't want to redefine calc() and rather suggest to use CSS. but this is ok
AmeliaBR: we do allow full cSS
grammar in presentation attributes and need to handle it in SVG
DOM
... at this point we should look at actual browser behavior in
these edge cases and look at consistency and decide based on
the results.
krit: thought there were tests. So we still need more tests for edge cases?
AmeliaBR: yes, need more testing.
<AmeliaBR> Proposed resolution: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.
RESOLUTION: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.
krit: could you ask Robert if he could help with edge case testing?
AmeliaBR: I can ping him
... I'll assign myself
krit: Tav, saw you discussed on the mailing list?
Tavmjong: got a response. He said
you can get the breaking points from pango. Still not sure if
that is the easiest way to do. He wants to avoid the CSS
wording because that depends on context.
... The spec says that breaking may depend on context. So you'd
break at different points. Unicode might work but I'd not say
this is the way to go.
krit: would you approve if we use CSS and ask to clarify what context awareness means?
Tavmjong: if we have.a set of numbers that need to apply to the same groups of chars. And CSS3 it depends on the context.
krit: it'd be great to understand what the context is
AmeliaBR: we had this issues with white space collapsing.
Tavmjong: In the email says that he likes the Edge behavior better with the cluster selection. Pango returns an array that are well defined clusters in unicode.
<AmeliaBR> Behdad's reply: https://lists.w3.org/Archives/Public/www-svg/2018Sep/0018.html
Tavmjong: if we are to switch from unicode code points, it would be the thing to switch too.
krit: could it happen that :first-letter selector can have a different meaning on layout and rendering?
AmeliaBR: :first-letter has a
different set of settings.
... for layout it is a different and predictability is more
important.
Tavmjong: my suggestion would be to leave unicode code points and add a note with a request of comments from implementers.
AmeliaBR: the limitation of leaving would be the inconsitencies and we can not file bugs on browsers until we decided how to go forward.
krit: The CSS has more text experts... is that something we should bring it up there or is it completely independent of CSS and its definition of typographic characters?
Tavmjong: I think it is
independent. We can not use typographic chars from CSS since
you might break at different positions dependent on the
context. That would be unpredictable and not consistent.
... so either use code points or Edge's behavior of clusters.
(which is not known detail.)
chris: surrogates are in UTF16 and 2 sets allow defining one character and older implementations do not understand this
AmeliaBR: this is how we even got into it
Tavmjong: only FF supports this but no one else.
AmeliaBR: we are going to file issues against specs. We need to decide on it to fix other issues.
<AmeliaBR> github: https://github.com/w3c/svgwg/issues/537
<chris> https://en.wikipedia.org/wiki/UTF-16#U+10000_to_U+10FFFF
krit: Maybe going with Tavs
proposal and ask for browser input would unblock us for
now.
... How can we bring this to their attention?
AmeliaBR: Tav, could you go though the text that may need changes and show how it would affect output if we are going to change?
Tavmjong: I can create a PR with the changes.
RESOLVE: Keep unicode code point for now until we get feedback from implementers. Keep previous resolution.
RESOLUTION: Keep unicode code point for now until we get feedback from implementers. Keep previous resolution.
AmeliaBR: Can it handle multi Byte characters and can it handle the 2nd issue?
chris: both *do* affect western text
Tavmjong: emoji is a good
example
... some emojis use colors?
chris: exactly, you may need to combine characters.
Tavmjong: maybe a good way to
test
... chris, could you send me an example with emojis? Then I'd
create a test out of it.
chris: yes
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/hom/him/ Succeeded: s/detaul/detail./ Succeeded: s/do not/*do*/ Succeeded: s/maybe w/maybe a/ Present: krit AmeliaBR Tavmjong stakagi chris Found ScribeNick: krit Inferring Scribes: krit Found Date: 01 Oct 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]