No more "HTML5 Nu Validator"?

[matatk]

When I try to validate a page with either of the Nu Validator HTML5 options, I get a page, generated by the Nu Validator, with the following message on it:

IO Error: c.validator.nu

Could it be that the separate HTML5 mode has been retired now HTML5 is a recommendation?

[matatk]

I gather @menovak cannot reproduce this -- @stevefaulkner do you get this error in the latest WAT release?

[matatk]

There seems to be something wrong with referring to this host as the validator; it doesn't seem accessible to me:

➜  ~ host validator.nu
validator.nu has address 46.226.110.49
validator.nu mail is handled by 10 spool.mail.gandi.net.
validator.nu mail is handled by 50 fb.mail.gandi.net.
➜  ~ host c.validator.nu
Host c.validator.nu not found: 3(NXDOMAIN)

I don't know why it is accessible to @menovak but not me, but it looks like we should be using the main host instead of the subdomain?

[menovak]

I would ask Steve again or others in the group, I do not seem to have the
same issue you do, sorry not sure what else to try.

On Mon, Dec 22, 2014 at 5:59 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

There seems to be something wrong with referring to this host as the
validator; it doesn't seem accessible to me:

➜ ~ host validator.nuvalidator.nu has address 46.226.110.49validator.nu mail is handled by 10 spool.mail.gandi.net.validator.nu mail is handled by 50 fb.mail.gandi.net.
➜ ~ host c.validator.nu
Host c.validator.nu not found: 3(NXDOMAIN)

I don't know why it is accessible to @menovak https://github.com/menovak
and not me, but it looks like we should be using the main host instead of
the subdomain?

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

@menovak what do you get when you run the same commands on your system? (The Windows equivalent command is nslookup instead of host.)

@stevefaulkner: if you're reading this, could you try the same please?

Either way, it does seem that we need to get this changed somehow, as Shirley I can't be the only person in the world who can't access that host?

[stevefaulkner]

@matatk yes i get same error when i use (as html5) options, suggest that this option is not needed in the wat, just have the w3c nu validation service function (and same with open in new window)
While we are on subject the label needs to change to 'W3C Nu Markup Checker'

[matatk]

Sounds fine to me; I guess the latest checker does all dialects anyway. I suggest that we assign this to @menovak and also ask @jun325 to remove the corresponding code, which appears to be in the DLL file (it is referenced from Translation.ini).

[menovak]

just so I am clear, are we removing both the W3C Nu Validation Service (as
HTML 5) and W3C Nu Validation Service (as HTML 5 - new window) as options
-and - what label(s) is/are changing to ""'W3C Nu Markup Checker'""
???

On Mon, Dec 22, 2014 at 10:18 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

Assigned #44
#44
to @menovak https://github.com/menovak.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[stevefaulkner]

@menovak
W3C Nu Validation Service = W3C Nu Markup Checker
W3C Nu Validation Service (new window) = W3C Nu Markup Checker (new window)

yes :)

[matatk]

I am experiencing a problem with the new Nu Markup Checker...

• If I use the "new window" one, it works as expected: the current tab stays there and a new on is opened, containing the results.
• If I use the "normal" one, it replaces the current tab with the results, but also opens two new tabs containing the results.

IE11, Win 8.1

[ghost]

If the frame is used, some windows are opened.

Please confirm the WAT command in the traslation.ini.
The "nu_auto_m"(and w3c_html_m) command validate only the mainframe.
The "nu_auto"(and w3c_html) command validate all frames.

[menovak]

hi Jun

In the Accessibility_Toolbar.xml file, the two remaining menu validate
choices are:

Which translate to in the Translation.ini file

validatorNU=nu_auto
validatorNU_m=nu_auto_m

So if I understand correctly, the "validatorNU" should be changed to
"validatorNU_m" to only trigger validation on the main page, not any
additional frames?

Regards,

Mark

On Thu, Jan 15, 2015 at 2:10 AM, Jun notifications@github.com wrote:

If the frame is used, some windows are opened.

Please confirm the WAT command in the traslation.ini.
The "nu_auto_m"(and w3c_html_m) command validate only the mainframe.
The "nu_auto"(and w3c_html) command validate all frames.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[ghost]

@menovak yes if you don't want the validation of other frames

[matatk]

My understanding (probably wrong) was that the whole code of the page (including content of iframes) would be POSTed (i.e. via HTTP) to the validator and checked as one page. It sounds, from @jun325, like each iframe actually has to be validated separately.

