Nabble - w3.org - spec-prod

Re: Proposed W3C Spec Conventions

2009-12-04T10:04:13Z

Hi, Folks-

Thanks for all the great feedback so far!

I've discovered the existing list spec-prod, which seems like a better
place for these discussions, so I'd ask that anyone interested in
following up further respond to spec-prod instead of www-archive.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Doug Schepers wrote (on 11/23/09 3:44 AM):

> Hi, Folks-
>
> (Forwarding and summarizing from Member-only space.)
>
> I'm not the first one to suggest this (apparently Karl tried to push
> this earlier this year), but I really think it's time we establish some
> standardized style conventions for W3C specs.
>
> I took a couple hours to pull together a proposal (attached) based on
> Karl's original along with feedback to that proposal, and conventions
> that I'm familiar with from the SVG and DOM3 Events specs; I'm not
> married to any of it, but any counter-proposals should probably stick
> with at least the level of granularity laid out here.
>
> Please see the attached, and send in counter-proposals or thoughts for
> consideration.
>
> I plan on using this (or whatever variant we all decide on) in the specs
> I'm editing (some SVG specs, DOM3 Events). I encourage others to do the
> same, and report back what works, what doesn't work, what's missing, etc.
>
> (Oh, and I'd really like to see this working with Robin Berjon's ReSpec.js:
> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html )
>
> Thanks!
> -Doug Schepers
> W3C Team Contact, SVG and WebApps \o/ WGs
>

Re: Proposed W3C Spec Conventions

2009-12-04T10:00:42Z

Hi, David-

+spec-prod

L. David Baron wrote (on 12/2/09 5:02 PM):
>
> One thing I'm not a big fan of in this proposal is the color
> conventions used for "Issue" and "Proposal" text, which swap in a
> different foreground color. I somewhat prefer the styles I've used
> a few times, e.g., in http://dbaron.org/css/intrinsic/#intrinsic ,
> which are clearly distinct, but which I find not quite as jarring.

Fair enough. It doesn't bother me, but different people have different
tastes. I imagine that if we get a real designer to lend a hand, we
will end up with better visual representations for everything than we
have right now.

> One other note is that I find the styles here:
> # The defining instance of a term is marked up like this: term.
> # Uses of that term are marked up like this.
> a bit odd, both because:
> (1) it seems odd to switch to a monospace font for something that's
> not code, and
> (2) defining instances of terms are traditionally styled in
> italics, I think.
> I would suggest styling the defining instance in italics and the
> uses as the default link styles.

Seems reasonable. Robin Berjon suggested different link underline
colors for internal vs. external links, and I like that idea, too... so,
maybe we could compromise somewhere in the middle?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

New IRC Channel #specs

2009-12-04T09:19:20Z

Hi, Folks-

I'd like to announce #specs, a new W3C IRC channel for discussing
spec-writing tools and tips:

IRC channel: #specs on irc.w3.org:6665 (that's port 6665, not the
default)

This is intended to be complementary to the spec-prod mailing list,
which is a public mailing list devoted to mechanisms for producing and
managing W3C specifications:

http://lists.w3.org/Archives/Public/spec-prod/

There seems to be a lot of recent momentum toward improving the W3C
spec-writing process, so if you're interested in that, please feel free
to join spec-prod (if you aren't there already).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Наращивание волос

2009-12-02T02:32:57Z

КРАСИВЫЕ ДЛИННЫЕ ВОЛОСЫ ЗА 5 МИНУТ

НАРАЩИВАНИЕ ВОЛОС увеличение длинны и объема.
Скрытие залысин и редких волос у женщин и мужчин.
Лечим волосы от выпадения, восстанавливаем секущиеся концы.
Обучаем наращиванию волос, нарашиванию ресниц. Все расходные материалы, волосы.
Магазины в 25 городах.
Запись к мастеру Киев: 050 469-03-73, 469-71-41, 063 774 1289
Одесса: 050 444 14 14

Re: Reverting symlinks to Recommendations

2009-10-19T10:11:21Z

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: +1 718 260 9447

Re: Reverting symlinks to Recommendations

2009-10-19T09:55:42Z

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: +1 718 260 9447
>
>
>
>
>

--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Re: Reverting symlinks to Recommendations

2009-10-19T09:19:28Z

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

Re: Reverting symlinks to Recommendations

2009-10-19T08:55:40Z

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

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.

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

--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Re: Reverting symlinks to Recommendations

2009-10-19T08:47:12Z

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.
________________________________________________________________________

Re: Reverting symlinks to Recommendations

2009-10-19T08:34:03Z

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: +1 718 260 9447

Re: Reverting symlinks to Recommendations

2009-10-19T08:13:16Z

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

Re: Reverting symlinks to Recommendations

2009-10-19T07:04:36Z

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

Re: Reverting symlinks to Recommendations

2009-10-19T06:32:19Z

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/

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-16T18:32:31Z

[sorry for the delay -- moderator]

On Thu, Oct 15, 2009 at 7:32 AM, Robin Berjon <robin@...> wrote:

> - Is it okay to have the logos of commercial companies on TRs?

I find it troubling, verging on offensive, that there are three
commercial entities (Google, Twitter, and Identi.ca) who now have
branding on the front of Web Standards. What's next, "Sponsored by
Cialis"? -Tim

RE: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T10:40:35Z

+1

speaking for myself only.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@...
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

From:	Michael Champion <Michael.Champion@...>
To:	Robin Berjon <robin@...>, Christopher B Ferris/Waltham/IBM@IBMUS, "spec-prod@..." <spec-prod@...>
Cc:	"chairs@..." <chairs@...>, Ian Jacobs <ij@...>, W3C Members <w3c-ac-members@...>, Michael Rys <mrys@...>
Date:	10/15/2009 12:17 PM
Subject:	RE: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)
Sent by:	chairs-request@...

