Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 75 reacties
Bron: IEBlog

Op het weblog van de Internet Explorer-developers is een artikel verschenen waarin een overzicht wordt gegeven van de veranderingen op CSS-gebied in Internet Explorer 7. Om na te gaan welke veranderingen in de renderengine van Internet Explorer 7, Trident genaamd, moesten worden doorgevoerd, is veel geluisterd naar en gesproken met de community. Ten opzichte van de versie 6 van deze browser zijn daarom in totaal ruim 200 zaken gewijzigd: als bug gefixt of als nieuwe feature toegevoegd. Microsoft is zich er terdege van bewust er nog niet te zijn: 'we understand that we are far from being done and we know we have still a lot of work ahead of us'. Volgens Program Manager Markus Mielke is Internet Explorer 7 een eerste stap op weg naar een browser die beter omgaat met recente specificaties. In de toekomst zal de browserontwikkeling dan ook blijven doorgaan.

Dat het Microsoft ernst is met het ondersteunen van CSS-specificaties blijkt, aldus Mielke, ook uit het feit dat in Internet Explorer 7 geen propriŽtaire functionaliteit is toegevoegd. De mogelijkheid dit in de toekomst wel te doen, wordt echter opengehouden. Wel zal dan gebruikgemaakt worden van het -ms--prefix. Dit is de officiŽle wijze om CSS uit te breiden met eigen of nog niet volledig geÔmplementeerde functionalteit. In Mozilla's Gecko-engine gebeurt dit bijvoorbeeld met het prefix -moz-. Verder wordt door Mielke samengewerkt met het W3C om de CSS-specificaties waar nodig te verhelderen. Alle opgeloste bugs zijn alleen van toepassing als Trident in standard compliance-modus sites rendert. Dit gebeurt alleen als een <!doctype> wordt meegegeven. Aan quirks mode is niets veranderd. Alphatransparante png-afbeeldingen worden in strict en in quirk modus goed gerenderd.

Overzicht CSS-veranderingen in Internet Explorer 7
Klik op de afbeeling voor een groter overzicht van de CSS-veranderingen in Internet Explorer 7
Moderatie-faq Wijzig weergave

Reacties (75)

Dus IE7 zal de ACID test beter renderen dan IE6?
Ja: zie IE7 beta 3 en IE6
Nog steeds steeds is er absoluut geen smilie in te herkennen, maar het is minder fout.

Overigens heeft acid2 betrekking op foute(!) css-code. Css beschrijft ook de manier hoe bepaalde foute code gerenderd moet worden.

@Blokker_1999. Het wordt een beedje standaart he, de: IE7 <-> Acid2 vraag ;)
Wat is dat toch met die ACID test?
Doelloos ding wat ik in geen enkele browser goed heb gezien!


@Blokker
Ja dat is precies het punt, maar het is natuurlijk om je voor te schamen. Dat je denkt dat je macht in handen hebt en daarom de boel maar niet update.
Ik denk ook dat de komst van FF goed is voor de ontwikkeling van het web. Laat MS maar lekker kutten met die IE... ik heb een beta gedraait, maar ik blijf toch lekker bij FF.
Het is iig goed dat MS met de ontwikkeling 'begint' en de standaarden aanhoudt!
Doelloos ding wat ik in geen enkele browser goed heb gezien!
Nog niet geprobeerd in Safari en Konqueror zeker? :P

Ik meen dat Opera in de volgende versie ook de ACID2 kan renderen, maar dat weet ik niet zeker.
Eťn van de eerste beta-versies van Opera 9 renderde ACID 2 al goed en de huidige releases dus ook. :)
Als de Acid 2 test goed gerenderd wordt, worden de meeste van CSS gebruik-makende sites ook goed gerenderd.

Safari's render WebKit ondersteunt de Acid 2 test al bijna 2 jaar. Ook Konquer's Khtml doet het goed en bij Opera duurt het renderen misschien even, maar daar is die uiteindelijk ook goed.

