Getting Math Onto Web Pages #43
Comments
|
The current discussions are not yet really focussed. Potentially this work may have an influence on CSS, and is of a major importance for publishers. |
|
Interesting discussion threads on the CG: |
|
A strategy favoured by at least a few on the CG is to try and persuade CSS to add features for formatting mathematics, taking the magic out of particular element names. Some of mathematics layout is generally useful - e.g. aligning multiple displayed equations on the = sign (vaguely doable today with css grid, as are matrices) - or splitting of complex multi-line objects across lines (also useful possibly for the two-line Japanese) - or building up diacriticals and superscripts/subscripts, or (best of all perhaps) large brackets and braces made of multiple pieces. Down sides to this strategy: (1) it doesn't work very well. CSS is too busy to pay attention to other people's needs. (2) there's a lot of details in mathematics formatting that don't apply elsewhere. (3) just because you can descrine an equation doesn't mean you can evaluate it. There's need for both. (4) mathml is really aimed too high :) and needs to cover elementary through high school (US "K12") enough for text books, exams, general writing. it needs to go for the 70% rather than the 5% of post-undergraduate mathemtaics and engineering needs. Having said that, maybe we still don't have strong enough links with people like stmassoc.org - still a large and relatively wealthy publishing segment with a vested interest in having people be able to read their journal articles on the Web. Maybe they could be persuaded to fung Igalia's mathml effort? |
|
Thinking about publishing, math is very important. Now that publishing is in scope for the W3C, a solution on how to present math is essential. Of course, accessibility is essential. Not only do people need to publish and read the math with their Assistive Technology, but there must be strategies for writing math. LaTex and ASCIImath have been mentioned and a standardized approach must be identified. The publishing community needs techniques they can use now and a longer term approach needs to be identified. I view math as an essential part of the web and I suggest that the importance of math be elevated in the W3C team. |
|
I think it's critical to get this problem right given how mixed reactions have always been to MathML. Easy extraction of semantics of the mathematics must be the priority here. Once that is achievable, everything else is virtually guaranteed to work. Styling based on meaning and appropriate identification of similar, but subtly different, pieces of mathematics would allow for publishers to use such a solution in their workflows instead of relying on image-based presentation of mathematics. |
|
I agree with what @GeorgeKerscher and @sinabahram have said. Publishers are begging for a solution, especially in the K-12 space, on how to put math in their publications in an accessible way. I support what the MathOnWeb CG is doing which I feel is a longer term solution. What publishers need is something is something now. Publishers have the MathML, or could obtain it, but are commenting it out or leaving out the mathML completely and replacing it with an inaccessible image of the math mainly due to the poor rendering of mathML and it inconsisten support accross browsers. I think a semantically rich SVG of math equations that would help low vision users zoom into complex equations without pixelation and can be explored by assistive technologies is an ideal long-term solution. But what does the publishers do in the meantime and want to make their math accessible? |
|
It seems like there are several threads here. I won’t address all of them, but here are my thoughts on some of them: Math notation vs semantics – very few people seem to be willing to take the time to write semantic math; they are mainly interested in what it looks like for publishing. One can argue whether that is a good or bad thing, but 40(!) years of TeX and 30 years of direct edit math editors have shown that’s what people are most interested in. Readers don’t seem to have a problem understanding what the notation represents, but it is tricky for programs to do that, especially if they can’t get context from the textual environment and other expressions on the page. I suspect some sophisticated programs will get better and better at that, and so the ability to add semantic information to the presentation is something I think is important (those sophisticated programs could be run by publishers or perhaps used on the fly as a library). MathML provides for parallel markup of presentation and content, so it can handle a dual role. Perhaps a simpler mechanism of adding a (not currently supported) attribute such as “math-role” to presentation MathML would be sufficient. The devil is in the details. Syntax is a red herring – some people have pushed for one math syntax over another because it is easier to write by hand, or it is more compact, or it is better able to manipulated by a program or on the web. Most proposals are relatively easy to convert from one form to another, although compact formats usually don’t allow for richer layout such as elementary math, spacing/positional tweaks, font and color changes, etc., nor do they typically allow for semantic specification (or vice-versa). The real question is: who is the syntax meant to benefit. Only “insiders” actually modify raw web pages – virtually all HTML is created by some program that provides a better interface, whether it is a website design program, a full-blown document editor, a mark down language, or an email program. For this reason, I’m dubious about claims that a math markup web language needs to be human writable. For accessibility, the ability to highlight individual tokens and possibly subexpressions as such as a fraction as they are read is important. Being able to apply CSS to text has proven very popular and there is no reason to think the same shouldn’t apply for math. Hence, I tend to feel an HTML markup such as MathML is best in the web context. CSS and Math – The Math on the Web CG has been discussing CSS “tricks” to do math layout. Some are very clever and MathJax found some clever CSS hacks also. However, it would be so much better if CSS added a few more features so that hacks weren’t needed. There really isn’t a lot that needs to be added so that CSS can be used to layout math. I’d love to see an update to both MathML and CSS so that one could use CSS on a MathML tag such as “mfrac” so that line thickness, length, color, font size and positioning of the numerator and denominator, etc., can be specified via CSS. That would allow moving some details/features in MathML to CSS where they belong. It would make the MathML spec cleaner. Elementary math -- liamquin commented that MathML is aimed too high. I want to correct that impression: MathML 3.0 added support for elementary math. Unlike higher-level math notation, elementary math notation does vary a bit around the world and the design in MathML recognizes it. I implemented elementary math support in MathPlayer and so I can say with confidence that while supporting elementary is not trivial, it is not hard. The WIRIS editor also supports it. I can’t speak to why MathJax or other renderers haven’t added support. However, given that most of the user base long ago moved beyond elementary math, it probably isn’t surprising that most of the user base is pushing for support of other features. I’m sure textbook publishers are among those who would really like to see it supported in the MathJax, Firefox, and Safari renderers. Perhaps a little money would grease some wheels... My bottom line wish is to see some improvements to CSS for Math and for MathML to be updated to align with those changes and CSS in general. With a bit more CSS support and a clean up of MathML, native implementations of MathML would be a lot easier. In the meantime, accessibility support for MathML is pretty good. Even if it isn't used for display, embedding MathML in a page makes the math accessible well beyond what alt text on an image provides. For the sake of an inclusive web, please make use of it. |
|
1+ to @NSoiffer comments that accessibility support for MathML is pretty good and should be included by publishers. The DIAGRAM Center with help from @NSoiffer, @sinabahram, @GeorgeKerscher have been working on just this and will soon be testing a mathML with fallback EPUB test book we created on various reading systems with the results being recorded in https://msf.mathmlcloud.org and http://epubtest.org |
|
On Thu, 2018-04-12 at 18:48 +0000, NSoiffer wrote:
[...]
**Elementary math** -- [liamquin
](https://github.com/liamquin)commented that MathML is aimed too
high.
Not MathML itself - i was trying to say that giving the impression that
what mattered most, or all that mattered, was research-level
mathematics or even university-level mathematical notations, was making
a mistake because elementary and middle-school and high-school is a
massively larger market and is of course important. Sorry if i wasn't
clear.
My bottom line wish is to see some improvements to CSS for Math and
for MathML to be updated to align with those changes and CSS in
general. With a bit more CSS support and a clean up of MathML, native
implementations of MathML would be a lot easier.
100% agree.
Liam
…--
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
Improving Web Advertising: https://www.w3.org/community/web-adv/
Personal: awesome vintage art: http://www.fromoldbooks.org/
|
|
Resuming this old thread but potentially with a new focus, how can we advance MathML in a way that the potential of the spec to support accessibility is better realized? In some accessibility community brainstorming recently, we'd discussed the possibility that this topic might be a good candidate for a workshop, where people could come together to define the current state of the art, in terms of the spec itself, but also what is & isn't working in how MathML is implemented. Relevant aspects of this could not only include advancing presentational as well as semantic aspects of how math accessibility is handled -- and what is the best path to pursue for doing that -- but also the broader topic of Math and publishing. What are your thoughts on how we could move this area forward, potentially through a workshop and a new group? |
|
I think setting up a group today would not work, for a lack of consensus on what the community needs. A Workshop may be a good idea trying to have clearer idea on how to move forward. A good representation of the CSS and, maybe, the SVG community at the Workshop would be essential, though. |
|
I support the idea of a workshop. I think explicit invitations to SVG, CSS, and ARIA would be helpful. |
|
I also support the idea of a workshop. It's clear that there's a big gap here. I think it's important to include speech input in the accessibility mix as well. I have some experience with speech input, accessibility and math - and how this dovetails with speech output and cognitive load - and might be able to help in this area. |
|
I think this is a great idea and I agree that several issues such as presentation/semantics, speech input, surfacing to AT, etc. are all topics that must be explored further.
Is the following workshop on everyone's radar? Quite a number of us who have all been working on this problem as well as others in related spaces will all be there.
Web accessibility of mathematics
from May 21 to May 25, 2018.
San Jose, CA
Description:
This workshop, sponsored by AIM and the NSF, will be devoted to bringing together a diverse group of players in the field of accessibility to address the barriers that impede development and adoption of accessible web content for mathematics, particularly math education.
More details can be found at
http://aimath.org/workshops/upcoming/webmath/
take care,
Sina
President, Prime Access Consulting, Inc.
Twitter: @sinabahram
Company Website: <https://www.pac.bz> https://www.pac.bz
Personal Website: <https://www.sinabahram.com> https://www.sinabahram.com
Blog: <https://blog.SinaBahram.com> https://blog.SinaBahram.com
From: Kim Patch <notifications@github.com>
Sent: Wednesday, May 9, 2018 3:17 PM
To: w3c/strategy <strategy@noreply.github.com>
Cc: Sina Bahram <sina@sinabahram.com>; Mention <mention@noreply.github.com>
Subject: Re: [w3c/strategy] Getting Math Onto Web Pages (#43)
I also support the idea of a workshop. It's clear that there's a big gap here. I think it's important to include speech input in the accessibility mix as well. I have some experience with speech input, accessibility and math how this dovetails with speech output and cognitive load, and might be able to help in this area.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#43 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABui7bzVnDwifKUShLKWtKiVyYqdLN51ks5tw0CpgaJpZM4KywhS> .
|
plehegar
moved this from Investigation
to Evaluation
in Strategy Team's Incubation Pipeline (Funnel)
|
@plehegar why did you move this forward? |
|
I believe it was moved forward because Igalia continues to move their MathML implementation (based on an evolving start to a MathML core rec) into Chrome. There are a few things such as potential new CSS properties, custom layout, and more that potentially extend beyond MathML. There was going to be a MathML meeting in May where, among other things, we work on a charter to reestablish the MathML WG and develop a recommendation for MathML 4. Obviously, a F2F meeting won't happen in May, but I suspect we will be requesting the MathML WG be reformed sometime in the summer. If there are issues that we need to be thinking about, it would be good to know about them before we start writing a charter. |
|
@NSoiffer, if you plan for a new charter, I would think you should contact the Publishing community. At the W3C, the primary access point may be the Publishing Business Group but it is also worth contacting by mail the Publishing Steering Committee (public-publishing-sc@w3.org). There are also non-W3C groups to contact, like BISG (US), BIS (UK), SNE (France), Börzenverein (DE), etc. The publishing world has greatly suffered by the lack of MathML implementations in e-Readers as well on the Web, and having this issue solved is of a huge interest for them. Also, any further evolution should be coordinated with them: they are, potentially, major user of this and have probably lots of use cases of interest. |
|
To help the community evaluation, consider the guidelines linked from the top of the column. In particular, we'll be wondering about the critical mass of implementers to make the work succeed. Expressions of interest can help. |
|
@NSoiffer plan is to have a draft charter for a breakout session at TPAC 2020. |
|
We now have a proposed draft charter: |
MathML Working Group Draft Charter: merging for review w3c/strategy#43
|
Please review: https://w3c.github.io/charter-drafts/math-2020.html |
|
The Scope section includes the line
It's good to see this, but it's rather too vague to be able to comment on the value of that statement. I would have liked to see a line item under Other Deliverables that says something along the lines of "MathML Internationalization Requirements & Techniques". I think it would also be useful to include under the Success Criteria section a line that says that international requirements for MathML have been surveyed, documented, and specced (at least to some extent). Without this we run the risk of producing something that is only a partial solution for many of the users around the world. PS: This may be useful: https://www.w3.org/TR/2006/NOTE-arabic-math-20060131/ |
|
No further comment/request from i18n, other than @r12a (Richard)'s previous comment on adding a line for i18n to other deliverables as requirements and techniques, like math formula and/or chemistry presentation in wide variety of languages. |
|
Apologies for the delay in responding to @r12a's comment --it apparently got buried in other email and I missed his comment. The group has looked at the internationalization in some detail. MathML 3 supports RTL and we looked into math in vertical writing systems as a possible extension. See discussion in https://github.com/mathml-refresh/mathml/issues/18. Even if your eyes glaze over when looking at math, seeing some math examples (the images in the links) in vertical writing systems may be interesting to people on this thread. Documenting that we have looked into the issue (and we may well take another look since the last look was over a year ago) is a good idea and so I will add something to the deliverables and create a PR. It would helpful to bring the examples and commentary together into a document for the next time someone wants to look into it. |
|
Replying to Liam's comments:
IMHO, the line between math notation and math is fuzzy. Part of MathML Core is defining an interface for MathML elements so they can be manipulated by JS. So while we are not addressing a computation engine to solve the equation, we are allowing for JS to manipulate the equations in a manner that shows a solution. E.g., there might be a 'next step' button that when clicked highlights part of the equation and shows the next line with a highlight indicating where the highlighted part of the previous step moved to or maybe even a fancier animation that moves a subexpression from one place to another place. Hopefully this isn't a bad analogy: HTML is not just about arranging text on a screen; MathML is not just about drawing MathML symbols on a screen either.
That is a good point. Will changing the statement to "Significant changes to Content MathML..." be a good way to convey that we might tweak a few things but we are not making design changes or planning to modify large chunks of Content MathML? |
In particular: Not in Scope -- modified content mathml changes to being significant changes Added deliverable on non ltr writing systems (internationalization) Changed Publishing WG to EPUB and added Publishing CG
|
On Wed, 2020-11-18 at 22:28 -0800, NSoiffer wrote:
Replying to Liam's comments:
> Two minor suggestions...
>
> (1) change mission to,
> inclusion of mathematical notation on the Web
>
> The difference between mathematics and mathematical notation was a
> major source of confusion in the past.
IMHO, the line between math notation and math is fuzzy.
Sure. Although evaluating presentation MathML is not so easy as content
MathML, but this also misses the point a little. Math on the Web
includes topics such as animating graphs of functions, is much much
broader than traditional notation, so i was trying to head off some of
the long arguments that happened in one of the previous groups,e.g.
where a participant wanted to abandon MathML and use SVG instead, by
making the scope clearer.
But maybe not a big deal. I can live without the proposed change.
[...]
That is a good point. Will changing the statement to "*Significant*
changes to Content MathML..." be a good way to convey that we might
tweak a few things but we are not making design changes or planning
to modify large chunks of Content MathML?
Yes, i'm fine with that, thanks.
…--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
|
|
Point taken that there is more to math than playing with mathematical expressions. Unifying MathML Core with the rest of the web platform will also mean we are unifying more with SVG. Potentially, this this could result in better integration between math and graphics. It's not the WG's planned focus though for this round. |
wseltzer
moved this from Evaluation
to Chartering
in Strategy Team's Incubation Pipeline (Funnel)
[MathML] Addressed comments in w3c/strategy#43
|
APA WG has no comments on this charter, and welcomes the group. Over to @brewerj to complete accessibility horizontal review. |
|
@NSoiffer , can we have https://w3c.github.io/mathml/ NOT say that this is a "W34C Working Draft"? It was never published as such on /TR and this creates confusion. It should stick to say that this is an "Editor's draft" for the time being. I'm certainly looking forward for the draft to become a Working Draft sooner rather than later. |
|
@plehegar can you confirm that it's OK to use the w3c editors draft styling but say editors draft not working draft? Specifically the fork of that spec in the MathML-Refresh Community Group github area at https://mathml-refresh.github.io/mathml/ is converted to respec and styled as editor's draft. If that is OK I can just push the changes back. |
|
Security and privacy reviews completed. No suggestions for the charter. Thank you very much for (apparently) starting from the current version of the charter template. I'm a bit surprised to see only one chair; I prefer having at least two chairs for each group. I'm a bit surprised to see long lists of codepoints in the docs rather than in registries. Opened an issue for the nascent WG to sort out. w3c/mathml#238 Opened several other issues on the two docs. None are relevant to the charter. Since these are in other-than-W3C github repos, I can't directly tag them for tracking by our tools, so I'm including the list here. w3c/mathml#234 |
|
From i18n, on the update by w3c/charter-drafts#296, i18n appreciates the inclusion of the item "Analysis of mathematical notation usage in non LTR writing systems" in the "Other Deliverables" section. |
|
Thanks for your comments. My memory is that the old MathML WG looked at
math in India an we were told that (not surprisingly) what is used today
follows standard western notations. Even Arabic math moves to LTR math by
college. Speaking for myself, but I suspect the CG agrees, support for
historic forms of math notation (Indian or otherwise) should not be in
scope for this revision.
There are definitely differences among LTR countries, and there are many
more differences for countries that don't use LTR writing systems. MathML 3
did considerable work in this regard already. It introduced RTL
directionality into MathML. In addition, the MathML 3 WG outreach resulted
in a few other internationalizations:
1. Russian math often breaks large expressions across lines by putting the
operators at the break at *both* the end of the line and the start of the
next line, so MathML 3 introduced a way to do this (
linebreakstyple="duplicate"
<https://www.w3.org/TR/MathML3/chapter3.html#presm.lbattrs>). I suspect in
MathML Core (Level 2), this will get migrated to a CSS property.
2. Long division looks very different around the world. MathML 3 introduced 10
different styles.
<https://www.w3.org/TR/MathML3/chapter3.html#presm.mlongdiv.ex>
3 Even in the US, borrows and carries in 2D elementary math some parts of
the country place them above the digit and other parts of the country place
them to the NW of the digit. That was part of the support for elementary
math introduced in MathML 3.
Around the world, there are many other notational differences, some big,
some small. For example, France and Italy sometimes use "tg" instead of
"tan" for the tangent. A slightly bigger difference is the open/close
interval notation which in much of the world is written "(0,1]" (the
numbers between 0 and 1, not including 0). InFrance, it would be written as
"]0, 1]". Both of these alternate notations have always been able to be
represented in MathML. The content side of MathML says nothing about how a
concept is displayed and the presentational side of MathML has had support
for most LTR notations for many years (now decades...). Because MathML has
at least the same layout capabilities of WYSIWYG math editors and about the
same as TeX's math layout capabilities, I feel pretty confident that at
least for LTR, MathML is able to express all the math notations commonly
now used except for some graphical ones.
I think there has been some coalescing of math layout notations among all
writing systems in the last few decades because math typesetting software
doesn't seem to have much support beyond horizontal writing systems. The
MathML Refresh CG looked at vertical writing a year ago or so. For the most
part, math was either written LTR, RTL, or LTR rotated 90 degrees. I don't
think anyone in the group felt that we were done with our research and that
is why we listed doing more work in the charter. We definitely have more
work to do for vertical writing modes.
One issue though that can't be overlooked: getting browser support for math
has been a challenge. Indeed, the MathML Core work is directly motivated by
the challenge of browser support. Igalia has led the effort of getting
MathML Core into Chrome and standardizing it across the other major
browsers. The need to get browser support leads to a lot of pushback for
adding new features unless the underlying technology stack cleanly supports
the feature. So even if we uncover an i18n need, we are at the mercy of
what is currently supported and also how difficult it is to adopt it to the
needs of math. This extends to adding new Unicode symbols -- the old WG
helped greatly expand the number of Unicode glyphs for math, but adding new
glyphs takes a few years to get through the Unicode Technical Committee and
then into fonts. For browsers, even the ability to stretch a parenthesis
appropriately for math is tricky to fit into layout engines. If a writing
system requires diagonally stretchy characters for math, that need will be
noted but probably can't be added to the spec because that's not (AFAIK)
supported by current browser layout engines (it's a 'width is a function of
height' issue).
I hope the "we looked at this, we support most notations around the world,
and we can't add more things" doesn't sound defensive or arrogant. I just
mean to point out that the old WG and the current CG hasn't ignored i18n,
we have embraced it. But we also have our hands tied as to what we can add
in the near (proposed WG lifetime) future.
…On Tue, Jan 12, 2021 at 8:46 PM himorin ***@***.***> wrote:
From i18n, on the update by w3c/charter-drafts#296
<w3c/charter-drafts#296>,
i18n appreciates the inclusion of the item "Analysis of mathematical
notation usage in non LTR writing systems" in the "Other Deliverables"
section.
However, we would like to see wording that points to analysis not only of
RTL or vertical orthographies, but also symbols and conventions (if any)
used in other orthographies around the world. For example, we heard mention
today from a mathematician that there were (still are?) differences between
the Russian and German conventions. Another possible example might be for
Indian languages which draw on their Vedic traditions. We don't know
whether these are valid examples of conventions that need to be
acknowledged (if not expanded on) in the spec, because we don't have
expertise in that area, but we'd like to at least see some research to
ascertain whether W3C is neglecting some part of the world, so we would
like you to look into it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALZM3HNIL4MTZYD3YRGTJTSZUQRZANCNFSM4CWLBBJA>
.
|
|
@NSoiffer that summary is terrific. I think that if you included your previous comment (with very little change needed) into your document, perhaps under a section heading such as "MathML Internationalization", that would probably satisfy our request. I think it's ok for historical approaches to be out of scope for the time being. |
|
@samuelweiler thanks for the review,
Perhaps the document could make it clearer but the lists are explicit there to define the proposed text transform but the codepoints in each list come straight from Unicode so they can't be changed here, so I don't think setting up a new registry would be appropriate. The lists are specified in the math alphabet Unicode block and used for example in the existing W3C entity names REC https://www.w3.org/TR/xml-entity-names/fraktur.html as used in MathML3 and HTML5 is the same list as the list in mathml-core at https://mathml-refresh.github.io/mathml-core/#fraktur-mappings which necessarily matches the Unicode Math alphabet block at http://www.unicode.org/charts/PDF/U1D400.pdf
I will respond in the issues but summary responses to a couple here [add a link to the github repo] [remove media type registrations] |
|
Oops. Two charter things after all:
|
|
@samuelweiler do you mean the links in the section heads such as
I suggest we simply drop the link here there are correct links to the editors drafts in the body of the section.
That is text from the template we were asked to use for a charter. The WG doesn't of course exist yet pending charter renewal, so we have not discussed this at all. If that is in the template and a suggestion for something that WG should do I don't see any harm in us keeping the text and filling the page with sensible data, even though currently it is just an (automatically generated?) stub. If the W3C doesn't want this we can remove it before the charter is finalised, not really our call...? |
In addition to those being broken, there's a heading near the top of the charter with (broken) github links for the charter's github repo and issues on the charter. (And I don't remember which sets of those I noticed before. Sorry for being unclear.)
I like also having links to the doc repos; why not just fix them?
It's not clear to me what WGs should do, but knowing that many groups do NOT use this, I'm encouraging the shepherd(s) for this charter to consider the question. @plehegar may have some input, and I point him at w3c/charter-drafts#297... |
the links to the current drafts are in the paragraph below the heading marked Draft state I can add those same links to the heading but it doesn't seem to add a lot so I thought better just to remove it, but I don't mind.
that's from the template and they are just have a relative URL of |
|
Following on Michael Cooper's accessibility horizontal review above, we welcome the specific attention to accessibility throughout this draft charter. In particular:
This will help address an urgent gap in accessible online STEM curriculum and in professional use of accessible math on the web. Separately there is a need for accessible semantic MathML. My understanding is that current circumstances do not support that additional area of focus . If any at point in the future this becomes feasible, this would be interesting to several groups in WAI. In the meantime however, we are happy to support this proposed charter. I'm therefore marking this as 'accessibility review completed.' |
|
Just a reminder that the i18n folks were hoping to widen the scope of the line in the charter that says:
to include worldwide writing systems in general, not just the RTL or vertical ones. |
Attempt to respond to w3c/strategy#43 (comment)
wseltzer
moved this from Chartering
to Strategy Work Concluded
in Strategy Team's Incubation Pipeline (Funnel)
There is a Community Group
The text was updated successfully, but these errors were encountered: