SVG Working Group Teleconference -- 18 Sep 2019

<mstange> ScribeNick: mstange

<heycam> https://github.com/w3c/svgwg/issues/731

Agenda

krit: We also want to discuss test suites, progress, plan for next year. Should we start with that?

heycam: I'm interested in tests.

krit: Amelia, anything else?

AmeliaBR: I think we have enough here. If we get bored, we have lots of open issues.
... We should ping gsnedders before we talk about tests.

krit: What should we discuss? How to write a test? Or what WPT tests look like?

AmeliaBR: Requirements for SVG tests, like which ones apply to non-browser environments, that sort of thing.

krit: Maybe also a review of the test suite?

AmeliaBR: Yes.

krit: There are a couple of fxtf topics. Let's move those later, too.
... There are a couple of things in fxtf that were marked as requiring SVG WG input. In the past, the SVG WG gives advice so that the CSS WG can resolve on these issues.

heycam: There was discussion about moving the specs to the CSS repository. Has there been a decision?

Rossen: Yes.

AmeliaBR: Yes.

krit: Tab Atkins has an action for that.

Rossen: I was hoping we can discuss the topic of non-scaling hatches. The CSS WG has a strong request to support non-scaling patterns; essentially, the ability to scale graphs and keep the fill pattern non-scaling.
... I remember that there was a draft with the non-scaling aspect.

krit: For vector effects we had a couple of additions.

AmeliaBR: Those wouldn't be specific to hatches, they would be specific to gradients and patterns. (?)
... Would user space on use be enough?

krit: Let's discuss this later.

Rossen: If there was an open issue on this, that would be great.

Short status update

krit: We have 86 open issues. 40 of those are marked needs-editing. They are distributed to different chapters.
... Issues in SVG Core are spanning multiple sections.
... What is the expectations for 1. fixing the issues and 2. the timeline when to fix them?
... So far, AmeliaBR did a lot of changes recently. I tried to keep up but had no chance.
... The text chapter is still open and requires some contributions to fix them.
... I don't think we have other members than Tav who's looking at those.
... Tav is still an active member but he hasn't done any edits in the last two or three months.

AmeliaBR: We can definitely go through things like need-editing issues where we know what the changes need to be.
... They just need to be done.

heycam: It would be good to have actual names on the issues.

krit: Amelia, how much time do you think you can spend on these issues? I will fix the issues assigned to me and maybe 10 more.

heycam: I can do some today.

krit: Rossen, is there somebody at Microsoft who could join the WG or look at some of the issues?

Rossen: I have to check how much time David Storey has. I know he was interested.

AmeliaBR: And he's familiar with stuff so it's easy to ramp up.

Rossen: And between myself and Bogdan we can spend some time.

krit: We are in the PR state, so we don't expect huge changes.
... It's going to be mostly small edits.
... We do not have all the members here. We probably cannot assign all the issues, but certainly some of them.

heycam: With the number of open issues discussed, is there (missed)

krit: We made some changes that are normative and require a CR update.
... We should fix as many normative changes as possible.

Rossen_: The issues that are currently marked as needs-editing, are those resolved?

AmeliaBR: Yes, we know what to write for those issues.
... If the resolution is missing in the issue, sometimes the github bot may have failed to pull them out of the transcript.

Rossen_: What about the definitions for the svg layout box vs css layout box, that looks more than editorial?

krit: We have those definitions already, just in the wrong place.

Rossen_: I was just trying to gauge how ready the need-editing issues are.

AmeliaBR: Every change goes through review. Make a PR, don't just commit.

krit: At least one member needs to review.
... We can go through the issues marked as needs-editing and take a brief look at them, and assign some of them.
... If you prefer, you can take a look first privately and then assign them.
... As for plans for the future: heycam asked if there will be a new CR. I strongly think we should fix the normative issues first.
... I will ask Apple and Mozilla people to help out with contributing.
... AmeliaBR, what are you proposing for next year?

AmeliaBR: So much of it is who has time to work on things. We have lots of pressure from W3C management to actually get something published.

krit: Having a timeline would communicate what we think the status of the SVG 2 spec is.

heycam: Do we have a good idea of what work is left to do, apart from knowing "this many issues"?

AmeliaBR: "This many issues" for editing. We have a few big ones, like cleaning up the use element sections.
... If we don't get any implementer commitment for wrapping text, we have to clean up the text chapter.
... There's also lots of other cleanup to do, most of which to address issues brought up by implementers saying "this isn't clear".
... This won't be done by the end of the year, which was the target date in the charter.
... Next spring, assuming as many people as have been working or more can keep working on it, and assuming we don't have too many more of "something's broken in this section, can you fix it?".
... That's the issues we know about. Testing is still a whole other task.

krit: We have had 60 commits this year. To fix the 80 issues, we probably need at least 80 commits, so we'll need at least another year at the current rate.

AmeliaBR: Teleconferences and bug testing take up time.

krit: My current expectation is that we don't expect to have the spec finished by the end of the year. But maybe by TPAC next year? Would be more realistic. That does not include testing yet.
... That's something that needs to be done in parallel.

