BUG: CSS und die ID-Namen von DIV u. SPAN

[Wowbagger]

Hallo forumsgemeinde!

Ich habe gerade einen kleinen aber gemeinen bug entdeckt, der die benamung von layers im zusammenhang mit CSS definitionen betrifft. Demnach darf im ID-namen kein underscore auftauchen, sonst wird die stil-zuordnung einfach ignoriert! Dieser bug ist übrigens 'browserunabhängig!' :

<STYLE TYPE="text/css"><!--
#ein_dummy {position:absolute;visibility:visible;width:150;height:20;background-color:teal}
--></STYLE>
<span id="ein_dummy">
Hallo Welt
</span>

<!--- BUG: underscore im id-namen wird nicht erkannt! --->

</body>
</html>

Echt übele sache, was?

/*,*/
Wowbagger

[Stefan Muenz]

Hallo Wowbagger

Ich habe gerade einen kleinen aber gemeinen bug entdeckt, der die benamung von layers im zusammenhang mit CSS definitionen betrifft. Demnach darf im ID-namen kein underscore auftauchen, sonst wird die stil-zuordnung einfach ignoriert! Dieser bug ist übrigens 'browserunabhängig!' :

Hmm, schlimm, wenn dem so ist. "Browserunabhaengig" ist naemlich auch das folgende:

"ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). "

aus: HTML4.0-Spec (W3C)

viele Gruesse
  Stefan Muenz

[Thomas J.S.]

Hallo !

<STYLE TYPE="text/css"><!--

»»  #ein_dummy {position:absolute;visibility:visible;width:150;height:20;background-color:teal}

--></STYLE>
<span id="ein_dummy">
Hallo Welt
</span>

Für mein Gefühl machst du so einiges falsch:
1)<span> als inline-level element kann nicht absolut positionert werden.
2) Netscape interprtiert zwar <span> als block-level-el. aber auch nur teilweise: z.B. boder werden akzeptiert. (bei Hintergrundfarbe in absolut pos. Elementen hat NS probleme --> layer-background-color)
3) IE erkenn <span> als inline-element, weshalb keine absoulte Positioniereung möglich ist.
4) bei position:absolute; fehlen bei dir Angaben z.B. zu top: /lef:/
5) bei nummerischen Angaben sollte man immer px/pt/em/in usw. hinzufügen.
Laut W§c sollten nämlich Browser WErte ohne diese Angaben ignorieren. Daß die B.'s es jedoch nicht tun ist nur Fehlertoleranz.
6) Ein abschlißender Semikolon könnte auch nicht schaden.

Also versuch es mal mit <div id="bla_bla">
Ich habe es jetztn icht ausprobieren können, aber mal sehen wie es geht.

Grüße
Thomas

[Stefan Muenz]

Hallo Thomas

1)<span> als inline-level element kann nicht absolut positionert werden.

<ilayer>, was in Netscape-Syntax in etwa <span> entspricht, kann man aber sehr wohl absolut positionieren.
Generell finde ich das immer etwas verwirrend. Auf der einen Seite ist immer von block-level- und inline-Elementen die Rede, was aber meines Erachtens nur bei nicht-positionierten Elementen bzw. Elementen Sinn macht, die sich im normalen "Textfluss" befinden.
Positionierte Elemente brechen aber den Textfluss auf, haben sinnvollerweise auch Angaben zu Breite und Hoehe und sind damit gewissermassen Block-Elemente, aber im freien Raum. Bei Netscape-Layern ist diese Funktionalitaet noch eher nachvollziehbar als beim MSIE und bei HTML4.0/CSS2.0, wo Positionierung praktisch auf alle HTML-Elemente anwendbar ist.

3. IE erkenn <span> als inline-element, weshalb keine absoulte Positioniereung möglich ist.

Also <span style="position:absolute; top:200px; left:300px">Test</span> funktioniert bei mir einwandfrei.

viele Gruesse
  Stefan Muenz

[Thomas J.S.]

Hallo Stefan!

(Ich möchte mich bei diejenigen, die im Englischen nicht so bewandt sind, schon jetzt entschuldigen, daß ich viele Zitate nur auf Englisch bringe.)

1)<span> als inline-level element kann nicht absolut positionert werden.

Also <span style="position:absolute; top:200px; left:300px">Test</span> funktioniert bei mir einwandfrei.

»»

Ja, stimmt. Es kann absolut positoniert werden.

Jedoch sei vermerkt: [damit ich halt wiedersprechen kann ;-) ]
In HTML 4.0:
"...These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content...."

dann weiter:

"Style sheets provide the means to specify the rendering of arbitrary elements, including whether an element is rendered as block or inline. In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way."

Das würde doch meinen; man kann zwar <span> als block-level Element bestimmen, aber es ist nicht im Sinne des Erfinders.

Generell finde ich das immer etwas verwirrend. Auf der einen Seite ist immer von block-level- und inline-Elementen die Rede, was aber meines Erachtens nur bei nicht-positionierten Elementen bzw. Elementen Sinn macht, die sich im normalen "Textfluss" befinden.

Glaube mir, das "Visual formatting model" hat mir einiges an Kopfzerbrechen beschert (und oft tut es noch immer).
In CSS2:
"...Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs). ...
In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block."

Dann weiter:

...Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines (e.g., emphasized pieces of text within a paragraph, inline images, etc.)...
In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block."

Wenn ich jetzt HTML 4.0 nehme, dann ist <span> inline-element. Nach CSS2 sollte es keinen neuen Block formen und der Inhalt ist in 'einer' linie. Wenn man mehrere <span>s aneinanderreiht sollten sie eine horizontale Reihenfolge haben.
Und das ist genau das, was <span> leistet.

Positionierte Elemente brechen aber den Textfluss auf, haben sinnvollerweise auch Angaben zu Breite und Hoehe und sind damit gewissermassen Block-Elemente, aber im freien Raum.

»»

Bist mir nicht böse, wenn ich das mal auch unter meine Lupe neheme? ;-)

"The width of a line box is determined by a containing block. The height of a line box is determined by the rules given in the section on line height calculations."

Wenn ich dem vorhergesagten zustimme und <span> als inline-elemet ansehe, sollte dessen Breite durch den umgebenden Box, die Höhe durch die 'line-heigt' Eigenschaften bestimmt werden.

Nicht desto trozt, wenn man CSS2 anschaut bleiben Fragen offen, viele Fragen. Und man neigt zu vergessen, daß CSS nur eine Ergänzungssprache zu HTML ist, weshalb die bestimmtnde 'Instantz' HTML sein sollte.
Was in HTML 4.0 mit '2' Sätzen erledigt ist (in Bezug auf <span>) bringt einem schier zum Verzweifeln, wenn man die ganze Boxmodellkonzepte anschaut im CSS2.

Grüße
Thomas

[Wowbagger]

Für mein Gefühl machst du so einiges falsch:
1)<span> als inline-level element kann nicht absolut positionert werden.

es ist nicht relevant ob nun DIV oder SPAN, denn wenn man die beiden underscores aus den id-namen entfernt, *funktioniert* der source ja!

2. Netscape interprtiert zwar <span> als block-level-el. aber auch nur teilweise: z.B. boder werden akzeptiert. (bei Hintergrundfarbe in absolut pos. Elementen hat NS probleme --> layer-background-color)

ich gebe ja nur *text* aus und in genau diesem fall hat der Netscape keine probleme mit background-color.

3. IE erkenn <span> als inline-element, weshalb keine absoulte Positioniereung möglich ist.

Hier gibt es nur *ein* element und keine childs, so daß es in jedem fall absolut positioniert wird!

4. bei position:absolute; fehlen bei dir Angaben z.B. zu top: /lef:/
5. bei nummerischen Angaben sollte man immer px/pt/em/in usw. hinzufügen.

Damit hat der Netscape aber evtl. probleme, denn der liefert solche angaben ohne die px-endung zurück.

Laut W§c sollten nämlich Browser WErte ohne diese Angaben ignorieren. Daß die B.'s es jedoch nicht tun ist nur Fehlertoleranz.
6) Ein abschlißender Semikolon könnte auch nicht schaden.

das semikolon ganz am ende ist völlig egal, da es als *trenner* zweier angaben verwendet wird und somit kein zwingend notwendiger abschluß ist.

Also versuch es mal mit <div id="bla_bla">

anbei der code, wie er deiner meinung nach funktionieren sollte. Aber er tut's nach wie vor nur *ohne* die underscores:

