Safari-ontwikkelaars treden toe tot html-werkgroep W3C

Door Olaf van Miltenburg, donderdag 22 maart 2007 18:08, 38 reacties • Feedback
Bron: Webkit.org, submitter: MacWolf

Apple heeft zitting genomen in de onlangs door W3C ingestelde html-werkgroep en krijgt daarmee invloed op wijzigingen van de html-specificatie. Het bedrijf wil vaker deelnemen aan W3C-werkgroepen en standaardiseringsorganisaties.

W3C logo Op hun weblog maken drie Safari-ontwikkelaars bekend Apple te vertegenwoordigen in de HTML Working Group. Enkele medewerkers van Apple, waaronder Safari-ontwikkelaar Dave Hyatt, zijn ook medeoprichter van de Whatwg-werkgroep, die is opgericht vanwege de trage ontwikkeling van de webstandaarden die worden overzien door de W3C. Eind oktober vorig jaar werd al bekendgemaakt dat de W3C een nieuwe werkgroep in het leven zou roepen voor de ontwikkeling van de html-specificatie. Begin deze maand nodigde het consortium geïnteresseerden uit zitting te nemen in de werkgroep, waarbij opvallend was dat iedereen zich kon inschrijven. De werkgroep wordt mede voorgezeten door Chris Wilson, platform architect bij het Internet Explorer-team van Microsoft. In tegenstelling tot de browsers van Mozilla, Opera en Apple, ondersteunt IE xhtml niet, waardoor de ontwikkeling van xhtml stokte en de noodzaak bestond de html-ontwikkeling nieuw leven in te blazen. De bestaande xhtml-werkgroep blijft daarnaast onverminderd werken aan XHTML 2.0.

De ontwikkelaars maakten ook bekend dat Apple zich meer gaat richten op deelname aan W3C-werkgroepen en andere instanties die zich bezighouden met de standaarden van het web. Dat het bedrijf invloed wil krijgen op de mobiele standaard, is niet geheel verbazend, aangezien de iPhone gebruik maakt van Safari als webbrowser.

Reacties (38)

+2 Gustaaf437
22 maart 2007 19:13

Het is niet alleen de ontwikkeling die ze willen voorrspoedigen. Een extra doel is ook zoveel mogelijk mensen aan de standaard-compliant websites te krijgen. Apple is de meest strikte partij op dat gebied.

Als iedereen zich aan de regels zou houden, dan zou het web kwa ontwikkeling 1 tot 2 jaar voorliggen.

Apple is zeer goed bezig op web-gebied en de WebKit render-engine is in zijn laatste nightly vormen dan ook andere render-engines inmiddels flink voorbijgestreefd. Als ik bijvoorbeeld kijk naar Gecko, gaat 1.9 er eerder op achteruit, dan op vooruit en dat is toch een slecht teken.

Ik hoop dat de WebKit in zijn huidige vorm compleet wordt geïntegreerd in Leopard, want de Nightlies icm Safari onder Tiger zijn niet altijd een supergroot feest. De systeem-standaard WebKit blijft behoorlijk achter inmiddels en het is jammer dat Apple geen tussentijdse updates daar voor uitgeeft.

Ik hoop ten zeerste dat "HTML 5" (werktitel) snel en breed geïmplementeerd wordt. De veranderingen zullen niet zo groot zijn als in XHTML 2, want dan werkt Microsoft weer niet mee. Wel moeten er een aantal dingen hard aangepakt worden om de huidige tekortkomingen van HTML 4 aan te pakken.

0 Maurits van Baerle
@Gustaaf437 • 22 maart 2007 20:28

Wat bedoel je precies met 'het achteruitgaan van Gecko'?

Qua snelheid, multi-platform compatibiliteit, functionaliteit, nauwkeurigheid en standards-compliance is 1.9 een forse verbetering ten opzichte van 1.8. Dat komt met name door de overschakeling op Cairo voor het grafisch gedeelte. Op welke vlakken vind je van niet dan?

0 Gustaaf437
@Maurits van Baerle • 23 maart 2007 00:15

Ik kom op mijn eigen site een paar onvolkomenheden tegen in Gecko 1.9 die er misschien niet zo een twee drie uit te halen zijn. Dan gaat het hier om dingen die in sommige gevallen de werking van een website onmogelijk maken.