AmeliaBR: Aiming for final CR (I don't think we can call it a PR without a test suite) in advance of next TPAC is reasonable at the rate we're going. If we have more people, it might speed up.

heycam: I think that is a good goal to work towards.

krit: Anything else to discuss?

AmeliaBR: The second side is testing. We're supposed to write tests as we make edits. We haven't been very great about that. We do have some people like Eric ??? pulling through and cleaning up tests and posting them, so we have some tests added.
... How high of a priority should adding tests be, from an implementers' perspective?

heycam: In some ways, the test suite is dependent on the spec.

krit: If we fix something, should be we be required to write tests along with it?

heycam: If both all of the spec editing work and the test work needs to be done before PR, and if it's not going to discourage people from making test edits, then yes. It should even save time!

AmeliaBR: Especially for any normative edits we should make the tests at the same time.

krit: Issues that are fixed in terms of spec editing work but don't have tests should marked with the needs-test label.

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

krit: Anything else?

AmeliaBR: We need more active contributors.

krit: If the issue is the telecon time, we can work on that.

non-scaling resources (patterns)

<AmeliaBR> https://svgwg.org/svg2-draft/coords.html#VectorEffects

AmeliaBR: We currently have vector-effects and are working on some edits to clean up this section because the grammar was incorrect, and then I just started cleaning up all the text.
... Non-scaling paint servers isn't yet a vector-effect. It can be added to that list if there is a strong use case, and it sounds like there is.
... Currently, everything except non-scaling stroke is marked as at-risk because we don't have any browser implementations.
... If we can work with somebody on Chrome who is interested in this feature, that would be good. Would adding this for patterns include the whole package?

Rossen_: I can't commit to that.

AmeliaBR: Getting parity with something like the MS Office vector graphics is a strong argument.
... We should help them to open an issue that sets up the use cases and finding which section it fits in well with the other vector effects.

krit: We also have use cases for patterns that don't scale with the shape in Illustrator. We see this used in Illustrator, but not in SVG, because SVG is mostly an export format. But we would still be interested in having it in SVG.

Rossen_: Visio is fully dependent on SVG. We also have partners interested in this.

krit: Is this something that should be picked up in the community group or in the working group?

Rossen_: Wherever progress will be made quicker.

AmeliaBR: It's a natural extension to something we have in the spec, so having it in the WG would be quicker. Clear use cases and implementer commitments would help.

krit: Is this something that should be inside SVG 2 or in parallel to SVG 2 in a new module for vector effects?

Rossen_: You know where I stand with respect to modules. I'm a fan of modules and moving faster that way. I wouldn't be opposed to a new module.

heycam: I'm worried about adding more things to SVG 2 if we're already tight on time.

AmeliaBR: At this point the whole of vector-effects is at risk and may get moved out.

Rossen_: In that case, it would make even more sense to have it in a new module.

krit: I'm fine with adding this to the general list of work items of the SVG WG. But who would be working on it?

Rossen_: In terms of implementation we certainly have interest in it and plan to experiment with and work on it.
... I don't know how the timeline is going to work compared to SVG 2 but I'm optimistic.

krit: What would all be included? Is there a need for gradients or other resources?

AmeliaBR: It would probably make sense from an implementation perspective to say "non-scaling paint servers".

Rossen_: Agreed.

krit: Ok. Who would make the proposal?

AmeliaBR: An issue with coming up with proposals is that there are pending edits. Once those are pushed, it'll be easy to make additions.

krit: We talked about having a max and min scale level of strokes.

Rossen_: That would probably be a quick follow to non-scaling paint servers. Those are the bigger use case.
... Non-scaling stroke was number 1 requirement, but that's in the spec now.
... Being able to specify a range in addition to non-scaling was the additional errata to that, with some use cases but less priority.
... Stroke and patterns are the two main requests.

krit: Once we get this proposal, are we in agreement that we would put it into SVG 2 first, since the section is at risk anyway?

AmeliaBR: We can decide on this at the time at which we get the proposal. At that point we can decide what we do with the other vector-effects.
... Proposed resolution: Non-scaling paint servers as a future extension to vector-effects, exact spec or module to be determined.

heycam: Is vector-effect really the best place to put this? You can have patterns in a fill or a stroke.

AmeliaBR: Maybe it should be directly on the panit server?

RESOLUTION: Explore non-scaling paint server functionality.

krit: I would be interested in helping out with the specification work, but in collaboration with an implementer.
... Anything else to discuss?

Rossen_: There were other use cases that Office was interested in. Mesh gradients, for example.

AmeliaBR: We need implementations!

myles: We're interested in that as well.

Rossen_: At this point, Office is mostly looking for ergonomics, which is a good sign. Most of the APIs are there, they're just not as ergonomic as they could be.

SVG native

myles: SVG native is a prospective new specification. The goal is to be similar to a raster image format, but being able to describe vector graphics.
... Today we have a collection of widely-implemented raster image formats like JPEG. These more or less just work everywhere. Developers don't have to worry about whether their JPEG image is going to work in browsers, it just does.
... There are a number of use cases where fire-and-forget is useful for vector graphics.
... One of them is artwork. Rasterizing all of the strokes would end up with a much higher size than the information contained in it.
... For these use cases, vector images would be very useful.
... SVG is missing some features, and is only supported by web engines. You can't put it in a native app and have it just work. You need a web view.
... Another use case are icons and symbols. They are used all over many operating system. Having raster images for them doesn't make much sense.
... On macOS and iOS, the state of the art is to include many different sizes of raster artwork. For example on the Dock in macOS, if you're using the genie effect and the image blows up, we use a larger image.
... This is unfortunate because authors have to create many different sizes. Vectors would be better.
... The goal is to describe a subset of SVG that can be widely implemented on platforms that are not the web.
... There are security implications as well, because e.g. icon rendering is usually not sandboxed, unlike web views.

heycam: Can you briefly describe the desired subset?

myles: The subset that we're trying to pick is designed not for developer ergonomics. Just like JPG and PNG are not hand-written by humans, we expect people to use tools that export to SVG native.
... For that reason, we don't want to include things like markers, because those can be described by other geometry.
... The sort of philosophy is: We'd like to include things that are required for drawing things to the screen, and are not just for semantic meaning or ergonomics.

<AmeliaBR> SVG Native issue discussion, includes a lot of "what should be included?" resolutions: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3A%22SVG+Native%22

myles: The goal for SVG native is that there is no semantic meaning. The whole image has a meaning, we don't go inside and mark up individual parts.
... The subset is shapes, paths, gradients, clipping.
... Patterns are not there because they can be flattened.
... Also no external resources. It should work like a JPEG. JPEGs can't reference other JPEGs. No resources, no JavaScript.

AmeliaBR: It's designed to match the SVG-in-OpenType minimum recommended support level.
... Any conformant SVG-in-OpenType renderer would be able to render SVG native. SVG-in-OpenType allows more features but warns.

Rossen_: Having worked with the team that implemented this at Microsoft, the one thing that I want to warn about is that this is a slippery slope.
... The current use case is icons. Then I might want to scale them on hover. But as soon as this becomes available, the next thing will be: "What about style?" Do I want to be able to update things on hover? Do I want to just scale, or change colors, or add additional detail?
... Then I get media queries, etc... It's a good sales pitch to say "I want something just like JPEGs". Trying to sell the idea that way is great. But the reality is that the users of this are trained to expect the support that we provide in the browser.
... Currently we already have a number of cases where Office has been shipping support for SVGs and more and more people are finding themselves trying to use Office for existing SVGs and finding discrepancies with browser rendering.
... So soon Office will need to have full support. There has to be full transparency and awareness of what we're getting ourselves into.

myles: The three examples you mentioned have strong cases against them. I agree there is a potential slippery slope that we could be sliding down.
... There are two counter arguments against that: 1. My goal is to make a new file format with a new name. My hope is that saying that we support "SVG native" will set up user expectations accordingly. Some SVG features cannot be added in the places where we want to support SVG native.

AmeliaBR: It needs to be clarified that this is a restricted subset of SVG for a specific context. If you need full SVG support, use full SVG.

krit: I agree with Rossen, for the use case of icons with different levels of detail. We have dozens of requests from customers at Adobe to have this functionality in SVG.

myles: Today people use media queries for this?

AmeliaBR: Yes. You can use them even in static SVGs.
... The current plan for SVG Native is "presentational-attributes only".

Rossen_: Our native implementation, from what I'm hearing, is a little bit broader.
... As your abilities grow, you will find yourself in a situation where it's easy to add support for unsupported features. For example, SVG in office supports mesh gradients whereas SVG in the browser does not.
... My point is that we're opening another lane that will be difficult to thread. Unless you're using exactly the same SVG stack (parser, style resolver, etc), things may diverge. It becomes a fairly difficult balance to try to keep the subset of features small and yet satisfy enough use cases.
... Framing it as an image format in this context is probably the most righteous thing to do. My experience is that, as soon as the format is in the hands of people, they are not going to stop requesting new capabilities. Maybe new capabilities for fonts? Just as an example.

heycam: If the concern is that we will get into interoperability problems, we should make the SVG Native format require that new features will not work. And then create a new format once we add new features.

AmeliaBR: We have talked a few times about other subsets. Subsetting SVG isn't new, it was done 10 years ago for SVG tiny and SVG basic for early mobile browsers.
... We had a discussion with an engineering standards body that wanted an official standardized version of SVG that's good for their visualization for machine control interfaces.
... And what's the best way to define which parts of SVG should or shouldn't be standardized.
... One thing that I've talked about is using the SVG Native spec as a model of how you can concisely define the subset of SVG that a given context should support.
... Other contexts can come up with a very simple table of what they support that is easy to put into a validator or an exporter.
... It is definitely a consideration that the subset that makes sense today may not make sense in the future.
... Just like the SVG tiny subset didn't make sense once we got smartphones.

myles: The fact that some people want more from a standard is true for every standard.
... It is up to this group to decide whether a particular feature request is valid or not.
... The ones that are can be added.
... If and we do add features, we can figure out how to do graceful fallback and versioning and things like that.
... It is worth stating why it's ever worth standardizing SVG Native.
... Right now the state of the art is that Microsoft supports parts of SVG that are not documented. Apple also supports a subset of SVG in fonts but it is not documented which.
... Android also supports yet another different subset.
... That's why I think this is worth standardizing.

AmeliaBR: But then it is also important to get involvement from people representing those other OS teams that had their own reasons for picking the subset that they did.

myles: If we have too many profiles or versions, then what we've effectively done is match what the state of the art is today, and have failed at standardization.
... Similarly, if we come up with a spec that nobody implements, we also have failed. We need implementations and this group to work together.

Rossen_: One thing that is not quite the case is that yes, people expect more things from standards all the time. But that's different in terms of adding new capability, versus unlocking existing capabilities.
... We are restricting people, putting them in a smaller box than they want to be in. And that's the slippery slope.

myles: There is a spec for this, but it doesn't contain my recent edits.

<heycam> https://svgwg.org/specs/svg-native/

<myles> ScribeNick: myles

gsnedders: I have no idea what i'm doing here

krit: The next agenda topic is the test suite

gsnedders: I'm sam sneddon. I'm been working on WPT for a while. AmeliaBR asked me to show up here because this is about testing.

AmeliaBR: A huge task for this working group is to get a proper test suite for all the new features for SVG 2, and or all the existing features from SVG 1 which have no or negligible tests.
... We have been getting some tests being pushed. They're heavy on scripting because they're the easier tests to do. There are nice harnesses and default methods you can call and say that when you set this style property on this element, this is what it should look like as a computed value. This is an easy test to write. We still need to write a heck of a lot more of them. But that's a clear path forward, we just have to sit down and do the work.
... We don't have many tests is the visual rendering. I was hoping to ask Sam to talk through best strategies for building a good ref test. Also, specific issues as far as annotating the test that are SVG issues because of the fact that we have lots of contextual features that depend on SVG behaving differently, as the main website or as an image. We have lots of implementors that aren't browsers that want to use the test suite but not the tests that

are browser-specific.

AmeliaBR: Does anyone have opinions on ordering?
... It might be useful to go through what a ref test looks like, if you can wing it, gsnedders

gsnedders: Sure. Ref tests in WPT are similar to those that exist in all major browser engines. There's two documents and an assertion that they either must be rendered the same, modulo some level of fuzziness, or rendered differently

emilio: for WPT reftest, you need a <link rel="match">

gsnedders: It has to be in the HTML namespace

emilio: If you want a proper SVG document, you need XMLNS, etc.

gsnedders: yes

emilio: I have never done that. it's fine

gsnedders: There's nothing stopping us from adding SVG-specific solution, but we haven't done it yet

<AmeliaBR> https://xmlgraphics.apache.org/batik/tools/browser.html

AmeliaBR: Both the expected and the actual files should be SVG files because we have implementations that aren't browsers. But if it involves javascript, HTML is okayi
... There's one implementation that supports scripting but not HTML

gsnedders: The policy for all of WPT is that it is primarily focused on browsers. There are bidirectional syncs between Gecko, Blink, and Servo. There is a reasonable chance of getting things from that which isn't SVG on both sides.
... We're willing to push people to do SVG references.... but...

AmeliaBR: I'm not saying to reject any tests here just because HTML is involved. But if people are making new tests, SVG standalone files are better

krit: Before we continue, does everyone know what WPT is?
... <repeats what AmeliaBR just said>

gsnedders: Yes, I'm aware.
... It's just a policy of WPT has been focussed on browser implementations.

<AmeliaBR> WPT SVG tests: https://github.com/web-platform-tests/wpt/tree/master/svg

There are 3 options. A) don't use WPT for SVG B) Have a readme inside the SVG folder educating authors C) have a bunch of tests that are irrelevant to many implemnetations, making implementation for them more difficult. B) is the best.

