<img alt="Example InitialCoords - SVG's initial coordinate system"
src="//afs/w3.org/pub/WWW/TR/2003/REC-SVG11-20030114images/coords/InitialCoords.png"
width="300" height="100"/>
Sorry to be blunt, but frankly I'm just amazed that this "live
re-styling" was allowed and didn't require some sort of approval by
the chairs.
Jeff
On Wed, Oct 14, 2009 at 7:42 PM, Jeff Schiller <codedread@gmail.com> wrote:
> I'm going to echo Robin's "surprise" here. Â I did not expect to have
> problems with specs because the W3C website design changed. Â Websites
> are different than technical specifications. Â One is fluid, the other
> is not expected to be, especially after the specification has been
> released. Â I will also echo Robin that specification re-styling should
> have been done in a sandbox somewhere, then reviewed with each WG,
> then released.
>
> On the one hand, thank you for restoring http://www.w3.org/TR/SVG11/
>
> On the other hand, http://www.w3.org/TR/SVG11/coords.html (for
> instance) is missing all of its images. Â This is just the first thing
> I noticed.
>
> I hope the web team can "power through" all these changes as quickly
> as possible so that W3C doesn't lose credibility.
>
> Regards,
> Jeff
>
> On Wed, Oct 14, 2009 at 11:52 AM, Robin Berjon <robin@robineko.com> wrote:
>> Hi Ian,
>>
>> On Oct 14, 2009, at 18:28 , Ian Jacobs wrote:
>>>
>>> We had a beta test period for some time. Going live was intended to get
>>> more feedback (which is happening).
>>> We will fix things as we go. If the new templates prove unfixable, we'll
>>> remove them.
>>
>> I do not question that that approach is right for the general site;
>> requirements for standards are different though. Cool standards don't change
>> under your feet. I strongly urge the Team to consider things that live under
>> /TR/ as being a completely different use case and a largely different crowd
>> than the rest of the W3C website.
>>
>> And if you do insist on running live tests inside TR, why run them on the
>> stable, important documents and not on unstable and less important ones?
>> Presumably, their formatting requirements are the same, while the impact of
>> issues is lesser.
>>
>>> We've kept the previous documents available at their original URIs. We
>>> have new URIs for the reformatted specs. So people who wish to refer to the
>>> dated spec can continue to do so. The "latest version" URI takes you to the
>>> reformatted versions.
>>
>> At the very least would you consider switching that around so that the
>> latest version would point to the latest version that actually reached
>> consensus in the WG in charge of publishing them and was endorsed by the
>> Membership? A lot of resources out there point to the latest version instead
>> of the dated one (as does Google in most cases).
>>
>>> Instead, I ask your patience while we fix bugs (which one should expect
>>> during a significant upgrade such as this one). If you need the stable
>>> previous specs in the meantime, those URIs still work.
>>
>> I am more than happy to be patient and to help out with the creation of new
>> templates. I merely ask that we don't play Russian roulette with documents
>> that worked and that are widely referenced. I am somewhat surprised (to put
>> it nicely) that the same organisation that deliberately inflicts dated URIs
>> upon the world would toy with the product of consensus so carelessly.
>>
>>> On the question of "google on every page" we discussed this issue quite a
>>> bit. We certainly don't have the resources to write our own search engine.
>>> And offering N search options to users (in a gesture to be more neutral) is
>>> not really a service to users. We talked to google about dropping their logo
>>> requirement and they let us know that that would not be possible.
>>>
>>> Regarding twitter and identi.ca, we are already using 2 rather than one.
>>> If we end up setting up our own microblog service at W3C, then we might
>>> promote it instead. But all of that would require more resources than we
>>> have currently allocated.
>>
>> Again, the general website and the specifications are different things. I'm
>> perfectly happy with those things in the general site. I would be happy with
>> ads on the general site â€” that'd make the W3C some useful money.
>>
>> The specifications, on the other hand, are authority documents. I have
>> absolutely nothing against Google, but W3C specifications aren't Google
>> specifications. There is enough confusion in the community already about who
>> drives what.
>>
>>
>>> I prefer to keep going and work out the bugs. The advantages of the new
>>> templates for TRs include:
>>>
>>> * integrated into the rest of site
>>
>> I think that's a bug. Specifications aren't pages just like other pages in
>> the site. We shouldn't be trying to give the impression that they sit on the
>> same level, which is what the current layout does.
>>
>>> * status section has been moved down so people can begin reading more
>>> quickly
>>
>> I'm not convinced that that's a good change either â€” see other thread in
>> chairs@.
>>
>>> There are some challenges in ensuring we don't break formatting; we will
>>> continue to investigate and fix those.
>>> If this experiment does not bear fruit, we will roll back.
>>
>> Is there at least a date at which we plan to make a call as to whether the
>> experiment was a failure or not? Is there a process of any sort telling us
>> who's making the call and who we can appeal to? Is there any plan to engage
>> and involve the people who actually write the specifications? The people
>> writing specification production tools?
>>
>>> But given the largely positive feedback we've received, I'd like to keep
>>> plugging ahead for a short while.
>>
>> Positive feedback on the site in general should be taken separately from
>> feedback on the specs, I hope.
>>
>> --
>> Robin Berjon
>> Â robineko â€” setting new standards
>> Â http://robineko.com/
>>
>>
>>
>>
>>
>