/ Forside / Teknologi / Udvikling / HTML / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
HTML
#NavnPoint
molokyle 11184
Klaudi 5506
bentjuul 3377
severino 2040
smorch 1950
strarup 1525
natmaden 1396
scootergr.. 1320
e.c 1150
10  miritdk 1110
Opdater css-hacks før IE7
Fra : Jens Gyldenkærne Cla~


Dato : 13-10-05 22:35

Følgende artikel kom på IE-bloggen i dag:
<http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx>

Den beskriver nogle af de fejl der kan opstå i IE7, hvis man har
brugt css-hacks til at skjule noget for IE6. Hvis man har brugt den
slags, er det nok en god ide at tjekke om siden ser korrekt ud i
IE7 - eller simpelthen bare erstatte css-hacket med noget bedre.

Det drejer sig bl.a. om følgende hacks:

html > body
* html
head:first-child + body
head + body
body.html
body > element
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

 
 
Jeppe Høiby (13-10-2005)
Kommentar
Fra : Jeppe Høiby


Dato : 13-10-05 23:21

Jens Gyldenkærne Clausen wrote:
> Følgende artikel kom på IE-bloggen i dag:
> <http://blogs.msdn.com/ie/archive/2005/10/12/480242.aspx>

Ja, det er en meget interessant blog, og det er rart at få forklaret
hvorfor tingene bliver gjort som de gør.

> Den beskriver nogle af de fejl der kan opstå i IE7, hvis man har
> brugt css-hacks til at skjule noget for IE6. Hvis man har brugt den
> slags, er det nok en god ide at tjekke om siden ser korrekt ud i
> IE7 - eller simpelthen bare erstatte css-hacket med noget bedre.
>
> Det drejer sig bl.a. om følgende hacks:
>
> html > body
> * html
> head:first-child + body
> head + body
> body.html
> body > element

Ja, det skal nok give anledning til forvirring, men omvendt tror jeg at
de fleste af dem som har brugt CSS hacks for at snyde IE, godt er klar
over der skal til for at få det til at virke igen.

Jeg synes det er meget positivt at der bliver gjort noget ved IE's bugs,
man må sige det €@£½!?$"#¤€+$%€£ også er på tide! Ærgeligt at mime type
ikke er med på listen over ting der bliver rettet, men man kan åbenbart
ikke få det hele...

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

Jens Gyldenkærne Cla~ (14-10-2005)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 14-10-05 00:37

Jeppe Høiby skrev:

> Ja, det er en meget interessant blog, og det er rart at få
> forklaret hvorfor tingene bliver gjort som de gør.

Jeg har den fast på min rss-liste. Vil man vide noget om
fremtidsudsigterne for IE, er det dér man skal kigge IMO.

> Ja, det skal nok give anledning til forvirring, men omvendt
> tror jeg at de fleste af dem som har brugt CSS hacks for at
> snyde IE, godt er klar over der skal til for at få det til at
> virke igen.

Det er jeg slet ikke så sikker på. Dem der har opfundet de givne
hacks ved nok hvad man kan gøre. Dem der beskriver de enkelte hacks
gør sikkert også. Men i mange tilfælde er hacks bare en del af en
færdig "pakke" - fx i en menu, en layout-skabelon eller lignende.

Hvis man ikke selv har skrevet hack-koden ind for at koble IE6 fra,
kan man let overse betydningen af den.


> Ærgeligt at mime type ikke er med på listen over ting der
> bliver rettet, men man kan åbenbart ikke få det hele...

Jeg havde gerne set at application/xhtml+xml-understøttelsen var
kommet med i IE7, men ser det ikke som nogen stor mangel. Brugen af
en xml-mimetype er ikke et praktisk problem, da html-sider (og
xhtml-sider) fungerer fint som text/html.

Rettelser i IE7's håndtering af css, png, xhtml m.v. betyder at der
bliver brug for mindre lappekode. En evt. tilføjelse af en xhtml-
mime-type, vil kun betyde at man kan få en større del af browserne
over på den "rigtige" side når man bruger content-negotiation.
Hensynet til ældre browsere vil gøre det upraktisk at gå helt over
til en xhtml-mime-type i meget lang tid.

Derudover kan jeg også godt se det potentielle problem i at gå over
til en xml-baseret mime-type. XML (og dermed xhtml) er ikke
fejltolerant - en enkelt fejl i xml-koden betyder at hele
dokumentet ikke kan vises. HTML er på den anden side ekstremt
fejltolerant - browseren forsøger efter bedste evne at vise en side
korrekt selv om der er fejl i koden.

En fordel ved den ikke-fejltolerante løsning er at fejl hurtigt
bliver opdaget - der er ikke store chancer for at en person der har
rettet en webside vil overse en fejl der blokerer hele sidens
visning.

Men ulempen er at meget af fleksibiliteten ved html forsvinder. En
simpel fejlrettet fil, kan i princippet lægge et helt site ned -
det vil gøre onlineredigering til et mareridt. Jeg vil tro at xml-
parsing også kan give problemer i et langsomtloadende dokument (kan
man reelt begynde at vise noget før hele xml-kilden er læst?)

Jeg er på ingen måde fortaler for at man skal acceptere fejl i sin
egen kode, men jeg tror alligevel ikke at jeg vil have browserne
til at forkaste ethvert dokument med fejl. Det kan være rart nok
som webdesigner at browseren går tydeligt opmærksom på en fejl i
xml-koden. Men som slutbruger er man fuldstændig ligeglad med
eventuelle kodefejl - bare man kan få lov at se den side man vil
have frem.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

Mikkel Moldrup-Lakje~ (14-10-2005)
Kommentar
Fra : Mikkel Moldrup-Lakje~


Dato : 14-10-05 09:33

