<scribe> ScribeNick: krit

Agenda for CR republication

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

What is the unit type after setting an SVGAngle or SVGLength's value

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

Update on character counting for layout attributes on text/tspan elements

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

end of meeting

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