First test of 9.02 Beta 2A

[MikeGale]

Hi,

I've just been away for a few days, so started testing Beta 2A this afternoon.

My observations follow.

The test was a batch file created before a site went live. The live site has a lot less pages (1 real page in fact) and several third party js files (which weren't previously checked, 'cause I won't touch them).

The changes I made involved altering the batch definition file using the tools provided (I usually generate the files using a code generator so this may be a new test for me). The changes involved removing a bunch of files, adding about 6 js files and adding in a couple of css files that are intended to generate errors.

This may seem an odd application so here's a quick summary. The site is an Ajax page, it is partially generated by ASPX (3.5), then is driven using jQuery to present (and remove) user choices depending on user input. Some items are populated using Ajax calls to a web service, validation is browser side and server side. When the data is "submitted" the questions disappear and a report is presented, on that same page (no callbacks). (In the background email documents are sent asynchronously to potential client and to back office...)

I suspect that there will be a growing number of these. I have found that with attention to detail (minimal database lookup, everything possible compiled, asynch. where you can...) the application performs really fast. (All my tests are within about 5000 km of the live server...) A lot of this cannot be easily tested (the page changes while live), which is another story that I won't address here.

Findings:

1) I was adding a URL to check (actually a js file). I switched away to check the name in explorer (Win 2003 machine) when I got back the "edit/create link for batch wizard" dialog was not on top. The batch wizard was unreachable (greyed out). I used alt tab and got it back and completed.

2) I got, as expected, a bunch of errors for the js files in the batch report. Unfortunately most content of the individual report pages was a copy of the first erroring page (a php page on a remote server reached by a redirect). The custom content was page name and time taken to analyse, i.e. nothing substantial. In other words I can't see the things that javascript lint picked up on any of those pages. On recheck I found that the add a UrL link dialog had inserted a different base address (site) to the one I was working with, so I imagine that what happened here was that when the lint found no file to analyse I got that incorrect error report.

3) I got a message about a "href='#'" on a page. This was put in because IE 7 (alone) needs it when an anchor is wired up by jQuery to link to someplace. Without it IE 7 doesn't generate an event on a click. The exception message doesn't mention this. It would be valuable to mention that in the message, especially where a growing number of people will face this issue with their Ajax applications. (I haven't tested that in IE 8 and probably won't until IE 7 has dropped off my radar.)

4) I had a "font face is probably illegal" message come up. The font face was defined in an "@font-face" declaration so was meaningful, in this case.

5) I got a marquee message. It said something like IE X+ does it but not NN4. On my last test of this (a while ago) I was surprised to see that (if I'm not mistaken) FF, Opera, Chrome and Safari; all now implement marquee. I recommend the message be updated to reflect the new situation. (I haven't seen this reported anywhere but presumably there is a growing number of sites using this functionality, which is now where it should be, in the browser!)

6) When I did automatic update check from 9.01 the "I'm checking" dialog stayed up for ever. I eventually found a way to kill the CSE process, at which point an update page appeared in the browser.

That's all for now.

Thanks for the great work you're doing with this tool.

[Albert Wiersch]

Findings:

1) I was adding a URL to check (actually a js file). I switched away to check the name in explorer (Win 2003 machine) when I got back the "edit/create link for batch wizard" dialog was not on top. The batch wizard was unreachable (greyed out). I used alt tab and got it back and completed.

Thanks! This should be fixed in the current BETA.

5) I got a marquee message. It said something like IE X+ does it but not NN4. On my last test of this (a while ago) I was surprised to see that (if I'm not mistaken) FF, Opera, Chrome and Safari; all now implement marquee. I recommend the message be updated to reflect the new situation. (I haven't seen this reported anywhere but presumably there is a growing number of sites using this functionality, which is now where it should be, in the browser!)

Updated.

Thanks for the great work you're doing with this tool.

Thanks for the report. I'll be looking into the other issues your brought up a little later.

[Albert Wiersch]

2) I got, as expected, a bunch of errors for the js files in the batch report. Unfortunately most content of the individual report pages was a copy of the first erroring page (a php page on a remote server reached by a redirect). The custom content was page name and time taken to analyse, i.e. nothing substantial. In other words I can't see the things that javascript lint picked up on any of those pages. On recheck I found that the add a UrL link dialog had inserted a different base address (site) to the one I was working with, so I imagine that what happened here was that when the lint found no file to analyse I got that incorrect error report.

I'm not sure I understand. Is there something that should be addressed in CSE HTML Validator for this issue or is it OK?

3) I got a message about a "href='#'" on a page. This was put in because IE 7 (alone) needs it when an anchor is wired up by jQuery to link to someplace. Without it IE 7 doesn't generate an event on a click. The exception message doesn't mention this. It would be valuable to mention that in the message, especially where a growing number of people will face this issue with their Ajax applications. (I haven't tested that in IE 8 and probably won't until IE 7 has dropped off my radar.)

I assume you are referring to:
[75] The "href" attribute specifies an internal link that may not be wanted. An internal link name should usually follow the # character, but it doesn't in this case. However, if the top of the current document is being referenced, then this message should be ignored because an internal link name is not needed.

What is your suggestion for an improved message?

4) I had a "font face is probably illegal" message come up. The font face was defined in an "@font-face" declaration so was meaningful, in this case.

