- From: Robin Berjon <robin@robineko.com>
- Date: Thu, 6 Aug 2009 17:34:06 +0200
- To: <richard.tibbett@orange-ftgroup.com>
- Cc: <marcosc@opera.com>, <jmcf@tid.es>, <public-device-apis@w3.org>
On Aug 6, 2009, at 17:10 , <richard.tibbett@orange-ftgroup.com> wrote:
> Agree with Marcos. Any output of ReSpec.js should be saved statically
> (minus scripting) before publication.
Yup. Contrast for instance:
ReSpec:
http://dev.w3.org/2009/dap/ReSpec.js/test-spec/index.html
Saved snapshot:
http://dev.w3.org/2009/dap/ReSpec.js/test-spec/snapshot-as-html_source.html
The latter passes PubRules, the former will never get close. But I
know which source I'd rather edit :)
> I agree that Javascript is a good
> authoring system though - quite accessible and debuggable to the
> widest
> audience.
Agreed. In developing this the availability of FireBug has been
invaluable.
> This should apply to all types of spec drafts and if that
> output process could be automated (?) then even better. Is this what
> you
> had in mind Robin?
It's what I've implemented :)
> Summarising the problems: with JS I can't rely on a.) it being enabled
> in the browser, b.) element markup rendering correctly across all
> browsers c.) when saving the spec for offline reading, whether the JS
> files remain attached (w/ HTML5 offline apps - probably. Relying on JS
> being always attached in all other cases - probably not).
After processing is performed, ReSpec removes itself from the
generated spec, so it leaves no traces.
--
Robin Berjon
robineko — setting new standards
http://robineko.com/
Received on Thursday, 6 August 2009 15:35:36 UTC