| Zeige Beiträge 1 bis 20 von 68 Treffern |
Seiten (4): [1] 2 3 4 nächste » |
 Thema: IE crasht durch HTML Code |
|
|
@GHALeader: Danke für den Screenshot. Da ich nämlich keinen IE habe, kann ich das nicht reproduzieren. Was ist aber "dopetier 10"???
|
|
| Thema: Sprachsteuerung selbstgemacht? |
|
|
| Zitat: |
Original von robsl
soltle man nur noch gut Englisch können 
|
Das heutzutage im Allgemeinen ganz hilfreich, besonders wenn man sich mit Programmieren beschäftigt... Ich weiß nicht, ob es eine deutsche Übersetzung davon gibt, könnte man im Zweifelsfall ja mal nach googlen. Im übrigen fande ich das Englisch von Dave Raggett nicht soo schwierig, als dass man wirklich "gut" englisch können müsste...
|
|
| Thema: Sprachsteuerung selbstgemacht? |
|
|
Hmm, ich glaube "einfache" Sprachsteuerungsprogramme gibt es sicher kaum.
Was genau möchtest du denn machen? Wenn es eine Art sprachgesteuerte Web-Anwendung sein soll, solltest du dich vielleicht mal mit VoiceXML beschäftigen. Dazu gibt es auch ein recht schönes Tut von Dave Raggett: http://www.w3c.org/Voice/Guide/
Gruß,
der Kapitan.
|
|
| Thema: seite halbieren?! |
|
|
| Zitat: |
Original von daisuke
die seite funktioniert nicht..... |
Hmm, der original SelfHTML-Server scheint down zu sein, probier's mal mit http://www.netzwelt.com/selfhtml/html/frames/definieren.htm
| Zitat: |
ich hab mir mal nen paar bücher ausgeliehen,und bin jetzt etwas schlauer als vorher.
ein frameset,das am oberen bildschirmrand habe ich jetzt erstellt!
aber der untere teil des bildschirms ist grau...und ich weiß nicht wie ich ihn aktiviere?! |
Nochmal eine kleine Erklärung: "frameset" nennt man die Datei, die die einzelnen Frames definiert. Die einzelnen Bildschirmteile, die man dann Frames nennt, sind widerum eigene HTML-Dateien. Du musst also jeweils für oben und für unten eigene Dateien erstellen und diese dann im Frameset unter <frame src=""> einbinden.
|
|
| Thema: seite halbieren?! |
|
|
| Zitat: |
Original von Zirias
| Zitat: |
| [quote]Und wenn der Frames deiner Meinung nach den aktuellen Standards nicht mehr entsprechen, solltest du dich für deinen Chat mal mächtig ins Zeug legen. Sonst kann den bald kein Browser mehr lesen
|
Ich glaube du weißt, dass das Bullshit ist. "Frameset" wird weiterbestehen für Anwendungen wo es nicht anders geht. |
Ich weiß, dass das Bullshit ist. Aber ich hatte mich daran orientiert:
| Zitat: |
| Nein. Bereits seit HTML 4.0 sind Frames nicht mehr in der strikten Spezifikation. Also definitiv veraltet. |
Also, definitiv veraltet oder manchmal unumgänglich?
Ich sehe, langsam weicht deine Argumentation auf. Im Prinzip sind wir uns doch einig. Frames sind nicht toll, aber manchmal unumgänglich, in einigen Fällen vielleicht etwas handlicher als andere MEchanismen. Vielleicht könntest du daisuke ja mal erklären, wie man das mit PHP oder WML macht und wo er konkrete Infos dazu findet. Dann kann er die Variante wählen, die ihm am besten gefällt...
| Zitat: |
Programmier mir bitte mal einen reinen HTML-Chat ohne Frames. 
|
Wie gesagt, es ist unpraktisch, aber es geht: Du kannst doch die Eingabemaske ganz oben in die "Chatfenster"-Datei schreiben. Dann sollte man natürlich immer die neusten beiträge oben einfügen. Dann verschwindet jedem Reload eben kurz die Eingabemaske (bereits enthaltenen Text könnte man ja über JavaScript abfangen und in der neuen Maske wieder einblenden). Ist zugegeben für den Nutzer etwas blöd, geht aber ohne Frames. WEnn man möchte!
| Zitat: |
| PS: Eine Möglichkeit fehlt in dem Thread noch komplett, die wäre SSI. Das ist kaum Overhead auf dem Server, weil es keine komplette Sprache ist, und spart einem das lokale "Übersetzen" mit WML. |
Das ist klingt prinzipiell gut 
Ob daisuke das möchte ist ne andere Frage...
Gruß,
der Kapitan.
|
|
| Thema: seite halbieren?! |
|
|
| Zitat: |
Original von Zirias
Da hast du was falsch verstanden. Es gibt keine "strict"-Spezifikation für Framesets sondern eine Definition "Strict", eine "Transitional" und eine "Frameset". Alles was nicht "Strict" ist sollte nach Möglichkeit vermieden werden. Frames KÖNNEN unumgänglich sein, aber das ist extremst selten. |
Und wofür gibt es die Frameset-Variante? Transitionall erlaubt ja auch die Frameset-Tags. Dann wäre die zusätzliche Variante überflüssig. Und das mit den Target-Attributen wäre immer noch inkonsequent... Ich habe gerade mal beim W3C etwas in den Spezifikationen gestöbert und absolut nichts dazu gefunden, dass Frames "deprecated" oder andersweitig nicht empfohlen sind... Auch in den Anmerkungen stehen bei Frames nur einige Tips zur Handhabung von uneindeutigen target-Attributen...
| Zitat: |
| WML = Website Meta Language. Interpreter, der lokal HTML erzeugt, das man dann hochladen kann, also sinnvoll für absolut statische Seiten |
Hmm, das klingt in der Tat interessant. Aber da brauch man dann den lokalen Interpreter, oder? Aber wenn es absolut statisch ist, gibt es doch wieder das Problem des doppelt programmieren, wenn man auf Frames verzichtet, oder?
| Zitat: |
| Falscher Bezug. Bei nem Webchat geht es technisch nicht anders. Für ein Problem wie daisukes sind sie in jedem Fall die schlechteste Lösung. So wars gemeint. |
In jedem Fall heißt in jedem Fall. Hatte das als allgemeines Statement von dir aufgefasst. Und wenn der Frames deiner Meinung nach den aktuellen Standards nicht mehr entsprechen, solltest du dich für deinen Chat mal mächtig ins Zeug legen. Sonst kann den bald kein Browser mehr lesen
Denn technisch geht es anders (ist aber umständlich und nicht sinnvoll, aber wenn man auf Frames verzichten möchte - Bitte!).
Gruß,
der Kapitan.
|
|
| Thema: seite halbieren?! |
|
|
Du widersprichst mir gerne, oder?
Eigentlich wollte ich so etwas ja vorbeugen mit meiner Einleitung, da ich seit ca. 3 Jahren nicht mehr mit Frames programmiere und sie persönlich wirklich ablehne! Ich gehörte damals sogar zu den ersten, die gegen Frames gewettert haben. Aber auch schon damals habe ich immer sachlich argumentiert...
| Zitat: |
Original von Zirias
| Zitat: |
Original von KptSpaltnagel
Es ist nur "veraltet" (d.h. verpönt), Frames dort einzusetzen, wo sie überflüssig sind. |
Nein. Bereits seit HTML 4.0 sind Frames nicht mehr in der strikten Spezifikation. Also definitiv veraltet. |
Der erste Satz ist Richtig. Allerdings hat das W3C für Framesets eine eigene "Strict"-Spezifikation verabschiedet nämlich die Spezifikation "Frameset". Diese gibt es bei HTML 4.01 und XHTML 1.0. Damit sollen (vernünftigerweise) Framesets und "normale" HTML-Dateien auf Definitionsseite getrennt werden. "HTML strict"-Hardliner übersehen aber gerne die Frameset-Spezifikation und nutzen das, um Frames als veraltet darzustellen. Außerdem wäre das target-Attribut in der strict-Variante dann ziemlich überflüssig, wenn es sie nicht geben solle... Also definitiv nicht veraltet.
| Zitat: |
| Aufwand kann man sich sehr viel besser sparen, indem man entweder eine Technik wie WML verwendet oder die Seiten erst auf dem Server von PHP erzeugen lässt. Ersteres ist resourcensparender, letzteres flexibler. |
WML= Wireles Markup Language? Das wäre in der Tat resourcensparend führt IMHO aber nicht zur Lösung des Problems, weil ja eine Seite speziell für ein mobiles Endgerät erstellt wird. Oder meinst du etwas anderes?
PHP ist unter Umständen flexibler (i.d.R. nicht so flexibel wie ich es mit statischem HTML bin), spart aber nicht zwingend Aufwand (gerade wenn man es neu lernen müsste und die Seite sehr klein ist). Vor allem aber ist es bei statischen Seiten völlig unnötig und verlangsamt die Seite nur, bzw. fordert dem Server unnötige Rechenleistung ab. Ist also nicht immer die Allheillösung...
| Zitat: |
| Frames sind in jedem Fall die schlechteste Lösung. |
Wenn es so wäre, wieso verwendet dein Webchat welche? Sie sind oft aber nicht immer die schlechteste Lösung
| Zitat: |
| Du hast daisukes Frage nicht richtig verstanden, es ging nicht darum, dass etwas beim scrollen stehenbleibt. Selbst wenn es darum ginge hättest du aber immernoch unrecht, auch das geht sehr gut ohne Frames. |
Sorry, ich hatte daisuke so verstanden, dass er die Seiten "teilen" möchte, und das impliziert gerade die Verwendung von Frames...
Alles andere wäre da in jedem Fall mit mehr Aufwand verbunden und ist meistens auch nicht so browserkompatibel (Permamente Anzeige durch CSS-Positionierung oder Sticky-script) wie Frames...
Gruß,
der Kapitan.
|
|
| Thema: seite halbieren?! |
|
|
Moin!
Gleich zu allererst eine Klarstellung: Auch wenn ich immer wieder dafür argumentiere, bin ich kein großer Anhänger der Frames-Technologie. Ich programmiere sehr selten Seiten mit Frames. In manchen Fällen sind sie aber ziemlich unausweichlich. Daher halte ich es für Schwachsinn, immer nur damit zu argumentieren, das Frames blöd und alt sind, sondern das Projekt gezielt beleuchten und die Vorzüge der Technologien objektiv betrachten. So, nun zu den Antworten:
| Zitat: |
Original von SS-L
frames wären die eine Lösung! Gelten aber auch als veraltet. Soll nicht heißen, dass es ein ungeschriebenes Gesetz gäbe, dass man das nicht benutzen darf, aber vielle (unteranderem auch ich) benutzen es nicht mehr, weil es nicht mehr zweckmäßig ist (dank DSL *ggg*). |
Es ist nur "veraltet" (d.h. verpönt), Frames dort einzusetzen, wo sie überflüssig sind. Zweckmäßig sind sie nämlich manchmal, weil sie einigen Aufwand ersparen. Der beschriebenen Fall von Daisuke gehört zu dieser Sorte. Übrigens ist die Aussage "sie sind nicht mehr zweckmäßig" absolut falsch. Sie sind bloß out, aber genau so zweckmäßig bzw. zwecklos wie schon immer. Früher wurden Frames jedoch gerne überstrapaziert, daher kommt der schlechte Ruf jetzt...
| Zitat: |
| Was ich eigentlich sagen wollte. Die 2. Möglichkeit wäre das mit PHP zu machen! Ist nicht wirklich schwer. Wenn du keine PHP-Erfahrung hast, kannste ja 'n Buch kaufen, oder 'n Tut saugen! Bei Problemen können dir hier sicher einige helfen. |
Ja, PHP ist wahnsinnig chic und das Allheilmittel überhaupt. Das kann immer hinschreiben und ist dann cool
Leider kann man das "Halbieren" der Seite, sprich die Teilung des Fensters in zwei voneinander unabhängige Bereiche auch über PHP nur mit Frames realisieren, weil es zur Ausgabe halt HTML braucht
@Daisuke, mit Frames teilst du das Fenster und zeigst in einzelnen Teilbereichen (Frames) verschiedene HTML-Seiten an. Dabei kannst du die Teilbereiche unabhängig voneinander verändern, die anderen Bereiche bleiben fix. Wie man Frames einrichtet, wird hier erklärt: http://selfhtml.teamone.de/html/frames/definieren.htm
Gruß,
der Kapitan.
|
|
| Thema: ICQ Wie sicher ist ICQ? |
|
|
| Zitat: |
Original von jakuza
ich wollte mal wissen wie sicher icq ist und ob es möglich is gespräche mit zu loggen? vor allem von den grünweißen!
|
Ich denke mal, dass ICQ schon alles auf dem Server loggt. Ist bloß die Frage, wen sie darein schauen lassen. Hängt wahrscheinlich ab, wo der Server steht. Dürfte aber eher unwahrscheinlich sein, dass unser Trachtenverein da etwas mitlesen kann, das wären dann eher CIA & Co...
|
|
| Thema: Browser Erkennung |
|
|
| Zitat: |
Original von LX
| Zitat: |
Original von KptSpaltnagel
Ich kenne die Empfehlungen des W3C, aber ich heiße sie nicht gut! |
Darf man fragen warum?
|
Gerne. Aber ich denke, die Antwort habe ich bereits in diesem Thread detailliert erläutert. Die freie Positionierung von Objekten passt nicht in mein Verständnis von HTML. Das fällt meiner Meinung nach unter das Aufgabengebiet des Vektorgrafik-orientierten SVG-Standards. Womit auch deine letzte Frage beantwortet sein dürfte. Und zum Thema Corel: Tatsächlich wünsche ich mir, in Zukunft SVGs einfach und ordentlich aus Corel zu erstellen. Das würde mich wirklich glücklich machen
|
|
| Thema: Browser Erkennung |
|
|
| Zitat: |
Original von Zirias
Das ist eben kompletter Unsinn. Es wird GEbraucht, geh W3C lesen. |
Ich kenne die Empfehlungen des W3C, aber ich heiße sie nicht gut! Und meiner Meinung nach werden die <DIV>s gerne missbraucht. Es wundert mich auch nicht, wenn es damit Darstellungsschwierigkeiten im Browser gibt, diese Technik passt einfach nicht in die text-strukturierte HTML-Welt
| Zitat: |
| Und Layer sind etwas, was es in HTML nicht gibt und nie gegeben hat! |
Ich sprach mit Absicht nicht von <layer>-Tags, sondern von dem logischen Begriff "Layer", und der fällt oft in Zusammenhang mit positionierten Divs... Im Prinzip ist das nichts anderes als eine "Nachäffung" der <layer>-Tags, bzw. eine Anpassung an Microsoft's alte DHTML Vorstellungen...
|
|
| Thema: Browser Erkennung |
|
|
Infos zum <DIV>-Tag:
http://selfhtml.teamone.de/html/text/bereiche.htm#block
Ist eine Möglichkeit logische Abschnitte zu erzeugen. Im Gegesatz zum Textabsatz <p> folgt dem <DIV> aber standardmäßig keine zusätzliche Leerzeile.
In den neueren HTML-Varianten wird der <DIV>-Tag aber missbraucht, um LAyer zu erzeugen. Layer sind auf der Seite freipositionierbare Bereiche, also vergleichbar mit dem Textfeld in Word. Das meint man i.d.R. wenn man von "positionierten DIVs" spricht...
GRuß,
der Kapitan.
|
|
 Thema: Schnelle Hilfe: pdf zu .doc konverter |
