Process questions for the transition to the new style

[w3c]

Process questions for the transition to the new style

[r12a]

Btw, adding a switch to respec could also swap in the required changes to the markup, such as the correct W3C logo at top right, and the markup needed to generate the TOC. It's a lot to expect editors to make those changes (if they know what they are) to test the styling on their current drafts.

[iherman]

I'm somewhat concerned that there appears to be only one demo document for the new styling, and that that document only contains a subset of the features likely to need support under the new style (eg. no wide tables or diagrams per issue #27 #27 ).

I wonder how many editors are actually trying the new styling against their documents to provide us with the necessary beta testing feedback before the big switch, and worry that all kinds of issues may surface AFTER the switch has been flicked. Such issues will need immediate attention to avoid confusion and the avoid impacting deadlines for some of the documents in question. Is there provision for that?

I suggest that we test the new styling against a wider range of specs (especially non-CSS specs!), and put up additional demos.

What could really help time-constrained editors to test against their specs would be to add a switch to respec and bikeshed (it would need to be within the next few days) that would allow the editor to quickly generate their document in the new style to check for errors. (Even if we don't do that this year, and i think we should, we ought to consider it for future years.)

I would go one step further. I believe that a switch between the new and old style for, eg, respec, as well as a larger number of test cases, is a must if we really plan a deployment on the 1st of January. The few examples show that changing to the new style is not only a simple matter of changing the stylesheet reference: it may require some manual editing on the source documents proper. While that may be o.k. for documents that are at the early stage of development, this may become more problematic for PR-s or RECS, but even for CR-s, where the visual stability of the documents are important for, eg, external reviews (and, typically, when the editors are more inclined finish the work quickly and move on). We should not overload and put time pressure on our editors.

(B.t.w., as far as I know if a document is in PR, and its transition to REC is accepted by the Director, there is supposed to be no changes on the document except maybe spelling mistakes. The problems for the documents leading to #27 is that PR is planned to be published in a few weeks, while REC is planned for January…)

[fantasai]

Fwiw, the only markup change required by the new styles is putting <nav id=toc> around the "Table of Contents" section and making sure there's an appropriate <meta> viewport tag. (And, optionally, adding the back-to-top link.) None of these is incompatible with the old style and improves the usability of the document in general, so it doesn't need to be conditional on the new style switch.

(The logo is currently swapped in via CSS because I wanted to minimize the markup changes we're asking of editors and the pubrules checker. But I suppose we can have that actually change over for 2016, if the pubrules checker can handle it.)

[tripu]

(“Putting <nav id=toc> around the ‘Table of Contents’ section”)

[r12a]

i think this comment can be closed now?