Closed plehegar closed 4 months ago
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), The one area where I would like improvement is not purely SVG: better integration and handling of Unicode glyphs, fonts and symbols, whether using a Unicode PUA (Private Use Area) or not. That is probably not helpful, but not sure where the issue could be tackled.
The one area where I would like improvement is not purely SVG: better integration and handling of Unicode glyphs, fonts and symbols, whether using a Unicode PUA (Private Use Area) or not.
@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: https://www.netweather.tv/charts-and-data/fax or https://meteologix.com/uk/observations/weather-observation.html or https://www.metlink.org/wp-content/uploads/2020/12/Fig_5.gif
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
- participation commitments from at least 2 browser implementer teams
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 the Director
from Sec 8. Decision Policy?
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 Deadline is May 23/24
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?
There is a desire from some Members to see SVG Accessibility API Mappings completed and published.
Is there work you can refer to that enumerates which parts are missing?
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