Kirjaudu

Uutiskirje

Rekisteröidy Sektoriin ja tilaa itsellesi joko aamuisin tai iltaisin ilmestyvä uutiskirje sähköpostiisi.

Maanantai, 6.6.2005

Konqueror selvitti Acid2-testin

Avoimeen lähdekoodiin perustuva Konqueror-selain on läpäissyt selaimen CSS/HTML-standarditukea mittaavan Acid2-testin virheittä. Konquerorin pärjääminen testissä ei ole yllätys, sillä samaa KTHML-renderöintimoottoria hyödyntävä Safari-selain läpäisi testin ensimmäisenä maailmassa viime huhtikuussa. Avoimen lähdekoodin kehitysmallista on KHTML:n kohdalla ollut hyötyä niin Applelle kuin Konqueror-kehittäjillekin. Tällä kertaa Konqueror hyötyi Applen Safariin tekemistä korjauspäivityksistä.

Testin läpäissyt Konqueror-versio ehtii näillä näkymin mukaan KDE-työpöytäympäristön 3.4.2-versiopäivitykseen.

Lue juttu oma, 6.6.2005 00:08. Lähde: kdedevelopers.org

Muita aiheeseen liittyviä uutisia

Rekisteröidy ja kirjaudu sisään, jos haluat kommentoida.

Kommentit ( 17 uutta / 17 )
pistettä.
Näytä vain kommentit joilla on vähintään
Jazmo Standardit
Jazmo, 6.6.2005 00:12:26		 Pisteet: 0
Toivottavasti tällaiset - joskin keinotekoiset - testit aiheuttavat paineita myös IE:n kehitykseen siten, että IE7 tukee hyvin kaikkia CSS2.1 määreitä ja miksei siitä pitemmällekin, tosin CSS3 ei taida olla vielä edes lyöty lukkoon, vai onko?

Voi mikä autuuden päivä se olisikaan, kun yksi validi css-tiedosto riittäisi ja kaikki selaimet näyttäisivät sisällön oikein :)
(no yuccan sivut saattavat näkyäkin..)
blog -> http://blog.qkaasu.com/
olmari Re: Standardit
olmari, 6.6.2005 00:18:10		 Pisteet: 0
Toivottavasti tällaiset - joskin keinotekoiset - testit aiheuttavat paineita myös IE:n kehitykseen siten, että IE7 tukee hyvin kaikkia CSS2.1 määreitä ja miksei siitä pitemmällekin, tosin CSS3 ei taida olla vielä edes lyöty lukkoon, vai onko?
Mikäs tästä tekee keinotekoisen testin?
Jazmo Re: Standardit
Jazmo, 6.6.2005 00:50:30		 Pisteet: 0
Mikäs tästä tekee keinotekoisen testin?
Onhan se vähän kuin 3D Mark tuolla näytönohjainpuolella. Ei kai millään sivulla tuolla tavalla hymiöitä piirrellä. :) No olet ehkä oikeassa, onhan tuo 'hauska' tapa osoittaa toimiiko selain standardin mukaan vai ei.
blog -> http://blog.qkaasu.com/
kakoskin Re: Standardit
kakoskin, 6.6.2005 07:33:51		 Pisteet: 0
Onhan se vähän kuin 3D Mark tuolla näytönohjainpuolella. Ei kai millään sivulla tuolla tavalla hymiöitä piirrellä. :) No olet ehkä oikeassa, onhan tuo 'hauska' tapa osoittaa toimiiko selain standardin mukaan vai ei.
Jos olisin IE7:n kehittäjä niin korjaisin tuon testin toimimaan IE:ssä, mutta lisäisin hymiön näyttämään keskaria ;)
tsvk Re: Standardit
tsvk, 6.6.2005 01:56:41		 Pisteet: +1
Toivottavasti tällaiset - joskin keinotekoiset - testit aiheuttavat paineita myös IE:n kehitykseen siten, että IE7 tukee hyvin kaikkia CSS2.1 määreitä ja miksei siitä pitemmällekin, tosin CSS3 ei taida olla vielä edes lyöty lukkoon, vai onko?
Juu, samaa mieltä testien luomien paineiden suhteen muille selaimille. ACID-testi on loppukäyttäjälle helppokäyttöinen ja -tajuinen mittari testata selaimen standardiyhteensopivuus. Esimerkiksi Mozillan bugtrackerin ACID2-seurantabugi http://bugzilla.mozilla.org/show_bug.cgi?id=289480... on saanut viime aikoina paljon huomiota sillä testi on ollut medioissa esillä.