<all> Yes.

SimonSapin: When making a ref test, we should have a reference that doesn't use the feature being tested. In CSS, this is easy. However, for SVG, this is difficult. If we add the constraint that the reference should be SVG as well, that might be more difficult

AmeliaBR: If you can't have a simpler version of SVG that gets the same graphic, then the solution is a PNG file that's in the SVG
... So the reference is either a standalone PNG file, or an PNG file embedded in a SVG

emilio: PNGs are not great
... I would prefer using HTML

AmeliaBR: Then we're excluding some implementations

emilio: The problem with PNGs, they don't account for running the test on other devices

myles: We don't run pixel tests because they're too flakey because of colorspaces

heycam: If we just have a rectangle, there's not much in SVG we can compare to. HTML is better here.

gsnedders: We can almost always have another path in SVG

AmeliaBR: In the vast majority of cases, a simpler SVG is possible.

We're not really interested in drawing rectangles at all. We're more interested in things like viewports

gsnedders: We have bad coverage of the basic cases in WPT

AmeliaBR: Can you have expected-mismatch tests?

gsnedders: yes!

myles: but it does require dilligence. For regular reference tests, you can have explanaotry text and other elements, becasue they all have to match. However, for expected-mismatch tests, you have to only have a single thign in the content becuase if there's a rendering difference in teh explanatory text, it will be a false pass

krit: can we resolve on anything? how about not having PNGs?

AmeliaBR: guidance: Whenever possible, the tests should be SVG files with SVG references. If this isn't possible, HTML references are okay, or mismatch references. If you use PNG, then you have to use fuzzy-match parameters.

heycam: A long time ago I added some basic WPT reftests for rectangle rendering. They use HTML reference files.
... I was writing a few WPT reftests as a demonstration. 4 years ago.

AmeliaBR: We've got rect01 is SVG with an HTML reference.

emilio: Another thing to be aware of is multiple matches or mismatches in WPT

gsnedders: That might change

emilio: Please make it change

<gsnedders> https://github.com/web-platform-tests/rfcs/pull/15

gsnedders: Any number of <link rel="match"> or <link rel="mismatch">, the tests passes if *any* of these are satisfied, rather than *all* of them are satisfied

krit: why?

gsnedders: Whoever was setting it up in the first place messed it up

myles: what about tests that test that the browser doesn't crash

gsnedders: Then use testharness.js.

<krit> https://raw.githubusercontent.com/web-platform-tests/wpt/master/svg/geometry/inheritance.svg https://github.com/web-platform-tests/wpt/blob/master/svg/geometry/svg-baseval-in-display-none.html or https://raw.githubusercontent.com/web-platform-tests/wpt/master/svg/path/bearing/absolute.svg

