Open
Bug 390011
Opened 18 years ago
Updated 3 years ago
userChrome-example.css doesn't say _why_ a @namespace line is required for correct functioning
Categories
(Toolkit :: Startup and Profile System, defect)
Toolkit
Startup and Profile System
Tracking
()
UNCONFIRMED
People
(Reporter: tonymec, Unassigned)
Details
(Whiteboard: [all versions])
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072804 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007072804 Minefield/3.0a7pre
See "Steps to Reproduce" below.
Reproducible: Always
Steps to Reproduce:
1. Find your (default) profile folder.
2. Go to its chrome/ subfolder.
3. Load userChrome-example.css in any pure-text editor such as WordPad, gvim, etc.
Actual Results:
Near the top, there are the following lines (line numbers added below, are not actually in the file):
12: /*
13: * Do not remove the @namespace line -- it's required for correct functioning
14: */
15: @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */
However, nothing says _why_ this line is required for correct functioning
Expected Results:
The comment should be expanded to tell the user to what kind of evils he would be leaving himself open by omitting the @namespace line.
Additional info:
As far as anyone can tell, the browser functions identically with or without the @namespace line in userChrome.css (which doesn't exist by default, but userChrome-example.css does). This apparently "identical" functioning, together with the lack of any explanation that anyone can find concerning the "why" of this @namespace line, has led to considerable skepticism among the users, as can be seen, for instance, by perusing the mozilla.support.firefox newsgroup on the news.mozilla.org.server. Some say "I can't tell whether it's required or not, therefore I accept -- until proof of the contrary -- the advice of the Mozilla developers." Many others reply: "Experiment shows that the functioning is identical with or without that line. Therefore I apply Occam's razor and omit everything which is not obviously required -- including the @namespace line." In the absence of any argument (other than the argument of authority) in its favour, the defensors of that line are hard put to explain their error to the other group.
-- If, on the other hand, the line is in fact /not/ required, then it (and its foregoing comment) should disappear from userChrome-example.css altogether (as set up by Firefox when creating the default profile).
Reporter | ||
Updated•18 years ago
|
Whiteboard: [all versions]
Comment 1•18 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072822 Minefield/3.0a7pre
Personally I don't have that line in userChrome.css.
As a side note: most users see the bunch of text in userChrome-example.css as something incomprehensible. Problems appear when they don't delete everything but start deleting somewhere in the middle of the text that is commented out.
Comment 2•18 years ago
|
||
Why *is* it there? To prevent rules intended for XUL elements from accidentally applying to elements from other namespaces that happen to be in chrome?
Reporter | ||
Comment 3•18 years ago
|
||
According to posts by "Alex K" in the thread "Why does userChrome.css require a @namespace line?" at nntp://news.mozilla.org/mozilla.support.firefox , and to my understanding of them, the @namespace line is perhaps not needed _now_ but it may become actually required at any (unspecified) time in some (possibly far) future, so it's "better" to leave the line there in case some future browser version stopped setting the "browser default namespace" to XUL when parsing userChrome.css
Personally, I would not advise removing that default setting -- it is logical and allows the userChrome.css sheet to work even when the user "misguidedly" removes the line -- but who am I to advise? There have been cases in the past when functionality has been removed for no apparent reason (the throbber link is the first example that pops into my mind), so I guess users had better leave that line there just in case, at some future time, the devs decided to ignore what users actually do and focus on what they "ought" to do, and set the default namespace to null instead of XUL at the start of the parse of userChrome.css, so that any namespace-less rules in it would thenceforward apply to no elements whatsoever.
Go read that thread though -- I don't claim I've perfectly understood all that Alex said.
(In reply to comment #2)
> Why *is* it there? To prevent rules intended for XUL elements from
> accidentally applying to elements from other namespaces that happen to be in
> chrome?
Exactly.
Comment 5•18 years ago
|
||
I vote for replacing
"Do not remove the @namespace line -- it's required for correct functioning"
with something like
"Prevent rules intended for XUL elements from accidentally applying to elements from other namespaces".
(I'm under the impression that without a @namespace line, rules apply to elements from all namespaces, so there isn't a danger of something changing and breaking all user stylesheets that omit the line.)
(In reply to comment #5)
> I vote for replacing
>
> "Do not remove the @namespace line -- it's required for correct functioning"
>
> with something like
>
> "Prevent rules intended for XUL elements from accidentally applying to elements
> from other namespaces".
May I suggest that, rather than replacing the original, that your proposed text be added? So the end result is something like:
"Do not remove the @namespace line -- it's required for correct functioning, to prevent rules intended for XUL elements from accidentally applying to elements from other namespaces."
Reporter | ||
Comment 7•18 years ago
|
||
(In reply to comment #6)
[...]
> May I suggest that, rather than replacing the original, that your proposed text
> be added? So the end result is something like:
>
> "Do not remove the @namespace line -- it's required for correct functioning, to
> prevent rules intended for XUL elements from accidentally applying to elements
> from other namespaces."
>
It seems not to be _currently_ required for correct functioning. (I'm taking no bets about the future in this comment):
Experiment: add /* and */ around the @namespace line (not including its associated comments), and add the following (sweeping) rule at the very bottom of the file:
* { background: red !important }
I don't see anything in red which shouldn't be, according to my interpretation of this rule (apply a red background to everything in chrome). In particular, none of the "content" gets that red background, not even HTML pages which I wrote myself and don't set the background.
Program version used for the above experiment:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007073104 Minefield/3.0a7pre
Assignee | ||
Updated•17 years ago
|
Product: Firefox → Toolkit
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•