Ik ben het wel met je eens dat men er op de pure plain-rendering er op vooruit gaat.

Cairo is zeker een verbetering grafisch (zeker de performance). WebKit gebruikt Cairo nu ook al en ik denk dat Cairo een goede kans heeft door meer projecten gebruikt te gaan worden.

0 Maurits van Baerle
@Gustaaf437 • 23 maart 2007 12:08

Ik zou me daar nu nog niet teveel mee bezig houden. Gecko 1.9 is nu nog een vroege alpha met nog maanden werk voor de boeg. Je moet op z'n minst wachten tot een tweede beta voor je je site er aan gaat aanpassen.

aliencowfarm
22 maart 2007 18:20

mja zo lang dat er meer ie browser zijn dan de rest heeft w3c weinig te zeggen. Dan blijven de meest ontwikkelaars strikt voor ie designen

0 defusion
@aliencowfarm • 22 maart 2007 18:54

achja, ik test mijn sites niet eens met IE. puur omdat ik weet dat het toch niet rendered zoals het hoort.
magoed, ik ben ook niet iemand die dit voor zijn werk doet, dus mijn centjes hangen niet af van of mijn sites compatible zijn met het hoogste aantal users.

ultimasnake
@defusion • 22 maart 2007 19:12

Beide gevallen vind ik fout.

Ik ben al jaren webdeveloper. En als je een site in CSS maakt.. met de XHTML 1.0 standaarden enzo (standaard in je dreamweaver bestandje gezet)... dan is er niets aan de hand.

Zelf kan ik site maken die in IE 6, IE 7, FF1, FF2, en safari 98% indentiek zijn. Op wat kleine dingen als margin afwijkingkjes zie je het verschil met het blote oog niet.

IE is slecht, maar veel legt toch aan de developer zelf!

dus gewoon

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

+ css en je zit gebakken

+1 Eswip
@ultimasnake • 22 maart 2007 19:16

Ik krijg een css dropdown menu nog steeds niet volgens standaarden werken in IE hoor.

Er is behoorlijk wat mis met IE, en dan VOORAL als je je aan de standaarden houd. Dat jij margins niet zo boeiend vind, betekend niet dat dit een groot probleem is. Als jij een hele grafische site hebt, met allemaal background plaatjes die precies moeten aansluiten, is IE echt een ramp.. geloof mij..

+1 Forau
@ultimasnake • 22 maart 2007 19:20

Margin errors zijn zeer duidelijk te zien in IE, zeker als je werkt met rechte lijnen. Die lopen niet netjes in elkaar door, zodat je weer aparte CSS instructies for IE moet schrijven, of het met plaatjes oplossen. Dit soort margin errors zie je op zo goed als alle TFT/LCD schermen, en waarschijnlijk ook op alle CRT schermen (ik zie het in ieder geval op de mijne). Het gebruik van XHTML verandert daar niets aan.

*edit* typo.

Erkens
@ultimasnake • 22 maart 2007 20:01

Waarom zou je XHTML willen gebruiken? De meeste sites draaien toch niet op een XML backend, dus dat nut verdwijnt al. Verder is het nogal loos om een transitional doctype te gaan gebruiken voor een _nieuwe_ site, daar is die doctype niet voor bedoeld

Maargoed, de meeste problemen met browsers zitten (zoals ik dat dageljiks in mijn werk tegen kom) vooral in de actievere onderdelen zoals JavaScript etc...

+1 Metal Baron
@ultimasnake • 22 maart 2007 21:59

Verder is het nogal loos om een transitional doctype te gaan gebruiken voor een _nieuwe_ site, daar is die doctype niet voor bedoeld

Waar ie ook voor bedoelt is: als je target=_blank wilt gebruiken, om maar iets te noemen, zit je toch aan trans vast ben ik bagn.

JackBol
@ultimasnake • 22 maart 2007 23:21

Als je frames wilt gebruiken ook. Het is er echt niet voor niets uit gesloopt.Google eens naar alternatieven, zou ik zeggen.

jurrie

@ultimasnake • 23 maart 2007 08:00

Waar ie ook voor bedoelt is: als je target=_blank wilt gebruiken, om maar iets te noemen, zit je toch aan trans vast ben ik bagn.

Buiten het feit dat ik blank targets grote onzin vind, kun je dit natuurlijk met een rel="" afvangen en die door javascript naar een nieuw venster laten gaan.

"Jamaar, javascript si teh ev0l!" -- dan geen nieuw venster openen met links of doen alsof je valid xhtml presenteert!

+1 Metal Baron
@ultimasnake • 23 maart 2007 09:36

Buiten het feit dat ik blank targets grote onzin vind, kun je dit natuurlijk met een rel="" afvangen en die door javascript naar een nieuw venster laten gaan.

"Jamaar, javascript si teh ev0l!" -- dan geen nieuw venster openen met links of doen alsof je valid xhtml presenteert!

Blank target is een noodzakelijk kwaad waar je zal moeten leren leven als je websites voor andere mensen dan voor jezelf ontwerpt.

Als je frames wilt gebruiken ook. Het is er echt niet voor niets uit gesloopt.Google eens naar alternatieven, zou ik zeggen.

De reden voor het er uit slopen is, is dat XHTML in de stricte vorm vindt dat de gebruiker zelf moet bepalen welke links in een nieuw venster moeten openen, en welke niet. Hier omheen gaan werken met javascript etc is jezelf voor de gek houden.

Validatie als 'strict' is geen doel op zich. XHTML 'transistional' is er niet voor niets: sommige sites moeten nou eenmaal blank targets hebben, of je het nu leuk vindt of niet. Heel veel bezoekers verwachten ook dat externe links in nieuwe vensters openen. Toen ik m'n site aanvankelijk in strict had gemaakt zonder blank target, waren de eerste klachten van bezoekers dat ze het zo vervelend vonden dat externe links niet in een nieuw venster opende, waardoor ze niet terugkwamen op m'n site als ze het venster dichtklikten. XHTML strict is gewoon te strict voor 'normale' sites, het wordt niet voor niets zo weinig gebruikt.

0 Despo
@defusion • 22 maart 2007 19:12

Sterker nog, ik ontwikel op een platform waar geen ie aanwezig is. Dus testen voor ie is er niet bij.

wvdburgt
22 maart 2007 18:20

Dit kan alleen maar goed nieuws zijn. Als microsoft eens een keer mee werkte dan hadden we het web zoals het is bedoeld: voor iedereen. Een goede zet weer van Apple , net zoals toen ze als eerste waren met ACID 2.

elmuerte
@wvdburgt • 22 maart 2007 18:57

ACID2 is overrated. Waarom? Simpel weg omdat de ACID2 test halen niks zegt over het correct weergeven van correcte HTML+CSS. ACID2 test voor een deel of de renderer ook foute CSS afhandeld zoals het gedocumenteerd is. Als alle websites correcte CSS gebruiken boeit het niet dat foute CSS misschien niet helemaal correct afgehandeld word. Mensen die het intereseert hoe CSS afgehandeld word produceren meestal correcte CSS.

Maar goed, het is allemaal leuk en aardig om de ontwikkeling van webstandaarden te versnellen, maar als de meerderheid van de gebruikers een outdated browser hebben heb je er niet veel aan. En veel veranderingen aan standaarden is ook vervelend voor ontwikkelaars en continuiteit.

+2 ytsmabeer
@elmuerte • 22 maart 2007 19:34

ACID2 geeft alleen maar weer dat de browser een bepaalde CSS standaard goed opvolgd.
Heeft niks met html te maken, maar alles met css2

Snake

@wvdburgt • 22 maart 2007 18:24

Dat was Opera 9 die de ACID 2 test perfect doorstond

+1 Carbon
@Snake • 22 maart 2007 18:32

Dat was Opera 9 die de ACID 2 test perfect doorstond

Safari was wel degelijk de eerste browser die dat voor elkaar kreeg.

http://en.wikipedia.org/wiki/Acid2#Released_browsers

Klaus_1250
22 maart 2007 19:19

Maakt Safari niet gebruik van een aangepaste versie van de KHTML-render engine (Konqueror)?

+1 Gustaaf437
@Klaus_1250 • 22 maart 2007 19:27

