W3C home > Mailing lists > Public > www-style@w3.org > November 2002

BAD definitions

From: by way of Bert Bos <tapio1@gamma.nic.fi>
Date: Thu, 14 Nov 2002 04:38:56 +0100
To: www-style@w3.org
Message-Id: <200211140438.56319.tapio1@gamma.nic.fi>

"Replaced element
An element for which the CSS formatter knows only the intrinsic

This definition covers oncy CERTAIN kinds of replaced elements.

BUT the definition doesn't cover all possible type of replaced
 elements. <q cite="phrase.inc"></q> is a replaced element, which the
 CSS formatter CAN'T know the intrinsic dimensions, because the element
 doesn't behava like IMG, which creates a rectangular box. In principle
 there could be much that kind of elements.
A fictional element 'include', which would be empty (<include
href="getString.inc" />) has NOT intrinsic dimension, because the
 content is just an arbitrary string, which can be brokened randomly.
 The width and height are NOT defined by the element itself, but they
 are instead imposed by the surroundings.

IF the browser force that kind of element having some kind of intrinsic
dimensions by using srink-wrapping algorith, it destroys the task and
expected behavior of the element. Using srink-wrapping doesn't cause
 exact dimensions because width and height are still depending of the
 font size of the surrounding element.

"Replaced element
An element for which the CSS formatter knows only the intrinsic
 dimensions. In HTML, IMG, INPUT, TEXTAREA, SELECT, and OBJECT elements
 can be examples of replaced elements. For example, the content of the
 IMG element is often replaced by the image that the "src" attribute
 designates. CSS does not define how the intrinsic dimensions are
Intrinsic dimensions
The width and height as defined by the element itself, not imposed by
 the surroundings. In CSS2 it is assumed that all replaced elements --
 and only replaced elements -- come with intrinsic dimensions. "

BOTH are bad definitions!
How CSS2.1 could improve to cover elements like <include />, which task
 is to embed arbitrary string to document and the expected behavior
 type is wrap like an ordinary phrase (for example 'strong') in a line?
 Schrink-wrapping or inline-block type behaviors cause incorrect

Indeed I don't understand how a block-level replaced element can have
intrinsic dimensions. The width is depending on the width of the
surrounding and the height is depending on the width. How for example
<block href="getBlockContent.inc"></block>
should be rendered?

It is just quite frustrating to design on the base of invalid spec.,
 which seems never be a proper spec.

tapio1@nic.fi; http://www.nic.fi/~tapio1/
____ Cascading
______ Style
______   Sheets

Received on Thursday, 14 November 2002 12:21:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:04 UTC