-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wg/svg] SVG Working Group #432
Comments
If the AC review is negative and we still don't have resources, what would we do? |
As a very passive member of SVG WG and a user rather than developer, I have to say the SVG Recommendations meet most of my interoperability needs for 2D graphics (e.g. weather maps (x,y), cross-sections (x,z), Hovmuller diagrams (z,t), lots of simple but obscure symbols, blended imagery and line graphics, etc), |
@chris-little can you give an example of the problem(s) you are facing? (It's not clear to me why this is an issue.) |
@r12a I suspect it is probably more of a tooling issue, but a typical weather application may want to place many specialised symbols, combined with conventional text glyphs in complicated, non-linear layouts. International aviation also has widespread use of similar requirements in their SigWx charts Some other examples are: The issue is the inconsistent support for the mixture of symbols, text treated as symbols, fonts (and speed of rendering, causing developers to create symbols or explicit graphics of conventional letter glyphs, undermining search) and inconsistent default sizing and positioning. I suspect HTML and CSS rendering may have an impact too. My wish is too reduce the cost of development and display of the above types of charts/maps. I apologise if it seems a rather generic whinge, but I recognise that I may need to discuss with some current developers to see if they still echo my concerns. |
Discussed at a recent AB-led session: https://www.w3.org/2023/10/17-ac-minutes.html#t13 |
@plehegar Apologies, but I cannot access that page, probably because we have just chosen to let our W3C membership lapse. |
Out that conversation came one idea: create a Maintenance Working Group in charge of hosting Core Web specifications that don't have a dedicated group to maintain. We certainly have a few of them but SVG is the posterchild example of such specification. To avoid Patent Policy issues, the specifications would be added one by one in it as the need arises. cc @tantek |
An other alternative would be to have a Maintenance Community Group instead of a Working Group. This would limit the IP exposure of the participants, make it easier for someone from the Community to step up, but prevent the introduction of new features in the specifications. |
Capturing some ideas from a side conversation this week (these are not all my ideas) SVG maintenance group with reduced scope:
It's important to republish SVG2 CR as a CRS against the new Patent Policy before the current group closes, because its current latent patent commitments won't be realized unless the group does so |
I'd prefer all 3. @zcorpan WDYT? |
update:
Ideally, I should start circulating a draft in the middle of January. |
Conclusion: have an SVG Working Group with the proposed scope above. |
(note: for those who will want new features, we could always recharter in the future) |
cc @bkardell |
Igalia is, of course, interested in SVG maintenance, yes. We will participate in the WG and are capable of implementation work in any of them (that's not a commitment to do implementation work, it's just noting abilities :)) |
|
APA is fine with this charter. |
no comment or request from i18n (sorry for late, due that I've been on business trip..) |
No comments from PING |
No comments from the Security side. Maybe in the future, it should be interesting to note the scenario of Stored XSS using SVG. |
Perhaps we should remove |
section number of decision policy in section 8 is old. |
I updated section 8 to remove mention of Director and correct the section number. |
AC Review: https://lists.w3.org/Archives/Member/w3c-ac-members/2024AprJun/0011.html |
There is a desire from some Members to see SVG Accessibility API Mappings completed and published. This has the potential to significantly improve the accessibility of SVG and it would be good if there was an expected completion date. If there is a lack of resource to move it forward could we either work with one of the a11y WGs to take on the work or move it into there to complete it? |
Is there work you can refer to that enumerates which parts are missing? |
This isn't something that I can answer. Based on the feedback I received, it was more a desire to see this published as a Recommendation. |
Deadline since we extended the charter review is June 7. |
Lack of charter proposal, reviewers please take note.Charter Review
No charter. this is a WG closure.We're drafting a new charter.
charter
diff from previous charter
What kind of charter is this? Check the relevant box / remove irrelevant branches.
"There are insufficient member resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C." 4.6. Chartered Group Closure
There is no charter. The Group does not have the resources necessary to maintain the SVG specification properly.
SVG is used widely on the Web nowadays but there is a lack of interest of maintaining the specification, including re-aligning the specification with the HTML specification.
Anything else we should think about as we review?
Should we do an AC review for this or not? Process doesn't ask us to do so.
cc @caribouW3 @dirkschulze
The text was updated successfully, but these errors were encountered: