Verschillende browsers; wat een HEL! - Softwareontwikkeling

woensdag 17 december 2008 02:40

Acties:

0 Henk 'm!

Topicstarter

Ik ben een freelance webdesigner. Ondertussen heb ik al een flinke kennis opgedaan met over web-development (html,css,php,asp,mysql,js,MVC) kortom, het wel bekende rijtje.

Zoals vele mede-collega's en hobbyisten heb ik we te maken met een scala aan techische problemen en uitdagingen, dat maakt het ook zo leuk.

Ik al heel lang bekend met het feit dat verschillende browsers anders reageren op een stukje code. Mede hierdoor ben ik me gaan verdiepen in het werken volgens de 'standaarden'. Bijvoorbeeld door de W3C validator consequent te gebruiken, de structuur gescheiden houden van de opmaak, en zelfs het MVC principe te leren. Verder kijk ik tijdens het onwikkel proces continue naar het resultaat van mijn gemaakte wijzigenen (veranderen, F5, veranderen, F5, etc). Hierdoor probeer ik direct de gevolgen van mijn wijzigingen te zien, en op te lossen.

Steeds vaker merk ik dat sommige problemen die zich voordoen bij de weergave van mijn creatie in verschillende browsers (IE, Firefox, Opera, etc) die voor mij nog niet te verklaren zijn. Ik heb hiervoor een heel simpel testje gemaakt om het probleem te illustreren.

W3C Check;
"This document was successfully checked as XHTML 1.0 Strict!"

De code;
De php-tag is wellicht verwarrend, maar ik weet niet hoe ik via UBB-codes op een goeie manier HTML kan invoeren op het forum. aangepast

HTML:

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

    <head>

        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
        <title>CSS / TEST</title>

        <!-- <link  rel="stylesheet" type="text/css" href="http://developer.yahoo.com/yui/build/reset/reset.css" /> -->
    
        <style type="text/css">
            .container {
                width:400px;
                background-color:#ff0000;
                padding:0 0 10px 0;
                margin:0;
            }
        </style> 
    
    </head>
    
    <body>
    
        <div class="container">
    
            <p>CSS browser test</p>
    
        </div>
    
    </body>

</html>

Het resultaat;

Afbeeldingslocatie: http://playmp.com/browsers.png

Je zou denken dat je eerst een 'reset' css file moet gaan laden om dit probleem op te lossen. Bijvoorbeeld die van het Yahoo Developer Network. (http://developer.yahoo.com/yui). Helaas blijft het resultaat van de browser dan exact hetzelfde.

Wat doe ik nog fout? Hoe kan ik zulke simpele problemen in de toekomst makkelijk oplossen?

woensdag 17 december 2008 02:59

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

DutchStoner schreef op woensdag 17 december 2008 @ 02:40:
De php-tag is wellicht verwarrend, maar ik weet niet hoe ik via UBB-codes op een goeie manier HTML kan invoeren op het forum.

Lees dan even code tags

Je probleem zit 'm (zo op 't oog) in het <p> element. Die zal by default andere paddings/margins hebben. Als je de container div leeg laat (of enkel tekst zonder een <p> element er in) zal het wel goed gaan neem ik aan.

Voor dit soort zaken moet je gewoon even logisch testen en proberen; dingen weglaten en zien of het helpt en je goed realiseren dat sommige elementen onder verschillende browsers verschillende eigenschappen zullen hebben. En natuurlijk kan een beetje webdevver niet zonder zaken zoals (bijv.) een web developer toolbar of andere add-ons waarmee je in no-time gevonden hebt waar het probleem zit (even outline block elements doen en klaar).

[ Voor 41% gewijzigd door RobIII op 17-12-2008 03:02 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 17 december 2008 03:00

Acties:

0 Henk 'm!

soulrider

ik merk schijnbaar al een verschil in lettertype en letterhoogte.
Als je dit aan de browser overlaat bestaat er inderdaad de kans dat het misloopt.
probeer eens met die vast in te stellen?

Heb je bv ook al eens gekeken met firebug in FF?
(geeft mooi grafisch weer hoe je margins en paddings lopen in je elementen)

en als ik je p-tags weglaat in de code die je hier neerzet, dan geven ze exact hetzelfde weer.
waarschijnlijk verklaarbaar doordat FF en opera een whiteline gaan invoegen en vandaar de padding toepassen, terwijl IE het van de echte tekst doet...

code:

1	p { margin:0;}

invoegen lost het bij mij bv al op....
dus om 1 of andere reden voegen zowel firefox als opera een extra margin in bij een p-tag ...
(en met firebug is het ook perfect zichtbaar dat die p-tag zorgt voor een extra regel witruimte - standaard gedrag wegens 'p=alinea en dus witregel extra nodig' ?)

mmm beetje spuit 11, maar toch ook wat extra info

[ Voor 25% gewijzigd door soulrider op 17-12-2008 03:10 ]

woensdag 17 december 2008 03:14

Acties:

0 Henk 'm!

DutchStoner

Topicstarter

Ik zie inderdaad dat het bij dit voorbeeld heeft te maken met het <P> element. Daarom wellicht een fout voorbeeld om te gebruiken. Maar één vraag blijft overeind.

"W3C Develops Web Standards and Guidelines" NIET dus?

(Microsoft, Mozilla & Opera zijn allemaal leden van deze club (http://www.w3.org/Consortium/Member/List)

Moeten we deze W3C test nog wel serieus nemen en moeten we als developers andere alternatieven gaan zoeken?

@RobIII

bedankt voor de web developer toolbar

[ Voor 45% gewijzigd door DutchStoner op 17-12-2008 03:45 ]

woensdag 17 december 2008 03:17

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

DutchStoner schreef op woensdag 17 december 2008 @ 03:14:
"W3C Develops Web Standards and Guidelines" NIET dus?

Moeten we deze W3C test nog wel serieus nemen en moeten we als developers andere alternatieven gaan zoeken?

Wél dus. Het wel/niet valid zijn van je document heeft werkelijk geen drol te maken met hoe je document gerenderd wordt door een browser. De validatie controleerd gewoon op well formedness van je (X)HTML (dus; netjes geopende tags sluiten, bepaalde elementen mogen niet genest worden in andere, bepaalde elementen zijn 'verplicht' in een document enz. enz.).

Dat browservendors verschillende interpretaties op die standards en guidelines nahouden heeft gewoon te maken met a) niet altijd 100% waterdicht zijn van de specificaties, b) technische imperfecties, c) vendors die gewoon doen waar ze zin in hebben omdat ze toch het grootste marktaandeel hebben

