Closed Bug 2942 Opened 26 years ago Closed 16 years ago

non-CSS presentational hints and user stylesheets [CASCADE]

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: dbaron, Unassigned)

References

(
URL
)

Details

(Keywords: css1, Whiteboard: [CSS1-3.2]) 

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.
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.
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?
Target Milestone: M7
Summary: non-CSS presentational hints and user stylesheets → {css1} non-CSS presentational hints and user stylesheets
Target Milestone: M10 → M11
Pushing off non-beta 1 issues
Reassigning peterl's bugs to myself.
Accepting peterl's bugs that have a Target Milestone
Although the only bug currently shown by the above test is the one with the FONT

element, there may be others.
Pushing my M15 bugs to M16
Keywords: css1
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...
Summary: {css1} non-CSS presentational hints and user stylesheets → non-CSS presentational hints and user stylesheets
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...
Target Milestone: M16 → M19
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".

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).
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.
Target Milestone: M19 → Future
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.
Keywords: nsbeta3
Depends on: 45240
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

*** Bug 45240 has been marked as a duplicate of this bug. ***
On a related matter, we also have bug 43220 ("author !important rules override 
user !important rules in user.css").

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.
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
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.
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!
[nsbeta3+].
Whiteboard: [nsbeta3+]
Priority: P2 → P1
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.
Priority: P1 → P5
Whiteboard: [nsbeta3+] → [nsbeta3+] [PDTP5]
Summary: non-CSS presentational hints and user stylesheets → non-CSS presentational hints and user stylesheets [CASCADE]
Changing to nsbeta3-.
Whiteboard: [nsbeta3+] [PDTP5] → [nsbeta3-] [PDTP5]
Support for user.css is gone in M18 ?
It's now userChrome.css (for the UI) or userContent.css (for web page content).
Keywords: nsbeta3 → mozilla1.0
Whiteboard: [nsbeta3-] [PDTP5]
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...
QA Contact: chrisd → ian
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.
Whiteboard: [CSS1-3.2]
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
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?
I wouldn't be surprised if fantasai's cascading changes fixed this.  However,
the original testcase should also be tested.
> 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.
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.
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.
OS: Windows 95 → All
Hardware: PC → All
The CSS working group has been hashing out exactly what CSS2.1 should say on
this topic.
Status: NEW → ASSIGNED
Priority: P5 → P2
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
Depends on: 234861
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
QA Contact: ian → style-system
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?
Maybe fixed by bug 43220?  Some further issues are covered by bug 252530.
> 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.
"
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
(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


Ok, then.

Resolving as FIXED

Un grand merci, Philippe :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.