Last Comment Bug 2942 - non-CSS presentational hints and user stylesheets [CASCADE]
: non-CSS presentational hints and user stylesheets [CASCADE]
: css1
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
P2 normal (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 45240 (view as bug list)
Depends on: 45240 234861
  Show dependency treegraph
Reported: 1999-02-04 21:06 PST by David Baron :dbaron: ⌚️UTC-8
Modified: 2009-01-19 09:39 PST (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image David Baron :dbaron: ⌚️UTC-8 1999-02-04 21:06:07 PST
The handling of non-CSS presentational hints is not correct for the FONT
element (it works for other stuff).  If you run the above test (which involves
tacking the end of the test onto ua.css), the sentence near the end that says
"This font should be quite large" ends up normal size.  Since the non-CSS
presentational hints should be translated to the corresponding CSS rules at the
beginning of the author stylesheet with specificity zero (see CSS2, ), the <FONT CLASS="test"
SIZE="7"> should be controlled by the SIZE="7" since the rule for CLASS="test"
is only in the user stylesheet.
Comment 1 User image David Baron :dbaron: ⌚️UTC-8 1999-03-10 18:31:59 PST
If you want to support presentational hints using the user stylesheet (for
example, table[frame=vsides], dl[compact] etc, you may want to use a weight
(such as
(or even just !important, although that could be confusing)
in the ua.css so that the rules cascade between the user-non-important and the
author-non-important levels.  This could be very useful.

Treating non-presentational hints at a level between user-non-important and
author-non-important is exactly equivalent to the spec's rule.
Comment 2 User image David Baron :dbaron: ⌚️UTC-8 1999-03-13 17:09:59 PST
One more thought on this -- You should probably translate the LINK, ALINK, and
VLINK attributes on BODY into:

A:link {
color: <LINK=>;
background-color: <BGCOLOR=>, otherwise inherit (that is, if there is no

A:visited {
color: <VLINK=>;
background-color: <BGCOLOR=>, otherwise inherit

A:active {
color: <ALINK=>;
background-color: <BGCOLOR=>, otherwise inherit

so that link colors don't clash with link colors specified in user
stylesheets.  Or is this too far away from the spec?
Comment 3 User image Peter Linss 1999-09-07 17:45:59 PDT
Pushing off non-beta 1 issues
Comment 4 User image Pierre Saslawsky 1999-10-21 01:07:59 PDT
Reassigning peterl's bugs to myself.
Comment 5 User image Pierre Saslawsky 1999-10-21 01:12:59 PDT
Accepting peterl's bugs that have a Target Milestone
Comment 6 User image David Baron :dbaron: ⌚️UTC-8 1999-12-17 19:27:59 PST
Although the only bug currently shown by the above test is the one with the FONT

element, there may be others.
Comment 7 User image Pierre Saslawsky 1999-12-20 21:10:59 PST
Pushing my M15 bugs to M16
Comment 8 User image Hixie (not reading bugmail) 2000-01-13 15:59:59 PST
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Comment 9 User image Pierre Saslawsky 2000-05-07 18:48:57 PDT
The text ("This font should be quite large") is now displayed correctly but 
several other things are not displayed as they say.

Just starting to look into it will take a while: pushing again...
Comment 10 User image Hixie (not reading bugmail) 2000-05-16 02:20:12 PDT
BTW, user stylesheets are now supported (I think) -- stick a user.css file into
the profile directory. Right Pierre?

See also bug 32746, "CSS border on IFRAME ignored".
Comment 11 User image David Baron :dbaron: ⌚️UTC-8 2000-05-16 07:38:33 PDT
The user.css goes in the chrome subdirectory of the profile directory, i.e.,
~/.mozilla/David/chrome/user.css (or the equivalent on Win/Mac).
Comment 12 User image Pierre Saslawsky 2000-06-12 04:02:52 PDT
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another known 
resource will be working on this bug, or if it blocks your work in some way -- 
please attach your concern to the bug for reconsideration. 

Comment 13 User image David Baron :dbaron: ⌚️UTC-8 2000-07-03 16:35:01 PDT
These are important issues in CSS1 compliance.  We should have a standard way of 
dealing with these things so they're always right.  Nominating for nsbeta3.
Comment 14 User image Pierre Saslawsky 2000-07-18 16:18:10 PDT
Bug 45240 will closed as dup but it contains a nice testcase and the following 
comment from

        HTML presentational elements (<B>, <I>, etc.) have their styles set in
        html.css, allowing the user stylesheet to override them. The CSS specs
        specify that presentational hints from the markup be treated as if it
        were at the top of the author's stylesheet, and thus the user stylesheet
        would not be able to alter these styles without an !important rule.

        CSS1:3.2 -
        CSS2:6.4.4 -

The testcase is in 2 parts:
  html file:
  user stylesheet:
Comment 15 User image Pierre Saslawsky 2000-07-18 16:19:10 PDT
*** Bug 45240 has been marked as a duplicate of this bug. ***
Comment 16 User image Pierre Saslawsky 2000-07-18 16:20:59 PDT
On a related matter, we also have bug 43220 ("author !important rules override 
user !important rules in user.css").
Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2000-07-18 16:35:07 PDT
I think the points made in bug 45240 are wrong.  Although the spec seems to
support them, I think the intention of the spec was otherwise.  In particular, I
think the language in CSS1 is much clearer (sec. 3.2):

# The UA may choose to honor other stylistic HTML attributes, for example
# 'ALIGN'. If so, these attributes are translated to the corresponding CSS rules
# with specificity equal to 1. The rules are assumed to be at the start of the
# author style sheet and may be overridden by subsequent style sheet rules. In a
# transition phase, this policy will make it easier for stylistic attributes to
# coexist with style sheets. 

I think this should be in the errata to CSS2.
Comment 18 User image David Baron :dbaron: ⌚️UTC-8 2000-07-18 16:45:19 PDT
See www-style:
Comment 19 User image fantasai 2000-07-18 16:54:30 PDT
Then <CENTER> should be treated differently from the other presentational 
<CENTER> is defined as <DIV align=center>.[1] It should behave exactly the same.

IMO, all of these elements (except <SUP> and <SUB>) are presentational hints. If 
HTML were defined differently, they would be no different from something like 
<PRES style=bold>, etc. There is no semantic meaning (other than grouping the 
text, as <FONT> does) associated with the element; only a presentational one.

At any rate, <CENTER> needs to be dealt with.

Comment 20 User image David Baron :dbaron: ⌚️UTC-8 2000-07-18 18:52:17 PDT
CENTER is weird.  I think it should be the exception, since it should act like
DIV align=center.  Also, its behavior can't be described by a UA stylesheet
rule, whereas B and I can.

If you want to bring this up on www-style, feel free.
Comment 21 User image ekrock's old account (dead) 2000-07-20 10:44:20 PDT
David, Pierre, this is nominated nsbeta3 but marked Future. How urgent do you
feel this is? David, please clear your nsbeta3 nomination if you no longer feel
it's merited, otherwise please justify priority for PDT team. Thanks!
Comment 22 User image ekrock's old account (dead) 2000-08-01 15:02:43 PDT
Comment 23 User image Phil Peterson 2000-08-30 16:22:57 PDT
PDT moving this to P5 and leaving [PDTP5] breadcrumb in status whiteboard. We'd
reconsider if there was a case for this being really critical.
Comment 24 User image karnaze (gone) 2000-09-21 11:15:07 PDT
Changing to nsbeta3-.
Comment 25 User image Jens 2000-10-04 12:39:35 PDT
Support for user.css is gone in M18 ?
Comment 26 User image David Baron :dbaron: ⌚️UTC-8 2000-10-04 12:43:42 PDT
It's now userChrome.css (for the UI) or userContent.css (for web page content).
Comment 27 User image Hixie (not reading bugmail) 2001-02-12 16:26:01 PST
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
Comment 28 User image Madhur Bhatia 2001-10-23 17:13:50 PDT
I visited the above mentioned url -
The testcase looks fine on builds 2001-10-20-x-0.9.4 (branch builds) on macOS9.1
and win2000.

the sentence near the end that says "This font should be quite large" displays
the fontsize as large - and not normal.

Comment 29 User image David Baron :dbaron: ⌚️UTC-8 2002-06-19 21:07:05 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 30 User image Greg K. 2002-07-11 17:48:21 PDT
Testing the testcase in comment #14 using FizzillaCFM/2002070913, everything
looks right, except the "Dark Green" text is shown in light green. Is that
evidence of this bug?
Comment 31 User image David Baron :dbaron: ⌚️UTC-8 2002-07-11 19:59:12 PDT
I wouldn't be surprised if fantasai's cascading changes fixed this.  However,
the original testcase should also be tested.
Comment 32 User image fantasai 2002-07-11 21:29:20 PDT
> I wouldn't be surprised if fantasai's cascading changes fixed this.

It would surprise me, though. :)

The way to fix this would be to take the HTML presentational rules out of the
UA level and put them in the presentational-hint level--by hard-coding them in
nsHTMLStyleSheet, perhaps.

Greg - Did you name the user stylesheet user.css or userContent.css? The
       instructions in that testcase are old--it needs to be userContent.css.

I tested in Moz1.0 -- still broken.
Comment 33 User image David Baron :dbaron: ⌚️UTC-8 2002-07-11 21:37:59 PDT
Well, the things I consider presentational hints are what we do in attribute
mapping (the HTMLStyleSheetImpl).  The line between presentational hints and UA
stylesheet isn't well defined, though.
Comment 34 User image Greg K. 2002-07-12 23:51:01 PDT
Appending the contents of the CSS file in comment #14 to my userContent.css and
accessing the testcase HTML in FizzillaCFM/2002071208, none of the Bold, Italic,
Underlined, or Struck-through text is styled at all. Presuming that reconfirms
this bug, setting All/All.
Comment 35 User image David Baron :dbaron: ⌚️UTC-8 2002-10-04 07:55:27 PDT
The CSS working group has been hashing out exactly what CSS2.1 should say on
this topic.
Comment 36 User image Max Kanat-Alexander 2003-06-20 03:34:20 PDT
WFM Win2K Mozilla1.3 Final

I have userContent.css in my chrome directory, and everything looks good per the
testcase in comment 14.

The original testcase gives me a HTTP 404.

I have to note that the "Dark Green" didn't turn dark green until I visited it.
However, looking at the code, that seems to be the intention.

Should this bug be marked WFM?

Comment 37 User image Gérard Talbot 2008-07-08 17:07:47 PDT
Hello all,

I copied the content of
and pasted it into my 
C:\Documents and Settings\[user-name]\Application Data\Mozilla\Firefox\Profiles\[bunch of numbers and characters].default\chrome\userContent.css
file, then started Firefox 3.0 rv:1.9 build 2008052906, then loaded
and read the content carefully. I confirm that the sentence near the end that says "This font should be quite large" is actually using a quite large font.

The last 2 tables were misfloated though, according to the content. 

<table class="fl" align="right"><tbody><tr><td>This table should float right.</td></tr></tbody></table>

when gives
.fl	{
	float: left;

<table class="fr" align="left"><tbody><tr><td>This table should float left.</td></tr></tbody></table>

and when gives

.fr	{
	float: right;

So, this is expected and the content should read instead

<table class="fl" align="right"><tbody><tr><td>This table should float left.</td></tr></tbody></table>

<table class="fr" align="left"><tbody><tr><td>This table should float right.</td></tr></tbody></table>


Can someone confirm, verify?
Comment 38 User image David Baron :dbaron: ⌚️UTC-8 2008-07-08 17:18:52 PDT
Maybe fixed by bug 43220?  Some further issues are covered by bug 252530.
Comment 39 User image Gérard Talbot 2008-07-08 17:36:18 PDT
> The original testcase gives me a HTTP 404.

Max, the tested stylesheet had to be downloaded first:

and the second test tests behavior with a user stylesheet.

Since this is the second test, you must download the stylesheet 
[ ] and set it up as your user stylesheet before proceeding.
Comment 40 User image Gérard Talbot 2008-07-08 17:43:46 PDT

your testcase works for me. I wish someone would verify and confirm my finding... so that we could safely resolve this bug.

I'll check bug 252530.

Comment 41 User image philippe (part-time) 2008-07-08 22:32:40 PDT
(In reply to comment #40)
> David, 
> your testcase works for me. I wish someone would verify and confirm my
> finding... so that we could safely resolve this bug.

Same findings as yours (comment 37) with 2008070802 Minefield/3.1a1pre OS X build

Comment 42 User image Gérard Talbot 2008-07-09 10:21:25 PDT
Ok, then.

Resolving as FIXED

Un grand merci, Philippe :) 

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