Re: Pseudo-class :framed for the body element

[Thu, 3 Apr 2003 17:44:16 -0500 (EST)] m.m. wargers:
>Would it be useful if one could style a page differently if it is inside a frame?

I think so... but with a reservation.

I don't see much sense in distinguishing merely *whether* a document is
being shown in a frame, without any clue as to *which* frame it's in.  The
document might be loaded into a different site's frameset, which might
have nothing to do with one's reasons wanting to style the document
differently for display in the frame in which it was expected to appear.

At least, the obvious reasons that occur to me for wanting to be able to
change the style of a document when it appears in a frame would be to do
things like add "display: none" to elements that provide information or
functions already handled elsewhere in the frameset, while still making
sure they're available should the user load the page outside of the

One might expect <NOFRAMES> to handle this case; but the description, at:
is unclear to me.  The text says:
     User agents that support frames must only display the contents
     of a NOFRAMES declaration when configured not to display frames.
yet later in the same section indicates that:
     NOFRAMES may be used, for example, in a document that is the source
     of a frame and that uses the transitional DTD. This allows authors to
     explain the document's purpose in cases when it is viewed out of the
     frameset or with a user agent that doesn't support frames.
which suggests that NOFRAMES content in a non-FRAMESET document is meant
to be rendered whenever the document is not displayed in a frameset.

In any case, any reasonable method of handling this through CSS would
doubtless be far more flexible and convenient than NOFRAMES.  For whatever
reason, NOFRAMES is not allowed in the HEAD element, so it can't be used
to make STYLE or LINK elements conditional on being outside a frame; and
however the description of its processing is to be taken, NOFRAMES suffers
from the problem I mentioned above of not being able to tell *which* frame
contains the document.

It would make much more sense to me to extend FRAME and IFRAME to allow
them to provide a style sheet that would apply to the contained document.

One way that could be done (but now we're into HTML territory, not CSS)
would be to allow LINK elements following a FRAME or IFRAME tag; e.g.:
     <FRAME NAME="index" SRC="index.html">
     <LINK REL="stylesheet" TYPE="text/css" HREF="f1ix.css" TITLE="frame">
to add a "frame" style sheet and make "frame" the preferred style name.
(There is no conflict with the use of the content of an IFRAME as
alternate content, since LINK can't occur where IFRAME can; thus the
meaning of LINK elements contained in an IFRAME would be unambiguous.)

A preferred style name specified this way should take precedence over
a preferred style specified in the document itself; but aside from that,
the LINK element(s) should be processed as if it (they) occurred at the
beginning of the document loaded into the frame.

Alternatively --- though I don't like this as well, because it makes it
necessary to modify the *loaded* document and/or the style sheets it
references, which might not always be convenient, or even possible ---
one could allow FRAME and IFRAME elements to specify a class name for the
root of the loaded document:
     <FRAME NAME="index" SRC="index.html" ROOTCLASS="idxframe">
which would then make it possible for the style sheets referenced by the
document to distinguish the framed case by including the ".idxframe" class
selector in rules that should apply only when the document is contained in
this frame.

Of course, if you can depend on your target audience having ECMAScript
enabled, the whole problem can be solved trivially now by including
something like:
     <SCRIPT TYPE="text/javascript">
     if (parent.location.href ==

                + "/frameset.htm")
           '<LINK REL=stylesheet TYPE="text/css" HREF="framed.css">'
in the HEAD of the document to be loaded.
Randall Joseph Fellmy aka

Received on Monday, 7 April 2003 17:55:24 UTC