Closed Bug 77991 Opened 23 years ago Closed 22 years ago

[ready]Platform user interface colors from HTML

Categories

(Core :: CSS Parsing and Computation, defect, P1)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: SkewerMZ, Assigned: pierre)

References

(
URL
)

Details

(Keywords: compat, css2, testcase, Whiteboard: WONTFIX)

Attachments

(2 files)

Testcase: CSS and HTML UI color backwards compatibility test
1.84 KB, text/html
Details
patch 1.0
4.25 KB, patch
dbaron
: review+
SkewerMZ
: superreview+
Details | Diff | Splinter Review 
Procedure: Load a page where a user interface color is specified (such as
ThreeDShadow or ButtonFace).

Expected: The user interface color is used as expected.

Actual: Mozilla supports these colors when specified in CSS, good! However, when
specified as an HTML color, the color is butchered into a hex code producing
strange results.

Proposal: In order to improve compatibility and reduce embarrassing bugs, this
should either behave as expected, or at the very least default to an acceptable
value (dark colors for UI objects that are usually dark, light colors for UI
objects that are usually light).
Oh, and this functionality is described at this URL:

http://www.w3.org/TR/REC-CSS2/ui.html#system-colors
It would be really nice if you could come up with a testcase to demonstrate this
bug, it would make it much easier for us, thanks!
This shouldn't be difficult to duplicate, but here you go:

http://www.blooberry.com/indexdot/color/uiname.htm
URL: http://www.blooberry.com/indexdot/col...
Confirm?
Adding qawanted since this bug STILL hasn't been confirmed. Adding compat since
this is a backwards-compatibility issue (deprecated by CSS).
Keywords: compat, qawanted
This is so not a DOM problem, reassigning to layout, and confirming that mozilla
works differently than IE does, wether IE is correct or not I don't know.
Assignee: jst → karnaze
Status: UNCONFIRMED → NEW
Component: DOM Core → Layout
Ever confirmed: true
QA Contact: desale → petersen
Verified on
build: 2001-05-14-04-Trunk
platform: WinNT

Following is the testcase and it works fine.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>HTML BODY - TEXT</TITLE>
</HEAD>
<BODY bgcolor="black" text="ButtonFace">
This document should have a text color of user interface color name 
"ButtonFace".
</BODY>
</HTML>
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Testcase must have been invalid. URL still renders incorrect colors in build
20010515 Win98. Reopening bug. Next time, upload the testcase as an attachment
so we can reproduce the behavior.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
FWIW, I tested the test page in several browsers:
Netscape 4.7 on win95, and Mozilla 2001052204 win2k: Same colors: red, purple,
black, blue, green, violet, etc etc.
Opera 5 on win2k: Nada (transparent)
IE5.5 on win2k: Shades of gray and a little dark blue.

I don't know which one is correct, but I'm sure the different browsers don't
agree ;-)
Testing results:

Build 2001052204 Win98 is displaying the CSS objects with the correct colors,
but the HTML UI colors are ignored and page colors are inherited instead. In
Netscape 4 the colors would be dissected such that the first HTML test would
come out in a pinkish color with reddish text, and the second test would come
out with blue text on black. (And, of course, it ignored the CSS and BUTTON tags...)

I'll have to make another bug report about highlighting text that is already
being rendered in the highlight color... IE reverses the colors to distinguish
highlighted text when it is rendered in this color.
Keywords: testcase
I don't know when this went from trivial to enhancement (those of you with bug
mod privs, you need to post a message notifying the author when you make
changes!). Changing it back. This is an issue with backwards compatibility, and
many webpages out there still use these colors.

ZDNet even describes UI colors using HTML, which shows you how high the
expectations are that any "good" browser will be able to interpret them.

http://www.zdnet.com/devhead/resources/tag_library/misc/uinames.html
Severity: enhancement → trivial
Nominating for moz1.0
Keywords: mozilla1.0
Tested with a more recent build. In 2001071803 Win98, bug still exists.
Reassigning to style system.
Assignee: karnaze → pierre
Status: REOPENED → NEW
Component: Layout → Style System
QA Contact: petersen → ian
Adding css2 keyword.
Keywords: css2
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
2001090603 W98 passes my CSS2 tests. Are you seeing differently, and if so, in
which build?
Priority: -- → P4
Target Milestone: mozilla0.9.5 → mozilla0.9.6
dbaron/jst: please review
Attached patch patch 1.0 — — Splinter Review 

    
    

    
  
Why should we be supporting CSS2 system colors in HTML?  Specification of colors
in HTML is deprecated, and we shouldn't be encouraging its use.  Do other
browsers support this?

    
    

    
  
Does this affect what we do for color="deg"?  'deg' is a CSS keyword but also
pretty close to a hex color (which I think NS_LooseHexToRGB would probably handle).

    
    

    
  
Comment on attachment 55547 [details] [diff] [review]
patch 1.0

>+        PRInt32 index = SearchKeywordTable(keyword, nsCSSProps::kColorKTable);
>+        if (0 < index) {

I can't figure out where this |SearchKeywordTable| is defined, so I can't
tell whether this should really be |0 <= index| or not, but I suspect it
should be.

Other than that, r=dbaron.

        Attachment #55547 -
        Flags: review+

    
    

    
  
Interestingly enough, I went through the same questions.
1) We should support it because some other browsers do, and for the sake of 
coherence (same results in style attribute and html color attributes).
2) It won't affect other colors: we do a lookup in the table of css keywords for 
performance reasons but it is always followed by a lazy search in the table of 
colors.
3) It is a small static function from CSSParser that I copied there, which does 
the opposite of CSSProps::SearchKeywordTableInt().


    
    

    
  
dbaron: This bug is just done in the interest of lazy webmasters who would
rather not convert their pages to CSS (and many of them have a good reason for
doing so, considering the lack of support in other browsers). As you can see
it's a very simple fix, and it ensures backward compatibility.

In case you didn't know, deprecated means *still supported*, only there's a
better method available.

    
    

    
  
> In case you didn't know, deprecated means *still supported*, only there's a
> better method available.

I know that, but generally one does not add *new capabilities* (in this case,
system colors) to deprecated features.

    
    

    
  
Marc: s/r please

Summary: Platform user interface colors from HTML → [review]Platform user interface colors from HTML

    
    

    
  
I have slight reservations about adding bloat for deprecated and rarely used
HTMLisms. Please remember, we are on a push to _reduce_ memory footprint because
Mozilla is too big. I fear that this will add to the bloat and provide little
value in return. This is, of course, my personal opinion, but considering that
Nav 4.x didn't support this either, I find it hard to believe that it could be
terribly important on mainstream pages. Please convince me that this is worth
the bloat before I can sr. Optionally, we can surround it in an #ifdef, but that
seems kinda messy, and what would the #ifdef be? #define SUPPORT_HTML_COLORNAMES?

    
    

    
  
The patch will actually reduce the bloat since nsHTMLValue::GetColorValue() is no 
longer an inline function.


    
    

    
  
OK, I doubt it was inlined on all platforms, but I get your point. I agree that
there is problably no noticable bloat increase here, and that patch looks good.
sr=attinasi

    
  
Summary: [review]Platform user interface colors from HTML → [ready]Platform user interface colors from HTML
Target Milestone: mozilla0.9.6 → mozilla1.0

    
    

    
  
It's not the time to checkin trivial things like this.  We'll reconsider later.


    
  
Keywords: mozilla0.9.9

    
    

    
  
I think this should be a wontfix, its an enhancement for a depreciated feature.

    
  
Keywords: mozilla0.9.9

    
    

    
  
Even though the feature is *deprecated*, it should still be changed especially
in quirks mode (though the change should affect both modes). I think a fairer
solution is Future/enhancement than WONTFIX, since the bug is still open to
wanderers who may feel like writing a patch.

    
    

    
  
Moving to mozilla1.1. Engineers are overloaded!
Target Milestone: mozilla1.0 → mozilla1.1

    
    

    
  
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.
Priority: P4 → P1
Target Milestone: mozilla1.1 → Future

    
  
Keywords: patch, 
          
            review

    
  
Keywords: qawanted, 
          
            review

    
  
Keywords: approval

    
  

        Attachment #55547 -
        Flags: superreview+

    
    

    
  
cc'ing myself

    
    

    
  
Since we've not had great demand for this, WONTFIXing. See comment 20.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
Whiteboard: WONTFIX

    
    

    
  
I am reopening this bug since Mozilla is now looking into improving
compatibility with non-standardized browser extensions. See bug 156979. It is
ridiculous for that bug to be resolved while this issue is WONTFIX. Furthermore,
there has been a patch submitted that has already received super review.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

    
    

    
  
Restoring wontfix.  There's a difference between a non-standard feature for
compatibility with other browsers and a non-standard feature that's our own
invention and against the direction that the web should be moving.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX

    
    

    
  
I beg your pardon, Internet Explorer does the exact same thing. Please wait for
my response before changing the bug's state.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

    
    

    
  
Can you cite a bunch of major pages that use them?
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX

    
    

    
  
Can you cite a bunch of major pages that use marquee?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

    
    

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

    
    

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

    
    

    
  
please see testcase attachment 99686 [details]. 

This testcase demonstartes that when Background color is set using Javascript,
it does not render correctly, whereas, when using CSS properties, the correct
background system colors are displayed. 
Happens on all platforms.

 

    
    

    
  
It really doesn't have much to do with Javascript, since the Javascript is just
writing out HTML with these colors in the bgcolor attribute.  If the Javascript
wrote out style attributes instead, it would work.  It's still a difference
between HTML and CSS.

    
    

    
  
yup... i see what you mean.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: