W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2009

Re: Editing specifications with ReSpec.js

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 06 Aug 2009 18:15:43 +0200
Message-ID: <4A7B01AF.1060202@opera.com>
To: richard.tibbett@orange-ftgroup.com
CC: robin@robineko.com, jmcf@tid.es, public-device-apis@w3.org

richard.tibbett@orange-ftgroup.com wrote:
>> On Thu, Aug 6, 2009 at 5:57 PM,
>> <richard.tibbett@orange-ftgroup.com>  wrote:
>>>> On Aug 6, 2009, at 17:16 ,
>> <richard.tibbett@orange-ftgroup.com>  wrote:
>>>>> My previous email crossed with yours, Robin :(
>>>> Such is the internet!
>>>>> So now I understand the process I would still suggest that
>>>> the specs
>>>>> minus JS applies to all drafts too.
>>>> You mean Editor's Drafts too? I think that would encourage
>> people to
>>>> not commit as often as they should, which is IMHO a bad
>> idea. The ED
>>>> drafts are mostly to help the WG work and communicate with its
>>>> community. Whenever there's a big difference between the
>> ED and the
>>>> latest published WD a new publication should be made in order to
>>>> reach a wider audience (you know, publish early, publish often ;).
>>> OK. Early and often is good and I agree automated snapshots will be
>>> difficult initially.
>>> Perhaps then ReSpec.js could check the browser environment on
>>> initialisation. If it fails whatever we need (e.g. it's not a
>>> supported/tested browser or e.g., Javascript is currently disabled)
>>> then it would leave a big red div at the top of the page
>> stating that
>>> 'this page is not rendering correctly...' and possibly why e.g.
>>> 'you're using
>>> IE6 and we only support these browser + versions...' or 'you must
>>> enable javascript'.
>>> Could be useful. Obviously, any snapshots generated and
>> this info gets
>>> removed (assuming the snapshots are created from a suitable
>> browser).
>>> I'm happy to add and play about with this in the ReSpec.js
>> if it's of
>>> interest.
>> Although useful, I don't think this is necessary. The CVS
>> server can be configured to always serve the "cooked" version
>> of the spec. This is how we work in Web Apps (raw=
>> Overview.src.html, cooked = Overview.html). It is very rare
>> the anyone but the editor sees the "raw" version of a spec
>> (no pun intended).
> This was primarilly intended for Early drafts and/or Editor's drafts,
> which as I understood, Robin did not want to snapshot (or "cook") before
> display to the DAP working group.
> If we are always serving the cooked versions of Early Drafts and/or
> Editor's drafts then forget this suggestion :-)

Yeah, only cooked version should ever be served. It gives editors a 
little bit of freedom too, as it allows them to check in raw drafts 
behind the scenes without spell-checking, or having completely finished 
parts, etc. without having to worry that people are reading those raw 

Kind regards,
Received on Thursday, 6 August 2009 16:16:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC