WG-03-10.md

Agenda for the March 10th video call of WebAssembly's Working Group

• Where: zoom.us
• When: March 10, 2021 at 4pm-5pm UTC ( March 10th, 8am-9am PST )
• Location: on calendar invite to registered attendees
• Contact:
  • Name: Derek Schuff, Luke Wagner

Registration

If you are a Working Group member no registration is required.

If you are a Community Group member who would like to observe, please register here: https://goo.gl/forms/HD2kLCM0iSKk7AVl1

Logistics

The meeting will be on a zoom.us video conference. See the calendar invite for link.

If no agenda items are added (after "Review of action items from prior meeting"), the meeting will be automatically canceled.

Agenda items

1. Opening, welcome and roll call
   1. Opening of the meeting
   2. Introduction of attendees
2. Find volunteers for note taking (chair to volunteer).
3. Adoption of the agenda
4. Proposals and discussions
   1. Review of action items from prior meeting.
   2. Discuss potentially switching to an Evergreen Recommendation / Living Standard.
5. Closure

Attendees

• Luke Wagner
• Derek Schuff
• Eric Prud'Hommeaux
• Andreas Rossberg
• [Probably others, unfortunately I missed this in the notes]

Meeting Notes

Looking at https://www.w3.org/wiki/Evergreen_Standards

We think this is a good match for our process, since we make all the decisions in the CG. The act of merging into the spec at stage 5 happens after we get consensus, so we don’t need the extra call-for-consensus step of publishing a CR.

Discussion about how snapshots can be used to periodically get IP cleared and that can be done more-or-less independently of merging PRs that have reached stage 5. Likely the snapshots would not have significance to implementers or tool vendors (who will mostly pay attention to the practical facts of which engines support which features).

The ES process allows the WG to produce RECs from the ES at a future point in time, if needed.

What would the process be to switch?

We’d need to get all the AC reps to approve it. We’ll need a charter extension anyway but going evergreen would still be a bigger change. Just re-upping our charter would be simpler.

To update the charter: Luke will look at the current list of proposals, and organize it a bit Eric will write up a new charter based on the existing one plus that list

It would probably be worth putting it in front of the CG, asking if anyone has concerns about the evergreen process, maybe even present the proposed charter.

But most of the work for the charter will be the same either way.

Also we can still put out REC-type documents even with the evergreen charter.

EP: then we have to figure out the publication process. Thinking about how to handle the HTML format: accessibility, mathML etc Didn’t really get a response from [?]. We could just try to put something together and see what they’d suggest to fix it. So put some boilerplate at the top, and then generate the multipage like we have it.

AR: we punted on everything sphinx for a long time, we are stuck on an old version because updating breaks everything.

EP: do any of the sphinx maintainers work for any of the companies in the WG? Maybe we could get their help that way

AR: don’t know.

LW: what was the issue? We have all this prose text by the formalism, was it just linking them?

EP for accessibility, i made the claim that the math stuff was duplicated, but the problem was the inline math?

For sphinx the question was whether we could get some help from the maintainers. Do any of them work for WG member companies?

AR: I don’t see any affiliations listed on the page. Certainly when you work with it you get the impression that it’s not very mature.

LW: wasn’t it automated by Brad?

AR: the bikeshed stuff is automated. But it all depends on special hacks that are hard to understand and probably fragile. It is still running automatically.

EP: we could just grab all that HTML and put it in some bigger document?

LW: the current build puts out 2 docs, multipae is the one we like to read and the other is more in the W3C format

EP: last time we did this i had to deal with a bunch of validation problems. So it made everything hard. So if i’m going to go through that i’d rather deal with the multipage doc.

AR: the bikeshed pipeline only generates the single page. The multipage is just the regular sphinx output

The pipeline is a bunch of hacks to make Katex work (we use that instead of mathjax)

LW: could we use mathML now?

AR: they are starting up a new standards process but it seems early. Converging on existing state across browsers but it seems it will be a while before it’s ready

EP: the mathjax is more complete and sphinx just renders that on its own? And katex is for accessibility?

AR: katex is static and mathjax is all rendered in JS and is slow, also made it impossible to process in bikeshed? (not sure)

EP: I guess the question is that if we’re going to say that the math is nice-to-have that is duplicated, then maybe that’s OK?

AR: also bikeshed couldn’t handle multiple pages at the time.

EP: so the question is, if BS can handle multipages, and sphinx is outputting valid HTML, then the question is could we use that and postprocess it

AR: that would certainly be easier. One of the other things was maybe adding the right front matter with BS

EP: taking that and modifying the DOM could be easier. BS also keeps track of some of our configurations, which we’d have to do some other way. But we aren’t using a lot of BS’s big features.

AR: also the JS and web spec are all BS. and the core spec doesn’t have any dependencies on web stuff.

EP: would one of you want to sit with me sometime and show me the process with sphinx and see if we can produce a doc with a small amount of effort?

AR: I wonder if we can find someone who can contribute too. We did have an external person who contributed some stuff, updated to the latest sphinx that worked

Oh, it was Zhi.

EP: what broke when we tried to upgrade?

AR: some of our math plugins. We were using it to define macros for embedded latex. I found a little code snippet somewhere on the web and it used some sphinx API that apparently went away. I assume there’s a replacement but I didn’t understand it well enough

DS: are multipage, mathjax vs katex, and formatting/front matter all separate issues?

EP: would have to add the font matter, might have to change the markup/ToC sidebar, want to see if we can get away with mathjax and see if someone complains.

AR: the katex is the thing that we know the least.

DS: maybe we should figure out exactly what we need to change, starting with the multipage output that we have now, then we can see if it’s easy enough to just hack/postprocess or if we think we want to update sphinx itself, or what

AR: the sidebar looks static. I don’t see anything dynamic looking in the first page

LW: we should come back to this, since we’ll need to have this automated for the evergreen spec.

EP: did I forward you a thing about W3C’s echidna tool? Automated publishing of CR-type docs from git.

LW: before the next WG, can you take a look at the output to see what is needed

EP: maybe i’ll take one and try to make it TR compliant and see what it takes.

AR: there are 2 parts in configuring sphinx, you can create style sheets for the sidebar and such it might be easier to hack ours incrementally than write a new one from scratch or maybe even compared to trying to postprocess it