– DRAFT –
(MEETING TITLE)

fserb: Thanks for coming to session
… This started as discussion at CSSWG F2F
… decided to move to TPAC, more interest in talking
… so I will give a summary of what I presented, then want to hear from ppl
… I have a doc I presented

<fserb> https://docs.google.com/document/d/1mMdmuXMUamXtNtiPgzj6Jg5XDmFshkiXNYqg-W2jzLI/edit

https://lists.w3.org/Archives/Public/www-archive/2023Jul/att-0001/Modern_Web_Vector_Graphics.pdf

fserb: What we tried to explore was improving vector graphics use cases on the Web
… discuss expressiveness that ppl struggle with
… trying to look at the landscape and see the direction

[shows example under Responsive Vector Graphics]

fserb: We have vector support in SVG, we have hacked shapes in CSS e.g. triangles and circles
… but no way to support responsive graphics, things that stretch properly

[example of a thumbs up hand -- stretched everything is distorted, responsive the arm is lengthened but hand still intact]

fserb: Animations. Lots of people these days in mobile space with animated icons
… local animations
… there are a few solutions like Loti and Rive (sp?)
… they depend on runtimes, and have lots of compat issues

fserb: One big issue is interactive UI elements
… expectation these days that started with mobile but definitely now on desktop
… of having motion as part of the UX
… ppl expect to express certain things, interactions, with motions
… want to do these on the Web
… A lot of hacking where people try to stretch what's possible

fserb: Another use case is parametric shapes, the squircle problem
… being able to have some basic shapes on the page that you want to interact with
… can do SVG for a specific use case, but complicated to do this in a way that's reproduceable, doens't involve doing math each time
… access to shapes, doing naturally, is something ppl trying to do

fserb: I described a bit after that some of the issues people have
… talked about runtime, trying to integrate SVG and CSS
… we know about CSS support of SVG as bg images and border image, but what are the limitations
… and also ppl trying to stretch SVG/animations for UI
… e.g. trying to use simple animations for e.g line dashing
… to synthesize feeling of line drawing
… all kinds of interesting hacks that kinda work but kinda break things
… things end up flimsy, easy to break

fserb: So this is a summary of the problems

fserb: Question I brought up to conversation was, what can we do that's better?
… which directions could we look into?
… one thing we talked about, could vector graphics be better integrated with CSS?
… can we make parameters come from CSS to SVG?
… could usage of vector graphics be more friendly to building web pages
… One question was, is paintworklet be a solution? should we not look into vector formats?
… what are the limitations of SVG that prevents advanced use cases?
… e.g. path data of SVG has string representation, but doesn't allow for any type of responsiveness we're talking about
… any type of parameterization from CSS or animation
… There has been in the past some standards for animated SVG, but limited to CSS things like colors, not paths

fserb: People trying different vector formats on different platforms. Complicated space.
… Text is a big challenve
… usually they give up on text
… As things are simpler, become more cross-patform

fserb: As discussed last time, it feels better to incrementally improve things, but what can we improve?
… Let's talk about it
… what's feasible? what can we do?

noamr_: I think going forward incrementally has been working to an extent
… a lot of things from vector graphics have been adopted into CSS, e.g. border-radius and clip-path
… we need a very strong motivation to jump from this into something more complicated like embedding <length-percentage> into SVG
… you need a strong motivation
… Two things I was trying to push for while working for Wikipedia
… one is a <shape> element which is responsive with <length-percentage>
… think about putting SVG into CSS rather than the other way around
… consistent conceptually with what arc, curve is. use same terminology and mental model, but speaking in CSS terms
… but wasn't able to champion other than drafting a theoretical spec

noamr_: other thing is, it's hard to do e.g. clip-path is too limited. Can't do borders that follow the clip-path
… and it clips out all the effects like blur
… just trying to do a balloon in Wikipedia, couldn't do it
… just trying to take this conversation to be more simple
… there are proposals and things that speak about it in the practical sense

<fantasai> fantasai: There's a couple things obvious to do

<noamr_> The shape() function: https://drafts.csswg.org/css-shapes-2/#shape-function

<fantasai> ... one of them is being able to define the visual shape of a box as a type of path

... I think we should be able to define the visual shape of a box as a type of path
… we should give that dedicated syntax because it's pretty common one. That'd take care of clipping and also have the border take care of the path?
… I think one tricky thing is having different borders on each side.
… on the flip side we do need responsive svg images or some kind of vector format that is responsive
… but we should not try to put all of svg into css
… we should bring some of the responsiveness concepts from css to svg
… introducing a divergence between pixel lengths and user coordinats would be a way to differentiate

<noamr_> clip-path with borders/filters: w3c/csswg-drafts#5881

<fantasai> ydaniv: Going beyond length values, going further wrt responsiveness

<fantasai> ... there's a lot of stuff that's already in HTML that didn't make its way back to SVG

<fantasai> ... tons of stuff, like text rendering and i18n

<fantasai> ... on the other hand, you can't ignore that SVG a huge ecosystem

<fantasai> ... from stuff that you create offline and you can use everywhere

<fantasai> ... so there's a huge amount of stuff that needs to go back into SVG

<fantasai> ... and no way to drop SVG on the way

<fantasai> ... but in order to use responsive images, i18n, a11y [missed]

<fantasai> myles: Naive question, has SVGWG met in the past year?

<fantasai> ChrisL: SVGWG is dead and has been for 4-5 years

<fantasai> ... nothing has happened, even when it had a charter

<fantasai> ... it's just been a tiny group, but without browser vendors

<fantasai> ... even if they make decisions, they are not able to make progress

<fantasai> nicole: Have we been getting bugs on SVG?

<fantasai> ... if there's a community unsatisfied with current state of affairs, usually they're bugging us

<fantasai> myles: Seems the community in this room is unsatisfied

<fantasai> nicole: I meant developers

<fantasai> ydaniv (?): Now that something's happening in WebKit, because working on new engine...

<fantasai> ... merging with HTLM engine, can solve tons of problems. foreignObject, text issues, etc.

<fantasai> nicole: will you propose for Interop?

<fantasai> ydaniv: I tried proposing SVG and Math for investigation, but was dropped

<fantasai> ... suggestion that came up today was maybe more specific issues

<fantasai> ... my previous suggestion was maybe get ??

<fantasai> ... there was no priority

<fantasai> ... maybe we can make it a focus for Interop

<fantasai> ... or maybe the new engine will bring focus

<fantasai> mitch11: Mitchell Evan, I work in a11y area

<fantasai> ... I see a couple things exciting here and helpful for a11y

<fantasai> ... particularly responsive vector graphics

<fantasai> ... Responsiveness has been great for making browser zoom work nicely

<fantasai> ... remaining problems with graphics

<fantasai> ... enlarging a page, graphics become smaller

<fantasai> ... a lot to improve here

<fantasai> ... collaboration through APA WG

<fantasai> ... let's solve problems together

<fantasai> ... unsure how to phrase request, how do we continue

<fantasai> ... I could try to offer use cases that would be relevant to this

<fantasai> ... who would I talk to? apparently not SVGWG

<fantasai> [exchange info with fserb]

<fantasai> fserb: Wrt incremental improvement of SVG vs new structure

<fantasai> ... completely agree with this

<fantasai> ... don't want to bootstrap a new ecosystem

<fantasai> ... don't want to go there

<fantasai> ... one issue that was brough up about that

<fantasai> ... if trying to solve things like responsiveness, have to do work in parameterizing paths

<fantasai> ... could it be that the solution diverges so much from what SVG

<fantasai> ... that you can't use existing tools?

<fantasai> ... if you change how path works, aren't you breaking the ecosystem?

<fantasai> ... this is the type of points that ppl brought up wrt starting something new

<fantasai> ... would be good to hear on that

<fantasai> fserb: second thing is wrt SVGWG

<fantasai> ... I wonder if, instead of merging with CSSWG (though not opposed), if we could meet again as SVGWG with a particular direction like this

<fantasai> ... e.g. can we solve parameterized paths

<fantasai> ... maybe that will be a way to engergize browser engagement

<fantasai> dbaron: From fserb's list of use cases, there's a list of "features", things that could be built that could address those use cases that are reasonably clear

<fantasai> ... one big one does seem to be parameterization of paths

<dbaron> https://www.w3.org/TR/SVGParamPrimer/ , https://tabatkins.github.io/specs/svg-params/