To confirm, you think that this check should not be done for font family names in @font-face declarations? It seems that that should be the case.

6) When I did automatic update check from 9.01 the "I'm checking" dialog stayed up for ever. I eventually found a way to kill the CSE process, at which point an update page appeared in the browser.

Hmmm.. maybe there was a hidden window that wasn't appearing correctly so the application looked like it froze. Can you reproduce this?

Thanks!

[MikeGale]

I'll restate the js issue. (I haven't retested it.)

1) I had a series of pages one html with errors, several were js files which (accidentally) didn't exist. All I think URL links. The js followed the html in the batch validator list.

2) The html validated with errors as you'd expected.

3) The js all showed as errors. The details on the individual pages were copies of the html page errors. i.e. not the right thing at all.

4) The js error pages had some custom details like file name and time to validate (I think), so were not identical under a diff tool.

[MikeGale]

On the href # issue.

Add something like this.

It is sometimes necessary to add a # link so that IE will emit an event when clicking on an anchor (a tag), in such cases this message should be ignored.

[MikeGale]

On the @font-face issue.

When a name is declared in an @font-face some browsers then become aware of that font name and map it to the declared font.

(The real situation is more complex than that given that some accept eot fonts others ttf... If the developer knows what he is doing he wil have designed appropriately.)

So the name declared is now a legal (semi-legal...?) font name and should not be identified as unknown.

Put another way. The list of known font faces can be extended for individual pages.

[MikeGale]

On the update dialog. Yes I can reproduce it, or something very similar.

I just tried it again, this is the C version.

The checking for update progress dialog comes up. It runs for a long time.

I attempt to shut the dialog, no luck.

I attempt to shut CSE. It says exiting on title bar but doesn't exit. The progress dialog has gone.

I hit alt-Tab and get CSE back now with progress dialog on top back.

I kill CSE with Task Manager, which gives me a "not responding" message.

[Albert Wiersch]

On the href # issue.

Add something like this.

It is sometimes necessary to add a # link so that IE will emit an event when clicking on an anchor (a tag), in such cases this message should be ignored.

Thanks! The message now reads:
[75] The "href" attribute specifies an internal link that may not be wanted. An internal link name should usually follow the # character, but it doesn't in this case. However, if the top of the current document is being referenced, then this message should be ignored because an internal link name is not needed. Note that it is sometimes necessary to use href="#" so that IE will trigger an event when clicking on an anchor in an "a" tag, and in such cases this message should be ignored.

I will work on the other issues today.

[Albert Wiersch]

On the @font-face issue.

When a name is declared in an @font-face some browsers then become aware of that font name and map it to the declared font.

(The real situation is more complex than that given that some accept eot fonts others ttf... If the developer knows what he is doing he wil have designed appropriately.)

So the name declared is now a legal (semi-legal...?) font name and should not be identified as unknown.

Put another way. The list of known font faces can be extended for individual pages.

I think I've addressed this issue. I'd appreciate if you could test it out (and give it a little extra attention) in the next BETA (though probably be a "release candidate").

UPDATE: I emailed you a new DLL that you can try.

[MikeGale]

Hi,

Thanks for the DLL.

I applied it and it fixes the issue.

Thanks very much.

I tested a css which has a related issue, which is not fixed.

This other css uses @import. An @font-face in the import defines a typeface. I get the unrecognised face name message there.

[Albert Wiersch]

Thanks for the DLL.

I applied it and it fixes the issue.

Thanks very much.

I tested a css which has a related issue, which is not fixed.

This other css uses @import. An @font-face in the import defines a typeface. I get the unrecognised face name message there.

Great, thanks for checking. CSE HTML Validator currently doesn't go into imported files like that so this is a current limitation.

However, you can program some additional font-family names to recognize and ignore using the configuration file and onConfigLoad() function.

[Albert Wiersch]

On the update dialog. Yes I can reproduce it, or something very similar.

I just tried it again, this is the C version.

The checking for update progress dialog comes up. It runs for a long time.

I attempt to shut the dialog, no luck.

I attempt to shut CSE. It says exiting on title bar but doesn't exit. The progress dialog has gone.

I hit alt-Tab and get CSE back now with progress dialog on top back.

I kill CSE with Task Manager, which gives me a "not responding" message.

Hello Mike,

I'm having trouble reproducing this. Could you have a firewall that is blocking HTTPS requests from CSE HTML Validator?

Also, if you have another computer, could you try it on that machine?

If anyone else is following this thread and using BETA 2B or 2C, is the Help->Check for Updates function working for you? Thanks!

[MikeGale]

Hi,

I won't dig into this today.

I'll bear it in mind should I manage to get some slack time.

An interesting thing is that I've not seen it before.

[Lou]

If anyone else is following this thread and using BETA 2B or 2C, is the Help->Check for Updates function working for you? Thanks!

Sorry for being slow.
Using Beta C (yes I finely figured out how to loaded it).

Help -> check for updates works as expected. Reasonable wait time given the latency of my link followed by the oh-key-doky box saying I'm using the latest Beta version 9.0196 etc.

[Albert Wiersch]

I'm not exactly sure why Mike was having the issue he was when checking for updates, but I've made some significant changes to the "check for updates" system that has resolved the issue (as confirmed by Mike). It now works in the background and also seems to be more reliable per Mike's testing.