krit: You could just use an expected-mismatch test
... Here are two examples of reference tests. One of them requires the parser understands XML. It sets namespaces for HTML.

AmeliaBR: That's used for the <link> elements. These should be HTML namespaced link elements. All web platform tests require metadata which are done with HTML <link> and <meta>

krit: In this case, you have the namespace for XHTML, for the other test is HTML, will the test be able to match that to the HTML namespace
... Does the test infrastructure understand XML and namespaces, etc/

gsnedders: yes.

heycam: In the first test, width=800, height=8000. What is the window size that WPT uses

gsnedders: 800 x 600
... For JS tests it's technically undefined

AmeliaBR: Knowing that reference size is important for things like viewbox scaling, if you want to test this *for the particular window size* then you need to know this

gsnedders: There's discussions about making custom viewport sizes for some tests. But it hasn't happened

AmeliaBR: We don't need that now but we'll let you know if we do need it in the future

heycam: Is there a place in WPT tree to put a template file that people can copy from?

gsnedders: We have some in /docs inside writing-tests/test-template

AmeliaBR: That's a separate repo?

gsnedders: no

AmeliaBR: It's a folder.

mstange: Does WPT have support for different device pixel ratio scales?

gsnedders: Nope.
... It's an issue reported somewhere

<gsnedders> https://github.com/web-platform-tests/wpt/issues/7135 is changing viewport size

<gsnedders> https://github.com/web-platform-tests/wpt/issues/7140 is changing DPI

mstange: We have 11 tests in firefox that are SVG files and use the reftest-zoom feature. If we wanted to convert those, we would need support.

gsnedders: This is a known issue.

AmeliaBR: We've got scattered additions to SVG 1 to make SVG 2 tests. Most of these are the scripting ones looking at things like parsing and a few interaction focused tests. ewilligers has been doing some, and David Story has done some. There a few new ref tests that Nicos has done, trying to convert the legacy tests. For markers, under painting ....
... Nicos did a whole bunch to convert SVG 1.1 marker tests to WPT tests
... Those are something we can look at for a reference. One thing that didn't exist at the time he did this is the fuzzy parameter, which would have been very helpful.

<gsnedders> heycam: https://github.com/web-platform-tests/wpt/blob/master/docs/writing-tests/test-templates.md has templates

AmeliaBR: If you're testing basic marker functionality, you need to compare it to drawing the shapes in that position, which was causing antialiasing issues.
... People will need to look at for one option as they're doing this
... The other thing that has come up from WPT is, if you are getting those antialiasing mismatches, where the edge of the graphic is the mismatch, consider drawing a separate shape on both the expected and the actual tests, that just covers up the antialiasing region

heycam: We have a bunch of SVG reftests internally. We might want to port them over to WPT

<all> yes please

AmeliaBR: that would really help

gsnedders: Most of the gecko ones have HTML as references, IIRC

heycam: not really....

emilio: some of them....

AmeliaBR: The other thing on WPT that I wanted to poke Sam about was how do we go about defining additional metadata for SVG. In CSS, they have their own special things, but things for SVG like "does this make sense in a non-scripted, non-interactive environment." We have mandatory things that need to not happen if you're in an <img> vs the main document

gsnedders: We never defined a generic way to do it. You're welcome to do something that isn't really burdensome to authors. CSS is special because legacy.

myles: can you just put the SVG in an <image>?

AmeliaBR: That's one option.

emilio: I don't think a lot of the new CSS tests use the <meta> at all

gsnedders: One option is to have wrappers like .image.svg which creates a wrapper for it to be in a secure environment. Any other implementation can just match on filename

AmeliaBR: I need to sit down and look at what we can do here.

krit: Is there any name pattern that implementations which want to use WPT to rely on to know which tests to test?
... e.g. how do i know which tests my implementation cares about/

gsnedders: there's no way to filter by name righ tnow

AmeliaBR: Righ tnow, tests are grouped into folders matching their names in the SVG spec. Some work needs to be done to match chapters which got moved around. Also, the idea was there would be some folders for reftests vs scripting tests, and I don't think we've been consistent wtiht that

gsnedders: That's not a requirement because there's a manifest which already exposes this information.

AmeliaBR: It's also worth while just for cleanliness

gsnedders: Navigability is important

<scribe> ACTION: AmeliaBR to Go through all the tests, and move tests around to match the README, and update the README

<trackbot> Created ACTION-3870 - Go through all the tests, and move tests around to match the readme, and update the readme [on Amelia Bellamy-Royds - due 2019-09-26].

heycam: Metadata tended not to be used in tests these days? That means people aren't using <meta assert>? What about spec link?

gsnedders: They're required in CSS, but there's an agreement to make them not required in future. If the folder structure matches the spec, you already have this information

emilio: CSS usually puts all the tests in the top level

gsnedders: ::frustration::

heycam: Do the directories have to match the link names? For the automatic annotations in specs that link to tests, they should know how to do it

gsnedders: The CSS tests rely on the CSS tooling, those rely on <link>

krit: I think that WPT wants to do something similar in the future.

gsnedders: There's WPT.fyi which has results for automated tests. Nothing is stopping non-browser implementations from submitting results there. We might not be able to run the tests on those implementations ourselves, but accepting results is no problem. Also, we have "WPT Report" which has been used to create implementation reports based on WPT runs previously, which is a lot of what people have used WPT for
... And there has been some talk about handling manual tests somehow, outside of Peter's tool, in some way that is better supportive of WPT

heycam: I'm adding templates to test-templates.md file, and I will include the <link rel="help"> in there

AmeliaBR: In assertions, rel is also helpful because it shows up in the FYI reports

gsnedders: This is different

emilio: This is about putting a link to a spec in the file

AmeliaBR: There's also something that tells you what you're testing

gsnedders: What shows up is the testharness.js tests. Asserts can have messages as their final argument, whcih does show up.

AmeliaBR: There's nothing similar for a reftest?
... In the test, you shoudl be able to say what it's testing

gsnedders: You can put a comment in the test

AmeliaBR: I may be adding a feature request

emilio: Most CSS reftests use the filename

heycam: I'm not creative enough to write useful filenames for 100 tests that I'm adding

gsnedders: Just do the best you can

<gsnedders> e.g., don't have path-001 to path-100, but path-data-syntax-001 etc.

krit: A short update: We do have an annotation script to the spec, and it does nothing. It turns out that we don't have an "SVG Test Suite" because it crashed Peter's system. As soon as he fixes it, it will exist

gsnedders: You're using bikeshed, right?

AmeliaBR: we're using heycam's brilliant combination of scripts that have crystallized and are somehow holding together

heycam: It's a large spec and it's multi-page makes it difficult to Bikeshed. But we'd like to

krit: And it's lots of work.

gsnedders: I knew there was talk at some point

AmeliaBR: It's a legacy system we're keeping alive for SVG 2, and for new modular specs, we're using bikeshed

gsnedders: Bikeshed has a way of including tests, and there was talk of integrating that with results from wpt.fyi
... If we had to do it with just JS, then .... maybe? This goes back into a long discussion we've had over the years and no one has done anything about it. We don't know if it's worth the effort because Bikeshed can do it easily
... The number of non-bikeshed specs is decreasing

AmeliaBR: We can just use the fact that WPT test directories match the chapters in the spec
... It calls python scripts which calls node scripts
... The main makefile builds SVG 2, but if you want modular spec, then go into a specific folder

gsnedders: It's better than CSS 2.1 at least

emilio: That's a low bar

gsnedders: yes.

heycam: Do we need to have an effort to go through the spec to determine what coverage we're missing in the test suite? I might have tried to do that once many years ago, but I don't remember

krit: There's a reason why I asked Peter to fix the problem, so we can have some data in the spec for which tests that section has

AmeliaBR: We have a two-stage plan for testing. We've been told by W3M that in order to progress in SVG 2, we need to test everything new. We need to determine if there are tests for legacy things, but that comes after the SVG 2-specific content. I did start a year ago doing a year ago doing a review of the changes list that we have, to determine test coverage. There was a set of issues opened about test coverage review or something like that, and I need to

finish that and assign people for specific things. That is one thing to do, to focus on our changes, which changes don't have tests, because that blocks going to PR

<krit> https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+author%3AAmeliaBR+label%3A%22Test+suite%22

gsnedders: HTML5 went to req with an entire top section of the spec not having tests

AmeliaBR: Which section?

gsnedders: "Browsing the web."
... It was not interoperable at the time HTML5 went to REC

s/Browsing the Web/Loading Webpages/

AmeliaBR: At some point I'd like to do an end-to-end, every paragraph, do we have a test for it

krit: Ideally, every paragraph would have its own ID so we can have a test link to it directly
... You can have multiple links to multiple parts of the spec, including subsections.

heycam: If we only rely on the directory names, then...

gsnedders: Peter's tool doesn't cope with that.

AmeliaBR: Another reason to include that metadata is to link to a precise reference.
... It's noon. I think we're done?

krit: Thanks to the WPT team!!!

AmeliaBR: Yes! Super helpful!

gsnedders: There will be some tool across all of WPT that will move tests around to an appropriate directory. But right now it's in the undefined future

<AmeliaBR> Tutorial from WPT about writing ref tests, in general: https://web-platform-tests.org/writing-tests/reftest-tutorial.html

AmeliaBR: WPT has a blog, including tutorials
... This is a good reference.

gsnedders: If you find holes in the documentation, file a bug on the docs.

heycam: If I were to get Gecko's SVG reftests imported to WPT, would you be fine without actually reviewing the tests?

gsnedders: You could let the 2-way sync do it

heycam: It would be a lot of work to review them
... The tests are probably mostly correct....

AmeliaBR: That will show up when the tests fail in other browsers

<AmeliaBR> https://github.com/web-platform-tests/wpt/blob/master/svg/META.yml

AmeliaBR: in WPT, each folder has a list of reviewers that are recognized. If you work a lot with SVG implementations and the spec and you have a little bit of time to review tests, please add your name to that yaml file.

gsnedders: Note that it's every folder, and its' recursive. If you only want to review things for a certain section, you can do that, just put the yaml file in the subdirectory

krit: If you just follow the repository, then you get thousands of notifications. How to do this?

gsnedders: Don't follow the entire repo, that's insane. Github has a setting "not watching" which means you get notified when you are mentioned, but not everything
... You get added as a reviewer by a bot based on the yaml file. That will notify you

AmeliaBR: I do send out a digest of SVG-related PRs on a weekly basis.

<gsnedders> https://web-platform-tests.org/reviewing-tests/email.html also has some guidelines for filtering GitHub notification email

gsnedders: There's also WPT docs have advice about how to filter notifications

AmeliaBR: I'm filtering on the word "SVG"

SimonSapin: Regarding the directory structure, I just looked at the docs, it says there are two common ways: 1) The flat structure 2) Nested structure, each subdir corresponding to the ID of a heading in the spec

AmeliaBR: We haven't done that. We're doing it by chapter. We could change this if necessary. We're using <link> metadata to link to specific sections.

SimonSapin: How far do we want to nest directories?

gsnedders: Until you don't have directories that are hundreds of files

krit: Let's go to lunch!

AmeliaBR: Yes please

gsnedders: +1

<gsnedders> 💯

<gsnedders> Meeting: SVG WG TPAC 2019 Day 1, Thursday

<satakagi> The subset of SVG that corresponds to the canvas2D context looks simpler in the sense that you don't have to think about restrictions based on any new requirements. And I think that the interoperability between Canvas and SVG was raised as a candidate for SVG2 requirements.

<heycam> ScribeNick: heycam

focusability compatibility

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

rniwa: inthe current draft, it mentions that SVG elements that are scrollable should be treated as if tabindex is set to 0, so it's focusable
... that's not what HTML does
... to decide whether something is scrollable, you must update styles and layout

AmeliaBR: this list was based on the accessibility desires that scrollable should be focusable
... since this isn't an SVG specific feature, it's about HTML nested in SVG, we should be consistent with HTML
... even if that means deferring to platform conventions that aren't ideal

emilio: to compute whether an element has scrollbars, you need to run layout. but afaict the focusability of a scrollable thing only depends on style, not on layout
... if it *could* have scrollbars
... we do allow stuff with scrollable overflow to be focusable

AmeliaBR: I think WebKit is the odd one out
... but it's an HTML issue
... I'm OK resolving to add a condition to that, that defers to HTML
... so element within a fO would be focusable accoridn gto the foreign language

rniwa: the issue is more the consistency with HTML here

emilio: I agree it should be consistent

krit: anything else that could be scrollable?

rniwa: HTML spec section 6.4.2 defines focusable area
... would be great if the SVG spec just delegates that to decide what's focusable

<rniwa> https://html.spec.whatwg.org/multipage/interaction.html#focusable-area

RESOLUTION: Defer to HTML for focusability of foreignObject content

AmeliaBR: second part of the concerns are more SVG specific
... the legacy focusable attribute

rniwa: one thing that is unclear is the old SVG Tiny 1.2 talks about focsuable = true,false,auto

<scribe> ... new spec doesn't talk about any of the values

UNKNOWN_SPEAKER: it's unclear whether tabindex or focusable takes priority

AmeliaBR: good criticism that we should have specified the interaction
... definitely want tabindex to take precendence
... only we mention focusable is to avoid breaking content that uses that attribute

rniwa: do we still want to support the 3 values?

heycam: do we still need to support that at all?

AmeliaBR: it was working in Edge, at least

rniwa: focusable=true is clear cut, to imply tabindex=0
... false, if it's set, it's like a noop

AmeliaBR: focusable=false got used a lot since MS browsers were treating every inline SVG as a focusable item
... we can say focusable=false is respected, as long as tabindex overrides it

rniwa: so your suggestion is to take the SVG Tiny 1.2 true/false/auto values into the spec, and allow tabindex to always override it?

AmeliaBR: officially define focusable, but deprecated, with those three values

rniwa: one tutorial I found says that focusable would override tabindex...

heycam: but do we have any implementations of focusable?

AmeliaBR: Edge does support it

mstange: there's a Firefox bug, WONTFIXed 5 years ago
... saying it wasn't in SVG 2

