Updating our /TR stylesheets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Updating our /TR stylesheets

Philippe Le Hegaret
I'd like to find a path for W3C to update our /TR style sheets and since
we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been
published in the past, we must not try to do it. It has the
simplification that we're breaking the consistency of style between all
W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead,
I'd like to enable ourselves to have progressive enhancements over the
years. It will also avoid having everyone trying to squeeze their own
ideas between of a once-in-a-lifetime chance to change the styles. To
make it easier on the tooling, we also need something predictable. So,
I'd like to propose that we allow ourselves to update the /TR style
sheets once per year, on January 1. All documents published in that year
would  have to use the style, ensuring some consistency. Note that it
doesn't imply we have to change the style every year, but it gives us an
opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:
   https://github.com/w3c/tr-design/blob/gh-pages/README.md

Feedback is welcome.

Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Tobie Langel-3
Separation between style and content--which incidentally is how I heard about Web standards even before I had published (or should I say authored?) my first Web page--should let us change styles without affecting any of the legal requirements we have or what am I missing? Frankly, if, as a standards boy, we write technology for separation of content and style, promote it as a best practice, then not apply it to the documents we publish, I find we just loose credibility.

If there are rules in place that make it impossible to change the style of already published documents (which seems bizarre, I've never heard someone claiming a Comic Sans version of the constitution diverges from the original text), can we just freeze pre 2015 specs, then change those rules and shift to a continuously deployed solution for new specs?

I mean, I applaud trying to find creative solutions to this problem that has been going on for years, but this feels about the same as administration's website that aren't available outside of office hours (yes, this exists).

That said, any solution is better than the current status quo, so if that's the only way through, let's continue looking outdated but at least, let's move forward.

With mixed feelings,

--tobie

On Thu, Apr 16, 2015 at 2:53 PM, Philippe Le Hegaret <[hidden email]> wrote:
I'd like to find a path for W3C to update our /TR style sheets and since we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been published in the past, we must not try to do it. It has the simplification that we're breaking the consistency of style between all W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead, I'd like to enable ourselves to have progressive enhancements over the years. It will also avoid having everyone trying to squeeze their own ideas between of a once-in-a-lifetime chance to change the styles. To make it easier on the tooling, we also need something predictable. So, I'd like to propose that we allow ourselves to update the /TR style sheets once per year, on January 1. All documents published in that year would  have to use the style, ensuring some consistency. Note that it doesn't imply we have to change the style every year, but it gives us an opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:
  https://github.com/w3c/tr-design/blob/gh-pages/README.md

Feedback is welcome.

Philippe



Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Philippe Le Hegaret
On 04/16/2015 09:43 AM, Tobie Langel wrote:
> Separation between style and content--which incidentally is how I
> heard about Web standards even before I had published (or should I say
> authored?) my first Web page--should let us change styles without
> affecting any of the legal requirements we have or what am I missing?
> Frankly, if, as a standards boy, we write technology for separation of
> content and style, promote it as a best practice, then not apply it to
> the documents we publish, I find we just loose credibility.
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.

>
> If there are rules in place that make it impossible to change the
> style of already published documents (which seems bizarre, I've never
> heard someone claiming a Comic Sans version of the constitution
> diverges from the original text), can we just freeze pre 2015 specs,
> then change those rules and shift to a continuously deployed solution
> for new specs?
There are no such rules. We change the style in the past and had to
revert it in fact.

I'm proposing that we put such rule on ourselves to simplify the way
forward for the time being. The other path of trying to change past
documents failed so far for various reasons. To me, the automatic
publication system or our switch to https are more  important than
changing the style of the first edition of XML 1.0 or the style of SOAP
1.2.

> I mean, I applaud trying to find creative solutions to this problem
> that has been going on for years, but this feels about the same as
> administration's website that aren't available outside of office hours
> (yes, this exists).

I would note that it doesn't prevent from solving the problem of old
documents in the future. It's just something where I don't think we
should spend the time on for the moment. I'd prefer the energy to go
into the modern tools proposed by Robin.

Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Shane McCarron
I am in favor of this. But as to changing the styles of previous specs... I agree that styles should not be retroactively changed.  Some specs (notably *mine*) often have PDF and postscript versions published along with them.  Changing a stylesheet would break things like that.  Also, if I remember correctly, the previous attempt at changing the styles was pretty radical and actually altered not just the look but also the order and some of the content.  That was sort of a disaster.  Stylesheets can be used to alter the look without munging the contents.  This is super important for A11Y and I am sure we all know this.  Let's be careful, but let's make progress!

On Thu, Apr 16, 2015 at 9:00 AM, Philippe Le Hegaret <[hidden email]> wrote:
On 04/16/2015 09:43 AM, Tobie Langel wrote:
Separation between style and content--which incidentally is how I heard about Web standards even before I had published (or should I say authored?) my first Web page--should let us change styles without affecting any of the legal requirements we have or what am I missing? Frankly, if, as a standards boy, we write technology for separation of content and style, promote it as a best practice, then not apply it to the documents we publish, I find we just loose credibility.
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.


If there are rules in place that make it impossible to change the style of already published documents (which seems bizarre, I've never heard someone claiming a Comic Sans version of the constitution diverges from the original text), can we just freeze pre 2015 specs, then change those rules and shift to a continuously deployed solution for new specs?
There are no such rules. We change the style in the past and had to revert it in fact.

I'm proposing that we put such rule on ourselves to simplify the way forward for the time being. The other path of trying to change past documents failed so far for various reasons. To me, the automatic publication system or our switch to https are more  important than changing the style of the first edition of XML 1.0 or the style of SOAP 1.2.

I mean, I applaud trying to find creative solutions to this problem that has been going on for years, but this feels about the same as administration's website that aren't available outside of office hours (yes, this exists).

I would note that it doesn't prevent from solving the problem of old documents in the future. It's just something where I don't think we should spend the time on for the moment. I'd prefer the energy to go into the modern tools proposed by Robin.

Philippe





--
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Tobie Langel-3
In reply to this post by Philippe Le Hegaret
Thanks for providing some background, Philippe. Wasn't aware of the context.

On Thu, Apr 16, 2015 at 4:00 PM, Philippe Le Hegaret <[hidden email]> wrote:
On 04/16/2015 09:43 AM, Tobie Langel wrote:
Separation between style and content--which incidentally is how I heard about Web standards even before I had published (or should I say authored?) my first Web page--should let us change styles without affecting any of the legal requirements we have or what am I missing? Frankly, if, as a standards boy, we write technology for separation of content and style, promote it as a best practice, then not apply it to the documents we publish, I find we just loose credibility.
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.

If there are rules in place that make it impossible to change the style of already published documents (which seems bizarre, I've never heard someone claiming a Comic Sans version of the constitution diverges from the original text), can we just freeze pre 2015 specs, then change those rules and shift to a continuously deployed solution for new specs?
There are no such rules. We change the style in the past and had to revert it in fact.

I'm proposing that we put such rule on ourselves to simplify the way forward for the time being. The other path of trying to change past documents failed so far for various reasons. To me, the automatic publication system or our switch to https are more  important than changing the style of the first edition of XML 1.0 or the style of SOAP 1.2.

Agreed. I assumed a common HTML structure along with a common stylesheet which could have been changed easily. 

I mean, I applaud trying to find creative solutions to this problem that has been going on for years, but this feels about the same as administration's website that aren't available outside of office hours (yes, this exists).

I would note that it doesn't prevent from solving the problem of old documents in the future. It's just something where I don't think we should spend the time on for the moment. I'd prefer the energy to go into the modern tools proposed by Robin.

Oh agreed. Wasn't aware it would be time consuming to do so I assumed that it would be simpler.

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

--tobie
 
Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Robin Berjon-6
On 16/04/2015 17:24 , Tobie Langel wrote:

> On Thu, Apr 16, 2015 at 4:00 PM, Philippe Le Hegaret <[hidden email]
>     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

Reply | Threaded
Open this post in threaded view
|

RE: Updating our /TR stylesheets

nigelmegitt
In reply to this post by Philippe Le Hegaret
Philippe,

Done for TTWG.

By the way, did you consider that the timeline for proposing final designs will often fall just before TPAC? You could deal with this in either direction: 1) make the deadline earlier so that whatever group approves the new style before the Director can resolve to accept a proposal to adopt it, during their TPAC meeting; 2) make the deadline later so that last-minute tweaks can be made by interested folk in the early hours during TPAC, for submission by the end of the week after TPAC.

hope all is well with you,

Nigel

--

Nigel Megitt
Lead Technologist, BBC Engineering
Telephone: +44 (0)208 0082360
Telephone (Lync): +44 (0)3030807996
BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP


________________________________________
From: Philippe Le Hegaret [[hidden email]]
Sent: 17 April 2015 14:16
To: Chairs
Subject: Fwd: Updating our /TR stylesheets

Dear Chairs,

Please, circulate this proposal around your Groups and, especially, your
editors. I'd appreciate feedback on the proposal by the AC meeting.

Philippe


-------- Forwarded Message --------
Subject:        Updating our /TR stylesheets
Date:   Thu, 16 Apr 2015 08:53:21 -0400
From:   Philippe Le Hegaret <[hidden email]>
To:     spec-prod <[hidden email]>



I'd like to find a path for W3C to update our /TR style sheets and since
we weren't able to do it so far, here is a radical change on how to do so.

First, since it's too complex to change documents that have been
published in the past, we must not try to do it. It has the
simplification that we're breaking the consistency of style between all
W3C documents but it allows us more forward.

Second, we shouldn't assume we need one new style and be done. Instead,
I'd like to enable ourselves to have progressive enhancements over the
years. It will also avoid having everyone trying to squeeze their own
ideas between of a once-in-a-lifetime chance to change the styles. To
make it easier on the tooling, we also need something predictable. So,
I'd like to propose that we allow ourselves to update the /TR style
sheets once per year, on January 1. All documents published in that year
would  have to use the style, ensuring some consistency. Note that it
doesn't imply we have to change the style every year, but it gives us an
opportunity if we want to.

I added a set of guidelines and an hopefully simple process to do it:
   https://github.com/w3c/tr-design/blob/gh-pages/README.md

Feedback is welcome.

Philippe




Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Philippe Le Hegaret
On 04/17/2015 09:31 AM, Nigel Megitt wrote:
> Done for TTWG.
Thank you.
>
> By the way, did you consider that the timeline for proposing final designs will often fall just before TPAC?
Yes. I phrased the timeline as "deadline" with the intention of giving
flexibility to the project to adapt each year:
[[
The dates above are deadlines but the earlier the better, especially
when considering the schedule of the W3C TPAC meeting.
]]
https://github.com/w3c/tr-design/

>   2) make the deadline later so that last-minute tweaks can be made by interested folk in the early hours during TPAC, for submission by the end of the week after TPAC.
Making the deadline later has the danger that it would give very little
time for our ecosystem to adapt, so I'd rather not. I considered moving
the adoption from January 1st to February 1st as well but I thought it
would generate too many questions. I didn't have get anyone to propose
February 29th yet :)

I'm sure we'll learn from years to years and tweak things as needed.

Philippe


Reply | Threaded
Open this post in threaded view
|

Updating our /TR stylesheets

Philippe Le Hegaret
In reply to this post by Philippe Le Hegaret
All,

I am pleased to report that this project is now adopted and Elika Etemad
(aka Fantasai) agreed to be the point person for 2015. She has now the
difficult mission to propose the new design for documents published in
the year 2016.

Many thanks to Elika and I'm looking forward for the change,

Philippe

On 04/16/2015 08:53 AM, Philippe Le Hegaret wrote:

> I'd like to find a path for W3C to update our /TR style sheets and
> since we weren't able to do it so far, here is a radical change on how
> to do so.
>
> First, since it's too complex to change documents that have been
> published in the past, we must not try to do it. It has the
> simplification that we're breaking the consistency of style between
> all W3C documents but it allows us more forward.
>
> Second, we shouldn't assume we need one new style and be done.
> Instead, I'd like to enable ourselves to have progressive enhancements
> over the years. It will also avoid having everyone trying to squeeze
> their own ideas between of a once-in-a-lifetime chance to change the
> styles. To make it easier on the tooling, we also need something
> predictable. So, I'd like to propose that we allow ourselves to update
> the /TR style sheets once per year, on January 1. All documents
> published in that year would  have to use the style, ensuring some
> consistency. Note that it doesn't imply we have to change the style
> every year, but it gives us an opportunity if we want to.
>
> I added a set of guidelines and an hopefully simple process to do it:
>   https://github.com/w3c/tr-design/blob/gh-pages/README.md
>
> Feedback is welcome.
>
> Philippe
>


Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

Philippe Le Hegaret
[adding Fantasai in cc]

On 05/13/2015 02:05 PM, Philippe Le Hegaret wrote:

> All,
>
> I am pleased to report that this project is now adopted and Elika
> Etemad (aka Fantasai) agreed to be the point person for 2015. She has
> now the difficult mission to propose the new design for documents
> published in the year 2016.
>
> Many thanks to Elika and I'm looking forward for the change,
>
> Philippe
>
> On 04/16/2015 08:53 AM, Philippe Le Hegaret wrote:
>> I'd like to find a path for W3C to update our /TR style sheets and
>> since we weren't able to do it so far, here is a radical change on
>> how to do so.
>>
>> First, since it's too complex to change documents that have been
>> published in the past, we must not try to do it. It has the
>> simplification that we're breaking the consistency of style between
>> all W3C documents but it allows us more forward.
>>
>> Second, we shouldn't assume we need one new style and be done.
>> Instead, I'd like to enable ourselves to have progressive
>> enhancements over the years. It will also avoid having everyone
>> trying to squeeze their own ideas between of a once-in-a-lifetime
>> chance to change the styles. To make it easier on the tooling, we
>> also need something predictable. So, I'd like to propose that we
>> allow ourselves to update the /TR style sheets once per year, on
>> January 1. All documents published in that year would  have to use
>> the style, ensuring some consistency. Note that it doesn't imply we
>> have to change the style every year, but it gives us an opportunity
>> if we want to.
>>
>> I added a set of guidelines and an hopefully simple process to do it:
>>   https://github.com/w3c/tr-design/blob/gh-pages/README.md
>>
>> Feedback is welcome.
>>
>> Philippe
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Updating our /TR stylesheets

fantasai
In reply to this post by Philippe Le Hegaret
On 05/13/2015 02:05 PM, Philippe Le Hegaret wrote:
> All,
>
> I am pleased to report that this project is now adopted and Elika Etemad (aka Fantasai) agreed to be the point person for
> 2015. She has now the difficult mission to propose the new design for documents published in the year 2016.
>
> Many thanks to Elika and I'm looking forward for the change,

Thanks Philippe!

Just so everyone's clear, my goal for this year is just minor improvements and cleanup,
so I'm not going to be accepting any major redesign work for 2016. I *want* to do major
redesign work, but doing that well is going to require markup changes, and that's a
project we don't want to tackle while the publication system is being overhauled. ;)
We can certainly start on that project this year, but the 2016 style sheet will not be
its release year.

I'll try to look through the pull requests in the next few weeks, and then send out a
survey to collect WG input for more changes.

Draft survey: https://www.w3.org/wiki/SpecProd/Restyle/Survey

~fantasai