<HTML>
<HEAD>
<TITLE>DHTML TEST</TITLE>
</HEAD>

<BODY>

<STYLE TYPE="text/css"><!--
#ein_dummy {position:absolute;visibility:visible;top:1px;left:1px;width:150px;height:20px;background-color:teal;layer-background-color:teal;}
--></STYLE>
<div id="ein_dummy">
Hallo Welt
</div>

<!--- BUG: underscore im id-namen wird nicht erkannt! --->

</body>
</html>

nach wie vor mächtig seltsam...

so long...
/*,*/
Wowbagger

[Thomas J.S.]

Hallo!

es ist nicht relevant ob nun DIV oder SPAN, denn wenn man die beiden underscores aus den id-namen entfernt, *funktioniert* der source ja!

»»

Ich habe es jetzt ausprobiert.
Wenn wir NS nehmen hast du recht. Im IE 4/5 funktionert aber dein Code. Mit <div> und <span> UND mit '_' underscore. Um den Effekt besser sichtbar zu machen habe ich es so geändert:
#ein_dummy {
  position:absolute;
  top:50px;
  left:100px;
  width:150px;
  height:20px;
  background-color:teal;
  layer-background-color:teal;
  visibility:visible;
  }

ich gebe ja nur *text* aus und in genau diesem fall hat der Netscape keine probleme mit background-color.

»»

Dann würde ich vorschlagen, ein absolut positioniertes <div> mit viel Text zu füllen und eine Hintergrundfarbe bestimmen.
Im NS wird stickt nur der Text 'unterfärbt', was einen Treppeneffekt erzeugt.

3. IE erkenn <span> als inline-element, weshalb keine absoulte Positioniereung möglich ist.

Hier gibt es nur *ein* element und keine childs, so daß es in jedem fall absolut positioniert wird!

»»

Siehe dazu mein Posting an Stefan.

5. bei nummerischen Angaben sollte man immer px/pt/em/in usw. hinzufügen.

Damit hat der Netscape aber evtl. probleme, denn der liefert solche angaben ohne die px-endung zurück.

Ich weiss zwar nicht was du meinst mit 'der liefert solche angaben ohne die px-endung zurück.' aber:
"...The format of a length value (denoted by <length> in this specification) is an optional sign character ('+' or '-', with '+' being the default) immediately followed by a <number> (with or without a decimal point) immediately followed by a unit identifier (e.g., px, deg, etc.). After the '0' length, the unit identifier is optional."

Das heisst, daß die einzige Möglichkeit wo keine Angabe (px,pt, etc) notwendig ist, ist eine Wertangabe von '0'.

6. Ein abschlißender Semikolon könnte auch nicht schaden.

das semikolon ganz am ende ist völlig egal, da es als *trenner* zweier angaben verwendet wird und somit kein zwingend notwendiger abschluß ist.

Ich weiss, aber sag das bitte dem IE auch. ;-)

Schöne Grüße
Thomas

[Thomas Hieck]

Ja, das stimmt. Ich hab auch ein paar Threads weiter unten schon darauf hingewiesen, dass da NETSCAPE (nicht der Explorer) einige Probleme damit hat, wenn man ein ID mit einem Underscore vergibt. Ein sinnvoller Grund, warum das so sein muss ist mir dazu leider noch nicht eingefallen. Ich hab aber die Vermutung es gibt wirklich einen.

Viele Gruesse, Thomas Hieck

[Wowbagger]

Hallo,

Ja, das stimmt. Ich hab auch ein paar Threads weiter unten schon darauf hingewiesen, dass da NETSCAPE (nicht der Explorer) einige Probleme damit hat, wenn man ein

im IE4 funktioniert's aber auch nicht!

ID mit einem Underscore vergibt. Ein sinnvoller Grund, warum das so sein muss ist mir dazu leider noch nicht eingefallen. Ich hab aber die Vermutung es gibt wirklich einen.

vielleicht, da es ja in *beiden* browsern scheitert...wirkt aber trotzdem für mich wie ein bug, da der underscore 'traditionsgemäß' immer zu den nicht-sonderzeichen gezählt wurde und daher nahezu überall zusammen mit a..z/0..9 verwendet werden darf...

tschau...
/*,*/
Wowbagger