Early results on injecting style sheets into DOM

Eli Cochran eli at media.berkeley.edu
Tue Oct 14 16:21:27 UTC 2008


I think that Jacob's comment is good news. Although, as our css files  
get more sophisticated, especially as we try to make fairly global  
changes at run time for Transformable, we may run into problems. What  
I'm thinking of is a case where we were injecting a CSS file to change  
the global font size but still want the main css file to control the  
relative sizes for headers, etc.

I'll try to create some test cases for this.

- Eli

On Oct 13, 2008, at 11:09 AM, Jacob Farber wrote:

> Actually, I should revise:  other than the reset, the order of the  
> files doesnt matter. And the reset file is a nicety anyways.
>
>
> On Mon, Oct 13, 2008 at 2:06 PM, Jacob Farber  
> <jacob.farber at gmail.com> wrote:
> From what I've seen, as long as our stylesheets exist in the  
> document they operate as intended. The dependencies are not in the  
> order but rather that they exist at all.
> Jacob
>
>
> On Fri, Oct 10, 2008 at 5:44 PM, Antranig Basman <antranig at caret.cam.ac.uk 
> > wrote:
> Eli - this is really fantastically useful research, and addresses a  
> number of
> crucial issues that we are worried about. It, correct me if I am  
> wrong, looks
> "a bit grim" for any possibly "subtle" usage of CSS in this model -  
> is it
> fair to say that one must expect that the effects of CSS injection  
> to be
> treated as if they were essentially equivalent to styling rules with
> !important written on them? Or is it even more complex than that.
>
> Jacob - does it look like our proposed skinning system will be able  
> to function
> in such an environment, or will we have to insist that any users of  
> our
> style of ruleset have all of their CSS sheets physically written  
> into the
> document by the server?
>
> Eli - would it be possible to detect if there is any difference in  
> behaviour
> from the @import versus the <link style of referencing CSS?
>
> Look forward to the results of your future testing. Should we create  
> an area
> in our Confluence where we can have a "quirksMode" like "scoreboard"  
> of the
> different browsers under different situations?
>
> Marvellous stuff,
> Boz.
>
>
> Eli Cochran wrote:
> >
> > Background:
> > The skinning team is looking at ways to inject style sheets into  
> DOM at run-time as a
> > way to transform pages that we don't know very much about.
> >
> > Early results:
> > I'm still in the midst of my tests on injecting CSS style sheets  
> into the head using
> > Javascript.
> >
> > The good news is that it works on FF3 and Safari3 on the Mac and  
> FF3, IE6 and IE7 on
> > Windows. After the page has loaded you can inject a style sheets  
> into the HEAD and the
> > style changes are reflected in the DOM. Sweet!
> >
> > The bad news is that only FF3 and Safari seem to respect the CSS  
> hierarchy. Inject a
> > style sheet that sets your text to blue after all the other style  
> sheets in the HEAD,
> > and your text changes to blue, and then if you inject a style  
> sheet that changes all the
> > text to red before all the style sheets in the HEAD, your text  
> stays blue. Which is as
> > it should be, since the blue sheet still comes after the red sheet  
> in the hierarchy.
> > Happiness!
> >
> > But under the IEs if you follow the same steps, all your text  
> turns red. Whatever styles
> > get injected last, win, even if they were injected higher up in  
> the hierarchy. Sadness!
> >
> > Interestingly, if you inspect the DOM as reported to Debugbar from  
> IE, the stylesheets
> > are getting loaded into the DOM in the correct order, they just  
> aren't being parsed
> > correctly.
> >
> > This is still a technique that may be useful to us, but one of the  
> things that we could
> > not do is inject a CSS reset before all the other style sheets. We  
> would then crush any
> > subsequent styling.
> >
> > I still want to test what happens if I inject stylesheets after  
> the HEAD loads but
> > before the BODY loads and a few other things.
> >
> > More to come...
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>
>
>
> -- 
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
> www.fluidproject.org
>
>
>
>
> -- 
> Jacob Farber
> University of Toronto - ATRC
> Tel: (416) 946-3002
> www.fluidproject.org
>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20081014/2ffb2bdf/attachment.html>


More information about the fluid-work mailing list