Forum:Anzeigefehler: Unterschied zwischen den Versionen
imported>Shisma |
|||
Zeile 47: | Zeile 47: | ||
::sieht ganz gut aus. abgsehen natürlich von ie. ich bin für die ohnehin für die Einbindung von [http://dean.edwards.name/weblog/2008/01/ie7-2/ ie7.js]. damit würden sich solche Fehler erledigen. kann aber sicher nicht mal als Admin solche Scripte verknüpfen. mal eine frage: du hängst ja an das Objekt einige Leerzeichen dran oder? werden diese pseudo-Leerezeichen mit den echten Leerzeichen die in HTML izusammen gemergt oder was?--<span style="font-family:Georgia; color:silver; font-size:21px; font-weight:normal; font-style:italic;">[[User:Shisma|Shisma]]</span><sub style="position:absolute; margin-left:-79px;margin-top:1.6em;">Bitte korrigiert mich</sub> | ::sieht ganz gut aus. abgsehen natürlich von ie. ich bin für die ohnehin für die Einbindung von [http://dean.edwards.name/weblog/2008/01/ie7-2/ ie7.js]. damit würden sich solche Fehler erledigen. kann aber sicher nicht mal als Admin solche Scripte verknüpfen. mal eine frage: du hängst ja an das Objekt einige Leerzeichen dran oder? werden diese pseudo-Leerezeichen mit den echten Leerzeichen die in HTML izusammen gemergt oder was?--<span style="font-family:Georgia; color:silver; font-size:21px; font-weight:normal; font-style:italic;">[[User:Shisma|Shisma]]</span><sub style="position:absolute; margin-left:-79px;margin-top:1.6em;">Bitte korrigiert mich</sub> | ||
+ | |||
+ | :::IE7.js/IE8.js würde auf jeden Fall vieles vereinfachen; wäre natürlich schön, wenn das jemand einfügen könnte. Zu den Leerzeichen: die verhalten sich, als würden sie im HTML-Code stehen. Die [http://de.wikipedia.org/wiki/Gesch%C3%BCtztes_Leerzeichen geschützten Leerzeichen] nach und vor dem Trennstrich werden auf jeden Fall dargestellt. Das eine „normale“ Leerzeichen, fällt – wie in HTML üblich – mit dem vorhergehenden zusammen. Das ist ja der Clou bei der Sache: falls zwischen den lis bereits ein Leerzeichen ist, fällt es mit dem aus dem CSS-Code zusammen, falls nicht bleibt einzig das Leerzeichen aus dem CSS-Code stehen. [[Spezial:Beiträge/84.176.35.247|84.176.35.247]] 15:52, 5. Nov. 2008 (UTC) |
Version vom 5. November 2008, 16:52 Uhr
Beachte: Dieses Thema ist seit 5853 Tagen unbearbeitet. Es ist automatisch archiviert worden, weil die Diskussion offenbar vorüber ist. Antworte nur, wenn es wirklich notwendig ist!
Bei mir wird die Schrift der Auswahlmenüs ziemlich groß dargestellt, sodass sie fast eine ganze Browser-Seite ausfüllen. --Mark McWire 22:59, 1. Nov. 2008 (UTC)
- Benutzt du zufälligerweise Opera? Wenn ja: so ein Problem hatte ich bereits einem Administrator gemeldet: http://memory-alpha.org/de/wiki/Benutzer_Diskussion:Shisma#Navleisten 84.176.54.142 21:22, 2. Nov. 2008 (UTC)
- Ja ich benutze Opera. --Mark McWire 22:46, 2. Nov. 2008 (UTC)
- ja, schon wieder ein Anzeigefehler im Opera. Da gibt es scheinbar einen Vererbungsfehler. habe die Befehle entfernt die ihn auslösen--ShismaBitte korrigiert mich 10:10, 3. Nov. 2008 (UTC)
- It’s not a bug, it’s a feature
Opera setztefont-size:0.1em
fürdiv.nav ul
aus Usability-Gründen nicht um, sondern nahm eine noch lesbare Mindestschriftgröße an.
BTW, es gibt keine „Befehle“ in CSS ;) 84.176.54.142 15:57, 3. Nov. 2008 (UTC)
- It’s not a bug, it’s a feature
- ja, schon wieder ein Anzeigefehler im Opera. Da gibt es scheinbar einen Vererbungsfehler. habe die Befehle entfernt die ihn auslösen--ShismaBitte korrigiert mich 10:10, 3. Nov. 2008 (UTC)
- ach, das ist ja ein super Feature das zu Anzeigefehlern führt. was ist denn die kleinste anzeigbare Größe im Opera?--ShismaBitte korrigiert mich 16:17, 3. Nov. 2008 (UTC)
- Das ist, wie so ziemlich alles im Opera, konfigurierbar (Standard ist AFAIK 9px).
Ach ja, und es ist in der Tat ein super Feature. Viele Websites könnte ich ohne dieses Feature nicht sinnvoll lesen (ohne dauernd zoomen zu müssen). Wenn es dir nicht passt, schön. Tatsache ist, dass hier nicht wirklich ein CSS-Interpretationsfehler vorliegt, sondern es “works as designed”. Der Designfehler lag hier im CSS, nicht im Browser. 84.176.54.142 16:31, 3. Nov. 2008 (UTC)- zeig mir bitte die betreffende W3C Spezifikation.
font-size:0.1em
ist ja kein Fehler. der opera ist hier in sofern schlecht gemacht als das, die gesetzte Schriftgröße nicht vererbt wird. aber gut. Mark, du musst denn wohl deinen Opera umkonfigurieren(oder einen Browser verwenden, der nicht seine eigenen Standards erfindet) --ShismaBitte korrigiert mich 16:37, 3. Nov. 2008 (UTC)
- zeig mir bitte die betreffende W3C Spezifikation.
- Das ist, wie so ziemlich alles im Opera, konfigurierbar (Standard ist AFAIK 9px).
- W3C-Spezifikation zu was denn konkret? Was willst du damit bezwecken? Der CSS-Code war ja valide, nur nicht ganz so vorteilhaft designed. Aber das hast du ja jetzt behoben. Und nun geht’s ja auch im Opera. Warum soll Mark jetzt seinen Opera umkonfigurieren, wo alles funktioniert?
Wie kommst du zu dem Schluss, Opera würde eigende Standards erfinden. Das könnte man dem IE vorwerfen, häufig auch Mozilla; meinetwegen auch der WHATWG (als W3C-Jünger ;). Aber was soll’s. Das führt hier jetzt zu weit. Der Darstellungsfehler ist behoben und damit gut. 84.176.54.142 16:50, 3. Nov. 2008 (UTC)
- W3C-Spezifikation zu was denn konkret? Was willst du damit bezwecken? Der CSS-Code war ja valide, nur nicht ganz so vorteilhaft designed. Aber das hast du ja jetzt behoben. Und nun geht’s ja auch im Opera. Warum soll Mark jetzt seinen Opera umkonfigurieren, wo alles funktioniert?
- Nur so am Rande: Das Problem ist auf der Seite "Letzte Änderungen" nach wie vor zu sehen... also keine Besserung. Wenn ihr schon so firm seit, sagt mir und den anderen wenigstens mal was man in Opera konkret ändern sollte... Danke! --Mark McWire 16:52, 3. Nov. 2008 (UTC)
- ich meine eine W3C-Spezifikation zu "was sollte die kleinste anzeigbare Schriftgröße sein" oder so. wer sagt denn das der code schlecht designd war. das ul-tag hatte eine winzige Schriftgröße (das währe in der tat schlecht) aber das einzig erlaubte tag in diesem ul ist ja das li und das wiederum hat die Schrift wieder vergrößert. ich hab das 'feature' vorhin wieder eingebaut. in der Hoffnung das Opera sich vlt. irgendwann mal anpassen wird werde ich jetzt einfach mal eine nicht-relative Angabe zur Schriftgröße machen--ShismaBitte korrigiert mich 17:01, 3. Nov. 2008 (UTC)
- Ok, Problem gelöst. --Mark McWire 17:07, 3. Nov. 2008 (UTC)
- ich meine eine W3C-Spezifikation zu "was sollte die kleinste anzeigbare Schriftgröße sein" oder so. wer sagt denn das der code schlecht designd war. das ul-tag hatte eine winzige Schriftgröße (das währe in der tat schlecht) aber das einzig erlaubte tag in diesem ul ist ja das li und das wiederum hat die Schrift wieder vergrößert. ich hab das 'feature' vorhin wieder eingebaut. in der Hoffnung das Opera sich vlt. irgendwann mal anpassen wird werde ich jetzt einfach mal eine nicht-relative Angabe zur Schriftgröße machen--ShismaBitte korrigiert mich 17:01, 3. Nov. 2008 (UTC)
- Warum nimmst du eine fixe Schriftgröße? Du hattest schonmal eine funktionierende Version mit relativer. Ich denke es spricht nichts dagegen diese wieder herzustellen: http://memory-alpha.org/de/index.php?title=MediaWiki:Common.css&oldid=221555
Aufgrund des Texts „opera "feature" wieder eingebaut“ in der CSS-Datei-Versionsgeschichte liegt die Vermutung nahe, es ist mir nicht gelungen, erfolgreich zu artikulieren, wo das Problem liegt. Mit schlecht designed meine ich, dass das ul eine winzige und das li eine riesige Schriftgröße hat. Wieso gibt man nicht gleich dem li eine sinnvolle.
„Was sollte die kleinste anzeigbare Schriftgröße sein“ fällt nicht in den Bereich der CSS-Spezifikation. Es gibt eventuell WAI-Richtlinien, aber die kannst du dir jetzt selbst raussuchen (nicht böse gemeint) ;) 84.176.54.142 17:17, 3. Nov. 2008 (UTC)
- Warum nimmst du eine fixe Schriftgröße? Du hattest schonmal eine funktionierende Version mit relativer. Ich denke es spricht nichts dagegen diese wieder herzustellen: http://memory-alpha.org/de/index.php?title=MediaWiki:Common.css&oldid=221555
- ich glaube, du hast den Grund nicht verstanden warum ich überhaupt dem ul die schriftgröße von .1em gegeben habe. wenn ich die Listepunkte mit
display:inline
formatiere und ihnen links noch einen border als Trennlinie mitgebe, entsteht durch das Leerzeichen(oder den Umbruch) bedauerlicherweise eine Lücke nach dem li. ich habe keine Ahnung wie ich die eliminieren soll, außer die Schriftgröße der Zwischenräume so klein wie möglich zu machen. hast du eine bessere idee?--ShismaBitte korrigiert mich
- ich glaube, du hast den Grund nicht verstanden warum ich überhaupt dem ul die schriftgröße von .1em gegeben habe. wenn ich die Listepunkte mit
- Eben, genau dieser Grund war mir völlig schleierhaft. Wobei ich auch ganz ehrlich sagen muss, mir fällt der zusätzliche Zwischenraum (im Opera ja nach wie vor vorhanden) kaum auf. Hätte ich nicht nochmal „nachgemessen“ wegen deiner Aussage, hätte ich das wirklich nicht gesehen. Bei Vorlage:Kriege tritt der Zwischenraum gar nicht auf. Ich kann schlecht abschätzen, wie viele Navleisten davon betroffen sind.
Also wie gesagt, ich hätte kein Problem mit dem zusätzlichen Zwischenraum, aber wenn du ihn gerne weg haben möchtest, kannst du entweder warten bis CSS3 verbreitet genug ist ;) (nach jetztigem Stand wird es möglich sein, Whitespaces vom Browser ignorieren zu lassen) oder – eine praktikablere Lösung – du verwendestfloat:left
stattdisplay:inline
. Dabei gehen die Whitepaces zwischen li und li auf jeden Fall verloren.
PS: Ich hab jetzt doch nochmal nachgesehen, und auch im Firefox oder Safari ist – selbstverständlich – das Festlegen einer Mindestschriftgröße auch möglich. 84.176.54.142 18:18, 3. Nov. 2008 (UTC)
- Eben, genau dieser Grund war mir völlig schleierhaft. Wobei ich auch ganz ehrlich sagen muss, mir fällt der zusätzliche Zwischenraum (im Opera ja nach wie vor vorhanden) kaum auf. Hätte ich nicht nochmal „nachgemessen“ wegen deiner Aussage, hätte ich das wirklich nicht gesehen. Bei Vorlage:Kriege tritt der Zwischenraum gar nicht auf. Ich kann schlecht abschätzen, wie viele Navleisten davon betroffen sind.
- das dachte ich mir auch schon. das problem steht nur an den sen nav-leisten mit validem code(wo die lis nicht von wiki parser geschlossen, was ein noch viel schlimmeres problem auslöst. die float Methode funktioniert leider nicht mit zentriertem text. was gibts denn in CSS3 für eine Lösung?-ShismaBitte korrigiert mich 18:27, 3. Nov. 2008 (UTC)
- Stimmt, floatende Elemente zu zentrieren, ist ein bisschen kompliziert. Wenn die li
float:left
und das uldisplay:inline-block
hat, lässt sich das ul wie ein normales Inline-Element übertext-align:center
zentrieren. Ich zweifle aber momentan daran, dass das im IE auch so problemlos funktioniert.
In CSS3 wird es die „white-space-collapse“-Eigenschaft geben (voraussichtlich; steht noch nicht endgültig fest): http://www.w3.org/TR/css3-text/#white-space-collapse - Nachtrag: Ist auch im IE machbar. Im Firefox3 kein Problem, im Firefox2 dagegen etwas problematisch.84.176.54.142 19:01, 3. Nov. 2008 (UTC)
- has gerade mal getestet.
display: inline-block
rafft bisher noch kein Internet Explorer bei einem block-level element. testumgebung--ShismaBitte korrigiert mich 08:39, 5. Nov. 2008 (UTC)
- has gerade mal getestet.
- Stimmt, floatende Elemente zu zentrieren, ist ein bisschen kompliziert. Wenn die li
- Natürlich. Der IE interpretiert den Wert
inline-block
nicht korrekt. Das Verhalten von inline-block-Elementen, lässt sich aber auch im IE herstellen. Ein Zitat von der von dir verlinkten Seite: “inline-block behaviour” (which the standards define in CSS2.1 9.2.4), can be (in good part) achieved in IE7-, but quite independently on using display:inline-block. Übrigens kann man dort auch sehr schön sehen, dass inline-block (über einen extrem simplen Workaround) im IE funktioniert. Soviel dazu.
- Natürlich. Der IE interpretiert den Wert
- Die inline-block-&-float-Variante bringt allerdings die Zentrierung betreffend ein paar Nachteile, die ich nicht bedacht hatte. Daher würde ich einen anderen Weg gehen, falls das Problem bei _allen_ Navleisten auftritt. Sprich: Befindet sich zwischen zwei lis _immer_ (mindestens) ein Whitespace (
<li>Item1</li>␣<li>Item2</li>
)? 84.176.35.247 13:23, 5. Nov. 2008 (UTC)
- Die inline-block-&-float-Variante bringt allerdings die Zentrierung betreffend ein paar Nachteile, die ich nicht bedacht hatte. Daher würde ich einen anderen Weg gehen, falls das Problem bei _allen_ Navleisten auftritt. Sprich: Befindet sich zwischen zwei lis _immer_ (mindestens) ein Whitespace (
- nein, nicht immer. was immer wir ändern, es sollte unabhängig davon funktionieren--ShismaBitte korrigiert mich 14:11, 5. Nov. 2008 (UTC)
- Gut, mein Vorschlag wäre folgender: Zusätzlich noch ein Hack für den IE, da der ::before nicht kennt.
div.nav ul{padding:0; margin:0;}
div.nav li{display:inline; line-height:1.5em;}
div.nav li::before {content:" \A0|\A0\A0";}
div.nav li:first-child::before {content:"";}
Wie du siehst, wird hier das Zeichen „|“ anstatt border-left als Trennzeichen benutzt, was IMO auch einen Tick besser aussieht (ist aber Geschmackssache ;)
Was hältst du davon? Soll ich das mal testweise abändern? 84.176.35.247 15:04, 5. Nov. 2008 (UTC)
- sieht ganz gut aus. abgsehen natürlich von ie. ich bin für die ohnehin für die Einbindung von ie7.js. damit würden sich solche Fehler erledigen. kann aber sicher nicht mal als Admin solche Scripte verknüpfen. mal eine frage: du hängst ja an das Objekt einige Leerzeichen dran oder? werden diese pseudo-Leerezeichen mit den echten Leerzeichen die in HTML izusammen gemergt oder was?--ShismaBitte korrigiert mich
- IE7.js/IE8.js würde auf jeden Fall vieles vereinfachen; wäre natürlich schön, wenn das jemand einfügen könnte. Zu den Leerzeichen: die verhalten sich, als würden sie im HTML-Code stehen. Die geschützten Leerzeichen nach und vor dem Trennstrich werden auf jeden Fall dargestellt. Das eine „normale“ Leerzeichen, fällt – wie in HTML üblich – mit dem vorhergehenden zusammen. Das ist ja der Clou bei der Sache: falls zwischen den lis bereits ein Leerzeichen ist, fällt es mit dem aus dem CSS-Code zusammen, falls nicht bleibt einzig das Leerzeichen aus dem CSS-Code stehen. 84.176.35.247 15:52, 5. Nov. 2008 (UTC)