Toivottavasti jatkossa tulee ACID3, jne.

Voi mikä autuuden päivä se olisikaan, kun yksi validi css-tiedosto riittäisi ja kaikki selaimet näyttäisivät sisällön oikein :)
No ei ihan, sillä esim. ACID2-testin CSS ei ole validia: http://jigsaw.w3.org/css-validator/validator?uri=h... Osa ACID2-testin eri osatesteistä koskevat selainten käyttäytymistä juuri ääri- ja virhetilanteissa, jolloin sivujen renderöinti virheellisen CSS:n kohdalla eri selaimissa vaihtelee. Selainkoodaajat ovat tulkinneet CSS-speksejä eri tavoin, tai speksi ei ole ollut kovin kattavasti määritelty, tai sitten selaimissa ei olla otettu huomioon kaikkia erikoistapauksia.

Eli siis autuus tulee silloin kun kaikki selaimet näyttävät sisällön oikein, oli CSS validia tai ei. :)
Karitku Re: Standardit
Karitku, 6.6.2005 07:56:03		 Pisteet: 0
No ei ihan, sillä esim. ACID2-testin CSS ei ole validia: http://jigsaw.w3.org/css-validator/validator?uri=h... Osa ACID2-testin eri osatesteistä koskevat selainten käyttäytymistä juuri ääri- ja virhetilanteissa, jolloin sivujen renderöinti virheellisen CSS:n kohdalla eri selaimissa vaihtelee. Selainkoodaajat ovat tulkinneet CSS-speksejä eri tavoin, tai speksi ei ole ollut kovin kattavasti määritelty, tai sitten selaimissa ei olla otettu huomioon kaikkia erikoistapauksia. Eli siis autuus tulee silloin kun kaikki selaimet näyttävät sisällön oikein, oli CSS validia tai ei. :)
Eli siis epästandardi testi? Eikös tämä nyt ole vähän kornia jos tehdään täysin standardien mukaan ja kuitenkin yhdessä kohtaa halutaan asioiden toimivan "kuten minä sanon". Ehkä noiden testien tekijän kannattaisi julkaista oma ACID2-merkki, joka takaisi selainten toimivuuden heidän määritysten mukaan. Mutta eihän tuo ole testin tekijän vika vaan surkeasti tehtyjen standardien, jos tulkinnan varaa jää liikaa.
Voitku
Shrike Re: Standardit
Shrike, 6.6.2005 09:07:39		 Pisteet: +1
Eli siis autuus tulee silloin kun kaikki selaimet näyttävät sisällön oikein, oli CSS validia tai ei. :)
Eli siis epästandardi testi? Eikös tämä nyt ole vähän kornia jos tehdään täysin standardien mukaan ja kuitenkin yhdessä kohtaa halutaan asioiden toimivan "kuten minä sanon". Ehkä noiden testien tekijän kannattaisi julkaista oma ACID2-merkki, joka takaisi selainten toimivuuden heidän määritysten mukaan. Mutta eihän tuo ole testin tekijän vika vaan surkeasti tehtyjen standardien, jos tulkinnan varaa jää liikaa.
Trolli voi mennä takaisin luolaansa.

ACID2-testissä on tarkoituksellisesti virheellistä CSS:ää tutkimassa sitä, että käyttäytyykö selain virhetapauksissakin speksin edellyttämällä tavalla. Aivan tavallinen testicase siis; kokeillaan ehjällä ja rikkinäisellä datalla, sovelluksen pitää selvitä molemmista kunnialla.
--
public class Shrike extends Codeslave implements Engineer, Nerd
Karitku Re: Standardit
Karitku, 6.6.2005 12:05:59		 Pisteet: 0
Trolli voi mennä takaisin luolaansa.
Taureni.

ACID2-testissä on tarkoituksellisesti virheellistä CSS:ää tutkimassa sitä, että käyttäytyykö selain virhetapauksissakin speksin edellyttämällä tavalla. Aivan tavallinen testicase siis; kokeillaan ehjällä ja rikkinäisellä datalla, sovelluksen pitää selvitä molemmista kunnialla.
Jos speksi niin sanoo niin sitten tuo on hyvä juttu. Edellisestä kommentoinnista ei tätä asiaa vain käynyt selväksi. Mutta ihan oikeasti olisi järkevää tehdä WiFi-sertifikaatin tapainen leima, jonka saisi vain tuon testin selvittäneet. Tämä olisi hyvä markkinointikikka ja nostaisi painetta niissä selainvalmistajissa joiden selain ei täytä tuota. Tai sitten ne vähät välittäisivät moisesta.
Voitku
Re: Standardit
neko, 6.6.2005 12:15:25		 Pisteet: 0
utta ihan oikeasti olisi järkevää tehdä WiFi-sertifikaatin tapainen leima, jonka saisi vain tuon testin selvittäneet. Tämä olisi hyvä markkinointikikka ja nostaisi painetta niissä selainvalmistajissa joiden selain ei täytä tuota.
Mircosoft tekisi vain oman sertifikaatin, josta vain sen oma IE selviäisi ;-)
Nothing more, nothing less. Every Little Thing. Kaori.
Re: Standardit
wheany, 6.6.2005 09:08:50		 Pisteet: 0
lan bugtrackerin ACID2-seurantabugi http://bugzilla.mozilla.org/show_bug.cgi?id=289480... on saanut viime aikoina paljon huomiota sillä testi on ollut medioissa esillä.
Ja Operan tilanteen näkee Operan foorumeilta: http://my.opera.com/forums/showthread.php?threadid...
d2s WebKit on nyt avoin projekti
d2s, 8.6.2005 21:31:03		 Pisteet: 0
Apple julkaisi WebKitin Open Source projektina. Se ei ollut aikaisemmin avointa koodia mutta nyt se on saatavilla BSD-lisenssillä varustettuna. WebKitin osat WebCore ja JavaScriptCore olivat jo ennestään avointa lähdekoodia (ne pohjautuvat LGPL-lisenssillä julkaistuihin khtml ja kjs koodeihin) mutta nyt homma helpottuu kun projektin kehitys avautuu julkisen CVS-serverin ja Bugzillan myötä.

WebKit on siis Objective-C API, joka kietoo sisäänsä WebCoren.

http://weblogs.mozillazine.org/hyatt/archives/2005...
http://webkit.opendarwin.org/
JJ Apple ja KHTML
JJ, 6.6.2005 05:35:22		 Pisteet: 0
Onpas kummaa tuo KHTML-kehittäjien ulosanti. Tänään ollaan vaihteeksi sitä mieltä että niitä Applen pätsejä kannattaakin käyttää. Kuukausi tai pari sitten kun tästä oli juttua viimeksi niin täälläkin annettiin linkkejä khtml-kehittäjien blogeihin joissa he sanoivat että yksikään Hyattin Acid-pätsi ei tule khtml:aan.

