W3C home > Mailing lists > Public > spec-prod@w3.org > July to September 2013

ReSpec UI ideas (was: IDL problem)

From: Robin Berjon <robin@w3.org>
Date: Thu, 19 Sep 2013 16:33:40 +0200
Message-ID: <523B0B44.5010402@w3.org>
To: shane@aptest.com
CC: Shane McCarron <ahby@aptest.com>, "spec-prod@w3.org Prod" <spec-prod@w3.org>, Richard Ishida <ishida@w3.org>
On 19/09/2013 15:52 , Shane McCarron wrote:
> I wasn't aware you were planning on a new GUI . I think that's a good
> idea. But a simple error checking module that runs very early and just
> halts processing is what I was thinking of.  Force the errors to be
> fixed right away.

I don't think that it's realistic to do checking upfront for the whole 
language. To begin with, it's poor design because it means that the 
checking module will have to know about everything that the other 
modules know, which in turn means that many changes to the latter also 
need to be reflected in checking.

What we can do however is make it a lot easier to catch errors.

The new UI idea is this: put a small pill at the top right that by 
default just says "ReSpec" and has a small thingie to open a drop down.

Whenever a module encounters an error, it signals it to the central 
event hub (that's pretty much *already* the case). The UI module would 
simply listen to error events, and when there's an error it would show a 
little red sign in the ReSpec pill, which would show the errors when 
pressed (likewise warnings).

Individual modules can do a better job at detecting errors (and an even 
better job at producing warnings), but once we have the basic system 
above wired in it's easy to upgrade them one by one. It's also 
relatively easy (at least for non-async code) to catch JS errors in the 
global runner and expose them there.

The UI module would also become the place to hang saving operations 
from. This would make it easier to add support for FileSaver and/or <a 
href="data:the_whole_generated_page" download="Overview.html">.click() 
as better ways to save, or saving the output straight to GitHub (I 
chatted with the guy behind GitHub Books, that's what he does).

It would also be possible to hang further linting that doesn't naturally 
belong in a module and can afford to be slower. This can include 
submitting the generated spec to the validator(s), perhaps even to 
pubrules or the link checker. And WebIDL checking, referential integrity 
checking, spell checking...

In order to avoid bloating ReSpec with UI modules, only the very core 
bit would ship with it; the rest can be dynamically loaded on demand 
(which is a minority of cases).

Currently, you can override configurations by appending to the query 
string (notably, you can enable tracing by passing trace=true) which is 
powerful but not super convenient. The UI could also enable that in a 
user-friendly manner.

Of course, the above can't easily all be done at once. But I reckon that 
with just the basic UI and the hooks for extra modules to work with it, 
we could build this in (many) steps.

> Honestly if web browsers had done that to html from
> day one the internet wouldn't be such a mess.

No no no, let's not go there :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 19 September 2013 14:33:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:19 UTC