We should definitely validate all of the page content, but currently it's confusing as to why all those tabs open -- though documentation is the answer to that perhaps.

The main problem I am having is that one of those tabs that's opened seems to overwrite the current one (I would like the current page to stay as it is, and then an extra tab/tabs open to show the validation results). When only one extra tab opens to show validation results, it works just fine, but when more than one tab opens to show validation results, it seems to overwrite the original page's tab.

[menovak]

Thanks Jun.

Matt, assume you are following this thread, so we need to add an item to
make this simple change to the Accessibility_Toolbar.xml file, if we do not
want to validate other frames.

Mark,

On Thu, Jan 15, 2015 at 10:03 AM, Jun notifications@github.com wrote:

@menovak https://github.com/menovak yes if you don't want the
validation of other frames

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[menovak]

hi Matt,

Opening in a new window is also an easy fix, again a simple change to the
Accessibility_Toolbar.xml file.

Perhaps something added to the documentation as to the difference then
would be appropriate?

Mark

On Thu, Jan 15, 2015 at 10:08 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

My understanding (probably wrong) was that the whole code of the page
(including content of iframes) would be POSTed (i.e. via HTTP) to the
validator and checked as one page. It sounds, from @jun325
https://github.com/jun325, like each iframe actually has to be
validated separately.

We should definitely validate all of the page content, but currently it's
confusing as to why all those tabs open -- though documentation is the
answer to that perhaps.

The main problem I am having is that one of those tabs that's opened seems
to overwrite the current one (I would like the current page to stay as
it is, and then an extra tab/tabs open to show the validation results).
When only one extra tab opens to show validation results, it works just
fine, but when more than one tab opens to show validation results, it
seems to overwrite the original page's tab.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

I just want to recap what the actual issue(s) are here, before we make any changes...

• When a page, in a tab, that does not contain any iframes is validated, the correct behaviour occurs -- the validation results appear in a single new tab.
• When a page that has iframes is validated, then...
  • a tab appears to be opened for each iframe's validation results (which we need to confirm and document)
  • the tab containing the original page appears to be overwritten by one of the validation report tabs -- this is definitely a bug, as the results should all appear in new tabs.

