- From: Hongchan Choi <hongchan@google.com>
- Date: Fri, 02 Oct 2015 21:53:45 +0000
- To: Alex Russell <slightlyoff@google.com>
- Cc: Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, Paul Adenot <padenot@mozilla.com>, Audio Working Group <public-audio@w3.org>
- Message-ID: <CAGJqXNuYereHUmZV5p6jSbbUuLgAOpQCBkipMYurw1CxV1=Pgw@mail.gmail.com>
Thanks Alex! It looks very interesting. I would like to look around how it fits to our needs. On Fri, Oct 2, 2015 at 2:23 PM Alex Russell <slightlyoff@google.com> wrote: > Lots of folks use tools like BikeShed: > https://github.com/tabatkins/bikeshed > > On Fri, Oct 2, 2015 at 11:06 AM, Hongchan Choi <hongchan@google.com> > wrote: > >> Not sure how other working groups work on their spec, but I would love to >> handle multiple markdown files with a build system, instead of dealing with >> a gigantic vanilla HTML file. Just tidying up the markup and the >> indentation is just not efficient enough. >> >> On Fri, Oct 2, 2015 at 10:59 AM Chris Wilson <cwilso@google.com> wrote: >> >>> Yes please. Or at the very least, this should be a separate PR. >>> >>> On Fri, Oct 2, 2015 at 10:55 AM, Raymond Toy <rtoy@google.com> wrote: >>> >>>> >>>> >>>> On Thu, Oct 1, 2015 at 8:31 AM, Paul Adenot <padenot@mozilla.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> Unrelated to the current effort, but it can be of interest, I was >>>>> tired with working with weird indentation and markup, so I reformatted the >>>>> whole thing with tidy-html5 (in a separate commit so we can still review >>>>> things properly), and set up a travis-ci job to make sure we don't regress. >>>>> I plan to extend it with link checks (we depend on some external >>>>> resources), and respec checks. For now, everything is pointing at my fork, >>>>> we can change than when we're ready to merge. >>>>> >>>> >>>> Would it be possible to apply the reformatting now rather than later? >>>> It gets really painful to review PRs when people reformat the original >>>> giant line into multiple lines. That makes me read ever word of the >>>> original and every word of the new paragraph to find what actually changed >>>> (only to find that nothing actually changed except for whitespace). >>>> >>>> This makes it difficult to go back in time to find changes, but I'd >>>> rather have that done now instead of later when even more changes have been >>>> made. >>>> >>>> >>> >
Received on Friday, 2 October 2015 21:54:25 UTC