Closed Bug 41975 Opened 24 years ago Closed 19 years ago

Per-site user stylesheets

Categories

(Core :: CSS Parsing and Computation, enhancement, P5)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 238099
Milestone:
Future

People

(Reporter: cesarb, Assigned: dbaron)

References

Details

(Keywords: css-moz, helpwanted, Whiteboard: [Hixie-PF]) 

It would be cool to be able to use CSS cascading to 'style' pages on the web.
What I would like to see is preferences like the image blocker which allow:

1. Per-site (with globbing) specification of stylesheets to be loaded _first_
(before any style in the page)

e.g.: www.cnn.com -> mystyle1.css
www.cnn.com/subpage -> none
www.cnn.com/article*.html -> fakestyle.css

2. Idem, but to be loaded after all the styles (including inline ones and the
ones generated by font, color and other Transitional HTML niceties)

3. "Override" for certain stylesheets.
For example, slashdot.org/slashdot.css -> file.css would load the local file.css
after loading slashdot.org/slashdot.css (independent of which page we're in)

This would be the most useful one, since pages that share the same stylesheet
have special markup which allow easier overriding.

4. Global override (after all styles have been loaded) in any page

This is almost useless, but some people might find uses for it.

5. Idem but before any styles (the good old 'default browser styles' -- loaded
after the real mozilla default CSS)

6. Override for any page with no style at all (not even font or color)

Useful for making all dummy HTML 2.0 pages come up with white instead of gray in
the background, or any other related hacking.

I believe (3) (override for certain stylesheets) is the most useful one, but
implementing all of them would be nice and useful.

I hope someone understood this mess and can figure out which order would be the
Right One when more than one rule apply.
View | Use Stylesheet, when it's implemented, seems like it would do much of 
what you ask for [though it doesn't appear to be a pref]

rfe, confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
You can already have a global override stylesheet, just create:
   <profiledir>/chrome/user.css

We already support the "before/after" thing, it is called "!important", see the
specification for details.

A per-site stylesheet override feature would be nice, but I severely doubt that
Netscape will have the time to implement it for FCS. Marking Future, helpwanted.
(Is that ok Pierre?)
Keywords: helpwanted
Target Milestone: --- → Future
Since we are starting to use "Future" for the bugs that we would have really 
liked to put in 6.0 but won't because of a lack of time, I'm marking this one as 
LATER because the possibility to implement it is even more remote. I'm assuming 
that the Future bugs *will* be fixed in 6.01 or subsequent revisions.

A per-server or per-page stylesheet selection would be nice but let's face it, it 
would only be used by a few geeks.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
> it would only be used by a few geeks

I disagree. I think the same kind of people who would hack mozilla's skins
endlessly just to have a prettier desktop would also like to be able to do the
same to their favorite sites.

I agree my proposal was too complex for a newbie. But hacking mozilla skins is
too, and my proposal covers all cases.

Reopening and moving to Future; LATER is going away. Taking QA Contact. Updating
summary to more accurately reflect the latest conclusions in the above comments.
Moving to P5/enhancement; this is one of the lowest priority bugs in the entire
style system. :-)
Status: RESOLVED → REOPENED
Priority: P3 → P5
QA Contact: ckritzer → ian
Resolution: LATER → ---
Summary: [RFE] CSS cascading UI → Per-site user stylesheets
Whiteboard: [Hixie-PF]
I support reporter's request. Since there is no way to build a user stylesheet
valid for all sites (thanks to specificity), having a per-site user stylesheet
is a good idea (I submitted that idea to the CSS WG quite a long time ago ;-).



Completely agreed, but short of "rounded dots for dotted borders" I'm not sure
I can think of a less important CSS bug off-hand. :-)
Then why is bug 1515 P4?
yeah, Hixie why is that bug a P4 ?
Summary: Per-site user stylesheets → [RFE]Per-site user stylesheets
presumably because "nobody@mozilla.org" thinks it is a P4 bug. the Priority
field is totally under the control of the assignee, and priorities may have no
bearing between engineers. You'll note both bugs are "[Hixie-PF]", which is 
basically my own priority field.
remove self
Isn't this a dupe of bug 45848 (which blocks the tracking bug for this) ??
Re comment 12:

no.

Bug 45848 is about being able to change the stylesheet by hand to a local one.

This bug is about being able to do it automatically on certain sites or situations.

Both bugs are complementary (sp?). If bugzilla had a "related bugs" feature, it
would be the right one to describe the relationsheep between both.
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: REOPENED → NEW
*** Bug 152062 has been marked as a duplicate of this bug. ***
Summary: [RFE]Per-site user stylesheets → Per-site user stylesheets
a more general aproach (not site specific) would be to replace style-sheets
details at http://www-ti.informatik.uni-tuebingen.de/~thiele/userstyle/
sorry - just read the "bug" report once more and noticed that it is point 3 I
suggest ;-)
=> my vote is for point 3





An example of where this would be more than cosmetics:

https://my.palm.com/Email

You will see that the Username and Password text boxes are only ten pixels wide.
 This is because the webpage author checks to see what browser the visitor is
using, and then sends a browser-specific style sheet.  If the visitor is using
(or claims to be using) Internet Explorer, the author sets the textbox to 100
pixels.  If the visitor (claims s/he) is using Mozilla, the author sets the
textbox to 10 pixels.  As a consequence, the page looks bad with Mozilla, and it
sure looks like a Mozilla bug, even though it is an author bug, because
"internet explorer displays it properly."

If we had per-site user stylesheets, someone (some style geek) could provide a
corrective (in a Palm-users' forum, in this case) that visitors could apply.

It would also be useful for situations like in bug 159494.
Depends on: 179006
*** Bug 198169 has been marked as a duplicate of this bug. ***
galeon remembers the selected author style-sheet in the history (per host)

*** Bug 218833 has been marked as a duplicate of this bug. ***
Depends on: @-moz-document
Keywords: css-moz
So is this just a dupe of bug 238099, or is there anything in particular different?
my interpretation: this bug is for associating a stylesheet file to a given
location not simply the existance of a rule... if that is doable via some UI now
that the rule exists so be it, but I don't see the two issues being dupes, no.
Well, it's perfectly possible to do this now (in nightlies), I already do it for
a few sites. 

If this is really about UI, then it's never going to happen--it's way too much
of a power user feature, and the best UI for it anyway is a text editor; no
point in building one of those into Firefox when we have plenty on our computers
anyway.

If it's not about UI, though, then as far as I can tell it is a dupe.
Hasn't this been addressed with the @-moz-document at-rule?

@-moz-document domain('example.org'),
@-moz-document url-prefix('http://cgi.example.org/exact/prefix/'),
@-moz-document url('http://example.org/absolute/uri.html') {
  /* CSS only to be applied to aforementioned URIs and such */
  center { text-align: left !important; }
  em { font-weight: bold !important; font-style: normal !important; }
}
If he wants to, the reporter could file seperate bugs (or find them if they are
already filed, which I'm sure some of them are) for the remaining 5 issues in
the initial description.

*** This bug has been marked as a duplicate of 238099 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 19 years ago
Resolution: --- → DUPLICATE
Since the assignee of both this and bug 238099 are the same, and this was filed
by the assignee after being assigned this, I would have thought it should be his
decision whether this is a dupe or not.

This seems to me to have open issues dependant on bug 68416 or possibly other
open bugs besides bug 179006.
You need to log in before you can comment on or make changes to this bug.