 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev- | Prev- | Mozilla- | Jul- | Next- | Next- |
| Subject: | Re: Why does userChrome.css require a @namespace line? |
| Group: | Mozilla-support-firefox |
| From: | Alex K. |
| Date: | 31 Jul 2007 |
Tony Mechelynck wrote:
> Alex K. wrote:
>> Tony Mechelynck wrote:
>>> <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.
>
> 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.
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_H TML.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.
_______________________________________________
support-firefox mailing list
support-firefox
https://lists.mozilla.org/listinfo/support-firefox
To unsubscribe, send an email to support-firefox-request?subject=unsubscribe
| Prev- | Prev- | Mozilla- | Jul- | Next- | Next- |