Jens Gyldenkærne Clausen wrote:
>
> Rettelser i IE7's håndtering af css, png, xhtml m.v. betyder at der
> bliver brug for mindre lappekode. En evt. tilføjelse af en xhtml-
> mime-type, vil kun betyde at man kan få en større del af browserne
> over på den "rigtige" side når man bruger content-negotiation.
> Hensynet til ældre browsere vil gøre det upraktisk at gå helt over
> til en xhtml-mime-type i meget lang tid.

Hensynet til ældre browsere btyder vel også, at vi fortsat vil have brug
for masser af lappekode.

Hvor mange mon vil droppe IE6 i løbet af det første år?

Kan vi gætte noget ud fra erfaringerne fra andre opdateringer?

Hvordan vil Microsoft mon lancere IE7? Kommer den med blandt de
almindelige opdateringer ller hvad?

FUT: dk.edb.internet.software.browser.

Mikkel

Jeppe Høiby (14-10-2005)
Kommentar
Fra : Jeppe Høiby


Dato : 14-10-05 18:30

Jens Gyldenkærne Clausen wrote:
> Det er jeg slet ikke så sikker på. Dem der har opfundet de givne
> hacks ved nok hvad man kan gøre. Dem der beskriver de enkelte hacks
> gør sikkert også. Men i mange tilfælde er hacks bare en del af en
> færdig "pakke" - fx i en menu, en layout-skabelon eller lignende.
>
> Hvis man ikke selv har skrevet hack-koden ind for at koble IE6 fra,
> kan man let overse betydningen af den.

Ja, det har du ret i. Jeg tror dog at hvis hacks er en del af en færdig
pakke, så er chancen for at det bliver fikset vel større?

> Jeg havde gerne set at application/xhtml+xml-understøttelsen var
> kommet med i IE7, men ser det ikke som nogen stor mangel. Brugen af
> en xml-mimetype er ikke et praktisk problem, da html-sider (og
> xhtml-sider) fungerer fint som text/html.

Ja, det er jeg enig i, men for hver version man udskyder en
understøttelse jo længere tid går der inden man kan tage det i brug.
Hvis nu fx IE7 understøttede application/xhtml+xml, var vi vel bedre
stillede når(hvis) engang XHTML 2.0 kommer? Men jeg ser det nu heller
ikke som første prioritet, og mener de har taget den rigtige beslutning
i at afhjælpe diverse CSS mv.

> Rettelser i IE7's håndtering af css, png, xhtml m.v. betyder at der
> bliver brug for mindre lappekode. En evt. tilføjelse af en xhtml-
> mime-type, vil kun betyde at man kan få en større del af browserne
> over på den "rigtige" side når man bruger content-negotiation.
> Hensynet til ældre browsere vil gøre det upraktisk at gå helt over
> til en xhtml-mime-type i meget lang tid.

Enig. Jeg tror også først det bliver udbredt når 2. generation af IE med
understøttelse af application/xhtml+xml ser dagens lys at det for alvor
vinder frem. Så der går nok laaaaang tid.

> Derudover kan jeg også godt se det potentielle problem i at gå over
> til en xml-baseret mime-type. XML (og dermed xhtml) er ikke
> fejltolerant - en enkelt fejl i xml-koden betyder at hele
> dokumentet ikke kan vises. HTML er på den anden side ekstremt
> fejltolerant - browseren forsøger efter bedste evne at vise en side
> korrekt selv om der er fejl i koden.

Jeg ser det som en kæmpe fordel at man helt "gratis" får tjekket sit
dokument, og at det ikke kan vises med fejl. Måske lidt i stil med
kompileret kode.

> En fordel ved den ikke-fejltolerante løsning er at fejl hurtigt
> bliver opdaget - der er ikke store chancer for at en person der har
> rettet en webside vil overse en fejl der blokerer hele sidens
> visning.

Yes, det er lækkert!

> Men ulempen er at meget af fleksibiliteten ved html forsvinder. En
> simpel fejlrettet fil, kan i princippet lægge et helt site ned -
> det vil gøre onlineredigering til et mareridt. Jeg vil tro at xml-
> parsing også kan give problemer i et langsomtloadende dokument (kan
> man reelt begynde at vise noget før hele xml-kilden er læst?)

Jeg synes det er en stor fordel fordi det *tvinger* os alle til at
levere et ordentlig stykke arbejde. Mht. onlineredigering, så tror jeg
at de gode CMS'er vil implementere en feature, der parser dokumentet
inden det kan publiceres. Og mht. håndkodede sider, så er der da ingen
der retter direkte i en fil i produktion, VEL?!

Så vidt jeg husker, så er det ikke et krav at dokumentet *skal* parses
før man må begynde at vise det. Jeg tror jeg læste det et sted på
mozillas website.

> Jeg er på ingen måde fortaler for at man skal acceptere fejl i sin
> egen kode, men jeg tror alligevel ikke at jeg vil have browserne
> til at forkaste ethvert dokument med fejl. Det kan være rart nok
> som webdesigner at browseren går tydeligt opmærksom på en fejl i
> xml-koden. Men som slutbruger er man fuldstændig ligeglad med
> eventuelle kodefejl - bare man kan få lov at se den side man vil
> have frem.

Ja, det er jeg sådan set enig i. Jeg tror dog at det kommer til at
betyde et skift i den måde vi laver sider på. Den måde vi arbejder på -
arbejdsgangen. Jeg tror det vil stille højere krav til os, og det synes
jeg kun er godt. Men du har helt ret i at brugere bare vil se siden og
vil ikke ulejliges med fejl - det er vores opgave at sikre det at sikre
fejlfri sider

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

Søg
Reklame
Statistik
Spørgsmål : 177559
Tips : 31968
Nyheder : 719565
Indlæg : 6408929
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste