Re: Updating our /TR stylesheets

On 16/04/2015 17:24 , Tobie Langel wrote:
> On Thu, Apr 16, 2015 at 4:00 PM, Philippe Le Hegaret <plh@w3.org
>     You're assuming all authors of previous documents wouldn't mind to
>     have the style of their documents changed. Past experiences showed
>     that it's not the case. This is not just technical or a resource
>     challenge here.
>
> I actually wasn't aware there were dramatically different spec styles
> and assumed that was more of a bug than a feature. Frankly, this is not
> how publishing is generally done, and I fail to understand the benefits
> of this strategy.

It's not so much that there are dramatically different spec styles (if 
you go to the really old stuff there are, but we can forget about 
those). It's more that people have been adding their own enhancements 
here and there (e.g. an absolutely positioned "Report Bug" button at the 
top right) and if you update the styles on them, you break stuff.

There's precedent. There was a project to update all TR styles several 
years ago, and while many specs went through unscathed, several really 
suffered. And no one has the time to go through all drafts to check.

Keep in mind that many of those documents are legally binding. If 
because of a stupid style conflict a normative requirement vanishes, 
you're in an interesting place.

> So my suggestion given this context is to go with pre 2015 style and
> continuous deployment for new specs.

My initial thought was continuous deployment too. But you know what you 
need for continuous deployment? A bloody good test suite. Doubly so if 
you can break legally binding documents that no one is reading with any 
regularity (say, an FPWD that gave an exclusion opportunity that no one 
took, but that is later contested). Alternatively, we could get away 
with enforcing much stricter markup constructs and no style overrides 
(and no JS toys) since that would enable us to guarantee we're not 
breaking stuff.

But I think I prefer the alternative of giving people freedom to do all 
sorts of things to their specs, which we commit to not breaking.

And, honestly man. Yearly releases. At a standards organisation. That 
*is* continuous deployment!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 16 April 2015 22:25:10 UTC