Re: IDL problem

Or an xpath expression?


On Thu, Sep 19, 2013 at 9:14 AM, Robin Berjon <robin@w3.org> wrote:

> 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
>



-- 
Shane P. McCarron
Managing Director, Applied Testing and Technology, Inc.