28558 - chrome validator

Status: RESOLVED WONTFIX

(Core :: XUL, enhancement, P3)

Description

[Robert Kaiser]

That bug's a feature request I brought up in the recent MozillaZine weekend
discussion (sorry, just don't know the right component for that thing...):

I'd like to see a built-in validator for
(1) HTML 4.0 + CSS 1/2 and
(2) XUL+CSS+DTD(+JS?) (chrome).

The first would be very usable to webmasters who want to see if their pages are
written correctly and to users who'd see if there are errors in the sites they
view ;-) There should be some small button showing something like "bad HTML" and
brings up a validator window showing the site's errors.

The second (chrome) validator would be VERY useful for people working on skins,
own components or localisation. There should be some validator window which
checks for errors in chrome code and shows them (also in which line they occur -
also in dtd or css files!). The "old" console window did show xul errors, if
there was a dtd error, it only showed up the file - now those notifications are
also gone if you redirect mozilla's output to a file :(

I think the two validators could also be more or less the same feature...

Comment 1

[Karl Ove Hufthammer]

This is probably a duplicate of bug #6211 ...

Comment 2

[Robert Kaiser]

[e-mail]: you're right that the HTML/Web page validator is a dupe.
But I'll leave this one for the chrome validator. It isn't covered by 6211, and
after re-thinking IMO it can't be solved with a button on the page 'cause the
"page" doesn't even display if there's a false entity in a dtd, for example.

So it should be a debug window or a popup (in this case, it must be a
default-off pref). Perhaps it would be enough (if we have a possibility to turn
on the debug window again) to dump _all_ chrome error comments there...

changed summary
from: [RFE] HTML/Web page/chrome validator(s)
to: [RFE] chrome validator

Comment 3

[Christine Begle]

updating component.  rick, there's no description for your XP Utilities 
component, so I'm just guessing that this might be a good place for it.  sorry 
if i guessed wrong.

Comment 4

[Christine Begle]

udpating component owner.

Comment 5

[rickg]

I've got a bug (RFE) on the HTML validator; I'm forwarding the XUL validator 
idea to hyatt. 

Comment 6

[David Hyatt]

Can't happen anytime soon... since XUL's syntax is still in flux...

Comment 7

[Robert Kaiser]

Hyatt, it's too early for a real validator - but can't we have dumping of 
rendering errors (and only errors) in stdout in the meantime?
So that if we redirect the output to a file we can see where rendering stopped, 
giving us only the filename and line of the xul/dtd/css file which couldn't be 
rendered?
especially telling us when an entity can't be found (which entity of which 
xul/dtd pair it was?). That would be a great help in the meantime. (the UI of 
any window simply doesn't draw now if there's a 'missing' entity - it would be 
good to know where we can find the error after we saw it didn't render 
properly).
In M13, we had a message in the console window which stated the error (even if 
it didn't tell which entity couldn't be found it said at least in whicht dtd the 
error occurred) - but that messages are gone now...

Comment 8

[David Hyatt]

All of these things are dumped to the console.  You get line #s of missing 
entities.  You also get line and col #s for syntax errors in XML files.

Comment 9

[Robert Kaiser]

Hyatt, I would like to get those messages in the console - but I simply do NOT
get them in 2000022308/win32 (typing "mozilla > mozdebug.txt" from MS-DOS
Prompt). Are they turned off in the nightlies?

Comment 10

[Robert Kaiser]

OK, now I know why I didn't see the output. It's due to bug #29395. Using
"mozilla>foo" only logs stout, not sterr. From what I read there, "mozilla
>&1>foo" should work.

Comment 11

[Peter Trudelle]

Mass move of all M20 bugs to M30.

Comment 12

[Peter Trudelle]

Mass moving M20 bugs to M30

Comment 13

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 14

[timeless]

bug 69542?

Comment 15

[Robert Kaiser]

timeless, bug 69542 might help for a part of the problem, but this one is about
a more elegant solution IMHO.

If we would do what requested here (it's a power-user feature for sure for both
HTML and chrome), we would have an internal console like we have JS console now,
which would tell us all parser errors in HTML, XML/XUL+DTD and CSS parsing
(similar to the XML errors we get now when we can't load the file - those are
very helpful in this manner btw).

Additionally, we'd get warnings for deprecated stuff etc. (in the thing I'm
dreaming of...)

I think this would be quite nice to do because we should have most of the needed
parts already in the tree. I think of this as an extension like venkman or DOM
viewer...

Comment 16

[Robert Kaiser]

removing DUPME because I think this has a common target in some style with 69542
but is a completely different way of doing that.

Perhaps we can do this in some way that we melt this with a HTML validator
(requested on other places, see bug 6211)...

But perhaps we should turn this (including summary) into a "parser console" or
something like that (as it's the original and still living idea)?

Comment 17

[timeless]

we already have rfes about renaming the jsconsole to application console and
sticking other parser messages in it... fwiw that bug has many more cc's than
this one...

Comment 18

[Mike Conca [:mconca]]

XUL came and went in the 21 years during which this bug was open.