- From: Jeff Schiller <codedread@gmail.com>
- Date: Wed, 14 Oct 2009 19:51:44 -0500
- To: Ian Jacobs <ij@w3.org>, site-comments@w3.org
- Cc: chairs@w3.org, Robin Berjon <robin@robineko.com>
In case it isn't immediately obvious, the src of that <img> should be: src="images/coords/InitialCoords.png" from what I can tell (at least that's what my offline copy has). Thank god I saved this specification locally long ago. Regards, Jeff On Wed, Oct 14, 2009 at 7:48 PM, Jeff Schiller <codedread@gmail.com> wrote: > <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/ >>> >>> >>> >>> >>> >> >
Received on Thursday, 15 October 2009 00:52:19 UTC