|
|
| Zitat: |
Original von Zirias
Kpt., mir gings von Anfang an nur um deine Äußerung, dass der Autor keine Weiterverwendung wolle und deshalb in PDF gespeichert hat. Das macht einfach keinen Sinn. Du argumentierst jetzt aber in eine völlig andere Richtung. |
Sorry, da muss ich mich wohl unverständlich ausgedrückt haben. Ich meinte, dass jemand der Weiterverarbeitung wünscht, kein PDF verwenden wird. Und wenn man das so sieht, dann ist es eine logische SChlussfolgerung zu sagen: Wer es als PDF publiziert, geht es nicht um Weiterverarbeitung. Anders habe ich nicht argumentieren wollen.
@Lektor:
Danke für deine Aufklärung
Es ging hier bloß leider nicht um WYSIWYG-Editoren für HTML (auf solche stehe ich ganz und gar nicht, denn das sind meist eher WYGIWYDWTS(What you get is what you don't want to see)-Editoren...), sondern um WYSIWYG-Editoren fürs PDF-Format. Phase 5 von Ully Meybohm (mein absolutes Lieblingsprogramm für HTML-Entwicklung) ist aber kein WYSIWYG-Editor, sondern ein Quellcode-Editor
Gruß,
der Kapitan.
|
|
| Thema: Schnelle Hilfe: pdf zu .doc konverter |
|
|
| Zitat: |
Original von Zirias
Fakt bleibt aber, dass PDF nicht dafür geschaffen wurde, Bearbeitung zu verhindern. |
Das habe ich auch weiterhin nicht gesagt. Das Format hat aber auch keine Mechanismen eingebaut, die eine gute Weiterverarbeitung erleichtern. Das ist auch ein Grund, wieso PDFs kleiner sind als Word-Dokumente, CorelDraw-Dateien und was auch immer als Quelle diente. Es geht hier um das schnelle und einfache publizieren und weitergeben von Daten, nicht aber das gemeinsame arbeiten an einem Dokument. Wenn ich jemanden einen Text schicke, der diesen korrigieren soll, tue ich das doch wohl nicht als PDF, oder?
Gruß,
der Kapitan.
|
|
| Thema: Browser Erkennung |
|
|
| Zitat: |
Original von Zirias
Na du machst da offensichtlich etwas falsch. Die Auslagerung sämtlicher Formatierungen etc. soll gerade bei Änderungen hilfreich sein und das ist sie auch. Mit Tabellen hast du dich da sehr viel schneller verhaspelt (JA, ich rücke ein). |
Was heißt für dich die "Auslagerung sämtlicher Formatierungen"? Das ich alles außer dem <div>-Tag und dem TExt ins CSS schreibe? Im Zweifelsfalle muss ich dann bei Ändern des Textes ins CSS wechseln und Positionierungen ändernt. Das brauche ich bei Tabellen nicht machen, weil gar nicht genau positioniert wird, sondern logisch! Und das ist doch das HTML-Prinzip...
Ich arbeite für mein Leben gerne mit dem <TH>-Tag, da mit kennzeichen ich logisch einen Überschriftsbereich, mit <td> einen Inhaltsbereich. Das geht mit DIVs aber nicht so schön. Und allein mit <h1-6> gibt es keine Flächeneffekte für Überschriften wie beim <th>. Da muss dann ein neues Div mit einer neuen class hin und das ist eigentlich auch nicht Sinn der Sache..
| Zitat: |
| Auch was das Textdokument angeht: Andersherum wird n Schuh draus. HTML soll ein reines Textdokument sein, lediglich mit einer ~logischen~ Struktur versehen. Was mit Layout zu tun hat, hat eigentlich nichts (mehr) in HTML zu suchen. Das erhöht ganz beträchtlich die Übersichtlichkeit. Dass man es auch ganz grauenhaft "falsch" machen kann ist kein Argument dagegen, das kann man bei Tabellen auch (die zu Layoutzwecken schon per se falsch sind, aber du weißt was ich meine) und ich denke mal das kann man da noch viel schlimmer
|
Stimmt, Tabellen sind zu Layout-Zwecken ungeignet, aber der Klassiker für logische Strukturierung! Auch außerhalb von HTML...
Und das Layout kann ich bei Tabellen mindestens genauso schön ausgegliedern wie bei Divs...
Gruß,
der Kapitan.
|
|
| Thema: Browser Erkennung |
|
|
| Zitat: |
Original von Zirias
[quote]SVG ist Vektorgrafik und mit Sicherheit nicht für das Layout von Seiten gedacht. Positionierte DIVs sind da nach dem HTML-Verständnis des W3C die einzige korrekte Möglichkeit (wegen Trennung von Layout und Inhalt/Struktur) 
|
Einen guten Vektor-Format schreibe ich die Funktionen zu, die der Klassiker CorelDraw bietet, und das taugt sehr wohl zum Seitenlayout. Es geht mir aber vielmehr um die unterschiedliche Logik zwischen Textdokument und Vektor-Dokument:
- Ein Text-Dokument hat eine feste Reihenfolge und ist streng linear aufgebaut. Ohne einzelne WErte auszulesen kann ich an der Reihenfolge der Elemente im Quelltext die Reihenfolge der Elemente in der Ausgabe erkennen. Tabellen sind dabei ein legales Mittel der "Strukturierung", weil sie auch streng nach Reihenfolge funktionieren...
- Vektordokumente dagegen arbeiten mit auf der Arbeitsfläche frei positionierbaren Elementen. Die Reihenfolge der Elemente ist dabei oft identisch mit der Anordnung an der z-Achse (bei positionierten HTML-Divs ist nichtmal das zwingend...).
Darüber hinaus kann ich bei beiden Paradigmen Inhalt und Layout trennen oder vermischen. Im konkreten Fall HTML hängt das immer davon ab, wieviel ich an CSS ausgliedere oder nicht...
| Zitat: |
Ich mache auch fast alles mit Tabellen, das geht auch in der Tat sehr gut und ich habe es bisher immer so gemacht, weil es der einzige Weg ist, dass auch IE meine Layouts kapiert ohne dass ich dem Schlagamnfall nahekomme
Aber die Nachteile liegen auf der Hand und schlechter Stil ist es auf jeden Fall. Nur eben ein schlechter Stil, zu dem man in vielen Fällen noch gezwungen wird. Ich habe jetzt mal testweise eine Seite mit positionierten DIVs aufgebaut und es ist wirklich frappierend, wieviel übersichtlicher dadurch der HTML-Code wird. Selbst die "CSS-Wurst" Ist allein eher leserlich als 5- oder 6fach verschachtelte TABLEs 
Naja und IE zeigt eben nur Müll an *g*
|
5 oder 6 Tabellen-ebenen ist auch schon etwas fille
Mehr als drei Ebenen brauche ich eigentlich selten. Und den HTML-Code mit Tabellen finde ich extrem übersichtlich (wenn man sauber erinrückt und so...). BEi Div-Seiten kriege ich immer ein Hals, wenn die Reihenfloge der Divs im Dokument nichts zu tun hat mit der Darstellung. Denn sobald man Textbereiche nebeneinander gruppiert, kommt die Frage auf: In welcher Reihenfolge mache ich das? Für die Anzeige ist es irrelevant, für die Übersichtlichkeit des Codes mag es aber entscheidend sein. Bei Tabellen muss ich zeilenweise von links nach rechts arbeiten, und zwar immer!
Ein weiteres Problem von Divs ist meiner Meinung nach die spätere Änderung der Inhalte. Schnell zerhaut eine zusätzliche Zeile alles, vor allem wenn andere Divs relativ zum ersten positioniert sind... Tabellen sind da weniger fehlersensitiv. SChau dir mal die verschiedenen Seiten unter www.xnot.net/dip an, die haben ganz verschiedenen Inhalt, werden häufig geändert, haben aber alle einen absolut identischen Grundaufbau. Bei keiner BEarbeitung habe ich auch nur einen width= oder height= Wert der Hauptstrukturen geändert und sowieso wenig Attribute geschrieben. Trotzdem hat sich so einiges geändert... und alle Änderungen waren schnell und ohne großes Austesten gemacht! Ich glaube nicht, dass ich das mit Divs genauso einfach hätte...
Ein anderer Punkt ist noch, dass Tabbellenzellen sich nie überlappen können. Denn durch die Überlappung resultieren viele Anzeigefehler bei Divs...
Gruß,
der Kapitan.
|
|
| Thema: Schnelle Hilfe: pdf zu .doc konverter |
|
|
| Zitat: |
Original von Zirias
Beide Formate sind Klartext, im Zweifelsfall also sogar mit jedem Editor bearbeitbar, wenn man die Sprache beherrscht. An WYSIWYG-Editoren mangelt es zwar etwas, aber die Formate sind überall verfügbar (darum gehts, sonst um nichts!) und in keiner Weise gegen Bearbeitung geschützt! |
Das habe ich nicht gesagt! Die Bearbeitung ist jedoch relativ schwierig. Zumindetst mit dem verfügbaren WYSIWYG-Editor Acrobat.
Und soweit ich weiß, hatte Adobe das Format nie dafür gedacht, dass damit später noch gearbeitet wird. Dann würde auch das Programm Acrobat etwas anders aussehen. PDF ist zum plattformunabhängigen Publizieren gedacht.
Falls du dich mit der PDF-Sprache auskennst: Wenn ich es richtig verstehe, gibt es keine Fließtext-Absätze, sondern es wird immer zeilenweise gearbeitet, oder? Das ist IMHO schon die größte BRemse für einen nachträgliche TExtbearbeitung. Auch im Acrobat kann man nur in Textzeilen, nicht in Absätzen arbeiten...
|
|
| Thema: Browser Erkennung |
|
|
| Zitat: |
Original von CrayX
Okay, ihr habt mich überzeugt, dann mach ich s halt ohne Weiche. Ab er ich fände sowas auf jeden Fall cool. Ist wenigstens besser, als zu sagen ich hab Netscape un die anderen sollen sich den auch holen, oder sie können meine Seite nicht sehen. 
Das ist ein bisschen dumm, denn diesen "Aufwand" scheuen viele User, und würden statt dessen deine Seite nicht mehr Besuchen.-
|
Vielleicht wurde durch unsere Diskussion eines nicht ganz klar:
Wir wollen dich auf keinen Fall dazu überreden, eine Seite zu bauen, die nur auf dem eigenen Browser geht, sondern eine Seite, die von Haus aus auf so gut wie allen Browsern gescheit läuft. Dazu sollte man sich an die Standards halten. Das ist auf jeden Fall ein "sauberer" Weg. Es ist aber so, dass das Anpassen aktueller Seiten an die Macken von Netscape 4 nicht nur zeitaufwändig sondern auch nervenzehrend ist. Da der Browser kaum noch verbreitet ist, sollte man sich gut überlegen, ob man das auf sich nimmt.
|
|
| Thema: Mozilla ist tot, es lebe Mozilla! |
|
|
| Zitat: |
Original von LX
I.e. der "alte Browser" (Mozilla) macht bei CSS Probleme? Wobei denn das? |
Je nachdem, wie speziell man's braucht...
Es gibt so'n paar Sachen, die sind nicht ganz so schön, z.B.:
- margin-left:0px bei Listenelementen, da verschwinden die Aufzählunsgzeichen im Nirvana...
- Arbeiten mit automatischer css-Numerierung, Variable usw. Da gab es letztens in der iX ein Beispiel. Das hat von allen aktuellen Browsern nur Opera 7 hinbekommen...
- CSS-Formatierungen von <hr>-Linien sind bei Mozilla bisher nicht möglich
Gruß,
der Kapitan.
|
|
|
| Zeige Beiträge 1 bis 20 von 68 Treffern |
Seiten (4): [1] 2 3 4 nächste » |
|