I agree with Robin and Jim that there wasn't enough consultation with WGs before their publications were reformatted. I'd suggest immediately rolling back the changes to the *specs'* formatting (not the overall website -- there are issues, but I will follow Ian's advice to be patient). Then, follow a process such as Robin suggests to work through the issues and let WGs opt-in -- or at least opt out-- of the new CSS. If you need guinea pigs, use submissions, Recommendations without active WGs, etc., but leave active WGs in control of both the form and content of their specs. I personally like the new look of the documents and believe that most WGs will eventually opt-in, but the team really needs to respect the consensus process and the principle that the WGs own the specs they produce. -----Original Message----- From: w3c-ac-forum-request@... [w3c-ac-forum-request@...] On Behalf Of Robin Berjon Sent: Thursday, October 15, 2009 7:33 AM To: Christopher B Ferris; spec-prod@... Cc: chairs@...; Ian Jacobs; W3C Members Subject: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched) Hi all, in the absence of a list specifically tailored for editors, I'd like to suggest that we can move this discussion to spec-prod@... which seems to be the closest logical location. All but a few of the W3C Recommendations listed at: http://www.w3.org/TR/tr-status-stds.htmlhave been reformatted to match the look of the new site. In many cases this has broken them with various degrees of severity (in some cases rendering them largely unusable). Surely, users can go to the previously published version if they happen to need a functional document, but it's not something that they're likely to guess (unless they read the small note at the bottom of all those documents). I don't think that I'm being particularly grouchy or demanding if I state that running live breaking experiments on documents that are expected to be stable and authoritative at their canonical URLs is a rather bad situation, that we should work together to address as quickly as possible. I have already heard several people who had reviewed beta.w3.org being surprised at the changes made to the Recommendations. It seems rather clear to me that this part of the new site has not received anywhere near the amount of validation that it ought to have. So in the spirit of reaching consensus that we are all familiar with, and in order to help the Team out as it pushes through this huge redesign effort that is in pretty much every other one of its aspects absolutely fantastic, to get all the editors past and present who are willing to help to discuss ways of addressing the current breakage swiftly. I would think that anyone would naturally be welcome to help, but I single out editors as they are after all those whose blood and tears and paper cuts from a thousand man-hours of last comments build these documents and donate them to W3C. They know the kinks and the warts, and they've generally had no other option but to listen to their users at great length. Amongst the topics that I would like to see resolved as part of this discussion are: - Should this experimentation be performed on live Recommendations at their canonical URLs? - Should old documents be updated at all? If yes, should the WGs in charge handle them? - Do TRs need to have the site navigation included or are they standalone? - Is it okay to have the logos of commercial companies on TRs? - Should the SotD and paraphernalia be pushed to the end? And of course any other concern that editors may bring up. Personally, I agree that the idea behind most of the changes has merit, but I believe that this is being rushed out unbaked, and that the quality of our production is taking a hit because of it. WDYT? -- Robin Berjon robineko - hired gun, higher standards http://robineko.com/

Re: Reverting symlinks to Recommendations

2009-10-15T10:34:11Z

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: +1 718 260 9447

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T10:26:24Z

Gentlepeople,

I appreciate Robin's well-said message suggesting some questions
whose answers should guide this topic as it goes forwards, and I'd
like to take the opportunity to express my viewpoint on his
questions. (I hasten to add that my opinion does not represent any
official position of my employer, but does represent my experience as
a Working Group chair and as an editor of standards in several
different fora for two and a half decades.

With respect, I don't believe that moving the discussion to spec-prod
is necessary, and it might not be helpful. I don't believe that any
of my WG's editors are subscribers to spec-prod (indeed, I'm not
certain that I myself am a member), much less all members of my
WG. This subject is of sufficient importance that I believe it
deserves the widest visibility.

At 10/15/2009 08:32 AM, Robin Berjon wrote:

> - Should this experimentation be performed on live Recommendations
>at their canonical URLs?

Absolutely not, and the W3C team should not have to be told
this. Commercial enterprises know never to make experimental changes
to the products on which their customers depend, nor even to their
production systems used internally only. Arguments that "we didn't
change the original documents, which were still available at their
original URIs" don't really fly. The "most recent version" URIs
resolved to the reformatted documents, as did the reformatted TR
page, and the vast majority of the general public use either the
shortname URI (most recent version) or the TR page links to access
W3C documents. Virtually nobody manually types in a dated URI to
access a specific version, and they can do that only if they happen
to have memorized the date of publication in any case!

> - Should old documents be updated at all? If yes, should the WGs in
>charge handle them?

I don't actually think that the reformatting is justified for old
documents OR for new documents. I disagree with some who have said
that the new format looks better, but that's obviously nothing more
than a matter of personal taste. My reason for objecting to the
reformatting is as simple as this: W3C has spent enormous resources
developing a brand and recognition of its specs. Changing the
appearance of the brand for no apparent reason beyond changing it has
proven to be a major problem for many commercial enterprises and it
may do so for W3C as well. There is value in being perceived as an
organization that produces stable specifications and seemingly
arbitrary changes (even to the formatting) might cause some of your
customers to question that perception.

More importantly to me, and to my WG, is the fact that we've spent a
tremendous amount of effort, time, and energy creating document
features that make our documents easier to use and to read, while
remaining absolutely faithful to the W3C published style guide and
the W3C look and feel. Applying blanket reformatting to our
documents without any knowledge of how our documents function has
caused a variety of breaking changes, including some functional
breaks (admittedly, however, most are formatting breaks). To adapt
our various enhancements to another look and feel will cost
additional resources. As my WG, like almost all other WGs, have
extremely limited resources (heck, we are having problems just
getting our minimum requirements accomplished) in a very bad economy,
we simply do not understand how we should be expected to start
re-doing work we've already done just so somebody's idea of
"prettier" can be applied to our documents.

