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".
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).
Any chance someone else could do these images? I'm not all that good with
I can do some pretty piccies.
See also bug 47128.
I can help out with this if I know what XPCOM interface exposes this status
qa: claudius, statusbarman....
Reassigning to matthew to provide the images. Send back to me when that's done.
Created attachment 12248 [details]
Unknown status or loading
Created attachment 12249 [details]
Created attachment 12250 [details]
HTML no good
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.)
Thanks. Maybe unknown could have a question mark?
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.)
Created attachment 12288 [details]
Clarifying: I think the blank icon with neither the x nor the check mark on it
can serve as "unknown".
Blake, for now can you set this up using Henri's icons? They're pretty good.
Created attachment 14394 [details]
Created attachment 14395 [details]
HTML Good - a more visible tick
Created attachment 14396 [details]
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
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.
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
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 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.
Marking nsbeta3- per PDT review.
Created attachment 15456 [details]
More sample icons...
Created attachment 15458 [details]
Actually, the file above was a PSD. Sorry for the spam :-/
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.
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
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.
*** Bug 57623 has been marked as a duplicate of this bug. ***
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.
>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.
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.
So which set of icons do we want to use?
And do we want to use the same set of icons in modern and classic?
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
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!!
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.
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
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
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.
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.
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.
RickG: By "valid", I mean "valid" as used in the relevant specifications.
* 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).
Created attachment 19424 [details] [diff] [review]
patch - add images to build
Created attachment 19428 [details] [diff] [review]
patch - add images and clean up tab hell
r=jag, but get some input on whether to use png or gif.
I'm sure some people will veto the whitespace change... *sigh*
*** Bug 83820 has been marked as a duplicate of this bug. ***
what is the status of this bug? How does it validate a document?
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"?
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.
So, what's the status on the back end for this? rickg?
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...
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?
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.
Yes a link to validator.w3.org
would be great !
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.
> 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
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.
*** Bug 42286 has been marked as a duplicate of this bug. ***
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?
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.
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?
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?
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).
> 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,
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
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.
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://bobby.cast.org/html/en/index.jsp for accessibility checks. There are
almost no sites that can pass the later.
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?
You could also use happy and sad smileys.
We could just have
Document: Done (1.2s)
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.
> 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
> 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).
How about a tab under Page Info?
> How about a tab under Page Info?
I think the idea is to have the quality meter *always* visible. ;)
> 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
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... ;)
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
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
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 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.
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?
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.
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
Anyone care to come up with such a design? It should probably be a
consumer/producer thing --- sort of like the sink?
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.
just me 2 cents :
or css, not html.
like text/plain mime type for css files should trigger it too...
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.
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?
> 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.
The case I had in mind was validator.w3.org raising the bar by requiring the
character encoding to be declared.
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).
*** Bug 160094 has been marked as a duplicate of this bug. ***
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.
no no no, rendering mode is already in page info. (which even gives you the
encoding, mime type, etc...)
Created attachment 97670 [details]
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
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.
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.
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. :-)
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.
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.)
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.
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
separate them so that they aren't all dependent on getting a validating parser
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.
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:
I would love to tackle this if I knew where to start.
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:
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.
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 #99 From firstname.lastname@example.org:
> *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.
> 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.
Check http://www.squarefree.com/bookmarklets/validation.html for examples. I
have this in my Personal Toolbar folder for the suggested functionality.
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.
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?
sure, you get something like this:
XML Parsing Error: not well-formed
Line Number 1, Column 2:</foo>
just enter that url (data:text/xml,</foo>) into your urlbar.
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" />
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"
<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. :-)
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"
xmlns="http://www.w3.org/1999/xhtml" lang="en-US"> <bla></html>
XML Parsing Error: mismatched tag. Expected: </bla>.
Line Number 1, Column 187:
This, for example, produces no error:
Could someone point me to related Mozilla documentation or to the related part
of the source code? Thanks.
Summary so far (please read before adding comments)
Really short version: Don't expect this feature to be implemented any time soon
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
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
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.
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.)
You can get a validation bookmarklet from
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.
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
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.
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).
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.
wontfixing this bug at all with over 100 votes shows how much
Mozilla/Netscape/AOL cares about the community.
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?
I personally think the entire feature isn't worth it, because I have a
people who want to validate local files need but install a validator on their
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.
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.
As a compromise, how about having this icon show up in the page info screen?
That would eliminate the performance hit for general browsing.
I posted this comment once before, but apparently it got lost somehow.
Regarding the following error message :
XML Parsing Error: not well-formed
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.
<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
> 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.
Hixie, Does the bookmarlket allow for validation of a dynamically generated page?
>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.
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
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:
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.
> 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
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
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.
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.
Haven't we been straying away from linking to websites from menus, toolbars, and
other prominent UI?
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.
Even with the further discussion it's obvious that you're still marking the
wrong bug as wontfix.
BTW, Composer has a menu item to run the W3C validator on the current page.
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.
That would be part of bug 6211. (And by the way, the way you described it would
People who have been hoping that this bug be fixed may want to download HTML validator extension from M. Gueury at
in particular Windows users. The Windows users can download and install version 0.8.3
which is a true validator, a SGML validator (based on OpenSP).
I've been using it for the last 3 days with Firefox 184.108.40.206 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.