173496 - validate actual page using W3C validator's file-upload

Status: RESOLVED WONTFIX

(SeaMonkey :: Page Info, enhancement)

Description

[Adam Hauner]

Page info should have button for actual page validation using W3C validator's
file-upload, futhermore it should have dialog for validation by several
validators (for HTML, CSS, accessibility). 
(Button should be disabled when user is offline.)

Idea by Ian in bug 47108.

Comment 1

[Adam Hauner]

*** Bug 173498 has been marked as a duplicate of this bug. ***

Comment 2

[Adam Hauner]

Peter Lairo's summary from duplicated bug 173498:

Need Button in the Page Info Dialog to upload the page to the HTML and CSS
validators.

This is a "compromise" bug spun off from bug 47108.

This way, users could press CTRL-i and press this "Validate webpage" button to
easily have a web page validated. The big advantage is that this would not cause
_any_ performance hit in Mozilla itself when displaying web pages. It would also
provide users an easy (yet unfortunately not discoverable) means of seeing that
it is a page and not Mozilla that is the cause of page display problems.

Comment 3

[Peter Lairo]

How about if the "Validate Page" button opened a _tab_ for each validator (HTML,
CSS, etc.)?

Comment 4

[Daniel Brooks [:db48x]]

how about the person who implements it picks the design?

Comment 5

[Hixie (not reading bugmail)]

Yeah, that's gotten us some great UI design so far hasn't it. </sarcasm>

Comment 6

[Daniel Brooks [:db48x]]

design by commitee is any better? Besides, I said 'pick' the design, not
necessarily 'design' it by himself. Anyway, I kinda like the idea, so lemme
think about it.

Comment 7

[Boris Zbarsky [:bzbarsky]]

confirming that this is being thought about.  ;)  (note that imo all the
suggested features are easily done as bookmarklets).

Comment 8

[Jesse Ruderman]

Three things that are hard to do with a bookmarklet: 
- validating a local page.
- validating a page on an internal network.
- validating a page that results form a form post.

Bookmarklets have access to the DOM but not the original source.  The browser,
on the other hand, usually has the original source available for things like
View Source and session history.

Comment 9

[J. Schreiber]

I have started a new project on http://checky.mozdev.org for validation and
checking web pages against different validation services. Perhaps you are
interested.

Comment 10

[Akkana Peck]

Composer has long had validation via the w3c validator pages.  If this is added
to the browser, I'd suggest trying to share code rather than having two separate
implementations of the same thing.

See nsValidateCommand in ComposerCommands.js for the existing composer
implementation.  The if (DocumentModified) CheckAndSaveDocument stuff should
happen only if we're editing, of course, so the logic would shift around a bit.

I always thought it would be better to make the validator url configurable
rather than hardwiring it, but never quite got around to it (and nobody ever
asked, so it wasn't a big deal).

There's one hitch for the local file case: there's a problem with the
notification, finding out when the page has loaded and then loading the file
picker field correctly.  It used to work, but a netlib change broke it and we
never found out the right way to solve the problem.  See bug 144604 (and more
history in its parent bug 71726).

Checky looks like it does lots of cool validation stuff.  If anyone does more
work on validation inside mozilla, either browser or editor, we should probably
work with Joachim and see if we can share code and ideas.  Maybe he's already
solved bug 144604. :-)

Comment 11

[J. Schreiber]

Yes I agree, sharing code is much better than re inventing the wheel.

A lot of mozilla plug-in projects (not only checky) implement a upload feature
for local files, mostly for W3C HTML and CSS.

I think validating files is not only a feature for composer, it's a good choice
to implement a validation module for mozilla so user can use it from browser,
mail, composer...... and as basis for firefox too.

Perhaps this validation module is extensible for new validation services and so
plug-in developers can extend the module (framework) instead of writing own
code. Perhaps this is a way to find validation service provider developing their
own plugs for mozilla.

The problem is not the hardcoding of the URL. The URL is not changing so often.
The problem are changing field names in the html forms of the validation
services. They change much more often.

On the web sites of the services you have a lot of choices to configure the
service before using. I realized that it is a must to have a interface inside
mozilla to configure these services without wrting URL's with params like

http://valid.org?ss=new&pp=4&kl=55&file=

this is a very bad usability. So the main work is not the URL, the main work is
to have a interface in mozilla to configure the service with all parameters to
combine them to a ready to go URL for the service. (see Checky).

or.... configuration is not so important, simple use the defaults of service and
no interface is needed.


The most important think I realized with Checky for most developers is NOT the
possibility to validate against one Service. This is not really a feature. I can
do it on the web site and there I have the posibility to configure everything
before vaidation, why using mozilla with default settings? The feature is to
combine different validation services and then fire all of them with one
keyboard shortcut. 

This is e.g. a use case for a developer who wants to check his complete work
before deploying to web: (my use case yesterday ;-)

HTML -> CSS -> P3P -> Bobby -> Cynthia -> Link Checker -> Search Engine
Simulator -> Meta Tag Analyzer -> Download Time -> ....


To bug 146404 :

No sorry I didn't solve the problem, determining when the W3C validator page
has loaded. In Checky you can choose a time in seconds Checky waits before
filling the form with the URL and submitting to the service. But this is not a
good approach this is simply a hack, but it's running.

I have one thing in mind but no time to check it:

For HTML pages: When a HTML page is completely loaded in mozilla the browser
fires the body onload event handler. per definition exactly then when the page
is completely loaded. (</body> or </html> is reached)) Perhaps we can catch this
event I don't know when mozilla fires this event: 
case 1: every time a document is loaded
case 2: every time a document is loaded but only if <body
onload="myExampleFunction()"> is defined.

If case 1 is true and the event is fired every time we can use it as identifier.
Just an Idea.

Comment 12

[J. Schreiber]

Attachment: interesting implementation for local file validation

I found a nice implementaion for a local file validation at
http://webdeveloper.mozdev.org . The attached method uses XMLHttpRequest() and
a small small hack but it seems working in mozilla and firefox.

Comment 13

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Philip Chee]

WONTFIX: See the following post in mozilla.dev.apps.seamonkey:
http://groups.google.com/group/mozilla.dev.apps.seamonkey/browse_thread/thread/722358827994743a/5b76454811bb342d