So we have two things to fix: one is a matter of documentation and another seems to be a bug, but I'm not sure if it's a bug in the DLL or in our the scripts (I guess it may be a bug in the DLL, as that's where the function that calls the validation service lives?)

[menovak]

hi Matt,

What we currently have is:

A. If you select W3C Nu Markup Checker it
1 - validates the main page and any iframe(s) if finds
2 - places results in the same open tab window as the page being validated,
and opens any new tabs for iframe(s) it finds

B. If you select W3C Nu Markup Checker (new window) it
1 - validates the main page ONLY
2 - places results in a new tab window

There are no bugs, this behavior is doing what the menu selections are
telling it to do. If you don't like this behavior, and want to call that a
'bug', that is fine.

We can change A above to open in a new tab window as B does, and it would
do so and also still open yet more tab windows should it find any
iframe(s). To make that change is a simple change to the
Accessibility_Toolbar.xml file.

If we 'always' want to validate the main window and any iframe(s) found,
and 'always' want that output in a new tab window, then I'd suggest we not
have two choices, and add 'new window' to A above, and remove the B menu
choice. I'd be hesitant to do that, however, as I suspect there once was a
reason to allow for not having to validate any iframe(s), but perhaps that
is no longer an issue.

I was suggesting some documentation to alert users to the difference in
what is validated should we leave both menu options...

Note, as it currently works, if there are no iframe(s) found, then the
validation results are the same, just the output is placed in different
windows.

Does that help?

Mark

On Thu, Jan 15, 2015 at 11:02 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

I just want to recap what the actual issue(s) are here, before we make any
changes...

• When a page, in a tab, that does not contain any iframes is
  validated, the correct behaviour occurs -- the validation results appear in
  a single new tab.
• When a page that has iframes is validated, then...
  • a tab appears to be opened for each iframe's validation results
    (which we need to confirm and document)
  • the tab containing the original page appears to be overwritten by
    one of the validation report tabs -- this is definitely a bug, as the
    results should all appear in new tabs.

So we have two things to fix: one is a matter of documentation and another
seems to be a bug, but I'm not sure if it's a bug in the DLL or in our the
scripts (I guess it may be a bug in the DLL, as that's where the function
that calls the validation service lives?)

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

Aha, this is interesting… I do not get the behaviour you described. The DLLs have just been updated to allow Translation.ini to support UTF-8. I wonder if this may be related? Using the latest build (just uploaded to GitHub), I get the following behaviour on IE 11 when looking at the IE default home page: http://www.msn.com/en-gb/?ocid=iehp

Using “W3C Nu Markup Checker”:

• The current page tab is not overwritten.
• Many — seemingly infinitely many — new tabs are opened for Nu Validator results pages. I have to forcibly quit IE.

Using the “W3C Nu Markup Checker (new window)”:

• The current page tab is not overwritten.
• Only one other tab appears (tab, not window).

Maybe there’s an option in IE for opening new windows as tabs — this is now a default in most browsers, so maybe IE is following suit.

[menovak]

hi Matt

1 - you sure pick 'interesting' sites for review, note, this site has at
least 8 iframes. , but it is dynamically changing so I would not
swear to that

2 - when I said a 'new tab window', that is the same as you saying 'tab
appears (tab, not window)"

Using my last build: (Win 7, IE 11, comments in bold below)

Using “W3C Nu Markup Checker”:

• The current page tab is not overwritten. -> my current page tab is
  overwritten as expected
• Many — seemingly infinitely many — new tabs are opened for Nu
  Validator results pages. I have to forcibly quit IE. 0-> my WAT opens
  8 new tab windows, one for each iframe as expected (had to be very patient
  to be sure the page was loaded before checking it)

Using the “W3C Nu Markup Checker (new window)”:

• The current page tab is not overwritten. -> same
• Only one other tab appears (tab, not window). -> same as my new tab
  window

Can you look at your copy of Accessibility_Toolbar.xml, line 24 and 25 I
have:

I suspect that your's got changed to the following, if the first check is
does not overwrite the current page:

Mark

On Thu, Jan 15, 2015 at 12:25 PM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

Aha, this is interesting… I do not get the behaviour you described. The
DLLs have just been updated to allow Translation.ini to support UTF-8. I
wonder if this may be related? Using the latest build
https://github.com/ThePacielloGroup/WebAccessibilityToolbar/releases/tag/2015-01-14a
(just uploaded to GitHub), I get the following behaviour on IE 11 when
looking at the IE default home page: http://www.msn.com/en-gb/?ocid=iehp

Using “W3C Nu Markup Checker”:

• The current page tab is not overwritten.
• Many — seemingly infinitely many — new tabs are opened for Nu
  Validator results pages. I have to forcibly quit IE.

Using the “W3C Nu Markup Checker (new window)”:

• The current page tab is not overwritten.
• Only one other tab appears (tab, not window).

Maybe there’s an option in IE for opening new windows as tabs — this is
now a default in most browsers, so maybe IE is following suit.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[menovak]

hi Matt

Just retested that IE home page, and found 12 iframes, so indeed it is
dynamically changing and perhaps not a good example? Just a thought...

Mark

On Thu, Jan 15, 2015 at 12:25 PM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

Aha, this is interesting… I do not get the behaviour you described. The
DLLs have just been updated to allow Translation.ini to support UTF-8. I
wonder if this may be related? Using the latest build
https://github.com/ThePacielloGroup/WebAccessibilityToolbar/releases/tag/2015-01-14a
(just uploaded to GitHub), I get the following behaviour on IE 11 when
looking at the IE default home page: http://www.msn.com/en-gb/?ocid=iehp

Using “W3C Nu Markup Checker”:

• The current page tab is not overwritten.
• Many — seemingly infinitely many — new tabs are opened for Nu
  Validator results pages. I have to forcibly quit IE.

Using the “W3C Nu Markup Checker (new window)”:

• The current page tab is not overwritten.
• Only one other tab appears (tab, not window).

Maybe there’s an option in IE for opening new windows as tabs — this is
now a default in most browsers, so maybe IE is following suit.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

OK, agreed re test page, but isn’t it odd that choosing the “(new window)” option doesn’t open all those extra tabs — it sounds like it should!

I’m now trying http://bbc.co.uk/ and I find the same behaviour as I described above, but the page only appears to have itself and one iframe, so when I use the ‘normal’ checker, I get two validator tabs (one which overwrites the BBC home page). But when I use the “(new window)” checker, I get only one extra tab. One is missing, then? Sounds like an off-by-one error in the DLL?

Here’s the XML file, seems it has an extra line, but otherwise seems correct: https://github.com/ThePacielloGroup/WebAccessibilityToolbar/blob/2015-01-14a/wat/Accessibility_Toolbar.xml#L25 (at the time of writing, this is the current version on master, too).

[menovak]

I think what is more interesting, but also somewhat expected, is that you
get different content and format served to you, than I do. I just loaded
up 'http://bbc.co.uk/' and I get a site with 6 iframes (as tested by
WAT:Frames).

""OK, agreed re test page, but isn’t it odd that choosing the “(new
window)” option doesn’t open all those extra tabs — it sounds like it
should!""

• we can make the 'new window' version test all the iframes, and it would
  open as many tabs (windows) as if finds iframes.

its not an 'off by one error in the DLL', two different functions are being
called, one ONLY validates the main page, the other validates the main page
and all iframes.

On Thu, Jan 15, 2015 at 2:05 PM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

OK, agreed re test page, but isn’t it odd that choosing the “(new window)”
option doesn’t open all those extra tabs — it sounds like it should!

I’m now trying http://bbc.co.uk/ and I find the same behaviour as I
described above, but the page only appears to have itself and one iframe,
so when I use the ‘normal’ checker, I get two validator tabs (one which
overwrites the BBC home page). But when I use the “(new window)” checker, I
get only one extra tab. One is missing, then? Sounds like an off-by-one
error in the DLL?

Here’s the XML file, seems it has an extra line, but otherwise seems
correct:
https://github.com/ThePacielloGroup/WebAccessibilityToolbar/blob/2015-01-14a/wat/Accessibility_Toolbar.xml#L25
(at the time of writing, this is the current version on master, too).

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[stevefaulkner]

It has always been the case that running the checking tools will overwrite the current page with the results. The new window (now really new tab option) has always left the original page in current tab and opened results in a new tab (if pages contained (iframes) in new tabs.) Sounds like @matatk does not like the overwriting bit. I am OK with having 2 options
test main page (oepns in new tab)
test main + iframe (opens in new tabs)

What would be nice if we could have all results included in one new page with results being included in multiple iframes, which would overcome the annoyance of many tabs opening.

[matatk]

@menovak I'm not choosing good test sites, sorry -- US version will be different, d'oh!

@stevefaulkner I agree with all that you've said, except there is still a bug here -- if you try the BBC site, I believe you'll see that...

• when using the 'normal' validator option, it opens two results tabs (one over the top of the BBC site and one new one)
• when using the 'new window' validator option, it opens one results tab (leaving the BBC site as-is).

This seems to indicate that there is a bug (off-by-one error?) when using the 'new window' option.

So there are potentially two things to change here...

1. Fix the error that's causing the wrong number of results tabs to open.
2. Have a new results scheme where all the results are included in just one tab, possibly using an expand/collapse set-up to help users navigate them.

If we can confirm that there is an off-by-one (or similar bug) then I think we'd need @jun325 to fix it. However I think myself and/or @menovak should implement the new results scheme (as we have all the kit to test it to ensure it's accessible).

