Why does userChrome.css require a @namespace line?
Tony Mechelynck
lines 12-15, line numbers added by me):
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, there is no explanation whatsoever of why this line is required, and
nobody that I know has ever had a problem for omitting it. So what's the
reason? I guess -- but it's only a guess -- that that line is there to protect
the user against a rare kind of exploit by some kind of Mozilla-directed
malware. But did I guess right, or not? If someone *really* in the know is
reading this, please reply -- and make an appropriate comment patch for the
file on the CVS tree which contains the text which ultimately gets copied to
userChrome-example.css, and attach that patch to Bugzilla bug 390011.
If, on the other hand, you are as much in the dark as I am, go vote for the
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=390011 -- the (vote) link is
near top right, above the "add CC" entry box.
Best regards,
Tony.
--
A [golf] ball hitting a tree shall be deemed not to have hit the tree.
Hitting a tree is simply bad luck and has no place in a scientific
game. The player should estimate the distance the ball would have
traveled if it had not hit the tree and play the ball from there,
preferably atop a nice firm tuft of grass.
-- Donald A. Metz
Sailfish
> <yourProfile>/chrome/userChrome-example.css contains the following
> warning (at lines 12-15, line numbers added by me):
>
> 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, there is no explanation whatsoever of why this line is
> required, and nobody that I know has ever had a problem for omitting it.
> So what's the reason? I guess -- but it's only a guess -- that that line
> is there to protect the user against a rare kind of exploit by some kind
> of Mozilla-directed malware. But did I guess right, or not? If someone
> *really* in the know is reading this, please reply -- and make an
> appropriate comment patch for the file on the CVS tree which contains
> the text which ultimately gets copied to userChrome-example.css, and
> attach that patch to Bugzilla bug 390011.
>
> If, on the other hand, you are as much in the dark as I am, go vote for
> the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=390011 -- the
> (vote) link is near top right, above the "add CC" entry box.
>
kind of acts like a demarcation point for using CSS "@import" AT-rules. ref:
http://www.w3.org/TR/REC-CSS2/syndata.html#at-rules
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
mozilla-based Themes: http://www.projectit.com/freestuff.html
Alex K.
> <yourProfile>/chrome/userChrome-example.css contains the following warning (at
> lines 12-15, line numbers added by me):
>
> 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 */
What this is saying is that the elements referred to in the CSS file,
will be as defined in XUL. As many have noted, there is nothing really
there, at that URL. The URL is used as a unique identifier for that
namespace.
The actual XUL elements are listed here, at MDC:
http://developer.mozilla.org/en/docs/XUL_Reference
> However, there is no explanation whatsoever of why this line is required, and
> nobody that I know has ever had a problem for omitting it. So what's the
> reason? I guess -- but it's only a guess -- that that line is there to protect
> the user against a rare kind of exploit by some kind of Mozilla-directed
> malware. But did I guess right, or not? If someone *really* in the know is
> reading this, please reply -- and make an appropriate comment patch for the
> file on the CVS tree which contains the text which ultimately gets copied to
> userChrome-example.css, and attach that patch to Bugzilla bug 390011.
Nope, wrong guess. :-)
I can't say I'm *really* "in the know". I do understand the concept of
namespaces, in a programming environment, from previous attempts at C++.
I know next to nothing about XUL, other than what I've picked up this
morning, researching this.
The best description I can find is here, albeit somewhat technical:
http://developer.mozilla.org/en/docs/XUL_Tutorial:Document_Object_Model
"As with each document, there is a different element object for XUL
elements as for HTML and XML elements. Every XUL element implements the
XULElement interface. A XUL element is any element declared with the XUL
namespace.
...
A namespace is a URI which specifies the kind of element. Here are some
examples:
<button
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>
<button xmlns="http://www.w3.org/1999/xhtml"/>
<html:button xmlns:html="http://www.w3.org/1999/xhtml"/>
<html:button
xmlns:html="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>
Namespaces are specified using the xmlns attribute.
[Edit: This seems to not be the case with the CSS file, as it is using
the @namespace syntax. - Alex]
* The first button is a XUL element as it has been placed in the XUL
namespace.
* The second element is an XHTML element as it has been given the
XHTML namespace.
* In the third example, the prefix 'html' is mapped to the namespace
'http://www.w3.org/1999/xhtml'. You can also use the prefix syntax with
a colon to use a specific namespace . This is used when you are using
several namespaces in a document and you need to be more precise with
which namespace is meant. This causes an XHTML button to be created for
this case.
* The fourth button is a little confusing, but might clarify that it
is the URI that is important and not the prefix. The fourth example is a
XUL button, not an HTML button, despite what the prefix might say.
This is an important distinction. In fact, the actual text used for the
prefix is irrelevant when determining what kind of element is used."
In layman's terms, what it all means is that you can have two different
elements with the same name, as long as you define separate namespaces
for them. As in the button example, above, the button object is defined
in *both* XUL and XHTML. So, if you have declared both namespaces, you
must specify *which* button you want.
Let me try a non-technical example:
You have two families, Smith and Jones. Both men are named John, and
both women are named Sue.
If I refer only to John, which one am I referring to, Smith or Jones?
This is what they call a "name collision". There are two people, or
elements, with the same name.
But if I first declare the last name, or namespace, to be Jones, and
then refer to John, there is no question that I am referring to John Jones.
If I then declare the namespace Smith, and refer to Sue, again, there is
no confusion. I am referring to Sue Smith.
I believe that is the reason for the statement not to delete the
namespace entry. At this time, there may not be anything added to that
file, that conflicts with a pre-defined XUL object. As long as there
are no name collisions, the file *will* work, without the namespace
declaration.
However, that could change in the future, so to avoid any potential name
collisions, they are explicitly defining the namespace for the standard,
XUL elements.
Now, maybe I come along with Alex's Super Widget, for example. I add
some custom elements with the same name as existing elements. No
problem, I just add a unique namespace declaration for my widget, before
I use my custom elements.
I don't know how you would *easily* and *understandably* explain that in
the comments, without bloating them. Perhaps just including a link to
the above page? Or another one, if there is a more "user friendly" one
out there.
Or perhaps a link to a page on the knowledge base, describing it? Of
course, the page would have to be created, and with a non-techie type
user in mind.
I guess what it really comes down to, is that if the devs state to do or
not do something with a file, there *is* a reason for it, even if it is
not immediately apparent to the layman. :-)
> If, on the other hand, you are as much in the dark as I am, go vote for the
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=390011 -- the (vote) link is
> near top right, above the "add CC" entry box.
--
Alex K.
Tony Mechelynck
b-b-but... wouldn't
button
{ -moz-border-radius: 4px !important
; background-color: #999 !important
}
(in a userChrome.css without @namespace) apply to any button? Similarly for
selectors with IDs and/or classes (for their respective scopes)? Or could you
give an example in which it wouldn't work?
To apply some rules to some elements and not to others, I could use classes
and/or IDs if defined, or else child/sibling/etc. from an identifiable
parent... There are a lot of IDs and classes defined in the browser chrome anyway.
Best regards,
Tony.
--
That secret you've been guarding, isn't.
Alex K.
Let me back up a bit, as I've learned a little bit more about this.
According to what I've read, namespaces are part of the CSS3 spec:
http://www.w3.org/TR/css3-namespace/
From what I have read, there are two ways to set the default namespace.
Either in the CSS file, with the @namespace declaration, or <some other
magic way in the application>.
In this case, they are specifiying the default namespace in the
userChrome.css file. If an element has specified its own namespace, a
generic 'button' statement will ignore anything prefixed with that
namespace. Anything without a namespace identifier, will be considered
to apply to the default namespace.
In CSS, you identify the namespace this way:
namespace prefix|element
Since the default namespace has been set to xul, it is not necessary to
specify the namespace prefix for xul elements. However, if there is an
additional namespace declared, any reference to elements in that
namespace must include the namespace prefix.
That's a summary of this:
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#simple-selectors
Perhaps a better example of this, rather than my widget example, can be
found here:
chrome://global/content/xul.css
(Don't know if that will show up as a link or not, if not just paste it
into the FF location bar.)
At the top of the file, there are three namespace declarations:
@namespace
url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /*
set default namespace to XUL */
@namespace html url("http://www.w3.org/1999/xhtml"); /* namespace for
HTML elements */
@namespace xbl url("http://www.mozilla.org/xbl"); /* namespace for XBL
elements */
You'll notice that in the XUL declaration, there is no 'xul' prefix
between the '@namespace' and the 'url()'. That is because they are
identifying it as the default. Basically, its saying that anything
without a namespace prefix will use this namespace.
The other two declarations define the prefix that will be used for those
namespaces, immediately after the '@namespace', 'html' and 'xbl'.
So, if we search that page for 'xbl', we find this:
/****** elements that have no visual representation ******/
script, data,
xbl|children,
<snipped a bunch of others>
{
display: none;
}
Since the default was set to XUL, the 'script' and 'data' elements are
in the XUL namespace, they do not need to specify the namespace. In
order to reference the XBL 'children' element, however, they had to
specify the xbl namespace. If they had not, then the rule would be
applied to XUL, and would hide all XUL children elements, which would
probably be a bad idea, I would imagine.
Now, when parsing this CSS file, the parser will only apply that rule to
*XBL* children elements, not to any other children elements. Further,
any other 'children' rules, without an 'xbl' prefix, will not affect XBL
children elements.
Similarly, if you search on 'html', you will find, outside of the html
namespace declaration, four rules affecting only html elements.
Finally, there is this reference from the Mozilla Developer Center:
http://developer.mozilla.org/en/docs/XUL_Coding_Style_Guidelines#XML.2C_XUL.2C_HTML.2C_and_XHTML_guidelines
XUL Coding Style Guidelines
XML, XUL, HTML, and XHTML guidelines
The following are considered good coding style for XML/XUL documents.
Disobeying them might not cause any parsing error for now, however, it
might cause future maintenance headache:
<snip>
* use Namespace.
<snip>
Now, I realize that they are identifying XML/XUL specifically, but since
the CSS alters the appearance of those, I'm reading that as indicating
that they may not be strictly enforcing it in the app at this time, that
it may work "for now", but that may change in the future. Hence, the
warning not to remove the @namespace declaration.
Is that better?
--
Alex K.
Tony Mechelynck
Well... Let's say I was totally in the dark, and now I feel like the moon has
risen. Not a noonday sun though.
So, IIUC, the reason the @namespace line is there is that "it is not required
now, but it may become so at some as-yet-unplanned time in a supposedly far
future". Well, I won't delete it from my own userChrome.css but, in the
future, neither will I try to convince the people who remove it (and boast
they do) to add it back.
The way I see it, if ever the code stops working without the @namespace line,
there will be such a hailstorm of bug reports from the people who
"misguidedly" removed it, that the devs will (I guess) have to revert to the
previous behaviour for upward-compatibility reasons. Of course, there have
been several documented times in the past when the devs have superbly ignored
pleas to keep past behaviour working, so I might quite well be wrong. So more
reason not to remove the line in my own files, "just in case".
Best regards,
Tony.
--
Oh Dad! We're ALL Devo!
squaredancer
Mechelynck to generate the following:? :
> <yourProfile>/chrome/userChrome-example.css contains the following warning (at
> lines 12-15, line numbers added by me):
>
> 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, there is no explanation whatsoever of why this line is required, and
> nobody that I know has ever had a problem for omitting it. So what's the
> reason? I guess -- but it's only a guess -- that that line is there to protect
> the user against a rare kind of exploit by some kind of Mozilla-directed
> malware. But did I guess right, or not? If someone *really* in the know is
> reading this, please reply -- and make an appropriate comment patch for the
> file on the CVS tree which contains the text which ultimately gets copied to
> userChrome-example.css, and attach that patch to Bugzilla bug 390011.
>
> If, on the other hand, you are as much in the dark as I am, go vote for the
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=390011 -- the (vote) link is
> near top right, above the "add CC" entry box.
>
>
> Best regards,
> Tony.
>
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22@namespace%22
hope you find a suitable explanation there! (No! I didn't read through
the links)
reg
Tony Mechelynck
Yeah, well, I guess that by reading some of these references I could get a
varnish of "what the notion of namespace means in CSS and XML" (references
outside Mozilla of course don't talk about XUL). But why specifically in
userChrome.css? What happens if the line is omitted, specifically in
<profile>/chrome/userChrome.css for Gecko-powered programs?
a) namespace-less selectors apply to everything?
b) namespace-less selectors apply to XUL because of a "browser default" for
chrome?
c) namespace-less selectors are treated as comments? (Experiment shows that
this is _currently_ not the case.)
d) currently like (b) but might change to (c) in some unspecified (and, I
guess, probably not anything near) future?
dbaron seems to imply (a) (at
https://bugzilla.mozilla.org/show_bug.cgi?id=390011#c4 ). Alex K. (in this
thread) seems to imply (d). I don't know what (or whom) to believe, possibly
in part because I don't know who is more familiar than whom with the ins and
outs of user CSS sheet parsing in Gecko.
... I wonder what would happen if I both removed the @namespace line and added
at the very bottom of the file something outlandish like:
* { background: red !important }
Would it apply to all chrome? To part of it? To all chrome _and_ all content?
Let's try. For the record, the program I'm trying it in is:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007073104
Minefield/3.0a7pre
Result: the red background applies to most of the chrome (but not all: in
particular, selected elements keep their distinctive colouring, at least
around the text), and none of the HTML content. Popups (and toolbars) are
mostly red with some grey around the text... (hm, what are those sites which
want to set cookies even though the page I'm displaying is a "file" URL?
- sb.google.comm
- add.my.yahoo.com
- fusion.google.com
Note to myself: Investigate later.)
Everything remains legible, though in some cases (e.g. disabled menu items)
barely. "Customizing a toolbar" by dragging, moves a very big red rectangle
which obliterates whatever is "covered" by it.
On the whole, nothing really unexpected. Let's leave it like that (but only in
Minefield, which I only use occasionally) to tell me what the universal
selector applies to.
Best regards,
Tony.
--
"There's nothing wrong with teenagers that reasoning with them won't
aggravate."
Alex K.
> Alex K. wrote:
<snip>
Well, I agree that there will be an outcry if/when the people who did
remove that line have their customizations break.
But, in *this* particular case, if it does break in the future, I see it
as a case of "Well, you were told *not* to take that line out, so what
do you expect?". I could understand your position, *if* there were no
warning about it. But here, there is a clear statement to not remove
it. Granted, it could/should be clarified a little, to add that it may
work now, without it, but that it could break in the future. But, even
as it is, IMO, the statement still stands as a warning to the user.
--
Alex K.
Tony Mechelynck
[...]
> Well, I agree that there will be an outcry if/when the people who did
> remove that line have their customizations break.
>
> But, in *this* particular case, if it does break in the future, I see it
> as a case of "Well, you were told *not* to take that line out, so what
> do you expect?". I could understand your position, *if* there were no
> warning about it. But here, there is a clear statement to not remove
> it. Granted, it could/should be clarified a little, to add that it may
> work now, without it, but that it could break in the future. But, even
> as it is, IMO, the statement still stands as a warning to the user.
>
>
Yeah, that's why I leave it in my "day-to-day" profiles. In my "testing"
profile for Minefield, I am commenting it out (not erasing it without trace)
and adding
* { background: red !important }
at bottom, so (IIUC) I'll be able to see it if ever it gets applied to
anything where it shouldn't (e.g. anything not in chrome) or if it starts
_not_ being applied.
IOW, in that "testing" profile only, I'm disobeying the "rule" but with my
eyes open, and with an easy way to re-enable the @namespace line if necessary.
Best regards,
Tony.
--
Man is the best computer we can put aboard a spacecraft ... and the
only one that can be mass produced with unskilled labor.
-- Wernher von Braun
squaredancer
conception, where the @namespace was conceived to reserve a function for
some (distantly possible) feature?? without any deep-sea-diving into the
actual effects of deleting the line, most discussion is a bit
theoretical, methinks! "Trial-and-Error" reigns *lol*
reg
Alex K.
Thats the part where I can't say what is happening. I'm not a dev. I'm
basing my comments on what the CSS specs have to say about namespaces.
> a) namespace-less selectors apply to everything?
>
> b) namespace-less selectors apply to XUL because of a "browser default" for
> chrome?
>
> c) namespace-less selectors are treated as comments? (Experiment shows that
> this is _currently_ not the case.)
>
> d) currently like (b) but might change to (c) in some unspecified (and, I
> guess, probably not anything near) future?
>
> dbaron seems to imply (a) (at
> https://bugzilla.mozilla.org/show_bug.cgi?id=390011#c4 ). Alex K. (in this
> thread) seems to imply (d). I don't know what (or whom) to believe, possibly
> in part because I don't know who is more familiar than whom with the ins and
> outs of user CSS sheet parsing in Gecko.
I believe that David is a developer, at least, he is listed in the
credits, and has a @mozilla.com address. Take my word on this: Always
trust a dev before you trust me. :-)
You can rest assured that I am in no way familiar with the "ins and
outs" of Gecko!
My reference about your behavior (b), was based on something I read,
somewhere, that basically said either the CSS file can specify the
default namespace or the implementing application can specify it (the
details of which, I know nothing about.) I'll have to go back through
my history, to see if I can find it again. I didn't bookmark it. :-(
> ... I wonder what would happen if I both removed the @namespace line and added
> at the very bottom of the file something outlandish like:
>
> * { background: red !important }
>
> Would it apply to all chrome? To part of it? To all chrome _and_ all content?
> Let's try. For the record, the program I'm trying it in is:
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007073104
> Minefield/3.0a7pre
>
> Result: the red background applies to most of the chrome (but not all: in
> particular, selected elements keep their distinctive colouring, at least
> around the text), and none of the HTML content. Popups (and toolbars) are
> mostly red with some grey around the text... (hm, what are those sites which
> want to set cookies even though the page I'm displaying is a "file" URL?
> - sb.google.comm
> - add.my.yahoo.com
> - fusion.google.com
> Note to myself: Investigate later.)
>
> Everything remains legible, though in some cases (e.g. disabled menu items)
> barely. "Customizing a toolbar" by dragging, moves a very big red rectangle
> which obliterates whatever is "covered" by it.
>
> On the whole, nothing really unexpected. Let's leave it like that (but only in
> Minefield, which I only use occasionally) to tell me what the universal
> selector applies to.
Note: I tested this using 2.0.0.6, so I realize its not exactly the same
as your test.
Do you have any bookmarks or bookmark folders on the bookmarks toolbar?
I have one folder and two bookmarks there.
When I applied your changes, the items on the bookmark toolbar are
invisible. They are still there, but the icons and text are gone,
apparently obliterated by the red background. The entire toolbar is
just solid red.
If I hover over them, I'll get the little popup tooltip that tells me
the name of the bookmark & the URL, but that is the only indication that
there is anything there.
None of the other toolbars show this problem, that I noticed. All of
the icons and text are where they should be.
Now, I don't know how/where that toolbar is implemented, in the code,
but I'm curious to see how those items are built. I'll have to go
digging into it, but don't have time right now. I'll have to look at it
later today.
--
Alex K.
Tony Mechelynck
I think I don't display the bookmarks toolbar; but I checked the bookmarks
manager. IIRC its insides weren't red, only its menus etc. were. OTOH the
Preferences popup was all red but I regard that as "expected" behaviour.
>
> If I hover over them, I'll get the little popup tooltip that tells me
> the name of the bookmark & the URL, but that is the only indication that
> there is anything there.
>
> None of the other toolbars show this problem, that I noticed. All of
> the icons and text are where they should be.
>
> Now, I don't know how/where that toolbar is implemented, in the code,
> but I'm curious to see how those items are built. I'll have to go
> digging into it, but don't have time right now. I'll have to look at it
> later today.
>
It's in XUL, I think, and the code ought to be findable. I've seen a list of
chrome URLs a few days ago... let me see whether I bookmarked it... ah, there,
even two lists:
http://kb.mozillazine.org/Dev_:_Firefox_Chrome_URLs
http://kb.mozillazine.org/Chrome_URLs
Best regards,
Tony.
--
TIM: But follow only if you are men of valour. For the entrance to this cave
is guarded by a monster, a creature so foul and cruel that no man yet has
fought with it and lived. Bones of full fifty men lie strewn about its
lair ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Alex K.
> Alex K. wrote:
>> Tony Mechelynck wrote:
<snip>
Thanks, I did start to look yesterday, until that thing called life
interrupted again. :-)
What I'm really curious about, is the difference between the regular
toolbar buttons and the bookmarks toolbar buttons. Why do the regular
toolbar button icons/text show up, but they do not show on the bookmarks
toolbar?
I'll try to take a look today. Thanks for the links.
--
Alex K.