Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Cookies in Safari

Cookies in Safari

MacRudi26.07.1416:27
Gibt es eine Erweiterung, die einem eine Liste der Seiten erstellen lässt, die keine Erlaubnis haben sollen, Cookies abzuspeichern? In Safari 8 gibt es sowas ja noch nicht eingebaut.
0

Kommentare

jeti
jeti26.07.1416:42
Eine vernünftige Cookie-Verwaltung suche ich auch noch.
Alle Safari-Erweiterungen bzw. Zusatzprogramme welche ich ausprobiert habe
waren meines Erachtens mehr schlecht als recht umgesetzt => Suche ebenfalls noch.
Im Apple-Store wird zum Beispiel CookieStumbler kostenfrei angeboten
Oder das kostenpflichtige Cookie

Verdammt Apple, so etwas gehört einfach von "Haus aus" in einen Browser!
0
sierkb26.07.1416:43
Z.B.:

Safari Cookies
oder
Cookie ,

Beide jeweils vom selben Hersteller.
0
Gerry
Gerry26.07.1416:43
Erweiterung kenn ich keine, aber ich kann dir zu Cookie raten. Das hab ich im Einsatz und ist sehr gut.

Das Tool findest du im Mac App Store und heisst einfach Cookie .
Cookie - https://macappsto.re/at/2zvXy.m

Es erfasst auch die von Flash und Silverlight

Du kannst da fest legen welche dürfen und wann gelöscht werden sollen und andere dinge.
0
jeti
jeti26.07.1417:07
Gerry
Erweiterung kenn ich keine, aber ich kann dir zu Cookie raten. Das hab ich im Einsatz und ist sehr gut.

Ok Erweiterung war eventuell etwas missverständlich ausgedrückt,
Safari Cookies hatte ich bereits im Einsatz mit einem enttäuschenden Ergebnis.
Entsprechende Cookies wurden NICHT gelöscht => Ergo war wieder viel Handarbeit angesagt.

Von Cookie hatte ich mir vor einiger Zeit die Trail-Version geladen => identisches Ergebnis.
Ist ja keine Wunder wenn beiden von demselben Entwickler stammen.
0
Hot Mac
Hot Mac26.07.1417:27
Ich verwende auch schon seit Jahren Cookie.
Funktioniert bei mir „ganz“ gut.
Gegen manch einen Scheiß ist aber kein Kraut gewachsen.

Unter iOS verwende ich fast ausschließlich iCab Mobile.
Mag sein, daß Safari der beste und schnellste Browser ist, aber warum jammern dann alle?
0
promac26.07.1417:48
jeti
Safari Cookies hatte ich bereits im Einsatz mit einem enttäuschenden Ergebnis.
Entsprechende Cookies wurden NICHT gelöscht => Ergo war wieder viel Handarbeit angesagt.

Glaube ich dir definitiv nicht ! Bei mir ist es so eingestellt das bei jedem Beenden von Safari der Müll gelöscht wird. Kannst sogar so konfigurieren das nach xx Minuten die Cookies die nicht als Favoriten gesetzt sind automatisch gelöscht werden. Benutze es schon seit mehreren Jahren und es funzt einwandfrei !
0
jeti
jeti26.07.1419:44
promac

Wie bereits erwähnt ist bei mir schon einige Zeit her,
aber besten Dank für den Hinweis und den ScreenShot.
Werde mir gerne die Trail-Version herunterladen und erneut testen,
sofern es dann funktioniert kann man ja bedenkenlos zuschlagen.

In dem Zusammenhang:
Weiß eventuell jemand ob eine ähnliche Funktion in Safari 8 (Yosemite) implementiert ist?
0
jeti
jeti26.07.1419:47
Hot Mac
Unter iOS verwende ich fast ausschließlich iCab Mobile.
Mag sein, daß Safari der beste und schnellste Browser ist, aber warum jammern dann alle?

Ja icab ist echt prima, war viele Jahre auf dem Mac mein bevorzugter Browser,
sogar noch weit vor OS X => immer schnell und zuverlässig.
Gefallen hat mir auch die Funktion das sich icab als Browser xy ausgeben konnte.
0
RiddleR
RiddleR26.07.1419:58
jeti

Gefallen hat mir auch die Funktion das sich icab als Browser xy ausgeben konnte.

Das kann Safari auch.
0
MacRudi26.07.1420:57
Weil ich in Safari 8 (Yosemite) das nicht fand, habe ich die Frage hier gestellt, siehe oben
0
promac26.07.1421:04
jeti
Gefallen hat mir auch die Funktion das sich icab als Browser xy ausgeben konnte.

Musst in Safari nur das Entwickler Menü einschalten unter Einstellungen > Erweitert !
Sieht dann so aus ...
0
jeti
jeti26.07.1423:43
RiddleR
jeti

Gefallen hat mir auch die Funktion das sich icab als Browser xy ausgeben konnte.

Das kann Safari auch.

Aber zu den Zeiten vor OS X gab es kein Safari => Ergo damals
0
sierkb27.07.1400:09
OT:
jeti
Gefallen hat mir auch die Funktion das sich icab als Browser xy ausgeben konnte.

Ausgeben konnte ist gut. Er musste es. Leider. Notgedrungen. Weil er sonst von Browserweichen, die eben aufgrund des begrenzten Vorstellungsvermögens und korrekten Verständnisses mancher Seitenbetreiber, wie man gewisse Dinge browserneutral für alle Browser tätigt, leider nur IE-Browser und Netscape-Browser kennen wollten, gnadenlos nicht erkannt worden und von zahlreichen Webinhalten ausgesperrt gewesen wäre. Also musste er (bzw. initiiert durch den betreffenden Nutzer), wenn es nicht anders ging, notgedrungen seine wahre Identität verleugnen und sich maskieren und als jemand anderes ausgeben als er tatsächlich war und konnte leider nicht sagen: "Ich bin ein iCab-Browser". Sondern musste schummeln und nach außen hin sich als Internet Explorer oder Netscape Browser ausgeben. Um von Browserweichen erkannt und durchgelassen zu werden. Ging dem Opera-Browser damals leider ganz genauso, den wollte so manche Browserweiche und Webseite auch nicht kennen, der hatte deshalb auch diese Möglichkeit, sich als ein anderer Browser auszugeben. Obwohl technisch dazu in der Lage, die betreffenden Webinhalte anzuzeigen.

Bzgl. Konqueror/KHTML, der Mutter von WebKit, ebenso. Wollte lange Jahre niemand kennen, dass dieser Browser existiert bzw. viele Webseitenersteller taten den als zu unwichtig und zu wenig genutzt ab. Ist viele Jahre ein totaler Irrweg gewesen, vom Denkansatz völlig falsch, hier browserorientiert zu filtern und den Webinhalt nach den beiden größten Spielern im Feld auszurichten statt für alle (für alle deswegen, weil genau das der eigentlich Denkansatz des WWW ist. Und Browser sich weiterentwickeln. Und morgen die Kräfteverhältnisse schon wieder völlig andere sein können).
Gott sei Dank sind Browserweichen heute verpönt (selbst Microsoft rief irgendwann auf seinen Entwicklerseiten dazu auf, diese weit verbreitet gewesene Unkultur endlich sein zu lassen und es richtig zu machen und eben keinen Browser vorsätzlich auszusperren und stattdessen lieber standardsorientiert zu arbeiten) und obsolet. Zumindest bei Webseiten, deren Ersteller das WWW und dessen Funktionsweise und Brot- und Butter-Sprachen verstanden haben und die ihr Handwerk beherrschen.

Aber das nur nebenbei. Back to topic.
0
sierkb27.07.1400:24
Nachtrag: aus diesen historischen Gründen hat übrigens die in Safari, Google Chrome und auch inzwischen in Opera eingesetzte WebKit Rendering Engine in ihrem Browser-Erkennungsstring immer noch die Bestandteile "Mozilla/5.0" und "KHTML, like Gecko" drinstehen. Dass diese Strings Einzug erhalten haben bzw. immer noch nicht inzwischen nach so vielen Jahren getilgt sind in deren Browser-Erkennungsstring rührt aus dieser Vergangenheit und um solchen potentiell aussperrenden Browserweichen ein Schnippchen zu schlagen und denen ein paar Wörter an die Hand zu geben, die sie vielleicht kennen, sollten die betreffenden Webseiten und Weichen uralt sein und über Jahre nicht aktualisiert.

/Ende Exkurs
0
jeti
jeti27.07.1409:28
sierkb
OT:

Ausgeben konnte ist gut. Er musste es. Leider. Notgedrungen. Weil er sonst von Browserweichen, die eben aufgrund des begrenzten Vorstellungsvermögens und korrekten Verständnisses mancher Seitenbetreiber, wie man gewisse Dinge browserneutral für alle Browser tätigt, leider nur IE-Browser und Netscape-Browser kennen wollten, gnadenlos nicht erkannt worden und von zahlreichen Webinhalten ausgesperrt gewesen wäre. Also musste er (bzw. initiiert durch den betreffenden Nutzer), wenn es nicht anders ging, notgedrungen seine wahre Identität verleugnen und sich maskieren und als jemand anderes ausgeben als er tatsächlich war und konnte leider nicht sagen: "Ich bin ein iCab-Browser". Sondern musste schummeln und nach außen hin sich als Internet Explorer oder Netscape Browser ausgeben. Um von Browserweichen erkannt und durchgelassen zu werden. Ging dem Opera-Browser damals leider ganz genauso, den wollte so manche Browserweiche und Webseite auch nicht kennen, der hatte deshalb auch diese Möglichkeit, sich als ein anderer Browser auszugeben. Obwohl technisch dazu in der Lage, die betreffenden Webinhalte anzuzeigen.

Und genau dieses ist der Grund das ich damals mit iCab
als "getarnter" Netscape unterwegs war.
0
MacRudi27.07.1409:42
Es ist ja nicht so, dass die Seitenbetreiber zu blöde waren, sondern die Browser-Hersteller waren sich ja nicht wohlgesonnen. Also war man gezwungen, wenn man für alle Browser etwas Nettes machen wollte, eine Weiche einzubauen. Und weil die Seitenbetreiber und Programmierer davon irgendwann die Faxen dicke hatten, hat man den ACID-Test eingeführt, um mal die Problematik bei denen anzusiedeln, die dafür verantwortlich sind: bei den Browserherstellern. Damit meine ich natürlich nicht iCab. Hut ab vor ihm!

