Last Comment Bug 2942 - non-CSS presentational hints and user stylesheets [CASCADE]
: non-CSS presentational hints and user stylesheets [CASCADE]
Status: VERIFIED FIXED
[CSS1-3.2]
: 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
:
:
Mentors:
http://dbaron.org/css/test/noncss2
: 45240 (view as bug list)
Depends on: 45240 234861
Blocks:
  Show dependency treegraph
 
Reported: 1999-02-04 21:06 PST by David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
Modified: 2009-01-19 09:39 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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,
http://www.w3.org/TR/REC-CSS2/cascade.html#q12 ), 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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
!-moz-preshint
(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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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
BGCOLOR=)
}

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 Peter Linss 1999-09-07 17:45:59 PDT
Pushing off non-beta 1 issues
Comment 4 Pierre Saslawsky 1999-10-21 01:07:59 PDT
Reassigning peterl's bugs to myself.
Comment 5 Pierre Saslawsky 1999-10-21 01:12:59 PDT
Accepting peterl's bugs that have a Target Milestone
Comment 6 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 Pierre Saslawsky 1999-12-20 21:10:59 PST
Pushing my M15 bugs to M16
Comment 8 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 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 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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 fantasai@escape.com:

Overview:
        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 - http://www.w3.org/TR/REC-CSS1#cascading-order
        CSS2:6.4.4 - http://www.w3.org/TR/REC-CSS2/cascade.html#q12

The testcase is in 2 parts:
  html file: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11289
  user stylesheet: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11290
Comment 15 Pierre Saslawsky 2000-07-18 16:19:10 PDT
*** Bug 45240 has been marked as a duplicate of this bug. ***
Comment 16 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2000-07-18 16:45:19 PDT
See www-style: http://lists.w3.org/Archives/Public/www-style/2000Jul/0022.html
Comment 19 fantasai 2000-07-18 16:54:30 PDT
Then <CENTER> should be treated differently from the other presentational 
elements?
<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.


[1] http://www.w3.org/TR/html4/present/graphics.html#edef-CENTER
Comment 20 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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 ekrock's old account (dead) 2000-08-01 15:02:43 PDT
[nsbeta3+].
Comment 23 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 karnaze (gone) 2000-09-21 11:15:07 PDT
Changing to nsbeta3-.
Comment 25 Jens 2000-10-04 12:39:35 PDT
Support for user.css is gone in M18 ?
Comment 26 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2000-10-04 12:43:42 PDT
It's now userChrome.css (for the UI) or userContent.css (for web page content).
Comment 27 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 Madhur Bhatia 2001-10-23 17:13:50 PDT
I visited the above mentioned url -
http://www.fas.harvard.edu/~dbaron/csstest/noncss2.html
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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2002-06-19 21:07:05 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 30 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 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 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?

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

I copied the content of 
http://dbaron.org/css/test/noncss.css
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 
http://dbaron.org/css/test/noncss2
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 http://dbaron.org/css/test/noncss.css gives
.fl	{
	float: left;
	}

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

and when http://dbaron.org/css/test/noncss.css 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>

WORKSFORME

Can someone confirm, verify?
Comment 38 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2008-07-08 17:18:52 PDT
Maybe fixed by bug 43220?  Some further issues are covered by bug 252530.
Comment 39 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 
[ http://dbaron.org/css/test/noncss.css ] and set it up as your user stylesheet before proceeding.
"
Comment 40 Gérard Talbot 2008-07-08 17:43:46 PDT
David, 

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.

Gérard
Comment 41 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 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.