Klopt, maar het is inmiddels zover aangepast dat het op sommige plekken al bijna niet meer mogelijk is om dingen uit te wisselen. Toch is men weer van start gegaan, van beide kanten uit, om dit weer geheel mogelijk te maken. Er is onder andere een Qt port gemaakt van WebKit. Het is eventueel op termijn mogelijk dat men de projecten geheel samenvoegt en zo ook samen verder werkt.

+2 Carbon
@Gustaaf437 • 22 maart 2007 19:41

maar het is inmiddels zover aangepast dat het op sommige plekken al bijna niet meer mogelijk is om dingen uit te wisselen.

Er bestaat een redelijke kans dat de volgende versie van Konqueror op WebKit gebaseerd wordt.

http://yuiblog.com/blog/2006/12/11/knoll-staikos-video/

+1 b19a
22 maart 2007 19:47

De ontwikkelaars van Internet Explorer zouden er beter aan doen XHTML support in te bouwen in plaats van HTML 5 te ontwerpen. Zoveel goeds hebben we immers nog niet uit het dat onderdeel van Microsoft gezien!

+1 zero4cool
@b19a • 22 maart 2007 22:33

Hoe zit het dan precies met XHTML ondersteuning in IE?
Ik heb net een site gemaakt in MS Expression Web in XTML 1.0 (strict). Wordt prima ondersteunt en afgedwongen door de syntax checker.
Zou toch raar zijn als het dan in de MS browser niet wordt ondersteund?
Ik zie het ook niet, werkt prima in IE7, en ziet er net zo uit als FF2 .

0 Exiss
@zero4cool • 22 maart 2007 23:11

XHTML wordt prima ondersteunt ieg IE6 en hoger (IE5 weet ik niet.) Beter gezegd zelfs: ASP.NET 2.0 / VS2005 (En dus het gehele .NET framework) supporten gewoon standaard XHTML en volgens mij is XHTML zelfs de default.

ACID2 is de meeste lompe en overrated test die ooit bedacht is vanuit een programmeeroogpunt. Fouten dienen door de programmeur opgelost te worden. De programmeur mag er niet vanuit gaan dat de browser dat wel even fixed.... Dat is zelfs 1 van de grootste en belangrijkste bad practises...

Cavorka
@Exiss • 22 maart 2007 23:41

Ja hoor, IE ondersteunt XHMTL.

Het rendert XHTML als HTML en dat is dus niet echt wat ik versta onder 'ondersteunen'.

+1 J.J.J. Bokma
@Exiss • 23 maart 2007 05:45

"Fouten dienen door de programmeur opgelost te worden. De programmeur mag er niet vanuit gaan dat de browser dat wel even fixed...."

Fout. Dat was het idee achter XHTML, en gelukkig zien meer en meer mensen in wat daar fout aan is.

Mensen die ooit met oude Netscape versies gewerkt hebben herinneren zich nog wel de grijze lege pagina. Een (1) foutje in een pagina, en daar was ie. Netscape stapte daar snel van af door een tolerante parser te maken, zoals het wat mij betreft hoort.

Als programmeur hoor je er voor te zorgen dat je applicatie niet er kompleet uitvliegt als er 1 foutje in zit. En dat is /precies/ wat XML (en dus XHTML) wel doen.

Zeker tegenwoordig met een enorm groot aantal dynamisch aangemaakte pagina's wil je niet dat een kleine fout je gebruiker opzadelt met "Parse error xxx at line 1313".

Kijk voor de grap eens hoeveel XHTML pagina's well formed zijn. Schrik! En dan hoeveel er valideren: Dubbele Schrik!

+1 psyBSD
@Exiss • 23 maart 2007 14:42

@ J.J.J. Bokma:

Dus omdat blijkbaar elke idioot met een internet-verbinding zichzelf web-developer kan noemen moeten we het web aan hun aanpassen?!

Het mooie van XHTML is niet dat het stuk kan, maar dat het HEEL duidelijk is waar het stuk gaat. En als dat betekend dat jan-met-de-pet moet gaan nadenken als hij <table></table> tags klopt dan is dat een feature, geen bug.

0 SmellyTweaker
@Exiss • 23 maart 2007 15:34

XHTML 1.0 is zo ontworpen, dat het als HTML kan worden opgeleverd en in de praktijk visueel hetzelfde eruit ziet in de browser.

In werkelijkheid is er geen ondersteuning voor XHTML in IE.

+1 praseodymium
@zero4cool • 22 maart 2007 23:51

Zolang je XHTML als HTML verstuurd (mime text/html, standaard) dan vindt IE alles goed maar wordt je document ook als HTML gerenderd.

Wanneer je het XHTML-document ook echt als XHTML doorgeeft (mime application/xhtml+xml) dan rendered elke normale browser je document als XHTML. Behalve IE, daar krijg je een 'bestand downloaden' dialoog. Het wordt dus inderdaad erg goed ondersteund

Nick_S
@zero4cool • 23 maart 2007 02:08

Ik weet in ieder geval, dat als je een xml header(<?xml ?>) toevoegt aan je pagina, dat IE 6 in quirks mode springt in plaats van in de standaard mode.

Dus volgens mij kan IE geen XHTML aan, aangezien dat een extensie is op XML.

Havocnl
@b19a • 22 maart 2007 19:54

Het zou echter ook zo kunnen zijn dat een complete verse start met een helemaal nieuwe HTML standaard (en geen extension op oude HTML 4.0) wel veel betere support kan leveren en uiteindelijk beter is. Soms moet je tijdelijk wat inleveren voor vooruitgang he.
XHTML support zou echter nog steeds een welkome toevoeging zijn in IE....

+1 J.J.J. Bokma
@b19a • 23 maart 2007 05:41

Laat XHTML alsjeblieft een zachte dood sterven. Eindelijk.

XHTML is een draak die nooit los gelaten had mogen worden. XML is leuk bij het ontwikkelen en testen, *niet* om uit te serveren op het web.

switchboy
22 maart 2007 18:09

Mooizo. Dan nu nog cross-platformfonts en dan zien pagina's er eindelijk overal uit zoals jij dat wilt.

+1 Troetelbiertje
22 maart 2007 19:18

Whatwg-werkgroep

Pleonasme?

0 Ron.IT
23 maart 2007 09:21

IE6/IE7 kunnen prima XHTML aan en renderen ook keurig in CSS1Compat mode.

Het punt is dat IE niet het xhtml/xml mime type ondersteunt, het moet vanuit de webserver als text/plain of text/html verstuurt worden.

Het volgende voorbeeld werkt perfect in alle browsers, en voldoet keurig aan de XHTML 1.1 versie (met uitzondering dus dat het mime niet goed is, als je het in IE6/7 wilt laten werken):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/tr/xhtml11/Dtd/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=ISO-8859-15" />
</head>
<body>
Geen probleem
</body>
</html>

En als je keurig naar een website gaat in je browser IE, FireFox, Opera (Safari heeft geen goede ondersteuning helaas), en dan het adres verandert in:

javascript:alert(document.compatMode);

Dan krijg je keurig een javascript prompt, die aangeeft of de browser in Quirks mode (BackCompat) aan het renderen is of dat het zonder fout correctie gedaan wordt via CSS1Compat mode.

Het is ook veel gemakkelijk om hetzelfde resultaat te verkrijgen tussen IE, Firefox, Opera, Safari, etc in CSS1Compat mode. Goed voorbeeld is bijvoorbeeld dat IE6/IE7 dan wel keurig margin: 0 auto; ondersteunen voor centreren in het midden en dat het text-align: center; truukje niet meer nodig is.

http://tweakers.net/ = BackCompat
http://cssplay.co.uk/ = CSS1Compat

+1 aToMac
23 maart 2007 09:22

Volgens mij wordt het tijd voor een andere internet standaard. HTTP en HTML met de hele klere bende op de schop.

Het is allemaal prachtig hoor, dat css en Javascript en AJAX en WPF/e en Apollo. Maar http en html waren er voor bedoeld om tekst over te pompen en niet al die rarigheid van tegenwoordig. Ik render een pagina in html 1.1 met Netscape 2 en een destijds Mac, sneller dan de huidige pagina's met alle toeters en bellen.

Alle technieken nu zijn workarounds om het Desktop gevoel over te brengen op internet.

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Safari-ontwikkelaars treden toe tot html-werkgroep W3C

Lees meer over

Nieuwste IT Banen

LOI ICT Opleidingen

Gerelateerde content

Sorteer op:

Weergave:

Reacties (38)