Und jetzt ist man in der komfortablen Situation, dass man eine Seite für alle macht. Und wenn ein Browser damit Probleme hat, dann sind es eben seine.

Das, um die Geschichte zu Ende zu erzählen bis zum heutigen Stand. Wenn in CSS Formate noch nicht einen abgesegneten Standard haben, werden sie mit -webkit- oder -moz- davor als experimentell gekennzeichnet. Und so kommt man damit auch gut klar.
0
sierkb27.07.1410:28
jeti
Und genau dieses ist der Grund das ich damals mit iCab
als "getarnter" Netscape unterwegs war.

Ich weiß. Deshalb habe ich das ja geschrieben. Du bist da ja nicht der Einzige mit dem Problem gewesen, ich kenne die Gründe und Diskussionen, warum die kleineren Browser-Hersteller das so gemacht haben, ja machen mussten und nicht anders, ich habe die betreffenden Diskussionen und Entscheidungen der betreffenden Hersteller damals wie heute aktiv mitverfolgt.

Und heute passiert leider wieder Ähnliches. Diesmal bezogen auf CSS-Präfixes. Weil viele Inhalte-Erssteller da draußen anscheinend nur WebKit-Browser kennen wollen, erstellen sie ihre Webseiten nur mit WebKit-spezifischen CSS-Präfixen, vergessen dabei aber gerne bzw. sind zu faul, dass es Äquivalente auch für andere Browser gibt und größtenteils sogar generische, präfix-lose CSS-Schreibweisen, die, wenn sie im betreffenden Browser umgesetzt sind, für alle Browser gelten. Und weil das so ist und viele Nicht-WebKit-Browser aus diesem Grund von einigen Webangeboten ausgeschlossen werden, obwohl sie technisch wunderbar in der Lage sind, die betreffenden Inhalte anzuzeigen, haben sich vor einiger Zeit im Rahmen der W3C HTML-Arbeitsgruppe und CSS-Arbeitsgruppe die Browser-Hersteller unter Führung Mozillas zusammengesetzt und beratschlagt, wie man dieser Fehlentwicklung Herr werden kann. Und es blieb nichts anderes übrig, als das Kind in den Brunnen gefallen zu betrachten und Folgendes zu machen:

WebKit-Aliase einzuführen. In Firefox. In Opera (der zu der Zeit noch nicht WebKit/Blink-basiert war). WebKit-Aliase, die, wenn angesprochen, auf die betreffenden browsereigenen bzw. generisch existierenden CSS-Funktionen zu verweisen. Um auf WebKit-zentrischen Webseiten wieder zum Zuge kommen zu können und nicht ausgeschlossen zu sein. Und gleichzeitig Druck auf Apple bzw. auf das WebKit-Team ausüben, ihre ganzen Präfixe doch endlich mal in die generische Schreibweise zu überführen bzw. mitzuhelfen, die Webseiten-Ersteller anzuweisen und drum zu bitten, es doch bitte korrekt und richtig zu machen und Präfixe vor allem im öffentlichen WWW doch möglichst nicht einzusetzen zugunsten der generischen Schreibweise.

Auch das übrigens ein Grund, warum Google WebKit geforkt hat und Opera deswegen "Hurra" geschrien hat und sogleich auf den neuen Fork umgestiegen ist (Jahre zuvor haben sie Google zu diesem Schritt öffentlich angebettelt, WebKit doch endlich Apples Oberhand zu entwinden und zu forken – zugunsten eines besseren WebKits: Opera Blog (06.05.2010): Dear Google: Please fork WebKit ). Google baut in Blink, im Gegensatz zu Apple in WebKit, so nach und nach diese CSS-Präfixe alle ab (die nie für was anderes gedacht waren und sind als für eine befristete Zeit zum Testen) und überführt sie in die browserneutrale generische Schreibweise, wenn sie stabil implementiert sind. So soll es sein, so macht es Mozilla seit Jahren, so ist es seit Jahren in der CSS-Spezifikation angeraten. CSS-Präfixe sind in der Spezifikation vorgesehen. Als Zugeständnis an die Browser-Hersteller. Als zeitlich befristete Möglichkeit, CSS-Features zu testen. Aufgrund der Gefahren, die sich hier leider auch nur allzu deutlich bewahrheitet haben, sind sie jedoch auch seit Jahren höchst umstritten. Und es gibt nicht wenige Forderungen innerhalb der Mitglieder der W3C Arbeitsgruppen, CSS-Präfixe doch endlich abzuschaffen zugunsten eben der generischen Schreibweisen (wenn also ein CSS-Feature implementiert, dann doch bitte gleich richtig und ohne CSS-Präfix), um das Missbrauchs-Potential und solche fatalen Fehlentwicklungen gar nicht erst möglich zu machen.
0
sierkb27.07.1410:57
MacRudi
Wenn in CSS Formate noch nicht einen abgesegneten Standard haben