Does this sound OK? First step is: can @stevefaulkner confirm the difference in number of tabs opened when testing the BBC site.

Also if someone could find a test site that has at least one iframe and is the same worldwide, so all of us get the same code, that would be great :-).

[menovak]

hi Matt and Steve,

I don't believe we are 'off by one', I think the two different functions
are working as designed. One validates only the main page, the other
validate the main page and any iframes it encounters.

I also prefer to leave as is, two options... but add some documentation to
alert users that one option only validates the main page should they be
concerned about iframes.

Mark

On Fri, Jan 16, 2015 at 8:00 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

@menovak https://github.com/menovak I'm not choosing good test sites,
sorry -- US version will be different, d'oh!

@stevefaulkner https://github.com/stevefaulkner I agree with all that
you've said, except there is still a bug here -- if you try the BBC site, I
believe you'll see that...

• when using the 'normal' validator option, it opens two results
  tabs (one over the top of the BBC site and one new one)
• when using the 'new window' validator option, it opens one results
  tab (leaving the BBC site as-is).

This seems to indicate that there is a bug (off-by-one error?) when using
the 'new window' option.

So there are potentially two things to change here...

1. Fix the error that's causing the wrong number of results tabs to
   open.
2. Have a new results scheme where all the results are included in
   just one tab, possibly using an expand/collapse set-up to help users
   navigate them.

If we can confirm that there is an off-by-one (or similar bug) then I
think we'd need @jun325 https://github.com/jun325 to fix it. However I
think myself and/or @menovak https://github.com/menovak should
implement the new results scheme (as we have all the kit to test it to
ensure it's accessible).

Does this sound OK? First step is: can @stevefaulkner
https://github.com/stevefaulkner confirm the difference in number of
tabs opened when testing the BBC site.

Also if someone could find a test site that has at least one iframe and is
the same worldwide, so all of us get the same code, that would be great :-).

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

