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).

sure...

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

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 information to JavaScript...

qa: claudius, statusbarman....

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

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.)

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.

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 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.

Marking nsbeta3- per PDT review.

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 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.

*** 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 displayed).

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 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.

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. 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).

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? Gerv

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 "Personal toolbar".)

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, 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.

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.

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. Knud

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.

> 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

> 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 to IE.

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 of errors/warnings.

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 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 overhaul. 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. Gerv

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...

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...)

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.

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. :-) Torsten

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 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.

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: http://validator.w3.org/source/ 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: 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.

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 s.marshall@open.ac.uk: > *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 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.

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 Location: data:text/xml,</foo> 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" /> 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. :-)

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.

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

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

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 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.

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 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.

<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.

> 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 > 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.

> 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.

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.

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.

<sigh> 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 bo wrong.)

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.