Closed Bug 285744 Opened 20 years ago Closed 20 years ago

wrong named colors incorrectly translated into hex colors

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: glazou, Assigned: dbaron)

Details

1. write a HTML document with <body bgcolor="tutu"> "tutu" is not an HTML4 nor an X11 color 2. browse the document with Firefox 1.0.1 Expected result: no background on the document since the color name is invalid. Actual result: black background!! (internally the attribute is translated into #000000. If you try with bgcolor="oran", and oran is not valid, you'll end up with... a green background! This bug is important to Nvu because direct contextual modification of an attribute in a new Advanced Properties panel cause incorrect colors to be shown in the main window... (not sure if GFX is the right component for that but since namedcolor-to-hex is done there...)
This is needed for compat with existing content, actually... (as in, pages depend on it). Note that this behavior _is_ quirks-only. Bug 121738 covers us not being completely compatible with IE as far as parsing things like this goes, but it doesn't sound like that's what this bug is about.
I don't understand this: | This bug is important to Nvu because direct contextual modification of an | attribute in a new Advanced Properties panel cause incorrect colors to be | shown in the main window... Surely Nvu doesn't allow you to edit the (deprecated) "bgcolor" attribute? Also I'd have assumed Nvu created strict mode documents, in which this wouldn't be a problem, since this behaviour is a quirks-mode only quirk IIRC. As far as I can tell this is INVALID.
Assignee: general → dbaron
Component: GFX → Style System (CSS)
(In reply to comment #2) > Surely Nvu doesn't allow you to edit the (deprecated) "bgcolor" attribute? Also > I'd have assumed Nvu created strict mode documents, in which this wouldn't be a > problem, since this behaviour is a quirks-mode only quirk IIRC. > > As far as I can tell this is INVALID. That kind of answer is just not acceptable from a user's point of view, Ian, and you have to understand AT LEAST ONCE IN YOUR LIFE that your perception of what's good or bad in an EDITOR is NOT Mr Smith's perception. Your favorite editor is emacs, when Nvu users don't even know emacs exists. You are a standards' freak when most of Web users are unable to say H-T-M-L in that order! Come back on earth, please. Nvu creates HTML 4.01 Transitional and Strict, XHTML 1.0 Transitional and Strict documents. The user has the choice, OF COURSE. My goal with Nvu is to provide a good open-source standards-compliant wysiwyg editor to people who currently use commercial software. Those software DO OUTPUT bgcolor attributes. If Nvu does not handle that attribute a way or another, users are not able to change the background of their page just because (a) THEY HAVE NO IDEA about the bgcolor attribute and its status (b) THEY DON'T HAVE TO KNOW ABOUT IT. Anyway, if we support this attribute in quirks mode to be able to render in FF pages made with FrontPage, I still don't understand why bgcolor="oran" results in a green background. "oran" and "tutu" are not color names, AFAIK. So if they generate a black and green background, that's an error. Am I correct in that assumption ?
What has the user's knowledge got to do with whether Nvu outputs deprecated elements or not? To quote from the HTML spec: "authors SHOULD use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes". "SHOULD" means "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course". What's the reason for exposing users to a feature that has been deprecated? As the implementor of an editor, it is your responsibility to help users make the most compliant pages possible. If you let authors create pages that use presentational markup (<font>, bgcolor="", style="", etc) instead of using semantic markup with stylesheets, then IMHO you are failing the users. Especially those who don't know HTML and therefore cannot make an informed choice about whether to use "Strict" or "Transitional". But that's all irrelevant to this bug, so we should probably move that discussion to e-mail. To come back to the topic at hand: bgcolor="<unknown value>" is intentionally handled specially in quirks mode for compatibility with IE6. There are numerous pages that rely on our current behaviour. In standards mode we drop unknown color values.
(In reply to comment #4) > As the implementor of an editor, it is your responsibility to help users make > the most compliant pages possible. If you let authors create pages that use > presentational markup (<font>, bgcolor="", style="", etc) instead of using > semantic markup with stylesheets, then IMHO you are failing the users. > Especially those who don't know HTML and therefore cannot make an informed > choice about whether to use "Strict" or "Transitional". That's the second responsability. The very first one, far above the second one, is to make sure the editor does what the user wants to do in all circumstances. And if it can be standards-compliant, then that's better. There is far more human-app interaction in an editor than in a browser. You just cannot say "no, I refuse to do that because it's deprecated". Unless you don't care about the success of your app, of course. But I guess that's a point of deep disagreement between you and me. > To come back to the topic at hand: bgcolor="<unknown value>" is intentionally > handled specially in quirks mode for compatibility with IE6. This comment made me try bgcolor="oran" in quirks mode in IE6. Green background... So in fact, we just copy IE6 bugs here. I now accept INVALID, but certainly not because I SHOULD not handle bgcolor.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
> I still don't understand why bgcolor="oran" results in a green background. Please do read the bug I cited in comment 1 -- that has a significant amount of discussion about exactly what NS4 and IE do with such malformed color names... (And I rather wonder whether that comment just got missed in all the acrimony).
You need to log in before you can comment on or make changes to this bug.