- From: Robin Berjon <robin@w3.org>
- Date: Thu, 19 Sep 2013 16:33:40 +0200
- 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