<scribe> ScribeNick: krit

organisation of edits that need testing

krit: We already discussed to have a milestone for testing

AmeliaBR: to keep track of it sep. from spec

krit: but an issue can not be part of 2 milestones

AmeliaBR: my suggestion is to switch over issues from one to other milestone but that affects process meter.
... question if we need this meter
... when we make spec edits, close issue and open new issue for testing. That way we track 2 actions separately

Tav: sounds like more work

AmeliaBR: more entries in GitHub but easier to track down issues

krit: we could have "has testing" beside "needs testing" to have both

AmeliaBR: we wanted to easily track issues for SVG 2.0 testing

krit: setting milestone or label is easier than opening a new issue.

AmeliaBR: don't think it would be a lot of work
... everything is fine that avoids keeping track or loosing to-test edits

krit: Tav what would you prefer?

Tav: changing labels.

krit: agree that closing issues when tests still need to be written but we can still filter for issues by milestone + label
... both suggestions have a risk of loosing issues that need testing

AmeliaBR: we should at least be consistent
... something that needs testing but doesn't have an issue. Should we open an issue and close it right away just to keep track of testing? This seems weird

krit: all edits should have at least an PR which can have labels and also be part of milesontes.

AmeliaBR: we can try this for now and if it get confusing go with new issues for testing.

krit: what about the label name for issues/PRs that has tests?

AmeliaBR: "has tests" works

Tav: sounds good for me.

RESOLUTION: Introduce "has tests" for issues/PRs that have testing and keep track with "needs testing"

AmeliaBR: we should make sure we have a link to WPT files for verification
... I think it is hard to search for tests that had "needs testing" and someone removed it

Tav: might not be many

AmeliaBR: are you going through all issues and mark them krit ?

krit: yes. Also need to go to closed issues/PRs/commits that have no milestone set.

AmeliaBR: list of issues with 2.1 milestones that should be move up to 2.0 milestone.
... anything that is about clarification we should try to move to 2.0

Tav: we want to be careful about making too much work for us.

AmeliaBR: we are suppposed to be done by EO November and I am not available for Nov.

Tav: things that can be postponed to 2.1 should be postponed.

AmeliaBR: agree.. we need to go through the issues carefully.
... and no-one beside Bogdan did I think

meeting next week

krit: TPAC is next week so I suggest canceling next week

AmeliaBR: fine

update on text

Tav: I have a PR for taking care of unicode point counting.
... Chris send me some text examples with emojis
... I got a question... what do you do with an emoji you have a fill and a stroke on?

AmeliaBR: there have been an effort that SVG uses multicolour strokes on fonts which didn't get anywhere.

krit: I'd need to check but I am pretty sure impls do not support fill or stroke on emojis

<Tav> http://tavmjong.free.fr/SVG/SVG2_TESTS/unicode.svg

AmeliaBR: chrome is using fill from font and stroke color from CSS
... FF on Windows just colors from the font
... Edge only colors in the stylesheet

Tav: consistent on what I see on Linux
... on android they do the colors on the font.

krit: is this something that we can move to stroke and fill spec?

AmeliaBR: I think it should be resolved in the CSS WG
... Tav could you open an issue on the CSS repo?

Tav: I can do that. Inkscape doesn't do anything.
... we get the stroke and fill from the font and fill ourselves
... the text dialog shows the emoji but we do not draw it the same way on the screen

AmeliaBR: sensible approach is to kick this over to CSS WG.

RESOLUTION: Request CSS WG input for fill/stroke on emojis.

krit: the PR is using user point counting as discussed the last time.

Tav: yes, with request for implementation-feedback
... I got a message from he unicode group and they list some problems with using unicode graphing cluster as a way to count. He does not endorse unicode code point counting but points out issues with the other methods. But I need to read the feedback more carefully.
... for now I think unicode point counting is the correct way to do.

svg:use subtrees

github: https://github.com/w3c/svgwg/issues/504

AmeliaBR: referencing element in another document and cloning in style rules of the other document (not only inline) is not what browsers implement
... when you copy from another document only inline styles would be copied in.

krit: I am not sure if cloning styles from other documents to get cloned in into the current document is save.

AmeliaBR: why would it be an issue than anything else?

krit: it could load own resources

AmeliaBR: there are rules on loading further resources from loaded exrternal documents
... stuff like line block from other files
... that are not well defined
... later to the issue I question even for the same document clone we do not have consistency with spec definition
... clone is a known change from SVG 1.1 to be more consistent with web components but that might not me necessary anymore.

krit: why

AmeliaBR: because we closed the shadow dom and author scripts can't access the shadow DOM and this makes it more up to browsers how special internal things work
... the other thing that changed: since 2016, web components have the idea of slotted elements sorted out now
... elements that have their styles resolved in main document and included in current document is closer to SVG 1 styling cloning works.
... this would get us back to the state of SVG 1.1 as far as same document style behaviour goes. Only browser not matching would be FF.
... which never matched the spec
... I have to talk to emilio if he could chnage the behavior of FF
... under the SVG 1.1 you access all styles before you clone it. That assume processing in the external document but that is not what browsers implemented.

krit: do you think it would be an issue that we isolate styling for external use reference and just allow inline styling

AmeliaBR: I think browsers are consistent for inline styling
... lets say you have a symbol element with an inner style element. Does this require cloning the style? I need to check what browsers do.
... I want to be able to use CSS selectors to style "use" content
... for external elements browsers usually don't pre-process the style other than they do for same document. So this needs to be tested.

krit: it sounds like you and Emilio would be the best persons to work on this. I will talk at TPAC with him when I see him.

AmeliaBR: I'll also try to ping Emilio and ask if FF could follow the other browsers and we get consistency
... if you could ask browser implementers to look at this issue (especially web components) would be great.

cross references and shadow DOM

<AmeliaBR> https://github.com/w3c/webcomponents/issues/179

AmeliaBR: I'd encourage you to look at the issue and comment if you have an opinion

krit: lets put it on the agenda for the week after next week.

AmeliaBR: I'll also make a poll and see what ppl want SVG to behave inside web components

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/happen a lot/be a lot of work/
Present: AmeliaBR Tav krit
Found ScribeNick: krit
Inferring Scribes: krit
Found Date: 15 Oct 2018
People with action items: 

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