-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The HTML specs speak of "replaced" and "non-replaced" elements, yet
for the life of me I can't find an explanation of what "replaced" is
supposed to mean in this context. Can someone explain?
TIA
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com
iQA/AwUBQdAS7+sywKfXgqKdEQJDPwCbBa2cnAhx8fqlTMbW8ZPLWw n3KnUAoLZm
EJsX4AxbSG4JS8KpxV1l4hpt
=xZUA
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/> 15  2808 
Sander Tekelenburg wrote: The HTML specs speak of "replaced" and "non-replaced" elements, yet
for the life of me I can't find an explanation of what "replaced" is
supposed to mean in this context. Can someone explain?
<http://www.w3.org/TR/html4/struct/objects.html#h-13.2>
"The IMG element has no content; it is usually replaced inline by the
image designated by the src attribute"
<http://www.w3.org/TR/CSS21/conform.html#replaced-element>
Replaced element
An element for which the CSS formatter knows only the intrinsic
dimensions. In HTML, IMG and OBJECT elements can be replaced elements.
For example, the content of the IMG element is often replaced by the
image that the "src" attribute designates.
I guess it also applies to form widgets.
Matthias
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <33*************@individual.net>,
Matthias Gutfeldt <sa************@gmx.net> wrote:
[...] <http://www.w3.org/TR/html4/struct/objects.html#h-13.2> [...]
<http://www.w3.org/TR/CSS21/conform.html#replaced-element> [...]
Thanks.
OK, so a SPAN element would apparently be a non-replaced element
then. Now if I were to say an *empty* SPAN element with a background
image would then be a replaced element, what would you say?
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com
iQA/AwUBQdBDzusywKfXgqKdEQIQGQCdFwwLlfKMnat8stkx1wWBh4 rNgt0An3Th
QJsULRX0HErOpTlpgPYTtJwn
=MUx+
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
"Sander Tekelenburg" <us**@domain.invalid> wrote in message
news:us************************@news.euro.net...
OK, so a SPAN element would apparently be a non-replaced element
then. Now if I were to say an *empty* SPAN element with a background
image would then be a replaced element, what would you say?
It isn't. A background image isn't an IMG element, and a non-replaced
element's dimensions aren't dictated by the dimensions of an image used for
its background. In other words, a span with a background image still doesn't
have intrinsic dimensions.
Sander Tekelenburg <us**@domain.invalid> wrote: -----BEGIN PGP SIGNED MESSAGE-----
Please don't be ridiculous.
OK, so a SPAN element would apparently be a non-replaced element
then.
Maybe. The "replaced element" concept is a CSS matter, not HTML, and it
has no rigorous definition.
Now if I were to say an *empty* SPAN element with a background
image would then be a replaced element, what would you say?
No, that wouldn't change anything.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
On Mon, 27 Dec 2004 12:28:39 -0500, "Harlan Messinger"
<h.*********@comcast.net> wrote: "Sander Tekelenburg" <us**@domain.invalid> wrote in message
news:us************************@news.euro.net.. . OK, so a SPAN element would apparently be a non-replaced element
then. Now if I were to say an *empty* SPAN element with a background
image would then be a replaced element, what would you say?
It isn't. A background image isn't an IMG element, and a non-replaced
element's dimensions aren't dictated by the dimensions of an image used for
its background. In other words, a span with a background image still doesn't
have intrinsic dimensions.
This subject is something I have been wondering a bit about too.
What about these following examples?
Where and in which element is the 'replaced element' concept popping up?
<DIV><IMG SRC="some-img.jpg" ALT="..."></DIV>
<P><IMG SRC="some-img.jpg" ALT="...">Abracadabra...</P>
<OBJECT STANDBY="AbraCadabra" DATA="some-img.png"<IMG SRC="some-img.jpg" ALT="..."
</OBJECT>
And for some details, are the attribute values for 'ALT' and 'STANDBY'
to be considered as replacements for the element if/when they occur in
the rendered result?
--
Rex
"Jan Roland Eriksson" <jr****@newsguy.com> wrote in message
news:r6********************************@4ax.com... On Mon, 27 Dec 2004 12:28:39 -0500, "Harlan Messinger"
<h.*********@comcast.net> wrote:
"Sander Tekelenburg" <us**@domain.invalid> wrote in message
news:us************************@news.euro.net.. . OK, so a SPAN element would apparently be a non-replaced element
then. Now if I were to say an *empty* SPAN element with a background
image would then be a replaced element, what would you say?It isn't. A background image isn't an IMG element, and a non-replaced
element's dimensions aren't dictated by the dimensions of an image used
forits background. In other words, a span with a background image still
doesn'thave intrinsic dimensions.
This subject is something I have been wondering a bit about too.
What about these following examples?
Where and in which element is the 'replaced element' concept popping up?
<DIV><IMG SRC="some-img.jpg" ALT="..."></DIV>
<P><IMG SRC="some-img.jpg" ALT="...">Abracadabra...</P>
<OBJECT STANDBY="AbraCadabra" DATA="some-img.png" ><IMG SRC="some-img.jpg" ALT="..."
></OBJECT>
And for some details, are the attribute values for 'ALT' and 'STANDBY'
to be considered as replacements for the element if/when they occur in
the rendered result?
I'm just gonna riff a little here. I think the idea of "replaced" is based
on the way the OBJECT element works.
<object ...>
<param ...>459</param>
<param ...>Hello</param>
<p>Not supported!</p>
</object>
This object element has text in it like "459" and "Hello" and "Not
supported!" but under ideal circumstances these are all "replaced" by the
visual interface for whatever applet or document the OBJECT tag invokes.
Likewise for a SELECT element, whose content (the options) is replaced with
a list box--which does, yes contain the values of the options, but whatever
(and similarly for TEXTAREA). The similarity of treatment for IMG and INPUT
is hidden by the fact that these are defined to be empty elements, but
conceptually it's still a matter of replacing "[no real content]" in the
following code:
<img src="..." ...>[no real content]</img>
with the image. And as the spec notes, a replaced element almost
tautologically has intrinsic dimensions, whether *intrinsic* intrinsic (like
an image's size) or imposed by the OS or browser (like form controls, and
possibly a function of attributes like the SIZE attribute of the SELECT tag
or the ROWS attribute of the TEXTAREA tag).
"Harlan Messinger" <h.*********@comcast.net> wrote: I think the idea of "replaced"
is based on the way the OBJECT element works.
The obscure excuse-for-a-definition in the CSS 2 specification says:
"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
found."
http://www.w3.org/TR/REC-CSS2/confor...placed-element
So the concept - which is a CSS concept, not an HTML concept - is not
defined in terms of elements but in terms of what "the CSS formatter
knows". The list of elements given is neither exclusive or inclusive -
note the words "can be" instead of "are".
We need not consider complicated things like element content, since the
specification mentions the simple IMG element. The wording suggests
that if the image is not displayed and the ALT text is used instead,
the IMG element is _not_ a replaced element but presumably rendered as
if the document contained the ALT text directly - contrary to what IE
does, of course.
I guess the basic idea is that a replaced element is something that is
treated by a browser as a "black box" with some intrinsic dimensions
that the browser gets from somewhere, like image data, and with content
that is taken from somewhere independently of the formatting of the
document as a whole. The phrase "CSS formatter" refers to the part of a
browser that deals with CSS-related things.
<object ...>
<param ...>459</param>
<param ...>Hello</param>
<p>Not supported!</p>
</object>
Invalid markup. The PARAM element is empty, and the parameter data is
passed in attributes - as usual in ad hoc tag soup trickery:
<param name="foo" value="459">
(The fallback content is indeed a typical example and shows how the
fallback idea fails in practice.)
This object element has text in it like "459" and "Hello" and "Not
supported!" but under ideal circumstances these are all "replaced"
by the visual interface for whatever applet or document the OBJECT
tag invokes.
It does _not_ contain the parameter data as text but in attributes, and
saying that the (fallback) content gets replaced is a bit odd. Rather,
it's the entire _element_ that gets replaced by something that is
taken, as a black box, from somewhere.
Likewise for a SELECT element, whose content (the
options) is replaced with a list box--which does, yes contain the
values of the options, but whatever
In implementations, a SELECT element is presented as a list box or as a
pulldown menu. In both cases, it indeed contains the OPTION elements,
so no replacement really takes place.
(and similarly for TEXTAREA).
TEXTAREA isn't really similar to anything but another TEXTAREA.
And as the spec notes, a replaced element almost
tautologically has intrinsic dimensions, whether *intrinsic*
intrinsic (like an image's size) or imposed by the OS or browser
(like form controls, and possibly a function of attributes like the
SIZE attribute of the SELECT tag or the ROWS attribute of the
TEXTAREA tag).
The word "intrinsic" is probably intrinsically misleading here.
I would say that the key to the "replaced element" concept is that it's
an element that is treated, for the purposes of formatting, as a
rectangle with unknown content and with default dimensions (i.e.,
dimensions used in the absence of CSS rules) based on something else
than its content in markup terms. Either the element has no content in
HTML terms, or the content is ignored in determining the default size.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. .. "Harlan Messinger" <h.*********@comcast.net> wrote:
I think the idea of "replaced"
is based on the way the OBJECT element works.
The obscure excuse-for-a-definition in the CSS 2 specification says:
"Replaced element
An element for which the CSS formatter knows only the intrinsic
dimensions.
Which is extra confusing because in the definition of "intrinsic dimensions"
that immediately follows, it says, "In CSS2 it is assumed that all replaced
elements -- and only replaced elements -- come with intrinsic dimensions."
So now, a replaced element is only assumed, rather than defined, to have
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
found."
http://www.w3.org/TR/REC-CSS2/confor...placed-element
So the concept - which is a CSS concept, not an HTML concept - is not
defined in terms of elements but in terms of what "the CSS formatter
knows". The list of elements given is neither exclusive or inclusive -
note the words "can be" instead of "are".
We need not consider complicated things like element content, since the
specification mentions the simple IMG element. The wording suggests
that if the image is not displayed and the ALT text is used instead,
the IMG element is _not_ a replaced element but presumably rendered as
if the document contained the ALT text directly - contrary to what IE
does, of course.
I guess the basic idea is that a replaced element is something that is
treated by a browser as a "black box" with some intrinsic dimensions
that the browser gets from somewhere, like image data, and with content
that is taken from somewhere independently of the formatting of the
document as a whole. The phrase "CSS formatter" refers to the part of a
browser that deals with CSS-related things.
<object ...>
<param ...>459</param>
<param ...>Hello</param>
<p>Not supported!</p>
</object>
Invalid markup. The PARAM element is empty, and the parameter data is
passed in attributes - as usual in ad hoc tag soup trickery:
<param name="foo" value="459">
(The fallback content is indeed a typical example and shows how the
fallback idea fails in practice.)
OK, oops. I *said* I was riffing.
This object element has text in it like "459" and "Hello" and "Not
supported!" but under ideal circumstances these are all "replaced"
by the visual interface for whatever applet or document the OBJECT
tag invokes.
It does _not_ contain the parameter data as text but in attributes, and
saying that the (fallback) content gets replaced is a bit odd. Rather,
it's the entire _element_ that gets replaced by something that is
taken, as a black box, from somewhere.
Likewise for a SELECT element, whose content (the
options) is replaced with a list box--which does, yes contain the
values of the options, but whatever
In implementations, a SELECT element is presented as a list box or as a
pulldown menu. In both cases, it indeed contains the OPTION elements,
so no replacement really takes place.
In one sense they're not replaced, but from the perspective of the CSS
formatter they may be, because the formatter may just pass the option values
on to whatever mechanism renders the list box, which arranges them according
to *its* rules, and then reports back to the CSS formatter, "OK, I've just
put a box here that's x pixels wide and y pixels high. You may move on to
the next thing." It's hard to say. Maybe it depends on whether the UA
supports applying CSS properties to the options. If it does, maybe it
depends on whether the formatter renders the options within a location
passed back to it by the widget renderer, or whether the formatter passes
the formatting properties on to the widget renderer which then takes care of
rendering the options.
A part of it that's unclear to me about the definition "intrinsic
dimensions" is this:
<img src="...">
is clearly meant to be considered a "replaced element" if the image is
rendered, but how about
<img src="..." style="width: 100px; height: 120px;">
? The image itself still has intrinsic dimensions, but does "replaced image"
mean:
a. Having intrinsic dimensions that the formatter uses without further
calculation, or
b. Having instrinsic dimensions, which are reported to the formatter but
which the
formatter may ignore
?
[snip]
Harlan Messinger wrote: "Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. ..
"Harlan Messinger" <h.*********@comcast.net> wrote:
Which is extra confusing because in the definition of "intrinsic dimensions"
that immediately follows, it says, "In CSS2 it is assumed that all replaced
elements -- and only replaced elements -- come with intrinsic dimensions."
So now, a replaced element is only assumed, rather than defined, to have
intrinsic dimensions.
A part of it that's unclear to me about the definition "intrinsic
dimensions" is this:
<img src="...">
is clearly meant to be considered a "replaced element" if the image is
rendered, but how about
<img src="..." style="width: 100px; height: 120px;">
? The image itself still has intrinsic dimensions, but does "replaced image"
mean:
a. Having intrinsic dimensions that the formatter uses without further
calculation, or
b. Having instrinsic dimensions, which are reported to the formatter but
which the
formatter may ignore
Intrinsic: Belonging to a thing by its very nature.
Ergo, intrinsic dimensions: Dimensions to a thing by its very nature -
as in self-contained (default) H&W in an image.
"In CSS2 it is assumed that all replaced elements -- and only replaced
elements -- come with intrinsic dimensions."
Meaning that all replaced elements (should/must) have intrinsic
dimensions (in order to be useful).
"[listed] elements can be examples of replaced elements."
Signifying that the[listed] elements "can be", but are not necessarily
replaced elements.
"Replaced element: An element for which the CSS formatter knows only
the intrinsic dimensions."
Taken together; An element having *only* intrinsic dimensions is a
Replaced element. An element (irregardless if it is with or without
intrinsic dimensions), having dimensions provided by either HTML or
CSS, is *not* a Replaced element.
<img src="..." style="width: 100px; height: 120px;">
The img, in this case, having both intrinsic and CSS dimensions is
*not* a Replaced element. The formatter overrides (takes precedence
over/ignores) the intrinsic dimensions with the CSS dimensions.
--
Gus
Sorry if I repeated understood items, but for completeness of my own and
others' understanding ....
"Harlan Messinger" <h.*********@comcast.net> wrote: In implementations, a SELECT element is presented as a list box or
as a pulldown menu. In both cases, it indeed contains the OPTION
elements, so no replacement really takes place.
In one sense they're not replaced, but from the perspective of the
CSS formatter they may be, because the formatter may just pass the
option values on to whatever mechanism renders the list box, which
arranges them according to *its* rules, and then reports back to
the CSS formatter, "OK, I've just put a box here that's x pixels
wide and y pixels high. You may move on to the next thing."
I think I have come to essentially the same conclusion, though still
wondering whether it's exactly the right one. The way I see it is that
for a replaced element, the CSS formatter does not know or does not
care of what happens inside the element and does compute any size
requirements for the element from the size requirements of its content.
The SELECT element is somewhat special though. Its height does not
depend on its content, but its width does (in a typical
implementation): the longest OPTION element sets the default for the
SELECT width. This means that a browser needs to process the content
(in the HTML sense), so I wonder why SELECT is (or "can be") a replaced
element.
A part of it that's unclear to me about the definition "intrinsic
dimensions" is this:
<img src="...">
is clearly meant to be considered a "replaced element" if the image
is rendered, but how about
<img src="..." style="width: 100px; height: 120px;">
?
I would say it's still a replaced element. The same applies to a case
where the dimensions are specified in HTML: width="100" height="120".
The element has an intrinsic width (defined by the image data itself),
and width and height properties (or corresponding HTML attributes) may
cause rescaling, but the browser does not compute the dimensions from
the content as it does for a P element for example - or for an IMG
element when the ALT attribute is used (in an advanced browser like
Firefox, whereas IE uses the intrinsic dimensions instead, by default,
and may truncate the text brutally).
The image itself still has intrinsic dimensions, but does
"replaced image" mean:
a. Having intrinsic dimensions that the formatter uses without
further calculation, or
b. Having instrinsic dimensions, which are reported to the
formatter but which the formatter may ignore
I don't see a conflict, or even an essential difference, between
a and b. But I see the width and height properties as _external_,
even though they can be technically specified in the element's
attributes (via style="..." or via width="..." and height="...").
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <33*************@individual.net>,
"Harlan Messinger" <h.*********@comcast.net> wrote:
[...] A part of it that's unclear to me about the definition "intrinsic
dimensions" is this:
<img src="...">
is clearly meant to be considered a "replaced element" if the image
is rendered, but how about
<img src="..." style="width: 100px; height: 120px;">
?
Right. Here you get close to where I wanted to go :) The reason I
asked is that I was wondering whether an empty SPAN with a background
image and explicit width is a valid construction.
I use that construction at <http://www.lotzofmusic.com/>. Mozilla
1.7.5, Opera 7.5.4 and iCab 3.0 happily deal with this the way I
hoped (although I'm not sure yet about the enclosing DIV's
float:left, but that's another issue).
What's more, the W3C CSS validator is happy with it too:
< http://jigsaw.w3.org/css-validator/v.../lotzofmusic.c
om/css/screen.php&warning=2&profile=css2&usermedium=scree n>.
But it 'felt' wrong to set an explicit height/width for a SPAN.
So I kept looking and found that according to the CSS2.1 spec width
and height are not for "non-replaced" inline elements. See
<http://www.w3.org/TR/CSS21/propidx.html>. Thus my question: "what is
a 'non-replaced' element?". If a SPAN is a "non-replaced" element, it
must not be given an explicit width/height. But then why does the W3C
validator not complain?
[The reason I posted this to ciwah, in spite of all the CSS involved,
was that it seemd to be about elements and thus about HTML.]
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com
iQA/AwUBQdJqdOsywKfXgqKdEQJbQwCg+Im+KazYvpJVxJo9FQ/FHvQStjkAnRxs
SIQYPVx/3q3OuRcRyGk9vH4Z
=eiR3
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
In article <us************************@news.euro.net>,
Sander Tekelenburg <us**@domain.invalid> wrote: Right. Here you get close to where I wanted to go :) The reason I
asked is that I was wondering whether an empty SPAN with a background
image and explicit width is a valid construction.
It the syntactic sense it is valid.
I use that construction at <http://www.lotzofmusic.com/>. Mozilla
1.7.5, Opera 7.5.4 and iCab 3.0 happily deal with this the way I
hoped
Only because the display property computes to block, because you have
set float: left;.
http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
So I kept looking and found that according to the CSS2.1 spec width
and height are not for "non-replaced" inline elements.
Your spans are not non-replaced inline elements but block elements in
this particular case for CSS purposes. The %block/%inline role of the
element in the HTML DTD is of no interest to the CSS formatter.
If a SPAN is a "non-replaced" element, it
must not be given an explicit width/height.
Span is *by default* display: inline; and, hence, a non-replaced inline
element. Giving a width to a non-replaced inline element is not
forbidden. The width just has no effect in a conforming CSS formatter.
(But here the width has an effect, because the element is a block
element for CSS purposes.)
But then why does the W3C validator not complain?
Declaring properties that do not apply in some situations is not a
syntax error.
[The reason I posted this to ciwah, in spite of all the CSS involved,
was that it seemd to be about elements and thus about HTML.]
This is all CSS stuff.
--
Henri Sivonen hs******@iki.fi http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
"Sander Tekelenburg" <us**@domain.invalid> wrote in message
news:us************************@news.euro.net... -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <33*************@individual.net>,
"Harlan Messinger" <h.*********@comcast.net> wrote:
[...]
A part of it that's unclear to me about the definition "intrinsic
dimensions" is this:
<img src="...">
is clearly meant to be considered a "replaced element" if the image
is rendered, but how about
<img src="..." style="width: 100px; height: 120px;">
?
Right. Here you get close to where I wanted to go :) The reason I
asked is that I was wondering whether an empty SPAN with a background
image and explicit width is a valid construction.
Unless you set display: block; for the SPAN, the width property is
inapplicable. Background images aren't elements, so they can't be *replaced*
elements. They aren't the content of any element, they just show up behind
them. The fact that a SPAN might have *no* content doesn't mean that the
browser will suddenly treat the background image as though it were an IMG
element.
I use that construction at <http://www.lotzofmusic.com/>. Mozilla
1.7.5, Opera 7.5.4 and iCab 3.0 happily deal with this the way I
hoped (although I'm not sure yet about the enclosing DIV's
float:left, but that's another issue).
What's more, the W3C CSS validator is happy with it too:
<http://jigsaw.w3.org/css-validator/v.../lotzofmusic.c
om/css/screen.php&warning=2&profile=css2&usermedium=scree n>.
The CSS validator only checks formal, grammatical validity of CSS code. It
doesn't--it *can't*--assess the context in which a given property is being
used. For example, it is perfectly content with
em { border-collapse: collapse; }
even though border-collapse only applies to table and inline-table elements.
It's not just because the validator isn't sufficiently sophisticated. It's
because the correctness of the above rule is context-dependent. The
validator can't know that some other style rule won't also be in effect at
the time the above rule is applied that specifies
em { display: inline-table; }
in which case the border-collapse property *would* be perfectly legal.
But it 'felt' wrong to set an explicit height/width for a SPAN.
So I kept looking and found that according to the CSS2.1 spec width
and height are not for "non-replaced" inline elements. See
<http://www.w3.org/TR/CSS21/propidx.html>. Thus my question: "what is
a 'non-replaced' element?". If a SPAN is a "non-replaced" element, it
must not be given an explicit width/height. But then why does the W3C
validator not complain?
See above.
[The reason I posted this to ciwah, in spite of all the CSS involved,
was that it seemd to be about elements and thus about HTML.]
Refer to the link you provided for the property index and note, from the
"applies to" column, that the applicability of each property isn't based on
an element's HTML type but on its CSS type. This isn't clear based only on
references to 'block' and 'inline' elements, since those are also HTML
concepts, but note that most of the other criteria cite unambiguously CSS
keywords or concepts--positioned, table-cell, table-caption, list-item, etc.
[Crossposted and followups set to
<news:comp.infosystems.www.authoring.stylesheets >]
In article <hs****************************@news.dnainternet.n et>,
Henri Sivonen <hs******@iki.fi> wrote: In article <us************************@news.euro.net>,
Sander Tekelenburg <us**@domain.invalid> wrote:
[...]
I was wondering whether an empty SPAN with a background
image and explicit width is a valid construction.
It the syntactic sense it is valid.
I use that construction at <http://www.lotzofmusic.com/>. Mozilla
1.7.5, Opera 7.5.4 and iCab 3.0 happily deal with this the way I
hoped
Only because the display property computes to block, because you have
set float: left;.
Yes, that would make sense. However, I don't see that confirmed by
http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
which says "[...] if 'float' has a value other than 'none', the box is
floated and 'display' is set according to the table below [...]". Then
in 'the table below' it seems to say that in this case display is set to
"same as specified". Eh?
(Ah, I see that <http://www.w3.org/TR/CSS21/visuren.html#q27> even
provides an example of a floating SPAN with an explicit width.)
[...] But then why does the W3C validator not complain?
Declaring properties that do not apply in some situations is not a
syntax error.
Duh, I knew that - just forgot to think of it :) Thanks.
Btw, are there CSS checkers that have more to offer than mere syntactic
validation? [The reason I posted this to ciwah, in spite of all the CSS involved,
was that it seemd to be about elements and thus about HTML.]
This is all CSS stuff.
So it seems. Crossposting and setting followups to
<news:comp.infosystems.www.authoring.stylesheets >
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[Crossposted and followups set to
<news:comp.infosystems.www.authoring.stylesheets >]
In article <hs****************************@news.dnainternet.n et>,
Henri Sivonen <hs******@iki.fi> wrote: In article <us************************@news.euro.net>,
Sander Tekelenburg <us**@domain.invalid> wrote:
[...]
I was wondering whether an empty SPAN with a background
image and explicit width is a valid construction.
It the syntactic sense it is valid.
I use that construction at <http://www.lotzofmusic.com/>. Mozilla
1.7.5, Opera 7.5.4 and iCab 3.0 happily deal with this the way I
hoped
Only because the display property computes to block, because you
have set float: left;.
Yes, that would make sense. However, I don't see that confirmed by
http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
which says "[...] if 'float' has a value other than 'none', the box
is floated and 'display' is set according to the table below [...]".
Then in 'the table below' it seems to say that in this case display
is set to "same as specified". Eh?
(Ah, I see that <http://www.w3.org/TR/CSS21/visuren.html#q27> even
provides an example of a floating SPAN with an explicit width.)
[...] But then why does the W3C validator not complain?
Declaring properties that do not apply in some situations is not a
syntax error.
Duh, I knew that - just forgot to think of it :) Thanks.
Btw, are there CSS checkers that have more to offer than mere
syntactic validation? [The reason I posted this to ciwah, in spite of all the CSS
involved, was that it seemd to be about elements and thus about
HTML.]
This is all CSS stuff.
So it seems. Crossposting and setting followups to
<news:comp.infosystems.www.authoring.stylesheets >
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com
iQA/AwUBQdOehOsywKfXgqKdEQKPPgCggDf84AokrHY7r0XafCupTh 3pI6QAoM8S
ulRnhVbLNj0tVk+OEdgBYyUD
=wILx
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/> This thread has been closed and replies have been disabled. Please start a new discussion. |
