Setting default stylesheets
Ben Hutchings
embedding Mozilla. It appears that I can use
nsIPresShell::SetAgentStyleSheets to change them, but I don't see how
to load a CSS stylesheet and obtain the interface pointer I would pass
into this function. How should I do that?
--
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.
Boris Zbarsky
> It's not clear to me how to override the default stylesheet(s) when
> embedding Mozilla.
You can use nsIStyleSheetService to load additional style sheets. If you want
to modify the existing ones, and you're shipping your own gecko, you can always
just edit ua.css...
-Boris
Ben Hutchings
> Ben Hutchings wrote:
>> It's not clear to me how to override the default stylesheet(s) when
>> embedding Mozilla.
>
> You can use nsIStyleSheetService to load additional style sheets.
Oddly I can only find an IDL file for that, not a header file (LXR
denies all knowledge of the identifier). Should I attempt to generate
a header file, and how should I find a/the implementation of it at
run-time?
> If you want to modify the existing ones, and you're shipping your
> own gecko, you can always just edit ua.css...
I was hoping to get away with using an existing installation, at
least in my current environment (Debian).
Ben.
Boris Zbarsky
> Oddly I can only find an IDL file for that, not a header file
The nsIStyleSheetService.h header is generated via xpidl.
> (LXR denies all knowledge of the identifier).
Yeah, lxr kinda sucks like that.
> Should I attempt to generate
> a header file, and how should I find a/the implementation of it at
> run-time?
getService() the "@mozilla.org/content/style-sheet-service;1" contract.
-Boris
Ben Hutchings
for you.
Boris Zbarsky <bzba...@mit.edu> wrote:
> Ben Hutchings wrote:
>> Oddly I can only find an IDL file for that, not a header file
>
> The nsIStyleSheetService.h header is generated via xpidl.
I figured it was something like that, but didn't know what the tool
was - I've used COM previously but not XPCOM. Is it a frozen
interface? If not, do you have any suggestions for how to find the
relevant version of the interface definition? Debian's mozilla-dev
package doesn't include the IDL file. Could this be considered a
packaging bug?
>> (LXR denies all knowledge of the identifier).
>
> Yeah, lxr kinda sucks like that.
Can it not parse IDL files?
>> Should I attempt to generate
>> a header file, and how should I find a/the implementation of it at
>> run-time?
>
> getService() the "@mozilla.org/content/style-sheet-service;1" contract.
Great. Thanks.
Boris Zbarsky
> I figured it was something like that, but didn't know what the tool
> was - I've used COM previously but not XPCOM. Is it a frozen
> interface?
Not yet, no.
> Debian's mozilla-dev
> package doesn't include the IDL file. Could this be considered a
> packaging bug?
Hmm... Which version are they packaging? This interface did not exist in the
1.7 version of Gecko.
If you're working against 1.7, then things are harder. You may have to go back
to that nsIPresShell business.
>> Yeah, lxr kinda sucks like that.
>
> Can it not parse IDL files?
It can, and does. But it has a tendency to sometimes miss identifiers, in both
IDL and C++...
-Boris
Ben Hutchings
>> Debian's mozilla-dev
>> package doesn't include the IDL file. Could this be considered a
>> packaging bug?
>
> Hmm... Which version are they packaging? This interface did not exist in the
> 1.7 version of Gecko.
>
> If you're working against 1.7, then things are harder. You may have to go back
> to that nsIPresShell business.
It's 1.7.8.
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
Boris Zbarsky
> It's 1.7.8.
OK. Then there is no really clean way to do it... You can try creating a
CSSLoader (nsICSSLoader.h) and using it to load sheets, then using
SetAgentStyleSheets() on the presshell, I guess.
-Boris
Ben Hutchings
That works for me, though it took me a while to work out that some of
my rules were being overridden by the default "preferences". I'm now
also calling EnablePrefStyleRules(false) to avoid this.
Something I don't understand is that I apparently have to do this for
each page. How do Seamonkey and Firefox set stylesheets to be applied
to all pages, and can I do the same?
Boris Zbarsky
> Something I don't understand is that I apparently have to do this for
> each page. How do Seamonkey and Firefox set stylesheets to be applied
> to all pages
There are hardcoded URIs to the sheets in the C++.
> and can I do the same?
Yes, if you change the C++ involved...
In 1.8-based builds, the stylesheet service does that work for you, but with
1.7, you have to do it for each page. :(
-Boris
Ben Hutchings
I'll carry on doing that for now, then. Thanks; you've been very
helpful.
I don't suppose you can help with my other query about link extents?
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
Boris Zbarsky
> I don't suppose you can help with my other query about link extents?
I'm not sure I saw this query.
-Boris
Ben Hutchings
Then I'll post it again:
I'm working on an application that uses Mozilla to render pages for
inclusion on a DVD. DVDs can only include MPEG video and overlaid
bitmaps (subpictures) with a limited palette. So I convert the page
into an MPEG video, set each link into its hover and active states and
copy the changes in appearance into a subpicture. (I assume that
state changes don't cause reflow, though I know it isn't guaranteed.)
Currently I'm using nsIDOMNSDocument::GetBoxObjectFor to find the
extents of each link before scanning for changes, but this doesn't
always provide the correct extents for my purposes. In particular,
the extents for links that contain images appear to be limited to the
height of a line of a text. Is there a better way to do this, or
should I look for changes across the whole window?
Boris Zbarsky
> Currently I'm using nsIDOMNSDocument::GetBoxObjectFor to find the
> extents of each link before scanning for changes, but this doesn't
> always provide the correct extents for my purposes.
What do you mean by "extents of each link", exactly? Given positioned content,
etc, a state change on the link can affect arbitrary bits in the final rendered
bitmap.
-Boris
Ben Hutchings
The extents of the content of the link. If the change of link state
causes the link content to change position or size, I would consider
that an error (and report it, if I can detect it).
Boris Zbarsky
> The extents of the content of the link.
You mean the smallest rectangle that contains all the layout objects
corresponding to descendants of the link DOM node in the DOM?
You can get that by getting the rectangles for all those nodes and taking the
minimal bounding rectangle... There's no one-stop place for this information.
Note, however, that change of state on a link can also affect rendering of the
link's siblings in the DOM, what with the CSS '+' and '~' combinators.
-Boris
Ben Hutchings
> Ben Hutchings wrote:
>> The extents of the content of the link.
>
> You mean the smallest rectangle that contains all the layout objects
> corresponding to descendants of the link DOM node in the DOM?
I suppose so, yes.
> You can get that by getting the rectangles for all those nodes and taking the
> minimal bounding rectangle... There's no one-stop place for this information.
OK, I can manage that.
> Note, however, that change of state on a link can also affect rendering of the
> link's siblings in the DOM, what with the CSS '+' and '~' combinators.
I realise there are things like this that I won't catch, but I think I
can live with documenting those as limitations. The idea is simply to
let people use a familiar format and tools, not to support arbitrary
existing web pages. For example, pages will have to fit on the screen
rather than being scrollable, and if I'm not mistaken there will be a
limit of 36 links per page.
Boris Zbarsky
> The idea is simply to let people use a familiar format and tools, not to support arbitrary
> existing web pages.
Ah, ok. That makes life simpler. ;)
-Boris