RE: OBJECT, inheritance, and rendering

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org]On
> Behalf Of Simon Richter
> Sent: Wednesday, July 29, 1998 6:16 PM
> To: braden@endoframe.com
> Cc: 'Todd Fahrner'; www-style@w3.org; www-html@w3.org
> Subject: Re: OBJECT, inheritance, and rendering

[shnip]

> > blue? I would. Therefore I'd also expect this code to
> render the same way:
> >
> >         <OBJECT DATA="myimage.png" TYPE="image/png"
> >         STYLE="background-color: blue">My Image</OBJECT>
> >
> > It seems reasonable to extend this to text documents, and
> probably other
> > media that do not inherently specify a background color.
>
> Well, but I would at least like to see some mechanism to turn
> this off.

How do you mean? If you have control over the background color, you can turn
it to whatever you like (including "transparent).

> > I suggest a
> > stickier situation is this:
> >
> >         <OBJECT DATA="mytext.txt" TYPE="text/plain"
> >         STYLE="color: red" HEIGHT="100%" WIDTH="100%">My Text
> >         </OBJECT>
> >
> > Obviously the (fallback) contents of the OBJECT element
> should be rendered
> > in red. But what about the referenced text file?
>
> I think the referenced text file should be rendered in red,

With this I agree...

> but the fallback
> contents should not be affected.

But this makes no sense to me. What you're describing is the general problem
of a browser that supports CSS, but may not support certain HTML elements.
As the HTML elements are the mechanism by which the styles are applied,
obviously an unrecognized element would not be able to convey a style. Would
you also argue that the style on

	<ACRONYM STYLE="color: red">FUBAR</ACRONYM>

should be uniformly ignored because some browsers do not recognize ACRONYM?

> There are many browsers
> (e.g. Netscape 4) out
> there that do not support <OBJECT>, but do recognize style sheets. For
> compatibility, those browsers should still be safe to ignore
> tags they don't
> know. So the style attribute of the object tag should refer
> to the embedded
> object, while the fallback text should be enclosed in <SPAN
> STYLE="">...</SPAN>.

I don't get it. Why should an OBJECT container be required to behave so
drastically differently from every other container where style sheets are
concerned?

> > Should the text for it be
> > rendered in red? Let's not think about this problem just
> for text files, but
> > for *any* monochromatic inclusion via object; I think they
> should all be
> > treated the same way.
>
> Indeed.

What about objects that are monochromatic + an alpha channel? Ponder,
ponder... Should the monochromatic bit element values just be treated the
same as the alpha values at 0 and 100%?

[snip]

> <TABLE>
>   <TR>
>     <TD STYLE="background-color: black;">
>       <OBJECT DATA="text1.html" TYPE="text/html">
>     </TD>
>     <TD STYLE="background-color: blue;">
>       <OBJECT DATA="text2.html" TYPE="text/html">
>     </TD>
>   </TR>
> </TABLE>
>
> Now in this example, I would certainly like to have the first
> OBJECT displayed
> with a black background, the second with a blue one. If the
> HTML files (and
> their style sheets) do not specify colors, this should be
> possible (if they
> contain color information, their colors will be used).

More accurately... If the style sheets for the HTML files specify
"transparent" as the background color, then the colors of the host document
will show through... yes? The color can't be "not specified," as
"background-color" (along with all the other CSS properties, AFAICT) is not
allowed to have no value. If it is not explicitly set, it keeps the default
value of "transparent".

Note that this mechanism involves no inheritance of styles, and seems to me
the natural behavior for "transparent" anyway.

> With
> your syntax, I would
> need to give the OBJECTs ids, then set the background color
> in the stylesheet.

Not so... see above.

> With "OBJECT {inherit-colors: yes;}" they could easily take
> over the table's
> colors.

I still don't see how this is necessary. Recall that background colors are
*not* inherited in CSS--the default value is "transparent" so that the color
of the parent element can show through. If "background" for OBJECT is just
treated the same as it is for IMG, then it seems to me that the case you
describe works itself out.

> > > > Now suppose OBJECT references an HTML file. [...]
>
> > [...] the HTML file in the <OBJECT>
> > > sits in its own box, and should not be interfere with
> > > what it outside. It can inherit stylesheet
> > > settings from the outer HTML file, however.
> >
> > This, I submit, would be a mistake. AFAICT, there is no
> inheritance rule to
> > deal with this.
>
> Well, but there should be (same table example as above)... :-)

There doesn't need to be. :-) (per comments above re. "transparent")

> > > IMHO the inner HTML file's style information gains
> > > precedence [...]
> >
> > In a browser that supports CSS, doesn't an HTML file
> *always* have its own
> > style sheet, by virtue of the presence of defaults on the
> CSS properties? So
> > the default style sheet has precendence, and (taking
> !important declarations
> > out of consideration for the moment) replaces the styles in
> the outer
> > document.
>
> Well, okay, that was unclear... IMHO the style information
> that was specified in
> the outer document to be handed down to the inner document
> should be parsed
> after the UA default and user style sheets, but before the
> inner document's own
> style sheet. Only this way we can specify things like
> background-color in the
> outer document, but leave the option of overriding this in
> the inner document.

"Background" properties are clearly a bad example for the case you're trying
to address. Can you show how the inheritance rule you describe would be
desirable for properties that actually inherit?

Braden

Received on Wednesday, 29 July 1998 23:01:44 UTC