Reverting symlinks to Recommendations

[Ian Jacobs-2]

Hello all,

In light of the comments we've received about linking to the  
reformatted Recommendations, today we will roll back the latest  
version URIs, restoring them to their state before the site launch. If  
you find any that are not restored correctly, do let us know.

We will leave the reformatted specs at their dated URIs. We will  
revisit the question of reformatting existing Recommendations.

Please allow the remainder of the day for updates. Thank you,

  _ Ian

--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[David Carlisle]

Thanks.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

[Charles McCathieNevile-2]

On Thu, 15 Oct 2009 18:49:02 +0200, David Carlisle <davidc@...>  
wrote:

>
> Thanks.
>

Likewise.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Ian Jacobs-2]

On 15 Oct 2009, at 11:46 AM, Ian Jacobs wrote:

> Hello all,
>
> In light of the comments we've received about linking to the  
> reformatted Recommendations, today we will roll back the latest  
> version URIs, restoring them to their state before the site launch.  
> If you find any that are not restored correctly, do let us know.
>
> We will leave the reformatted specs at their dated URIs. We will  
> revisit the question of reformatting existing Recommendations.
>
> Please allow the remainder of the day for updates.

We've completed the rollback. This includes:

  * latest version URIs restored
  * reformatted specs no longer appear in TR views, current status  
pages, or spec histories.

Let me know if you see any issues.

  _ Ian
--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[Robin Berjon-4]

On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
> We've completed the rollback. This includes:
>
> * latest version URIs restored
> * reformatted specs no longer appear in TR views, current status  
> pages, or spec histories.
>
> Let me know if you see any issues.

Excellent, thanks a lot, and again many kudos for the rest of the site!

Should we maybe have a BoF/quick session/beer/whatever about new TR  
templates at TPAC?

--
Robin Berjon
   robineko — hired gun, higher standards
   http://robineko.com/

[Chris Lilley]

On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:

RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>> We've completed the rollback. This includes:

>> * latest version URIs restored
>> * reformatted specs no longer appear in TR views, current status  
>> pages, or spec histories.

>> Let me know if you see any issues.

RB> Excellent, thanks a lot, and again many kudos for the rest of the site!

RB> Should we maybe have a BoF/quick session/beer/whatever about new TR  
RB> templates at TPAC?

That sounds like a good idea.

The recent alteration of /TR had a similar effect to 'Last' Call, i.e. it was the first time many of us took a serious look at the proposed changes :)


--
 Chris Lilley                    mailto:chris@...
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

[Ian Jacobs-2]

On 19 Oct 2009, at 9:04 AM, Chris Lilley wrote:

> On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:
>
> RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>>> We've completed the rollback. This includes:
>
>>> * latest version URIs restored
>>> * reformatted specs no longer appear in TR views, current status
>>> pages, or spec histories.
>
>>> Let me know if you see any issues.
>
> RB> Excellent, thanks a lot, and again many kudos for the rest of  
> the site!
>
> RB> Should we maybe have a BoF/quick session/beer/whatever about new  
> TR
> RB> templates at TPAC?
>
> That sounds like a good idea.
>
> The recent alteration of /TR had a similar effect to 'Last' Call,  
> i.e. it was the first time many of us took a serious look at the  
> proposed changes :)

My current thinking is this:

  * There were a number of things we wanted to accomplish via the  
