Re: IDL problem

On 19/09/2013 16:10 , Richard Ishida wrote:
> On 19/09/2013 14:52, Shane McCarron wrote:
>> 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.  Honestly if web browsers had done that to html from day one
>> the internet wouldn't be such a mess.
>
> What I think would be useful is an error message like PHP emits, at the
> top of the page, that would also break validation.

That's why I want a UI. But I also don't want to have a big ugly message 
at the top: a lot of the people who read specs are not the editor, and 
they shouldn't have to be pained. That said, it should be visually clear 
and noticeable by the people who need to know.

>  In the IDL case, for
> example, I only realised we had a problem when the TOC failed to appear
> - and to be honest I didn't even notice that for a while. It was only
> after checking the structure of the markup around the TOC location
> several times, that i looked in Firefox's browser console and got the
> tip that this might be IDL related. Then i had to figure out which of a
> couple of possibilities was the actual culprit. The firefox tool didn't
> even give me a useful line number - just pointed to a very long js line.

Yeah, and a line in the ReSpec code is unlikely to help anyway unless 
you're hacking on ReSpec itself. What you want is an error to be pointed 
at in the HTML source. Getting a line number might be painful, but 
giving a Selector (so that for instance you could find the document in 
the Firebug tree view) ought to be doable.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Thursday, 19 September 2013 14:14:17 UTC