23:40:32 RRSAgent has joined #svg 23:40:32 logging to https://www.w3.org/2019/09/18-svg-irc 23:40:34 RRSAgent, make logs public 23:40:34 Zakim has joined #svg 23:40:36 Meeting: SVG Working Group Teleconference 23:40:36 Date: 18 September 2019 23:40:39 rrsagent, this meeting spans midnight 23:40:52 chair: krit 23:41:01 present+ 23:50:35 prushforth has joined #svg 23:51:12 prushforth has left #svg 00:01:30 present+ 00:02:04 lizheming has joined #svg 00:20:22 plh has joined #svg 00:24:46 mstange has joined #svg 00:24:49 AmeliaBR has joined #svg 00:25:01 ScribeNick: mstange 00:25:08 prushforth has joined #svg 00:25:10 satakagi has joined #svg 00:25:10 present+ mstange 00:25:16 kevers has joined #svg 00:25:20 https://github.com/w3c/svgwg/issues/731 00:25:20 present+ prushforth 00:25:24 present+ 00:25:41 Topic: Agenda 00:25:49 present+ 00:26:49 krit: We also want to discuss test suites, progress, plan for next year. Should we start with that? 00:26:52 heycam: I'm interested in tests. 00:27:22 krit: Amelia, anything else? 00:27:31 AmeliaBR: I think we have enough here. If we get bored, we have lots of open issues. 00:27:58 Rossen_ has joined #svg 00:28:34 AmeliaBR: We should ping gsnedders before we talk about tests. 00:28:58 skk has joined #svg 00:29:00 krit: What should we discuss? How to write a test? Or what WPT tests look like? 00:29:12 krit: Requirements for SVG tests, like which ones apply to non-browser environments, that sort of thing. 00:29:19 s/krit/AmeliaBR/ 00:29:28 krit: Maybe also a review of the test suite? 00:29:30 AmeliaBR: Yes. 00:29:58 krit: There are a couple of fxtf topics. Let's move those later, too. 00:30:43 krit: 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. 00:30:55 heycam: There was discussion about moving the specs to the CSS repository. Has there been a decision? 00:30:59 Rossen: Yes. 00:31:00 AmeliaBR: Yes. 00:31:09 krit: Tab Atkins has an action for that. 00:32:15 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. 00:32:32 Rossen: I remember that there was a draft with the non-scaling aspect. 00:32:41 krit: For vector effects we had a couple of additions. 00:32:55 AmeliaBR: Those wouldn't be specific to hatches, they would be specific to gradients and patterns. (?) 00:33:02 AmeliaBR: Would user space on use be enough? 00:33:05 krit: Let's discuss this later. 00:33:17 Rossen: If there was an open issue on this, that would be great. 00:33:38 Topic: Short status update 00:34:12 krit: We have 86 open issues. 40 of those are marked needs-editing. They are distributed to different chapters. 00:34:37 krit: Issues in SVG Core are spanning multiple sections. 00:35:05 krit: What is the expectations for 1. fixing the issues and 2. the timeline when to fix them? 00:35:19 krit: So far, AmeliaBR did a lot of changes recently. I tried to keep up but had no chance. 00:35:27 krit: The text chapter is still open and requires some contributions to fix them. 00:35:41 krit: I don't think we have other members than Tav who's looking at those. 00:35:53 krit: Tav is still an active member but he hasn't done any edits in the last two or three months. 00:36:07 AmeliaBR: We can definitely go through things like need-editing issues where we know what the changes need to be. 00:36:08 bdekoz has joined #svg 00:36:16 AmeliaBR: They just need to be done. 00:36:26 heycam: It would be good to have actual names on the issues. 00:36:52 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. 00:36:59 heycam: I can do some today. 00:37:15 krit: Rossen, is there somebody at Microsoft who could join the WG or look at some of the issues? 00:37:25 Rossen: I have to check how much time David Storey has. I know he was interested. 00:37:33 AmeliaBR: And he's familiar with stuff so it's easy to ramp up. 00:37:42 Rossen: And between myself and ??? we can spend some time. 00:37:51 krit: We are in the PR state, so we don't expect huge changes. 00:37:58 krit: It's going to be mostly small edits. 00:38:13 s/???/Bogdan/ 00:38:19 krit: We do not have all the members here. We probably cannot assign all the issues, but certainly some of them. 00:38:36 heycam: With the number of open issues discussed, is there (missed) 00:38:58 krit: We made some changes that are normative and require a CR update. 00:39:13 krit: We should fix as many normative changes as possible. 00:39:38 Rossen_: The issues that are currently marked as needs-editing, are those resolved? 00:39:49 AmeliaBR: Yes, we know what to write for those issues. 00:40:09 AmeliaBR: If the resolution is missing in the issue, sometimes the github bot may have failed to pull them out of the transcript. 00:40:26 Rossen_: What about the definitions for the transform-box? 00:40:33 krit: We have those definitions already, just in the wrong place. 00:40:47 Rossen_: I was just trying to gauge how ready the need-editing issues are. 00:41:13 AmeliaBR: Every change goes through review. Make a PR, don't just commit. 00:41:21 krit: At least one member needs to review. 00:41:44 krit: We can go through the issues marked as needs-editing and take a brief look at them, and assign some of them. 00:41:50 s/transform-box/svg layout box vs css layout box, that looks more than editorial/ 00:42:02 krit: If you prefer, you can take a look first privately and then assign them. 00:42:30 krit: 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. 00:42:46 krit: I will ask Apple and Mozilla people to help out with contributing. 00:43:10 krit: AmeliaBR, what are you proposing for next year? 00:43:44 bdekoz_ has joined #svg 00:44:00 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. 00:44:26 krit: Having a timeline would communicate what we think the status of the SVG 2 spec is. 00:44:38 heycam: Do we have a good idea of what work is left to do, apart from knowing "this many issues"? 00:44:52 AmeliaBR: "This many issues" for editing. We have a few big ones, like cleaning up the use element sections. 00:45:08 AmeliaBR: If we don't get any implementer commitment for wrapping text, we have to clean up the text chapter. 00:45:26 AmeliaBR: There's also lots of other cleanup to do, most of which to address issues brought up by implementers saying "this isn't clear". 00:45:35 AmeliaBR: This won't be done by the end of the year, which was the target date in the charter. 00:46:03 AmeliaBR: 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?". 00:46:13 AmeliaBR: That's the issues we know about. Testing is still a whole other task. 00:46:48 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. 00:47:06 AmeliaBR: Teleconferences and bug testing take up time. 00:47:36 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. 00:47:42 krit: That's something that needs to be done in parallel. 00:48:10 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. 00:48:16 heycam: I think that is a good goal to work towards. 00:48:33 krit: Anything else to discuss? 00:49:02 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. 00:49:31 AmeliaBR: How high of a priority should adding tests be, from an implementers' perspective? 00:49:38 heycam: In some ways, the test suite is dependent on the spec. 00:49:53 krit: If we fix something, should be we be required to write tests along with it? 00:50:24 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! 00:50:35 AmeliaBR: Especially for any normative edits we should make the tests at the same time. 00:51:13 krit: Issues that are fixed in terms of spec editing work but don't have tests should marked with the needs-test label. 00:51:19 bdekoz_ has joined #svg 00:51:54 github: https://github.com/w3c/svgwg/issues/731 00:52:09 krit: Anything else? 00:52:15 AmeliaBR: We need more active contributors. 00:52:33 krit: If the issue is the telecon time, we can work on that. 00:53:12 Topic: non-scaling resources, patterns and hashes 00:53:46 s/, patterns and hashes/ (patterns)/ 00:54:09 https://svgwg.org/svg2-draft/coords.html#VectorEffects 00:54:35 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. 00:54:52 AmeliaBR: 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. 00:55:09 AmeliaBR: Currently, everything except non-scaling stroke is marked as at-risk because we don't have any browser implementations. 00:55:34 AmeliaBR: 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? 00:55:48 Rossen_: I can't commit to that. 00:56:01 AmeliaBR: Getting parity with something like the MS Office vector graphics is a strong argument. 00:56:33 AmeliaBR: 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. 00:57:29 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. 00:57:48 Rossen_: Visio is fully dependent on SVG. We also have partners interested in this. 00:58:08 krit: Is this something that should be picked up in the community group or in the working group? 00:58:15 Rossen_: Wherever progress will be made quicker. 00:58:34 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. 00:58:55 krit: Is this something that should be inside SVG 2 or in parallel to SVG 2 in a new module for vector effects? 00:59:15 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. 00:59:26 heycam: I'm worried about adding more things to SVG 2 if we're already tight on time. 00:59:38 AmeliaBR: At this point the whole of vector-effects is at risk and may get moved out. 00:59:48 Rossen_: In that case, it would make even more sense to have it in a new module. 01:00:19 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? 01:00:33 Rossen_: In terms of implementation we certainly have interest in it and plan to experiment with and work on it. 01:00:43 Rossen_: I don't know how the timeline is going to work compared to SVG 2 but I'm optimistic. 01:00:53 krit: What would all be included? Is there a need for gradients or other resources? 01:01:09 AmeliaBR: It would probably make sense from an implementation perspective to say "non-scaling paint servers". 01:01:11 Rossen_: Agreed. 01:01:32 krit: Ok. Who would make the proposal? 01:01:54 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. 01:02:15 krit: We talked about having a max and min scale level of strokes. 01:02:31 Rossen_: That would probably be a quick follow to non-scaling paint servers. Those are the bigger use case. 01:02:46 Rossen_: Non-scaling stroke was number 1 requirement, but that's in the spec now. 01:03:12 Rossen_: Being able to specify a range in addition to non-scaling was the additional errata to that, with some use cases but less priority. 01:03:18 Rossen_: Stroke and patterns are the two main requests. 01:03:39 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? 01:04:01 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. 01:04:33 AmeliaBR: Proposed resolution: Non-scaling paint servers as a future extension to vector-effects, exact spec or module to be determined. 01:04:48 heycam: Is vector-effect really the best place to put this? You can have patterns in a fill or a stroke. 01:05:02 AmeliaBR: Maybe it should be directly on the panit server? 01:05:15 RESOLVED: Explore non-scaling paint server functionality. 01:05:34 krit: I would be interested in helping out with the specification work, but in collaboration with an implementer. 01:05:42 krit: Anything else to discuss? 01:10:20 Rossen_: There were other use cases that Office was interested in. Mesh gradients, for example. 01:10:24 AmeliaBR: We need implementations! 01:10:36 myles: We're interested in that as well. 01:11:03 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. 01:11:09 Topic: SVG native 01:11:37 myles has joined #svg 01:11:42 present+ myles 01:12:08 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. 01:12:35 ... 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. 01:12:45 ... There are a number of use cases where fire-and-forget is useful for vector graphics. 01:13:14 ... One of them is artwork. Rasterizing all of the strokes would end up with a much higher size than the information contained in it. 01:13:28 ... For these use cases, vector images would be very useful. 01:13:51 ... 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. 01:14:17 ... 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. 01:14:44 ... 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. 01:15:01 ... This is unfortunate because authors have to create many different sizes. Vectors would be better. 01:15:16 ... The goal is to describe a subset of SVG that can be widely implemented on platforms that are not the web. 01:15:37 ... There are security implications as well, because e.g. icon rendering is usually not sandboxed, unlike web views. 01:15:50 heycam: Can you briefly describe the desired subset? 01:16:23 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. 01:16:37 myles: For that reason, we don't want to include things like markers, because those can be described by other geometry. 01:17:00 ... 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. 01:17:18 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 01:17:21 ... 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. 01:17:38 ... The subset is shapes, paths, gradients, clipping. 01:17:44 ... Patterns are not there because they can be flattened. 01:18:10 ... Also no external resources. It should work like a JPEG. JPEGs can't reference other JPEGs. No resources, no JavaScript. 01:18:25 AmeliaBR: It's designed to match the SVG-in-OpenType minimum recommended support level. 01:18:55 ... Any conformant SVG-in-OpenType renderer would be able to render SVG native. SVG-in-OpenType allows more features but warns. 01:19:32 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. 01:20:50 ... 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? 01:21:37 ... 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. 01:22:15 ... 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. 01:22:44 ... So soon Office will need to have full support. There has to be full transparency and awareness of what we're getting ourselves into. 01:23:08 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. 01:24:03 ... 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. 01:24:24 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. 01:24:59 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. 01:25:07 myles: Today people use media queries for this? 01:25:15 AmeliaBR: Yes. You can use them even in static SVGs. 01:25:37 AmeliaBR: The current plan for SVG Native is "presentational-attributes only". 01:25:58 Rossen_: Our native implementation, from what I'm hearing, is a little bit broader. 01:26:40 ... 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. 01:28:10 ... 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. 01:28:55 ... 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. 01:29:41 q? 01:29:46 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. 01:29:55 q+ 01:30:11 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. 01:30:33 ... 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. 01:30:44 ... And what's the best way to define which parts of SVG should or shouldn't be standardized. 01:31:06 ... 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. 01:31:24 ... 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. 01:31:38 ... It is definitely a consideration that the subset that makes sense today may not make sense in the future. 01:31:50 ... Just like the SVG tiny subset didn't make sense once we got smartphones. 01:31:57 q- myles 01:32:09 myles: The fact that some people want more from a standard is true for every standard. 01:32:18 ... It is up to this group to decide whether a particular feature request is valid or not. 01:32:27 ... The ones that are can be added. 01:32:45 ... If and we do add features, we can figure out how to do graceful fallback and versioning and things like that. 01:32:55 ... It is worth stating why it's ever worth standardizing SVG Native. 01:33:27 ... 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. 01:33:34 ... Android also supports yet another different subset. 01:33:46 ... That's why I think this is worth standardizing. 01:34:03 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. 01:34:28 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. 01:34:46 ... Similarly, if we come up with a spec that nobody implements, we also have failed. We need implementations and this group to work together. 01:35:21 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. 01:35:38 ... We are restricting people, putting them in a smaller box than they want to be in. And that's the slippery slope. 01:36:07 myles: There is a spec for this, but it doesn't contain my recent edits. 01:36:23 https://svgwg.org/specs/svg-native/ 01:49:46 skk has joined #svg 02:02:27 ScribeNick: myles 02:03:06 gsnedders: I have no idea what i'm doing here 02:03:55 krit: The next agenda topic is the test suite 02:04:11 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. 02:04:23 present+ 02:04:27 present+ 02:04:28 present+ 02:04:47 present+ 02:04:48 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. 02:05:38 AmeliaBR: 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. 02:06:48 AmeliaBR: 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 02:06:48 are browser-specific. 02:06:53 AmeliaBR: Does anyone have opinions on ordering? 02:07:19 AmeliaBR: It might be useful to go through what a ref test looks like, if you can wing it, gsnedders 02:07:54 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 02:07:59 emilio: for WPT reftest, you need a 02:08:05 gsnedders: It has to be in the HTML namespace 02:08:16 emilio: If you want a proper SVG document, you need XMLNS, etc. 02:08:17 gsnedders: yes 02:08:24 emilio: I have never done that. it's fine 02:08:43 gsnedders: There's nothing stopping us from adding SVG-specific solution, but we haven't done it yet 02:09:38 https://xmlgraphics.apache.org/batik/tools/browser.html 02:09:55 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 02:09:59 prushforth has joined #svg 02:10:06 mstange: There's one implementation that supports scripting but not HTML 02:10:12 present+ prushforth 02:10:24 s/mstange/AmeliaBR/ 02:11:05 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. 02:11:16 gsnedders: We're willing to push people to do SVG references.... but... 02:11:34 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 02:11:55 krit: Before we continue, does everyone know what WPT is? 02:12:06 krit: 02:12:11 gsnedders: Yes, I'm aware. 02:12:24 gsnedders: It's just a policy of WPT has been focussed on browser implementations. 02:12:30 WPT SVG tests: https://github.com/web-platform-tests/wpt/tree/master/svg 02:13:55 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. 02:13:55 Yes. 02:14:26 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 02:14:43 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 02:15:00 AmeliaBR: So the reference is either a standalone PNG file, or an PNG file embedded in a SVG 02:15:06 emilio: PNGs are not great 02:15:25 emilio: I would prefer using HTML 02:15:33 AmeliaBR: Then we're excluding some implementations 02:15:37 q+ 02:15:54 q? 02:16:29 emilio: The problem with PNGs, they don't account for running the test on other devices 02:16:50 q- heycam 02:17:04 myles: We don't run pixel tests because they're too flakey because of colorspaces 02:17:18 heycam: If we just have a rectangle, there's not much in SVG we can compare to. HTML is better here. 02:17:29 gsnedders: We can almost always have another path in SVG 02:17:37 AmeliaBR: In the vast majority of cases, a simpler SVG is possible. 02:17:57 We're not really interested in drawing rectangles at all. We're more interested in things like viewports 02:18:10 gsnedders: We have bad coverage of the basic cases in WPT 02:19:35 AmeliaBR: Can you have expected-mismatch tests? 02:19:36 gsnedders: yes! 02:20:16 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 02:20:37 krit: can we resolve on anything? how about not having PNGs? 02:21:14 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. 02:21:37 heycam: A long time ago I added some basic WPT reftests for rectangle rendering. They use HTML reference files. 02:21:55 heycam: I was writing a few WPT reftests as a demonstration. 4 years ago. 02:22:04 AmeliaBR: We've got rect01 is SVG with an HTML reference. 02:22:24 emilio: Another thing to be aware of is multiple matches or mismatches in WPT 02:22:28 gsnedders: That might change 02:22:31 emilio: Please make it change 02:23:09 https://github.com/web-platform-tests/rfcs/pull/15 02:23:09 gsnedders: Any number of or , the tests passes if *any* of these are satisfied, rather than *all* of them are satisfied 02:23:17 krit: why? 02:23:30 gsnedders: Whoever was setting it up in the first place messed it up 02:24:06 myles: what about tests that test that the browser doesn't crash 02:24:16 gsnedders: Then use testharness.js. 02:24:40 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 02:24:43 krit: You could just use an expected-mismatch test 02:25:05 krit: Here are two examples of reference tests. One of them requires the parser understands XML. It sets namespaces for HTML. 02:25:28 AmeliaBR: That's used for the elements. These should be HTML namespaced link elements. All web platform tests require metadata which are done with HTML and 02:25:55 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 02:26:14 krit: Does the test infrastructure understand XML and namespaces, etc/ 02:26:15 ? 02:26:17 gsnedders: yes. 02:26:42 heycam: In the first test, width=800, height=8000. What is the window size that WPT uses 02:26:43 ? 02:26:46 gsnedders: 800 x 600 02:26:52 gsnedders: For JS tests it's technically undefined 02:27:25 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 02:27:37 gsnedders: There's discussions about making custom viewport sizes for some tests. But it hasn't happened 02:27:55 AmeliaBR: We don't need that now but we'll let you know if we do need it in the future 02:28:04 q+ 02:28:07 heycam: Is there a place in WPT tree to put a template file that people can copy from? 02:28:21 gsnedders: We have some in /docs inside writing-tests/test-template 02:28:29 AmeliaBR: That's a separate repo? 02:28:31 gsnedders: no 02:28:33 AmeliaBR: It's a folder. 02:28:42 mstange: Does WPT have support for different device pixel ratio scales? 02:28:44 gsnedders: Nope. 02:28:52 gsnedders: It's an issue reported somewhere 02:28:58 q- mstange 02:29:01 https://github.com/web-platform-tests/wpt/issues/7135 is changing viewport size 02:29:09 https://github.com/web-platform-tests/wpt/issues/7140 is changing DPI 02:29:12 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. 02:29:32 gsnedders: This is a known issue. 02:31:06 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 .... 02:31:17 AmeliaBR: Nicos did a whole bunch to convert SVG marker tests to WPT tests 02:31:55 AmeliaBR: 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. 02:31:57 heycam: https://github.com/web-platform-tests/wpt/blob/master/docs/writing-tests/test-templates.md has templates 02:31:59 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. 02:32:10 AmeliaBR: People will need to look at for one option as they're doing this 02:32:50 AmeliaBR: 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 02:34:09 heycam: We have a bunch of SVG reftests internally. We might want to port them over to WPT 02:34:11 yes please 02:34:17 AmeliaBR: that would really help 02:34:30 gsnedders: Most of the gecko ones have HTML as references, IIRC 02:34:35 heycam: not really.... 02:34:47 emilio: some of them.... 02:34:48 s/SVG marker/SVG 1.1 marker/ 02:34:57 02:35:09 kevers has joined #svg 02:35:14 q? 02:35:55 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 vs the main document 02:36:13 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. 02:36:35 myles: can you just put the SVG in an ? 02:36:42 AmeliaBR: That's one option. 02:36:52 emilio: I don't think a lot of the new CSS tests use the at all 02:38:05 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 02:38:12 AmeliaBR: I need to sit down and look at what we can do here. 02:38:30 krit: Is there any name pattern that implementations which want to use WPT to rely on to know which tests to test? 02:38:44 krit: e.g. how do i know which tests my implementation cares about/ 02:38:51 gsnedders: there's no way to filter by name righ tnow 02:39:30 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 02:39:55 gsnedders: That's not a requirement because there's a manifest which already exposes this information. 02:39:55 AmeliaBR: It's also worth while just for cleanliness 02:40:06 gsnedders: Navigability is important 02:40:35 ACTION AmeliaBR: Go through all the tests, and move tests around to match the README, and update the README 02:40:36 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]. 02:41:11 heycam: Metadata tended not to be used in tests these days? That means people aren't using ? What about spec link? 02:41:39 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 02:41:55 emilio: CSS usually puts all the tests in the top level 02:41:55 gsnedders: ::frustration:: 02:42:17 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 02:42:28 gsnedders: The CSS tests rely on the CSS tooling, those rely on 02:42:42 krit: I think that WPT wants to do something similar in the future. 02:43:54 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 02:44:12 gsnedders: 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 02:45:34 heycam: I'm adding templates to test-templates.md file, and I will include the in there 02:45:55 AmeliaBR: In assertions, rel is also helpful because it shows up in the FYI reports 02:45:55 gsnedders: This is different 02:45:57 emilio: This is about putting a link to a spec in the file 02:46:09 AmeliaBR: There's also soethign that tells you what you're testing 02:46:24 gsnedders: What shows up is the testharness.js tests. Asserts can have messages as their final argument, whcih does show up. 02:46:29 AmeliaBR: There's nothing similar for a reftest? 02:46:45 AmeliaBR: In the test, you shoudl be able to say what it's testing 02:46:51 s/soethign/something/ 02:47:16 gsnedders: You can put a comment in the test 02:47:31 AmeliaBR: I may be adding a feature request 02:47:55 emilio: Most CSS reftests use the filename 02:48:23 heycam: I'm not creative enough to write useful filenames for 100 tests that I'm adding 02:48:47 gsnedders: Just do the best you can 02:50:03 e.g., don't have path-001 to path-100, but path-data-syntax-001 etc. 02:50:53 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 02:51:09 gsnedders: You're using bikeshed, right? 02:51:28 AmeliaBR: we're using heycam's brilliant combination of scripts that have crystallized and are somehow holding together 02:51:55 heycam: It's a large spec and it's multi-page makes it difficult to Bikeshed. But we'd like to 02:51:55 krit: And it's lots of work. 02:51:55 gsnedders: I knew there was talk at some point 02:52:11 AmeliaBR: It's a legacy system we're keeping alive for SVG 2, and for new modular specs, we're using bikeshed 02:52:26 gsnedders: Bikeshed has a way of including results, and there was talk of integrating that with WPT.fyi 02:53:17 gsnedders: 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 02:53:18 s/including results/including tests/ 02:53:32 gsnedders: The number of non-bikeshed specs is decreasing 02:53:44 s/that with WPT.fyi/that with results from wpt.fyi/ 02:53:56 AmeliaBR: We can just use the fact that WPT test directories match the chapters in the spec 02:54:08 AmeliaBR: It calls python scripts which calls scripts 02:54:20 s//node/ 02:54:30 AmeliaBR: The main makefile builds SVG 2, but if you want modular spec, then go into a specific folder 02:54:39 gsnedders: It's better than CSS 2.1 at least 02:54:41 emilio: That's a low bar 02:54:42 gsnedders: yes. 02:55:36 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 02:55:55 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 02:57:28 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 02:57:28 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 02:57:48 https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+author%3AAmeliaBR+label%3A%22Test+suite%22 02:57:55 gsnedders: HTML5 went to req with an entire top section of the spec not having tests 02:57:55 AmeliaBR: Which section? 02:57:55 gsnedders: "Browsing the web." 02:58:06 gsnedders: It was not interoperable at the time HTML5 went to req 02:58:14 s/Browsing the Web/Loading Webpages/ 02:58:34 AmeliaBR: At some point I'd like to do an end-to-end, every paragraph, do we have a test for it 02:58:47 s/to req/to REC/ 02:58:51 krit: Ideally, every paragraph would have its own ID so we can have a test link to it directly 02:59:02 krit: You can have multiple links to multiple parts of the spec, including subsections. 02:59:11 heycam: If we only rely on the directory names, then... 02:59:14 gsnedders: WPT doesn't cope with that. 02:59:26 AmeliaBR: Another reason to include that metadata is to link to a precise reference. 02:59:28 s/WPT doesn/Peter's tool doesn/ 03:00:05 AmeliaBR: It's noon. I think we're done? 03:00:15 krit: Thanks to the WPT team!!! 03:00:22 AmeliaBR: Yes! Super helpful! 03:00:50 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 03:01:08 Tutorial from WPT about writing ref tests, in general: https://web-platform-tests.org/writing-tests/reftest-tutorial.html 03:01:20 AmeliaBR: WPT has a blog, including tutorials 03:01:32 AmeliaBR: This is a good reference. 03:01:55 gsnedders: If you find holes in the documentation, file a bug on the docs. 03:02:19 heycam: If I were to get Gecko's SVG reftests imported to WPT, would you be fine without actually reviewing the tests? 03:02:26 gsnedders: You could let the 2-way sync do it 03:02:36 heycam: It would be a lot of work to review them 03:02:43 heycam: The tests are probably mostly correct.... 03:02:59 AmeliaBR: That will show up when the tests fail in other browsers 03:03:08 https://github.com/web-platform-tests/wpt/blob/master/svg/META.yml 03:03:28 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. 03:03:54 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 03:04:09 krit: If you just follow the repository, then you get thousands of notifications. How to do this? 03:04:44 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 03:04:58 gsnedders: You get added as a reviewer by a bot based on the yaml file. That will notify you 03:05:17 AmeliaBR: I do send out a digest of SVG-related PRs on a weekly basis. 03:05:18 https://web-platform-tests.org/reviewing-tests/email.html also has some guidelines for filtering GitHub notification email 03:05:34 gsnedders: There's also WPT docs have advice about how to filter notifications 03:05:54 AmeliaBR: I'm filtering on the word "SVG" 03:06:11 SimonSapin: Regarding the directory structure, I just looked at the docs, it says there are two common ways: 1) The file structure 2) Nested structure, each subdir corresponding to the ID of a heading in the spec 03:06:34 AmeliaBR: We haven't done that. We're doing it by chapter. We could change this if necessary. We're using metadata to link to specific sections. 03:06:45 SimonSapin: How far do we want to nest directories? 03:06:59 gsnedders: Until you don't have directories that are hundreds of files 03:07:16 s/The file structure/The flat structure/ 03:07:28 krit: Let's go to lunch! 03:08:22 AmeliaBR: Yes please 03:08:23 gsnedders: +1 03:08:38 💯 03:08:58 RRSAgent, make minutes 03:08:58 I have made the request to generate https://www.w3.org/2019/09/18-svg-minutes.html gsnedders 03:09:36 Meeting: SVG WG TPAC 2019 Day 1, Thursday 03:59:16 satakagi has joined #svg 04:23:48 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. 04:29:24 kevers has joined #svg 04:30:22 ScribeNick: heycam 04:30:34 Topic: focusability compatibility 04:30:56 github: https://github.com/w3c/svgwg/issues/736 04:31:00 prushforth has joined #svg 04:31:08 present+ 04:31:32 rniwa has joined #svg 04:31:38 present+ 04:32:03 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 04:32:06 ... that's not what HTML does 04:32:20 ... to decide whether something is scrollable, you must update styles and layout 04:32:33 AmeliaBR: this list was based on the accessibility desires that scrollable should be focusable 04:32:45 ... since this isn't an SVG specific feature, it's about HTML nested in SVG, we should be consistent with HTML 04:32:55 ... even if that means deferring to platform conventions that aren't ideal 04:33:15 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 04:33:30 ... if it *could* have scrollbars 04:33:38 ... we do allow stuff with scrollable overflow to be focusable 04:33:48 AmeliaBR: I think WebKit is the odd one out 04:33:52 ... but it's an HTML issue 04:33:57 myles has joined #svg 04:34:05 ... I'm OK resolving to add a condition to that, that defers to HTML 04:34:16 ... so element within a fO would be focusable accoridn gto the foreign language 04:34:27 rniwa: the issue is more the consistency with HTML here 04:34:32 emilio: I agree it should be consistent 04:35:05 krit: anything else that could be scrollable? 04:35:15 rniwa: HTML spec section 6.4.2 defines focusable area 04:35:23 ... would be great if the SVG spec just delegates that to decide what's focusable 04:35:29 https://html.spec.whatwg.org/multipage/interaction.html#focusable-area 04:35:49 RESOLUTION: Defer to HTML for focusability of foreignObject content 04:36:09 AmeliaBR: second part of the concerns are more SVG specific 04:36:13 ... the legacy focusable attribute 04:36:28 rniwa: one thing that is unclear is the old SVG Tiny 1.2 talks about focsuable = true,false,auto 04:36:32 ... new spec doesn't talk about any of the values 04:36:40 ... it's unclear whether tabindex or focusable takes priority 04:36:53 AmeliaBR: good criticism that we should have specified the interaction 04:36:58 ... definitely want tabindex to take precendence 04:37:05 ... only we mention focusable is to avoid breaking content that uses that attribute 04:37:19 rniwa: do we still want to support the 3 values? 04:37:32 oriol has joined #svg 04:37:33 heycam: do we still need to support that at all? 04:37:37 AmeliaBR: it was working in Edge, at least 04:37:51 rniwa: focusable=true is clear cut, to imply tabindex=0 04:37:56 ... false, if it's set, it's like a noop 04:38:10 AmeliaBR: focusable=false got used a lot since MS browsers were treating every inline SVG as a focusable item 04:38:33 ... we can say focusable=false is respected, as long as tabindex overrides it 04:38:53 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? 04:39:03 AmeliaBR: officially define focusable, but deprecated, with those three values 04:39:22 rniwa: one tutorial I found says that focusable would override tabindex... 04:39:55 heycam: but do we have any implementations of focusable? 04:41:08 AmeliaBR: Edge does support it 04:41:25 mstange: there's a Firefox bug, WONTFIXed 5 years ago 04:41:32 ... saying it wasn't in SVG 2 04:41:32 https://bugzilla.mozilla.org/show_bug.cgi?id=409404 04:42:40 [some discussion about having it in the spec, allowed to implement, not required] 04:42:52 rniwa: if Edge wasn't going to change, normative or not probably doesn't matter 04:43:01 rniwa: I'm curious what Edge does in terms of priority between focusable and tabindex 04:43:31 emilio: in the bug comment, IE <= 11 only supported focusable, and not tabindex 04:44:29 rniwa: can we agree on a non-normative note? 04:44:38 AmeliaBR: I think we should have a normative thing, if you implement it, this is how it interacts with tabindex 04:44:58 ... I wouldn't mind saying every browser should implement it but it's deprecated 04:45:08 rniwa: question is whether implementors will implement focusable 04:45:11 myles: I think the answer is no 04:46:02 krit: I think the note in the spec should advise against using it 04:46:25 RESOLVED: 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. 04:47:55 addison has joined #svg 04:48:57 Topic: xlink:href in sourceless iframes 04:49:03 github: https://github.com/w3c/svgwg/issues/700 04:49:13 AmeliaBR: we have discussed this 04:49:18 Bert has joined #svg 04:49:35 ... this is related to Shadow DOM in the simple sense that it's a similar problem in Shaodw DOM 04:49:42 ... same document references in trees that don't have a base URL 04:49:51 ... but the iframe is a little more isolated from the parent document 04:50:02 ... if cross reference works inside a shadow tree, it should also work inside an iframe document 04:50:05 ... that's even more isolated 04:50:11 rniwa: I think anchor tag inside sourceless iframe works as well 04:50:19 ... this should somehow be resolved in the HTML spec 04:50:30 ... so we should be using that mechanism 04:50:38 AmeliaBR: is that in the HTML spec? 04:50:42 rniwa: hyperlinks already work... 04:50:47 AmeliaBR: the special rules for SVG hash references 04:51:05 heycam: that's defined in CSS somewhere? 04:51:09 AmeliaBR: that's another set of special rulse 04:51:12 s/rulse/rules/ 04:51:52 AmeliaBR: 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 04:52:24 RESOLVED: Defer to HTML for how to handle local references inside sourceless iframes 04:52:49 ACTION: AmeliaBR to file an HTM Lissue for sourceless iframe local references 04:52:49 Created ACTION-3871 - File an htm lissue for sourceless iframe local references [on Amelia Bellamy-Royds - due 2019-09-26]. 04:53:52 Topic: SVG2 spec means elements within a tag can not be targeted for styling 04:53:55 github: https://github.com/w3c/svgwg/issues/367 04:54:03 emilio: SVG 1 says you take the style rules from the reference element 04:54:13 ... that not only changes the behavior of decendant combinators, but also element specific states 04:54:34 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 04:54:42 ... and then inherited styles are inherited in 04:54:50 ... nothing in Web Components shadow DOM that's at all like that 04:55:29 ... trying to harmonize with shadow DOM, we defined it so that the style sheet is cloned in the shadow trees 04:55:40 ... but that could break some select matching compared with the original element 04:55:47 ... what gets fixed is the interactive selectors 04:55:54 rniwa: do we know what implementations do? 04:56:01 AmeliaBR: Firefox matches SVG 2 spec 04:56:21 emilio: Blink and WebKit, in order to resolve style in the use subtree, you match the referenced element 04:56:29 rniwa: so the original source element is used for styling 04:56:36 emilio: so when you hover over the reference, all the clones get hover styles 04:56:55 ... the Firefox behavior is a bit unfortunate, regarding the combinators, but we haven't received many bugs about that 04:57:02 krit: how long has it been shipping? 04:57:14 emilio: more than 2 years 04:57:27 AmeliaBR: Firefox had never implemented the SVG 1.1 spec 04:57:28 heycam: right 04:57:34 myles: did you have to add special case SVG code? 04:57:36 emilio: not really 04:58:03 ... 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 04:58:25 AmeliaBR: it can probably be represented by the adopted style sheets concept 04:58:29 emilio: yeah.... 04:58:38 ... but to implement it efficiently, you just look up to the parent scope 04:58:47 rniwa: conceptually you're copying the rules 04:58:48 emilio: yes 04:59:03 ... conceptually you just look at the outside use shadow tree 04:59:20 AmeliaBR: when this has previously come up, Rossen has been cautious of breaking changes 04:59:21 satakagi_ has joined #svg 04:59:33 ... but we don't have a sensible spec 04:59:46 ... in the existing SVG 1.1 match browsers, there were inconsistencies in terms of interactive styles, animations, whether htings get copied 04:59:57 ... so in the details, we don't have a spec to define how those things work in a way that's actually corss browser 05:00:07 ... so either way, implementations would have to change if we want truly consistent behavior 05:00:21 ... 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 05:00:33 ... that also takes care of interactions, animations, etc. 05:00:51 rniwa: the question to me is which behavior is more compatible with existing content 05:00:55 ... also author expectations 05:01:10 emilio: regarding author expectations, it's tricky. SVG 1 kind of matches "I'm styling the element I'm cloning" 05:01:14 ... so ancestor combinators work 05:01:21 ... however it doesn't match expectations of :hover 05:01:27 ... the SVG 2 behavior works the other way around 05:01:35 ... for authors who are familiar with shadow trees, it probably makes sense 05:02:00 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 05:02:05 ... but when you explain how to fix it, it was OK 05:02:13 ... the :hover not working, that's a much more intrinsic confusion 05:02:18 ... and there's no easy way to explain that 05:02:39 rniwa: whatever solution we come up with, it should handle :hover. :focus would even be a bigger problem 05:03:01 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 05:03:04 Bert has left #svg 05:03:24 rniwa: there's also some niceness in that if we had adopted style sheets, it could be described in that way 05:04:13 AmeliaBR: I need to talk to Antti and folks to check what they think 05:04:18 s/AmeliaBR/rniwa/ 05:04:39 plh has joined #svg 05:04:43 AmeliaBR: we should probably poke a Chromium engineer for feasibility too 05:04:46 http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7216 is a testcase that shows the difference of behaviors 05:05:01 krit: we've had this issue for a long time, it's been waiting for implementor view for a while 05:05:10 emilio: I recall having a WebKit patch for that in the past... 05:06:30 emilio: there's a test case I've pasted 05:06:53 krit: how does the shadow content know about the viewport size? 05:07:06 AmeliaBR: that's the same as regular shadow DOM, it uses the document viewport for MQs etc. 05:07:35 rniwa: might want to consider what happens if you support shadow root on an SVG element at some point 05:08:05 AmeliaBR: definitely want to support custom SVG elements with shadowRoot 05:08:31 q? 05:09:15 [some discussion about use elements pointing to foreignObject] 05:09:38 rniwa: https://github.com/w3c/svgwg/issues/511 05:10:47 krit: but in general we agree we don't want foreignObject in the shadow tree? 05:10:50 rniwa: yes, that would get hairy 05:11:03 ... then you can have SVG, MathML, plugins.... 05:13:01 RESOLVED: child content of foreignObject is stripped out of a use element shadow tree clone -- check browsers for exact impl details 05:13:16 RESOLVED: No change to spec around use element styling, but focus on getting feedback from implementors about feasibility of current SVG 2 model 05:13:57 Topic: Referencing SVGs through USE from other domains 05:13:59 github: https://github.com/w3c/svgwg/issues/707 05:14:08 AmeliaBR: cross origin use elements 05:14:28 ... 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 05:14:43 ... we have no way of cloning from a file on another domain, which is problematic for people who use CDNs for static assets 05:14:59 krit: we already resolved to move that to SVG 2, but Blink is waiting for feedback if they can implement it 05:15:19 AmeliaBR: Robert Longson, Mozilla contributor, pointed out other browsers haven't supported , , cross origin references 05:15:24 ... so shouldn't count on them doing it for 05:15:35 ... but we did have fsoder on the Chromium team saying it shouldn't be too difficult to consider 05:15:46 emilio: from Opera 05:16:03 krit: do we stand by our resolution to defer? 05:16:17 AmeliaBR: we all agree it's desired, but should it be in SVG 2 05:16:20 myles: are there implementations? 05:16:22 emilio: no 05:16:25 myles: then it shouldn't be in SVG 2 05:16:49 emilio: what are the security implementations? not confident enough about that 05:16:59 AmeliaBR: it's similar to other active content references, cross origin filters 05:17:06 emilio: but cross origin use elements insert content inside the host document 05:17:13 ... it's not the same as just applying a filter 05:17:24 emilio: if you leave the foreignObject details as is, that could be a security issue 05:17:36 AmeliaBR: the other things we strip are things like scripts 05:17:47 emilio: scripts only run once, so the clone knows the script has already run 05:17:57 AmeliaBR: and you don't scripts in the external file 05:18:06 ... but security things would need to be spelled out clearly 05:18:12 emilio: someone should do a security audit of the feature 05:18:23 ... cross origin filters, didn't want we want to remove them? 05:18:27 mstange: it's come up again and again 05:18:35 ... this is filter on cross origin iframes 05:18:47 ... nobody has suggested removing cross origin images referenced by feImage 05:19:00 AmeliaBR: the closest thing here is something like HTML Imports, cloning content into the DOM from another file 05:19:14 ... even for that reason, let's wait for the HTML folks to figure out the security concerns here 05:19:20 plh_ has joined #svg 05:19:20 ... and we really need to get SVG 2 stabilized 05:19:30 ... minutes from Jul 16 had 3 different solutions 05:19:44 ... 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 05:20:13 krit: I would rather let us defer the entire feature 05:20:35 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 05:20:45 krit: could also be done in the CG 05:21:33 RESOLVED: defer cross origin use element references to post-SVG 2 05:23:13 All text issues: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3A%22Text+chapter%22 05:23:31 Two tagged internationalization: https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3Ai18n-tracking 05:29:21 satakagi has joined #svg 05:30:13 Topic: make the behavior of an invalid mask be consistent with clip-path and filter 05:30:16 github: https://github.com/w3c/fxtf-drafts/issues/130 05:30:27 krit: the issue is what happens if a filter, mask, clip-path is invalid 05:30:36 ... for filters, what happens if there's no content 05:31:00 krit: so if you have a rect, apply a clip-path, but the referenced has no children 05:31:22 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? 05:31:25 AmeliaBR: no, but good question 05:31:28 plh_ has joined #svg 05:32:01 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 05:32:06 ... so it would become blank 05:32:34 AmeliaBR: I was thinking of the basic case of when you're first loading. but in the interactive case, sometihng disappearing would be bad 05:32:55 myles: we have a similar situation with async image decoding 05:33:04 ... where if oyu're on the first load of a webpage, we will not show the image until it's fully decoded 05:33:29 ... 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 05:33:49 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 05:34:00 ... we have different rules for different elements, and different implementations 05:34:07 ... my general preference is to try to harmonize as much as possible 05:34:30 krit: I can go through the clip path examples 05:34:44 krit: [reads from the table] 05:34:56 myles: the no content case, I remember implementing this 05:35:02 ... there was an SVG 1.1 test suite test for this 05:36:46 myles: our fonts implementation doesn't match Gecko, it matches others. [it skips invalid child content of the clipPath] 05:38:06 nmccully has joined #svg 05:39:43 krit: Firefox is the odd one out here mostly, would they be willing to change? 05:39:52 mstange: there's cases are all handled explicitly, should be simple to change 05:40:02 ... not sure on jwatt's or longsonr's opinion 05:43:29 RESOLVED: 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 05:44:22 AmeliaBR: what's different between filters and clip/mask, is missing references 05:44:33 ... if you have a url() reference to a missing element, clip/mask just applies no clip/mask 05:44:40 ... for filter, the filtered element disappears 05:44:46 ... which is usually not helpful 05:44:54 krit: not sure if I did change this, but I would like to align with mask and clip 05:45:37 ... the Filters spec has a special rule, if the url() reference is to a different file, then you treat it as a no-op 05:45:42 krit: [reads spec text] 05:45:53 ... so we already have changed the spec to not make the filtered element disappear 05:46:20 myles: putting a filter on an element causing a stacking context, so we can't treat it as 'filter:none' 05:46:37 AmeliaBR: as a no-op filter item 05:46:52 krit: so a stacking context still gets created 05:47:04 AmeliaBR: if your filter is invalid, that would be something to clarify in the spec 05:47:12 krit: didn't find anything about external references. think it should behave in the same way 05:47:23 mstange: I would be in agreement. I suppose we don't know how much content it would break 05:47:33 ... but from an authoring perspective, I much prefer this behavior 05:47:55 myles: if an author was trying to get a filter, and make a typo, their element would disappear 05:48:09 ... it's hard to believe that there's content out there that relies on it disappearing 05:48:19 AmeliaBR: when the url() is to another filter, and you get a network error 05:48:32 ... the other issue is just debugging SVG filters is a pain, if your content keeps disappearing 05:48:41 ... and the inconsistency with clipping/masking 05:48:51 mstange: these are arguments for it being a pass through, not for there being no broken content 05:49:03 myles: inside a filter you create a graph of nodes. do they also need this analysis performed on them? 05:49:14 mstange: if you have in="" that refers to something non-existent 05:49:21 AmeliaBR: each primitive has its own rules 05:50:12 krit: if the filter reference is invalid, the filter is not applied, but the stacking context is still created 05:50:57 heycam: you might have a filter property with multiple filters in it 05:51:01 AmeliaBR: this would make the entire filter chain a no-op 05:53:43 RESOLVED: If a referenced filter is missing or invalid, the side effects like stacking context are still preserved. 06:02:11 skk has joined #svg 06:06:04 addison has joined #svg 06:06:15 Resolution was at https://github.com/w3c/svgwg/issues/631#issuecomment-505164786 06:06:40 and at https://github.com/w3c/svgwg/issues/537#issuecomment-452092266 06:07:00 Topic: Text i18n issues 06:08:09 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 06:08:34 ScribeNick: emilio 06:08:44 r12a has joined #svg 06:08:58 q+ 06:09:34 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 06:09:40 plh has joined #svg 06:09:54 ... so for actually rendering it you need to actually do some tweaks 06:10:13 ... most text rendering you do it by a zwj on the other side of the shaper 06:10:32 myles: that's not quite how it works but what you describe is ok 06:11:01 heycam: what gecko does and I wrote in the spec is that each is a
and the are is shaped as if a
06:11:15 s/textspan/tspan 06:12:14 DavidClarke has joined #svg 06:12:20 ... then you lay them out, and all the positioning stuff is applied to individual grapheme clusters 06:12:27 present+ 06:12:44 ... we only apply the positioning it is the first dom character of a grapheme cluster 06:13:07 addison: so you're positioning the grapheme clusters individually right? 06:13:15 myles: after shaping 06:13:17 heycam: yes 06:13:28 AmeliaBR: so you can separate the clusters into the screen after shaping? 06:13:29 myles: yes 06:13:49 AmeliaBR: so for impls that don't do that and pretend that the different chunks are independent 06:13:58 q? 06:14:01 ack r12a 06:14:18 r12a: today I asked 3 iranian people and 2 arabic speakers what to do here 06:14:33 ... [whiteboard time] 06:15:04 ... I asked whether they would ever put a joint word aligning each of them vertically differently 06:15:10 ... and their answer was yes 06:16:12 ... but that they would show up in isolated form, not joint 06:16:27 ... that's the opposite of what behnam (?) said 06:16:44 ... because that's what you'd do in crosswords and games 06:17:37 ... one of the iranian people referred me to a persian professor in iran 06:17:48 myles: are you confident enough on this data or should we wait more 06:18:09 r12a: the people I spoke with seemed pretty confident 06:18:41 addison: does this also position multi-character segments? 06:18:59 AmeliaBR: yes, you can do that 06:19:19 nmccully: when they're joint in arabic you stretch when you go in the inline direction 06:19:44 ... but it seems you're confident that if you move them vertically you shape them separately? 06:19:55 ... anyhow there is a place for automatic place shaping 06:20:16 r12a: this is like letter-spacing if you only do it at the horizontal boundary so that may be appropriate 06:21:06 AmeliaBR: it puts the same spacing between every glyph pair but not for stuff in between 06:21:16 r12a: so I didn't ask for this use case... 06:21:25 heycam: my feeling is that this feature is poorly thought-out 06:21:41 ... and I was introduced into svg because you could do the same on postcript 06:21:53 ... where it is simple because that works on glyph 06:22:11 ... so when I thought about it and wrote the spec I tried to do the simple thing that did some amount of sense 06:22:29 ... so the question is is this feature as specified sufficient for the use cases? 06:22:37 r12a: it'd depend on the authors in the end 06:22:55 AmeliaBR: sounds like what we need is some sort of property to toggle "use isolated forms vs. connected forms" 06:23:22 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 06:23:32 heycam: so there's no existing css feature for that 06:23:39 ... even required ligature 06:23:58 AmeliaBR: you can't turn of required ligatures 06:24:10 addison: you could use zws or something 06:24:46 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 06:25:31 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 06:25:46 ... I don't think people are doing this right now 06:26:01 ... so we could advocate for new content to use different elements 06:26:23 addison: then they'd draw as isolated regardless of vertical spacing 06:26:39 AmeliaBR: a11y would read them as separate letters... 06:26:52 myles: that's what you want for the crossword stuff 06:27:27 r12a: given the current state I don't think we have a clear answer 06:28:21 ... for the case of vertical differences what I'm hearing we should use isolated forms 06:28:30 ... except behnam which says the opposite 06:28:57 myles: So if I have with 5 chars and x="1 2 3" 06:29:20 ... the proposal would be that for the character that have specific x position (the first three) 06:29:36 ... you'd have isolated forms 06:29:40 ... the rest would join 06:30:05 heycam: my concern implementation wise is that now I need to resolve the positions before shaping 06:30:27 ... and tell the shaper whether to use isolated form which would not be very easy 06:30:43 ... I wonder if there's context other than svg where you want to get the isolated forms 06:30:53 ... so you can add a css property or something 06:31:02 ... and the author could opt-into it 06:31:12 AmeliaBR: that'd be my preference 06:31:31 ... but I don't know if there's enough use cases to get implementors on board 06:31:48 r12a: I don't see the use case for such a property for horizontal text 06:31:58 ... for vertical text... it depends 06:33:21 ... 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) 06:33:44 AmeliaBR: so are we likely to get any resolution? If not? more feedback and from who? 06:33:46 r12a: yes 06:33:57 addison: this is something we'd want to continue to study 06:34:03 ... there's more people we need to ask 06:34:13 krit: so unspecified for svg2 until we have a solution for it? 06:34:32 AmeliaBR: I think we should try to make the edits 06:34:35 myles: for what? 06:34:57 r12a: this works fine for latin so maybe drop a note that it may misbehave in arabic? 06:35:09 AmeliaBR: it may also be a problem with cursive latin fonts 06:35:49 ... where it's not clear if the context remains there 06:35:57 heycam: you can control it with opentype features 06:36:11 AmeliaBR: for non-required ligatures you can turn it off 06:36:34 heycam: I think we should add a "beware" note to the spec for arabic 06:36:54 r12a: more than one 06:37:02 (more than one script) 06:37:10 myles: they should talk to us if they have use cases 06:37:23 ... another option is to say that this only works in some languages 06:37:42 heycam: so letter-spacing does cause isolated forms to be used? 06:38:01 AmeliaBR: I don't think it affects glyph selection 06:38:23 r12a: csswg also throws up their hands up abut how that should work 06:38:24 CSS advice on letter-spacing and cursive scripts: https://drafts.csswg.org/css-text-3/#cursive-tracking 06:38:42 ... you usually don't do same spacing for all glyphs 06:39:00 ... use-cases are justifications 06:39:11 [side conversations about how to justify text in svg] 06:39:28 github: https://github.com/w3c/svgwg/issues/631 06:39:41 topic: end 06:41:04 skk_ has joined #svg 06:59:49 prushforth has joined #svg 07:00:03 present+ prushforth 07:03:34 ScribeNick: mstange 07:03:40 Topic: Character counting in text attributes 07:03:46 github: https://github.com/w3c/svgwg/issues/537 07:04:18 AmeliaBR: To recap: text attributes for positioning, as we've been discussing, can have multiple values that can be applied to multiple characters. 07:04:27 nmccully has joined #svg 07:04:41 AmeliaBR: 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. 07:04:52 ... But if you have more complex multi-byte characters, things get more confusing. 07:05:11 s/characters,/characters or clusters,/ 07:05:25 AmeliaBR: "What is a character" becomes a debate. 07:06:11 ... 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? 07:06:32 ... We have a resolution from January which resolved that values in the array should be assigned based on unicode codepoints. 07:07:05 ... 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. 07:07:26 myles: Other part of the resolution: We count based on code points, but we don't segment based on code points. 07:09:16 myles: 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. 07:10:42 ... 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. 07:11:30 ... 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. 07:11:58 ... This ensures consistency between browsers. 07:12:36 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. 07:13:54 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 . 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. 07:14:52 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. 07:16:12 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. 07:16:42 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. 07:16:48 AmeliaBR: Yes, it's only the hand authoring case that's hard. 07:17:01 myles: Alternatively, we could specify that goes through normalization. 07:17:20 r12a: I do not like the idea of normalizing my content. Sometimes I want things to be composed and put the accents afterwards. 07:17:34 myles: Pragmatic / performance, might not be worth it. 07:18:22 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. 07:18:37 ... and those are not a graphing cluster. 07:19:19 heycam: You would ignore the positioning value for the zero-width joiner. 07:19:58 AmeliaBR: If you're intentionally putting the ZWJ , you still want contextual glyph selection. 07:20:23 s//to change to a medial glyph/ 07:20:26 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. 07:20:49 s/ goes/the text content/ 07:21:15 nmccully: If you need backward compatibility with engines that don't understand the red combining thing, 07:21:31 myles: A lot of people said "there is incompatibility and we have to deal with it." 07:21:43 s/engine will /engine will get fewer glyph clusters from the engine than there are characters/ 07:21:44 nmccully: Are you protecting from a malformed SVG from a bad player? 07:22:35 nmccully: 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. 07:23:17 mstange: seems like whenever you have parallel arrays, you should just have a single array of pairs 07:23:23 ... why is this API necessary? 07:24:21 AmeliaBR / myles: There is existing content that uses it. 07:25:29 r12a: In Indic scripts you have conjuncts, you split a syllable at a time. 07:26:29 ... (shows an example that has two graphing clusters that combine into one visible unit) 07:26:45 myles: This is why we didn't want to specify what segmentation to use. 07:28:51 s/graphing clusters/grapheme clusters/g 07:30:35 AmeliaBR: r12a, are you ok with keeping the existing resolution? 07:30:46 r12a: It's not pretty, but I understand why it's there, and I can't figure out anything better. 07:31:43 r12a: (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) 07:33:26 RESOLVED: Do not change the previous resolution. 07:38:03 RRSAgent, make minutes 07:38:03 I have made the request to generate https://www.w3.org/2019/09/18-svg-minutes.html AmeliaBR 07:41:29 CG meeting is on channel #svgcg 07:59:49 skk has joined #svg 09:03:32 Zakim has left #svg 09:07:43 github-bot, end topic 09:11:23 github-bot has joined #svg 09:29:46 Rossen has joined #svg 09:31:17 leaverou has joined #svg 09:31:47 plinss_ has joined #svg