[ Voor 59% gewijzigd door RobIII op 17-12-2008 03:21 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 17 december 2008 03:21

Acties:

0 Henk 'm!

soulrider

het is en blijft een adviserende organisatie... ('guidlines'

)

trouwens hier staat toch netjes dat bedrag omschreven ?
http://www.w3.org/TR/html401/struct/text.html#h-9.3.5

enkel kiest IE ervoor geen whitespace toe te voegen en FF en opera wel...

TS: zou moeten, maar zolang het geen regels zijn, doet iedere browser-maker nog steeds wat ie wilt ...
en als ze al een groot markt-aandeel hebben, kunnen ze die guidlines wat in hun eigen richting duwen,
(we volgen ze maar doen het net wat anders ...) terwijl kleine spelers weinig inspraak hebben en achterna mogen lopen.

En zoals je merkt: totale controle krijg je net via die css. p.margin=0 lost het op.
maw: je eigen fout dat je het aan de browser overlaat.
wat als ik in mijn IE instel dat alle tekst in 50px. moet komen? dan is je container nog groter...
(gebruiksvriendelijkheid en vooral toegankelijkheid even buiten spel gelaten)
wil je perfecte controle over 't uitzicht van je site, dan ga je wat standaard gaten mogen dichten

[ Voor 89% gewijzigd door soulrider op 17-12-2008 03:31 ]

woensdag 17 december 2008 03:22

Acties:

0 Henk 'm!

DutchStoner

Topicstarter

@RobIII

Ik snap heel goed wat je bedoeld. Maar zou het niet zo moeten zijn dat als je alle regeltjes volgt die er zijn opgesteld (dus W3C correct), de opmaak in iedere browser hetzelfde moet zijn? Of zijn daar weer andere / of zelfs geen standaarden/afspraken over gemaakt? De W3C gaat toch ook over CSS (http://www.w3.org/Style/CSS/)

Of de W3C alleen maar gebruiken voor een correcte code opmaak, en de interpretatie van deze code maar overlaten aan de browsers zelf? En dus testen met een virtual machine installatie van alle mogelijke browsers... waanzin!

Bedenk eens hoe zich dat met de aankomende ontwikkelingen gaat uitpakken? Internet op (console, telefoon, tv, vliegtuig, linux, apple, pc, subnotebook, pda, mda, tomtom, fiets, etc). Je zal een team moeten hebben om zoiets te kunnen realiseren.

[ Voor 43% gewijzigd door DutchStoner op 17-12-2008 03:33 ]

woensdag 17 december 2008 03:26

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

DutchStoner schreef op woensdag 17 december 2008 @ 03:22:
Ik snap heel goed wat je bedoeld. Maar zou het niet zo moeten zijn dat als je alle regeltjes volgt die er zijn opgesteld (dus W3C correct), de opmaak in iedere browser hetzelfde moet zijn?

Welcome in the real world, waar perfectie enkel een nobel streven is

In een utopische perfecte wereld misschien, maar we hebben nog een lange weg te gaan zoals je inmiddels zelf ondervonden hebt. Bedenk dat veel browsers al ontstonden toen die guidelines nog maar amper bestonden en nog zélf behoorlijk aan verandering onderhevig waren en veel browsers dus een historische rugzak aan crap meesleuren en zelfs browsers die vrij recent pas zijn ontstaan kunnen lang niet altijd 100% aan de specificaties voldoen. Los van het feit dat de specificaties zélf niet altijd perfect zijn of hiaten bevatten. Shit happens. Live with it.

Daarbij ben je als browservendor niet verplicht je aan die specificaties te houden. Het is wel zo fijn als iedereen dat zou doen, maar er is niemand die je verbiedt (of kan verbieden) er van af te wijken en er is al helemaal geen instantie die daarvoor (bijv.) boetes zou opleggen of iets dergelijks. En thank God for that overigens, dat zou helemaal te gek worden en dan bleef er geen browser over

Tot slot: Het W3C is overigens ook niet 's werelds snelste of vooruitstrevendste organisatie; als het aan hen lag en browservendors het W3C tempo hadden aangehouden zaten we nu nog in het stenen tijdperk.

[ Voor 30% gewijzigd door RobIII op 17-12-2008 03:40 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 17 december 2008 03:51

Acties:

0 Henk 'm!

DutchStoner

Topicstarter

RobIII schreef op woensdag 17 december 2008 @ 03:26:
vendors die gewoon doen waar ze zin in hebben omdat ze toch het grootste marktaandeel hebben

De standaarden zijn blijkbaar niet genoeg uitgewerkt om tot een gelijke interpretatie te komen, maar er moet iets aan gedaan worden. Waarom is een of andere patch voor een excotisch beveiligingslek wel per direct op te lossen, en zoiets niet? Wat zijn de belangen? Waarom willen browsers zo stellig hun eigen interpretatie als 'superieur' zien? Waarom buigt firefox niet voor de interpretatie van IE, of andersom? (backward-compatibility is technisch op te lossen).

maw. is firefox, opera, chrome, etc fouter dan IE in deze discussie? Negeren de concurenten van de grote reus bewust de meest gebruikte interpretatie?

Het lijkt erop dat deze 'underdogs' het voordeel van de twijfel krijgen door het vooroordeel 'zich wel aan de standaard te houden' en MS 'zich niet aan de standaard te houden'.? Terwijl deze standaarden dus niet veel voorstellen ("well formedness van je (X)HTML"), en dus (blijkt) door iedere browser goed mee wordt omgegaan.

Is MS toch niet zo schuldig aan deze waanzin als we soms denken?

(en geloof me, ik ben geen MS fanboy).

[ Voor 74% gewijzigd door DutchStoner op 17-12-2008 04:36 ]

woensdag 17 december 2008 04:42

Acties:

0 Henk 'm!

soulrider

effe een quote uit de link die ik hierboven postte:

HTML user agents have traditionally rendered paragraphs with white space before and after, e.g.,
....
Following the precedent set by the NCSA Mosaic browser in 1993, user agents generally don't justify both margins, in part because it's hard to do this effectively without sophisticated hyphenation routines. The advent of style sheets, and anti-aliased fonts with subpixel positioning promises to offer richer choices to HTML authors than previously possible.

Style sheets provide rich control over the size and style of a font, the margins, space before and after a paragraph, the first line indent, justification and many other details. The user agent's default style sheet renders P elements in a familiar form, as illustrated above. One could, in principle, override this to render paragraphs without the breaks that conventionally distinguish successive paragraphs. In general, since this may confuse readers, we discourage this practice.

maw: FF en opera houden zich net aan de oude gewoonte, terwijl IE ermee breekt.
Nu is het natuurlijk de vraag: wie moet wie gaan volgen, en wie moet zich 'aan de traditie' houden

Maar als je dan ook nog gaat rekening houden met IE8, dan merk je toch dat MS terugkomt van de eigen standaarden (en meer de algemene standaard gaat volgen), en toch meer een groepsspeler wordt.
enkel zitten zij nu verveeld met hun legacy, en webdesigners gaan veel 'if IE>7 and IE<8' moeten gaan toepassen in de toekomst.

woensdag 17 december 2008 07:27

Acties:

0 Henk 'm!

Zakkenwasser

en webdesigners gaan veel 'if IE>7 and IE<8' moeten gaan toepassen in de toekomst.

Ik geloof dat als je semantisch schrijft, en css ook goed schrijft, dat je een perfecte website kunt maken die op iedere browser werkt.
Ja, zelfs zonder hacks, want hacks is meer werk als er een nieuwe browser uitkomt.

We moeten die hacks vergeten, en gewoon netjes schrijven.

PSP 1000 @ 6.60 Pro C2 [+256GB]
PSVita @ Henkaku Enso [+256GB]
3DS @ Luma (B9S) [+160GB]
Nintendo Switch 3.0.1 [+256GB]

woensdag 17 december 2008 08:23

Acties:

0 Henk 'm!

soulrider

MrJey schreef op woensdag 17 december 2008 @ 07:27:
[...]

Ik geloof dat als je semantisch schrijft, en css ook goed schrijft, dat je een perfecte website kunt maken die op iedere browser werkt.
Ja, zelfs zonder hacks, want hacks is meer werk als er een nieuwe browser uitkomt.

We moeten die hacks vergeten, en gewoon netjes schrijven.

er zijn verschillende reden waarom hacks nodig zijn soms ( :hover en soortgelijken zijn al voorbeelden )
oke kan ook met js (mouseover, mouseout) maar ook dat is een hack eh

(js gaan toepassen waar css al zou moeten voldoen)

net als de min-height bij vaux-colums... maar zo kunnen er wel voor- en tegen-voorbeelden gegeven worden.
werken: ja, correct werken en telkens hetzelfde beeld geven: nee
(bekendste voorbeeld: die browser-css-test ...)

tegenvoorbeeld: code van TS: semantisch geschreven html en css, en toch verschil in weergave.
enkel is zijn css niet 'strict' genoeg om eenzelfde weergave te waarborgen, wederom door verschillend default gedrag bij zelfde elementen zonder een door dev'er bepaalde style.

tegenvoorbeeld: flat html met weinig css doet het ngo steeds natuurlijk

(T.net heeft wrs ook genoeg hacks in hun css om correct te werken in bijna alle browsers - in IE op mobile windows in 320x240 of 240x320 formaat is bv niets zichtbaar van de nieuwsposts op de frontpage - in opera mini werkt alles zoals het hoort ... buiten aanmelden op 't forum)

maar mijn voorbeeld was vooral om aan te geven dat IE het bv al moeilijk maakt om een site die perfect werkt in een oude versie nog steeds perfect te laten werken in de nieuwere versie (vooral met IE8) - waar dat met FF, opera en dergelijken een pak makkelijker is wegens betere volging van algemene richtlijnen - waar MS zijn eigen standaarden wel eens wilt aanpassen tss versie's door... en dev'ers er maar achter moeten komen door eigen testen en/of door klachten van bezoekers...

maar goed dit kan nog een devschuur (of move naar SG?) discussie worden over browsers, en we weten allemaal hoe die uitdraaien: heen-en-weer flamming en ieder blijft bij zijn favo-browser.
(ben zelf eentje die regelmatig wisselt van browser en vooral van IE naar FF en terug)

[ Voor 46% gewijzigd door soulrider op 17-12-2008 08:42 ]

woensdag 17 december 2008 09:57

Acties:

0 Henk 'm!

mieJas

Ja, maar nee.

soulrider schreef op woensdag 17 december 2008 @ 04:42:
'if IE>7 and IE<8'

IE 7.5 ?

Yes, but no.

woensdag 17 december 2008 10:31

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

De subtitel van mijn weblog zegt het toch al?

Browsers are from Hell, standards suck

Intentionally left blank

woensdag 17 december 2008 12:10

Acties:

0 Henk 'm!

wackmaniac

DutchStoner schreef op woensdag 17 december 2008 @ 03:51:
[...]

De standaarden zijn blijkbaar niet genoeg uitgewerkt om tot een gelijke interpretatie te komen, maar er moet iets aan gedaan worden. Waarom is een of andere patch voor een excotisch beveiligingslek wel per direct op te lossen, en zoiets niet? Wat zijn de belangen? Waarom willen browsers zo stellig hun eigen interpretatie als 'superieur' zien? Waarom buigt firefox niet voor de interpretatie van IE, of andersom? (backward-compatibility is technisch op te lossen)

Moeten de browservendors van jou ook alle knoppen gelijk gaan opmaken? Moeten alle browsers alle lettertypen ondersteunen? Dit is natuurlijk met een goede reset css makkelijk op te lossen. Dat doe ik al jaren en werkt als een trein. Ik zal de laatste zijn die zegt dat browsers zich allemaal keurig aan de standaarden houden, maar de marges van een paragraaf behoort gewoon niet tot de standaard naar mijn mening.

Read the code, write the code, be the code!

woensdag 17 december 2008 15:12

Acties:

0 Henk 'm!

soulrider

mieJas schreef op woensdag 17 december 2008 @ 09:57:
[...]

IE 7.5 ?

IE 7.0.x.x

(en met dat die laatste 2 altijd >0 zijn klopt mijn vergelijking )

http://www.google.be/search?hl=nl&q=if+IE+%3E7&meta=
ps: ik zeg ook nergens dat het op 1 regel (of gelijktijdig) moet gebruikt worden eh...
(enkel dat er extra filteringen gaat moeten gebeuren in css voor IE)
vooral voor de css-hacks die soms nodig zijn voor IE 7 en voorgangers die niet meer nodig zijn bij IE8
en dan moet je gaan spelen met [if IE lt 8] en/of [if IE 6],[if IE 7]-tags....

woensdag 17 december 2008 15:25

Acties:

0 Henk 'm!

mozinator

Dit soort problemen kun je oplossen met projecten zoals Google Web Toolkit, of Microsoft Volta.
Ellende met Internet Explorer 5 en 6 kun je oplossen met het zogenaamde /IE7 script: http://dean.edwards.name/IE7/
CSS Ellende kun je gedeeltelijk oplossen met het zogenaamde CSS reset script: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/

donderdag 18 december 2008 16:45

Acties:

0 Henk 'm!

moozzuzz

De eerste vraag die je je moet stellen is natuurlijk of deze verschillen een probleem vormen voor je uiteindelijke product (website, webapp, ...). Wat mi teveel vergeten wordt is dat webcontent niet aan dezelfde regels hoeft te voldoen dan printed content en dan vooral het gedeelte pixelperfectness.

Goeie kleurencombi, leesbare font en structuur zijn mi voldoende. Kijk naar Google en Facebook. De websites zijn niet meteen voorbeelden van pixelperfectie.

donderdag 18 december 2008 17:13

Acties:

0 Henk 'm!

Boelie-Boelie

Bovendien ben jij waarschiijnlijk de enige die het echt opvalt dat het niet bij elke browser tot op de pixel precies zit, want er is verder niemand die jouw site gaat vergelijken in meerdere browsers. En ook al valt het iemand op (bijv. verschil browser thuis vs. werk), dan nog gaat het de bezoeker er slechts om dat de site gewoon werkt, er vertrouwd uitziet en niet uit elkaar valt. Bezoekers vinden pixelverschillen pas boeiend als het ervoor zorgt dat ze worden gehinderd in waar ze voor kwamen.

Cogito ergo dubito

vrijdag 19 december 2008 11:07

Acties:

0 Henk 'm!

CMG

mozinator schreef op woensdag 17 december 2008 @ 15:25:
Dit soort problemen kun je oplossen met projecten zoals Google Web Toolkit, of Microsoft Volta.
Ellende met Internet Explorer 5 en 6 kun je oplossen met het zogenaamde /IE7 script: http://dean.edwards.name/IE7/
CSS Ellende kun je gedeeltelijk oplossen met het zogenaamde CSS reset script: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/

Dat IE7 project is wel interessant, ga ik meteen even testen op mijn site (Werkt prima in FF en IE7 maar is een ramp in IE6. Als het werkt zoals geadverteerd, dan zou dit geweldig zijn

)

NKCSS - Projects - YouTube

vrijdag 19 december 2008 11:12

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

CMG schreef op vrijdag 19 december 2008 @ 11:07:
[...]

Dat IE7 project is wel interessant, ga ik meteen even testen op mijn site (Werkt prima in FF en IE7 maar is een ramp in IE6. Als het werkt zoals geadverteerd, dan zou dit geweldig zijn )

Dean's IE7 is een leuke effort, maar op een site met enige complexiteit heeft het erg nadelige gevolgen voor de performance in IE6 (die toch al niet zo best is). Ik ben meer voor gracefull degradation.

Intentionally left blank

vrijdag 19 december 2008 11:25

Acties:

0 Henk 'm!

CMG

crisp schreef op vrijdag 19 december 2008 @ 11:12:
[...]

Dean's IE7 is een leuke effort, maar op een site met enige complexiteit heeft het erg nadelige gevolgen voor de performance in IE6 (die toch al niet zo best is). Ik ben meer voor gracefull degradation.

Is er een betere IE6 PNG Transparancy fix + position fixing? Ben Virtual PC nog aan installen om te kijken wat het resultaat is, maar als jij een betere oplossing weet is dat altijd fijn natuurlijk.

NKCSS - Projects - YouTube

vrijdag 19 december 2008 11:28

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

CMG schreef op vrijdag 19 december 2008 @ 11:25:
[...]

Is er een betere IE6 PNG Transparancy fix + position fixing? Ben Virtual PC nog aan installen om te kijken wat het resultaat is, maar als jij een betere oplossing weet is dat altijd fijn natuurlijk.

Gewoon geen semi-transparante images/backgrounds gebruiken voor IE6; ziet er minder mooi uit maar is een voorbeeld van gracefull degradation.

Intentionally left blank

vrijdag 19 december 2008 11:31

Acties:

0 Henk 'm!

Kiphaas7

@CMG: Daarbij is het png32 waar de problemen mee zijn, niet png8. Google maar.

[ Voor 3% gewijzigd door Kiphaas7 op 19-12-2008 11:31 ]

vrijdag 19 december 2008 11:32

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Kiphaas7 schreef op vrijdag 19 december 2008 @ 11:31:
@CMG: Daarbij is het png32 waar de problemen mee zijn, niet png8. Google maar.

Maar voor semi-transparantie heb je wel png32 nodig, png8 kan alleen maar volledige transparantie net zoals gif

Intentionally left blank

vrijdag 19 december 2008 11:49

Acties:

0 Henk 'm!

CMG

Het is misschien niet zo netjes, maar ik heb gewoon besloten versies ouder dan IE7 van de site te weren en ze te verwijzen naar een download voor IE7. Misschien dat ik op een later moment de site opnieuw ontwerp en zorg dat ook de oude browsers en nog leuk uit zien, maar nu is de site gewoon niet functioneel door de CSS die ik gebruik. Dan kun je beter niets tonen dan een gebroken site :-/

Bijna vergeten: Dat IE7 project zorgde alleen maar voor meer problemen ipv wat op te lossen, dus die is meteen weer weggehaald

[ Voor 14% gewijzigd door CMG op 19-12-2008 11:50 ]

NKCSS - Projects - YouTube

vrijdag 19 december 2008 11:55

Acties:

0 Henk 'm!

MBV

Anders doe je voor IE6 een rigoreuze degradation: om je CSS en Javascript-blokken zoiets zetten:

HTML:

<!--[if gte IE7] -->
<script ...></script>
<style ...></style>
<!---[endif]-->
<!--[if lte IE6]-->
Download een nieuwe browser! IE7, of nog liever Firefox!
<!--[endif]-->

Gevolg: mensen kunnen alle inhoud van je site lezen, zonder fancy opmaak. En de versie zonder CSS was uiteraard toch al goed te lezen, om mensen met screen-readers van dienst te zijn

vrijdag 19 december 2008 12:05

Acties:

0 Henk 'm!

CMG

MBV schreef op vrijdag 19 december 2008 @ 11:55:
Anders doe je voor IE6 een rigoreuze degradation: om je CSS en Javascript-blokken zoiets zetten:
HTML:
1
2
3
4
5
6
7

<script ...></script>
<style ...></style>


Download een nieuwe browser! IE7, of nog liever Firefox!

Gevolg: mensen kunnen alle inhoud van je site lezen, zonder fancy opmaak. En de versie zonder CSS was uiteraard toch al goed te lezen, om mensen met screen-readers van dienst te zijn

Nah, dat is ook weer erg negatief (IMHO).

Het probleem gaat vooral om positioning en transparency, hier een voorbeeld:

Afbeeldingslocatie: http://www.buyinbulk.nl/images/voorbeeld.jpg

Afbeeldingslocatie: http://www.buyinbulk.nl/images/voorbeeld.jpg

Die blauwe 'sterren' zijn scherp uitgesneden en transparant zodat ik ze ergens 'overheen' kan leggen, hierdoor krijg je een speelse look. De buy/notify icons rechts onder zijn absolute positioned binnen een relative positioned div, dit gaat in IE6 niet echt goed.

NKCSS - Projects - YouTube

vrijdag 19 december 2008 12:08

Acties:

0 Henk 'm!

Da Weef

Is er een betere IE6 PNG Transparancy fix + position fixing? Ben Virtual PC nog aan installen om te kijken wat het resultaat is, maar als jij een betere oplossing weet is dat altijd fijn natuurlijk.

Er zijn heel wat PNG fixes die zeer eenvoudig zijn in te passen en waarbij prestaties acceptabel zijn. Echter gaat mijn voorkeur ook uit naar gracefull degradation met gifs.
Principieel vind ik het tegenstrijdig om juist machines die IE6 draaien te belasten met allerlei excessieve scripts. Iemand die werkt met IE6 hecht vast niet meer waarde aan een perfect strakke lay-out dan aan prestaties.

.

vrijdag 19 december 2008 12:11

Acties:

0 Henk 'm!

MBV

CMG schreef op vrijdag 19 december 2008 @ 12:05:
[...]

Nah, dat is ook weer erg negatief (IMHO).

En dat is beter dan mensen wegsturen om ze een betere browser te laten downloaden?

Het probleem gaat vooral om positioning en transparency, hier een voorbeeld:

[afbeelding]

Die blauwe 'sterren' zijn scherp uitgesneden en transparant zodat ik ze ergens 'overheen' kan leggen, hierdoor krijg je een speelse look. De buy/notify icons rechts onder zijn absolute positioned binnen een relative positioned div, dit gaat in IE6 niet echt goed.

Transparantie heb ik op http://mvdvlist.nl een simpele oplossing voor.
En met een beetje hacken krijg je elke positioneringsbug wel ongeveer goed, dus dan zou ik dat gewoon fixen (met een aparte CSS waarin alle IE6-hacks staan).

vrijdag 19 december 2008 12:12

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Iemand die IE6 draait heeft geen idee waar ie mee bezig is en dat er nieuwere/andere browsers zijn. Dat heeft niets van doen met z'n wens om een site goed te bekijken.

Dat daargelaten hebben wij ook al een keer in samenspraak met een klant een hele sectie van een site IE6-disabled met "Download hier of hier een nieuwe browser, deze sectie werkt niet in je verouderde mormel". Sommige dingen kunnen gewoon niet.

[ Voor 4% gewijzigd door curry684 op 19-12-2008 12:13 ]

Professionele website nodig?

vrijdag 19 december 2008 12:14

Acties:

0 Henk 'm!

CMG

curry684 schreef op vrijdag 19 december 2008 @ 12:12:
Iemand die IE6 draait heeft geen idee waar ie mee bezig is en dat er nieuwere/andere browsers zijn. Dat heeft niets van doen met z'n wens om een site goed te bekijken.

Dat daargelaten hebben wij ook al een keer in samenspraak met een klant een hele sectie van een site IE6-disabled met "Download hier of hier een nieuwe browser, deze sectie werkt niet in je verouderde mormel". Sommige dingen kunnen gewoon niet.

Same here, een arbodienst systeem, mochten we ontwikkelen voor IE7+ only. Hij werd wel gedisplayed, maar je kreeg een mooie gele balk boven in met het verzoek tot upgraden en de melding dat sommige dingen niet helemaal correct worden weergegeven.

NKCSS - Projects - YouTube

vrijdag 19 december 2008 12:45

Acties:

0 Henk 'm!

DJ Henk

DutchStoner schreef op woensdag 17 december 2008 @ 03:22:
@RobIII

Ik snap heel goed wat je bedoeld. Maar zou het niet zo moeten zijn dat als je alle regeltjes volgt die er zijn opgesteld (dus W3C correct), de opmaak in iedere browser hetzelfde moet zijn?

Nee, dat is niet de bedoeling van die regeltjes.

En je geeft zelf al aan waarom:

Bedenk eens hoe zich dat met de aankomende ontwikkelingen gaat uitpakken? Internet op (console, telefoon, tv, vliegtuig, linux, apple, pc, subnotebook, pda, mda, tomtom, fiets, etc). Je zal een team moeten hebben om zoiets te kunnen realiseren.

Zoals al een beetje gezegd hierboven: html en css verschillen van print op papier. Het wereldwijde web bestaat uit een enorme diversiteit van van computers en systemen, waar veel verschillen tussen zitten. Zowel qua formaat, als qua technische mogelijkheden. In tegenstelling tot drukwerk weet je niet hoe groot het papier is waarop je schrijft en je weet ook niet hoe groot de letters zijn. Het is onmogelijk om in die situatie pixelperfect te werken. (Of eigenlijk, dat kan wel, maar dan krijg je een www van PDF-bestanden.)

Html + css is dus een manier om juist flexibel met opmaak om te kunnen gaan. Heb je een grotere monitor -> de layout kan meerekken en als het goed is precies zover als dat het er nog prettig uitziet. Ben je slechtziend (of ondersteunt je laptop alleen een achterlijke resolutie) -> stel een groter lettertype in en de opmaak van de pagina schaalt probleemloos mee.

Wil je toch die pixelperfecte controle, dan zul je dus zelf alles vast moeten zetten, van marges tot lettertypes en niets aan de client overlaten. Of je maakt gewoon een PDF-bestand. Maar dat heeft dus ook onverstandige kanten, want je kent de situatie aan de clientkant misschien wel helemaal niet. Aan de andere kant willen, bijvoorbeeld, meer marketinggerichte types juist zoveel mogelijk sturen. Ze willen 'controle over de gebruikerservaring'.

Goed webdesign is de kunst van de juiste middenweg hierin vinden. En dat betekent vaak dat je je niet druk moet maken over een marge die enkele pixels dikker is in een andere browser.

vrijdag 19 december 2008 13:35

Acties:

0 Henk 'm!

xzaz

Ik zit nog altijd met PNG en IE6. Heeft er iemand ervaringen met projecten die dit ondersteunen en ook makkelijk implementeerbaar zijn zonder een hele framework te moeten installeren. Ik heb diverse scripts getest maar zijn of niet functioneel of 't kost gewoon te veel tijd om ze te installeren.

Schiet tussen de palen en je scoort!

vrijdag 19 december 2008 13:43

Acties:

0 Henk 'm!

MBV

ehm, zoals ik het op mijn website (www.mvdvlist.nl) heb gedaan?

Cascading Stylesheet:

.png {
  behavior: url(/layout_elements/ie-png.htc);
    -ie-png-blankimage: url(/layout_elements/blank.gif);
}

en dan alles waar een PNG in voorkomt (background-image o.i.d.) de klasse PNG meegeven. Eventueel kan je hier een opsomming van classes maken waarvoor het geldt. Werkt bij mijn weten prima, alleen wordt de behaviour pas uitgevoerd na de weergave van het oorspronkelijke plaatje. Dit was 2 jaar geleden nog prima te vinden met de zoekfunctie

[ Voor 7% gewijzigd door MBV op 19-12-2008 13:44 ]

zaterdag 20 december 2008 00:57

Acties:

0 Henk 'm!

Verwijderd

Da Weef schreef op vrijdag 19 december 2008 @ 12:08:
[...]
Principieel vind ik het tegenstrijdig om juist machines die IE6 draaien te belasten met allerlei excessieve scripts. Iemand die werkt met IE6 hecht vast niet meer waarde aan een perfect strakke lay-out dan aan prestaties.

Waarbij toch de afweging moet worden gemaakt, hoeveel van het marktaandeel van IE6 (ca 22%) veroorzaakt wordt door bedrijven met snelle pc's, die om redenen van brakke intranetten niet willen upgraden.

zaterdag 20 december 2008 00:59

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Verwijderd schreef op zaterdag 20 december 2008 @ 00:57:
[...]

Waarbij toch de afweging moet worden gemaakt, hoeveel van het marktaandeel van IE6 (ca 22%) veroorzaakt wordt door bedrijven met snelle pc's, die om redenen van brakke intranetten niet willen upgraden.

En de afweging mbt het feit dat het aandeel van IE6 sterk afnemend is...

Intentionally left blank

zaterdag 20 december 2008 19:34

Acties:

0 Henk 'm!

Bosmonster

*zucht*

crisp schreef op zaterdag 20 december 2008 @ 00:59:
[...]

En de afweging mbt het feit dat het aandeel van IE6 sterk afnemend is...

Voor zover ik weet blijft dat aandeel momenteel juist schrikbarend gelijk.

zaterdag 20 december 2008 19:41

Acties:

0 Henk 'm!

Verwijderd

Bosmonster schreef op zaterdag 20 december 2008 @ 19:34:

Voor zover ik weet blijft dat aandeel momenteel juist schrikbarend gelijk.

Dat is exact het probleem dat met IE4 en NS4 al bestond, en met IE5, en IE5.5. En dat probleem zal altijd bestaan.

Wat nu niet in de huidige browsers werkt, zal 3 tot 5 jaar niet serieus kunnen worden toegepast als je niet een aanzienlijk deel van de bezoekers direct kwijt wilt zijn.

Dat de TS in 2008 nog over browser-hell begint, vind ik eerlijk gezegd minstens zo treurig.

zaterdag 20 december 2008 22:50

Acties:

0 Henk 'm!

Zakkenwasser

crisp schreef op woensdag 17 december 2008 @ 10:31:
De subtitel van mijn weblog zegt het toch al?

[...]

Leuke blog, alleen heb ik zo mijn twijfels over dit topic

Open je foutconsole in Mozilla Firefox maar eens.

PSP 1000 @ 6.60 Pro C2 [+256GB]
PSVita @ Henkaku Enso [+256GB]
3DS @ Luma (B9S) [+160GB]
Nintendo Switch 3.0.1 [+256GB]

zondag 21 december 2008 00:08

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

MrJey schreef op zaterdag 20 december 2008 @ 22:50:
[...]

Leuke blog, alleen heb ik zo mijn twijfels over dit topic

Open je foutconsole in Mozilla Firefox maar eens.

* crisp kijkt en ziet alleen maar stomme warnings, maar geen errors...

Intentionally left blank

zondag 21 december 2008 01:20

Acties:

0 Henk 'm!

Zakkenwasser

crisp schreef op zondag 21 december 2008 @ 00:08:
[...]

* crisp kijkt en ziet alleen maar stomme warnings, maar geen errors...

klik

[ Voor 9% gewijzigd door Zakkenwasser op 21-12-2008 01:23 ]

PSP 1000 @ 6.60 Pro C2 [+256GB]
PSVita @ Henkaku Enso [+256GB]
3DS @ Luma (B9S) [+160GB]
Nintendo Switch 3.0.1 [+256GB]

zondag 21 december 2008 02:38

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

MrJey schreef op zondag 21 december 2008 @ 01:20:
[...]

klik

Ah een error! Oh noes!
Validatie is geen doel op zich, begrijp dat goed. Validatie is een hulpmiddel en als dat met 0 "fouten" kan is het heel mooi meegenomen, maar als er zo nu en dan eens een foutje op duikt en er liggen nog 1001 andere (belangrijkere) zaken die gedaan moeten worden dan sod it. Je maakt gebruikers blijer met degelijke en goed doordachte functionaliteit; die ene error zal geen enkele doorsnee gebruiker van wakker liggen. True; 't is zo gefixed en op te lossen maar het is ook een kwestie van prioriteiten stellen. En validatie hoort geen top-prioriteit te zijn.

Edit: ah, ik zie zojuist ook je topic in LD; lees maar eens goed wat daar staat, want je 'workaround' is natuurlijk ook enkel en alleen jezelf voor de gek houden

Ik heb je overigens ook al vaker gezegd dat je wat doorslaat in alles; perfectie is mooi om na te streven en heel leuk als je toch niets beters te doen hebt ofzo maar in the real world zijn er zat zaken die nog allemaal moeten gebeuren en deadlines te halen etc. en dan kun je je écht niet altijd permitteren uren in dat soort futiliteiten te steken. Let wel: ik zeg niet dat je, omdat je deadlines hebt, maar alles overboord moet gooien om je doel te bereiken maar je moet ook helder kunnen zien wat wél belangrijk is en wat niet of minder. Ik steek persoonlijk liever wat extra tijd in XSS en SQL injection testing en dat soort zaken en natuurlijk gewoon de algemene functionaliteit die nog gebouwd moet worden en als ik me dan écht een keer verveel en tijd over heb ga ik aan akkefietjes werken zoals degene die je nu aanhaalt (en als ze zich überhaupt lonen om op te lossen; jezelf voor de gek houden is daar dus geen onderdeel van).

En vraag je zelf eens het volgende af: zie je de fout (of warning), uitgezonderd van allerlei tools die je er op wijzen, ook terug in de site? Of weet je er alleen maar van omdat die tools je er op wijzen? Want, uitgaande van een site die goed cross-browser werkt (en dat doet t.net al jaren, zo niet forever), wie heeft er dan eigenlijk 'last' van? En dan nog: is die 'fout' (of warning) ernstig genoeg om alle andere zaken te laten varen en er meteen actie op te ondernemen?

[ Voor 51% gewijzigd door RobIII op 21-12-2008 02:50 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

zondag 21 december 2008 13:15

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

MrJey schreef op zondag 21 december 2008 @ 01:20:
[...]

klik

crisp in "Tweakers faalt w3c validatie"

en verder: zie RobIII en de overige posts in bovengelinkt topic. Nogmaals: validatie is niet heilig, en specificaties zijn dat ook niet - HTML4 is immers ook al hopeloos veroudert en loopt daarmee behoorlijk achter op de werkelijkheid. Ik gebruik dan ook graag features uit HTML5/WF2 of CSS3 drafts als browsers daar ondersteuning voor bieden en het geen issues oplevert in browsers die daar (nog) geen ondersteuning voor hebben. Dat is forwards-compatible en helpt indirect juist de adoptie van dergelijke features.

[ Voor 18% gewijzigd door crisp op 21-12-2008 13:18 ]

Intentionally left blank

zondag 21 december 2008 13:36

Acties:

0 Henk 'm!

Clay

cookie erbij?

Al die verschillen tussen browsers vallen reuze mee. Het "probleem" is dat veel browsers er een verschillende basis rendering op na houden (standaard marges tussen elementen, line-heights, font-sizes etc), waardoor er inderdaad een zichtbaar verschil ontstaat als je een testcase maakt waarin je maar 2 of 3 properties verandert.

Zo'n style reset kan een handige tool zijn om dat soort dingen gelijk te trekken, maar het belangrijkste voor een developer blijft natuurlijk dat je weet - waar - die verschillen vandaan komen, en wat je daar zelf aan kan doen, voordat je alles bv plat slaat met de grote hamer:

Cascading Stylesheet:

* {
   margin:0;
   padding:0;
}

Als je je een beetje verdiept in die default styles, en wat het gedrag van verschillende properties (al dan niet in combinatie met elkaar) zou moeten zijn, dan zul je nog verbaasd zijn van hoe xbrowser pixelperfect je veel dingen kan krijgen met een paar regels css. Dan heb je die grote hamer ook niet nodig.

Instagram | Flickr | "Let my music become battle cries" - Frédéric Chopin

zondag 21 december 2008 13:49

Acties:

0 Henk 'm!

curry684

left part of the evil twins

En ik heb nog nooit iemand een steekhoudend argument horen leveren tegen die grote hamer overigens.

Professionele website nodig?

zondag 21 december 2008 16:01

Acties:

0 Henk 'm!

Clay

cookie erbij?

Maar dat je er geen display:block; bij zou moeten zetten vindt iedereen logisch, of een float

Waar komt dan die berusting vandaan dat het wel ok is om overal de margin en padding van weg te gooien? Daarna moet je ze immers gaan herstellen op alle elementen, zodat een list netjes inspringt als iemand die in een cms gebruiken wil.

Die resetters doen dit misschien voor je, maar als dit niet strookt met je huisstijl kan je alsnog specifieke styles aan gaan passen. Prima als je dit netjes doet - in zoverre is er idd niets mis mee - maar is het ook echt makkelijker, snel, leesbaar, of overdraagbaar? Je had dan net zo goed de default styles van een aantal elementen aan kunnen passen zonder de grote hamer te gebruiken.

't is wat mij betreft ook niet fout, ik geloof gewoon dat je het totaal niet nodig hebt als je even de moeite neemt om die paar verschillen in default styles uit te zoeken. Mooie code hoort gewoon kort en doeltreffend te zijn. Resets zijn geen van beide

Instagram | Flickr | "Let my music become battle cries" - Frédéric Chopin

zondag 21 december 2008 16:04

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Clay schreef op zondag 21 december 2008 @ 16:01:
Mooie code hoort gewoon kort en doeltreffend te zijn. Resets zijn geen van beide

Nou voor 3 regels code is het behoorlijk doeltreffend?

Professionele website nodig?

zondag 21 december 2008 16:06

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

curry684 schreef op zondag 21 december 2008 @ 16:04:
[...]

Nou voor 3 regels code is het behoorlijk doeltreffend?

Je bedoelt dat je verder ook nergens margins of paddings hoeft te hebben in je opmaak?

Honestly, wat is het verschil tussen:

Cascading Stylesheet:

* {
    margin: 0;
    padding: 0;
}
h1, h2, h3, h4, h5, h6, ul, p {
    margin: 0 0 10px 0;
}

en

Cascading Stylesheet:

h1, h2, h3, h4, h5, h6, ul, p {
    padding: 0;
    margin: 0 0 10px 0;
}

/simpel gezegd ?
waarbij de tweede imo vriendelijker is voor alle elementen die je in het geval van een generieke reset 'vergeten' bent alsnog margin of padding te geven. Default styling gaat om accessibility, dat wil je er niet met een hamer uitslaan en vervolgens zelf halfslachtig weer 'repareren'...

daarnaast zijn er naar mijn weten wel edge-cases waarbij je door een generieke reset bepaalde default styling niet meer goed crossbrowser kunt "repareren", denk dan aan elementen zoals input (type="xxx"), select en button.

[ Voor 65% gewijzigd door crisp op 21-12-2008 16:15 ]

Intentionally left blank

zondag 21 december 2008 22:36

Acties:

0 Henk 'm!

Verwijderd

Bosmonster schreef op zaterdag 20 december 2008 @ 19:34:
Voor zover ik weet blijft dat aandeel momenteel juist schrikbarend gelijk.

Geen idee hoe betrouwbaar deze cijfers zijn, maar als deze trend over 2008 klopt, dan gaat het best wel hard.

January, 2008	32.30%
February, 2008	30.63%
March, 2008	28.94%
April, 2008	28.71%
May, 2008	27.52%
June, 2008	26.38%
July, 2008	25.74%
August, 2008	25.17%
September, 2008	24.67%
October, 2008	23.47%
November, 2008	21.53%

Los daarvan, ik blijf erbij dat de veronderstelling, dat computers waar IE6 nog op draait in het algemeen wat ouder en trager zijn, niet klopt. Dat zijn de bedrijven. Die zorgen denk ik ook voor de – inderdaad – iets vertragende vermindering van het marktaandeel van IE6. Maar van gelijk blijven zou ik niet spreken.

zondag 21 december 2008 22:53

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Verwijderd schreef op zondag 21 december 2008 @ 22:36:
[...]

Geen idee hoe betrouwbaar deze cijfers zijn, maar als deze trend over 2008 klopt, dan gaat het best wel hard.

January, 2008 32.30%
February, 2008 30.63%
March, 2008 28.94%
April, 2008 28.71%
May, 2008 27.52%
June, 2008 26.38%
July, 2008 25.74%
August, 2008 25.17%
September, 2008 24.67%
October, 2008 23.47%
November, 2008 21.53%

Los daarvan, ik blijf erbij dat de veronderstelling, dat computers waar IE6 nog op draait in het algemeen wat ouder en trager zijn, niet klopt. Dat zijn de bedrijven. Die zorgen denk ik ook voor de – inderdaad – iets vertragende vermindering van het marktaandeel van IE6. Maar van gelijk blijven zou ik niet spreken.

Ik ken die site niet, maar als ik naar de sites kijk van een aantal van onze klanten is er over het afgelopen jaar nauwelijks verbetering zichtbaar. Neemt niet weg dat het aantal wel zou moeten dalen, gezien de verspreiding van Windows Vista en het niet meer leveren van Windows XP.

[ Voor 4% gewijzigd door Bosmonster op 21-12-2008 22:54 ]

zondag 21 december 2008 22:58

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Bosmonster schreef op zondag 21 december 2008 @ 22:53:
[...]

Ik ken die site niet, maar als ik naar de sites kijk van een aantal van onze klanten is er over het afgelopen jaar nauwelijks verbetering zichtbaar. Neemt niet weg dat het aantal wel zou moeten dalen, gezien de verspreiding van Windows Vista en het niet meer leveren van Windows XP.

Het zal zeker verschillen per site en de demografie van de bezoekers van deze sites. Hier op Tnet zien we het aandeel IE6 hard achteruit hollen (momenteel onder de 10% als ik het goed heb, tegenover nog ruim 20% begin van dit jaar).

Edit: even gechecked in Analytics: in januari was het aandeel IE6 nog 17,6%, momenteel (laatste 30 dagen) nog maar 9,1%. Ik zal nog even kijken hoe de afname-trend precies is

Edit2:

Maand	IE6 aandeel Tnet
Jan	17.65%
Feb	16.44%
Mar	14.97%
Apr	14.11%
May	13.04%
Jun	12.79%
Jul	12.29%
Aug	11.69%
Sep	11.08%
Oct	10.25%
Nov	9.45%

gestaag dus, en nog geen noemenswaardige afvlakking van de afname... Hoewel het aandeel IE(6) dus wel substantieel lager is op Tweakers.net (altijd al geweest) in vergelijking met meer mainstream-sites is de trend toch ongeveer gelijkend met de cijfers die BARTdG heeft gepost.

[ Voor 43% gewijzigd door crisp op 21-12-2008 23:37 ]

Intentionally left blank

maandag 22 december 2008 08:30

Acties:

0 Henk 'm!

Woudloper

« - _ - »

Voor wat betreft het gebruik van IE6 zijn er helaas diverse bedrijven (inclusief het bedrijf waar ik momenteel voor werk, en dat ik geen kleintje) dit nog gebruik maken van deze browser in verband met het feit dat diverse applicaties onder IE7 niet meer goed functioneren en ze vervolgens afhankelijk zijn van fixes (van de leveranciers), (interne/externe) releasekalenders, etc.

maandag 22 december 2008 08:41

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Woudloper schreef op maandag 22 december 2008 @ 08:30:
Voor wat betreft het gebruik van IE6 zijn er helaas diverse bedrijven (inclusief het bedrijf waar ik momenteel voor werk, en dat ik geen kleintje) dit nog gebruik maken van deze browser in verband met het feit dat diverse applicaties onder IE7 niet meer goed functioneren en ze vervolgens afhankelijk zijn van fixes (van de leveranciers), (interne/externe) releasekalenders, etc.

Tsja, helaas hebben veel bedrijven zich laten verleiden tot een lock-in door leveranciers die tot op heden nog steeds niet het besef hebben dat er meer is dan IE6 en blijkbaar dus niet in staat zijn met de tijd mee te gaan - hoe oud is IE6 nu? En hoe lang bestaan er al alternatieve browsers?

IE7 is inmiddels ook alweer ruim een jaar oud, en sec gezien hebben leveranciers zelfs al 2 jaar de tijd gehad om hun producten IE7-ready te maken. Als ze dat met IE8 op komst nog steeds niet zijn dan zou ik ondertussen toch wel vraagtekens gaan zetten bij de competentie van die software leverancier...

Intentionally left blank

maandag 22 december 2008 09:16

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Bosmonster schreef op zondag 21 december 2008 @ 22:53:
[...]

Ik ken die site niet, maar als ik naar de sites kijk van een aantal van onze klanten is er over het afgelopen jaar nauwelijks verbetering zichtbaar. Neemt niet weg dat het aantal wel zou moeten dalen, gezien de verspreiding van Windows Vista en het niet meer leveren van Windows XP.

Bij de meest "noob-gevoelige site" die wij in beheer hebben voor klanten is de score over december so far 17.8% voor IE6, 62.2% voor IE7, 11.2% Firefox en 7.5% Safari. En dan heb ik het echt over een site met merendeels bejaard publiek.

Professionele website nodig?

maandag 22 december 2008 09:31

Acties:

0 Henk 'm!

shappie

CMG schreef op vrijdag 19 december 2008 @ 11:49:
Het is misschien niet zo netjes, maar ik heb gewoon besloten versies ouder dan IE7 van de site te weren en ze te verwijzen naar een download voor IE7. Misschien dat ik op een later moment de site opnieuw ontwerp en zorg dat ook de oude browsers en nog leuk uit zien, maar nu is de site gewoon niet functioneel door de CSS die ik gebruik. Dan kun je beter niets tonen dan een gebroken site :-/

Bijna vergeten: Dat IE7 project zorgde alleen maar voor meer problemen ipv wat op te lossen, dus die is meteen weer weggehaald

Mag ik vragen hoe je dit hebt gedaan? Ik heb ook zeer regelmatig dat mijn sites goed in FF, IE7, opera enz... goed werken maar in IE6 het een ramp is. Ik zou graag een redirect maken hiervoor inderdaad. Alvast bedankt!

maandag 22 december 2008 09:36

Acties:

0 Henk 'm!

Verwijderd

crisp schreef op zondag 21 december 2008 @ 22:58:
Hoewel het aandeel IE(6) dus wel substantieel lager is op Tweakers.net (altijd al geweest) in vergelijking met meer mainstream-sites is de trend toch ongeveer gelijkend met de cijfers die BARTdG heeft gepost.

De mainstream site waar ik voor werk ziet ook gelukkig een duidelijke afname in het gebruik van IE6 (en IE in het algemeen). FF is in een jaar tijd van 13% naar 25% gegaan, IE nam van 85% naar 69% af.

Van die 85% IE gebruikers was een jaar geleden 68% IE6 (dus 58% van het totaal). Dat is nu 40% (van 69%) geworden (dus 28% van het totaal). IE7 is van 32% van 85% (dus 27% van het totaal) naar 59% van 69% (dus 41%) gegaan.

Samenvattend:

Browser	20 dec 2007	20 dec 2008
IE6	58%	28%
IE7	27%	41%
FF	13%	25%

zondag 28 december 2008 12:55

Acties:

0 Henk 'm!

ZpAz

crisp schreef op zondag 21 december 2008 @ 16:06:
[...]

Je bedoelt dat je verder ook nergens margins of paddings hoeft te hebben in je opmaak?

Honestly, wat is het verschil tussen:
Cascading Stylesheet:
1
2
3
4
5
6
7
* {
    margin: 0;
    padding: 0;
}
h1, h2, h3, h4, h5, h6, ul, p {
    margin: 0 0 10px 0;
}
en
Cascading Stylesheet:
1
2
3
4
h1, h2, h3, h4, h5, h6, ul, p {
    padding: 0;
    margin: 0 0 10px 0;
}
/simpel gezegd ?
waarbij de tweede imo vriendelijker is voor alle elementen die je in het geval van een generieke reset 'vergeten' bent alsnog margin of padding te geven. Default styling gaat om accessibility, dat wil je er niet met een hamer uitslaan en vervolgens zelf halfslachtig weer 'repareren'...

daarnaast zijn er naar mijn weten wel edge-cases waarbij je door een generieke reset bepaalde default styling niet meer goed crossbrowser kunt "repareren", denk dan aan elementen zoals input (type="xxx"), select en button.

Mwah, ik zou toch voor de eerste gaan (iets wat ik dus ook altijd! doe). Omdat bijvoorbeeld IE6 ook paddings en margins om een form heen gooit, moet je die dan ook afzonderlijk weer aan je lijstje toevoegen?

Daarnaast is de kans gewoon erg klein dat je van een aantal objecten de default paddings / margins wil hebben omdat het dan gewoon niet strookt met het door je ontworpen ontwerp. Ook al zou je wel de default paddings / margins (bij toeval) gebruiken, omdat deze hetzelfde zijn zoals je het in je ontwerp geplaatst hebt, dan moet je alsnog bij elke browser gaan kijken 'hee, heeft deze browser wel dezelfde default waardes'? En mocht dat niet zo zijn dan kan je het alsnog invullen... -_-

Nee, ik ga gewoon voor consequent alles op 0 (margins / paddings) en dan zelf defineren wat anders moet.

Tweakers Time Machine Browser Extension | Chrome : Firefox

zondag 28 december 2008 13:22

Acties:

0 Henk 'm!

Verwijderd

ZpAz schreef op zondag 28 december 2008 @ 12:55:

Mwah, ik zou toch voor de eerste gaan (iets wat ik dus ook altijd! doe). Omdat bijvoorbeeld IE6 ook paddings en margins om een form heen gooit, moet je die dan ook afzonderlijk weer aan je lijstje toevoegen?

Ja. Wees altijd zo specifiek mogelijk.

Nee, ik ga gewoon voor consequent alles op 0 (margins / paddings) en dan zelf defineren wat anders moet.

Waarmee je IMHO alleen maar aangeeft dat je CSS misschien wel kent en kunt gebruiken, maar dat je het principe erachter niet begrijpt.

zondag 28 december 2008 14:49

Acties:

0 Henk 'm!

MBV

Wat een berucht voorbeeld in IE is, is de textbox en dropdown-box, die slecht te formatteren zijn met CSS, maar wel last hebben van padding/margin=0. Je moet altijd zo specifiek mogelijk zijn: het heet niet voor niets Cascading Style Sheets.

zondag 28 december 2008 23:39

Acties:

0 Henk 'm!

mcDavid

om ook nog maar een duit in het zakje te doen voor browsergebruik statistieken:

http://duft.nl/avatars/browsers.php

(zal helaas nooit geheel objectief zijn omdat mijn forumgedrag de stats beïnvloedt, maar toch leuk)

maandag 29 december 2008 02:02

Acties:

0 Henk 'm!

Bosmonster

*zucht*

curry684 schreef op maandag 22 december 2008 @ 09:16:
[...]

Bij de meest "noob-gevoelige site" die wij in beheer hebben voor klanten is de score over december so far 17.8% voor IE6, 62.2% voor IE7, 11.2% Firefox en 7.5% Safari. En dan heb ik het echt over een site met merendeels bejaard publiek.

Een zakelijk site die wij in beheer hebben (alsin een site met voornamelijk bezoekers die vanaf kantoor kijken) had begin van dit jaar nog een IE6 percentage van rond de 45%. Dat is nu inderdaad teruggelopen tot 35%. Hoop dat dat een systeembeheerder-upgrade-trend is die doorzet

Dit is wel het meest extreme geval dat je kunt hebben (ma-vr ook druk bezocht, in het weekend bijna niemand).

[ Voor 28% gewijzigd door Bosmonster op 29-12-2008 02:06 ]

dinsdag 30 december 2008 23:06

Acties:

0 Henk 'm!

DiSiLLUSiON

Verwijderd schreef op zondag 28 december 2008 @ 13:22:
[over '* { margin: 0; padding: 0; }']
Waarmee je IMHO alleen maar aangeeft dat je CSS misschien wel kent en kunt gebruiken, maar dat je het principe erachter niet begrijpt.

Daar ben ik het niet mee eens.

De verschillen in default opmaak tussen de browsers heeft niets te maken met het principe achter CSS, maar met het toegankelijk presenteren van basis informatie. Het presenteren van deze informatie is visueel op meerdere manieren mogelijk (afhankelijk van de toepassing en doelgroep), en dit hoeft voor bepaalde (of alle) elementen niet persé de manier te zijn die een bepaalde browserfabrikant gebruikt.

Ook het stylen van deze informatie hoort bij de vormgeving van een pagina, en het is onzin om alle standaard verschillen intact te houden, om ze vervolgens per browser weer terug te draaien en aan te passen; dit aanpassen doe je namelijk toch al, maar dan algemeen.

Er zijn grensgevallen zoals textinputs en dergelijke, maar deze zijn ruim en wijd bekend, hier kun je rekening mee houden.

Ja. Wees altijd zo specifiek mogelijk.

Ook daar ben ik het niet mee eens.

Het principe achter CSS is dat de regels "cascading" zijn. Ze worden doorgegeven van ouder aan kind, het is door deze overerving niet meer noodzakelijk om, zoals vroeger met inline FONT tags etc., voor elk element/id/class/etc een complete stijlset aan te maken.

Het voordeel hiervan is dat je op een algemene manier de basis stijlen kunt neerzetten (net als een schilderij, eigenlijk), en alleen in de gevallen (bepaalde elementen / elementcombinaties) deze kunt aanpassen. Zo zorg je ook voor consistente vormgeving op het moment dat er dingen mee gedaan worden die niet voorzien zijn (zoals altijd het geval is).

Juist '* { margin: 0; padding: 0; }' is een hardstikke mooi voorbeeld van de kracht van CSS. Je kunt alles meten en aanpassen per element, per browser, etc... Of je kunt alles op 0 zetten, zelf je margins en paddings instellen en die paar grenselementen even snel aanpakken in een paar regeltjes.

Op het moment dat je alles zo specifiek mogelijk gaat specificeren, kom je in de problemen. Wat nou als je die ene ul in dat menu item hebt gestyled met:

"document > body.default > div#left > ul.menu > li.menu_item > ul#speciallist"
en de klant wil het menu opeens rechts? ctrl+h en dan 'div#left' naar 'div#righttmp', 'div#right' naar 'div#left' en 'div#righttmp' naar 'div#right'? Niet handig.

En als er nu opeens meerdere listitems met een ul in je menu moeten komen? ctrl+h door alle html en css en er opeens een class van maken? Dan is '.menu > li > ul' toch een stuk handiger.

Wees dus juist zo algemeen mogelijk.

Dit maakt het later aanpassen van of toevoegen aan de CSS des te makkelijker, als je onderaan de stylesheet een iets specifiekere rule neerzet is het klusje al geklaard.

dinsdag 30 december 2008 23:39

Acties:

0 Henk 'm!

MBV

Het probleem wat je nu gaat krijgen met alles in je eigen site definieren, is mobiele browsers. Ook verspil je bandbreedte door eerst alle standaard-layout weg te gooien en vervolgens opnieuw te installeren.
Zo algemeen mogelijk of zo specifiek mogelijk vind ik allebei fout: doe het op het niveau waar je het nodig hebt. Als je iets aan een menu wil doen, doe het dan op een manier dat het alleen je menu kan aanpassen, en niet de rest van de content.

CSS is trouwens niet alleen cascading binnen je site, maar ook cascading door verschillende lagen: browser, website, user css. Volgens mij is het zelfs expliciet genoemd in de standaard, maar daar kan ik me in vergissen.

woensdag 31 december 2008 11:46

Acties:

0 Henk 'm!

Verwijderd

DiSiLLUSiON schreef op dinsdag 30 december 2008 @ 23:06:
[...]
Daar ben ik het niet mee eens.

De verschillen in default opmaak tussen de browsers heeft niets te maken met het principe achter CSS, maar met het toegankelijk presenteren van basis informatie. Het presenteren van deze informatie is visueel op meerdere manieren mogelijk (afhankelijk van de toepassing en doelgroep), en dit hoeft voor bepaalde (of alle) elementen niet persé de manier te zijn die een bepaalde browserfabrikant gebruikt.

Dat "of alle" is precies waar de schoen wringt. Dan zou je net zo goed een standaard stylesheet kunnen maken waarin je alles "reset". Dus strong en em zien er net zo uit als gewone tekst. De een zou namelijk weleens tekst rood willen maken om te benadrukken, de ander smallcaps, en nog weer iemand anders zou er een ander lettertype voor willen.

Dát er verschillen zijn weet iedereen. Maar je zou alleen datgeen moeten aanpassen dat je niet bevalt. Om dan in één keer alle margins en paddings te resetten is een teken van onmacht, en levert bij grote projecten véél meer werk op dan je zou verwachten.

Ik durf wel te beweren dat ik hier op GoT één van de meest invloedrijke personen ben geweest op dit gebied. Ik heb zelf in de praktijk nooit alle margins en paddings gereset, omdat dat nou eenmaal makkelijker was. Zo ongeveer vanaf het begin heb ik ingezien dat je jezelf daar op lange termijn alleen maar meer problemen mee bezorgt.

Dit zal vast arrogant overkomen, maar in dit geval heb ik er redenen genoeg voor.

Ook het stylen van deze informatie hoort bij de vormgeving van een pagina, en het is onzin om alle standaard verschillen intact te houden, om ze vervolgens per browser weer terug te draaien en aan te passen; dit aanpassen doe je namelijk toch al, maar dan algemeen.

Je moet alleen de verschillen aanpakken die je in een bepaalde situatie niet bevallen.

Er zijn grensgevallen zoals textinputs en dergelijke, maar deze zijn ruim en wijd bekend, hier kun je rekening mee houden.

In welk opzicht verschillen textinputs van andere elementen?

Ook daar ben ik het niet mee eens.

Ik zie nu in dat die opmerking wel heel kort door de bocht was. Beter zou zijn om te zeggen dat je selectors "zo specifiek moet maken dat het geen invloed heeft op niet relevante situaties" en toch "eventueel iets algemener als dat handiger is".

Het principe achter CSS is dat de regels "cascading" zijn. Ze worden doorgegeven van ouder aan kind, het is door deze overerving niet meer noodzakelijk om, zoals vroeger met inline FONT tags etc., voor elk element/id/class/etc een complete stijlset aan te maken.

Het voordeel hiervan is dat je op een algemene manier de basis stijlen kunt neerzetten (net als een schilderij, eigenlijk), en alleen in de gevallen (bepaalde elementen / elementcombinaties) deze kunt aanpassen. Zo zorg je ook voor consistente vormgeving op het moment dat er dingen mee gedaan worden die niet voorzien zijn (zoals altijd het geval is).

Mooi verwoord, maar de * selector heeft niets meer met cascading te maken. Dat is gewoon een zooi keien in een rivier dumpen om de alles af te dammen, en heeft weinig meer van doen met het begeleiden van de stroom.

Juist '* { margin: 0; padding: 0; }' is een hardstikke mooi voorbeeld van de kracht van CSS. Je kunt alles meten en aanpassen per element, per browser, etc... Of je kunt alles op 0 zetten, zelf je margins en paddings instellen en die paar grenselementen even snel aanpakken in een paar regeltjes.

Door dat te doen kun je juist niet meer gebruik maken van de kracht van CSS. Als je een applicatie hebt waarvoor er een standaard stylesheet is, en voor sommige "klanten" er een gecustomizede uitstraling aan de applicatie kan worden gegeven, baal je als een stekker als in de algemene stylesheet zulke onzin is uitgehaald.

Op het moment dat je alles zo specifiek mogelijk gaat specificeren, kom je in de problemen. Wat nou als je die ene ul in dat menu item hebt gestyled met:

"document > body.default > div#left > ul.menu > li.menu_item > ul#speciallist"
en de klant wil het menu opeens rechts? ctrl+h en dan 'div#left' naar 'div#righttmp', 'div#right' naar 'div#left' en 'div#righttmp' naar 'div#right'? Niet handig.

Dat is dan ook nogal dom, ook al heb ik me daar zelf vaak genoeg aan schuldig gemaakt. Sowieso is #left natuurlijk een slecht ID. In de HTML moet je proberen aan te geven wat iets is, niet waar het moet komen te staan.

Verder bedoel ik natuurlijk dat je bijvoorbeeld voor een menu bij voorkeur niet selectors als "li" gebruikt, maar wel iets als "map ul li". Dat is specifieker, want je wilt alleen de li-elementen binnen een navigatiestructuur (map) veranderen, en dan nog alleen degenen zonder specifieke volgorde (ul en dus niet ol).

Wil je binnen zo'n menu de linkjes stylen, kun je het best dat doen met de selector "map ul li a" en dus niet "map a" tenzij je een goede reden hebt om dat wél zo te doen. Zonder goede reden moet je gewoon specifiek zijn.

En als er nu opeens meerdere listitems met een ul in je menu moeten komen? ctrl+h door alle html en css en er opeens een class van maken? Dan is '.menu > li > ul' toch een stuk handiger.

Wees dus juist zo algemeen mogelijk.

Alleen als de situatie daar om vraagt. Dat is helaas iets wat je alleen kunt leren door er ervaring in op te doen.

Dit maakt het later aanpassen van of toevoegen aan de CSS des te makkelijker, als je onderaan de stylesheet een iets specifiekere rule neerzet is het klusje al geklaard.

De one-liner "* { padding: 0; margin: 0 }" zorgt ervoor dat je veel meer "klusjes moet klaren" dan nodig is.

woensdag 31 december 2008 12:39

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Grappig, mooi voorbeeld is de veelgebruikte Thickbox (jQuery Lightbox variant). In de standaard CSS daarvan staat * {margin: 0; padding: 0} en dat dat nodig is voor Thickbox.

Dat is leuk, maar voor mij een reden dat hele script als gaar te bestempelen en niet te gebruiken. Ik kan toch moeilijk een Lightbox script gebruiken dat op eigen houtje ALLE margins en paddings reset?

*-selector is iets dat je eigenlijk niet hoort te gebruiken. Het is feitelijk een soort symptoom bestrijding. "Ow er klopt iets niet, laat ik dan maar ALLES resetten, dan snap ik het weer".

woensdag 31 december 2008 12:43

Acties:

0 Henk 'm!

Clay

cookie erbij?

Ik vraag me dan ook af of diegenen die met * alles resetten ook de obscuurdere elementen van styles voorzien, bv de definition list of blockquote. Maar zelfs een gewone list kan al problemen opleveren.

Stel ik werk aan een site waar iemand anders de basis voor heeft gelegd, en ik heb een eenvoudige list nodig in de content. Nou blijkt dat wanneer ik die erin zet en hem bekijk, alles tegen de linker kantlijn aanstaat zonder bullets. Leuk is anders, want het kan best voorkomen dat iemand later een list wil gebruiken, dus wil ik deze van wat styling voorzien. In de CSS kom ik die * {} tegen, en nou heb ik een dilemma; ik houd namelijk van zo generiek mogelijke selectors voor het component in kwestie, en voor de basis styling van een list zijn dat:

Cascading Stylesheet:

1
2
3

ul {}
/* en */
li {}

Het is echter een groot project, en er zijn op meerdere plaatsen al lists gebruikt voor andere doeleinden; hoofdmenu, tabmenu's etc...

Het liefst zou ik op de LI een leftmargin zetten met een disc list style, maar nou moet ik alle componenten afgaan of die wel zelf hun linker marge beheren, of dat ze ervanuit gaan dat het * dat wel oplost. In dat laatste geval ben ik de lul, omdat de specificity van * 0 is, en moet ik alsnog overal die marges gaan opgeven, en alles opnieuw gaan testen.

En dan is dit nog een simpel voorbeeld.

Margin en padding zijn bovendien nog maar een subset van de default style verschillen, fontsizes en lineheights zijn veel grotere "boosdoeners".

Instagram | Flickr | "Let my music become battle cries" - Frédéric Chopin

zondag 4 januari 2009 00:46

Acties:

0 Henk 'm!

link0007

Verwijderd schreef op maandag 22 december 2008 @ 09:36:
[...]

De mainstream site waar ik voor werk ziet ook gelukkig een duidelijke afname in het gebruik van IE6 (en IE in het algemeen). FF is in een jaar tijd van 13% naar 25% gegaan, IE nam van 85% naar 69% af.

Van die 85% IE gebruikers was een jaar geleden 68% IE6 (dus 58% van het totaal). Dat is nu 40% (van 69%) geworden (dus 28% van het totaal). IE7 is van 32% van 85% (dus 27% van het totaal) naar 59% van 69% (dus 41%) gegaan.

Samenvattend:

Browser 20 dec 2007 20 dec 2008
IE6 58% 28%
IE7 27% 41%
FF 13% 25%

mijn site, een filesharing site voor natuurkundige simulaties, gemeten over 92k "absoluut unieke bezoekers" tussen 28 juli 2008 en 03 januari 2009

browser	percentage
firefox	47.09%
firefox 3.x	39.2%
firefox 2.x	7.64%
internet explorer	39.02%
IE 8	0.65%
IE 7	31.29%
IE 6	7.08%
opera	5.85%
safari	4.66%
chrome	2.99%
overig	0.39%

Behoorlijk up-to-date dus

Maar toch doe ik m'n best alles IE6 compatible te houden.. een vreemde 1px afwijking in een marge boeit me logischerwijs geen drol. Maar wanneer mensen niet meer kunnen een rating toe kunnen voegen in IE6 (zoals ik laatst had), dan zorg ik er uiteraard voor dat het gefixt word.

Ik heb dan wel een publiek waar weinig webdevelopers nee tegen zouden zeggen

Vooral (gelukkig) veel FF3 gebruikers

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;

zondag 4 januari 2009 02:04

Acties:

0 Henk 'm!

ZpAz

Verwijderd schreef op zondag 28 december 2008 @ 13:22:

Waarmee je IMHO alleen maar aangeeft dat je CSS misschien wel kent en kunt gebruiken, maar dat je het principe erachter niet begrijpt.

Dus omdat niet elke browser gelijke margins en paddings toepast op de verschillende html tags, en het ook nog eens verschilt per browser per html tag, en ik dat probleem (het probleem wat praktisch de meeste cross-browser problemen oplost). En ik dit oplos door te resetten, en later goed te defineren voor de tags wanneer nodig betekend dat ik het princiepe niet begrijp?

Tweakers Time Machine Browser Extension | Chrome : Firefox

zondag 4 januari 2009 10:56

Acties:

0 Henk 'm!

MBV

Ja. En Clay gaf ook nog een valide punt wat een probleem is bij jouw aanpak: als je een li/ul-lijst nodig hebt in nieuwe content, wat je toevallig nog niet eerder hebt gebruikt, dan zal die dankzij de reset niet werken.

Waarom maak je het niet specifiek voor de tags waarbij je er last van hebt? Dankzij Firebug en IE8 kan je heel snel de boosdoener aanwijzen. En dikke kans dat je die tags toch al een andere styling wilde geven. Dus in plaats van alles resetten, en daarna de goeie layout geven:

Cascading Stylesheet:

* {
  margin: 0;
  paddings: 0;
}
/*...*/
select {
  margin-right: 5px;
}

Zou je toch net zo goed zoiets neer kunnen zetten:

Cascading Stylesheet:

1
2
3

select {
  margin: 0 5px 0 0;
}

Of zelfs zoiets, als je echt niks anders doet met de layout kan je gewoon de dingen aanpassen waar je er last van hebt:

Cascading Stylesheet:

1
2
3

p, div {
  margin: 0; padding: 0;
}

zondag 4 januari 2009 13:33

Acties:

0 Henk 'm!

Copyman

Dode muis

Ik heb even een berekening gemaakt van 6 websites met gemiddeld 1500 unieke Nederlandse bezoekers per dag. De doelgroepen variëren van jeugd tot ouderen. Ik heb van 3 browsers de gemiddelden uitgerekend:

	Site 1	Site 2	Site 3	Site 4	Site 5	Site 6	Gemiddeld
IE-ALL	~89	~83	~97	~88	~86	~74	~86%
IE7	75,32	78,56	65,06	75,94	80,23	62,05	72,86%
IE6	24,31	20,71	34,78	23,40	19,38	36,87	26,58%
FF	8,26	13,46	1,67	8,43	9,81	20,91	10,42%

Gemiddelde IE7 tov. andere browsers: (86*72,86)/100 = 62,65%
Gemiddelde IE6 tov. andere browsers: (86*26,85)/100 = 22,85%

De 4% die overblijft zijn browsers als Safari, Opera, etc.

Site 1: Voetbalclub
Site 2: Grote uitgaansgelegenheid
Site 3: Grote leverancier automaterialen
Site 4: Bekende autogroep in Twente e.o.
Site 5: Webwinkel in babyartikelen
Site 6: Import/export landbouwmachines

Helaas valt Firefox hier wat in de minderheid, maar dit is natuurlijk ook sterk afhankelijk van de doelgroep. Globaal gezien merken wij ook wel een lichte afname in IE6-gebruik. Gemiddeld zo'n 0,5% per maand voor zover ik dat even snel uit heb kunnen rekenen. Wil natuurlijk niet zeggen dat dit de komende maanden ook in die lijn doorgaat (mag van mij wel wat sneller).

[ Voor 9% gewijzigd door Copyman op 04-01-2009 18:05 . Reden: Wijziging tabel en percentages IE ]

Zeer belangrijke informatie: Inventaris

zondag 4 januari 2009 15:45

Acties:

0 Henk 'm!

Verwijderd

Copyman schreef op zondag 04 januari 2009 @ 13:33:

Site 1 Site 2 Site 3 Site 4 Site 5 Site 6 Gemiddeld
IE7 75,32 78,56 65,06 75,94 80,23 62,05 72,86%
IE6 24,31 20,71 34,78 23,40 19,38 36,87 26,58%
FF 8,26 13,46 1,67 8,43 9,81 20,91 10,42%

	Site 1	Site 2	Site 3	Site 4	Site 5	Site 6	Gemiddeld
IE7	75,32	78,56	65,06	75,94	80,23	62,05	72,86%
IE6	24,31	20,71	34,78	23,40	19,38	36,87	26,58%
FF	8,26	13,46	1,67	8,43	9,81	20,91	10,42%

Thanks, interessant.

Maar ligt het aan mijn zondagdip, of kloppen de percentages niet? Als ik per site optel, kom ik steeds boven de 100% uit.

[ Voor 0% gewijzigd door Verwijderd op 04-01-2009 15:46 . Reden: typo ]

zondag 4 januari 2009 17:48

Acties:

0 Henk 'm!

Copyman

Dode muis

Verwijderd schreef op zondag 04 januari 2009 @ 15:45:
[...]
Maar ligt het aan mijn zondagdip, of kloppen de percentages niet? Als ik per site optel, kom ik steeds boven de 100% uit.

Oops, excuses. Dat zijn de percentages van de algehele IE percentage natuurlijk.

Zeer belangrijke informatie: Inventaris

zondag 4 januari 2009 19:07

Acties:

0 Henk 'm!

curry684

left part of the evil twins

MBV schreef op zondag 04 januari 2009 @ 10:56:
Waarom maak je het niet specifiek voor de tags waarbij je er last van hebt?

Omdat dat een pointless evangelist issue is. Ik prefeer met 2 regels alles te resetten zelf en in 100 regels te rebuilden wat ik nodig heb, anderen prefereren om in 100 regels alles te resetten wat ze nodig hebben. Big deal: er is in dit hele topic nog niemand geweest die enig steekhoudend argument voor de ene of de andere methode heeft op weten te werpen, met uitzondering van het resetten van bepaalde margins/paddings in <input>-elements die je in bepaalde deprecated outdated browsers niet terug kunt krijgen, waar ik persoonlijk nog nooit tegenaan ben gelopen.

Overigens geldt dit natuurlijk alleen voor de 'absolute reset' in de root-CSS van een site waar je gewoon nul behoefte hebt aan default stylesheets - het voorbeeld van een externe lightbox plugin die eisen aan de 'hogere' stylesheets stelt is natuurlijk wel van de zotte gezien het concept Cascading Style Sheets. Voor de rest, tja evangelism, dit topic barst van de "my method is better than yours and i'm not saying why because i have no idea myself".

Professionele website nodig?

zondag 4 januari 2009 19:26

Acties:

0 Henk 'm!

MBV

curry684 schreef op zondag 04 januari 2009 @ 19:07:
[...]
Voor de rest, tja evangelism, dit topic barst van de "my method is better than yours and i'm not saying why because i have no idea myself".

En bedankt

. Jij bent kennelijk de grote expert, je bent heel zeker ervan dat jouw methode goed is, terwijl ik altijd had begrepen dat dat het domste was dat je kon doen. Dan vraag ik waarom je het zo doet, in de hoop er wat van te leren. Is dat nou zo heel raar?

zondag 4 januari 2009 20:10

Acties:

0 Henk 'm!

mcDavid

Het zal me werkelijk geen reet uitmaken of iemand wel of niet reset. Heb het één keer zelf gedaan en toen besloten dat nooit meer te doen omdat het gewoon kei-irritant is. Gewoon weten waar je mee bezig bent is veel handiger. Maar voor de rest kleven er niet echt nadelen aan volgens mij. 't Is niet dat het conflicten oplevert of dat het er (significant) trager van wordt.

zondag 4 januari 2009 20:22

Acties:

0 Henk 'm!

curry684

left part of the evil twins

MBV schreef op zondag 04 januari 2009 @ 19:26:
[...]

En bedankt . Jij bent kennelijk de grote expert, je bent heel zeker ervan dat jouw methode goed is, terwijl ik altijd had begrepen dat dat het domste was dat je kon doen. Dan vraag ik waarom je het zo doet, in de hoop er wat van te leren. Is dat nou zo heel raar?

Je hebt m'n post niet goed gelezen. Ik ben er niet zeker van dat mijn methode goed is, en ik zeg nergens dat jouw methode kut is. Er is geen beste.

Professionele website nodig?

zondag 4 januari 2009 23:43

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

curry684 schreef op zondag 04 januari 2009 @ 19:07:
[...]

Omdat dat een pointless evangelist issue is. Ik prefeer met 2 regels alles te resetten zelf en in 100 regels te rebuilden wat ik nodig heb, anderen prefereren om in 100 regels alles te resetten wat ze nodig hebben. Big deal: er is in dit hele topic nog niemand geweest die enig steekhoudend argument voor de ene of de andere methode heeft op weten te werpen, met uitzondering van het resetten van bepaalde margins/paddings in <input>-elements die je in bepaalde deprecated outdated browsers niet terug kunt krijgen, waar ik persoonlijk nog nooit tegenaan ben gelopen.

Dat probleem speelt nog steeds in zekere mate in recente browsers. Een snelle test gaf mij al de volgende situaties:

1) een universal reset maakt dat checkboxen en radiobuttons in Opera terugvallen naar de 'standaard' GUI presentatie in plaats van Opera's eigen 'fancy' styling. Om dat teniet te doen moet je dit toevoegen:

Cascading Stylesheet:

input[type="checkbox"],
input[type="radio"] {
    padding: 0 1px;
}

2) universal reset maakt dat in o.a. Firefox en Opera (maar niet IE) de tekst in button-type elementen dicht tegen de randen komt te staan. Ook is in Firefox een deel van het 'push-down' effect dan weg. Dat kan je oplossen met iets als:

Cascading Stylesheet:

button,
input[type="button"],
input[type="reset"],
input[type="submit"] {
    padding: 0px 6px;
}
button:active:hover,
input[type="button"]:active:hover,
input[type="reset"]:active:hover,
input[type="submit"]:active:hover {
    padding: 0px 5px 0px 7px;
}

maar helemaal perfect is dat niet. Opera mist daar eigenlijk nog wat verticale padding, en dit zorgt er voor dat in IE button-type elementen juist weer teveel 'spacing' krijgen.

3) universal reset maakt dat bij select-elementen in Firefox in sommige gevallen er geen spacing meer is tussen de geselecteerde tekst en de dropdown arrow. Dit los je niet op met een padding op <select> maar juist met een padding-right op <option>. Het effect op <optgroup> heb ik nog niet bekeken, mozilla gebruikt zelf -moz-padding-start en -moz-padding-end in z'n default stylesheet; ik kan me voorstellen dat fixes met plain padding negatieve effecten zullen hebben in andere browsers.

In het algemeen vind ik, buiten bovenstaande voorbeelden, een universal reset nog steeds een slecht idee omdat default styling wel degelijk nut heeft. Stel dat je de universal reset gebruikt en vervolgens voor een aantal gangbare elementen weer padding/margin definieert, maar er onverhoopt toch eens een ander element wordt gebruikt in de site die door de universal reset geen padding of margin krijgt. Je vergeet bijvoorbeeld <blockquote> te un-resetten zeg maar, wat zal maken dat dat element helemaal niet meer te herkennen is als een citaat, en in het ergste geval zelfs gewoon onderdeel lijkt uit te maken van de gewone tekst in bijvoorbeeld een artikel (omdat het helemaal niet meer los staat van een vorige of volgende paragraaf).

Daarbij is het gevaar van het gebruik van de universal selector dat mensen het misschien gaan gebruiken voor properties die normaliter inherited zijn zoals font-size of line-height, wat het 'repareren' nog een stuk complexer maakt.

Intentionally left blank

maandag 5 januari 2009 08:59

Acties:

0 Henk 'm!

curry684

left part of the evil twins

crisp schreef op zondag 04 januari 2009 @ 23:43:
[...]

Dat probleem speelt nog steeds in zekere mate in recente browsers. Een snelle test gaf mij al de volgende situaties:

Valide voorbeelden, maar de hamvraag in deze is in hoeverre een aanpak van een bepaalde probleemstelling slecht te noemen is omdat de clients er niet goed mee om gaan? Dat gedrag van Opera wat je omschrijft bijv. is ronduit buggy, en in hoeverre moet je core principles waar je gebruik van maakt aan laten passen door beperkte ondersteuning van de clients? Ga dan direct IE6 100% supporten met volledig separated templatesets, die heeft iig meer actieve gebruikers

In het algemeen vind ik, buiten bovenstaande voorbeelden, een universal reset nog steeds een slecht idee omdat default styling wel degelijk nut heeft. Stel dat je de universal reset gebruikt en vervolgens voor een aantal gangbare elementen weer padding/margin definieert, maar er onverhoopt toch eens een ander element wordt gebruikt in de site die door de universal reset geen padding of margin krijgt. Je vergeet bijvoorbeeld <blockquote> te un-resetten zeg maar, wat zal maken dat dat element helemaal niet meer te herkennen is als een citaat, en in het ergste geval zelfs gewoon onderdeel lijkt uit te maken van de gewone tekst in bijvoorbeeld een artikel (omdat het helemaal niet meer los staat van een vorige of volgende paragraaf).

Ja en als je blockquote vergeet te stylen ziet ie er alsnog kut uit omdat ie voor geen meter past bij de rest van je ontwerp, maar heeft ie iig wel margins om z'n kutlayout. Net zoals je je methodieken niet aan moet passen aan buggy clients moet je ze ook niet aanpassen aan buggy developers - je moet gewoon geen elementen vergeten te stylen die wel gebruikt worden.

Daarbij is het gevaar van het gebruik van de universal selector dat mensen het misschien gaan gebruiken voor properties die normaliter inherited zijn zoals font-size of line-height, wat het 'repareren' nog een stuk complexer maakt.

Da's dan ook gewoon buggy gebruik, dat maakt het fundamentele idee achter padding+margin resetten niet fout

Professionele website nodig?

maandag 5 januari 2009 09:15

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

curry684 schreef op maandag 05 januari 2009 @ 08:59:
[...]

Ja en als je blockquote vergeet te stylen ziet ie er alsnog kut uit omdat ie voor geen meter past bij de rest van je ontwerp, maar heeft ie iig wel margins om z'n kutlayout. Net zoals je je methodieken niet aan moet passen aan buggy clients moet je ze ook niet aanpassen aan buggy developers - je moet gewoon geen elementen vergeten te stylen die wel gebruikt worden.

Vorm boven functie?
En jij styled ook alvast alle nieuwe elementen die we straks in HTML5 krijgen?

Intentionally left blank

maandag 5 januari 2009 10:28

Acties:

0 Henk 'm!

MBV

curry684 schreef op maandag 05 januari 2009 @ 08:59:
Ja en als je blockquote vergeet te stylen ziet ie er alsnog kut uit omdat ie voor geen meter past bij de rest van je ontwerp, maar heeft ie iig wel margins om z'n kutlayout. Net zoals je je methodieken niet aan moet passen aan buggy clients moet je ze ook niet aanpassen aan buggy developers - je moet gewoon geen elementen vergeten te stylen die wel gebruikt worden.

Standaard layout is vaak ongeveer wat 'gebruikers' verwachten. li/ul is zo'n voorbeeld: het functioneert standaard prima, je krijgt alleen lelijke bullets. met de universele reset werkt het niet meer.

[...]

Da's dan ook gewoon buggy gebruik, dat maakt het fundamentele idee achter padding+margin resetten niet fout

Het fundamentele idee achter padding+margin resetten is dat de standaard layout niet voldoet, toch? Waarom valt line-height enzo daar dan niet onder, die kan je toch net zo goed per element gaan repareren? Ik denk dat universele reset fundamenteel fout is, maar dat je daar bij margin en padding relatief weinig last van hebt.

maandag 5 januari 2009 11:09

Acties:

0 Henk 'm!

curry684

left part of the evil twins

crisp schreef op maandag 05 januari 2009 @ 09:15:
[...]
Vorm boven functie?
En jij styled ook alvast alle nieuwe elementen die we straks in HTML5 krijgen?

Ik zet gewoon geen HTML5 doctype erboven tot al die nieuwe elementen bekend zijn?

@hierboven: layouts breken niet op verkeerde line-heights. De layout van Tweakers.net breekt morgen wel *volledig* en pijnlijk als een browser op <li> ineens een margin-left:2px zet in z'n default stylesheet, die wordt op regel 275 van framework.css namelijk niet hard gedefined waardoor het hele topmenu omvalt. Dat is mij te fragiel voor een default regel die helemaal niet vreemd is, een simpele left indent op een list item.

Afbeeldingslocatie: http://opbokken.nu/tnetlayoutbug.jpg

Afbeeldingslocatie: http://opbokken.nu/tnetlayoutbug.jpg

[ Voor 44% gewijzigd door curry684 op 05-01-2009 11:19 ]

Professionele website nodig?

maandag 5 januari 2009 11:14

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

curry684 schreef op maandag 05 januari 2009 @ 11:09:
[...]

Ik zet gewoon geen HTML5 doctype erboven tot al die nieuwe elementen bekend zijn?

@hierboven: layouts breken niet op verkeerde line-heights. De layout van Tweakers.net breekt morgen wel *volledig* en pijnlijk als een browser op <li> ineens een margin-left:2px zet in z'n default stylesheet, die wordt op regel 275 van framework.css namelijk niet hard gedefined waardoor het hele topmenu omvalt. Dat is mij te fragiel voor een default regel die helemaal niet vreemd is, een simpele left indent op een list item.

[afbeelding]

Ik vind dat persoonlijk een non-argument; er zal geen browser-vendor zijn die dat soort dingen in z'n hoofd haalt aangezien ze daarmee niet alleen Tweakers.net zullen 'breken'...

[ Voor 62% gewijzigd door crisp op 05-01-2009 11:21 ]

Intentionally left blank

maandag 5 januari 2009 11:26

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Aha, dus nu mag de default stylesheet, na enkele schermen preek dat 'sites de default stylesheet moeten gebruiken want die is er voor een reden', nooit of te nimmer door eender welke vendor meer aangepast worden omdat ie daarmee sites gaat breken die deze wijzigingen slecht voorzien hebben? Daarmee heb je wmb definitief het failliet uitgesproken over het laten bestaan van paddings en margins uit de default stylesheet

Want als ie nooit meer aangepast mag worden moet ie gestandaardiseerd worden, en zodra dat gebeurt is de hele discussie inderdaad ineens anders - dan is het gevaar weg van defaults volgen en kun je de default aanpassen op waar je dat nodig hebt.

Professionele website nodig?

maandag 5 januari 2009 14:23

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

curry684 schreef op maandag 05 januari 2009 @ 11:26:
Aha, dus nu mag de default stylesheet, na enkele schermen preek dat 'sites de default stylesheet moeten gebruiken want die is er voor een reden', nooit of te nimmer door eender welke vendor meer aangepast worden omdat ie daarmee sites gaat breken die deze wijzigingen slecht voorzien hebben?

Ik denk inderdaad dat de huidige status quo voor browservendors een probleem is

Daarmee heb je wmb definitief het failliet uitgesproken over het laten bestaan van paddings en margins uit de default stylesheet Want als ie nooit meer aangepast mag worden moet ie gestandaardiseerd worden, en zodra dat gebeurt is de hele discussie inderdaad ineens anders - dan is het gevaar weg van defaults volgen en kun je de default aanpassen op waar je dat nodig hebt.

En je slaat de spijker op z'n kop: ik vind inderdaad dat default styling gestandaardiseerd zou moeten worden, want linksom of rechtsom levert de huidige situatie gewoon problemen op...

Intentionally left blank

zondag 11 januari 2009 03:36

Acties:

0 Henk 'm!

_Thanatos_

Ja, en kaal

xzaz schreef op vrijdag 19 december 2008 @ 13:35:
Ik zit nog altijd met PNG en IE6. Heeft er iemand ervaringen met projecten die dit ondersteunen en ook makkelijk implementeerbaar zijn zonder een hele framework te moeten installeren. Ik heb diverse scripts getest maar zijn of niet functioneel of 't kost gewoon te veel tijd om ze te installeren.

Beetje late reactie, maar kijk eens naar DD_belatedPNG

日本！🎌