<fantasai> ... one of the other pieces was passing parameters into SVG

<fantasai> ... these are two of the proposals that came up before

<fantasai> ... might not be a complete list

<fantasai> ... having a plan for some work that starts from a set of proposals

<fantasai> ... not necessarily complete

<Domenic> +1 to fserb's suggestion of concrete proposals. I suspect targeted proposals that eventually become spec patches with web platform tests would get browser engagement. At some point the spec may collapse under the mountain of tech debt, but until then... :)

<myles> +1 to dbaron

<fantasai> ... but some level of sketched out on the table could be a way to get people interested

<fantasai> [nodding heads]

<fantasai> myles: Totally agree, and there's an example of parameterization in OpenType fonts

<fantasai> ... the tech exists (though you may not want to copy it)

<fantasai> lea: Wanted to reply to nicole's point about bug reports about SVG

<myles> s/in SVG fonts/in OpenType fonts/

<fantasai> ... although SVG is used widely in Web, but very low level

<fantasai> ... so few devs write SVG directly, might be why few bug reports

<fantasai> ... also tool authors are unlikely to file bugs that are about shortcomings rather than browser bugs

<fantasai> noamr_: There's literally a proposal for parameterized paths in CSS Shapes 2

<fantasai> ... confused why we need ot add

<fantasai> ... how about discussing existing proposals

<fantasai> noamr_: What's missing isn't playing with WGs. What we need is implementer interest.

<fantasai> ... we need to convince champions in browser teams to prioritize it

<fantasai> ... and champion within WG

<fantasai> ... until that happens, it's all talk

<fantasai> ... once it happens, it can be in any WG

<fantasai> ... if there's enough talking about it in order to do it

<fantasai> ... then doesn't matter if we revive in SVGWG or do it in WHATWG

<fantasai> noamr_: Wrt tools, we're talkin about scalaable vector graphics turn into responsive vector graphics

<fantasai> ... you can't use the same tools

<fantasai> ... once we have more maturity in CSS

<fantasai> ... we can have tools that convert scalable to responsive

<fantasai> ... e.g. conveying leng-percentage

<fantasai> ... can't, as an after-effect, say SVG is RVG

<fantasai> ... it's not going to be a good idea to do that, imho

<fantasai> ... SVG is scalable, not responsive

<fantasai> ... and then converstion to something responsive that's web thing

fantasai: I agree #1 thing is getting people interested
… seems clear there's some interest from the people in this group
… there are some issues. First that there's thing we want to add. Second is that SVG implementations are not at the level of fidelity we want
… if you want to build on SVG you kinda want to have a good foundation
… not sure what's the strategy for that
… though with a new format you have even more problems

<Zakim> fantasai, you wanted to comment on future of SVGWG

<fantasai> nicole: There are weird things where you can make SVG reponsive, e.g. through inline use

<fantasai> ... SVG behaves really differently depending on how you include it

<fantasai> ... I think as a former author, that was very confusing, that how I include the format changes what I can do with it

<fantasai> ... I think when it comes to cleaning something that's a mess

<fantasai> ... doing something exciting is a great way to get motivation

<fantasai> ... so I think if we have a good picture of what we want to do

<fantasai> ... and allow that to inspire the clean-up work

<Domenic> +1

<fantasai> ... find what needs to be updated based on the features we're excited about shipping

<fantasai> ... I think that would help fserb and I to drum up interest in this project

<lea> +1

<fantasai> myles: Question. You mentioned that there are some libraries that ppl use these effects on the Web today

<fantasai> ... from authors point of view, what features do you expect to be improved by replacing these libraries with in-browser support?

<fantasai> ... what's the user-perceived benefit are you aiming for?

<fantasai> fserb: There are few dimensions that ppl bring up

<fantasai> ... Definitely, performance angle

<fantasai> ... better way to declare some of those things

<fantasai> ... the runtimes have ?? issues

<fantasai> ... which is performance is pretty bad

<noamr_> We often these libraries in performance traces

<fantasai> ... if you want to do all path tracing from scratch, because no other way; but even on Rive side it's an issue

<fantasai> ... if you look at something like Greensock, which is different

<fantasai> ... (Rive and Lottie are vector animation runtimes)

<fantasai> ... Other type of library solution is like Greensock

