Brauche CSS-Hack

Webdesign & Technik HTML & CSS
#1

Servus Community!

Ich persönlich versuche mich gerade ein wenig in Stylesheets. Das altbekannte Problem heißt IE und kommt aus dem Hause Microsoft.

Ein Bild sagt mehr als tausend worte, deswegen vergleicht selbst: niedermann.bplaced.de

Was ich suche, ist ein CSS-Hack für das Design, der das ganze beim IE zumindest etwas gerade rückt.
aber: was ich NICHT brauche sind runde ecken. ich hab das gefühl das wird sonst zu kompliziert. also muss nich sein, es soll nur etwas gerade sein.

leider habe ich weder die erfahrung noch die zeit mich ewig lange mit googlen zu beschäftigen, und ich glaube das ist etwas “höheres” was ich nicht aus i-einem tutorial lernen könnte.

cool wäre wenn der platz unten bei der linken “link-liste” wegfällt - den brauche ich bei anderen browsern schließlich nur um den schönen runden bogen hinzubekommen.

vielen dank im voraus :slight_smile:

ps.: ich weiß, das hier ist nicht der showroom, aber ich bitte trotzdem um meinung: das design soll das alte - aurachtaler.bplaced.de - ablösen. schaut bitte nicht auf den inhalt der neuen seite - mir wurden unter anderem schon die riesigen bild-grössen kritisiert - das kommt alles noch, das ist eine DESIGN-frage. die zielgruppe sind 30-40 jährige leute aus meiner “dörflichen” umgebung für einen kleinen dorf-verein - sprich es ist mit absicht etwas - manche sagen langweilig - schlicht, und es soll seriös wirken.

#2

Erst mal die Fehler im HTML beseitigen:
validator.w3.org/check?uri=http% … 1.0+Strict

#3

Ääähm, gutes argument, bei allgemeine hilfe & support hab ich vorhin rumgejammert dass der validator bei mir gemuckt hat, weswegen ich nich alle fehler rausbekommen hab (bisher halt)

ach ja und, das is html 5 nich xhtml 1.0 wie dus angegeben hast, mach “detect automatically” - dann sin die einzigen “fehler” dass ich ein paar sachen nicht per css gemacht habe, sondern direkt in den html-tag geschmissen hab…

#4

Nein, da ist auch noch ein dicker Verschachtelungsfehler drin, der gehört auf jeden Fall beseitigt.

Und überhaupt solltest du mit HTML sinnvoller umgehen (lernen) - so, dass es die Struktur der Inhalte auch möglichst gut auszeichnet.

Bspw. machst du die Hauptnavigation sinnvoller Weise schon als Liste - aber warum ist dann das unten im Inhaltsbereich, „Vereine und Firmen aus der Gegend:“, nicht auch eine …?

Und du solltest Überschriften sinnvoller einsetzen - bisher ist da nur eine einzige H3-Überschrift drin, sonst keine einzige, egal welcher Stufe! Das ist definitiv kein sinnvoller Struktur-Aufbau.
Und Überschriften-Stufen „überspringen“ sollte man auch keine - d.h. als erstes kommt mal H1 (könnte bspw. das ersetzen, was derzeit

ist), danach welcher zweiter Ebene, etc.

EDIT: Und behebe bitte mal die im anderen Thread angesprochene Sache mit den Bildern - das nervt nämlich beim Testen; und die „ich hasse es, etwas verlustbehaftet zu komprimieren“-Einstellung ist wenn es um Webdesign geht absoluter Humbug, also lege die bitte auch ab.

#5

Wenn die Fehler beseitigt sind und die Struktur mit sinnvollen
Elementen realisiert wird und dann immer noch Probleme mit
CSS auftreten, gibt es da folgende Verdächtige:

  1. browser-Stilvorlage nicht überschrieben (die kann bei
    unterschiedlichen browsern anders sein, besonders was
    Randabstände (margin, padding) anbelangt.

  2. die Anzeige im MSIE kann von der Version abhängen, bei
    neueren Versionen wohl auch davon, ob man an dem Teil
    eingestellt hat, daß es korrekt arbeiten soll oder eher so wie alte
    Versionen - auf letztere Einstellung hat man als Autor natürlich
    keinen Einfluß.
    Angeblich kann man für den MSIE in neueren Versionen aber per
    meta-Element einstellen, ob man alt oder neu haben will (habe ich
    nie ausprobiert, halte ich inhaltlich für unsinnig, daher habe ich mir
    auch nicht gemerkt, was die meinen, was man da angeben kann).

Verbleiben dann noch Fehler bei bestimmten Versionen des
MSIE, kann man per sogenannten ‘conditional comments’ hinter
dem link-Element zur allgemeinen CSS-Datei noch weitere
versionsspezifische CSS-Dateien nur für den MSIE angeben, wo
man Angaben für den reinschreibt, Fehler kompensiert oder die
Stilvorlage so weit vereinfacht, daß der Inhalt wenigstens passabel
lesbar ist. MSIE 8 oder 9 sollten eigentlich weitgehend ohne dies
auskommen, wenn obige Verdächtige 1 und 2 ausgeschaltet wurden.

Ansonsten: HTML5 ist derzeit (und wohl auch noch die nächsten
Jahre) erst im Stadium eines Arbeitsentwurfes, einerseits kann
sich der Kram jederzeit ohne Vorwarnung ändern, zum anderen
darf man nicht erwarten, daß die browser da bereits besonders
viel von implementiert haben. Diese Version von HTML5 empfiehlt
sich also derzeit eher nicht, um außerhalb von Testseiten
verwendet zu werden.
Der Validator für HTML5 ist experimentell, auch dessen Resultate
können sich jederzeit ändern - was heute richtig ist, kann morgen
falsch sein und umgekehrt (zumindest was einige Feinheiten
anbelangt, weniger prinzipielle Sachen wie Verschachtelungsfehler).
Nach meinen wenigen Tests liefert der experimentelle
HTML5-Validator auch so schon öfter man falsche Ergebnisse - kann
man sich also nicht drauf verlassen will. Wer es wirklich richtig
machen will, müßte seine Dokumente mindestens täglich anhand
des aktuellen Arbeitsentwurfes kontrollieren und gegebenenfalls
anpassen.

#6

[quote=“hoffmann”]Angeblich kann man für den MSIE in neueren Versionen aber per
meta-Element einstellen, ob man alt oder neu haben will (habe ich
nie ausprobiert, halte ich inhaltlich für unsinnig, daher habe ich mir
auch nicht gemerkt, was die meinen, was man da angeben kann).[/quote]
aktuell.de.selfhtml.org/weblog/k … explorer-8

#7

Wenn du noch infos zu Conditional Comments suchst, wirst du hier fündig.

#8

klasse 1. mal danke

weiter gehts mit diesem netten kleinen problem-kind:

validator.w3.org/check?uri=http% … ator%2F1.1

ich bekomme einen fehler, das von einem

tag auszugehen scheint. allerdings ist dort kein solcher tag :smiley:

ich hab im quellcode nachgeschaut, ich hab in der php-ursprungsdatei nachgeschaut, überall wo was eingebunden oder generiert wird, da darf kein

-tag stehen, und er is auch nicht da.
er wird nur angemosert.

Ob das wohl am experimentellen html 5 validator liegt??

EDIT: @hoffmann
Mir ist bewusst, dass html 5 noch nicht mal annähernd “fertig” ist, allerdings habe ich keine lust die komplette seite neu zu schreiben wenn es so ist.
des weiteren verwende ich ja keine der, ich sag mal “komplizierteren” dinge, etwa neue tags () - das meiste dürfte sich wohl kaum ändern, etwa
und

und

etc…

naja, trotzdem schonmal danke

#9

Doch.

Kreuze bei den Validierungs-Optionen “Show Source” an, dann verlinkt dich die Fehlermeldung direkt auf die richtige Zeile.

Und ja, da ist ein

, zu welchem es kein öffnendes

gibt.

Nein - an mangelnden Grundkenntnissen.

HTML5 führt es wieder ein, dass Elemente nicht immer explizit geschlossen werden müssen.
Wenn du den Code als XHTML 1.0 Strict validieren lässt, bekommst du eine Fehlermeldung, die etwas klarer ist, weil sie diesen Umstand nicht berücksichtigen muss.

#10

Wenn ich als XHTML validieren lasse, bekomme ich gar keinen Fehler mit

.

“mangelnde Grundkenntnisse”. Hab ich i-wo behauptet ich wäre der top-ober-pro? ich frage mich manchmal, wofür es ein support-forum gibt, wenn man sich jedes mal wieder das selbe anhören darf wenn man ein problem hat. Dafür fragt man doch oder? weil man es lernen möchte?

#11

Aber einen an ähnlicher Position - und das ist auch die fehlerhafte Stelle, dein

-Fehler ist ein Folgefehler davon.

Ja - aber die Fehlermeldungen des Validators sollte man auch verstehen lernen.

Und deshalb wies ich dich darauf hin, dass dir bei Validation als XHTML ganz klar angezeigt wird, wo dein Fehler liegt.
Wenn du den trotz Erklärung des Validators nicht verstehen solltest - dann ist es vielleicht noch ein bisschen früh für dich, dich an HTML5 zu wagen.

#12

Na schön, der Fehler ist beseitigt. Aber. Man will ja nicht dumm sterben, also:

#13

Tja, und damit sind wir wieder beim Grundlagenwissen …

P darf keine weiteren Block-Elemente enthalten, sondern nur inline-Elemente und #PCDATA.

#14

grins okay, ich geb mich geschlagen.
Wieder was gelernt :wink:

#15

Glückwunsch zum gefundenen und verstandenen Fehler ;o)

Die Schwächen von dem experimentellen Validator sind meist
subtiler. So grobe Schnitzer bekommt der spielend raus.
Der gibt insbesondere unzutreffende bis unsinnig Tips, wenn
eine andere Version der Sprache angegeben ist, als er mag.
Dann pflegt er die Angabe zu ignorieren und dummes Zeug
rauszulassen.
Dann gibt es aber auch einige Dinge, die man gemäß Arbeitsentwurf
nicht immer angeben muß, der Validator streicht das dann aber
trotzdem als Fehler an (was inhaltlich oft sinnvoll ist, im Sinne des
Arbeitsentwurfes aber nicht korrekt, weil der explizit auch definiert,
wie man eine möglichst sparsame und dann auch eher
unzugängliche Markierungssuppe anrührt, dem aber folgt der
Validator nicht konsequent, weswegen das letztlich weder Fisch
noch Fleisch ist, was da bei dem herauskommt.
Der alte Validator hat aber auch nur anhand der
Dokumenttypdeklaration geprüft, dessen Aussagen muß man bei
einigen subtilen Details auch mit eigenen Kenntnissen gegenprüfen.
Neuere Empfehlungen ohne DTD (doctype) kann der gar nicht
prüfen. Daher macht das HTML5 auch ein ganz anderer Validator,
bei dem alles komplett handgestrickt ist.

Wenn du ohnehin nichts von HTML5 verwendest, kannst du auch
gleich eine derzeit gültige Version von (X)HTML verwenden ;o)

Ach so, daß einige Elemente automatisch ergänzt oder
geschlossen werden, gibt es in HTML4 genauso, das hat man in
HTML5 nur nicht verbessert, ist also nicht neu, sondern ein altes
Problem, was HTML für Autoren deutlich komplizierter macht als
XHTML, obwohl das eigentlich mal zur Vereinfachung gedacht war.
Eine falsche Verschachtelung oder fehlende Elemente sind in
XHTML auch Unfug, nur werden die da nicht ergänzt und es wird
auch nichts automatisch geschlossen - schon gar nicht an einer für
den unerfahrenen Autor überraschenden Stelle - was dann für
lustige Effekte bei der Anwendung von CSS sorgen kann.

Immerhin hat man in HTML5 inzwischen die Kurzmarkierungen
gestrichen, die kaum jemand verstanden habt, erst recht nicht
die Programmierer der allgemein gebräuchlichen browser, daher
wurden die fast nirgends implementiert. Das führt wiederum dazu,
daß in HTML5 einiges mehr als Fehler angestrichen wird, was in
HTML4 keiner ist (der Validator für HTML4 ist wohl einer der
wenigen, der die Kurzmarkierungen richtig interpretieren kann).

#16

Öööhm,… Danke :wink:

Joah, ich hab jetz mal den Rat befolgt auf xhtml 1.1 umzusteigen (scharf war ich vor allem auf die neuen input-types, opera und ff interpretierns ja schon zum teil)…

bei mir ist eine etwas allgemeinere css-frage aufgetaucht. ich habe bisher noch nie mit media-typen gearbeitet.

laut google ist der aufbau ja so

@media screen {
body {blablabla}
}
@media print {
body {blablabla}
}

is das so richtig, kann ich das alles in eine einzige datei schreiben? und der browser “sucht” sich dann automatisch das richtige raus?

ich hab auch gehört dass man css einbinden kann - also ne style.css datei und dann noch eine z.b. screen.css und eine print.css, die in der style.css eingebunden werden (und im html muss ich dann halt nur noch diese eine style.css einbinden). stimmt das / wie funzt das? :stuck_out_tongue:

#17

Falls du wirklich XHTML 1.1, und nicht die XML-Variante von HTML5 meinst - Auweia.

[quote]bei mir ist eine etwas allgemeinere css-frage aufgetaucht. ich habe bisher noch nie mit media-typen gearbeitet.

laut google ist der aufbau ja so

@media screen {
body {blablabla}
}
@media print {
body {blablabla}
}

is das so richtig, kann ich das alles in eine einzige datei schreiben? und der browser “sucht” sich dann automatisch das richtige raus?[/quote]
Ja, kannst du.

