Tja, das wird wohl vorerst nichts mit 10.5.2 für den Endanwender, wenn Apple noch immer Probleme feststellt und/oder Änderungen vornimmt...

besser das die probleme jetzt festgestellt werden.

a_JAguar

genau, sonst quillt es hier wieder über, vor lauter Beschwerden Das braucht auch kein Mensch!

CooperCologne: Keine Sorge, die wird es auch diesmal geben, wie immer: Denn solche großen Apple-Updates decken halt traditionell verpfuschte und halbdefekte Systeme auf, von ruinierten Dateisystemen bis zu Hacks. Nix geht mehr, und Apple ist schuld - nie der Nerd vor der Maschine.

Egal.... eines kann man mit Sicherheit sagen... Apple wird 10.5.2 mit 99,9999... % Wahrscheinlichkeit vor dem Release von 10.5.3 herausbringen.

BlueFalcon:

mit dem hab ich mich auch beruhigt

Es ist erfreulich, dass Apple diesmal keine Schnellschüsse in die Welt setzt. Vielleicht wird Leopard 10.5.2 endlich das Betriebssystem, das Leopard 10.5.0 und 10.5.1 hätte werden sollen.

wow schon HTML 5-Elemente und ich dachte es wird noch Jahre dauern bis jemand mal damit anfängt . Auch der SQL-Zugriff via JavaScript tönt super!

Wird wohl auch für das iPhone kommen, denn dort ist das ganze am sinnvollsten damit man nicht immer verbunden sein muss und die privaten Daten lokal gespeichert werden...

Bis man das ganze wirklich einsetzen kann muss man sicher noch 3-5 Jahre warten bis Internet Explorer das ganze unterstützt :o.

Das Gemeine daran ist, je mehr darüber geschrieben wird, desto mehr will ich es auch mal ausprobieren dürfen, all diese Fehlerbeseitigungen...
Nicht das ich hier Grund zu klagen hätte, die meisten Dinge sind Kleinigkeiten für mich als Hobbycomputernutzer.
Also her damit, wenns Fertig ist
Raller

So lange TimeMachine endlich auch meine AirPort Festplatte erkennen wird bin ich zufrieden! TimeCapsule ist ja schön, aber ich habe all das schon lange mit einer AirPort Basis und großen USB Festplatten! Nur verwenden kann ich es nicht! (offiziell)

Ich frag mich gerade, ob Safari 3.1 noch für Tiger erscheinen wird!? An sich dürfte es ja nur ein Webkit-Update sein, also sollte das durchaus machbar sein.

Dass sie jetzt schon HTML5 implementieren, macht mir etwas Sorgen. HTML5 ist meines Wissens nach noch in einem sehr frühen Entwicklungsstadium. Im schlimmsten Fall gibts dann wieder einige unterschiedliche Implementierungen, die zu nicht Standard-konformen Darstellungen führen.
Aber grundsätzlich bin ich von HTML5 begeistert (im Großen und Ganzen), obwohl ich anfänglich gegen eine Weiterentwicklung von HTML war...

oh man ich will doch einfach nur dass safari endlich stabil läuft

weiss jemand wo ich mehr zu diesem Client SQL finde? Html5 ist ja noch nicht mal final, aber wie ich das verstehe geht es hier nur um Audio/Video embedding, oder? Klingt jedenfalls geil.. wird aber wohl nur in den Widgets zum Einsatz kommen, solange andere Browser nicht mitmachen.

kein Name

Auzug aus den MacTechNews-Nutzungsbedingungen:

Bitte schreib doch dem Verfasser eine Mail wenn du Typos findest, hier nerven solche Beiträge nur.

Danke.

Morpheus3k

Ich würde mich um die Standard-Konformität von Safari keine sorgen machen, Safari ist seit Jahren auf Platz 1 was das anbelangt. Schon Jahre bevor sogar Firefox den Acid II-Test, etc. bestanden hat. Je schneller es implementiert ist, desto schneller hat man ein "Proof-Of-Concept" und desto schneller wirds auch Standardisiert.

HTML5 ist anscheinend in Module aufgeteilt bei dem schon Features wie <video> und <audio> vor dem Rest standardisiert werden könnten...

Andere Browser werden im Offline SQL auch mitmachen, es kommt anscheinend definitiv auch in Firefox und dann fehlt wie immer noch IE.

ich bin gespannt wann endlich die finale Windows Version vom Safari 3.x kommen wird.

Unbd wo sind jetzt diue "manigfaltigen" Änderungen an Safari 3.1? Ich sehe nur zwei, für Endanwender eher unwichtige, Änderungen an Safari?!?

madox

Ich wollte dem Safari seine Standard-Konformität nicht unterschlagen. WebKit ist in diesem Bereich sicher weitfortgeschritten. Aber es gab schon sehr oft starke Änderungen in Entwürfen, wo Teile es nicht in den Standard geschafft haben. Es könnte Funktionen in der API geben, die vielleicht so garnicht in den Standard (eigentlich Recommendation) schaffen.
Aber natürlich kann es den Umkehrschluss geben: Wenn es im Safari implementiert ist, könnten die Anderen nach diesem Beispiel es ebenfalls implementieren...

Ich denke, der IE wird schon zu einem Standard-konformen Browser werden. Aber das Problem ist, dass es einfach noch zuviele alte IEs gibt und geben wird, weshalb sich das einfach alles hinziehen wird.

Wegen dem Offline-SQL: ich glaube, dass Mozilla/Google die teibende Kraft zur Standardisierung ist. Immerhin hatte Mozilla mit Firefox 3 schon seit über 2 Jahren einen Browser in der Entwicklung, der dies unterstützen wird.

Jedenfalls gilt: Nur durch hohe Verbreitung kommt es zum Einsatz. Wenn Apple dies fördern will (was sie ja tun, sonst hätten sie nicht unter anderem HTML5 vorgeschlagen), müssten sie es zumindest auch für Tiger-User zugänglich machen. (Windows wird ja bestimmt Safari 3.1 bekommen...)

Hoffe, dass 10.5.2 auch meine Probleme mit iTunes löst ...

@madox:

Ich auch nicht.


Das ist so, wie Du es sagst, eine Falschaussage.
Safari resp. WebKit ist aus KHTML (lange eingesetzt in KDEs Konqueror) hervorgegangen. Und zwar Jahre später gegenüber der Mozilla-Rendering-Engine. Der Umstand, dass nicht zuletzt Apple sich bei der Wahl seines Browsers für KHTML entschieden hat und nicht für die Mozilla Engine, hat bei Mozilla die zwar wohl angedachte aber noch nicht vollzogene baldige Umsetzung eines schlankeren Browsers bewirkt: Firefox. Mozilla war aber schon damals der KHTML Rendering Engine um einige Längen voraus, was die Einhaltung und vor allem die korrekte Interpretation von Webstandards geht, wozu ich auch JavaScript zähle. Genau auf diesem Feld, JavaScript, hatte KHTML schon immer besondere Schwächen, welche auch bei WebKit/Safari bis heute noch nicht völlig gelöst sind und an die Qualität von Firefox ranreichen. Safari hat in den letzten Jahren bzgl. Webstandards enorm aufgeholt, das ist wohl wahr, und ich sehe mit Genugtuung, dass Safari gerade in puncto CSS3 dem Firefox ganz gehörig Dampf und Handlungsdruck macht. In einigen Fällen, was so manche CSS3-Eigenschaft angeht, ist WebKit/Safari derzeit sogar führend gegenüber Firefox. Doch es sollte nicht vergessen werden, dass vieles von CSS3 leider noch "Draft"-Status hat, also ein Entwurf und eben nicht stabil und verlässlich spezifiziert ist. Firefox kann auch schon so Einiges aus CSS3 oder CSS3 Draft, ist da aber etwas konservativer und vorsichtiger in der Umsetzung, auch beim in wenigen Monaten erscheinenden FF3 wird so manche weitere CSS3-Eigenschaft Einzug erhalten haben. Aber eben nur jene, die als stabil spezifiziert betrachtet werden können. Apples WebKit-Team ist da etwas progressiver, was die Umsetzung angeht, die Frage wird aber sein, ob's am Ende gut war oder nicht, sich so schnell an CSS3-Eigenschaften ranzumachen, wenn diese dann doch noch irgendeiner Änderung unterworfen werden, bevor sie endgültig als stabil spezifiziert in einer Recommendation landen. Auch Opera ist da eher auf der etwas konservativeren Linie von Mozilla, und bei Opera kann man wohl ziemlich sicher sein, dass die Webstandards und CSS voll im Blick haben, denn schließlich ist deren Chief Techology Officer kein geringerer als CSS-Miterfinder und CSS-Co-Autor Håkon Wium Lie.

Was den ACID-Test angeht, da gebe ich Dir recht, da ist Firefox etwas langsam in der Umsetzung, erst FF3 wird diesen Test bestehen. Doch sei gesagt, dass dieser Test nur ein Test ist und ihm von manchem (vor allem den Medien) eine größere Relevanz beigemessen wird als es eigentlich angemessen wäre. Der Test testet nur einen *Ausschnitt* dessen, was es an Webstandards gibt. Mir fallen auf Anhieb gleich mehrere Felder ein, auf denen Firefox *ziemlich gut* darsteht, was die Umsetzung einer *breiten* Palette von Webstandards angeht, WebKit/Safari kann da noch nicht mithalten, obwohl er auf einem guten Weg ist.
Ich könnte Dir auch auf Anhieb die eine oder andere Webseite nennen, die Safari im Detail *nicht* korrekt darstellt, obwohl sie von allen anderen Browsern korrekt und erwartungsgemäß dargestellt wird und auch der HTML- und CSS-Code der betreffenden Seite selbst nach Überprüfung
als völlig korrekt eingestuft werden können.

Ist da irgendwas an mir vorbeigegangen, ohne dass ich es mitbekommen habe? Bei XHTML 1.1, XHTML Basic, XHTML Mobile, XHTML 2.0 und bei CSS3 trifft diese Aussage zu, bei HTML5 meines Wissens nicht. Dazu muss gesagt werden, dass mit Modularisierung vor allem die zugehörige jeweilige Spezifikation gemeint ist. Deshalb ist CSS3 eben in Gänze noch nicht fertig, weil einzelne Module davon bzw. die zugehörigen Spezifikationen dieser noch keinen "Recommendation"-Status haben, sondern erst maximal den "Draft"-Status.
Gleiches bzgl. des vor wenigen Tagen als "Draft" freigegebene HTML5. Bzgl. HTML5/XHTML5 kann und wird sich noch so viel ändern, fertig soll HTML5 laut Zeitplan im Jahre 2010 sein. Dass jetzt ein erster Draft existiert, mit dem man pressewirksam an die Öffentlichkeit gegangen ist, hat nur mit dem selbstgesteckten Zeitplan zu tun. Aber da kann und wird sich noch ziemlich viel drin ändern. Was einem ja auch augenfällig entgegenspringt, wenn man das Dokument liest. Da gibt es noch viele, viele Löcher, die gestopft werden müssen, vieles darin ist noch gar nicht spezifiziert oder nur vage umschrieben, viele Anmerkungen für Änderungen stehe drin.
Wenn WebKit jetzt also schon das eine oder andere HTML5-Element umsetzt, dann ist das sicher löblich und dem Enthusiasmus der betreffenden Safari-Entwickler geschuldet (oder auch der Marketing-Abteilung von Apple?), die in der HTML-Working Group mit drinsitzen (wie ich auch übrigens) und an HTML5 mitschreiben, mitdiskutieren und mitentwickeln. Die Frage am Schluss wird jedoch sein, was das bringen soll, wenn bestimmte andere Teile von HTML5 noch gar nicht als so stabil zu Ende spezifiziert sind. Mal abwarten, was die kommenden Opera (incl. Opera Weekly Build) Versionen davon bereits zum jetzigen Zeitpunkt so umsetzen, dort müsste es eigentlich noch viel höheren Enthusiasmus geben, möglichst schnell möglichst viel von HTML5 umzusetzen: Ian Hickson, der für Opera arbeitet (früher: Mozilla) und HTML5 als Editor und Motor in der W3C HTML WG vorantreibt (schon seit Jahren als Antreiber und Motor innerhalb der WAHTG, die in der W3C HTML WG aufgegangen ist). Aus Ians Feder stammt maßgeblich übrigens auch der ACID2-Test. Ein kommender ACID3-Test von ihm ist darüberhinaus schon in Vorbereitung (ist noch nicht fertig) und kann schon mal unter bzw. eingesehen und ausprobiert werden. In Zeiten von Web 2.0, Ajax und Co. testet er eine Menge mehr Dinge ab als bisher ACID2 (vor allem viel JavaScript und Dinge, die wichtig sein können für dynamische Webseiten).

Ich würde mir keine Sorgen machen wg. Safari 3.1 unter Tiger...es ist ja eine WebKIT-Änderung und die wird man sicher durchreichen. Man hat ja bei der Tiger-Version von Safari eh schon WebClip weggelassen und die alte GUI beibehalten um Gründe für Leo zu "schaffen" ^^

Prima - ich hatte Apple den Vorschlag gemacht, Audioinhalte auf Websites in Safari ausschalten bzw. leiser machen zu können. Da haben sie gleich mal weitergedacht und noch mehr implementiert. Super. Danke. Bin gespannt.

sierkb

Man merkt schon dass du den Text mit Safari geschrieben hast, ansonsten wäre das kleine Kommentarfeld etwas zu klein für so einen grossen Text. hihi..

Ich denke HTML5 ist keine grosse Sache für die Rendering-Engine und relativ einfach zu implementieren, da die gesamte Darstellung auf CSS ausgelagert werden möchte. CSS3 wäre dann schon die etwas komplexere Arbeit. Abgesehen von <audio> und <video> Tag gibts nur noch Tags wie <article>, etc. welche den Content eher beschreiben aber nicht wirklich Auswirkungen auf das Rendering haben.

@madox:

Falsch vermutet. Mein bevorzugter Standard-Browser unter MacOSX, Linux und Windows ist und bleibt seit Jahren ein Mozilla-Produkt, im Speziellen: Firefox.

Zu dem, was Du "Tags" nennst: es sind Elemente, welche in der Regel, aber nicht zwingendermaßen (es gibt ja auch sog. leere Elemente, wie z.B. ein <br/>) aus Anfangs- und Endtag bestehen.

Zur genauen Begriffsbestimmung und -definition sei Dir die kurze aber sehr gute Erklärung von Michael Jendryschik anempfohlen:


Ich finde es wichtig, dass diese Begriffe korrekt benannt und im Sprachgebrauch verwendet werden, weil sie immer regelmäßig zu Unklarheiten und Missverständnissen führen, wenn sie von den Menschen in Unkenntnis und mangelnder Fachkenntnis immer wieder und nach Belieben durcheinander gewürfelt werden. Deshalb stelle ich das hier richtig. So manche Unklarheit und Frage löst sich von selbst in Wohlgefallen auf, wenn klar ist, was HTML ist, was es sein soll, was es *nicht* ist oder sein soll, wie es aufgebaut ist und wie die Begriffe richtig heißen. Soviel Zeit und Korrektheit muss sein. Die muss man ja woanders auch aufbringen (Stichwort: korrekte Rechtschreibung), um von allen auf Anhieb verstanden zu werden.

Wie groß ist dieser Build eigentlich?

@sierkb
von wegen:
"Der Umstand, dass nicht zuletzt Apple sich bei der Wahl seines Browsers für KHTML entschieden hat und nicht für die Mozilla Engine, hat bei Mozilla die zwar wohl angedachte aber noch nicht vollzogene baldige Umsetzung eines schlankeren Browsers bewirkt: Firefox."

Nun, mit Firefox hat das nichts zu tun.
Gecko ist sehr verflochten mit den für die GUI zuständigen Techniken - also den Mozilla eigenen XUL u.s.w.
Das macht Gecko einerseits kompizierter - z.B. um neue Elemente einzuführen und ist sowieso "unsauberer"
Apple hat nicht zuletzt auf KHTML gesetzt, weil sie genau das nicht gebrauchen können. Und der andere Grund ist wohl Kontrolle. WebKit ist nun voll von propitären Kram, den sie für Dashboard, das iPhone u.s.w benutzen. Gecko mit propitären Kram wie XUL u.s.w. Die würden sich permanent in den Haaren liegen, wenn sie zusammen arbeiten müssten. Mal abgesehen von unterscheidlichen Deadlines für fertige Versionen.

Übrigens sind für Gecko 2.0 grundlegende Umbauarbeiten im Gange, also die Entflechtung von Gecko und den GUI Kram.

sierkb
Apple macht das richtig. Wieso? Siehe folgenden Artikel:



Diesbezüglich vor allem folgende Stelle:

wäre auch schon zufrieden, wenn Safari endlich stabil würde....

@RETRAX:

Eric Eggert schreibt eingangs, dass er "eher stilles" Mitglied der W3C HTML Working Group ist. Nun, ich bin es ebenso , doch bin ich schon länger in verschiedene Prozesse innerhalb des W3C involviert und an ihnen teilhabend (z.B. Validator Dev Team). Eric wirft da etwas durcheinander: das was er meint, ist die Definition eines Standards wie ihn das W3C versteht. Weil eben das W3C, historisch und kulturell begründet, keine expliziten Vorschreibungen macht, weshalb die Spezifikationen ja auch alle, wenn sie fertig sind, "Recommendation", also auf deutsch: Empfehlung, heißen. Bis dahin gibt es verschiedene Abstufungen nach unten, "Draft" ist eine davon. Niemand wird gezwungen, sich an eine solche Empfehlung zu halten, doch er tut gut daran, genau das zu tun, wenn er sich mit möglichst vielen Endgeräten und Benutzern verstehen will.
Das mal vorweg. Und das, was Eggert da beschreibt, ist das Wort "Standard", welches ja vielerorts unterschiedlich und teilweise abenteuerlich interpretiert wird (in Sachen Word, IE und Co. reden ja viele von "Quasi"-Standard, obwohl diese Dinge nie irgendeinem übergeordneten und unabhängigen Gremium vorgelegt worden sind, um diese Bezeichnung zu vergeben). Eine technische Spezifikation, die vom W3C mit der Bezeichnung "Recommendation" veröffentlicht wird, kann und sollte dann als Standard angesehen werden, wenn es mindestens zwei Implementationen von mindestens zwei relevanten bzw. großen Herstellern gibt. Dann darf diese Recommendation als "Standard" bezeichnet werden. Vorher nicht. Und von daher hat es für die Browser-Hersteller einen gewissen Sinn, frühzeitig mit der Umsetzung anzufangen, wenn ihnen daran gelegen ist, diese Technik zu unterstützen (und um genau das zu erreichen, gibt es die HTML WG in der jetzigen Ausprägung und Größe überhaupt -- es war allen Beteiligten enorm wichtig, dass möglichst Viele und vor allem *alle* namhaften und relevanten Browser-Hersteller mit im Boot sind und *aktiv* mitarbeiten, was glücklicherweise auch geschieht). Aber nur dann hat es Sinn, sehr früh mit der Umsetzung anzufangen, wenn bestimmte Teile in der Spezifikation eineindeutig und unverrückbar spezifiziert sind. Und genau da habe ich meine leisen Zweifel geäußert.

Ich habe ja nicht gesagt, dass Apple da einen Fehler macht, indem sie damit jetzt schon anfangen. Ich habe mich lediglich dahingehend geäußert, dass ich es evtl. noch ein wenig *zu* früh halte. Ich finde andere Baustellen in den Bereichen XHTML, CSS2.1, Teilen von CSS3 und JavaScript viel viel dringender -- auch und gerade bei Safari, weil sie sich viel direkter, nämlich schon heute auswirken. HTML5 ist im Moment noch akademischer Natur, es wird laut offiziellem Fahrplan erst im Jahre 2010 fertig spezifiziert sein. Doch die anderen Dinge sind schon längst, teilweise seit mehreren Jahren mehr oder weniger stabil spezifiziert. Erst sollten diese Dinge alle rund laufen, dann kann sich das Safari-Team meinetwegen daranmachen, HTML5 umzusetzen.

sierkb

herzlichen dank für die Ausführen.