No, maailma muuttuu ja ehkä parin kuukauden päästä taas kuorolla uusi laulu harjoiteltuna. :)
Karitku Re: Apple ja KHTML
Karitku, 6.6.2005 07:48:05		 Pisteet: 0
Onpas kummaa tuo KHTML-kehittäjien ulosanti. Tänään ollaan vaihteeksi sitä mieltä että niitä Applen pätsejä kannattaakin käyttää. Kuukausi tai pari sitten kun tästä oli juttua viimeksi niin täälläkin annettiin linkkejä khtml-kehittäjien blogeihin joissa he sanoivat että yksikään Hyattin Acid-pätsi ei tule khtml:aan.
Eikös ne uhonneet kirjoittaneensa suurimman osan uusiksi tuosta koodista. Tiedä sitten mitä se uudelleen kirjoitus taas meinaa. Noh, voi kai päätellä heillä olleen ongelmia sitten saada omat koodit(ei siis nämä uudelleen kirjoitetut) toimimaan vai mistä lienee suunnan muutos johtunut, kenties liikaa töitä tarvittu.
Voitku
daimoni Re: Apple ja KHTML
daimoni, 6.6.2005 09:44:19		 Pisteet: 0
Eikös ne uhonneet kirjoittaneensa suurimman osan uusiksi tuosta koodista. Tiedä sitten mitä se uudelleen kirjoitus taas meinaa. Noh, voi kai päätellä heillä olleen ongelmia sitten saada omat koodit(ei siis nämä uudelleen kirjoitetut) toimimaan vai mistä lienee suunnan muutos johtunut, kenties liikaa töitä tarvittu.
Quote tuosta: "Roughly half of the Safari Acid2 patches could be merged in some form or another, and another two bugfixes could be merged from Safari 1.3 once found and isolated. The rest was written from scratch. All in all not a bad reuse of code, allthough slow."

Joidenkin pätsien backporttaus WebCoresta on ongelmallista senkin takia että Apple tekee optimoinnit luonnollisesti käyttäen omia rajapintojaan, ja nämä osat on melkeinpä pakko kirjoittaa KHTML:lle alusta.

Turhaa kitinää enivei, itse ovat KHTML:än ja KDE:n develoopperit lisenssinsä valinneet.
"Minusta on viime aikoina daimonin kommentteja lukeneena alkanut muutenkin tuntua, että äijä kuvittelee olevansa joku jumalhahmo, jonka sana on totuus ja laki."
-- Anonyymi kommentoija
Nemesis Re: Apple ja KHTML
Nemesis, 6.6.2005 10:34:24		 Pisteet: +2
Turhaa kitinää enivei, itse ovat KHTML:än ja KDE:n develoopperit lisenssinsä valinneet.
On se nyt kumma kun ihmiset ei VIELÄKÄÄN tajua mistä tässä skismassa oikein oli kyse. KHTML-kehittäjiä ärsytti ne _käyttäjät_ (ei niinkään Apple) jotka kuvittelivat, että koska Apple tekee parannuksia WebCoreen, niiden pitäisi ilmestyä nopeasti KHTML:ään. KHTML-kehittäjät sitten kertoivat, että noin ei tapahdu, koska Apple on päättänyt olla tekemättä yhteistyötä KHTML-kehittäjien kanssa. Toki, Applella on oikeus toimia noin, ja tuo tosiasia vieläpä oikein erikseen mainittiin KHTML-kehittäjien toimesta kun tästä alettiin puhumaan.

Mielestäni KHTML-kehittäjillä on oikeus olla ärtynyt Applen toimista (vaikka se alkuperäinen viesti käsitteli nimenomaan käyttäjiä, ei niinkään Applea). Apple mainostaa itseään open-source ystävällisenä firmana. Mutta ainakin tässä tapauksessa Apple teki tietoisen päätöksen olla tekemättä yhteistyötä KHTML-kehittäjien kanssa. KHTML-tyypit antoivat Applelle pääsyn heidän CVS:ään (jolloin Applen kehittäjät voivat poimia parhaat patchit sieltä), mutta Apple ei antanut KHTML-kehittäjille mitään. Ei pääsyä bugitietokantaan, eikä pääsyä heidän n omaan VCS:ään (vaikka KHTML-kehittäjät olivat valmiit allekirjoittamaan NDA:t). Applen patchit eivät ole sellaisessa muodossa missä niitä voitaisiin käyttää, he vain pudottaman KHTML-kehittäjien syliin valtavan koodikasan.

