OBJECT: size rendering

[Hans Dietmar Jaeger]

Hello again, you helped me out with the OBJECT-tag, thanks. But I can't
find anything about who the size of the OBJECT to be rendered is
calculated:-|

Ok, if the OBJECT is an image, it's it natural size (defined in the
header of the OBJECT). But now the OBJECT is a HTML-page; and this page
consist of javascript code to build the HTML-source!

I embedded an OBJECT with type text/html that consisted of only one
simple plain HTML code: <font color="#ff0000">hello world!</font> It ist
displayed correctly. But I do not gave an width/height attribute to the
OBJECT-tag:
<object border="1" type="text/html" data="object_text.html"></object>

border attribute only to see the size of the rendered object. And that
is much more than the natural size of the HTML code!

Ok, when the size cannot be calculated on-the-fly, I will give an
expicit width/height-attribute; but these attributes must be calculated
regarding the actual font size (height/width/style)! How can I do this?!

Perhaps the flexibility of the OBJECT-tag is not intendet to do those jobs.

Any comments/help?

Thank you,

jagger

 

[Spartanicus]

Hello again, you helped me out with the OBJECT-tag, thanks. But I can't
find anything about who the size of the OBJECT to be rendered is
calculated:-|

Ok, if the OBJECT is an image, it's it natural size (defined in the
header of the OBJECT). But now the OBJECT is a HTML-page; and this page
consist of javascript code to build the HTML-source!

I embedded an OBJECT with type text/html that consisted of only one
simple plain HTML code: <font color="#ff0000">hello world!</font> It ist
displayed correctly. But I do not gave an width/height attribute to the
OBJECT-tag:
<object border="1" type="text/html" data="object_text.html"></object>

border attribute only to see the size of the rendered object. And that
is much more than the natural size of the HTML code!

If you analyze the finer detail of the CSS spec, CSS capable and enabled
browsers should determine the size of embedded HTML, despite the fact
that it has no /intrinsic/ size. However no browser that I know of does
that. Without a specified width and height a browser may collapse width
and height of the viewport established by the object element to 0 (IE),
or default to a certain non zero value (Opera, Gecko).

Ergo when embedding HTML you should always specify a width and height
for the viewport established by the object element via the width and
height attributes on the object element. Since you can only specify a
size in pixels that way, you could elect to also specify a width and/or
height with CSS, in which case you have other units available.

 

[Hans Dietmar Jaeger]

Ergo when embedding HTML you should always specify a width and height
for the viewport established by the object element via the width and
height attributes on the object element. Since you can only specify a
size in pixels that way, you could elect to also specify a width and/or
height with CSS, in which case you have other units available.

Ok, thank you, that works fine and I think I got the point; I changed
the source code to:

<style type="text/css">object.test {height: 3em;width: 50%;}</style>
<object class="test" border="1" type="text/html"
data="object_text.html"></object>

Have a look at http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/

AND NOW IT WORKS correct! WOW!

If you change the browsers font-size by CTRL-+ or CTRL-- the size of the
OBJECT-box is scaled properly!

That is excactly what I needed! Thanks a lot!

jagger

P.S.: Now I only have to adjust the top-/...-margins of the border to
fit my individual taste

 

[Spartanicus]

Have a look at http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/

That is a misguided usage of embedding. It looks to me that what you are
really after is *inclusion* of common content into various pages. The
simplest way to do that is to do a S&R across various files using an
editor that has a proper multi line S&R. Alternatively you could
consider using a preprocessor, or (worse) a server side inclusion
method.

 

[Hans Dietmar Jaeger]

Have a look at http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/

That is a misguided usage of embedding. It looks to me that what you
are really after is *inclusion* of common content into various pages.

But why it is not intended? What is the reason? I store the common
content in only ONE place (to avoid redundant data), save disk space and
there is an easy maintenance (you can't forget one file because the
latest version is automatically imported).

What should be the intantion to allow type="text/html"?

The simplest way to do that is to do a S&R across various files using
an editor that has a proper multi line S&R.

= data redundancy (s. a.)! And why working on several fully identical
files instead of one centrlized one?

Alternatively you could consider using a preprocessor, or (worse) a
server side inclusion method.

My provider provides no server side inclusion in my package.

jagger

P.S.: See also
http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/css_jagger/adresse/adresse.html:
But only the top-three entries are working "Hans Dietmar Jäger",
"Adresse und Photos", "Dark Midnight Fever" in the navigation on the
left. DO NOT go beyond!

 

[Hans Dietmar Jaeger]

P.S.: See also
http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/css_jagger/adresse/adresse.html

.... without the ":" at the end, sorry ...

jagger

 

[Spartanicus]

But why it is not intended? What is the reason?

Unless you have a very good reason for it you should not use coding that
causes a new viewport to open inside another document. It causes
problems for you the author since what is rendered inside that new
viewport is completely independent from the document in which it is
embedded. For example clicking links inside such a new viewport normally
causes them to open inside that viewport, not in the main viewport.
Anything rendered inside the new viewport needs to be styled separately
etc.

It also causes problems for the user, manipulating in document viewports
causes usability problems.

Use inclusion* if you want to include a code fragment. That way the code
fragment becomes an integrated part of the document in which it is
included, without any of the drawbacks of opening a new viewport.

I store the common
content in only ONE place (to avoid redundant data), save disk space

What you are including measures a few hundred bytes. You'll likely lose
more disc space due to your file system's inefficiency with small files.

and
there is an easy maintenance (you can't forget one file because the
latest version is automatically imported).

Changing one file or changing one code fragment across multiple files
shouldn't require any more work.

What should be the intantion to allow type="text/html"?

= data redundancy (s. a.)! And why working on several fully identical
files instead of one centrlized one?


My provider provides no server side inclusion in my package.

So use one of the preferred suggested methods, site wide S&R or a
preprocessor.

* To distinguish between what are two fundamentally different processes
I use the phrase "embedding" to refer to opening a new viewport inside
an existing document, and "inclusion" to refer to incorporating a code
fragment into another document. In the wild both phrases are used
interchangeably, for example the HTML spec refers to the <object>
element as "general inclusion".

 

[Greg N.]

Have a look at http://www.tcs.informatik.uni-muenchen.de/~hdjaeger/
AND NOW IT WORKS correct! WOW!

It looks OK under FF, but you have probably not seen this under IE.
IE puts a horribly ugly scrollable viewport box around this.

 

[Hans Dietmar Jaeger]

Unless you have a very good reason for it you should not use coding that
causes a new viewport to open inside another document. It causes
problems for you the author since what is rendered inside that new
viewport is completely independent from the document in which it is
embedded. For example clicking links inside such a new viewport normally
causes them to open inside that viewport, not in the main viewport.
Anything rendered inside the new viewport needs to be styled separately
etc.

Ok, I understood!
While implementing one workaround[*] after the other for the drawbacks
mentioned above I have to think in a new way to redesign my homepage.

Thank you for discussing the advantages/drawbacks of opening a new viewport!
____
[*] E.g. I have to resize the viewport every time the content changes
(after clicking in it); and that makes the code much more complex than
using any other solution!

What you are including measures a few hundred bytes.

No, it is 36 Kb, transfered every time.

Thank you anyway,

jagger

 

[Spartanicus]

No, it is 36 Kb, transfered every time.

adressen.html measures 1322 bytes.