From re-reading the thread and looking at the code, I can see that the numbers of tabs are intentional and not an off-by-one error — sorry for ‘not getting this’ before. (There are also quite a lot of now-redundant lines in Translation.ini relating to the validators which, with some testing, and now that we have Translation.ini in a format git sees as text, it will be safe to remove.)

However, I find it very confusing that the options do two different things to each other — I would like results from the validation to always appear in a new tab. Then the only difference between the options would be that one checks only the main page and one checks all frames. Does this sound OK?

If so, in order to close this bug, I propose that:

• @jun325 ensures that both nu_auto and nu_auto_m open new tabs for the results, always leaving the page under test alone.
• I rename the menu options in the UI to…
  • ‘W3C Nu Markup Checker (main page only)’
  • ‘W3C Nu Markup Checker (main page and all frames)’
• I update the documentation.
• I remove the redundant lines from Translation.ini (and test :-)).

As we are perennially short on time, we should record @stevefaulkner’s good idea of including all the results in one tab as a separate enhancement issue for… later… :-)

[menovak]

Hi Matt,

""However, I find it very confusing that the options do two different
things to each other — I would like results from the validation to
always appear
in a new tab. Then the only difference between the options would be that
one checks only the main page and one checks all frames. Does this sound
OK?""

I'm OK with this .. to always have the results in a new tab..

""If so, in order to close this bug, I propose that:

• @jun325 https://github.com/jun325 ensures that both nu_auto and
  nu_auto_m open new tabs for the results, always leaving the page under
  test alone.""

We don't need Jun to do anything, I just tested with this change (see
below), and it opens in a new tab for both options (validating Main and
iframes, or just validating Main), , so all you need to do is edit line #24
in Accessibility_Toolbar.xml (was line 24 for me, your may be slightly
different, and add the window="new" part)

""

• I rename the menu options in the UI to…
  • ‘W3C Nu Markup Checker (main page only)’
  • ‘W3C Nu Markup Checker (main page and all frames)’""

Be sure you get them in the correct order, right now the first one on the
list does the main page and iframes, and the second one only does main page

""

• I update the documentation.
• I remove the redundant lines from Translation.ini (and test :-)). ""

Thanks for volunteering to update DOCS. PLEASE be careful removing items
from translation.ini, recall I had to replace a bunch of stuff to make
(remake) the luminosity checker work again...

""As we are perennially short on time, we should record @stevefaulkner
https://github.com/stevefaulkner’s good idea of including all the results
in one tab as a separate enhancement issue for… later… :-) ""

Agree, can make this change another time, as then the validator(s) would be
more like the changes I made, for example, to the 'list of images'
function, all in one tab.

Thanks

Mark

On Fri, Jan 16, 2015 at 10:10 AM, Matthew Tylee Atkinson <
notifications@github.com> wrote:

From re-reading the thread and looking at the code, I can see that the
numbers of tabs are intentional and not an off-by-one error — sorry for
‘not getting this’ before. (There are also quite a lot of now-redundant
lines in Translation.ini relating to the validators which, with some
testing, and now that we have Translation.ini in a format git sees as text,
it will be safe to remove.)

However, I find it very confusing that the options do two different
things to each other — I would like results from the validation to
always appear in a new tab. Then the only difference between the
options would be that one checks only the main page and one checks all
frames. Does this sound OK?

If so, in order to close this bug, I propose that:

• @jun325 https://github.com/jun325 ensures that both nu_auto and
  nu_auto_m open new tabs for the results, always leaving the page under
  test alone.
• I rename the menu options in the UI to…
  • ‘W3C Nu Markup Checker (main page only)’
  • ‘W3C Nu Markup Checker (main page and all frames)’
    • I update the documentation.
• I remove the redundant lines from Translation.ini (and test :-)).

As we are perennially short on time, we should record @stevefaulkner
https://github.com/stevefaulkner’s good idea of including all the
results in one tab as a separate enhancement issue for… later… :-)

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[matatk]

@menovak thanks for all that information. Also very-much noted with respect to the .ini file -- the good news is that from no on, we have Git on hand to make fixing any such problems easy (though I don't anticipate them this time; will test it a lot, first, too ;-)).

@jun325 looks like we do not need you to do any work on this one after all, thanks for putting up with this thread!