<fantasai> ... closer to what we talk about wrt responsive side

<fantasai> ... builds JS tools to allow some control of paths

<fantasai> ... Maybe mistaken, I think Greensock does good job with path animations

<fantasai> ... but not anything about responsiveness?

<fantasai> ... I think integration with rest of HTML and CSS is pretty poor across the board

<fantasai> ... Can authors easily pick shapes or have integration with how they're building CSS designs and teams, able to integrate those things

<fantasai> ... no great solution at this point

<fantasai> ... totally doable if you want to do by yourself with observers in JS trying to rebuild things

<fantasai> ... but not great

<fantasai> ... integration part is not there

<fantasai> ... animation has perf issue

<fantasai> ... responsiveness / UI element side, even the tools don't really bridge the gap properly for good quality

<fantasai> myles: thanks

<fantasai> ydaniv: Wix is doing a lot with animation and SVG

<fantasai> ... so before there was SMIL animations

<fantasai> ... dropped in favor of using CSS animations

<fantasai> ... still very quirky

<fantasai> ... we want to be able to work with CSS Animations, Web Animations, to do whatever you can with CSS/HTML

<fantasai> ... inSVG

<fantasai> ... Lots of attributes you can't control through CSS

<fantasai> ... so you can't animate

<fantasai> ... e.g. d attribute on path

<fantasai> ... maybe supported in Chrome

<fantasai> ... gsock allows you to animate any number of points into any number of other points

<fantasai> ... which is why using gsock for morph

<fantasai> ... so the there are technical issues

<fantasai> ... [missed]

<fantasai> ... have SG and want to animate stuff, lots of quirkiness and bugs

<fantasai> myles: Sounds like you're saying, if we could take the current system we have of animations in SVG

<fantasai> ... and make it work better and work over browsers, it'll be fine

<fantasai> ... you're not looking for a new system

<fantasai> ydaniv: Yes. If it could be composited, accelerated, etc. work with HTML and CSS

<fantasai> ... would be great

<fantasai> myles: Thanks, that was helpful.

<fantasai> fserb: what I got from the room

<fantasai> ... seems we agree there's a space of use cases

<fantasai> ... particular on responsive side

<fantasai> ... that ppl care about, worth looking into

<fantasai> ... I do like some of the proposals that address steps on this

<fantasai> ... e.g. passing parameters

<fantasai> ... I haven't read the whole Shapes 2 proposal

<fantasai> ... but also outside of SVG, pure CSS solution

<fantasai> ... maybe worth mapping some of those piecewise solutions

<fantasai> ... that address use cases

<fantasai> ... and try to map if there are particular use cases

<fantasai> ... one seems to be parameterization of text

<fantasai> ... SVG is not RVG

<fantasai> ... Lea made comment only on text that maybe that's the way to move forward, not sure if ironic or not

<fantasai> ... [missed]

<fantasai> ...Main part goes to what nicole said, which is having those use cases that motivate the work may be the way to move forward

<fantasai> ... even for core SVG itself

<fantasai> ... Saying we care about this space

<fantasai> ... need to move forward on it

<fantasai> ... whatever way we can find to have motivation

<fantasai> ... seems to be a direction that sounds reasonable

<fantasai> ... Also, someone mentioned that parameterizatoin is complicated and hard to achieve

<fantasai> ... maybe trying to bridge those gaps... is it possible to address those cases?

<fantasai> ... but sense is that there's a lot that can be gained by solving these incrementally

<fantasai> fserb: others mentioned use cases and a11y

<fantasai> ... maybe next steps is proposals or drafts that could be reasonably put under umbrella of addressing responsive vectors and animations

<fantasai> fantasai: Might want to clearly scope out the problem, use cases, collect existing proposals

<fantasai> ... and then try to sell the managers on solving this package of problems

<fantasai> fserb: If anyone interested, reach out to me and nicole

<fantasai> mitch11: I would suggest that graphing and charting is a big use case

<fantasai> ... often resorting to canvas today

<fantasai> ... and has solved a lot of domain-specific responsiveness

<fantasai> fserb: thanks, i'll try to move these ideas forward

<fantasai> Session closed.

<fserb> thanks fantasia for the notes :)

<fserb> fatansai argh

<fantasai> :)

<fserb> why does this always happen to me? I'm sorry