Was der Browser zu Anwendung bringt, hängt natürlich neben der Reihenfolge der Einbindung noch von der Spezifität der jeweiligen Selektoren ab.

de.selfhtml.org/css/formate/einb … link_media und #media

de.selfhtml.org/css/formate/einb … #at_import

#18

Waaaaaaas?? :ps: :ps:
Wieso is, was is schlimm dran? von html 5 wurde mir (einleuchtend) abgeraten, dann kommt für mich doch nur ne möglichst aktuelle xhtml version in frage…

#19

Als aktuell im Sinne von Verbreitung und Browserunterstützung kommt nur XHTML 1.0 in Frage.

Vor allem soll XHTML 1.1 als application/xhtml+xml ausgeliefert werden, womit du im IE bis einschließlich Version 8 aber nur den XML-Baum angezeigt bekommst.
Wenn du das ignorieren willst, und es trotzdem mit Auslieferung als text/html durch einen sog. Tag-Soup-Parser schicken lassen willst - dann bringt dir 1.1 überhaupt keine Vorteile gegenüber 1.0, nicht mal gegenüber HTML 4.01.

Du solltest dir wirklich angewöhnen, dich erst gründlich zu informieren, bevor du immer sofort auf’s erste Pferd springst, dessen Name „neu genug“ klingt.

#20

Die oben genannten Selektoren dienen ja gerade dazu da, um für
verschiedene Ausgabemedien andere Stilvorlagen anzubieten,
nachzulesen etwa auch in 7.2.1 von CSS2.1

In diesem Falle ist das erste also für eine Ausgabe auf dem Monitor
gedacht, das zweite zum Drucken. Welches Darstellungsprogramm
das dann wirklich umsetzt, ist eine andere Frage ;o)

XHTML1.1 nutze ich auch - mit XML-Ausgabe. Veraltete Versionen
von browsern (netscape4, MSIE) bekommen das dann als
HTML-Markierungsuppe spendiert - ist dann zwar formal ein
fehlerhaftes HTML-Dokument, stellt praktisch aber kein Problem
dar - für den Leser mit altem browser immer noch besser als gar
nichts lesen zu können.
XHTML1.0 sollte man eigentlich genauso als XML ausgeben lassen,
nicht als HTML, im letzteren Falle ist das Dokument zumindest
genauso falsch - darin gibt es da keinen Unterschied zwischen den
beiden Versionen.

Inhaltlich ist der wesentliche Unterschied von XHTML1.1 zu
HTML4.01 strict oder XHTML1.0 ein Modul für Ruby-Notation,
braucht man eher im asiatischen Raum. Von daher muß man da
nicht umsteigen. Die aktuellste Version von XHTML ist
XHTML+RDFa1.0. Das hat wirklich einige sehr interessante neue
Attribute. Bei neueren Projekten nutze ich das daher. Bei älteren
strebe ich langsam eine Umstellung an. Was ähnliches ist als
zusätzliches Modul für HTML5 auch in Arbeit, kämpft aber noch
mit der allgemeinen Problematik von HTML5, daß man da sinnvolle
Verbesserungen kaum einfach mal machen kann, auch weil sich
die Arbeitsgruppe gegen die Einführung von Funktionen sträubt,
die es Autoren erlauben, wohldefinierte Erweiterungen zu nutzen,
wie das bei XML/XHTML1.1 möglich ist - das täte der Arbeitsgruppe
ja Macht, Einfluß, Dominanz und Relevanz rauben, was man
natürlich auf jeden Fall vermeiden will ;o)
Für Formulareingaben gibt es da aber auch nicht direkt was neues,
gut, man kann das formal mit den neuen Attributen zum Ausdruck
bringen, was die spezifische inhaltliche Bedeutung ist, glaube aber
nicht, daß die browser darauf anders reagieren, wenn man damit
eine andere Art von Eingabe definiert.
Mag sein, daß sie das aber bei einer entsprechenden Angabe wie
für HTML5 vorgeschlagen ohnehin tun, unabhängig von der
verwendeten Version, denn für solche Details sind in den aktuellen
Formaten meist keine Regeln angegeben, wie auf fehlerhafte
oder unbekannte Attributwerte zu reagieren ist - meist ist
stattdessen einfach die Voreinstellung zu verwenden. Zudem
verwenden die ohnehin nicht für verschiedene Versionen andere
parser-Regeln, das ist alles nicht sauber programmiert, was man da
vorfindet.
Jedenfalls ist das wohl so formuliert und getestet, daß die gängigen
alten browser den Kram auch noch losschicken können, obwohl
man diese neuen Angabe macht - ist also bei einer alten Version
von (X)HTML zwar inhaltlich unsinnig, funktioniert praktisch aber
ausrreichend.