Tämä Acid2-juttu olikin sitten hieman erilainen tapaus. Applen kehittäjät uhosivat että he läpäisevät Acid2-testin. Kun tämä skisma sitten levisi ympäri nettiä ja Apple sai huonoa PR:ää, KHTML-kehittäjät pyysivät että voisiko Apple antaa KHTML-kehittäjille ne Acid2-patchit järkevässä muodossa. Ja Applen kehittäjät suostuivat siihen. Normaalisti he julkaisevat muutoksensa vain osana isompaa WebCore-julkaisua. Nyt he julkaisivat muutokset järkevässä muodossa, ja seurauksena on se, että niistä osa jopa saatiin liitettyä osaksi KHTML:ää. Kun ottaa huomioon, että nämä pienista patcheista noin puolet saatiin KHTML:ään suoraan, siitä valtavasta WebCore-julkaisusta saaraan varmaan 5% liitettyä KHTML:ään järkevässä ajassa.

Applella on oikeus toimia siten kuin se toimii, mutta ei se silti ole kovin mukavaa. Ja jos he päättävät toimia noin, heidän ei tulisi mainostaa itseään "open-source-ystävällisenä". Pelkkä lisenssin noudattaminen ei riitä tuohon IMO.
JJ Re: Apple ja KHTML
JJ, 6.6.2005 15:36:03		 Pisteet: 0
Turhaa kitinää enivei, itse ovat KHTML:än ja KDE:n develoopperit lisenssinsä valinneet.
On se nyt kumma kun ihmiset ei VIELÄKÄÄN tajua mistä tässä skismassa oikein oli kyse. KHTML-kehittäjiä ärsytti ne _käyttäjät_ (ei niinkään Apple)
Itkua oli sekä käyttäjistä että Applesta, osittain ihan syystäkin.

KHTML-tyypit antoivat Applelle pääsyn heidän CVS:ään (jolloin Applen kehittäjät voivat poimia parhaat patchit sieltä),
Ööh, eikö KHTML:n CVS ole kaikille avoin? (ei toki kirjoitus, mutta patchien poimintaan ei kai tarvita kirjoitusoikeutta)

Applen kehittäjät uhosivat että he läpäisevät Acid2-testin. Kun tämä skisma sitten levisi ympäri nettiä ja Apple sai huonoa PR:ää, KHTML-kehittäjät pyysivät että voisiko Apple antaa KHTML-kehittäjille ne Acid2-patchit järkevässä muodossa. Ja Applen kehittäjät suostuivat siihen.
Dave Hyatt on ainoa Safarin kehittäjistä jonka olen Acid2-testistä mitään havainnut kirjoittaneen. Eikä hänen blogistaan mitään uhoamista löydy. Muistaakseni ne pätsit olivat kyseisessä blogissa _heti_ kun Safarin kehitysversio sen läpäisi. Onko jossakin viitteitä siihen että KHTML-kehittäjät nimenomaan näitä pätsejä erikseen pyysivät ja saivat. Vai tarkoittaako tuo järkevämpi muoto jotakin muuta kuin niitä blogin liitteenä olleita pätsejä?

Normaalisti he julkaisevat muutoksensa vain osana isompaa WebCore-julkaisua. Nyt he julkaisivat muutokset järkevässä muodossa, ja seurauksena on se, että niistä osa jopa saatiin liitettyä osaksi KHTML:ää.
Mikä tämä järkevä muoto nyt oli? Minä olen nähnyt ainoastaan pätsit edellistä WebCore-julkaisua vasten, joka on ihan sama muoto kuin normaalistikin, toki normaalisti muutoksia on paljon enemmän.