I cannot say what my WG members will decide in the future, but I
would not be surprised if they would argue never to adopt these
arbitrary reformatting changes.

> - Do TRs need to have the site navigation included or are they
>standalone?

TRs are not, IMHO, supposed to be integral parts of the warp and woof
of a web site. They are supposed to be documents whose value is
based in part on the ability to link within themselves and to link to
other related documents -- not all of which are even available on
that web site (e.g., IETF RFCs). W3C policies and copyright clearly
allow people to keep their own copies of the TRs, within their
companies and on their private computers. However much we might all
wish that the world is 100% connected 24x7, it simply ain't so. If I
can't get my work done in a timely fashion when my Internet
connection is broken, even though I have all the documents I need on
my laptop, simply because I can't get to the W3C site to fetch a
bunch of icons and menus, I am going to be increasingly less than
enthusiastic about using the W3C TRs.

> - Is it okay to have the logos of commercial companies on TRs?

Absolutely not, unless the technology represented by the logos are
integral to the technical content of the given TR. In other words, I
might not object to, e.g., a Firefox logo on an HTML TR if it linked
to a clean demo of some esoteric HTML feature that Firefox has
implemented particularly well.

I don't mind there being various commercial companies' logos on the
W3C web site (e.g., Google for a search box, Twitter for
microblogging, and the like) and think that is well within the
authority of the team to determine. But the TRs are supposed to
belong to the community, not to the W3C alone, and I presume that the
owner of one search engine might not be an enthusiastic supporter of
the technology defined by a specification on which the logo of (only)
a competing search engine appears. Whether it's intended as
advertising or not (obviously not, in this case), perceptions matter.

Trust me, if the DB2 (database system by IBM) logo appeared at the
top of every W3C spec, Oracle would not be an enthusiastic member of
W3C for very long.

> - Should the SotD and paraphernalia be pushed to the end?

No, I think not. In spite of some recent comments to the effect that
"nobody reads the SotD and valuable information is overlooked when it
appears there", my experience is different. I personally read the
SotD to be sure that the document I'm reading is the one I wanted to
read, and may people to whom I talk about W3C TRs have implied or
stated that they do the same. When I have to wait for the entire
document to download (sorry, but not everybody has a 10MB/sec link to
the Internet) before I can even tell whether "this' is the correct
version, I tend to get frustrated.

My personal recommendation is that all of the reformatted TRs be
removed immediately and the "real" documents be given the same
visibility and accessibility they had last week. I do not believe
that any documents currently under development, much less those for
which RECs or other final stages have been achieved, should be
reformatted without an explicit opt-in decision by the developing
WG. I would prefer that documents not yet under development by any
arm of the W3C continue to use the current ("old") formatting,
because I don't think it's helpful to change it, certainly not in the
way that it has been experimentally changed. However, if a rather
more carefully thought out reformatting effort were to eventuate,
then perhaps future documents could be created using the new
formatting/style rules.

Hope this helps,
Jim

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
Chair, W3C XML Query WG; XQX (etc.) editor Fax : +1.801.942.3345
Oracle Corporation Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA Personal email: jim at melton dot name
========================================================================
= Facts are facts. But any opinions expressed are the opinions =
= only of myself and may or may not reflect the opinions of anybody =
= else with whom I may or may not have discussed the issues at hand. =
========================================================================

Re: Reverting symlinks to Recommendations

2009-10-15T10:20:35Z

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

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T09:51:47Z

On Thu, Oct 15, 2009 at 7:32 AM, Robin Berjon <robin@...> wrote:

> - Is it okay to have the logos of commercial companies on TRs?

I find it troubling, verging on offensive, that there are three
commercial entities (Google, Twitter, and Identi.ca) who now have
branding on the front of Web Standards. What's next, "Sponsored by
Cialis"? -Tim

Re: Reverting symlinks to Recommendations

2009-10-15T09:49:02Z

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.
________________________________________________________________________

Reverting symlinks to Recommendations

2009-10-15T09:46:49Z

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: +1 718 260 9447

RE: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T09:44:22Z

As I've said, I strongly agree, and would like to add an additional point:

Keep in mind that various groups have, for good or bad reasons, augmented
the standard CSS with customizations or additions, and the new base CSS is
mangling some of these. Compare the renderings of constraints, principles
and good practice notes from the old version of the Architecture of the
World Wide Web (attachment ArchdocOriginal.jpg) [I can't even get a
hyperlink for this in the old format!!!] and the new [1]
(ArchdocBroken.jpg). The layout is clearly broken, and the color coding
of the boxes is also lost.

Furthermore, those boxes were intentionally parallel in layout to the ones
used for "Stories" (other two attachments). First of all, the layout of
the stories themselves is now pretty bad (no padding on the bottom), but
the similarity with good practice notes, constraints, and principles is
also now less apparent.

I request that all of this be reverted immediately. It's very
unprofessional looking as it stands, and arguably misleading. Furthermore,
fixing the architecture document and various findings to "work" with the
new CSS would be time consuming and unnecessary IMO, and who's to say
nobody would try another change later?

