47108 - Hook up HTML quality indicator to status bar (icon for notification of page errors)

Status: VERIFIED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Henri Sivonen (:hsivonen)]

Per comments in bug 41331 the parser can already give an overall opinion about the 
HTML quality. This bug is a feature request for adding the related indicator in the UI.

It would be nice to have an overall quality led even if bug 6211 (detailed error reporting) 
remains unfixed for the time being. Such a led would be important in putting the blame 
on the page instead of Mozilla when bogus HTML appears to "break".

Comment 1

[Matthew T (active 1999-2002)]

Blake, could you do the front end? RickG said he'd do the back end. This is 
important to move the user perception of blame for badly-rendered pages from 
Gecko to the page author.

We need an icon to the left of the progress bar in the status bar. It would be in 
one of four states:
* in progress (page with ellipsis)
* unknown (blank page)
* contains errors (page with dark red cross)
* apparently valid (page with dark green tick).

Comment 2

[Blake Ross]

sure...

Comment 3

[Blake Ross]

Any chance someone else could do these images?  I'm not all that good with 
image design...

Comment 4

[Matthew T (active 1999-2002)]

I can do some pretty piccies.

See also bug 47128.

Comment 5

[Tim Hill]

I can help out with this if I know what XPCOM interface exposes this status 
information to JavaScript...

Comment 6

[sairuh (rarely reading bugmail)]

qa: claudius, statusbarman....

Comment 7

[Blake Ross]

Reassigning to matthew to provide the images.  Send back to me when that's done.

Comment 8

[Henri Sivonen (:hsivonen)]

Attachment: Unknown status or loading

Comment 9

[Henri Sivonen (:hsivonen)]

Attachment: HTML OK

Comment 10

[Henri Sivonen (:hsivonen)]

Attachment: HTML no good

Comment 11

[Henri Sivonen (:hsivonen)]

