Why does userChrome.css require a @namespace line? - Mozilla

This is a discussion on Why does userChrome.css require a @namespace line? - Mozilla ; /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 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Why does userChrome.css require a @namespace line?

  1. Why does userChrome.css require a @namespace line?

    /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.
    --
    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

  2. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > /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.
    >

    Hmm, good question. I don't know the answer, however, I do know that it
    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

  3. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > /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...t_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:

    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>

  4. Re: Why does userChrome.css require a @namespace line?

    Alex K. wrote:
    > Tony Mechelynck wrote:
    >> /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...t_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:
    >
    > > xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>
    >

  5. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > Alex K. wrote:
    >> Tony Mechelynck wrote:
    >>> /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...t_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:
    >>
    >> >> xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>
    >>

  6. Re: Why does userChrome.css require a @namespace line?

    Alex K. wrote:
    > Tony Mechelynck wrote:
    >> Alex K. wrote:
    >>> Tony Mechelynck wrote:
    >>>> /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...t_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:
    >>>
    >>> >>> xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"/>
    >>>

  7. Re: Why does userChrome.css require a @namespace line?

    On 29.07.2007 08:05, CET - what odd quirk of fate caused Tony
    Mechelynck to generate the following:? :
    > /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.
    >

    lookie-lookie at google... :-P

    http://www.google.com/search?hl=en&i...2@namespace%22

    hope you find a suitable explanation there! (No! I didn't read through
    the links)

    reg

  8. Re: Why does userChrome.css require a @namespace line?

    squaredancer wrote:
    > On 29.07.2007 08:05, CET - what odd quirk of fate caused Tony
    > Mechelynck to generate the following:? :
    >> /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.
    >>

    > lookie-lookie at google... :-P
    >
    > http://www.google.com/search?hl=en&i...2@namespace%22
    >
    > hope you find a suitable explanation there! (No! I didn't read through
    > the links)
    >
    > reg


    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
    /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."

  9. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > Alex K. wrote:




    >> Finally, there is this reference from the Mozilla Developer Center:
    >> http://developer.mozilla.org/en/docs...TML_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:
    >>
    >>
    >>
    >> * use Namespace.
    >>
    >>
    >>
    >> 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?
    >>

    >
    > 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".


    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.

  10. Re: Why does userChrome.css require a @namespace line?

    Alex K. wrote:
    [...]
    > 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

  11. Re: Why does userChrome.css require a @namespace line?

    On 01.08.2007 14:10, CET - what odd quirk of fate caused Tony
    Mechelynck to generate the following:? :
    > squaredancer wrote:
    >
    >> On 29.07.2007 08:05, CET - what odd quirk of fate caused Tony
    >> Mechelynck to generate the following:? :
    >>
    >>> /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.
    >>>
    >>>

    >> lookie-lookie at google... :-P
    >>
    >> http://www.google.com/search?hl=en&i...2@namespace%22
    >>
    >> hope you find a suitable explanation there! (No! I didn't read through
    >> the links)
    >>
    >> reg
    >>

    >
    > 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
    > /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.
    >

    hmmmm - as case of "I wonder...???" maybe a left-over from the original
    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

  12. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > squaredancer wrote:
    >> On 29.07.2007 08:05, CET - what odd quirk of fate caused Tony
    >> Mechelynck to generate the following:? :
    >>> /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.
    >>>

    >> lookie-lookie at google... :-P
    >>
    >> http://www.google.com/search?hl=en&i...2@namespace%22
    >>
    >> hope you find a suitable explanation there! (No! I didn't read through
    >> the links)
    >>
    >> reg

    >
    > 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
    > /chrome/userChrome.css for Gecko-powered programs?


    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.

  13. Re: Why does userChrome.css require a @namespace line?

    Alex K. wrote:
    > Tony Mechelynck wrote:
    >> squaredancer wrote:
    >>> On 29.07.2007 08:05, CET - what odd quirk of fate caused Tony
    >>> Mechelynck to generate the following:? :
    >>>> /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.
    >>>>
    >>> lookie-lookie at google... :-P
    >>>
    >>> http://www.google.com/search?hl=en&i...2@namespace%22
    >>>
    >>> hope you find a suitable explanation there! (No! I didn't read through
    >>> the links)
    >>>
    >>> reg

    >> 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
    >> /chrome/userChrome.css for Gecko-powered programs?

    >
    > 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.


    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

  14. Re: Why does userChrome.css require a @namespace line?

    Tony Mechelynck wrote:
    > Alex K. wrote:
    >> Tony Mechelynck wrote:




    >>> ... 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.

    >
    > 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


    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.

+ Reply to Thread