73105 - HTML/CSS validation shortcuts for browser

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Asko Tontti]

It would be nice to have menu entries to active HTML or CSS validation
for the page in the current browser window.

I made a patch which adds this feature to browser. Attaching soon...

PS. Should I assign this to myself?

Comment 1

[Asko Tontti]

Attachment: implementation for RFE

Comment 2

[Keyser Sose]

Adding correct keywords and marking NEW.

Comment 3

[Asa Dotzler [:asa]]

this sounds great.  I'd rather it was added to the QA or Debug menu though.

Comment 4

[Doron Rosenberg (IBM)]

I agree, should go to the QA menu.

as for adding to the contributors, i thought we were going to remove that and do
blame via bonsai/lxr

Comment 5

[Asko Tontti]

Why QA or Debug menu?

Aren't they removed from public when Mozilla goes to 1.0, or have I
misunderstood their meaning?

I cannot see anything common between Validate HTML/CSS and menu items in
Debug and QA menus.

Comment 6

[Doron Rosenberg (IBM)]

--> UI:DF

This is not a feature that needs to be in the main menus, it is not something
mose users will ever use.  However, it is helpfull for finding out if pages are
messed up or not.  The qa/debug menus will remain after 1.0, just probably not
used by netscape and others who will embedd moz.  

Comment 7

[Asko Tontti]

I understand your comments but my motivations for this feature and its
place in View menu are

 - to grow the people's awareness of standards, standard compliance and
   validation services
 - to offer a visible, easy and fast way for validating HTML/CSS so
   people will use it when they are building sites or pages and
   when they are browsing sites
 - View menu already have features: Page Source, Page Info, Translate.
   The validation feature fits in with them.

Why I don't like the idea of moving this feature to QA menu or Debug menu:

 - QA menu has only items relating to Mozilla's QA and seems to be
   done only for Mozilla's own QA people
 - Debug menu seems to be done only for testing Mozilla
 - the public ingores and will ignore QA and Debug menus

Comment 8

[Asa Dotzler [:asa]]

Asko Tontti, I think you're missing a fundamental piece of the puzzle here.  You
said "the public ingores and will ignore QA and Debug menus".  You are right. 
That public won't be using Mozilla.  They will be using Beonex or Netscape6 or
AsaZilla or some other _distribution_.  Mozilla provides binaries for testing
and development purposes.  Mozilla releases Milestones _with_ the QA and Debug
menus in tact for QA and Debugging.  If you are talking about an end user
feature like Edit|Copy or View|Reload then I don't think that this feature
should be implemented in the browser (maybe in the HTML Composer).  If you are
talking about a feature to help Mozilla testing and QA then I think it belongs
in the QA menu.

Comment 9

[Asko Tontti]

Yes, I really meant it for end user so that is why I put it to View menu.

Maybe I am not typical "end user" but I use validation services often
and I don't use Mozilla's Composer because I prefer Emacs :-)
Also it would be very slow to start Composer to check pages when I
browse my own or other's pages and sites.

But if you don't agree to include this feature to browser's View menu
I can move it to QA menu (for me it doesn't have relevance because
I will use Mozilla but for other's that would like this feature it
might have relevance).

I can include it to Mozilla's Composer if you think it would be nice to
be also there. If it is included to Composer, is View menu okay or what
menu would be better one?

And what I should do with that contributors section? 

Comment 10

[Asko Tontti]

Attachment: updated implementation

Comment 11

[Asko Tontti]

comments or r/sr needed.

Comment 12

[Matthew T (active 1999-2002)]

[--> XP Apps: GUI]

Comment 13

[Blake Ross]

Back to UI Design to figure out the best UI for this, because I don't think the 
menubar is the best place either.  Would it be weird to place this in Page Info:

Page Address: [ http://www.foo.com/ ] (_Validate Url_)

or some such (where _Foo_ denotes a link)?

Comment 14

[Matthew T (active 1999-2002)]

This should be implemented as part of bug 6211 -- a cheap way of doing error 
reporting, until we can display errors properly ourselves. And if we can't 
display errors properly ourselves by final release, then I think we should 
really ask w3.org for permission to link to their validator.

So basically we rearrange Navigator's status bar (which we were going to do 
anyway, remember, Blake?), something like the following:

+------------------------------------------------------------------+---+
| () Read 25 K of 168 K, 7 seconds remaining ...    [####):::::::] | n |
+------------------------------------------------------------------+---+

Now that () is an icon, which changes depending on the situation:
*   while doing proxy authentication/DNS on the server for the main resource,
    it's a globe with a magnifying glass over it;
*   while waiting for the server to respond, it's an hourglass;
*   while loading the page, it's a throbber (e.g. a spinning globe).

What concerns this bug, however, is the icon once the page is loaded:
*   if the page is valid, it's a blank page (maybe with a smiley face);
*   if the page has HTML/XML/CSS errors, it's a blank page which has been torn
    in two;
*   if the page has script errors, it's the traditional black exclamation mark
    in a yellow triangle with black border (this overrides the broken-page icon
    if the page has both HTML/XML/CSS and script errors).

Then, clicking (*once*) on the icon brings up an alert. (The wording I've shown 
probably wouldn't be the final wording, I just have an imagination failure at 
the moment.)

+----------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::::|
+----------------------------------------------+
| | .|  This page contains errors which may    |
| | 1|  cause it to display improperly.        |
|                                              |
|                                              |
|                       ( Details ) ((  OK  )) |
+----------------------------------------------+

Clicking `Details' takes you to the validator.w3.org validation for the page. 
Eventually, however, `Details' will display Mozilla's own list of errors with a 
superior UI to that provided by the W3C.

The above mini-spec was composed by a semi-conscious human and may be incorrect 
in some areas. Batteries not included. Check the in-store display for full 
details.

Comment 15

[Asko Tontti]

That's better idea than the page info dialog.

Comment 16

[timeless]

it's missing the filename, and it reminds me of Bugzilla Bug 47108 Hook up HTML 
quality indicator to status bar. otherwise it sounds good.

Ben: any comments before Asko starts working on this?

Comment 17

[chris hofmann]

any work happening on this bug?  if not lets unset the target milestone
and get a better estimate on when it might land.

Comment 18

[Asko Tontti]

Been busy. Trying to get it into mozilla 0.9.1.

Comment 19

[Asko Tontti]

due Hofmann's deadline for new features.

Comment 20

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 21

[Asko Tontti]

I have UI written (has been for some time) but there are some problems
getting information about errors from HTML and CSS parsers and JavaScript
engine. There are some hooks for error handlers but they don't seem to work.

Comment 22

[Blake Ross]

I seem to recall the editor team mentioning this recently...

Comment 23

[rubydoo123]

we are planning on adding an item to validate teh edited document against the 
W3C Validator

Comment 24

[mgueury]

It should be in the Task/Tools menu. This feature would be used very 
often by a lot of web page developers to know if their pages are
syntaxically correct. It is very usefull if you develop dynamic web
pages.

Also it would allow, for example, to see that the www.mozilla.org page has 
currently 2 mistakes...

Comment 25

[Christopher Hoess (gone)]

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

Comment 26

[rubydoo123]

removing myself from the cc list

Comment 27

[Ole Tange]

I would like to have a small light in the status bar that is gray if the webpage is not fully 
loaded, green if the displayed webpage conforms to any HTML-standard, yellow if the 
webpage almost conforms and red if there are serious errors.  
  
The test may simply be running the webpage through html-tidy and have tidy tell whether 
the page is OK or not. Warnings only may cause the yellow light. When clicking the light 
a new window will open with the output from tidy. 
  
The idea of sending the webpage off to the validator is not usuable for me: I have to 
validate some pages that are secret (generated customer data) so validation must take 
place locally. Also it is important for me to know that each and every page validates and 
it is very cumbersome to run the validator for each page. Therefore an automatic local 
validation of every page will be very useful.  
 
This is a minor expansion of mpt's idea. 
 

Comment 28

[M. Kristall]

I don't think lights are doable. This is because iCab already does that
(http://www.icab.de/img/screenshots/notab.jpg - the frowning smiley in the red
circle).
I too feel that external validation cannot be required (though maybe an option
-- "Hmmm... Mozilla says my pages are not valid... what does the W3C say?").

Maybe also a "corrected code" option (if possible)? Most bad nesting will have
no effect on the final result of the page, so automatically fixing this might be
useful (or at least something like "Syntax error (improper nesting): <b><i>some
text_</b>_</i> - assuming <b><i>some text</i></b>").

Comment 29

[mgueury]

Another idea.

The validation is not needed during the rendering of the page. Maybe
after, it could be done in background after that all rendering has been
done.

For example, what about running "tidy" or his library on the html 
received after that the page is rendered and then show an icon at the bottom
depending of the errors and warnings. Double-clicking on it would show the
list of the errors (and the maybe the HTML). 

Tidy is very good for that. And it would avoid to rewrite such code.
Depending of the integration, tidy could stay an external program and
just be called in the background. 

I prefer this solution a lot since a lot of validation website do not allow
to check intranet site. And a lot of people believe in tidy results.

Comment 30

[Robert Kaiser]

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 31

[Robert Kaiser]

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 32

[Robert Kaiser]

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 33

[Robert Kaiser]

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 34

[Robert Kaiser]

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 35

[Robert Kaiser]

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 36

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 37

[Karsten Düsterloh]

Extension fodder.