Separate static and dynamic parts

[saschanaz]

For example:

webidl-clipboard.js has a part that can be static (adding clipboard copy buttons) and a dynamic UI part (adding event listeners to those added buttons). Currently respec2html removes any dynamic UI features and this causes weird situation that users cannot use the feature in respec2html-generated page.

We may separate those two parts so that we can ultimately:

1. serve static parts as respec2html already does
2. serve dynamic UI parts as separate modules
3. avoid removeOnSave

What do you think?

[marcoscaceres]

Currently respec2html removes any dynamic UI features and this causes weird situation that users cannot use the feature in respec2html-generated page.

The reason that these things get removed is that the W3C doesn't allow arbitrary JS in /TR/ documents: it only allows fixup.js to be included.

I'm happy for us to have a discussion with the W3C about including more JS things on TR. However, I feel that remains the precursor before we can have a discussion about how to do it.

[marcoscaceres]

@plehegar, tl;dr: ReSpec in "live mode" (e.g., Editor's drafts) adds useful things like buttons that allow readers to copy/paste WebIDL with one click. The W3C currently doesn't allow JS on TR (apart from fixup.js), so we are wondering... what would we need to be allowed to ship some additional JS on TR?

[saschanaz]

Bikeshed adds inline scripts, maybe we can do the same?

[marcoscaceres]

Bikeshed adds inline scripts, maybe we can do the same?

On documents published on /TR/? If yes, then we can make a case to the W3C.

[saschanaz]

On documents published on /TR/?

Yes, check this out for example: https://www.w3.org/TR/webaudio/

[saschanaz]

https://www.w3.org/TR/clreq/ has an arbitrary JS file. Not sure it's explicitly allowed or not.

[marcoscaceres]

Ok, we can definitely do the either inline or we can host our own scripts. I'd personally like to have the scripts hosted (same a ReSpec currently is)... we have very few scripts that would need hosting. Primarily the copy/paste IDL one.

[plehegar]

Missed this somehow, catching up...

It is no longer true that we don't allow JS except for fixup.js.

W3C TR allows "recognized" JS. The list is at https://www.w3.org/scripts/ (this is not a public page apparently, not sure why). https://www.w3.org/TR/webaudio/ uses MathJAX for example. https://www.w3.org/TR/clreq/ might be a mistake however (but pubrules doesn't seem to flag it).
Keep in mind that similarly to CSS files, we don't allow changes except for bug fixes to the scripts once the document has been published (thus we link to specific library versions). You may publish a new version of the script for every publication but, given that we'd need to review the script for each publication, we won't scale fast if it becomes common practice.

The philosophy remains towards avoiding the use of JS if possible and strongly respecting the security and privacy of our users (so nothing outside w3.org unless exceptions). But we do recognize that the modern Web makes extensive use of it and we welcome it in particular when it provides additional value on top of the text context of the specification. I expect our use of JS to increase overtime in that spirit (better integration with MDN, WPT, caniuse, etc.).

[plehegar]

As a reference, here is the announcement: https://lists.w3.org/Archives/Public/spec-prod/2015JulSep/0014.html

[saschanaz]

Thanks for the details! I don't expect our script to be persistent and immutable, though...

[marcoscaceres]

I guess we just want the clipboard.js script to be hosted, right?

We should also look at externalizing jQuery for those that need it still instead of bundling it. Just having jQuery outside the library would be a massive win for a lot of specs.

[marcoscaceres]

(the jQuery thing unrelated to TR docs... but still)

[saschanaz]

I guess we just want the clipboard.js script to be hosted, right?

Probably also caniuse and MDN. Those can be static but should be dynamic to keep the numbers updated.

[marcoscaceres]

Yes, good suggestions.