rewritten TRs, including:

    - Providing dynamic status information
    - Simplifying the front matter ("nobody reads the status  
section!") while leaving the most important bits up front.
    - Providing useful context (links to tutorials, validators, etc.)  
on the right side
    - Integration into the rest of the site while retaining much of  
the branding of the original style.
    - Getting all this without changing pubrules requirements or  
authoring practices.
    - Giving multiple views of the specs (desktop, mobile, print) so  
that people could hide navigation.

    We set up the "print mode" for TRs to look almost exactly like the  
classic TRs (modulo minor formatting
    bugs we could fix in a matter of days). However, I doubt that most  
people realized this, and we didn't
    advertise it loudly. (Perhaps making the classic view the default  
view would have helped, but even then, the
    status section had migrated to the bottom.)

* I'm less inclined to do rewriting now that the editors have made  
clear how strongly they feel about our reformatting  specs after the  
editors have put on their finishing touches. Other valuable lessons  
included:  don't put non-w3c branding on specs@

* And so I would like to find another approach to providing some of  
the benefits mentioned above without any rewriting. For instance, we  
might offer a (prominently displayed) service where one can provide a  
spec uri (or get it through a link or pulldown) and a tool generates  
dynamically the currents status information, available tutorials, etc.

* We had not done this before because it is simply to get all the  
information at a URI rather than having to do the two-step of going to  
a service to get the information.

Thanks again for moving this discussion forward constructively.

  _ Ian

--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[noah_mendelsohn]

Ian Jacobs wrote:

> * I'm less inclined to do rewriting now that the editors have made
> clear how strongly they feel about our reformatting  specs after the
> editors have put on their finishing touches. Other valuable lessons
> included:  don't put non-w3c branding on specs@

I share your inclination to be very conservative in moving ahead.  Not
only have we learned that change in this space is very difficult, I read
you list of what the requirements were for the last attempt, and find that
even some of them seem less then clearly beneficial.  So, it's not only
the implementation impediments, IMO.

>     - Providing dynamic status information

I'm not sure what dynamic means

> Simplifying the front matter ("nobody reads the status
> section!")

It's often the first thing I read.  Very often I'll wind up looking at a
draft because it was hyperlinked from a public (non W3C) email discussion
or blog;  the first thing I want to know is whether I'm looking at
something that's well along in the process, if it's not a full
Recommendation, or whether it's some working draft that is likely to
change.

>     - Providing useful context (links to tutorials, validators, etc.)
> on the right side

Might make sense on wide screens, and when users run with wide browser
windows, but what fraction of the time that I read a Rec. do I want to get
that other stuff?  Often the, screen space is better devoted to keeping
things simple.  Also, aesthetics aside (and they do matter, I often prefer
to see this stuff at the top where it can be scrolled off the screen as I
read, if it's even there at all.  I think the number one thing you want to
devote screen space to is: the document itself.  Keep it simple.  Could
one have a single link to "additional resources", perhaps with a popup on
hover if you really want?

>     - Integration into the rest of the site while retaining much of
> the branding of the original style.

Yes.

>     - Getting all this without changing pubrules requirements or
> authoring practices.

Going to be very hard.  Please do ask a broad range of working groups what
their tool chains, stylesheets, and publication process is like.  I think
you'll find in some cases quite a bit of sophistication/complexity, and
quite a bit of variety as people have adapted to meet the particular needs
of particular specifications.


>     - Giving multiple views of the specs (desktop, mobile, print) so
> that people could hide navigation.

If it's there at all, yes.

Just my 2 cents.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Ian Jacobs <ij@...>
Sent by: chairs-request@...
10/19/2009 11:13 AM
 
        To:     Chris Lilley <chris@...>
        cc:     Robin Berjon <robin@...>, chairs@...,
spec-prod@..., (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Reverting symlinks to Recommendations



On 19 Oct 2009, at 9:04 AM, Chris Lilley wrote:

> On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:
>
> RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>>> We've completed the rollback. This includes:
>
>>> * latest version URIs restored
>>> * reformatted specs no longer appear in TR views, current status
>>> pages, or spec histories.
>
>>> Let me know if you see any issues.
>
> RB> Excellent, thanks a lot, and again many kudos for the rest of
> the site!
>
> RB> Should we maybe have a BoF/quick session/beer/whatever about new
> TR
> RB> templates at TPAC?
>
> That sounds like a good idea.
>
> The recent alteration of /TR had a similar effect to 'Last' Call,
> i.e. it was the first time many of us took a serious look at the
> proposed changes :)

My current thinking is this:

  * There were a number of things we wanted to accomplish via the
rewritten TRs, including:

    - Providing dynamic status information
    - Simplifying the front matter ("nobody reads the status
section!") while leaving the most important bits up front.
    - Providing useful context (links to tutorials, validators, etc.)
on the right side
    - Integration into the rest of the site while retaining much of
the branding of the original style.
    - Getting all this without changing pubrules requirements or
authoring practices.
    - Giving multiple views of the specs (desktop, mobile, print) so
that people could hide navigation.

    We set up the "print mode" for TRs to look almost exactly like the
classic TRs (modulo minor formatting
    bugs we could fix in a matter of days). However, I doubt that most
people realized this, and we didn't
    advertise it loudly. (Perhaps making the classic view the default
view would have helped, but even then, the
    status section had migrated to the bottom.)

* I'm less inclined to do rewriting now that the editors have made
clear how strongly they feel about our reformatting  specs after the
editors have put on their finishing touches. Other valuable lessons
included:  don't put non-w3c branding on specs@

* And so I would like to find another approach to providing some of
the benefits mentioned above without any rewriting. For instance, we
might offer a (prominently displayed) service where one can provide a
spec uri (or get it through a link or pulldown) and a tool generates
dynamically the currents status information, available tutorials, etc.

* We had not done this before because it is simply to get all the
information at a URI rather than having to do the two-step of going to
a service to get the information.

Thanks again for moving this discussion forward constructively.

  _ Ian

--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[David Carlisle]

Ian,

I think it's right that existing RECs stay as they are, and that going
forward we don't add text (eg sidebars and search links) to recs after
they have been finalised by the appropriate WG, but it would certainly
be possible (if that's what was wanted) to come up with a styling for
future rec track documents more in tune with the new design.

A tool that massages the "final form" html document is never going to be
workable in practice, too many working groups produce their documents in
multiple forms (html, xhtml, single file, multiple file, diff-marked etc)
often by having modified xmlspec based workflows for each document
variant. What's needed is to modify those workflows; not to add a further
transformation stage to just one of the formats.


If there was a specification for new style front matter, and for heading
colours and sizes and image usage eg white w3c on blue rather than blue
on white) or any other stylistic elements, and a version of the pubrules
checker that could work with new style documents, I'd certainly be
prepared to modify the mathmlspec/xmlspec stylesheets to produce
something that would match a new TR style specification, and probably
most other groups using variants of xmlspec markup could do something
similar.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

[Ian Jacobs-2]

On 19 Oct 2009, at 10:34 AM, noah_mendelsohn@... wrote:

> Ian Jacobs wrote:
>
>> * I'm less inclined to do rewriting now that the editors have made
>> clear how strongly they feel about our reformatting  specs after the
>> editors have put on their finishing touches. Other valuable lessons
>> included:  don't put non-w3c branding on specs@
>
> I share your inclination to be very conservative in moving ahead.  Not
> only have we learned that change in this space is very difficult, I  
> read
> you list of what the requirements were for the last attempt, and  
> find that
> even some of them seem less then clearly beneficial.  So, it's not  
> only
> the implementation impediments, IMO.
>
>>    - Providing dynamic status information
>
> I'm not sure what dynamic means

That means: the specs would change in place over time to reflect two  
pieces of information:

  * Is this a rec?
  * Is this the most recent thing for this publication series?

>
>> Simplifying the front matter ("nobody reads the status
>> section!")
>
> It's often the first thing I read.

Good to know. We hear a lot of the other as well.

>  Very often I'll wind up looking at a
> draft because it was hyperlinked from a public (non W3C) email  
> discussion
> or blog;  the first thing I want to know is whether I'm looking at
> something that's well along in the process, if it's not a full
> Recommendation, or whether it's some working draft that is likely to
> change.
>
>>    - Providing useful context (links to tutorials, validators, etc.)
>> on the right side
>
> Might make sense on wide screens, and when users run with wide browser
> windows, but what fraction of the time that I read a Rec. do I want  
> to get
> that other stuff?

That's why we created the print mode: to hide that if you wanted to.  
You can select print mode when reading on your screen or, obviously,  
when printing.

> Often the, screen space is better devoted to keeping
> things simple.  Also, aesthetics aside (and they do matter, I often  
> prefer
> to see this stuff at the top where it can be scrolled off the screen  
> as I
> read, if it's even there at all.  I think the number one thing you  
> want to
> devote screen space to is: the document itself.  Keep it simple.  
> Could
> one have a single link to "additional resources", perhaps with a  
> popup on
> hover if you really want?

[Part of broadening topic of "what UI" for TPAC and moving forward.]

>
>>    - Integration into the rest of the site while retaining much of
>> the branding of the original style.
>
> Yes.
>
>>    - Getting all this without changing pubrules requirements or
>> authoring practices.
>
> Going to be very hard.  Please do ask a broad range of working  
> groups what
> their tool chains, stylesheets, and publication process is like.

We have. That's why we intended to require no changes to pubrules. The  
idea was: if you give us a pubrules-compliant document, we will wrap  
it an only made these modifications:

  * Add top, right, left, footer
  * Move status section to the bottom
  * Add new status table at the top.

No other content was to change, and we designed the style sheets to  
not interfere with editor-provided styles by using prefixes. (NOTE:  
Bugs are bugs and we could have worked those out.)

  _ Ian

> I think
> you'll find in some cases quite a bit of sophistication/complexity,  
> and
> quite a bit of variety as people have adapted to meet the particular  
> needs
> of particular specifications.
>
>
>>    - Giving multiple views of the specs (desktop, mobile, print) so
>> that people could hide navigation.
>
> If it's there at all, yes.
>
> Just my 2 cents.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Ian Jacobs <ij@...>
> Sent by: chairs-request@...
> 10/19/2009 11:13 AM
>
>        To:     Chris Lilley <chris@...>
>        cc:     Robin Berjon <robin@...>, chairs@...,
> spec-prod@..., (bcc: Noah Mendelsohn/Cambridge/IBM)
>        Subject:        Re: Reverting symlinks to Recommendations
>
>
>
> On 19 Oct 2009, at 9:04 AM, Chris Lilley wrote:
>
>> On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:
>>
>> RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>>>> We've completed the rollback. This includes:
>>
>>>> * latest version URIs restored
>>>> * reformatted specs no longer appear in TR views, current status
>>>> pages, or spec histories.
>>
>>>> Let me know if you see any issues.
>>
>> RB> Excellent, thanks a lot, and again many kudos for the rest of
>> the site!
>>
>> RB> Should we maybe have a BoF/quick session/beer/whatever about new
>> TR
>> RB> templates at TPAC?
>>
>> That sounds like a good idea.
>>
>> The recent alteration of /TR had a similar effect to 'Last' Call,
>> i.e. it was the first time many of us took a serious look at the
>> proposed changes :)
>
> My current thinking is this:
>
>  * There were a number of things we wanted to accomplish via the
> rewritten TRs, including:
>
>    - Providing dynamic status information
>    - Simplifying the front matter ("nobody reads the status
> section!") while leaving the most important bits up front.
>    - Providing useful context (links to tutorials, validators, etc.)
> on the right side
>    - Integration into the rest of the site while retaining much of
> the branding of the original style.
>    - Getting all this without changing pubrules requirements or
> authoring practices.
>    - Giving multiple views of the specs (desktop, mobile, print) so
> that people could hide navigation.
>
>    We set up the "print mode" for TRs to look almost exactly like the
> classic TRs (modulo minor formatting
>    bugs we could fix in a matter of days). However, I doubt that most
> people realized this, and we didn't
>    advertise it loudly. (Perhaps making the classic view the default
> view would have helped, but even then, the
>    status section had migrated to the bottom.)
>
> * I'm less inclined to do rewriting now that the editors have made
> clear how strongly they feel about our reformatting  specs after the
> editors have put on their finishing touches. Other valuable lessons
> included:  don't put non-w3c branding on specs@
>
> * And so I would like to find another approach to providing some of
> the benefits mentioned above without any rewriting. For instance, we
> might offer a (prominently displayed) service where one can provide a
> spec uri (or get it through a link or pulldown) and a tool generates
> dynamically the currents status information, available tutorials, etc.
>
> * We had not done this before because it is simply to get all the
> information at a URI rather than having to do the two-step of going to
> a service to get the information.
>
> Thanks again for moving this discussion forward constructively.
>
>  _ Ian
>
> --
> Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
> Tel:                                      [phone]
>
>
>
>
>

--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[Lauren Wood]

One of the problems with these changes is that Working Groups that no
longer exist, and chairs and editors who no longer work on activities
with W3C, likely didn't know of the mooted changes (I didn't, for
example). These people are less likely to feel like spending the time
to work through any bugs introduced through the new stylesheets into
the Recs they produced ten or more years ago than the chairs and
editors of specs currently being produced. This makes leaving the Recs
that have already been published the way they are, and introducing the
changes to new ones, the safest approach.

I looked at DOM Level 1, and found the new stylesheet made it much
harder to read than the old version.

Lauren

[noah_mendelsohn]

Thank you for the careful response.

> No other content was to change, and we designed the style sheets to
> not interfere with editor-provided styles by using prefixes.

Am I right that you also changed fonts, in some cases colors, etc.?  All
of those things can either improve or detract from the readibility of a
document, sometimes even for accidental reasons (lack of contrast with
colors in an image).  I really think that good editors proof their
documents in several user agents, and with an eye toward things that might
not have been obvious at the markup level.

> You can select print mode when reading on your screen or, obviously,
> when printing.

I don't like the idea of overloading the "print" abstraction this way.  In
my experience, there are a variety of things one sometimes need to do to
get printing right, e.g. to fudge font sizes to keep boxes from blowing
off the sides of the printed page.  I believe I worked on that on and off
for several weeks for the SOAP Recommendation.  In those days, CSS wasn't
as robust (or I didn't know it as well), so I think the fonts we used were
the same for screen and print, but they were the result of considerable
experimentation with Print Preview in a number of browsers.   If you do
want to have all that other stuff as the default when looking at a Rec on
screen, then I would probably prefer a button like "Clean screen" or
"Document-only" or some such if an interactive user wants a clean copy.  I
think the "print" meme is really a relic of advertising-driven sites, that
want you to believe that their clean views are only for print.

I still think that less is more:  a very simple, small header line, or
maybe a small wrapround box in the upper right as a wormhole into more
help would in many cases be better than something elaborate.  Most of us
who open a spec just want the best rendering we can get of the spec
itself.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Ian Jacobs <ij@...>
10/19/2009 11:55 AM
 
        To:     noah_mendelsohn@...
        cc:     chairs@..., chairs-request@..., Chris Lilley
<chris@...>, Robin Berjon <robin@...>, spec-prod@...
        Subject:        Re: Reverting symlinks to Recommendations



On 19 Oct 2009, at 10:34 AM, noah_mendelsohn@... wrote:

> Ian Jacobs wrote:
>
>> * I'm less inclined to do rewriting now that the editors have made
>> clear how strongly they feel about our reformatting  specs after the
>> editors have put on their finishing touches. Other valuable lessons
>> included:  don't put non-w3c branding on specs@
>
> I share your inclination to be very conservative in moving ahead.  Not
> only have we learned that change in this space is very difficult, I
> read
> you list of what the requirements were for the last attempt, and
> find that
> even some of them seem less then clearly beneficial.  So, it's not
> only
> the implementation impediments, IMO.
>
>>    - Providing dynamic status information
>
> I'm not sure what dynamic means

That means: the specs would change in place over time to reflect two
pieces of information:

  * Is this a rec?
  * Is this the most recent thing for this publication series?

>
>> Simplifying the front matter ("nobody reads the status
>> section!")
>
> It's often the first thing I read.

Good to know. We hear a lot of the other as well.

>  Very often I'll wind up looking at a
> draft because it was hyperlinked from a public (non W3C) email
> discussion
> or blog;  the first thing I want to know is whether I'm looking at
> something that's well along in the process, if it's not a full
> Recommendation, or whether it's some working draft that is likely to
> change.
>
>>    - Providing useful context (links to tutorials, validators, etc.)
>> on the right side
>
> Might make sense on wide screens, and when users run with wide browser
> windows, but what fraction of the time that I read a Rec. do I want
> to get
> that other stuff?

That's why we created the print mode: to hide that if you wanted to.
You can select print mode when reading on your screen or, obviously,
when printing.

> Often the, screen space is better devoted to keeping
> things simple.  Also, aesthetics aside (and they do matter, I often
> prefer
> to see this stuff at the top where it can be scrolled off the screen
> as I
> read, if it's even there at all.  I think the number one thing you
> want to
> devote screen space to is: the document itself.  Keep it simple.
> Could
> one have a single link to "additional resources", perhaps with a
> popup on
> hover if you really want?

[Part of broadening topic of "what UI" for TPAC and moving forward.]

>
>>    - Integration into the rest of the site while retaining much of
>> the branding of the original style.
>
> Yes.
>
>>    - Getting all this without changing pubrules requirements or
>> authoring practices.
>
> Going to be very hard.  Please do ask a broad range of working
> groups what
> their tool chains, stylesheets, and publication process is like.

We have. That's why we intended to require no changes to pubrules. The
idea was: if you give us a pubrules-compliant document, we will wrap
it an only made these modifications:

  * Add top, right, left, footer
  * Move status section to the bottom
  * Add new status table at the top.

No other content was to change, and we designed the style sheets to
not interfere with editor-provided styles by using prefixes. (NOTE:
Bugs are bugs and we could have worked those out.)

  _ Ian

> I think
> you'll find in some cases quite a bit of sophistication/complexity,
> and
> quite a bit of variety as people have adapted to meet the particular
> needs
> of particular specifications.
>
>
>>    - Giving multiple views of the specs (desktop, mobile, print) so
>> that people could hide navigation.
>
> If it's there at all, yes.
>
> Just my 2 cents.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Ian Jacobs <ij@...>
> Sent by: chairs-request@...
> 10/19/2009 11:13 AM
>
>        To:     Chris Lilley <chris@...>
>        cc:     Robin Berjon <robin@...>, chairs@...,
> spec-prod@..., (bcc: Noah Mendelsohn/Cambridge/IBM)
>        Subject:        Re: Reverting symlinks to Recommendations
>
>
>
> On 19 Oct 2009, at 9:04 AM, Chris Lilley wrote:
>
>> On Monday, October 19, 2009, 3:32:19 PM, Robin wrote:
>>
>> RB> On Oct 15, 2009, at 19:34 , Ian Jacobs wrote:
>>>> We've completed the rollback. This includes:
>>
>>>> * latest version URIs restored
>>>> * reformatted specs no longer appear in TR views, current status
>>>> pages, or spec histories.
>>
>>>> Let me know if you see any issues.
>>
>> RB> Excellent, thanks a lot, and again many kudos for the rest of
>> the site!
>>
>> RB> Should we maybe have a BoF/quick session/beer/whatever about new
>> TR
>> RB> templates at TPAC?
>>
>> That sounds like a good idea.
>>
>> The recent alteration of /TR had a similar effect to 'Last' Call,
>> i.e. it was the first time many of us took a serious look at the
>> proposed changes :)
>
> My current thinking is this:
>
>  * There were a number of things we wanted to accomplish via the
> rewritten TRs, including:
>
>    - Providing dynamic status information
>    - Simplifying the front matter ("nobody reads the status
> section!") while leaving the most important bits up front.
>    - Providing useful context (links to tutorials, validators, etc.)
> on the right side
>    - Integration into the rest of the site while retaining much of
> the branding of the original style.
>    - Getting all this without changing pubrules requirements or
> authoring practices.
>    - Giving multiple views of the specs (desktop, mobile, print) so
> that people could hide navigation.
>
>    We set up the "print mode" for TRs to look almost exactly like the
> classic TRs (modulo minor formatting
>    bugs we could fix in a matter of days). However, I doubt that most
> people realized this, and we didn't
>    advertise it loudly. (Perhaps making the classic view the default
> view would have helped, but even then, the
>    status section had migrated to the bottom.)
>
> * I'm less inclined to do rewriting now that the editors have made
> clear how strongly they feel about our reformatting  specs after the
> editors have put on their finishing touches. Other valuable lessons
> included:  don't put non-w3c branding on specs@
>
> * And so I would like to find another approach to providing some of
> the benefits mentioned above without any rewriting. For instance, we
> might offer a (prominently displayed) service where one can provide a
> spec uri (or get it through a link or pulldown) and a tool generates
> dynamically the currents status information, available tutorials, etc.
>
> * We had not done this before because it is simply to get all the
> information at a URI rather than having to do the two-step of going to
> a service to get the information.
>
> Thanks again for moving this discussion forward constructively.
>
>  _ Ian
>
> --
> Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
> Tel:                                      [phone]
>
>
>
>
>

--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]

[Ian Jacobs-2]

On 19 Oct 2009, at 11:55 AM, noah_mendelsohn@... wrote:

> Thank you for the careful response.
>
>> No other content was to change, and we designed the style sheets to
>> not interfere with editor-provided styles by using prefixes.
>
> Am I right that you also changed fonts, in some cases colors, etc.?

No, not intentionally.

[snipping the rest for now]

  _ Ian
--
Ian Jacobs (ij@...)    http://www.w3.org/People/Jacobs/
Tel:                                      [phone]