The larger observation here is: don't assume that the decoupling of style
and content is sufficiently robust in practice that you can go swapping
stylesheets on deployed documents. It is possible to achieve this if the
authors of every document are aware from the start that this might happen
and if they plan for it, but then it can become extremely difficult to
meet the demand for features specific to particular sorts of documents
(principles, constraints, and good practice notes in the case of AWWW).
The safe assumption is, IMO: act as if each publication is permanently
bound to its stylesheets unless you have specifically verified that
changes aren't going to compromise the quality of the result. Furthermore,
don't assume that you can legislate this away be telling groups to live
with only a bounded set of stylesheet classes used in limited ways. That's
a fine thing to try for when content is quite repetitive in nature or
tightly controlled, but W3C publications cover a very wide range of
subject matter and audiences; such a restriction would not be practical
for them.

Noah

[1] http://www.w3.org/TR/webarch/

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

Michael Champion <Michael.Champion@...>
Sent by: chairs-request@...
10/15/2009 12:10 PM

To: Robin Berjon <robin@...>, Christopher B Ferris
<chrisfer@...>, "spec-prod@..." <spec-prod@...>
cc: "chairs@..." <chairs@...>, Ian Jacobs <ij@...>,
W3C Members <w3c-ac-members@...>, Michael Rys <mrys@...>,
(bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: RE: Review of the Reformatted Recommendations (was
Re: New W3C Web Site Launched)

I agree with Robin and Jim that there wasn't enough consultation with WGs
before their publications were reformatted. I'd suggest immediately
rolling back the changes to the *specs'* formatting (not the overall
website -- there are issues, but I will follow Ian's advice to be
patient). Then, follow a process such as Robin suggests to work through
the issues and let WGs opt-in -- or at least opt out-- of the new CSS. If
you need guinea pigs, use submissions, Recommendations without active WGs,
etc., but leave active WGs in control of both the form and content of
their specs.

I personally like the new look of the documents and believe that most WGs
will eventually opt-in, but the team really needs to respect the consensus
process and the principle that the WGs own the specs they produce.

-----Original Message-----
From: w3c-ac-forum-request@... [mailto:w3c-ac-forum-request@...] On
Behalf Of Robin Berjon
Sent: Thursday, October 15, 2009 7:33 AM
To: Christopher B Ferris; spec-prod@...
Cc: chairs@...; Ian Jacobs; W3C Members
Subject: Review of the Reformatted Recommendations (was Re: New W3C Web
Site Launched)

Hi all,

in the absence of a list specifically tailored for editors, I'd like to
suggest that we can move this discussion to spec-prod@... which seems
to be the closest logical location.

All but a few of the W3C Recommendations listed at:

http://www.w3.org/TR/tr-status-stds.html

have been reformatted to match the look of the new site. In many cases
this has broken them with various degrees of severity (in some cases
rendering them largely unusable). Surely, users can go to the previously
published version if they happen to need a functional document, but it's
not something that they're likely to guess (unless they read the small
note at the bottom of all those documents).

I don't think that I'm being particularly grouchy or demanding if I state
that running live breaking experiments on documents that are expected to
be stable and authoritative at their canonical URLs is a rather bad
situation, that we should work together to address as quickly as possible.

I have already heard several people who had reviewed beta.w3.org being
surprised at the changes made to the Recommendations. It seems rather
clear to me that this part of the new site has not received anywhere near
the amount of validation that it ought to have.

So in the spirit of reaching consensus that we are all familiar with, and
in order to help the Team out as it pushes through this huge redesign
effort that is in pretty much every other one of its aspects absolutely
fantastic, to get all the editors past and present who are willing to help
to discuss ways of addressing the current breakage swiftly. I would think
that anyone would naturally be welcome to help, but I single out editors
as they are after all those whose blood and tears and paper cuts from a
thousand man-hours of last comments build these documents and donate them
to W3C. They know the kinks and the warts, and they've generally had no
other option but to listen to their users at great length.

Amongst the topics that I would like to see resolved as part of this
discussion are:

- Should this experimentation be performed on live Recommendations at
their canonical URLs?
- Should old documents be updated at all? If yes, should the WGs in
charge handle them?
- Do TRs need to have the site navigation included or are they
standalone?
- Is it okay to have the logos of commercial companies on TRs?
- Should the SotD and paraphernalia be pushed to the end?

And of course any other concern that editors may bring up. Personally, I
agree that the idea behind most of the changes has merit, but I believe
that this is being rushed out unbaked, and that the quality of our
production is taking a hit because of it.

WDYT?

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

StoryOriginal.jpg (150K) Download Attachment
ArchdocBroken.jpg (90K) Download Attachment
ArchdocOriginal.jpg (113K) Download Attachment
StoryBroken.jpg (106K) Download Attachment

RE: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T09:10:22Z

I agree with Robin and Jim that there wasn't enough consultation with WGs before their publications were reformatted. I'd suggest immediately rolling back the changes to the *specs'* formatting (not the overall website -- there are issues, but I will follow Ian's advice to be patient). Then, follow a process such as Robin suggests to work through the issues and let WGs opt-in -- or at least opt out-- of the new CSS. If you need guinea pigs, use submissions, Recommendations without active WGs, etc., but leave active WGs in control of both the form and content of their specs.

I personally like the new look of the documents and believe that most WGs will eventually opt-in, but the team really needs to respect the consensus process and the principle that the WGs own the specs they produce.

-----Original Message-----
From: w3c-ac-forum-request@... [mailto:w3c-ac-forum-request@...] On Behalf Of Robin Berjon
Sent: Thursday, October 15, 2009 7:33 AM
To: Christopher B Ferris; spec-prod@...
Cc: chairs@...; Ian Jacobs; W3C Members
Subject: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

Hi all,

in the absence of a list specifically tailored for editors, I'd like to suggest that we can move this discussion to spec-prod@... which seems to be the closest logical location.

All but a few of the W3C Recommendations listed at:

http://www.w3.org/TR/tr-status-stds.html

have been reformatted to match the look of the new site. In many cases this has broken them with various degrees of severity (in some cases rendering them largely unusable). Surely, users can go to the previously published version if they happen to need a functional document, but it's not something that they're likely to guess (unless they read the small note at the bottom of all those documents).

I don't think that I'm being particularly grouchy or demanding if I state that running live breaking experiments on documents that are expected to be stable and authoritative at their canonical URLs is a rather bad situation, that we should work together to address as quickly as possible.

I have already heard several people who had reviewed beta.w3.org being surprised at the changes made to the Recommendations. It seems rather clear to me that this part of the new site has not received anywhere near the amount of validation that it ought to have.

So in the spirit of reaching consensus that we are all familiar with, and in order to help the Team out as it pushes through this huge redesign effort that is in pretty much every other one of its aspects absolutely fantastic, to get all the editors past and present who are willing to help to discuss ways of addressing the current breakage swiftly. I would think that anyone would naturally be welcome to help, but I single out editors as they are after all those whose blood and tears and paper cuts from a thousand man-hours of last comments build these documents and donate them to W3C. They know the kinks and the warts, and they've generally had no other option but to listen to their users at great length.

Amongst the topics that I would like to see resolved as part of this discussion are:

- Should this experimentation be performed on live Recommendations at their canonical URLs?
- Should old documents be updated at all? If yes, should the WGs in charge handle them?
- Do TRs need to have the site navigation included or are they standalone?
- Is it okay to have the logos of commercial companies on TRs?
- Should the SotD and paraphernalia be pushed to the end?

And of course any other concern that editors may bring up. Personally, I agree that the idea behind most of the changes has merit, but I believe that this is being rushed out unbaked, and that the quality of our production is taking a hit because of it.

WDYT?

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

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T09:06:36Z

I have considered the change to presentation ofpublished RECs over the
past few days. Speaking only for myself and not Apple or the HTML WG,
I must admit I am not happy with the change. Thoughts on Robin's
questions:

On Oct 15, 2009, at 7:32 AM, Robin Berjon wrote:

>
> Amongst the topics that I would like to see resolved as part of this
> discussion are:
>
> - Should this experimentation be performed on live Recommendations
> at their canonical URLs?

No. Changing the appearance of specifications is a sensitive issue. It
would be better to start with new Working Drafts, or with WG Notes, as
a way to work out the kinks.

> - Should old documents be updated at all? If yes, should the WGs in
> charge handle them?

No. In my opinion, old RECs should not be updated at all without going
through the appropriate formal Process to update a REC, even if the
changes are only intended to be cosmetic.

> - Do TRs need to have the site navigation included or are they
> standalone?

No. I think TRs not only do not need the site navigation, they *should
not* haveit It's true that Technical Reports of the W3C are published
*on* the W3C site. But I think it is a mistake to present them as
*part of* the W3C site. That seems inappropriate to me. Web Standards
should stand alone. The practice of other standards bodies is that the
standards documents stand alone; they are not presented as an
intrinsic part of some organizations Web site.

> - Is it okay to have the logos of commercial companies on TRs?

I'm ok with this on most of the W3C site, but it seems to be in bad
taste as to TRs. We should be very careful to avoid even the slightest
appearance that Web Standards documents are being used as an
advertising platform. And the tradeoff, I feel, is not a good one.
Most readers of the HTML4.01 specification, for instance, do not need
an immediate affordance to search the whole W3C site, or to see what
the W3C is up to on Twitter.

> - Should the SotD and paraphernalia be pushed to the end?

No. Status of this Document sections often contain information that is
critical to understanding the document. And these sections were
written with the understanding that they would be at the very
beginning of the document - otherwise some material in the SotD may
have been put in the abstract or introduction. I think it's bad to
change this retroactively for old documents, even if we wanted to
change this for future documents.

Regards,
Maciej

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T08:51:20Z

Err.... yay? That's completely unacceptable. I assume you agree. We went to a lot of trouble to produce multiple versions of the documents. We want those versions to remain available to our constituents.

David Carlisle wrote:

Further to this... in many specs there are non-normative versions like 
postscript and PDF t


in the case of mathml at least this is cunningly catered for by removing
all the links to non normative versions, so you have a hard job getting
to the version of the mathml2 spec that uses mathml for example.

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. 
________________________________________________________________________

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@...

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T08:47:58Z

> Further to this... in many specs there are non-normative versions like
> postscript and PDF t

in the case of mathml at least this is cunningly catered for by removing
all the links to non normative versions, so you have a hard job getting
to the version of the mathml2 spec that uses mathml for example.

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.
________________________________________________________________________

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T08:45:00Z

Further to this... in many specs there are non-normative versions like
postscript and PDF that will no longer match! This is unacceptable to
me as an editor, and a quick poll of the call I am on right now (RDFa
Task Force) shows that others agree.

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@...

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T08:36:11Z

> - Should this experimentation be performed on live Recommendations
> at their canonical URLs?

No. especially for documents like MathML which are at last call, we
really can't wait for these things to be fixed, we need TR/MathML2 to
redirect to a valid, readable document, now, today.

> - Should old documents be updated at all? If yes, should the WGs in
> charge handle them?

Some css restyling would (perhaps) be acceptable but editing the actual
files (even if those edits did not make the documents invalid) should
not be done. It completely breaks the spirit of the stability
requirements for TR space.

> - Do TRs need to have the site navigation included or are they
> standalone?

The top bar navigation isn't so bad as it is clearly distinct but the
sidebar and bottom bar should not be added. It gratuitously mixes non
normative text in with the text of the recommendation with very little
visual clues that this is being done.

> - Is it okay to have the logos of commercial companies on TRs?
No.

> - Should the SotD and paraphernalia be pushed to the end?
No.

One could perhaps make a case for changing the position going forward
but the existing texts were written assuming a particular position,
making forward not backward references to the document, they can not in
general be moved.

> And of course any other concern that editors may bring up.

The documents should either be valid html served as text/html or valid
xhtml served as application/xhtml+xml. To sloppily produce xhtml served
as text/html means you are relying on the error correction on the
browser to correctly make something out of invalid html syntax, with the
result you see in most of the curent XML related recs where <a/> syntax,
parsed as text/html causes virtually the entire document to be styled as
a link with a mouse over styling that underlines random runs of text.

As a first, immediate, cause of action, all the short undatated URL
should change to redirect to the original versions until the new
versions are usable.

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.
________________________________________________________________________

Re: Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T08:12:18Z

Robin Berjon writes:

> in the absence of a list specifically tailored for editors, I'd like
> to suggest that we can move this discussion to spec-prod@...

I have not strong feeling either way, since the key points have been here
in any case. Please do keep in mind that spec-prod has a very different
readership than, e.g. chairs. I can see why moving it off ac-members
makes sense, and indeed I don't believe I have posting permissions to that
one (so, this note probably won't get there). Maybe we should, ahem,
cross post to chairs and spec-prod? Usually, I don't like cross posting,
but I suspect that both communities are interested in this one.

Noah

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

Robin Berjon <robin@...>
Sent by: chairs-request@...
10/15/2009 10:32 AM

To: Christopher B Ferris <chrisfer@...>,
spec-prod@...
cc: chairs@..., Ian Jacobs <ij@...>, W3C Members
<w3c-ac-members@...>, (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Review of the Reformatted Recommendations (was Re:
New W3C Web Site Launched)

Hi all,

in the absence of a list specifically tailored for editors, I'd like
to suggest that we can move this discussion to spec-prod@... which
seems to be the closest logical location.

All but a few of the W3C Recommendations listed at:

http://www.w3.org/TR/tr-status-stds.html

have been reformatted to match the look of the new site. In many cases
this has broken them with various degrees of severity (in some cases
rendering them largely unusable). Surely, users can go to the
previously published version if they happen to need a functional
document, but it's not something that they're likely to guess (unless
they read the small note at the bottom of all those documents).

I don't think that I'm being particularly grouchy or demanding if I
state that running live breaking experiments on documents that are
expected to be stable and authoritative at their canonical URLs is a
rather bad situation, that we should work together to address as
quickly as possible.

I have already heard several people who had reviewed beta.w3.org being
surprised at the changes made to the Recommendations. It seems rather
clear to me that this part of the new site has not received anywhere
near the amount of validation that it ought to have.

So in the spirit of reaching consensus that we are all familiar with,
and in order to help the Team out as it pushes through this huge
redesign effort that is in pretty much every other one of its aspects
absolutely fantastic, to get all the editors past and present who are
willing to help to discuss ways of addressing the current breakage
swiftly. I would think that anyone would naturally be welcome to help,
but I single out editors as they are after all those whose blood and
tears and paper cuts from a thousand man-hours of last comments build
these documents and donate them to W3C. They know the kinks and the
warts, and they've generally had no other option but to listen to
their users at great length.

Amongst the topics that I would like to see resolved as part of this
discussion are:

- Should this experimentation be performed on live Recommendations
at their canonical URLs?
- Should old documents be updated at all? If yes, should the WGs in
charge handle them?
- Do TRs need to have the site navigation included or are they
standalone?
- Is it okay to have the logos of commercial companies on TRs?
- Should the SotD and paraphernalia be pushed to the end?

And of course any other concern that editors may bring up. Personally,
I agree that the idea behind most of the changes has merit, but I
believe that this is being rushed out unbaked, and that the quality of
our production is taking a hit because of it.

WDYT?

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

Review of the Reformatted Recommendations (was Re: New W3C Web Site Launched)

2009-10-15T07:32:34Z

Hi all,

in the absence of a list specifically tailored for editors, I'd like
to suggest that we can move this discussion to spec-prod@... which
seems to be the closest logical location.

All but a few of the W3C Recommendations listed at:

http://www.w3.org/TR/tr-status-stds.html

have been reformatted to match the look of the new site. In many cases
this has broken them with various degrees of severity (in some cases
rendering them largely unusable). Surely, users can go to the
previously published version if they happen to need a functional
document, but it's not something that they're likely to guess (unless
they read the small note at the bottom of all those documents).

I don't think that I'm being particularly grouchy or demanding if I
state that running live breaking experiments on documents that are
expected to be stable and authoritative at their canonical URLs is a
rather bad situation, that we should work together to address as
quickly as possible.

I have already heard several people who had reviewed beta.w3.org being
surprised at the changes made to the Recommendations. It seems rather
clear to me that this part of the new site has not received anywhere
near the amount of validation that it ought to have.

So in the spirit of reaching consensus that we are all familiar with,
and in order to help the Team out as it pushes through this huge
redesign effort that is in pretty much every other one of its aspects
absolutely fantastic, to get all the editors past and present who are
willing to help to discuss ways of addressing the current breakage
swiftly. I would think that anyone would naturally be welcome to help,
but I single out editors as they are after all those whose blood and
tears and paper cuts from a thousand man-hours of last comments build
these documents and donate them to W3C. They know the kinks and the
warts, and they've generally had no other option but to listen to
their users at great length.

Amongst the topics that I would like to see resolved as part of this
discussion are:

- Should this experimentation be performed on live Recommendations
at their canonical URLs?
- Should old documents be updated at all? If yes, should the WGs in
charge handle them?
- Do TRs need to have the site navigation included or are they
standalone?
- Is it okay to have the logos of commercial companies on TRs?
- Should the SotD and paraphernalia be pushed to the end?

And of course any other concern that editors may bring up. Personally,
I agree that the idea behind most of the changes has merit, but I
believe that this is being rushed out unbaked, and that the quality of
our production is taking a hit because of it.

WDYT?

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

RE: Pubrules checker & VMMF

2009-10-05T06:46:14Z

Hi Ian,

Thanks, it works :)

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@...

-----Original Message-----
From: Ian Jacobs [mailto:ij@...]
Sent: Monday, October 05, 2009 3:41 PM
To: Marcin Hanclik
Cc: spec-prod@...
Subject: Re: Pubrules checker & VMMF

On 5 Oct 2009, at 8:08 AM, Marcin Hanclik wrote:

> Hi,
>
> I am prepare the Widgets 1.0: View Modes Media Feature document for
> FPWD [1].
> I ran the pubrules checker on the doc [2] and there seems to be a
> problem with <hr> element.
> The document is XHTML strict so I use <hr/> and the problem occurs.
> I removed it, and the the document does not validate, but also the
> pubrules checker seems to crash [3].
> This brings me to the conclusion that the <hr> checker does not work
> as expected.
> Please let me know if you need any further info.

Hi Marcin,

If you include the copyright and the h2 within the <div class="head">
it should work.

_ Ian

>
> Thanks,
> Marcin
>
>
> [1] http://dev.w3.org/2006/waf/widgets-vmmf/Overview.src.html
> [2] http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fdev.w3.org%252Fcvsweb%252F%257Echeckout%257E%252F2006%252Fwaf%252Fwidgets-vmmf%252FOverview.src.html%253Frev%253D1.4%2526content-type%253Dtext%252Fhtml%253B%252520charset%253Diso-8859-1&xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F08%2Fonline_xslt%2Fxslt%3Fxmlfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F07%2Fpubrules%253Fuimode%253Dchecker_full%2526year%253D2009%2526docstatus%253Dfpwd-wd-tr%2526rectrack%253Dyes%2526prevrec%253Dnone%2526patpol%253Dw3c%2526normative%253Dyes%2526uri%253Dhttp%25253A%25252F%25252Fdev.w3.org%25252Fcvsweb%25252F%25257Echeckout%25257E%25252F2006%25252Fwaf%25252Fwidgets-vmmf%25252FOverview.src.html%25253Frev%25253D1.4%252526content-type%25253Dtext%25252Fhtml%25253B%25252520charset%25253Diso-8859-1%2526filterValues%253Dform%2526nscheckmanual%253D%2526display%253Dall%2526recursive%253Doff%2526recurse_auth%253Don%26xslfile%3Dhttp%3
> A%2F%2Fwww.w3.org%2F2005%2F09%2Fchecker%2Fframe.xsl%26display%3Dall%26recurse_auth%3Don&uimode=checker_full&filterValues=form&year=2009&docstatus=fpwd-wd-tr&rectrack=yes&prevrec=none&patpol=w3c&normative=yes&doc_uri=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2006%2Fwaf%2Fwidgets-vmmf%2FOverview.src.html%3Frev%3D1.4%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&recursive=off&nscheckmanual=&display=all&recurse_auth=on
> [3] http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fdev.w3.org%252Fcvsweb%252F%257Echeckout%257E%252F2006%252Fwaf%252Fwidgets-vmmf%252FOverview.src.html%253Frev%253D1.2%2526content-type%253Dtext%252Fhtml%253B%252520charset%253Diso-8859-1&xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F08%2Fonline_xslt%2Fxslt%3Fxmlfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F07%2Fpubrules%253Fuimode%253Dchecker_full%2526year%253D2009%2526docstatus%253Dfpwd-wd-tr%2526rectrack%253Dyes%2526prevrec%253Dnone%2526patpol%253Dw3c%2526normative%253Dyes%2526uri%253Dhttp%25253A%25252F%25252Fdev.w3.org%25252Fcvsweb%25252F%25257Echeckout%25257E%25252F2006%25252Fwaf%25252Fwidgets-vmmf%25252FOverview.src.html%25253Frev%25253D1.2%252526content-type%25253Dtext%25252Fhtml%25253B%25252520charset%25253Diso-8859-1%2526filterValues%253Dform%2526nscheckmanual%253D%2526display%253Dall%2526recursive%253Doff%2526recurse_auth%253Don%26xslfile%3Dhttp%3
> A%2F%2Fwww.w3.org%2F2005%2F09%2Fchecker%2Fframe.xsl%26display%3Dall%26recurse_auth%3Don&uimode=checker_full&filterValues=form&year=2009&docstatus=fpwd-wd-tr&rectrack=yes&prevrec=none&patpol=w3c&normative=yes&doc_uri=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2006%2Fwaf%2Fwidgets-vmmf%2FOverview.src.html%3Frev%3D1.2%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&recursive=off&nscheckmanual=&display=all&recurse_auth=on
>
> Marcin Hanclik
> ACCESS Systems Germany GmbH
> Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@...
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5 | D-46047 Oberhausen
> HRB 13548 Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that
> is privileged or confidential, and is intended for use only by the
> individual or entity to which it is addressed. Any disclosure,
> copying or distribution of the information by anyone else is
> strictly prohibited.
> If you have received this document in error, please notify us
> promptly by responding to this e-mail. Thank you.

--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Re: Pubrules checker & VMMF

2009-10-05T06:40:44Z

On 5 Oct 2009, at 8:08 AM, Marcin Hanclik wrote:

Hi Marcin,

If you include the copyright and the h2 within the <div class="head">
it should work.

_ Ian

--
Ian Jacobs (ij@...) http://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Pubrules checker & VMMF

2009-10-05T06:08:33Z

Hi,

I am prepare the Widgets 1.0: View Modes Media Feature document for FPWD [1].

I ran the pubrules checker on the doc [2] and there seems to be a problem with <hr> element.

The document is XHTML strict so I use <hr/> and the problem occurs.

I removed it, and the the document does not validate, but also the pubrules checker seems to crash [3].

This brings me to the conclusion that the <hr> checker does not work as expected.

Please let me know if you need any further info.

Thanks,

Marcin

[1] http://dev.w3.org/2006/waf/widgets-vmmf/Overview.src.html

[2] http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fdev.w3.org%252Fcvsweb%252F%257Echeckout%257E%252F2006%252Fwaf%252Fwidgets-vmmf%252FOverview.src.html%253Frev%253D1.4%2526content-type%253Dtext%252Fhtml%253B%252520charset%253Diso-8859-1&xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F08%2Fonline_xslt%2Fxslt%3Fxmlfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F07%2Fpubrules%253Fuimode%253Dchecker_full%2526year%253D2009%2526docstatus%253Dfpwd-wd-tr%2526rectrack%253Dyes%2526prevrec%253Dnone%2526patpol%253Dw3c%2526normative%253Dyes%2526uri%253Dhttp%25253A%25252F%25252Fdev.w3.org%25252Fcvsweb%25252F%25257Echeckout%25257E%25252F2006%25252Fwaf%25252Fwidgets-vmmf%25252FOverview.src.html%25253Frev%25253D1.4%252526content-type%25253Dtext%25252Fhtml%25253B%25252520charset%25253Diso-8859-1%2526filterValues%253Dform%2526nscheckmanual%253D%2526display%253Dall%2526recursive%253Doff%2526recurse_auth%253Don%26xslfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F09%2Fchecker%2Fframe.xsl%26display%3Dall%26recurse_auth%3Don&uimode=checker_full&filterValues=form&year=2009&docstatus=fpwd-wd-tr&rectrack=yes&prevrec=none&patpol=w3c&normative=yes&doc_uri=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2006%2Fwaf%2Fwidgets-vmmf%2FOverview.src.html%3Frev%3D1.4%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&recursive=off&nscheckmanual=&display=all&recurse_auth=on

[3] http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fdev.w3.org%252Fcvsweb%252F%257Echeckout%257E%252F2006%252Fwaf%252Fwidgets-vmmf%252FOverview.src.html%253Frev%253D1.2%2526content-type%253Dtext%252Fhtml%253B%252520charset%253Diso-8859-1&xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F08%2Fonline_xslt%2Fxslt%3Fxmlfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F07%2Fpubrules%253Fuimode%253Dchecker_full%2526year%253D2009%2526docstatus%253Dfpwd-wd-tr%2526rectrack%253Dyes%2526prevrec%253Dnone%2526patpol%253Dw3c%2526normative%253Dyes%2526uri%253Dhttp%25253A%25252F%25252Fdev.w3.org%25252Fcvsweb%25252F%25257Echeckout%25257E%25252F2006%25252Fwaf%25252Fwidgets-vmmf%25252FOverview.src.html%25253Frev%25253D1.2%252526content-type%25253Dtext%25252Fhtml%25253B%25252520charset%25253Diso-8859-1%2526filterValues%253Dform%2526nscheckmanual%253D%2526display%253Dall%2526recursive%253Doff%2526recurse_auth%253Don%26xslfile%3Dhttp%3A%2F%2Fwww.w3.org%2F2005%2F09%2Fchecker%2Fframe.xsl%26display%3Dall%26recurse_auth%3Don&uimode=checker_full&filterValues=form&year=2009&docstatus=fpwd-wd-tr&rectrack=yes&prevrec=none&patpol=w3c&normative=yes&doc_uri=http%3A%2F%2Fdev.w3.org%2Fcvsweb%2F%7Echeckout%7E%2F2006%2Fwaf%2Fwidgets-vmmf%2FOverview.src.html%3Frev%3D1.2%26content-type%3Dtext%2Fhtml%3B%2520charset%3Diso-8859-1&recursive=off&nscheckmanual=&display=all&recurse_auth=on

Marcin Hanclik

ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@...

________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Editing specifications with ReSpec.js

2009-08-05T16:55:05Z

Hi,

there are many tools meant to help with editing specifications, so I
won't write page upon page trying to sell you this one. It's
implemented in Javascript and therefore runs straight in the browser,
it has a few nifty features, and in general it scratches my itches.
I'm posting it here because I'm guessing that if I like it, others
might as well.

You can read more about it at:

http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

and in general poke around http://dev.w3.org/2009/dap/ReSpec.js/ to
see what it's made of.

Enjoy!

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

Re: WebIDL checker

2009-08-04T18:39:20Z

On Thu, 30 Jul 2009, Dominique Hazael-Massieux wrote:
>
> I have just released a simple on-line WebIDL checker:
> http://www.w3.org/2009/07/webidl-check It detects bugs in the WebIDLs it
> finds inside HTML documents - it looks for <pre> elements with a class
> set to "idl" or "webidl", and then validates what it extracts using
> Aplix' widlproc:
> http://widl.webvm.net/svn/widlproc/trunk/doc/widlproc.html

This is fantastic.

I have a small feature request. Would it be possible to have a mode
wherein the script returns an empty document if it parses the provided URL
without problems, and returns a text/plain document with one error per
line with line numbers reporting the errors if it finds any? That would
let me integrate this with my build tools and find errors as I make them.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'