I'm not Matthew, but I attached three placeholder icons anyway to let Blake start. 
(Combined unknow/loading. Couldn't make an ellipsis obviously visible at that size.)

Comment 12

[Blake Ross]

Thanks.  Maybe unknown could have a question mark?  

Comment 13

[Henri Sivonen (:hsivonen)]

I tried putting a question mark there. It didn't look good. It think neither x
nor check can serve as unknown. (The icons can't be taller than 12px. Else they
would block fixing the Mac status bar alignment with the window size box.)

Comment 14

[Matthew T (active 1999-2002)]

Attachment: template.png

Comment 15

[Henri Sivonen (:hsivonen)]

Clarifying: I think the blank icon with neither the x nor the check mark on it
can serve as "unknown".

Comment 16

[Matthew T (active 1999-2002)]

Blake, for now can you set this up using Henri's icons? They're pretty good.

Comment 17

[Nik Makepeace]

Attachment: HTML Bad

Comment 18

[Nik Makepeace]

Attachment: HTML Good - a more visible tick

Comment 19

[Nik Makepeace]

Attachment: HTML of unknown quality - not great but more IMO intuitive than a blank page, plus the question mark might get users to pay attention and learn a bit more about their new browser

Comment 20

[Nik Makepeace]

Here is a set of icons based on Henri's with Matthew's template.  The question 
mark isn't great, but an ellipsis is illegible and unintuitive, a clockface 
very hard to do legibly in 12px over the page template. There are better 
designers out there who can do it all again in due course, I imagine.

Comment 21

[timeless]

HTML bad is odd :-( how about a red document, or a red frowny face in a 
document? Or a wholed / distorted document.

To me x is more often _missing_ than failing

Comment 22

[Henri Sivonen (:hsivonen)]

Mozilla's XML parser is non-validating. The validity of a document parsed as XML 
(including XHTML) is unknown. Still, it wouldn't look good if Mozilla displayed a question 
mark for all XML documents. Mozilla should either display a blank icon or no icon at all 
for XML. (Note: Well-formedness alone shouldn't warrant an OK icon. The document can 
still be invalid and the user should see a more conspicuous error message if a document 
isn't well-formed.)

RickG,
Isn't it so that CNavDTD can't say for sure if a document is valid? But it can in some cases 
tell that the document is broken, right?

If that is the case, Mozilla shouldn't endorse any document as valid. It should only flag 
errors. Saying that an invalid (but not severely broken) document is OK, wouldn't be right.

Comment 23

[Michael La Guardia]

Marking nsbeta3- per PDT review.

Comment 24

[mw]

Attachment: More sample icons...

Comment 25

[mw]

Attachment: Actually, the file above was a PSD. Sorry for the spam :-/

Comment 26

[mw]

Here above are a couple of more icons, based on Henri Sivonen's great template. I
think they have "application-grade" quality ;-) They are in the order, from left
to right, Validation OK, Validation Failed, and Loading/Unknown. Except for the
top column, where the first two are switched... well, whatever.

Comment 27

[Cesar Eduardo Barros]

Hm, I think there should be three icons besides "loading" and "unknown":

- good page (green)
- deprecated features found (yellow)
- errors found (red)

So we could also warn on people using things that are needed just for
compatibility with 2.x (or people using HTML 3.0).

I think the icon should be not only for the page, but also for the http sessions
used to transfer it and its components, its components (marking .gif files as
'deprecated' would be nice...), and interactions between them (like a .js
referring to something that don't exist in the page).

I also believe we should use 'green' for 'looks good enough for me' (i.e. we
don't need to build a full validator, but only flag what we can check with
minimal work).

Clicking on the icon should open a dialog listing all the "errors" and
"warnings", with short explanations/links for the full explanations.

Yellow could also be used for "I don't know how to handle it" (layers, HTML5,
myfancyML embedded in XHTML, whatever), so the user knows mozilla isn't at fault
for the page not displaying perfectly.

Comment 28

[Doron Rosenberg (IBM)]

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

Comment 29

[Doron Rosenberg (IBM)]

blake - any work done on this?  I think this would be a cool feature, to scare
the living hell of webmasters who abuse html all around the world.

Comment 30

[Jesse Ruderman]

>Clicking on the icon should open a dialog listing all the "errors" and
>"warnings", with short explanations/links for the full explanations.

Right, because otherwise the feature would be nearly impossible to debug and 
nearly mpossible for webpage authors to use.

Comment 31

[Blake Ross]

Sorry for the delay everyone; I'll look at this next.

Rick, I notice in bug 41331, you said: "If UI folks want to reenable the UI, 
I'll hook up the reporting code."  Have you had a chance to do that?  Or can 
you tell me where I can find it?  It needs to be scriptable.

Comment 32

[Blake Ross]

So which set of icons do we want to use?

Comment 33

[Blake Ross]

And do we want to use the same set of icons in modern and classic?

Comment 34

[Blake Ross]

Let's see if I can successfully spam everyone one last time:

OK I just saw matthew's comments to use Henri's icons, so doing that now.

I also see that you said to put it to the left of the progress meter.  Are you 
sure?  My not-so-refined UI half is saying it should be to the left of the 
status text (which is where the `Click to display error' or whatever would be 
displayed).

Comment 35

[Jacob Steenhagen]

If Click to Display errors already has a place in the UI, I'd put it there...
otherwise I put it in the lower right corner (by the security icon)...
Disclaimer: My UI refinement level is quite low!!

Comment 36

[gary_Cope]

My feeling too is that these icons belong to the right of the progress meter.
That way there is an  ordering of connection-progress-document quality-status
that reflects the flow of the information.

I think the icons in the fourth row of mw's attachment reflect the html quality
best :green page icon -good ; red broken page icon -broken html ; partially
visible page icon-unknown/blank.

I too would like to see another icon -amber broken page, representing
deprecating features etc. 

Comment 37

[Matthew T (active 1999-2002)]

Assuming that the status text must be to the right of the icon (for a
left-to-right language), there are three options for the layout of the status 
bar.
1: [icon][progress bar][status text               ] (as I originally suggested)
1: [icon][status text               ][progress bar] (as in IE for Windows)
2: [progress bar][icon][status text               ] (as Gary suggested)

Each layout has its advantages and disadvantages. On reflection, the icon is more 
closely related to the status text than it is to the progress indicator, so my 
original suggestion (1) is probably not a good idea. And I think the icon needs 
to be in a corner of the window to avoid aesthetic problems in the status bar 
when the document is fully loaded, so (3) probably isn't so good either. So I 
recommend (2), which would also allow bug 47909 to be fixed without much visual 
disruption.

As for the icons, I think we can show an approving-looking icon to pages which 
Mozilla can find no errors in, without giving the false impression that the page 
is necessarily flawless (the simple dialog produced by clicking the icon would 
make this even clearer). As time goes on, as Web authors gradually fix their 
pages, and as implementation of bug 6211 becomes more sophisticated, we can 
gradually raise the bar on how good a page needs to be in order for us to show 
such an icon.

Comment 38

[rickg]

Henri: Sorry, I missed your question. The answer is, "it depends on what you 
mean by validating". If you mean "do we fail if the document is not well formed" 
the answer is no. If you mean "can we tell when a document is not well formed 
per a given spec" the answer is yes.

Comment 39

[Braden]

In the interest of sane communications, I suggest we all stick to the
definitions of "valid" and "well-formed" as given in the XML spec, and assume
that others are abiding by that as well.

Rick, could you clarify your comment, "If you mean 'can we tell when a document
is not well formed per a given spec' the answer is yes."? Since the XML spec
defines well-formedness, your use of "a given spec" makes me wonder if you're
talking about something other than well-formedness here.

Comment 40

[Henri Sivonen (:hsivonen)]

RickG: By "valid", I mean "valid" as used in the relevant specifications.

About XML: 
* Mozilla's XML parser isn't a validating parser. Mozilla cannot and should not make any 
claim about the validity of an XML document (including XHTML) documents
* Given that Mozilla cannot make a claim about the validity of an XML document, I am 
inclined to think that a quality indicator should either not be displayed or be in the 
undefined state for all text/xml content. (Well-formedness errors must be reported in a 
more conspicuous manner anyway.)

Questions about the HTML parser:
* There are different HTML versions. Does the HTML parser differentiate between them in 
its error reporting?
* If a document contains a syntactic error, is the parser always able to find and report any 
such error? If so, Which HTML versions are supported?

I think it is acceptable to signal an error when one is known to exist. However, indicating 
that a document is correct if no errors were found would be harmful unless the system is 
known to catch all errors. If Mozilla's HTML parser does not meet the criteria for a 
validating parser, then the term "valid" should, in my opinion, not be used in connection 
with an error reporting feature.

My point is that ((no errors found) implies (document OK)) if and only if (the parser always 
finds an error when one exists).

Comment 41

[Blake Ross]

Attachment: patch - add images to build

Comment 42

[Blake Ross]

Attachment: patch - add images and clean up tab hell

Comment 43

[Peter "jag" Annema]

r=jag, but get some input on whether to use png or gif.

I'm sure some people will veto the whitespace change... *sigh*

Comment 44

[Henri Sivonen (:hsivonen)]

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

Comment 45

[basic]

what is the status of this bug? How does it validate a document?

Comment 46

[Lasse Marøen]

Would it be possible to give the icon a tooltip text with additional
information, like "Valid HTML 4.01" or "XHTML 1.1 with errors"? 

Comment 47

[mmc]

I like the fourth row of icons in attachment id=15458.
Are you sure that we need an icon for a page in progress or unknown?
So if the parser of mozilla can give a validation ok or bad I'd like to see
the corresponding icon, and nothing in other cases.

Comment 48

[Gervase Markham [:gerv]]

So, what's the status on the back end for this? rickg?

Gerv

Comment 49

[Daniel Jensen]

Either Gerv didn't get his question answered, or people are tossing emails under
the table. I'd like to know- after all, if this is a 1.0 target, we ought to be
coming fairly close here...

Comment 50

[Arnoud Berendsen]

This thing has 44 votes, a patch that has r=, and has been around for almost a
year (!). Is that patch even valid anymore? Do we *really* want to wait for 1.0
to get this in with the possible risks of regression?

Comment 51

[nnooiissee]

my long standing comment to this (other than get it done! please!) is, why not
make clicking on the icon take you to validator.w3.org?

also, for those watching this bug, i don't think rickg is @netscape any longer,
so somebody else will have to do the back end.

Comment 52

[1984]

Yes a link to validator.w3.org
 would be great !

Comment 53

[Tim Powell]

The icon should link to a dialog (or page) that explains the quality indicator. 
That dialog/page could have a link to a validator. It should also let you look 
at a list of the page errors, perhaps with a expand widget. See bug 6211.

In any case, just having the quality indicator and status bar text that says 
something about it would be better than we have now.

Comment 54

[Henri Sivonen (:hsivonen)]

> This thing has 44 votes, a patch that has r=, and has been around for almost 
> a year (!). Is that patch even valid anymore? Do we *really* want to wait for 
> 1.0 to get this in with the possible risks of regression?

When I filed this bug, I thought the parser already had the back-end
functionality required for full error reporting. It appears that it is not the
case. I don't think it is realistic to expect Mozilla to get a HTML quality
indicator any time soon.

Those wanting validation from the UI may be interested in the bookmarklet
available from http://www.hut.fi/~hsivonen/test/validate.html (I have it in my
"Personal toolbar".)

Comment 55

[Daniel Jensen]

Seems to me that the proposed and unimplemented backends for this and for bug
6211 are largely the same. That bug depends on 65469 - CSS error reporting. I
think this ought to depend on that as well.

Comment 56

[Blake Ross]

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

Comment 57

[Jeremy M. Dolan]

The three icons from 9/11/00 are quite nice. Thanks nikm.

> Given that Mozilla cannot make a claim about the validity of an XML document,
> I am inclined to think that a quality indicator should either not be
> displayed or be in the undefined state for all text/xml content.

If Mozilla doesn't need a validating XML parser to display pages, then it
doesn't need one for purposes of alerting users to errors it's encountered. If
it misses some errors that would be fine. If it detects errors where it
shouldn't that would be a problem, but I don't think that's the case. We can let
developers know it's not a perfect indication of validity, but it's certainly
better then nothing. More and more pages are going to be XML... we mine as well
not add this at all if we're going to show a blank icon for all of those pages.
I assume there's eiather an unacceptable performance hit or question of
compatibility with web pages by validating as we parse?

Comment 58

[Kai Lahmann (is there, where MNG is)]

the icon should open a info-page with:
- rendering mode
- if there are other unknown tags or attributes (does Mozilla know if they are?)
- a Link to Validator
- DOCTYPE and if nothing not allowed in this is used
- wellformed or not

only if all 4 point say ok the user should get the green icon, red if the last
is not and in all other cases yellow.

Comment 59

[Bartosz Wucke]

Please make the icon optional/removable (through preferences) - For users often
everything making the text area in the statusbar shorter is annoying - less
space to read the destination URL.
Are the icons skin'able?

Comment 60

[Christopher Hoess (gone)]

It looks as if there's a space already between status bar and the online/offline
icon that could be used for this without infringing on the status bar. Is that
ever used for anything?

Comment 61

[Neil Marshall]

There are spaces for the progress meter, Online/Offline, Secure/insecure, and a 
space for the resize icon on a mac (IIRC).  There is also a place for a little 
cookie icon (Which I've never seen).

Comment 62

[Jonadab the Unsightly One (Nathan Eady)]

> Please make the icon optional/removable (through preferences) 
> For users often everything making the text area in the statusbar 
> shorter is annoying - less space to read the destination URL.

I think it should be enough to allow user CSS to display: none it.

> Are the icons skin'able?

They should be.  But (unless NS4 had an equivalent, which I 
don't seem to recall being the case), I think it's okay for 
Classic to use the same icons as Modern.  I agree with the 
twice-cited-already fourth row from the comment #25 attachment,
as well as the twice-stated-already comment that an additional
yellow or amber icon (like the green one, but not green) should
if possible be used for pages with deprecated features but no
errors detected per se.  Anything with colours in the body tag,
for example.  

Unfortunately, I _don't_ think it's reasonable to deprecate
GIFs; as much as I'd like to deprecate anything with lossy
compression or only 256 colours, I don't know that the W3C 
would back that.  I _do_ think it's reasonable to deprecate
versions of HTML prior to 4.0, as well as anything with no
doctype declaration.

Ultimately, I'd like to see non-ECMA-compliant Javascript
and incorrect DOM access in Javascript be flagged as an 
error, but I don't think that needs to keep the rest of 
this from going, if or when the HTML and XML stuff in 
the backend become available.  

Comment 63

[Rick DeBay]

In regards to comments 51 and 52, please allow more than one validator.
I've found that the validator at w3.org won't even attempt some pages,
and misses some errors.  Just like Mozilla ships with links to various search
engines, links to a couple of validators would be a good thing.
I nominate http://www.htmlhelp.com/tools/validator/ ,
http://www.htmlhelp.com/tools/csscheck/ and
http://bobby.cast.org/html/en/index.jsp for accessibility checks.  There are
almost no sites that can pass the later.

Comment 64

[Ken Harris]

Instead of adding Yet Another Preference, how about just displaying it only
when the text in the status bar is relevant to this page?  When you mouse
over a link that links to another page, don't display the icon.  (If you did,
you'd have the icon for this page right next to the URL for the the link's page,
which might make me try to associate the two.)

If it's only shown when the status bar says "Transferring data..." or
"Document: done (10 secs)", I don't think anybody would have a problem with
losing 10-20 horizontal pixels then.  How's that sound?

Comment 65

[Knud Sørensen]

You could also use happy and sad smileys.

Knud

Comment 66

[Hixie (not reading bugmail)]

We could just have

   Document: Done (1.2s)

...and

   Document: Done (1.2s) (with 5 errors and 2 warnings)

Clicking on that text would then bring up the console (it could be made to look
like a link). Just an idea.

Comment 67

[m_mozilla]

> Document: Done (1.2s) (with 5 errors and 2 warnings)


FWIW, I like the idea, but dislike the phraseing. I can hear it now:

    "sure mozilla's a nice browser, but it has errors trying
     to load 95% of the pages out there"

Maybe something like
    - found 5 errors and 2 warnings
    - this document has 5 errors and raises 2 warnings
    - the author of this page should fix 5 errors and 2 warnings

-matt

Comment 68

[Peter Lairo]

> Document: Done (1.2s) (with 5 errors and 2 warnings)

Unfortunately, the text will too quickly be gone once the user passes over
anything that causes new text to appear in the status bar.

I would prefer an icon (with descriptive tooltip) and a dialogue (when clicked).

Comment 69

[Aaron Kaluszka]

How about a tab under Page Info?

Comment 70

[Peter Lairo]

> How about a tab under Page Info?

I think the idea is to have the quality meter *always* visible. ;)

Comment 71

[Kelson]

> I think the idea is to have the quality meter *always* visible. 

Exactly.  If a random web surfer sees a broken page that works fine in IE,
they're not going to look in Page Info or see the status bar text that
disappeared the moment their mouse cursor passed over a link.  Unless there's an
*obvious* warning icon, they're just going to assume Mozilla sucks and go back
to IE.

Comment 72

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Also please note we don't want to give the impression that there were errors in
Mozilla, but errors in the markup of the page... ;)

Comment 73

[Mike Gratton]

peter, kelson, heikki; I think the idea is that when you click on the
error/warning icon, it brings up the Page Info dialog, open to a tab which
explains the errors/warnings.

The Page Info dialog *is* logical place to put the actual explaination and list
of errors/warnings.

Comment 74

[Marek Lugowski]

All interested in this bug should take a look at how
the German iCab the web browser handles this.
They make quite a big deal out of" making iCab smile,
cultivating links to a variety of pages that show a smiling
vs. impassive or frowning icon.  So they educate the user 
and draw the user into the game of crafting standard-supporting
web coding.

Clicking on the icon opens the report window where entries
are indexed by line number and icon as warnings or
errors.  Content of this singelton window change as you move
from page to page.  It's very well done and an integral part
of the browser's personality.

Instead of starting from nothing, we might want to
work with them on this; maybe give them credit
for the feature and take it up, make it even beter.

It's a Macintosh only web browser, but their website has a section
about it, and I think, screenshots.  http://www.icab.de/  

They also implement a great site navigation (link tags) 
toolbar.  The two features work very well together.
 

Comment 75

[Sascha Claus]

comment 73 (click on icon -> page info) is IMO a good idea - it's like the
security information and consistency is good. Another solution for the position
of the icon: If toolbar and urlbar are separated there's a lot of space in the
toolbar for a big, red icon, perhaps near the already colored Mozilla icon.

Comment 76

[Adam Tomlinson]

From what I can gather here, RickG said he would do the back end but has since
left netscape. So, does the bug need to be reassigned until the back-end is
finished? Does anyone know its status?

Comment 77

[Christopher Hoess (gone)]

If there was ever any back-end code for validation in the parser, it's long
since gone. This would require an extensive overhaul of htmlparser to implement.

Comment 78

[Esben Mose Hansen]

In this case we should IMHO design a mechanism/class to which a validation
results could be reported, first. Then we could easily add the capability to the
HTML (and CSS) parser in small iterations, thus eliminating the need for a major
overhaul.

Anyone care to come up with such a design? It should probably be a
consumer/producer thing --- sort of like the sink?

Comment 79

[Gervase Markham [:gerv]]

This doesn't necessarily require any parser support to do a lot of what's wanted.

The two most common problems are feeding Mozilla stuff with document.all and
document.layers. Doing both of these things puts errors on the JS console
("document.all undefined"). So it should be reasonably easy to make them also
change an indicator in the UI. You know immediately if it goes e.g. blue, that
document.layers is being used. And so on.

Gerv

Comment 80

[Mathieu Pillard [:mat]]

just me 2 cents :
its not enough. most of the sites down there are broke because of bad javascript
or css, not html.
we would need javascript errors to trigger that led, and maybe css too. errors
like text/plain mime type for css files should trigger it too...

Comment 81

[Adam Tomlinson]

Then would it be possible to add the front-end for the available parsing and add
more functionality as it becomes available? This bug has 92 votes and doesn't
seem to be going anywhere at the moment.

Comment 82

[Henri Sivonen (:hsivonen)]

First, I reiterate that when I filed this bug, I thought that the HTML parser
already had an error-reporting infrastructure. It doesn't.

Implementing this would require adding *correct* and *comprehensive* error
detection features to the HTML parser and then justifying the possible
performance hit to the module owner(s) and other interested parties.

Re: Incremental implementation
Adding reported error detection incrementally is potentially harmful. If the
hypothetical error detector didn't detect all errors, some authors would use
Mozilla as a justification for publishing bogus HTML and even bragging about it.
OTOH, once authors are bragging about correctness, they are known to become
angry if additional error check are added so that their page no longer passes.

Re: JS Errors
I think it would be good to show some problem indicator (which would open the JS
comsole when clicked) in the status bar whenever there are JS errors. It
wouldn't HTML quality indicator, but it would actually be implementable. :-) Is
there already a bug number for that?

Comment 83

[Braden]

> Re: Incremental implementation
> Adding reported error detection incrementally is potentially harmful. If the
> hypothetical error detector didn't detect all errors, some authors would use
> Mozilla as a justification for publishing bogus HTML and even bragging about
> it. OTOH, once authors are bragging about correctness, they are known to become
> angry if additional error check are added so that their page no longer passes.

I believe this is bogus. First of all, authors already do brag that their pages
display correctly in Mozilla, regardless of whether or not their pages are
actually correct. Second, these authors might, as you suggest, be angered by
*any* scheme that imposes more rigor than they are accustomed to.

I furthermore think it is simply wishful thinking that an error reporting
mechanism could be deployed in Mozilla without any bugs that impacted the
veracity and completeness of its reports.

The desirability of this feature is based on the notion that authors care about
correctness and want a convenient way of verifying it. mozilla.org either cares
about that or it doesn't. I do not believe it is possible to earnestly pursue
this feature *and* be concerned that adding it might piss some people off.

Comment 84

[Henri Sivonen (:hsivonen)]

The case I had in mind was validator.w3.org raising the bar by requiring the
character encoding to be declared.

Comment 85

[Adam Tomlinson]

I don't think there should be a problem with incremental implementation if the 
implementation is done right eg:

Document: Done (3 Errors Detected)

and on the page info tab an explanation that a proper validator should be used. 
The sites with some errors detected are more likely to have more errors anyway.

If at first the basic JS errors were added this might encourage website authors 
to properly validate their page (especially if we encouraged this somehow).

Comment 86

[Alfonso Martinez]

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

Comment 87

[Joe Pranevich]

Failing a full validation test of HTML/CSS/JS, etc. (which would require a
better error reporting infrastructure), can we do something with the information
that we already have? We already have two levels of "quirks"-mode rendering and
no obvious way to tell how a page is being rendered. (Is it in Page Info?) Could
we narrow down this feature to only report what mode the page was rendering in,
which would be an incentive for page maintainers to make the switch so that no
notification was given. This is not a complete validation, of course, just a
display of information we already have.

Is this a separate enough RFE that it merits a separate bug number? Short of a
lot of validation code, this may be a good compromise.

Note that comments #53 and #79 also give examples of things that Mozilla already
"knows" that could be relatively quickly implemented short of a full validator.

Comment 88

[Mathieu Pillard [:mat]]

no no no, rendering mode is already in page info. (which even gives you the
encoding, mime type, etc...)

Comment 89

[PTRourke]

Attachment: Idea for a more comprehensive reporting widget

Just a talking point I hope you'll all find useful: Might it make sense to
incorporate this sort of thing into a more comprehensive error-reporting
mechanism.  On the attachment, I have three states: a red exclamation point for
a page which is not readable, a yellow exclamation for a page which is
readable, but has some kind of error on it, and a green dot or asterisk for a
page which is apparently ok.  Hovering over the icon would give a tool tip with
some information (e.g., HTTP status code for unloaded pages, warnings about
HTML or Java errors, etc.), and clicking the icon would bring up the page info
window.  

Obviously the punctuation is something that could be replaced by one of the
much-better-looking icons in the other attachments; but the fundamental idea
would be for there to be a kind of very simple, easily graspable page quality
icon distinguishing three possible states (good, not so good, unusable) with a
little more detail on hover and a lot more detail on click.

Comment 90

[Christopher Hoess (gone)]

n.b. there's some kind of requirement in the SGML spec (which applies to HTML4,
at least) about reporting SGML errors vis-a-vis other errors and distinguishing
them. I'll check the exact wording in the morning.

Comment 91

[Torsten Scheck]

Regarding the votes it's obvious that css-, html-, js- validation is a
desperately needed feature for developers of dynamic web content. But the fact
that there is no solution after two years shows the difficulty of coming up with
a new validation component, a reporting concept and a suitable gui at the same time.

I suggest starting with a simple hook concept, which allows to automatically
process every loaded page by an external validator tool like xmllint. The error
messages may be logged in a file; I don't need a reporting gui. A selection of
the pages to be vaidated would be nice, but even this could be done by a small
wrapper around xmllint. After all, this should be mainly a feature for
developers, not for the end user. (After our itch is scratched, this feature
could be gradually improved until the end user can use it to slander about web
authors, of course. :-)

Torsten

Comment 92

[Adam Tomlinson]

surely with 112 votes, this bug should be assigned to someone or at least
nominated for netscape engineers? i wish i knew some programming so that i could
fix this myself.

Comment 93

[Christopher Hoess (gone)]

The frontend is probably not so difficult; it's fixing blocker bug 40945 that's 
the problematic part. (See comment #77; this requires either a massive rewrite of 
htmlparser, which is unlikely, or the integration of nsgmls.)

Comment 94

[Christian Reis]

Then unblock it. Bug 40945 is much more comprehensive, hasn't seen progress, and
the infrastructure exists to at least say if it's triggered quirks (and other
workarounds that may be used), JS is broken, etc.

Comment 95

[Malcolm Rowe]

As comment 88 mentions, rendering mode (quirks/strict) is already in Page 
Info.  I think this bug is really about validating the source rather than just 
showing the rendering mode.  If you want, I suggest raising a separate bug to 
give greater visibility to the current document rendering mode.

I think that giving an indication that a something (page-load,  mouse-click or 
whatever) has caused warnings/errors to appear in the JS console is also badly 
needed.  At the moment, there is no notification that an error has occurred.  
However, I think this should also really be raised as a separate bug, rather 
than morph this bug to combine all three concepts.

LATER, we could combine the indicator(s) into one combined 'Render 
mode/validated source/Javascript error' "quality meter", but for now I'd rather 
separate them so that they aren't all dependent on getting a validating parser 
implemented.

Comment 96

[Hixie (not reading bugmail)]

We do _not_ want to implement a page validation system in Mozilla. That is a
large undertaking fraught with complications. If people want to validate pages
they can go to validator.w3.org.

Comment 97

[Matthew Mastracci]

Someone should bundle up the client-side version of the w3c validator into an
XPI and have it be an optional install.  It could just check the source of each
page loaded into the browser, whenever enabled, and report the status.  

No Mozilla changes, completely optional component:

http://validator.w3.org/source/

I would love to tackle this if I knew where to start.  

Comment 98

[Matthew Mastracci]

Silly me, making a suggestion without checking out the source itself.  Looks
like the validator is Perl-based, but all it does is wrap an SGML parser, SP. 
SP is open-source C++ and has what seems like a good API to interface with:

http://www.jclark.com/sp/generic.htm

Other than that, you need the HTML DTDs locally (or just grab them from the w3
each time) and some sort of API for displaying the validation errors.

Comment 99

[s.marshall]

The W3C validator is an utter nightmare consisting of several packages in
different programming languages. Just getting it to run is a miracle. It
wouldn't be easy to package in an XPI at all. That said if somebody did it - cool.

But Mozilla should not IMO attempt to fully validate pages against a DTD as a
standard feature; this would hit page load performance. If this were implemented
it should be as a menu option (Tools / Web Development / Validate Page, w/ key
shortcut). Actually, that could be done right away if it only really jumped off
to the W3C validator, until somebody's coded it 'properly'. I think that'd be a
separate RFE. Quite useful as sometimes, validating pages can show problems
which cause trouble in Mozilla but work in IE, so having a quick link to help
people validate in the browser would make sense.

But automatic validation for HTML is basically a goal that was missed anyway.
*XHTML* is where a degree of validation should come in, and it does; Mozilla
already checks XHTML documents for well-formedness. (When they are served with
an appropriate MIME type.)

'Live' icon warnings as described in this thread would be a good idea for JS
errors etc. but that's probably another bug.

Comment 100

[Torsten Scheck]

Comment #99 From [e-mail]:
> *XHTML* is where a degree of validation should come in, and 
> it does; Mozilla already checks XHTML documents for 
> well-formedness. (When they are served with an appropriate 
> MIME type.)

If this is the case, I suggest to display the validation result 
of XHTML-documents in the GUI: 
a) no XHTML => no validation possible
b) valid XHTML
c) invalid XHTML (maybe with validation error details on click)

This way users will be sensitized to the existence of XHTML as 
the current standard _and_ to the importance of valid pages.

Comment 101

[Markus Pihlaja]

Comment 99
> If this were implemented it should be as a menu option (Tools / Web
Development / > Validate Page, w/ key shortcut). Actually, that could be done
right away if it   > only really jumped off to the W3C validator, until
somebody's coded it           > 'properly'.

There already exists at least one "bookmarklet" that does just this.
Bookmarklets are normal bookmarks that have javascript as URL

Check http://www.squarefree.com/bookmarklets/validation.html for examples. I
have this in my Personal Toolbar folder for the suggested functionality.

Comment 102

[Hixie (not reading bugmail)]

We already report non-wellformed XHTML *very* *very* clearly. (We refuse to
render the document point blank if it is not well-formed. This is what the XML
spec says we should do.)

So that's already covered.

Comment 103

[Mark Bitterling]

When Mozilla refuses to render the document point blank if it is not
well-formed, is the user informed that that is why the page is not being rendered?

Comment 104

[timeless]

sure, you get something like this:

XML Parsing Error: not well-formed
Location: data:text/xml,</foo>
Line Number 1, Column 2:</foo>
-^

just enter that url (data:text/xml,</foo>) into your urlbar.

Comment 105

[Torsten Scheck]

Where in an XHTML-document am I supposed to put this mime-type, so that Mozilla
accepts it and validates the document?

I tried a 
  <meta http-equiv="data" content="text/xml" />
without success.

Do I have to change my XHTML-header? 

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">

Sorry, I haven't found anything appropriate with google-web and google-groups.
I'm really eager to produce valid XHTML and with Mozilla's XML-validation I
could debug PHP-output very comfortably with Mozilla.

If there is a chance to use Mozilla for this purpose, I'm sure many
web-developers will embrace Mozilla due to this feature. I'll make sure to
spread the word about it, then. :-)

Comment 106

[Torsten Scheck]

Mozilla  doesn't seem to validate against XHTML or a given DTD, respectively. It
just reports an error if the XML isn't well-formed.

data:text/xml,<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html
xmlns="http://www.w3.org/1999/xhtml" lang="en-US"> <bla></html>

returns:

XML Parsing Error: mismatched tag. Expected: </bla>.
Location: [...]
Line Number 1, Column 187:

This, for example, produces no error:
data:text/xml,<bla/>

Could someone point me to related Mozilla documentation or to the related part
of the source code? Thanks.

Comment 107

[Henri Sivonen (:hsivonen)]

Summary so far (please read before adding comments)
---------------------------------------------------

Really short version: Don't expect this feature to be implemented any time soon
if ever.


Longer version
--------------

When I reported this bug, I thought Mozilla had the back end capability of
reporting HTML errors. This is *not* the case. The assumption was based on
comment #1 of bug 41331.

There are two approaches to implementing back end support for HTML error reporting:

1) iCab doesn't do proper validation (in the SGML sense). iCab's HTML parser has
a built-in linter. 

Adding comprehensive error checking to Mozilla's HTML parser would involve a lot
of work and could cause measurable run-time overhead even though a linter
wouldn't have to read DTDs. 

Making Mozilla's HTML parser to be a linter, too, is non-trivial. It is 
unlikely that someone would implement proper error reporting for Mozilla's HTML
parser. And the error reporting needs to be proper, because people would rely on it.

However, if you feel like implementing error reporting, go for it, but be aware
that you'd have to defend your code against accusations of causing performance
regressions. 

2) The other approach is bug 40945. That is, using a real SGML parser. Using a
real SGML parser is problematic, because there is so much tag soup out there.
Mozilla's HTML (tag soup) parser has had years of testing with real-world data.
It is unlikely that a real SGML parser would be able to cope with real-world Web
pages the way end users tend to expect. Also, the various HTML DTDs are huge
compared to many Web pages. Using real DTDs would cause a significant
performance hit.

Also, an SGML parser doesn't check for violations of restrictions set forth in
the prose of the HTML 4.01 spec.

I think that integrating SP with Mozilla would be a cool exercise, but I don't
believe SP could replace Mozilla's HTML parser in the default version of Mozilla.


About XML
---------

Mozilla's XML parser is non-validating. The validity of a document parsed as XML
(including XHTML) is unknown. Also, reading a DTD incurs significant run-time
overhead. Performance-wise it doesn't make sense to have use a validating XML
parser in a Web user agent. I might add that validating XML at run time in an
user agent isn't that interesting. Also, one of the main reasons of introducing
the concept of well-formedness was to relieve time-critical interactive apps
like Web browsers from validation.

There's no point in having an extra indicator for XML well-formedness, because
Mozilla already complains very clearly when the user tries to access an
ill-formed document served using an XML content type.

XHTML served as text/html is effectively tag soup with croutons. It is parsed
using the HTML parser. You can't override the HTTP Content-Type using <meta>
tags. (It isn't a bug. Please don't file one.)


Workaround
----------

You can get a validation bookmarklet from
http://www.iki.fi/hsivonen/test/validate.html

Comment 108

[Knud Sørensen]

Don't expect this feature to be lesser popular just because it is
hard to implement. ;-)

It got that many votes because it is a real problem and it need a
real solution to go away.

The validate javascript doesn't do it.

a) You can't validate pages behind a firewall.

b) You can't validate multi-page server-side scripts.



The validate could be a option in the preference only for people
who wants it. (The performance hit you get in mozilla is very small
to the performance hit you get if you try to validate your pages in any
other way.) 
 
It could run in the background after the page is showed using 
a different parser.

The DTD can be cached like every other web page to
avoid many big downloads 

A linter like iCab would be okey for a start. 

Knud

Comment 109

[Jos.vandenOever]

I have to agree with the last post.  A simple smiley like icab's can really make people fanatical about correct html. Believe me, I've seen it.  Make icab smile! (lovely slogan).  

Comment 110

[Hixie (not reading bugmail)]

You can download SP, it's available online, and does both SGML and XML iirc.

If you want your XHTML docs to be handled as described above, you have to tell
Mozilla they are XML, by sending them as HTTP Content-Type: text/xml.

Anyway. If someone wrote an XPI to do this, that would be great. But this will
not make it into Mozilla trunk (I say this on behalf of the module owner).

Note that this doesn't stop bug 6211 from being fixed. It only stops Mozilla
from becoming or shipping a validating parser in default builds.

Comment 111

[Kai Lahmann (is there, where MNG is)]

wontfixing this bug at all with over 100 votes shows how much
Mozilla/Netscape/AOL cares about the community.

Comment 112

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #111 From Kai Lahmann 2002-10-08 14:01
> wontfixing this bug at all with over 100 votes shows how much
> Mozilla/Netscape/AOL cares about the community.

Calm down, Kai. hixie doesn't work for mozilla.org, Netscape or AOL. He also has
questioned his WONTFIXing - look in the Status Whiteboard.

I'm not sure about this either, though. hixie, don't you think that creating a
mozdev project just for adding this feature isn't worth it?

Comment 113

[Hixie (not reading bugmail)]

I personally think the entire feature isn't worth it, because I have a
javascript bookmarklet on my personal toolbar which validates the page, and
people who want to validate local files need but install a validator on their
local machine.

The problem with putting this feature in the core client is that it would hit
performance, or, would increase the number of preferences, both of which aren't
really a good thing at this stage.

Comment 114

[Chris Carlin]

But Ian, a lot of people rooting for this bug are doing so not thinking about
validation of one's own pages, but rather showing the user that the problem is
in someone else's pages instead of in Mozilla. I think there has been a lot of
wasted breath in this bug from people not realizing that they have sometimes
comflicting motives for this same request.

I know it seems wrong to me that it's being marked wontfix just because the
backend doesn't exist. Wouldn't it be more precise to simply make it depend on
the bug of creating the backend? It looks like the definition of an "acceptable"
backend is so stringent that it probably won't be made, but don't kill this bug
because of that. Instead just say we're blocked by that other bug and not doing
any more on this one until that one is finished.

Comment 115

[Andrew Taylor]

As a compromise, how about having this icon show up in the page info screen? 
That would eliminate the performance hit for general browsing.

Comment 116

[Mark Bitterling]

I posted this comment once before, but apparently it got lost somehow.

Regarding the following error message :

XML Parsing Error: not well-formed
Location: data:text/xml,</foo>
Line Number 1, Column 2:</foo>

An error message like this is not going to make sense to an average end user;
they will most likely simply blame Mozilla for not rendering the page --
especially if another browser is able to render it "better" in their eyes.  This
is one reason for having some kind of simple indicator to tell users that the
page is at fault and not the browser.

Having the indicator appear on the info page defeats this purpose since it
forces the user to try to find the reason for the page's failure.  Most users do
not care that much; it is easier to just blame the browser and move on.

Personally I'd be happy with an indicator that only caught some coding errors. 
It does not have to be a full HTML validator.

Comment 117

[Chris Carlin]

<i>Personally I'd be happy with an indicator that only caught some coding errors. 
It does not have to be a full HTML validator.</i>

Right, would it be moderately inexpensive to look for something like the top
incorrect things pages do incorrectly (in terms of look and detriment)? Perhaps
base this list on submissions to Bugzilla? Maybe even go request examples of
things that look bad in Mozilla because of bad coding? 

Heck, you could even have Mozilla update this list once a week from Mozilla.org
to keep track of the current problematic practices. Or perhaps not, it's just a
thought.

Comment 118

[Jeremy M. Dolan]

> look for something like the top incorrect things pages do incorrectly

The problem with this (and any approach) is if Mozilla implements page checking,
people will consider it authoritative. That puts in a hugely bad position, one
which mozilla.org should not take on.

As much as I'd like to see a big red X in the mozilla chrome on nasty sites that
violate the standard (ie, 99.98% of them), I agree with the WONTFIX. Someone
should be able to implement this as an XPI addon, but it's just not possible for
mozilla.org to add a reliable error parser to their web browser (something that
is intended to VIEW web pages quickly and easily, not debug them).

We are liberal in what we accept, even in standards mode. To add error checking
code to all those cases we "deal with" now would contribute huge amounts of bloat.

Comment 119

[Marcus Pallinger]

Hixie, Does the bookmarlket allow for validation of a dynamically generated page? 

Comment 120

[Peter Åstrand]

>The problem with this (and any approach) is if Mozilla implements 
>page checking, people will consider it authoritative. 

This will only happen if we use "HTML good" icons or "happy smileys". We
shouldn't do that. The HTML quality indicator should only have two modes:

1) "HTML bad" 
2) "Unknown.", some kind of question mark. 

Clicking on any of these should contact validator.w3.org. With this design,
there will be some "false negatives", but I think this is better than nothing.
If people starts interpreting a question mark as "my page is perfectly OK!",
there is not much we can do about it. We cannot solve all stupidity. 

Comment 121

[Hixie (not reading bugmail)]

Chris in comment 114:
> But Ian, a lot of people rooting for this bug are doing so not thinking about
> validation of one's own pages, but rather showing the user that the problem is
> in someone else's pages instead of in Mozilla.

Right. That feature definitely won't be in the trunk because it would hurt
performance a lot, and not having it enabled by default would make it pointless.


> I know it seems wrong to me that it's being marked wontfix just because the
> backend doesn't exist. 

It is the back end that is being wontfixed.


> As a compromise, how about having this icon show up in the page info screen? 
> That would eliminate the performance hit for general browsing.

Someone should write that as an extension, but that work would happen in a
mozdev context, not here.


Mark in comment 116:
> [xml error]
> An error message like this is not going to make sense to an average end user;
> they will most likely simply blame Mozilla for not rendering the page --
> especially if another browser is able to render it "better" in their eyes.

No user agent will ever render an XML page which has validation errors, that 
would be a GROSS violation of the XML spec.


> Personally I'd be happy with an indicator that only caught some coding errors. 
> It does not have to be a full HTML validator.

That's bug 6211. _This_ bug was asking for validation.


Marcus Pallinger in comment 119:
> Hixie, Does the bookmarlket allow for validation of a dynamically generated 
> page? 

Not the one I use, but it would probably be possible for someone to hook it up 
to the HTML validation service's upload form:

   http://validator.w3.org/file-upload.html


If someone filed a bug on having a button in the page info dialog which uploaded 
the page to the HTML and CSS validators, then that would probably be welcomed.

Comment 122

[Chris Carlin]

> It is the back end that is being wontfixed.

This bug very clearly for the frontend. By marking this bug wontfix you're not
saying anything about the backend. The discussion mentions that the backend
doesn't exist, but that is not the focus of this bug. Or if it is the summary
and perhaps component of this bug need to be made more precise.

> _This_ bug was asking for validation.

Are you sure? As I said there are definately people in this discussion who seem
to think otherwise. The summary certainly doesn't sound like validation to me,
it makes me wonder if these votes were for validation or the more general
quality indication.

Comment 123

[Peter Lairo]

Ok, just filed bug 173498 "Need Button in the Page Info Dialog to upload the
page to the HTML and CSS validators".

Not exactly discoverable, but at least it's there; and it doesn't cause a
performance hit.

Comment 124

[Esben Mose Hansen]

Arghhh! Why can't people *propose* a bug wontfix, state their reasons watch the
discussion for three days and *then* close a bug? Especially a bug with a 102(!)
votes :-( :-( :-(

As for the reasons stated: 

- There doesn't *have* to be a performance hit. E.g., the validation could be
performed asynchroniously on a low-prioty thread. It wouldn't even affect the
bug as this bug is *frontend*

- If the validation needs to be "authoritative", let it be a complete
DTD-validation. Nobody can ask more than that. Perhaps we could even steal one
if one under a compatible license could be found. On second thought, that's
unlikely. Is this a problem in the browser that does sport a validation of sorts?

Just my two angry euro.

P.S: I do not direct all this a Ian, which is apparantly a middle man here.

Comment 125

[Eugene Savitsky]

I do not really need this feature, so my suggest just put somewhere a "vlidate
this page" that shows the validation of this page by validator.w3.org.

Comment 126

[Shark Daddy (Jonathan L.)]

Haven't we been straying away from linking to websites from menus, toolbars, and
other prominent UI?

Comment 127

[Jeremy M. Dolan]

Yes, we have. And a bookmark can do what he suggests. As for dynamically
generated pages, if bookmarks can't submit them to a bug, someone should file an
RFE on bookmarklet functionality.

I think we're done here. Do this either with an XPI or bookmarklet. No possible
(reasonable) solution to do it by default.

Comment 128

[Chris Carlin]

<sigh>
Even with the further discussion it's obvious that you're still marking the
wrong bug as wontfix.

Comment 129

[Akkana Peck]

BTW, Composer has a menu item to run the W3C validator on the current page.

Comment 130

[gabriel]

As a workaround, why not just show a big red 'X' if 'document.all' or
'document.layers' is found in the page ?

That would probably work 99% of the time.

Comment 131

[Hixie (not reading bugmail)]

That would be part of bug 6211. (And by the way, the way you described it would
bo wrong.)

Comment 132

[Gérard Talbot]

People who have been hoping that this bug be fixed may want to download HTML validator extension from M. Gueury at
http://users.skynet.be/mgueury/mozilla/
in particular Windows users. The Windows users can download and install version 0.8.3 
http://users.skynet.be/mgueury/mozilla/preview_080.html
which is a true validator, a SGML validator (based on OpenSP). 

I've been using it for the last 3 days with Firefox 1.5.0.3 and it works basically - almost exactly - the same as the W3C validator but without having to submit the page to the W3C HTML valdiator. I did not notice any significant slowing down in the rendering of page and I'm using a Pentium 3, 667Mhz cpu, 384MB of RAM. The extension is 1,849 KB in size. M. Gueury's extension is more powerful, more reliable, more useful and more versatile than anything I've seen so far: it works off-line (and that is a big advantage), it can alternatively use HTML Tidy (same code as Tidy from W3C), it can report accessibility errors, warnings, accessibility issues to check manually.

Considering that most of the discussion in this bugfile and in bug 6211 have been about performance consequences and back-end support and considering that other browsers (like Opera 9 and its Error console) are moving toward an extended error reporting, I wonder if this bug could not be reopened. I'm just probing this possibility.