Wann es letztlich ein Standard ist, hängt u.a. ganz entscheidend davon ab, wie weit die Browser-Hersteller in der Umsetzung sind bzw. selbst wenn sie es umgesetzt haben, ob sie ihre Hausaufgaben der betreffenden W3C CSS-Arbeitsgruppe gegenüber gemacht haben. Es hängt z.B. ganz entscheidend davon ab, wie weit die mit ihren eingereichten Test-Suiten und Resultaten sind, die sie beordert sind, bei der W3C CSS-Arbeitsgruppe einzureichen. Vorbildhaft gerade auf diesem Gebiet (man mag es kaum glauben): Microsoft. Nicht so dolle diesbzgl. (leider und ausgerechnet): Apple.
Diese lästige Kärrner- und Fleißarbeit des Schreibens von Test-Suiten macht niemand gerne. Aber sie ist gefordert, fester Bestandteil des Standardisierungsprozesses des W3C und notwendig. Ohne die kein formales Fortkommen einer Spezifikation.

Existiert hier Stau (in der Kommunikation und im Abliefern von Rückmeldungen) bzw. fehlen hier Ergebnisse der Browser-Hersteller, kommt eine Spezifikation auf der formalen Leiter leider nicht weiter, da kann sie im Grunde fix und fertig spezifiziert sein und der Text schon lange stehen und in Punkt und Komma fertig sein, und alle Browser-Hersteller sind in der tatsächlichen Umsetzung im Browser so weit. Solange z.B. geforderte Test-Suiten nicht eingegangen sind und die Browser-Hersteller hier lieber ihr eigenes Süppchen kochen statt ihre Hausaufgaben zu machen und zur Arbeitsgruppe zurückzuliefern, tritt ein Standard formal auf der Stelle. Das hört sich nach Bürokratie an, ist es irgendwo auch, aber so sind nun mal die (wohldurchdachten) Regeln.
Wie weit eine Spezifikation ist, welchen formalen Status sie hat, hängt also eher weniger mit ihrem Inhalt zusammen. Sondern ob der formale Ablauf des Spezifikationsprozesse, den eine Spezifikation zu durchlaufen hat, reibungs- und verzögerungsglos verläuft oder nicht und ob alle Beteiligten auf dieser Ebene ihre Hausaufgaben gemacht haben oder nicht.

In wenigen Tagen/Wochen wird die HTML5-Spezifikation übrigens ihren jetzigen Status "Working Draft" bzw. "Last Call Working Draft" formal ändern in "Candidate Recommendation". Sollte eigentlich schon letztes Jahr im Sommer geschehen sein. Die Verzögerung, warum jetzt erst, liegt u.a. in genau dem begründet, was ich grad' angesprochen habe: entsprechende Test-Suites und Rückmeldungen der einzelnen Browser-Hersteller (die am Entstehungsprozess des Spezifikationstextes ja beteiligt sind und eine entscheidende Rolle spielen).
Gleichzeitig werdfen auch noch ein paar weitere Spezifikationen formal in ihrem Status angehoben auf eine nächsthöhere Stufe.
, werden sie mit -webkit- oder -moz- davor als experimentell gekennzeichnet. Und so kommt man damit auch gut klar.

Siehe zuvor Gesagtes. Zudem: wenn bestimmte CSS-Präfixe noch nicht überall in den Browsern gleichermaßen implementiert sind, dann gelten sie solange im Grunde als experimentell und inoffiziell, und dann verwendet man sie gefälligst entweder noch nicht auf öffentlichen Seiten, oder, wenn man sie schon verwendet, dann verwendet man halt auch gleichzeitig die zugehörigen vorhandenen Präfixe der anderen Browser-Hersteller gleich mit (ist nur eine weitere kleine Zeile mehr im CSS-Code) bzw. schreibt dann noch gleich die präfixlose, generische Schreibweise als Fallback bzw. eigentlich korrekte Schreibweise dazu. Das geht. Und ist an Mehrarbeit eigentlich nicht der Rede wert. Sondern sollte selbstverständlich sein. So ist es auch angeraten und auch vom W3C einschlägig empfohlen, und das wäre dann auch saubere Arbeit.

Aber wir sind mal wieder OT.
0
sierkb27.07.1412:18
Es ist ja nicht so, dass die Seitenbetreiber zu blöde waren

Zum nicht ganz unbeträchtlichen Teil: leider doch.
Und weil die Seitenbetreiber und Programmierer davon irgendwann die Faxen dicke hatten, hat man den ACID-Test eingeführt also, um mal die Problematik bei denen anzusiedeln, die dafür verantwortlich sind: bei den Browserherstellern.

Nicht "die". Sondern wohlgemerkt nur jene, die wussten, wie herum der Hase zu laufen hat, und von welcher Seite aus (Handlungs-)Druck aufzubauen ist. Vielen Seitenerstellern war das bis dahin egal, sie wussten es nicht besser, wollten es auch lange Zeit danach nicht beser wissen. Das war ein hartes Stück Überzeugungsarbeit dieser aus engagierten Webstandards-Verfechtern gegründeten Gruppe The Web Standards Project (WaSP ) – auch und gerade ihren eigenen, teilweise beratungsresistenten weniger wissenden und wissenwollenden "Kollegen" gegenüber – aus deren Dunstkreis dann die ACID-Tests entwickelt wurden. Zuerst vor allem, um einem ganz bestimmten Browser-Hersteller Dampf unterm Hintern zu machen bzw. die Unfähigkeit von dessen Browser schön für alle sichtbar offenzulegen: Microsoft Internet Explorer. Ganz schnell hat man beim WaSP dann aber erkannt, dass sich der erste ACID-Test und vor allem der dann folgende zweite eigentlich auch ganz gut anwenden ließ auf alle anderen Browser-Hersteller, um diese auf Herz und Nieren zu prüfen und zu schließende Schwachstellen in puncto Unterstützung wesentlicher und oft nachgefragter Webstandards-Eigenschaften aufzudecken.

Der 3. ACID-Test, bei dem es dann das berühmte Kopf-anKopf-Rennen zwischen WebKit und Opera gab (was leider nicht ganz ohne Tricksereien seitens der WebKit-Leute vonstattenging, um "Erster" schreien zu können; wobei nebenbei anzumerken ist: Operas CTO, Håkon Wium Lie = "Erfinder" von CSS und für Opera ist CSS deswegen schon immer eine vorrangige und heilige Aufgabe gewesen, da nicht zu patzen), war dann im Grunde nur noch eine logische Folge. Federführung bei dem allen und treibende Kraft damals: Ian Hickson. Der initiierte und schrieb diese ACID-Test maßgeblich. Damals war er bei Mozilla tätig, dann wechselte er zu Opera, und schließlich dann zu Google (wo er noch heute tätig ist). Er ist auch der erste und langjährige Editor und treibende Kraft gewesen in Bezug auf die HTML5-Spezifikation bzw. die WHATWG und deren, bereits lange Jahre zuvor erarbeitete alternative Spezifikation, die dann 2007 die Grundlage für die HLTML5-Spezifikation gebildet hat, und er ist es auch gewesen, der beide Spezifikationen parallel gepflegt und harmonisiert/gesynct hat. Diesen Job hat er lange Jahre ganz alleine gemacht, mittlerweile hat ihn die Deutsche und Mozilla nahestehende Silvia Pfeiffer, die sich ihre Meriten vor allem im Webaudio- und WebRTC-Bereich erworben hat durch ihre umfangreiche Vor- und Zu- und Forschungsarbeit, abgelöst, die dafür um sich herum ein kleines Editor-Team gebildet hat, um diese umfangreiche Aufgabe zu schultern.
0
MacRudi27.07.1412:28
Bei den Webseitenbetreibern muss man unterscheiden zwischen vielen. Da gibt es HTML-Generatoren, die sich Mühe gegeben haben, um ihren Kaufpreis zu rechtfertigen, Code zu generieren, der in jedem Browser gleichermaßen aussieht. Das war zu Zeiten der verschiedenen Box-Modelle schon eine Menge Aufwand und Code, der da in einer Seite war.

Das ist für mich aber kein Webseitenbetreiber, der sich mit der Materie auskennt und maßgeblich ist. Da wurde Know-how mit dem HTML-Generator eingekauft.

Ich meine die, die um ihren Code wussten, und denen hats gestunken. Wie zum Beispiel mir.
0
Hot Mac
Hot Mac27.07.1413:39
Ist Euch schon mal aufgefallen, daß es seit HTML 5 kaum noch valide Seiten gibt?

Früher haben die Leute nocht wert darauf gelegt, daß Ihre Seiten in sämtlichen Browsern betrachtet werden konnten.
Heute ist es doch eigentlich umso wichtiger, oder nicht?

Ich verstehe es nicht ...
0
sierkb27.07.1413:47
MacRudi
Bei den Webseitenbetreibern muss man unterscheiden zwischen vielen.

Das habe ich bereits ausgedrückt, Du nun mit Deinen Worten nochmal.
MacRudi
HTML-Generator

So gut wie kein HTML-Generator kann guten handgeschriebenen, optimierten Code ersetzen. Konnte früher erst recht nicht. Und kann, obwohl sich da inzwischen wirklich bemerkenswert und lobenswert Gutes an Verbesserungen bzgl. der Code-Ergebnisse abgespielt hat, heute immer noch nicht wirklich.
MacRudi
Ich meine die, die um ihren Code wussten, und denen hats gestunken. Wie zum Beispiel mir.

Mir auch. Und das war bei mir damals, 1999, der Wendepunkt. Weil ich gemerkt habe: irgendwas läuft da grandios schief. Im Denken, und in der Umsetzung. Und muss korrigiert werden. Vor allen von denen, die's umsetzen müssen. Seitdem werbe ich für Webstandards, fürs Einhalten derselben, bewege ich mich im Dunstkreis des W3Cs, bringe mich da ein, habe an deren Werkzeugen mitgearbeitet (z.B. dem W3C Markup Validator), helfe mit, diese bekannt zu machen und zu verbreiten (z.B. auch in Bezug auf die lokale Installation desselben), biete diesbzgl. selber ein Werkzeug für Admins und Seitenersteller an, bin Mitglied geworden in der W3C HTML Arbeitsgruppe, habe im Rahmen dessen meinen bescheidenen kleinen Beitrag zur HTML5-Spezifikation geleistet.
Also Flucht nach vorne angetreten statt nur passiv zu sein. Mitgemacht, mitdiskutiert, mitgestaltet, es in der Umsetzung aktiv (vor-)gelebt. Bis zum heutigen Tage.
0
sierkb27.07.1414:02
Hot Mac
Ist Euch schon mal aufgefallen, daß es seit HTML 5 kaum noch valide Seiten gibt?

Ich habe eher den Eindruck: das Gegenteil ist der Fall. Beispiel?
Zudem: wogegen genau geprüft?
Du weißt, dass HTML5 diesbzgl. dem Schreiber mehr Freiheiten zugesteht als es HTML4, XHTML 1.0 oder gar XHTML 1.1 je getan haben? Und dass die HTML5-Parser in den Browsern diesbzgl. nicht laxer, sondern strenger geworden sind, vor allem auch daher, weil sie zum allerersten Mal für alle Hersteller verbindlich ganz genaue Handlungsanweisungen durch eine genau spezifizierte API als Teil der HTML5-Spezifikation an die Hand bekommen haben, die sicherstellt, dass alle Browser diesbzgl. das Gleiche interpretieren und darstellen können? Ein Novum gegenüber früher, schon allein deshalb ist ein Umstieg auf HTML5 angeraten, um von genau diesen Vorteilen, die in den Parsern der Browser verbaut sind, profitieren zu können: alle verstehen es gleich, keiner schert mehr aus und interpretiert es anders – weil's in der Spezifikation ganz genau steht, wie es zu interpretieren ist und wie ein Parser zu handeln hat.
Früher haben die Leute nocht wert darauf gelegt, daß Ihre Seiten in sämtlichen Browsern betrachtet werden konnten.

Wer sind "die", wer sind "die Leute"? Die Wenigsten der früheren Webseitenersteller haben das getan, und die Meisten haben lieber um Fehler und Probleme und Seiteneffekte herumgearbeitet, die nicht selten durch ihr eigenes Verschulden überhaupt erst zustandekamen, eben weil sie nicht standardkonform, nicht valide dachten und arbeiteten. Nur die, die um die Sinnhaftigkeit, die Notwendigkeit und die Vorteile von Validität wussten, die haben es schon seit langem so gemacht. Und wurden lange Zeit müde belächelt als Spinner und Theoretiker. Leider. Heute ist man da im allgemeinen Denken und Handeln Gott sei Dank etwas weiter, und die meisten haben aus den Fehlern und Irrwegen, die man lange Jahre mitgegangen ist, gelernt.


Aber wir werden hier imemr mehr Off-Topic. Ich schlage vor, es hiermit auf sich beruhen zu lassen und den Thread wieder fürs eigentliche Thread-Thema freizugeben. Es sei denn, der Offiz, das Thread-Thema, hat sich inzwischen erledigt und kann für beendet erklärt werden, und wir können getrost nun ins "Bierdorf", in die Fidulität übergehen.
0
Hot Mac
Hot Mac27.07.1414:18
sierkb

Ich bin Dir wirklich sehr dankbar, daß Du nicht müde wirst, uns an Deinem Wissen teilhaben zu lassen.
Das meine ich wirklich ehrlich!

Ich hab zwar manchmal keinen Schimmer, aber ich bemühe mich, Dich zu verstehen.

Negative Beispiele in Sachen HTML 5 habe ich jetzt gerade nicht zur Hand, positive aber auch nicht.
Wenn Du manche Seiten durch den Validator schickst – ist das nicht immer noch die Referenz? –, besteht kaum eine Seite den Test ohne Fehler.

Vielleicht reden wir auch aneinander vorbei.
Wie auch immer: zurück zum Thema!
0
sierkb27.07.1415:25
Hot Mac:

Danke für die Blumen.
Tut zur Abwechslung auch mal ganz gut – sonst werde ich hier ja überwiegend nur von der Seite angemacht, niedergeschrien, und mir wird nachgerufen, ich solle doch nach Hause gehen.
Wenn Du manche Seiten durch den Validator schickst – ist das nicht immer noch die Referenz?

Die Validatoren des W3C , also der W3C HTML Markup Validator (welcher für die Prüfung von HTML5-Dokumenten auf den Parser/Validator von Validator.nu zurückgreift bzw. diesen einbindet), der W3C CSS Validator , der W3C mobileOK Checker sowie der W3C Feed Validator bzw. alles zusammen unter einem Dach: Unicorn sind Referenz, korrekt.
besteht kaum eine Seite den Test ohne Fehler.

Ohne konkrete Beispiele nutzt uns diese Aussage nichts und ist erstmal nur eine leere, unbewiesene Behauptung.

Zumal unterschieden werden muss zwischen Fehler und Warnung. Warnung ungleich Fehler. Viele, die diesbzgl. prüfen lassen, kennen leider den Unterschied nicht und denken bei Warnungen gleich an Fehler bzw. ordnen es dann fälschlicherweise so ein. Kenntlich gemachte Fehler sind echte Fehler, teilweise grobe Fehler. Die ein Dokument invalide machen und die dazu führen können, dass ein Benutzeragent (z.B. ein Web-Browser) ein Dokument nicht korrekt darstellen kann bzw. anfangen muss zu raten (dessen Fehlerkorrektur also anspringen muss, und die kann nur eine grobe Korrektur sein und ist als unzuverlässig und potentiell fehlerhaft anzusehen). Zudem werden in dem Fall Dokumente dann langsamer vom Browser geparst und somit dargestellt. Es sollte also auch daher schon vom Ansatz her vermieden werden, diese zu triggern, weshalb es anempfohlen ist, valide zu schreiben bzw. HTML strict bei HTML 4,, XHTML 1.0 zu schreiben (XHTML 1.1 und HTML 5 bzw. XHTML 5 sind per definitionem immer strict, die kennen kein transitional, keine in der Spezifikation missbilligten Elemente mehr). Weil die Darstellung durch die etwaige Fehlerkorrektur und Raten des Browsers verlangsamt wird. Zwar minimal und kaum auffällig und bei heutiger Rechnerleistung fast nicht der Rede wert, aber immerhin. Denn Kleinvieh macht auch Mist bzw. kann sich summieren zu Spürbarem.

Warnungen hingegen sind nicht entscheidend für die Validität eines Dokuments und sollten zwar ebenfalls ausgeräumt werden im Sinne anderer auch zu beachtender Regeln und Empfehlungen (z.B. im Sinne von Barrierefreiheit, was wiederum in der Folge bedeutet: ), können aber auch mal geflissentlich irgnoriert werden, da eben nicht entscheidend für die Darstellungsfähigkeit im Web-Browser.

Deshalb sind Fehler rot, Warnungen gelb und wenn weder das Eine noch das Andere zutreffend und komplett alles OK, dann schlicht ein grünes OK für die Meldungen der Validatoren vereinbart und auch so erklärt.


Back to topic.
0
Hot Mac
Hot Mac27.07.1415:54
sierkb
Deshalb sind Fehler rot, Warnungen gelb und wenn weder das Eine noch das Andere zutreffend und komplett alles OK, dann schlicht ein grünes OK für die Meldungen der Validatoren vereinbart und auch so erklärt.

Das ist mir bekannt!
Würdest Du eine Seite auf den Server laden, die kein „grünes Gütesiegel" erhalten hat?
Ich nicht, obzwar es nicht mein Job ist!
0
sierkb27.07.1416:57
Hot Mac
Würdest Du eine Seite auf den Server laden, die kein „grünes Gütesiegel" erhalten hat?
Ich nicht, obzwar es nicht mein Job ist!

Möglichst nein. Mit Fehlermeldungen schon mal gar nicht. Und manchmal wissentlich der einen oder anderen Warnung trotzdem. Wenn ich ganz genau weiß, was für eine Warnung das ist und wie und warum sie zustandekommt. Weil zum Beispiel der CSS-Validator da manchmal strenger ist als der Papst. Bei vendorspezifischen CSS-Präfixen zum Beispiel. Die gibt er stur als Warnungen aus. Weil eben bei strenger Auslegung der Spezifikation nicht in der CSS-Spezifikation stehend, sondern da steht nur drin, dass es welche geben kann und wenn ja, wie die Präfixe zu setzen sind. Und da herstellerspezifische CSS-Präfixe eigentlich per definitionem immer experimentell sind, haben sie auch in einer allgemeingültigen Spezifikation nichts zu suchen. Erst recht nicht vor dem Hintergrund, dass alle Nas' lang von den Browser-Herstellern neue hinzukommen bzw. neue Teil-Spezifikationen eingereicht werden und das ganze Thema somit stets im Fluss ist.

Erst, wenn auch andere Browser-Hersteller diese CSS-Eigenschaften von einem anderen Browser-Hersteller übernommen haben bzw. von dessen eingereichtem Vorschlag, erst dann wird's in die offizielle allgemeingültige Spezifikation übernommen. Vielleicht. Nicht alle. Es gibt herstellerspezifische CSS-Erweiterungen, denen wird der Einzug in die allgemeingültige Spezifikation verweigert, weil deren Wert und Nutzen für die Allgemeinheit entweder nicht vorhanden oder gar kontraproduktiv ist (dem Ganzen geht ein Arbeitsgruppen-interner Diskussionsvorgang voraus, wo alle Beteiligten, auch derjenige, der's eingebracht hat, an einem Tisch sitzen zusammen mit zahlreichen anderen Vertretern und auch Webentwicklern). Und erst dann, und das ist jetzt der entscheidene Punkt – erst dann, wenn's für alle gleichermaßen Präfix-los in der allgemeingültigen CSS-Spezifikation steht, erst dann richtet auch der CSS Validator sich danach und beugt sich dem. Bevor das nicht geschehen ist, sagt er ganz streng: "Kenne ich nicht. Steht so nicht in der Spezifikation. Also: (gelbe) Warnung".

Es existieren seit Jahren Meinungsverschiedenheiten um genau diesen Punkt – ob der CSS-Validator nun diesbzgl. "devil's advocate" sein soll und päpstlicher als der Papst, oder ob er herstellerspezifische Präfixe, die noch nicht in der offiziellen CSS-Spezifikation präfixlos Einzug erhalten haben nicht doch stillschweigend und tolerant akzeptieren soll (was eigentlich gegen Wort und Geist der Spezifikation wäre), um Verwirrung zu vermeiden. Entschieden ist dieser Kampf, so ich das bisher mitbekommen habe, noch nicht gänzlich, aber die Fronten haben sich wohl einander angenähert.

Ein großer Befürworter, hier die Schranken aufzuheben und den CSS-Validator bzgl. herstellerspezifischer Präfixe toleranter zu machen und diese nicht mehr, noch nicht mal per Warnung, anzumängeln, das ist mein geschätzter Kollege Jens Meiert. Er wie andere Größen des Genres plädieren seit Jahren dafür:

Jens Meiert Blog (26.06.2010): CSS Validation and Vendor Extensions: Throw Warnings, Not Errors

Jens Meiert Blog (25.01.2011): CSS Validation Will Soon Be More Realistic

Unter anderem ihm und seinem unermüdlichen Werben dafür ist die Fehlerbehandlung des CSS Validator inzwischen dahingegend abgeändert/abgemildert worden, dass sie bei herstellerspezifischen CSS-Präfixen nicht mehr wie lange Jahre zuvor einen roten Fehler auswirft. Sondern eben nur noch eine gelbe Warnung.
Ein hart errungener Kompromiss zwischen "devil's advocate" und Benutzerfreundlichkeit. Der zwar einige immer noch nicht zufriedenstellt, der aber, finde ich, ein zufriedenstellener Kompromiss ist und kein fauler.

Wenn ich also genau weiß, dass allein das Vorhandensein herstellerspezifischer CSS-Präfixe in meinem CSS vorhanden sind, ich aber gleichzeitig alle Hersteller diesbzgl. berücksichtigt habe inklusive der präfixlosen, spezifikationskonformen Notation, dann kann ich gut damit leben, dass der CSS-Validator mir da an solcher Stelle diesbzgl. eine gelbe Warnung ausspricht. Denn ich weiß, woher die kommt, ich weiß den Grund, und ich habe ja trotzdem alle Hersteller berücksichtigt und auch die spezifikationskonforme Schreibweise nicht vergessen. Sodass sich dann jeder Browser das rauspicken kann, was er beherrscht. Und wenn er die spezifikationsgemäße, Präfix-lose Notation beherrscht und diesbzgl. kein Vendor-Präfix mehr benötigt bzw. dieses in vom Hersteller zugunsten der Präfix-losen Schreibweise deaktiviert worden ist, dann umso besser.

Beispiel in Bezug auf automatisch gesetzte Trennungsstriche in Abhängigkeit der verwendeten Landessprache des Inhalts:

-webkit-hyphens: auto;
-moz-hyphens: auto;
-ms-hyphens: auto;
-o-hyphens: auto;
hyphens: auto;

Wirft im CSS-Validator Warnmeldungen (früher: Fehlermeldungen) aus in Bezug auf die herstellerspezifischen Präfix-Schreibweisen. Einzig korrekt und browserneutral im Sinne der für alle gleichermaßen geltenden Spezifikation allein die letzte Notation ohne Präfix. Alle anderen Schreibweisen sind von der Spezifikation nicht gedeckt, kennt der CSS-Validator nicht, hat sie auch nicht zu kennen, da nicht offiziell. Wenn ich im CSS-Validator ein grünes OK haben will, verzichte ich auf die herstellerspezifischen Schreibweisen, benutze nur und ausschließlich die in der Spezifikation definierte. Hat den Nachteil, dass ich nur den oder die Browser ansprechen kann, die eben nicht nur die dahinterstehende Funktionalität sondern insbesondere diese spezifikationskonforme präfixlose Notation implementiert haben und alle diejenigen nicht, die zwar die Funktionalität implementiert haben, diese aber erstmal noch nur über ein entsprechendes Präfix ansprechbar gemacht haben.

Auch deshalb seit Jahren der Ruf Einiger (und ich schließe mich dem eigentlich an), diesen Murx sein zu lassen und gleich die offiziell korrekte Notation zu implementieren, sobald die dahinterstehende Funktion implementiert ist. Ohne den zeitverzögerten Umweg über herstellerspezifische Präfixe. Und um damit diesen ganzen Problemen und Seiteneffekten und sich wie ein Rattenschwanz nachziehenden Seiteneffekten und dem Wartungsaufwand bei allen Beteiligten, der sich daraus ergibt, komplett aus dem Wege zu gehen.

Leider spielen da aber einige Browser-Hersteller nicht mit und wollen unbedingt die Möglichkeit haben, ihrerseits vendorspezifische Präfixe zu setzen, wann sie wollen. Das kann man ihnen gerne zugestehen. Doch: wie sicherstellen, dass die niemals in öffentlich zugängliche Webdokumente gelangen, die auch mit anderen Web-Browsern zugänglich sein müssen und nicht nur mit diesem einen Browser dieses einen Herstellers? Wie hält man Inhalte-Ersteller davon ab, das zu tun, wie bringt man ihnen das bei? Ist so gut wie unmöglich. Was daraus entstanden ist bisher, habe ich obig bereits skizziert in Bezug auf viele WebKit-only-Webseiten, die inzwischen das Web geflutet haben. WebKit-only, weil die nur so wimmeln von reinen -webkit-Präfixen in deren CSS und nirgendwo Rücksicht drauf genommen worden ist, dass es auch noch andere Web-Browser gibt, die diese Inhalte ganz genauso darstellen können und auch dürfen und auch dürfen sollen.

Auch deshalb ist der CSS-Validator "devil's advocate". Um sowas nicht noch zu unterstützen und offiziell salonfähig zu machen, vorbei an der Spezifikation und vorbei an Geist und Inhalt des World Wide Web und dessen Brot-und-Buttter-Sprachen, das stets und unterschiedslos alle im Blickfeld hat und als Zielperson/Zielgruppe ansieht und nicht nur einige wenige.


Mann, sind wir nun aber Off-topic.
Hoffe, es ist trotzdem OK.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.