[thelist] (Avoiding) CSS precedence

[Olivier Percebois-Garve]

If the widgets have to communicate with the rest of the page, or with
eachother, iframe will make that more difficult. Also there is a performance
penalty to the use of iframes.

On Tue, May 11, 2010 at 3:01 PM, Lee Kowalkowski <
lee.kowalkowski at googlemail.com> wrote:

> On 11/05/2010, Eike Pierstorff <eikepierstorff at googlemail.com> wrote:
> > The problem is of course that my HTML inherits CSS styles from the
> > host page, which breaks the layout of the widget, and I had somehow
> > underestimated how much trouble that would cause. It seems that I have
> > to reset every possible CSS property for every HTML element I use and
> > even so it might happen that some rule from the host site takes
> > precedence and breaks my code.
>
> Naturally, I don't think there's any way to guarantee your CSS
> selectors will be the most specific even when using an insane number
> of nested elements all with IDs.
>
> > Currently I'm using a lot of !important statements which make for a
> > terribly bloated style sheet and is by no means failsafe. Other
> > options I have considered so far
> >
> > - using iframes - the client specifically does not want this
>
> But this is the only real way to do it, it may also be more secure
> because other scripts won't be able to tamper with your widget, if
> that's of any concern.  With an iframe you get a dependable sandbox
> (it's essentially a separate window).
>
> > - using inline styles - makes for even more bloated code
>
> Inline style only takes precedence over the specified properties, for
> example, if you don't specify a line-height your widget can still be
> ruined.  Like you said, you'll need to specify every conceivable
> property, and to be future proof, all the properties that will be
> conceived in future too.
>
> > Is there any way to insert HTML markup into an arbitrary page and yet
> > avoid inheritance/precedence of the CSS of the host page (or another
> > way to solve the problem) ?
>
> Convert all your hard work to flash or a HTML5 Canvas?  The iframe is
> the 'standard' way.  Even the preview in the page you linked to is in
> an iframe.
>
> What does your client have against iframes?  Perhaps they have a
> misconception here and just need education or reassurance.  Of course
> iframes have potential issues but as long as they are understood and
> mitigated.  Most issues related to the use of iframes are not
> applicable to such widgets anyway.
>
> --
> Lee
> www.webdeavour.co.uk
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>