Closed
Bug 2942
Opened 26 years ago
Closed 17 years ago
non-CSS presentational hints and user stylesheets [CASCADE]
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: dbaron, Unassigned)
References
()
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.
Reporter | ||
Comment 1•26 years ago
|
||
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.
Reporter | ||
Comment 2•26 years ago
|
||
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?
Updated•26 years ago
|
Target Milestone: M7
Updated•26 years ago
|
Summary: non-CSS presentational hints and user stylesheets → {css1} non-CSS presentational hints and user stylesheets
Updated•26 years ago
|
Target Milestone: M10 → M11
Comment 3•25 years ago
|
||
Pushing off non-beta 1 issues
Comment 4•25 years ago
|
||
Reassigning peterl's bugs to myself.
Comment 5•25 years ago
|
||
Accepting peterl's bugs that have a Target Milestone
Reporter | ||
Comment 6•25 years ago
|
||
Although the only bug currently shown by the above test is the one with the FONT
element, there may be others.
Comment 7•25 years ago
|
||
Pushing my M15 bugs to M16
Comment 8•25 years ago
|
||
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...
Updated•25 years ago
|
Summary: {css1} non-CSS presentational hints and user stylesheets → non-CSS presentational hints and user stylesheets
Comment 9•25 years ago
|
||
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
Comment 10•25 years ago
|
||
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".
Reporter | ||
Comment 11•25 years ago
|
||
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•25 years ago
|
||
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
Reporter | ||
Comment 13•25 years ago
|
||
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
Comment 14•25 years ago
|
||
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•25 years ago
|
||
*** Bug 45240 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
On a related matter, we also have bug 43220 ("author !important rules override
user !important rules in user.css").
Reporter | ||
Comment 17•25 years ago
|
||
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.
Reporter | ||
Comment 18•25 years ago
|
||
Comment 19•25 years ago
|
||
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
Reporter | ||
Comment 20•25 years ago
|
||
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•25 years ago
|
||
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!
Updated•25 years ago
|
Priority: P2 → P1
Comment 23•25 years ago
|
||
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]
Updated•24 years ago
|
Summary: non-CSS presentational hints and user stylesheets → non-CSS presentational hints and user stylesheets [CASCADE]
Comment 25•24 years ago
|
||
Support for user.css is gone in M18 ?
Reporter | ||
Comment 26•24 years ago
|
||
It's now userChrome.css (for the UI) or userContent.css (for web page content).
Updated•24 years ago
|
Keywords: nsbeta3 → mozilla1.0
Whiteboard: [nsbeta3-] [PDTP5]
Comment 27•24 years ago
|
||
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
Comment 28•23 years ago
|
||
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.
Updated•23 years ago
|
Whiteboard: [CSS1-3.2]
Reporter | ||
Comment 29•23 years ago
|
||
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
Comment 30•23 years ago
|
||
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?
Reporter | ||
Comment 31•23 years ago
|
||
I wouldn't be surprised if fantasai's cascading changes fixed this. However,
the original testcase should also be tested.
Comment 32•23 years ago
|
||
> 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.
Reporter | ||
Comment 33•23 years ago
|
||
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•23 years ago
|
||
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
Reporter | ||
Comment 35•22 years ago
|
||
The CSS working group has been hashing out exactly what CSS2.1 should say on
this topic.
Status: NEW → ASSIGNED
Priority: P5 → P2
Comment 36•22 years ago
|
||
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
Reporter | ||
Updated•21 years ago
|
Reporter | ||
Updated•18 years ago
|
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
QA Contact: ian → style-system
Comment 37•17 years ago
|
||
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?
Reporter | ||
Comment 38•17 years ago
|
||
Maybe fixed by bug 43220? Some further issues are covered by bug 252530.
Comment 39•17 years ago
|
||
> 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•17 years ago
|
||
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•17 years ago
|
||
(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•17 years ago
|
||
Ok, then.
Resolving as FIXED
Un grand merci, Philippe :)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•