Patchien liittämisen vaikeus on osittain seurausta siitä että apple ei julkaise versiohistoriaa, osittain siitä että Apple käyttää omia rajapintojaan, mikä on tietenkin järkevää ja osittain siitä että se Applen WebCore on koko ajan enemmän erossa KHTML:sta. Opensourceen kuuluu oikeus forkata kehitys, Apple on sitä käyttänyt eikä siinä ole mitään pahaa, toki markkinointi voisi olla vähän erilaista.

un ottaa huomioon, että nämä pienista patcheista noin puolet saatiin KHTML:ään suoraan, siitä valtavasta WebCore-julkaisusta saaraan varmaan 5% liitettyä KHTML:ään järkevässä ajassa.
No ei se WebCore niin valtava ole, toki riippuu ihan mihin vertaa. Liittämisen ongelmia on myös muita kuin muutosten määrä, KHTML-kehittäjät haluavat usein tehdä asiat eri tavalla kuin Apple, joka on ihan kannustettavaa, silloin patchista (ja mahdollisesti suuresta määrästä muita patcheja jotka riippuvat kyseisestä) ei ole mitään hyötyä, paitsi ehkä patchin dokumentaatio.
Nemesis Re: Apple ja KHTML
Nemesis, 6.6.2005 19:14:27		 Pisteet: 0
Itkua oli sekä käyttäjistä että Applesta, osittain ihan syystäkin.
Alkuperäisessä viestissä josta tämä koko rumba alkoi, puhuttiin lähinnä käyttäjistä. Ei siinä Applea tietenkään ylistetty, mutta siinä todettiin että Apple noudattaa KHTML:n lisenssiä. Se viesti lähinnä käsitteli käyttäjiä jotka syyttivät KHTML-kehittäjiä laiskoiksi jne.

Ööh, eikö KHTML:n CVS ole kaikille avoin? (ei toki kirjoitus, mutta patchien poimintaan ei kai tarvita kirjoitusoikeutta)
Toki, sekosin tuossa hetkeksi :)

uistaakseni ne pätsit olivat kyseisessä blogissa _heti_ kun Safarin kehitysversio sen läpäisi. Onko jossakin viitteitä siihen että KHTML-kehittäjät nimenomaan näitä pätsejä erikseen pyysivät ja saivat. Vai tarkoittaako tuo järkevämpi muoto jotakin muuta kuin niitä blogin liitteenä olleita pätsejä?
Käsittääkseni he työskentelivät yhdessä noiden patchien parissa. JA tämä oli ensimmäinen kerta kun WebCoresta saatiin yksittäisiä patcheja, hervottoman koodikasan sijaan.

Mikä tämä järkevä muoto nyt oli? Minä olen nähnyt ainoastaan pätsit edellistä WebCore-julkaisua vasten, joka on ihan sama muoto kuin normaalistikin, toki normaalisti muutoksia on paljon enemmän.
Järkevä muoto on pienet sulautettavissa olevat patchit, jossa saisi olla vieläpä kuvaavat kommentit ja dokumentoinnit, eikä valtava koodikasa josta ei ota mitää tolkkua.

Patchien liittämisen vaikeus on osittain seurausta siitä että apple ei julkaise versiohistoriaa, osittain siitä että Apple käyttää omia rajapintojaan, mikä on tietenkin järkevää ja osittain siitä että se Applen WebCore on koko ajan enemmän erossa KHTML:sta. Opensourceen kuuluu oikeus forkata kehitys, Apple on sitä käyttänyt eikä siinä ole mitään pahaa, toki markkinointi voisi olla vähän erilaista.
Ja kuten minäkin sanoin, Apple ei riko mitään lakia eikä lisenssiä. Eli sinun ei tarvitse kertoa minulle, että Apple toimii ihan lisenssin mukaan, totesin tuon jo alkuperäisessä viestissäni.