Closed dherman closed 9 years ago
@dherman we are doing the same with ecma-402 (https://github.com/tc39/ecma402/tree/master/spec), moving it to html to use http://bterlson.github.io/ecmarkup/, I can take care of that this week, including the separation into different files per section for convenience. The only question is: should we continue with using .bs
for part of the goodies it offers? I'm talking about styles, metadata, etc. I'm not sure ecmarkup will ever provide support for that /cc @bterlson.
An intermediate (and quite easy) solution is to use Bikeshed as the scaffolding but use Ecmarkdown inside the <emu-alg>
s. That is what whatwg/streams is doing; see:
You can probably get rid of a couple of levels of indirection by not going through a transpiler for the ecmarkupify.js script.
/cc @tabatkins
@domenic that looks good, but there are a couple of features that I will like to have:
<link require="...">
, but for a relatively small spec, I will be ok with a single file (a la streams).<emu-xref href="#something"></emu-xref>
, and it will populate the proper section number from emu-clause
s, etc. How can we combine these? who should be run first? Bikeshed, or Ecmarkup? who is responsible for creating the table of content then?If there a reason for only using emu-alg
in streams? what about the other goodies of ecmarkup
?
I plan on adding ecmarkup to Bikeshed natively. I can push that up in the schedule if it would help.
I plan on doing both multipage (multiple output files) and omnibus (multiple source files) at some point as well. Same thing - I can bump its priority if necessary.
Bumping ecmarkup will be great. Multi-files can wait :)
Interim solution until Bikeshed natively supports ecmarkup: https://github.com/whatwg/loader/pull/57
Once the tools are ready for use we'll want to use ecmarkup and ecmarkdown to do the algorithm steps.