De Acid 2 test is dus alleen een indicatie, maar wel een hele handige. Nu hoeven web-engine ontwikkelaars niet duizenden sites af te gaan en zelf veel CSS schrijven om te kijken of wat zij in elkaar gezet hebben goed werkt.

Gelukkig is de CSS ondersteuning in IE 7 in ieder geval veel beter, maar ik vraag me af of hij goed door mijn site komt, maar dat zien we dan wel.

@johnbetonschaar: Gecko 1.9, de renderer van FireFox 2.0b en 3.0a is wat verder dan Gecko 1.8, maar doet het nog niet vlekkeloos.
Nee, Acid 2 is zeker geen uitputtende testcase. In fact focussed deze test zich met name op de afhandeling van mallformed CSS (error-correctie) en zegt dus juist erg weinig over correcte implementatie van CSS zelf :P

En de ondersteuning van CSS in IE7 is op fundamenteel vlak nog net zo beroerd als in IE6 ;)
Moet je het wel goed zeggen he.
FF 2.0b : Gecko 1.8.1 (bijna gelijk aan Gecko 1.8 (FF1.0/FF1.5)
FF 3.0a : Gecko 1.9 -> Acid2 compliant!
Acid is zeker GEEN methode om te kijken of je CSS goed werkt. Wie dat denkt weet niet waar hij over praat.
Acid gaat over een theroetische afwerking van fouten in CSS en heeft geen enkele waarde bij het afwerken van goed werkende CSS.
Leuk voor de anti-ms groep en leuk voor de ontwikkelaars maar zeker geen doel dat enige prioriteit zou moeten hebben boven het gewoon ondersteunen van de aanbevelingen van de 3WC's ;)
Wat is dat toch met die ACID test?
Doelloos ding wat ik in geen enkele browser goed heb gezien!


Safari rendered de Acid2 test al vanaf April 2005 perfect, opera vanaf versie 8.5 zo goed als perfect (nog niet met de nieuwste opera getest). Firefox 1.5.x is er bijna, en ik meen te hebben gelezen 2.0-CVS ook perfect...

Hoewel Acid2 inderdaad niet echt een real-world voorbeeld van CSS is, zou ik het toch zeker niet doelloos noemen. De test is zo opgezet dat wanneer je hem perfect kan renderen het zo goed als gegarandeerd is dat er geen enkele site met geldige CSS bestaat die niet correct afgebeeld zal worden...
Opera 9.0 doet 'm correct.
Inderdaad ACID2 compliance is (bijna) overbodig.
Zolang de browser de weergave van correcte CSS maar goed doet. Of foute CSS ook goed behandeld word is een bij zaak.
Anders? Zeker
Beter? Waarschijnlijk
Correct? Absoluut niet

ACID2 test is voor de IE devs alles behalve een prioriteit. Men bouwt liever eerst de belangrijkste functionaliteit en het exotische houd men voor later
Ik begrijp dat de ontwikkeling van software zeer ingewikkeld en tijdsintensief is maar dit duurt nu toch echt wel lang! Dat een grote mastodont als microsoft niet in staat is van een applicatie als IE sneller te ontwikkelen verbaast mij!

Wat wel zeer positief is, is dat er is samengewerkt met W3C, het standaard ondersteunen van deze standaarden is belangrijk voor de toekomstige compatibiliteit en ontwikkeling van websites!
De ontwikkeling aan IE heeft jarenlang in de ijskast gestoken. Voor MS was het geen prioriteit meer. Men had de browseroorlog gewonnen en de concurentie (Netscape) volledig uit de markt gedrukt. Andere alternatieven zoals Opera zijn nooit echt kunnen doorgroeien.

Toen is Firefox gekomen en ze hebben infeite veel geleerd van hie IE destijds NS heeft verslagen en passen dat nu opnieuw toe. IE verliest marktaandeel en uiteindelijk kon MS niet anders dan de ontwikkeling voor IE opnieuw leven in te blazen. Uiteraard zit men nu met het probleem dat men 4 a 5 jaar na het stilvallen van de ontwikkeling een enorme achterstand heeft opgelopen tov de concurentie en dat het dus tijd vergt om hen terug in te lopen.

Had MS de afgelopen 5 jaar IE gewoon blijven doorontwikkelen, regelmatig updates uitgevoerd en verbeteringen in de renderengine blijven doorvoeren dan had Fx nooit het marktaandeel gehad dat het vandaag heeft en had MS zoveel tijd niet nodig om al die wijzigingen klaar te krijgen. Men weet nu al dat de implementatie van de nieuwste standaarden nooit zal voltooid zijn voor de release van Vista en men begint daarom nu al te spreken over de volgende IE versies.
Mja ze hebben dan ook al een keertje beweerd dat hun html implementatie nodig was omdat het vooruitstrevend is, wat als gevolg had dat als ze 1maal de nummer 1 waren verdere ontwikkeling gestopt waren, denk niet dat ze datzelfde trucje nog eens kunnen gebruiken.

En eerlijk gezegd zie ik ook niet in waarom MS niet zou proberen standards compliant te zijn, ze zien dat er toch concurrentie is en deze is niet kapot te krijgen door marktaandeel ervan af te snoepen, kunnen ze beter geen kosten steken in zelf "nieuwe" dingen te gaan maken en gewoon de standaarden volgen.
Vreemd dat de bugs alleen in strict modus zijn opgelost.
Ik maak mijn sites altijd in xhtml Transitional.
Als ik het goed gelezen heb zal ik dus nog steeds hacks moeten gebruken :(

offtopic:
Van de week was ik bezig met een select dropdown box.
Wel grappig dat de (W3C) add() methode wel wordt ondersteund door IE, maar niet door FF :o
Volgens mij gaat het om Render-strict versus Quirks. Niet om HTML-strict versus HTML-transitional.

Render-strict is volgens mij bij IE7 alles wat een goede Doctype op de juiste manier gebruikt. Als jij dat doet zullen jouw sites in Strict/Standard Compliant mode worden gerenderd en gaat het goed.

Het idee er achter is dat ze niet teveel kunnen veranderen aan IE zonder miljoenen bestaande sites in de wereld te verneuken. Dit hebben ze opgelost door de bugs in Quirksmode te laten zitten. Die buggy homepage over iemands hamster die voor het laatst in 2000 is geupdate en is gemaakt met een hele brakke editor renderd in Quirksmode en ziet er nog hetzelfde uit.

Die goed gebouwde site door professionele web-devvers die zorgen dat ie goed in elkaar zit en gebruiken een goede Doctype waardoor het makkelijker wordt om een site te bouwen die compatible is met meerdere browsers.
Het artikel is niet helemaal duidelijk, maar wat bedoeld wordt, is dat de bugs alleen gefixt zijn als de browser in 'standards compliance mode' draait, in tegenstelling tot 'quirks mode', waarin het het gedrag van oude versies van IE nadoet. Je komt in standards compliance mode door een geldig doctype op te geven. Dat kan best xhtml 1.0 transitional zijn, of html 4.01 loose.
Echt balen, dat ze dat hebben verandert. In IE5/6 kreeg je quirks door <?xml voor je doctype te zetten, nu dus niet meer. Hoe moet ik nou zorgen dat IE7 mijn site goed weergeeft?

* MBV gaat overschakelen van dirty hacks naar officiŽle hacks: conditional comment :(
Nee, het gaat niet om Strict maar om 'standards-compliant' mode hetgeen ook het geval is bij het gebruik van een volledig (dus inclusief een system identifier*) Transitional DTD.
Note wel dat IE7 nog steeds geen XHTML ondersteund.

* funny thing is dat IE7 elke string waar maar http:// in voorkomt goedkeurt als system identifier :P
imho mag men IE7 niet releasen vooraleer van dit soort zaken degelijk werk is gemaakt. Anders moeten we achtereen weer op zoek gaan naar extra hacks om een site toch maar weer correct te laten weergeven op weer een andere browser.
Ach, wat mij betreft mogen browser niet gereleased worden die niet 100% compatible zijn met de marktleider. Vergeet niet IE had vrijwel de complete markt in bezit. Alle "problemen" die zijn ontstaan komen dus doordat de concurrenten geen compatible producten hebben ontwikkeld. :)


Wat denk je, zullen de ontwikkelaars van Opera, Firefox of Safari zich iets van mij aantrekken?

Edit: Sarcastisch? Gedeeltelijk.
Maar je kunt wel degelijk vraagtekens zetten bij de geestelijke vermogens van mensen die "standaarden" ontwikkelen wetende dat het product dat 95% van de markt in handen heeft daar fundamenteel van afwijkt. Dan leef je wat mij betreft in een ivoren toren. Hopelijk leert men hiervan en gaat men in de toekomst meer samenwerken maar gezien de discussie OpenXML vs OpenDoc lijkt de wereld in de laatste 5 jaar nauwelijks veranderd.
@humbug:

Op zich zou je gelijk kunnen hebben en er zijn meerdere situaties waarin het in het verleden zo is uitgepakt en niemand er over klaagt, er zijn echter twee redenen waarom het in dit geval niet klopt.

- De W3C standaarden waren er eerder, ze zouden zich nooit kunnen aanpassen aan iets wat nog niet bestaat, namelijk de MS interpretatie. Je kunt W3C dus niet verwijten de markt te hebben genegeerd.

- Er bestaat geen MS Standaard. De verschillen tussen IE en de rest van de wereld bestaan niet uit menings- en interpretatieverschillen van MS programmeurs maar uit simpele typfouten, bugs, slordig programmeerwerk, vergeten onderdelen etc. De verschillende IE versies zijn vaak ook incompatibel met elkaar. Als iets in situatie A op een bepaalde manier uitpakt is dat helemaal geen garantie dat het in een situatie waar je gelijke interpretatie mag verwachten ook zo uitpakt. Er is niet een lijst waar je kunt op zoeken hoe de IE developers iets hebben bedoeld of ontwikkeld, niemand weet hoe iets zal worden geinterpreteerd, ook de IE-developers niet. Pas bij gebruik blijkt hoe het zal uitpakken. Dat heeft niets met een standaard te maken. Zelfs toen de wereld voor 99% uit IE gebruikers bestond waren deze problemen er en was het maken van pagina's die op alle IE versie er goed uitzagen een ramp omdat documentatie over de MS-'standaard' niet bestaat.
Natuurlijk zijn er wel microsoft standaards. Dat die niet openbaar zijn is een tweede maar ze bestaan zeker wel.

Daarnaast is IE6 gewoon een redelijk beperkte doorontwikkeling van IE5. Hierbij was het ook toen al vele malen belangrijker dat IE6 aan de interne standaarden bleef voldoen dan dat de nieuwe W3C zaken geimplementeerd werden. Een van de redenen daarvoor was natuurlijk dat niemand anders die standaarden beter implementeerde dan MS! De houding van Microsoft met IE7 is dan ook niets nieuws. Vernieuw de user interface, fix de bugs en breidt de functionaliteit uit met nuttige zaken. Volledige ondersteuning van "een" standaard is daarbij niet het primaire doel van MS. Een product op de markt brengen wat competatief is wel.

IE7 lijkt voor mij voornamelijk een poging om IE6 weer up to date te brengen waarna in volgende versies MS weer extra functionaliteit gaat toevoegen. Maar of die functionaliteit uit een openbare standaard komt of MS zelf wat uit de hoge hoed tovert is niet relevant. Feit is dat het enkel werken naar 100% standard compliance een teken is van stilstand. En ik blijf het vreemd vinden dat een organisatie standaarden voor een markt kan ontwerpen zonder dat een marktpartij met meer dan 80% marktaandeel daar aan mee werkt. Dat klopt gewoon niet.

Maar ik heb liever dat MS (of wie dan ook) iets nieuws aan de browser toevoegd wat een hoop mensen aanzet om nieuwe dingen met hun websites te doen dan dat men blijft staren naar zaken die op zich goed werken. Flash is niet volgens een bepaalde officiele standaard bedacht. Zelfs HTML is uit het brein ontspoten van iemand die dacht "dat kan beter!" Men zag een gat in de functionaliteit en heeft daar een oplossing voor bedacht.

En juist doordat MS zo'n groot marktaandeel heeft kunnen dat soort vernieuwingen snel door de markt geadopteerd worden. Who cares dat de webdevelopers trucs moeten uithalen om IE8 met W3C standaard code om te kunnen laten gaan. Als de nieuwe features goed zijn zullen een hoop gebruikers daar toch voor kiezen. Dat is dan misschien niet leuk voor het W3C en de concurrentie maar wel de manier waarop een succesvol bedrijf werkt. Uiteindelijk is het de gebruiker die bepaald wat belangrijk is. En die gebruiker vindt standaarden leuk, maar features nog veel leuker. Want laten we eerlijk zijn. Is Firefox een succes door zijn betere ondersteuning van de standaarden of gewoon door de betere user interface met tabs en dergelijke?
Natuurlijk zijn er wel microsoft standaards. Dat die niet openbaar zijn is een tweede maar ze bestaan zeker wel.
Als jij ze weet te vinden moet je even contact opnemen met MS, die zullen heel geinteresseerd zijn in documentatie van hun render engine.

Er is geen enkele reden om aan te nemen dat er een MS standaard is. MS heeft openlijk de hulp van duizenden webdevelopers moet inroepen om aan te geven hoe iets werkt in hun eigen rendereninge. Een standaard suggereerd dat er een reden is voor sommig gedrag, dat er consistentie in zit en dat iemand weet hoe hij werkt.

Heb je uberhaupt wel eens iets gelezen uit de IE7 developer blog? Hoe ze zelf hun uiterste best hebben gedaan om een hele hoop bugs (zoals ze ze zelf noemen) te verwijderen uit de engine. Heb je wel eens gezien wat voor bugs het zijn? Denk je dat iemand bij MS bewust heeft gedacht:
"Ik weet van Float betekent maar laten we in 10% (niet in 100%!) van de gevallen Float eens alles laten kopieeren, in plaats van wat de bedoeling is."
"Laten we content pas laten verschijnen als mensen hun browservenster hebben geminimaliseerd en weer gemaximaliseerd"
"Laten we 40% + 40% +20% eens 110% laten zijn, behalve als alles in een kader staat, dan is 40+40+20=90"
"Laten we de eerste letter van een regel soms eens niet laten zien en soms wel."

De inconsistentie is met de beste wil van de wereld geen standaard te noemen. MS zal de bugs in ieder geval geen standaard noemen, daar is vijf minuten kijken op de IE7-dev-blog genoeg voor.
Concurrenten die zich moeten aanpassen aan IE? Dat is een vreemde redenatie. Boor CSS, XHTML enz. zijn standaarden gemaakt zodat iedere browser de code hetzelfde zou kunnen weergeven. (een soort omschrijving van wat de code inhoud) Als nou de concurrenten van IE het 9 van de 10 keer wel goed weergeven en IE zelf niet dan moeten we de standaarden maar vergeten? IE is niet de standaard, IE houdt zich niet aan de standaarden. En dat is het hele probleem nou net, en daar word je als je met css e.d. werkt niet blij van :(
ie is de de facto standaard. Zo gek is deze redenatie dus nog niet.
De šanbevelingen" en geen standaarden zijn ook betrekkelijk en lopen eveneens achter bij de ontwikkelingen. Dus houd nu eens op met het verheerlijken van die zogenaamde standaarden.
Op die manier denkend hadden we nooit airbags gekregen, was het nooit verplicht geworden om een gordel te dragen, hadden schepen nooit van metaal geweest maar nog steeds van hout of papyrus, hadden we geen restricties op milieuvervuiling gehad, en zo kan ik nog wel even doorgaan.

Echte vernieuwing betekent altijd dat er spaanders vallen.
Al deze zaken zijn niet als standaard aan de industrie opgelegd maar door de industrie zelf ontwikkeld door vraag van de gebruikers. (Behalve misschien de gordel)

Je kan nog steeds houten boten kopen en bezitters van een auto zonder airbag worden niet van de weg gehaald.

Nee, je kan het optreden van de W3C het beste vergelijken met het ontwikkelen van een nieuwe vulopening voor een benzinetank waar geen bestaande slang inpast zonder overleg met autofabrikanten en olieconcerns.

Echte vernieuwing komt niet uit standaarden. Standaarden komen uit vernieuwende activiteiten.
Je wil dus zeggen dat WMP enkel nog maar mag werken met iPods en dat online downloads enkel nog in het AAC formaat met DRM verkocht mogen worden? Microsoft is hier immers geen marktleider en heeft een ander formaat.
Ik hoop dat dit sarcastisch bedoeld is maar er was leven voor en tijdens IE. Er zijn standaarden gemaakt juist zodat browsers allemaal hetzelfde weergeven bij dezelfde informatie.
Het grote gevaar van deze hacks is dat ze vervolgens niet meer werken in andere browsers en we weer geconfronteerd worden met IE-only sites. Als IE dan ook nog backwards compatible wordt en goed om blijft gaan met de hacks zijn de rapen helemaal gaar, want dan is er ook geen stimulans meer om deze hacks ooit nog te verbeteren en zullen ze alleen maar toenemen in gebruik.
Inderdaad,
Maak de hacks helemaal uit IE halen is geen goed idee.
Ik zou er zo'n informatiebalk voor inzetten.
"Deze site gerbuikt features die deze versie van IE niet standaard ondersteund, wil u deze features voor deze eer aanzetten?"

Voor de gebruiker is de site dan nog toegangkelijk, maar voor devvers blijft de drang om te zorgen dat je die informatiebalk niet krijgt.

Of te wel, de gebruiker verliest geen funtionaliteit, maar de devvers worden met de neus op de feiten gedrukt.
De kunst van de 'hacks' is juist dat je de gebruiker helemaal niet lastig valt met hoe brak IE wel niet is...

Het lijkt me niet echt prettig voor een gebruiker om elke keer op zo'n balk te moeten klikken om z'n site te kunen zien. Een hack kan pas succesvol zijn als hij transparant naar de gebruiker gebracht kan worden namelijk :)
Tja achteraf moeten we toch opzoek naar hacks omdat er nogsteeds dingen gaar/niet zullen werken. Internet Explorer 7 is een beetje het zelfde als Windows 3.0 verkopen onder de naam Windows XP. Oude troep die ze een wat grafischere omgeving hebben gegeven, maar geen problemen opgelost die zich voortdoen.

Microsoft denkt wat mensen blij te maken met IE7, maar ik word er alleen maar minder blij van. Dat ze idd netjes wachten tot alles klaar is aan IE7 en Vista ipv dat ze dingen doordrukken omdat het anders te laat is. Owja het is een commercieel proces. :z
Als windows 3.1 verkocht werd met het uiterlijk van XP, en dan met Internet ondersteuning zou ik het gelijk gebruiken! :+

3.1 is in vergelijking met xp echt Snel!
Simpel, Trumpet, PPP en Mosaic erop => internet!
Gewoon even de databits, stopbits, PPP PAP of CHAP en nog wat kleine details configureren, maar dan ga je ook.

Damn, voor het eerst online komen met Windows 3.1 voelde bij alsof je jezelf het Internet op gehackt had :)
och.. er blijft altijd wel iets met microsoft producten wat er voor zorgt dat het het eerste jaar crap is.. maargoed.. deadlines halen ze al niet, dus er moet ergens op bezuinigd worden :+
Het wordt de maanden na de release goed opletten op marktonderzoeken over de penetratie van IE7. Als veel (aka de meeste) mensen nog steeds IE6 blijven en niet op IE7 overstappen dan duurt het nog wel tot de algehele overstap op Vista voordat web developers echt weer kunnen ademhalen en maffe IE6 hacks eruit kunnen halen en websites zich eindelijk gedragen zoals ze moeten.
Je opmerking is enigszins off-topic, maar een reactie is er echter wel op mogenlijk:
Alles gebruikers van XP/SP2 krijgen IE7 als een 'soort verplichte update'*, net zoals gebruikers van bijvoorbeeld IE6 als 'verplichte update' binnen kregen.

*: Volgens mij kun je, als je in de advanced update mode zit de update weer wel uitschakelen - dus als gebruiker heb je enigszins de keuze, maar voor Jan Modaal zal het updaten bijna een verplichting zijn.
Ik denk dat de overgang van IE6 naar IE7 een stuk sneller zal gaan dan die van IE5.5 naar IE6.

Tegenwoordig hebben veel meer mensen automatische updates aan staan dan vijf jaar geleden door de opmars van XP en het tegenwoordig standaard aan staan van automatische updates.

Bovendien was het volgens mij destijds geen 'verplichte' update maar een optionele. IE7 wordt een 'critical' update. Bij IE6 moest je er expliciet voor kiezen om hem te installeren, bij IE7 moet je er expliciet voor kiezen om hem niet te installeren.
veel bedrijven zitten nog op Windows2000, waar IE7 niet voor beschikbaar wordt, dus ik zou maar niet teveel hopen :'(
Zou je zo vriendelijk willen zijn een lijstje te posten; dan kan ik dat doorspelen naar de afdeling sales.
Voorlopig kunnen webdevelopers sowieso geen adem halen want IE7 behoeft nog minstens net zoveel hacks en workarounds als IE6...

Fundamenteel is er weinig veranderd buiten de interne hacks voor de genoemde common bugs; wat dat betreft is IE7 nog steeds zo non-comformant op CSS gebied als IE6 dat is...
En dan snap ik nog steeds niet waar alphatransparantie van png-afbeeldingen nog steeds niet wordt ondersteunt.
excellent point!
Hoezo 'excellent point' ?

Alphatransparantie voor png-afbeeldingen wordt namelijk wŤl ondersteund. Dat gebeurt dan misschien wel niet op de wijze die ontwikkelaars gehoopt hadden, maar de ondersteuning is er in elk geval wŤl.

Lees gerust even na op http://blogs.msdn.com/ie/archive/2005/04/26/412263.aspx hoe de PNG Alpha Channel-implementatie gerealiseerd werd :)
Heuh?
Alphatransparante png-afbeeldingen worden zowel in strict als in quirk modus goed gerenderd.
Als je de volledige blogpost leest dan merk je dat dit wel degelijk is toegevoegd, net omdat het zo een belangrijk iets is.
Alpha channel PNG support (Not a CSS feature but too important for designers to not call it out J)
Ik zie telkens mensen over 'hacks' praten; maar kan iemand wat concrete voorbeelden geven?

(zelf knutsel ik een heel klein beetje, doe dat in notepad, en test dat tegenwoordig in ie7 (op een Vista Beta). Als alles goed werkt laat ik iemand op ie6 kijken, en heel soms controleer ik FF. Eigenlijk heb ik dan nooit problemen, vandaar. Overigens doe ik (blijkbaar) geen spannende dingen)
Blijkbaar werk je nog met tables en niet met allerlei spannende dingen zoals floats. Zodra je IE6 aan de floats zet kom je allerlei bugs tegen: gedupliceerde content, dubbele marges, linebreaks in je code die als <BR> worden weergegeven, etc. Om dit soort dingen te verhelpen worden er allemaal rare IE6-hacks toegepast, dingen als "margin-right: -3px" om de dubbele content op te lossen, of een "display: inline" bij een float toevoegen om IE niet de margin te laten weergeven.
Om de linebreak parsing uit te zetten moet je vervolgens je tekst links laten floaten, waarbij je dan weer 1% hoogte moet maken, etc. Aangezien IE voor de mac dat dan weer niet heeft en daar anders op getoond wordt gebruik je de zgn "Holly Hack". Allemaal ranzige oplossingen om IE6 ook aan de CSS2 conforme code te krijgen.
Ik ken wel meer browsers die niet om kunnen gaan met floats. Sterker nog ik ken (veelgebruikte) XHTML browsers die niet om kunnen gaan met een <hr> tag (bv Teleca)
Moet dat dan ook niet <hr /> zijn in XHTML?
Internet Explorer is nog steeds niet bij de tijd, maar ik moet zeggen dat ze wel een behoorlijke inhaalslag hebben gemaakt.Veel dingen die we al lang wilden werken nu:

min/max-width/height,
png-support,
:hover op alle elementen,
veel minder bugs met borders, marges, overflow enz.

Dus zo negatief ben ik nog niet. Natuurlijk duurt het nog minstens anderhalf jaar voordat een redelijk deel van de gebruikers is overgestapt, maar het is een goed begin voor MS na 5 jaar stilstand.
Nu nog zorgen dat GOT het er ook goed in gaat doen. Als er code tussen code tags staat zie ik de code niet in IE7.... als de code te breed is zie je dat mooie pijltje om toe te staan dat het codeblok breder wordt en als ik daar op klik zie ik het wel. Maar niet alle code is breed genoeg om dat pijltje te krijgen...

Blijf voorlopig dus nog wel bij FF... maar gelukkig werken steeds meer dingen goed in IE.

En de gebruikers overstap zal veel sneller gebeuren aangezien IE7 als windowsupdate op niveau Kritiek meekomt (dus automatisch geinstalleerd bij auto-update).
Ik heb zojuist - geheel tegen mijn wil en religie in - een aantal hacks ingebakken voor deze bugs in IE7...
<?xml> prolog lno longer causes quirks-mode
Daar ben ik NIET bij mee. Bij moderne browsers kun je box-model aanpassen naar border-box op bepaalde elementen. Bij IE6 kun je dat effect (globaal) verkrijgen door pagina's in quirks mode te gooien. En olee! Dat kan nu niet meer! Maar border-box, dat kent IE7 niet!

;(
Een HTML-comment voor de DTD triggered wel nog steeds quirksmode, en IE ondersteund sowieso nog geen XHTML dus die voer je het beste HTML ;)

Maar zo lastig is het toch niet om gewoon met het W3C boxmodel te werken?
Ik ben op dit moment bezig met een interne webapplicatie waarbij het design vol met 100% height elementen zit, die dan ook nog eens een padding in pixels krijgen en her en der wat scrollbars gebruiken.

Dan ben je toch erg blij dat je in CSS 3 van box-model kan veranderen voor die specifieke elementen die het nodig hebben.
ik develop op men werk een soort van front end voor machinebesturing puur gebaseerd op xml, xhtml en css voor een activex component die bestaatuit de IE activex control en wat macro's.
Je kan je echt niet voorstellen hoeveel problemen je hebt met ie6 zeker als je dan nog eens vanaf marketing 500+ png files krijgt :)
je weet dat er een activeX control is die prcies het zelfde kan en doet als de IE control alleen dan met de gecko engine?

ik meende dat ie mozcontrol oid heette wordt op dit moment vooral in wine veel gebruikt

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True