<mstange> https://bugzilla.mozilla.org/show_bug.cgi?id=409404

[some discussion about having it in the spec, allowed to implement, not required]

rniwa: if Edge wasn't going to change, normative or not probably doesn't matter
... I'm curious what Edge does in terms of priority between focusable and tabindex

emilio: in the bug comment, IE <= 11 only supported focusable, and not tabindex

rniwa: can we agree on a non-normative note?

AmeliaBR: I think we should have a normative thing, if you implement it, this is how it interacts with tabindex
... I wouldn't mind saying every browser should implement it but it's deprecated

rniwa: question is whether implementors will implement focusable

myles: I think the answer is no

krit: I think the note in the spec should advise against using it

RESOLUTION: Clarify the interaction of tabindex and focusable; make it clear this only applies if the UA supports focusable; support is not required; authors are discouraged from using it.

xlink:href in sourceless iframes

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

AmeliaBR: we have discussed this
... this is related to Shadow DOM in the simple sense that it's a similar problem in Shaodw DOM
... same document references in trees that don't have a base URL
... but the iframe is a little more isolated from the parent document
... if cross reference works inside a shadow tree, it should also work inside an iframe document
... that's even more isolated

rniwa: I think anchor tag inside sourceless iframe works as well
... this should somehow be resolved in the HTML spec
... so we should be using that mechanism

AmeliaBR: is that in the HTML spec?

rniwa: hyperlinks already work...

AmeliaBR: the special rules for SVG hash references

heycam: that's defined in CSS somewhere?

AmeliaBR: that's another set of special rules
... I think we can resolve to file an issue on HTML, and ask them to clarify how these sourceless iframes work with the specific use case of breaking SVGs

RESOLUTION: Defer to HTML for how to handle local references inside sourceless iframes

<scribe> ACTION: AmeliaBR to file an HTM Lissue for sourceless iframe local references

<trackbot> Created ACTION-3871 - File an htm lissue for sourceless iframe local references [on Amelia Bellamy-Royds - due 2019-09-26].

SVG2 spec means elements within a <use> tag can not be targeted for styling

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

emilio: SVG 1 says you take the style rules from the reference element
... that not only changes the behavior of decendant combinators, but also element specific states

AmeliaBR: it wasn't clear in SVG 1, the way it was implemented was the specified style gets copied over, so any style rules directly set on the element get cloned with it
... and then inherited styles are inherited in
... nothing in Web Components shadow DOM that's at all like that
... trying to harmonize with shadow DOM, we defined it so that the style sheet is cloned in the shadow trees
... but that could break some select matching compared with the original element
... what gets fixed is the interactive selectors

rniwa: do we know what implementations do?

AmeliaBR: Firefox matches SVG 2 spec

emilio: Blink and WebKit, in order to resolve style in the use subtree, you match the referenced element

rniwa: so the original source element is used for styling

emilio: so when you hover over the reference, all the clones get hover styles
... the Firefox behavior is a bit unfortunate, regarding the combinators, but we haven't received many bugs about that

krit: how long has it been shipping?

emilio: more than 2 years

AmeliaBR: Firefox had never implemented the SVG 1.1 spec

heycam: right

myles: did you have to add special case SVG code?

emilio: not really
... in special of the special casing code being on the "compute the style" function, the code checks if the element is in a use shadow tree, then also look at your tree parent scope for rules

AmeliaBR: it can probably be represented by the adopted style sheets concept

emilio: yeah....
... but to implement it efficiently, you just look up to the parent scope

rniwa: conceptually you're copying the rules

emilio: yes
... conceptually you just look at the outside use shadow tree

AmeliaBR: when this has previously come up, Rossen has been cautious of breaking changes
... but we don't have a sensible spec
... in the existing SVG 1.1 match browsers, there were inconsistencies in terms of interactive styles, animations, whether htings get copied
... so in the details, we don't have a spec to define how those things work in a way that's actually corss browser
... so either way, implementations would have to change if we want truly consistent behavior
... I'm OK with making that be closer to SVG 1.1, but I need a spec proposal for that if people want to do that
... that also takes care of interactions, animations, etc.

rniwa: the question to me is which behavior is more compatible with existing content
... also author expectations

emilio: regarding author expectations, it's tricky. SVG 1 kind of matches "I'm styling the element I'm cloning"
... so ancestor combinators work
... however it doesn't match expectations of :hover
... the SVG 2 behavior works the other way around
... for authors who are familiar with shadow trees, it probably makes sense

AmeliaBR: we have had some bug reports on SVG spec and Firefox about people whose selectors didn't work because they were using these ancestor selectors
... but when you explain how to fix it, it was OK
... the :hover not working, that's a much more intrinsic confusion
... and there's no easy way to explain that

rniwa: whatever solution we come up with, it should handle :hover. :focus would even be a bigger problem

AmeliaBR: SVG 1 really didn't discuss keyboard focus. but now we have a model, you can have focus in the shadow tree, so your :focus rules should reflect the element that's actually focused

rniwa: there's also some niceness in that if we had adopted style sheets, it could be described in that way
... I need to talk to Antti and folks to check what they think

AmeliaBR: we should probably poke a Chromium engineer for feasibility too

<emilio> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7216 is a testcase that shows the difference of behaviors

krit: we've had this issue for a long time, it's been waiting for implementor view for a while

emilio: I recall having a WebKit patch for that in the past...
... there's a test case I've pasted

krit: how does the shadow content know about the viewport size?

AmeliaBR: that's the same as regular shadow DOM, it uses the document viewport for MQs etc.

rniwa: might want to consider what happens if you support shadow root on an SVG element at some point

AmeliaBR: definitely want to support custom SVG elements with shadowRoot

[some discussion about use elements pointing to foreignObject]

<emilio> rniwa: https://github.com/w3c/svgwg/issues/511

krit: but in general we agree we don't want foreignObject in the shadow tree?

rniwa: yes, that would get hairy
... then you can have SVG, MathML, plugins....

RESOLUTION: child content of foreignObject is stripped out of a use element shadow tree clone -- check browsers for exact impl details

RESOLUTION: No change to spec around use element styling, but focus on getting feedback from implementors about feasibility of current SVG 2 model

Referencing SVGs through USE from other domains

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

AmeliaBR: cross origin use elements
... right now, use elements can clone from the same file, or from a different file on the same domain. we do have good support for both of those
... we have no way of cloning from a file on another domain, which is problematic for people who use CDNs for static assets

krit: we already resolved to move that to SVG 2, but Blink is waiting for feedback if they can implement it

AmeliaBR: Robert Longson, Mozilla contributor, pointed out other browsers haven't supported <image>, <feImage>, cross origin references
... so shouldn't count on them doing it for <use>
... but we did have fsoder on the Chromium team saying it shouldn't be too difficult to consider

emilio: from Opera

krit: do we stand by our resolution to defer?

AmeliaBR: we all agree it's desired, but should it be in SVG 2

myles: are there implementations?

emilio: no

myles: then it shouldn't be in SVG 2

emilio: what are the security implementations? not confident enough about that

AmeliaBR: it's similar to other active content references, cross origin filters

emilio: but cross origin use elements insert content inside the host document
... it's not the same as just applying a filter
... if you leave the foreignObject details as is, that could be a security issue

AmeliaBR: the other things we strip are things like scripts

emilio: scripts only run once, so the clone knows the script has already run

AmeliaBR: and you don't scripts in the external file
... but security things would need to be spelled out clearly

emilio: someone should do a security audit of the feature
... cross origin filters, didn't want we want to remove them?

mstange: it's come up again and again
... this is filter on cross origin iframes
... nobody has suggested removing cross origin images referenced by feImage

AmeliaBR: the closest thing here is something like HTML Imports, cloning content into the DOM from another file
... even for that reason, let's wait for the HTML folks to figure out the security concerns here
... and we really need to get SVG 2 stabilized
... minutes from Jul 16 had 3 different solutions
... we'll go back to the first one: add cross origin use references to a future spec, rather than in SVG 2 and at risk

krit: I would rather let us defer the entire feature

AmeliaBR: so override our July resolution to put it in the spec as at risk, and just say we'd like to it, but not in SVG 2. maybe add a note to authors/implementors in the spec

krit: could also be done in the CG

RESOLUTION: defer cross origin use element references to post-SVG 2

<AmeliaBR> All text issues: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3A%22Text+chapter%22

<AmeliaBR> Two tagged internationalization: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3Ai18n-tracking

make the behavior of an invalid mask be consistent with clip-path and filter

github: https://github.com/w3c/fxtf-drafts/issues/130

krit: the issue is what happens if a filter, mask, clip-path is invalid
... for filters, what happens if there's no content
... so if you have a rect, apply a clip-path, but the referenced <clipPath> has no children

mstange: looking at the table in the issue, does one of the rows describe if you have a filter in an external SVG that's still loading?

AmeliaBR: no, but good question

mstange: I ran into this before CSS filters existed. I wanted to darken on mousedown. I only set the filter on :active, which is when the external resource started loading
... so it would become blank

AmeliaBR: I was thinking of the basic case of when you're first loading. but in the interactive case, sometihng disappearing would be bad

myles: we have a similar situation with async image decoding
... where if oyu're on the first load of a webpage, we will not show the image until it's fully decoded
... but if you're in the middle of a page, and you change the src, you won't show nothing until the new image is decoded. you show the old image until the new one is ready

AmeliaBR: first we need to make the basic case of what do you do when you know the reference is invalid, either it's a bad URL, or there's an error in the content you're referencing
... we have different rules for different elements, and different implementations
... my general preference is to try to harmonize as much as possible

krit: I can go through the clip path examples
... [reads from the table]

myles: the no content case, I remember implementing this
... there was an SVG 1.1 test suite test for this
... our fonts implementation doesn't match Gecko, it matches others. [it skips invalid child content of the clipPath]

krit: Firefox is the odd one out here mostly, would they be willing to change?

mstange: there's cases are all handled explicitly, should be simple to change
... not sure on jwatt's or longsonr's opinion

RESOLUTION: For clipping and masking, we follow the behavior of Edge, WebKit, and Blink in the https://github.com/w3c/fxtf-drafts/issues/130#issuecomment-390981529 table

AmeliaBR: what's different between filters and clip/mask, is missing references
... if you have a url() reference to a missing element, clip/mask just applies no clip/mask
... for filter, the filtered element disappears
... which is usually not helpful

krit: not sure if I did change this, but I would like to align with mask and clip
... the Filters spec has a special rule, if the url() reference is to a different file, then you treat it as a no-op
... [reads spec text]
... so we already have changed the spec to not make the filtered element disappear

myles: putting a filter on an element causing a stacking context, so we can't treat it as 'filter:none'

AmeliaBR: as a no-op filter item

krit: so a stacking context still gets created

AmeliaBR: if your filter is invalid, that would be something to clarify in the spec

krit: didn't find anything about external references. think it should behave in the same way

mstange: I would be in agreement. I suppose we don't know how much content it would break
... but from an authoring perspective, I much prefer this behavior

myles: if an author was trying to get a filter, and make a typo, their element would disappear
... it's hard to believe that there's content out there that relies on it disappearing

AmeliaBR: when the url() is to another filter, and you get a network error
... the other issue is just debugging SVG filters is a pain, if your content keeps disappearing
... and the inconsistency with clipping/masking

mstange: these are arguments for it being a pass through, not for there being no broken content

myles: inside a filter you create a graph of nodes. do they also need this analysis performed on them?

mstange: if you have in="" that refers to something non-existent

AmeliaBR: each primitive has its own rules

krit: if the filter reference is invalid, the filter is not applied, but the stacking context is still created

heycam: you might have a filter property with multiple filters in it

AmeliaBR: this would make the entire filter chain a no-op

RESOLUTION: If a referenced filter is missing or invalid, the side effects like stacking context are still preserved.

<AmeliaBR> Resolution was at https://github.com/w3c/svgwg/issues/631#issuecomment-505164786

<AmeliaBR> and at https://github.com/w3c/svgwg/issues/537#issuecomment-452092266

Text i18n issues

AmeliaBR: if you're using SVG attributes to lay out individual characters, many browsers create the effect that these are the isolated character forms, which are not useful if tweaking individual characters in a word

<emilio> ScribeNick: emilio

AmeliaBR: resolution was that the desired behavior is that if you have a text element the shaping of the letter forms should behave as if it was a paragraphs or text even if you tweak the character positions with svg
... so for actually rendering it you need to actually do some tweaks
... most text rendering you do it by a zwj on the other side of the shaper

myles: that's not quite how it works but what you describe is ok

heycam: what gecko does and I wrote in the spec is that each <text> is a <div> and the <textSpan> are <span> is shaped as if a <div>

s/textspan/tspan

scribe: then you lay them out, and all the positioning stuff is applied to individual grapheme clusters
... we only apply the positioning it is the first dom character of a grapheme cluster

addison: so you're positioning the grapheme clusters individually right?

myles: after shaping

heycam: yes

AmeliaBR: so you can separate the clusters into the screen after shaping?

myles: yes

AmeliaBR: so for impls that don't do that and pretend that the different chunks are independent

r12a: today I asked 3 iranian people and 2 arabic speakers what to do here
... [whiteboard time]
... I asked whether they would ever put a joint word aligning each of them vertically differently
... and their answer was yes
... but that they would show up in isolated form, not joint
... that's the opposite of what behnam (?) said
... because that's what you'd do in crosswords and games
... one of the iranian people referred me to a persian professor in iran

myles: are you confident enough on this data or should we wait more

r12a: the people I spoke with seemed pretty confident

addison: does this also position multi-character segments?

AmeliaBR: yes, you can do that

nmccully: when they're joint in arabic you stretch when you go in the inline direction
... but it seems you're confident that if you move them vertically you shape them separately?
... anyhow there is a place for automatic place shaping

r12a: this is like letter-spacing if you only do it at the horizontal boundary so that may be appropriate

AmeliaBR: it puts the same spacing between every glyph pair but not for stuff in between

r12a: so I didn't ask for this use case...

heycam: my feeling is that this feature is poorly thought-out
... and I was introduced into svg because you could do the same on postcript
... where it is simple because that works on glyph
... so when I thought about it and wrote the spec I tried to do the simple thing that did some amount of sense
... so the question is is this feature as specified sufficient for the use cases?

r12a: it'd depend on the authors in the end

AmeliaBR: sounds like what we need is some sort of property to toggle "use isolated forms vs. connected forms"

r12a: even with the joining forms if you tear them apart enough without a proper kashida you're going to get gaps which is undesirable

heycam: so there's no existing css feature for that
... even required ligature

AmeliaBR: you can't turn of required ligatures

addison: you could use zws or something

r12a: and you may need to do it even in actual cases like the ?? and the 5, where you use a joining form even at the end of the sentence

myles: so we have two use cases, one is for kerning between letters for which we don't want the isolated form, another is for crossword like stuff for which we do
... I don't think people are doing this right now
... so we could advocate for new content to use different <text> elements

addison: then they'd draw as isolated regardless of vertical spacing

AmeliaBR: a11y would read them as separate letters...

myles: that's what you want for the crossword stuff

r12a: given the current state I don't think we have a clear answer
... for the case of vertical differences what I'm hearing we should use isolated forms
... except behnam which says the opposite

myles: So if I have <text> with 5 chars and x="1 2 3"
... the proposal would be that for the character that have specific x position (the first three)
... you'd have isolated forms
... the rest would join

heycam: my concern implementation wise is that now I need to resolve the positions before shaping
... and tell the shaper whether to use isolated form which would not be very easy
... I wonder if there's context other than svg where you want to get the isolated forms
... so you can add a css property or something
... and the author could opt-into it

AmeliaBR: that'd be my preference
... but I don't know if there's enough use cases to get implementors on board

r12a: I don't see the use case for such a property for horizontal text
... for vertical text... it depends
... for arabic layout requirements there's behdam's example about first letter, but there's people I've talked with which have never seen that (not clear if due to technology limitations)

AmeliaBR: so are we likely to get any resolution? If not? more feedback and from who?

r12a: yes

addison: this is something we'd want to continue to study
... there's more people we need to ask

krit: so unspecified for svg2 until we have a solution for it?

AmeliaBR: I think we should try to make the edits

myles: for what?

r12a: this works fine for latin so maybe drop a note that it may misbehave in arabic?

AmeliaBR: it may also be a problem with cursive latin fonts
... where it's not clear if the context remains there

heycam: you can control it with opentype features

AmeliaBR: for non-required ligatures you can turn it off

heycam: I think we should add a "beware" note to the spec for arabic

r12a: more than one

(more than one script)

myles: they should talk to us if they have use cases
... another option is to say that this only works in some languages

heycam: so letter-spacing does cause isolated forms to be used?

AmeliaBR: I don't think it affects glyph selection

r12a: csswg also throws up their hands up abut how that should work

<AmeliaBR> CSS advice on letter-spacing and cursive scripts: https://drafts.csswg.org/css-text-3/#cursive-tracking

r12a: you usually don't do same spacing for all glyphs
... use-cases are justifications

[side conversations about how to justify text in svg]

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

end

<mstange> ScribeNick: mstange

Character counting in text attributes

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

AmeliaBR: To recap: text attributes for positioning, as we've been discussing, can have multiple values that can be applied to multiple characters.
... The first step is that we look at the attribute and assign each value to a different DOM character. In some cases that's very simple.
... But if you have more complex multi-byte characters or clusters, things get more confusing.
... "What is a character" becomes a debate.
... There are other definitions that use utf-16 blocks, which is not very useful. But beyond that, do you use unicode codepoints or do you combine and cluster things so that you have a combining accent character, are those the same character or different characters?
... We have a resolution from January which resolved that values in the array should be assigned based on unicode codepoints.
... The argument for that is that unicode codepoints are stable and won't be affected by whether a new cluster gets introduced, or whether a particular font supports a particular combining unit.

myles: Other part of the resolution: We count based on code points, but we don't segment based on code points.
... Let's say we have the string of code units "A" "B" "heart emoji" "red combining character". Now we also have an array of positioning values with four elements.
... Now we need to come up with a mapping. There's to parts to this resolution: When you count, you count code point by code point. And the second part is: You're allowed to disregard any positions assigned to any combining characters, because the combining characters don't get rendered on their own.
... We didn't want to have a situation where regular characters following a combining character end up in the wrong position because they get assigned the wrong value from the position array.
... This ensures consistency between browsers.

AmeliaBR: It's not intuitive for hand-authoring. But the upside is that, outside of browser differences of the graphing cluster, the rest of the layout stays consistent from browser to browser. Once you get past the cluster that has the discrepancy, everything else is the same.

nmccully: Let's say there is a browser with a shaping engine and one that is not. The browser that has a shaping engine will get fewer glyph clusters from the engine than there are characters. The browser that *doesn't* have a shaping engine will presumably manually get positioning information and the combining red would be passed by itself to a table that gives a space.

AmeliaBR: There is a multi-stage lining up process. The way we're proposing is: positioning values to code points is a one-to-one matching. The next step (matching code points to your shaping) is where things can be discarded because of ligatures or combinations etc.

r12a: There are two issues. One, e.g. the word réd can have two code point representations, and an author cannot immediately see which one is used.

heycam: If the positional values are coming from a graphical editor, the graphical editor knows what code points are used and can generate the correct arrays.

AmeliaBR: Yes, it's only the hand authoring case that's hard.

myles: Alternatively, we could specify that the text content through normalization.

r12a: I do not like the idea of normalizing my content. Sometimes I want things to be composed and put the accents afterwards.

myles: Pragmatic / performance, might not be worth it.

r12a: The other issue is that, for example if you have some Persian, sometimes a zero-width joiner is used at the end of a word to produce the right shape. Then you need the two characters to stay together.
... and those are not a graphing cluster.

heycam: You would ignore the positioning value for the zero-width joiner.

AmeliaBR: If you're intentionally putting the ZWJ to change to a medial glyph, you still want contextual glyph selection.

heycam: CSS properties can change the effect of ligatures and other combinations, and you wouldn't want to have to adjust your positioning value array based on that.

nmccully: If you need backward compatibility with engines that don't understand the red combining thing, <missed>

myles: A lot of people said "there is incompatibility and we have to deal with it."

nmccully: Are you protecting from a malformed SVG from a bad player?
... Different browsers might get different results for cluster segmentation. Users want to get consistent positions everywhere. So we can't count positioning values based on the results from cluster segmentation. So we have to do the matching based on something in the source.

<heycam> mstange: seems like whenever you have parallel arrays, you should just have a single array of pairs

<heycam> ... why is this API necessary?

AmeliaBR / myles: There is existing content that uses it.

r12a: In Indic scripts you have conjuncts, you split a syllable at a time.
... (shows an example that has two grapheme clusters that combine into one visible unit)

myles: This is why we didn't want to specify what segmentation to use.

AmeliaBR: r12a, are you ok with keeping the existing resolution?

r12a: It's not pretty, but I understand why it's there, and I can't figure out anything better.
... (shows a testcase that renders differently in Firefox and Chrome, where diagonal Arabic text is rendered top-right to bottom-left in Firefox and top-left to bottom-right in Chrome)

RESOLUTION: Do not change the previous resolution.

- DRAFT -

SVG Working Group Teleconference

18 Sep 2019

Attendees

Contents