Probleem Chrome - CSS wordt eerste keer niet goed geladen

[poepkop]

Hallo,

Ik heb een vreemd probleem met Chrome met een vrij eenvoudig formulier. De eerste keer wanneer ik de pagina bezoek met Chrome staan de labels onder de checkbox en radio button, terwijl ik float:left gebruik. Apart is dat als ik de pagina dan vernieuw, de layout wel goed is.

Ik heb er een filmpje van gemaakt:
http://www.robinvanholst.nl/form/vreemd.mov

Het script vind je op:
http://www.robinvanholst.nl/form/

Is dit nou een bug, of is het te omzeilen?

[Ook al Bezet]

Ik kan dat hier op Linux niet reproduceren (Chrome 17.0.963.79). Misschien een foutje in de Mac versie van Chrome?

[ Voor 10% gewijzigd door Ook al Bezet op 14-03-2012 16:06 ]

[Acid_Burn]

Hier gaat het met chrome niet fout (XP/Chrome 17.0.963.79)

[SanderTje!]

Chrome op Linux (Ubuntu) gaat ook prima.

Heb je je Cache al leeggemaakt en/of met CTRL-F5 gerefreshed? Gebruik je bepaalde extensions in Chrome? Die zou je ook uitschakelen als niets lijkt te werken.

[ Voor 45% gewijzigd door SanderTje! op 14-03-2012 15:58 ]

[Verwijderd]

Bij mij staan ze ook eronder. Windows 7/Chrome 17.0.963.79
Bovendien blijft het na refreshen.

[ Voor 23% gewijzigd door Verwijderd op 14-03-2012 16:02 ]

[poepkop]

Ik heb inmiddels al wat gevonden, door de html tag html5 te maken wordt het probleem opgelost voor sommige versies van Chrome op Windows. Maar op de Mac heb ik het probleem nog steeds.

@Sandertje:
Als ik een pc pak waarop ik de pagina nog nooit heb geopend, heb ik het probleem ook.

[Ook al Bezet]

Je hebt op dit moment geen </html> tag, weet niet of dat daarnet ook al zo was.

[poepkop]

Dat is net per ongeluk gebeurd. Maar dat lost ook het probleem niet op...

[Verwijderd]

Ik heb het zelfde als TTx.
Ik heb ook even je pagina gedownload zodat ik even wat dingen kon testen maar lokaal werkt hij wel goed.

Beetje off-topic:
Zou je trouwens niet beter wat meer met overflow:hidden; gaan werken ipv al die 'clear' div's?

[R4gnax]

Verwijderd schreef op woensdag 14 maart 2012 @ 16:37:
Beetje off-topic:
Zou je trouwens niet beter wat meer met overflow:hidden; gaan werken ipv al die 'clear' div's?

Nog beter:

Cascading Stylesheet:

.bfc { zoom: 1; }
.bfc:before, .bfc:after {
  clear: both;  
  content: "";  
  display: table;   
}

Creeërt alle effect van een nieuwe block formatting context, net zoals overflow: hidden dat doet, maar staat nog steeds toe dat je elementen (en box shadows) buiten de container kunt laten vloeien.

[Verwijderd]

R4gnax schreef op woensdag 14 maart 2012 @ 21:12:
[...]

Nog beter:

Cascading Stylesheet:

.bfc { zoom: 1; }
.bfc:before, .bfc:after {
  clear: both;  
  content: "";  
  display: table;   
}

Creeërt alle effect van een nieuwe block formatting context, net zoals overflow: hidden dat doet, maar staat nog steeds toe dat je elementen (en box shadows) buiten de container kunt laten vloeien.

Ik ken deze methode verder niet maar waarom is dat beter voor dit formulier?

[Ook al Bezet]

Verwijderd schreef op donderdag 15 maart 2012 @ 10:15:
[...]


Ik ken deze methode verder niet maar waarom is dat beter voor dit formulier?

Omdat je dan geen clear divs meer nodig hebt, waardoor je HTML gelijk een stuk schoner wordt.

Wat die zoom:1; daar doet begrjip ik trouwens niet helemaal maar het zal wel met IE compatibiliteit te maken hebben.

[SanderTje!]

Ook al Bezet schreef op donderdag 15 maart 2012 @ 10:33:
[...]

Omdat je dan geen clear divs meer nodig hebt, waardoor je HTML gelijk een stuk schoner wordt.

Wat die zoom:1; daar doet begrjip ik trouwens niet helemaal maar het zal wel met IE compatibiliteit te maken hebben.

Dit topic wordt inmiddels gehijacked Ik ben ook wel benieuwd hoe het staat met het antwoord op de vraag van de TS.

Wat betreft zoom: 1; dit is om Internet Explorer 7 elementen 'Layout' mee te geven. Het hele verhaal staat hier: http://www.satzansatz.de/cssd/onhavinglayout.html . In basis komt het erop neer dat als een element zich in IE7 erg 'vaag' gedraagt, dat het vaak kan helpen als je zoom: 1; toevoegt. Dit is een statement wat visueel niets doet met het element, maar wel zorgt dat er 'layout' is. IE6 is dan wel uitgefaseerd nu, IE7 mag wat mij betreft snel volgen.

[Verwijderd]

Ook al Bezet schreef op donderdag 15 maart 2012 @ 10:33:
[...]

Omdat je dan geen clear divs meer nodig hebt, waardoor je HTML gelijk een stuk schoner wordt.

Wat die zoom:1; daar doet begrjip ik trouwens niet helemaal maar het zal wel met IE compatibiliteit te maken hebben.

Daar is mijn overflow:hidden; methode veel simpeler voor.

[R4gnax]

Verwijderd schreef op donderdag 15 maart 2012 @ 13:42:
[...]


Daar is mijn overflow:hidden; methode veel simpeler voor.

En daar betaal je voor wanneer je in de situatie komt dat een containing element ineens wèl overflow moet toestaan, bijv. voor decoratief-verantwoorde elementen die over de rand naar buiten leunen of voor box shadows.

[Verwijderd]

R4gnax schreef op donderdag 15 maart 2012 @ 19:52:
[...]


En daar betaal je voor wanneer je in de situatie komt dat een containing element ineens wèl overflow moet toestaan, bijv. voor decoratief-verantwoorde elementen die over de rand naar buiten leunen of voor box shadows.

Want één regeltje overflow:hidden; weghalen en jouw code daarin voor de plaats zetten is dan heel veel werk? Je gaat toch niet van te voren allemaal onnodige code schrijven voor als je ooit eens... dan kun je bezig blijven.

On-topic:
En ik heb even wat dingen met Stylebot geprobeert en het ligt aan de breedte van je options div. Ik heb hem op 200px gezet en dan komt het label er wel naast te staan. Schijnbaar geef jij hem ergens een breedte mee maar dat kan ik zo snel nergens vinden?

[Bosmonster]

Kom nu overigens precies hetzelfde probleem tegen in Chrome in een project. Ook met floats waar het compleet willekeurig soms wel goed gaat en soms niet. Doe ook niks bijzonders, gewoon 2 elementen naast elkaar floaten.

Chrome lijkt wel elke release buggy'er te worden

[R4gnax]

Bosmonster schreef op vrijdag 16 maart 2012 @ 09:27:
Chrome lijkt wel elke release buggy'er te worden

Had ik ook al gemerkt. Pas nog zowaar een redraw probleem gehad met elementen die spontaan verdwenen totdat een redraw geforceerd werd via bijvoorbeeld muisinteractie. Echt; WTF. Ik dacht dat dat soort bugs samen met IE's 'hasLayout' tot het verleden behoorden, maar kennelijk toch niet.

Verwijderd schreef op vrijdag 16 maart 2012 @ 09:24:
Want één regeltje overflow:hidden; weghalen en jouw code daarin voor de plaats zetten is dan heel veel werk?

Wel als het op twintig verschillende plekken ineens mee veranderd omdat je een net systeem van overerving in je CSS hebt zitten en die twintig plekken dan ook weer opnieuw onder al je ondersteunde browsers getest moeten worden...

Verwijderd schreef op vrijdag 16 maart 2012 @ 09:24:
Je gaat toch niet van te voren allemaal onnodige code schrijven voor als je ooit eens... dan kun je bezig blijven.

Nee, in plaats van het in één keer goed te doen ga je overal comments bij zetten en notities bijhouden voor het geval in de toekomst de quick fix met side effects niet meer toepasbaar is.

[ Voor 21% gewijzigd door R4gnax op 16-03-2012 10:57 ]

[SanderTje!]

Bosmonster schreef op vrijdag 16 maart 2012 @ 09:27:
Kom nu overigens precies hetzelfde probleem tegen in Chrome in een project. Ook met floats waar het compleet willekeurig soms wel goed gaat en soms niet. Doe ook niks bijzonders, gewoon 2 elementen naast elkaar floaten.

Chrome lijkt wel elke release buggy'er te worden

Ik dacht vandaag precies hetzelfde!

Wij hebben namelijk een nieuwe header, waarbij Chrome in een bepaalde situatie de 'sticky' bovenbalk laat verdwijnen. Als je 1 keer scrolled, dan verschijnt de balk ineens weer. Aangezien dit met CSS geregeld wordt, lijkt mij dit een behoorlijke bug van Chrome.

[Bosmonster]

Ook nog een leuke. li's + opacity gaat in Chrome ook niet altijd lekker, tenzij je ze expliciet op display:block zet. Maakt in de praktijk gelukkig niet zoveel uit, maar ook weer zoiets...

Zelfs IE6 doet dat prima

[ Voor 8% gewijzigd door Bosmonster op 16-03-2012 11:30 ]

[Verwijderd]

R4gnax schreef op vrijdag 16 maart 2012 @ 10:54:
[...]


Had ik ook al gemerkt. Pas nog zowaar een redraw probleem gehad met elementen die spontaan verdwenen totdat een redraw geforceerd werd via bijvoorbeeld muisinteractie. Echt; WTF. Ik dacht dat dat soort bugs samen met IE's 'hasLayout' tot het verleden behoorden, maar kennelijk toch niet.


[...]


Wel als het op twintig verschillende plekken ineens mee veranderd omdat je een net systeem van overerving in je CSS hebt zitten en die twintig plekken dan ook weer opnieuw onder al je ondersteunde browsers getest moeten worden...


[...]

Nee, in plaats van het in één keer goed te doen ga je overal comments bij zetten en notities bijhouden voor het geval in de toekomst de quick fix met side effects niet meer toepasbaar is.

Het is in dit geval maar 1 keer nodig.

Maar jij zal vast hele efficiënte code schrijven, laat ik hier even een fix maken voor als ik ooit een full browser background image wil ipv een witte, en hier een fixje voor als ik ooit ronde hoeken wil gebruiken, en hier nog een beetje code voor het geval dat ik er ooit een nieuwssite van maak ipv een webshop. Vooral doen, ieder zijn ding, maar hier laat ik het verder bij.

[R4gnax]

Verwijderd schreef op vrijdag 16 maart 2012 @ 11:40:
Maar jij zal vast hele efficiënte code schrijven.

Toevallig wel ja. Dat moet ook wel in een competitieve branche als de reisindustrie. Zeker op de schaal van websites voor de grotere touroperators.

De filosofie achter CSS structuren als OOCSS werkt daar dan ook ideaal voor: zeer herbruikbare componenten met een minimale code footprint, overzichtelijke code en dankzij de component isolatie ook korte en snel te evalueren selector ketens. Vraag het bijvoorbeeld maar eens aan Facebook, die er zeer significante winnings mee kon halen ten opzichte van de 'klassieke' manier van CSS bouwen. Zowel in de categorie bandbreedte verbruik als in de categorie render snelheid.

Het laatste wat je bij zo'n opzet wilt is een generieke bouwsteen voor grid-uitlijning die dankzij zijn verborgen gebreken eigenlijk helemaal niet generiek is, maar ondertussen wel overal in een project door meerdere developers ingezet moet worden om aan hun toebedeelde functionaliteit te implementeren. Dat is een maintenance nachtmerrie in wording. Op zo'n moment kies je de robuustere oplossing; vooral als het nog geen 0.1 kB aan data scheelt.

(Het zou je overigens sieren om in het vervolg niet op de man te spelen. En daarbij houd ik het ook, voordat deze thread nog verder ontspoort.)

[Verwijderd]

R4gnax schreef op vrijdag 16 maart 2012 @ 20:28:
[...]


Toevallig wel ja. Dat moet ook wel in een competitieve branche als de reisindustrie. Zeker op de schaal van websites voor de grotere touroperators.

De filosofie achter CSS structuren als OOCSS werkt daar dan ook ideaal voor: zeer herbruikbare componenten met een minimale code footprint, overzichtelijke code en dankzij de component isolatie ook korte en snel te evalueren selector ketens. Vraag het bijvoorbeeld maar eens aan Facebook, die er zeer significante winnings mee kon halen ten opzichte van de 'klassieke' manier van CSS bouwen. Zowel in de categorie bandbreedte verbruik als in de categorie render snelheid.

Het laatste wat je bij zo'n opzet wilt is een generieke bouwsteen voor grid-uitlijning die dankzij zijn verborgen gebreken eigenlijk helemaal niet generiek is, maar ondertussen wel overal in een project door meerdere developers ingezet moet worden om aan hun toebedeelde functionaliteit te implementeren. Dat is een maintenance nachtmerrie in wording. Op zo'n moment kies je de robuustere oplossing; vooral als het nog geen 0.1 kB aan data scheelt.

(Het zou je overigens sieren om in het vervolg niet op de man te spelen. En daarbij houd ik het ook, voordat deze thread nog verder ontspoort.)

Excuus.
Maar ik wil toch even iets rechtzetten want nu gooi je het op OOCSS maar dat heeft met ons verschil van methodes vrij weinig te maken.

In dit geval zou OOCSS dit betekenen:

Hoe het nu is:

Cascading Stylesheet:

.options {
     /* styling van de div */
     overflow:hidden;
}

Met toepassing van OOCSS:

Cascading Stylesheet:

.options {
     /* styling van de div */
}

.overflow {
     overflow:hidden;
}

Het heeft dus gewoon te maken met het kunnen herbruiken van code, en of je dan jouw code of mijn code gebruikt maakt niks uit.

En nogmaals, ieder zijn manieren. Maar jij begon met het verkondigen dat jouw methode beter was, terwijl dat in dit geval helemaal niet zo is.

[ Voor 189% gewijzigd door Verwijderd op 17-03-2012 08:25 ]

[R4gnax]

Vooraf mijn excuses aan poepkop en de lezers van deze thread, maar het lijkt er op dat ik gedwongen wordt nogmaals antwoord te geven omdat mijn woorden uit context gehaald worden. Misschien dat één van de
mods nog een threadsplit o.i.d. toe kan passen om alles weer netjes te maken.

Dat gezegd hebbende ...

Verwijderd schreef op zaterdag 17 maart 2012 @ 08:20:
Excuus.
Maar ik wil toch even iets rechtzetten want nu gooi je het op OOCSS maar dat heeft met ons verschil van methodes vrij weinig te maken.
[...]
Het heeft dus gewoon te maken met het kunnen herbruiken van code, en of je dan jouw code of mijn code gebruikt maakt niks uit.

Excuus, maar volgens mij moet je leren lezen. Ik had het over de filosofie achter structuren zoals OOCSS en hoe deze aansturen op het brede hergebruik van een set in CSS gedefinieerde 'componenten'. Ik gooi dus helemaal niets concreet 'op OOCSS', maar beweer precies wat jij zo vlijtig met voorbeeld hebt herhaaltd het levert problemen op bij het kunnen hergebruiken van code.

En ja, daar maakt het wel degelijk voor uit. Wanneer één bepaalde methode op honderden plekken hergebruikt wordt over tientallen pagina's, door zowel jezelf als jouw collega's, en het voor een aantal daarvan ineens omgezet moet worden is dat een precaire situatie. Dat houdt in dat je òf een andere methode er parallel aan opzet, òf de huidige methode vervangt. De eerste levert meer maintenance op voor de toekomst en onduidelijkheden zoals welke methode vanaf dan leidend wordt voor nieuw gebruik. De tweede levert (tenminste in volwassen development situaties) een meer direct probleem op, namelijk dat het gebruik van de vervangen methode op alle plekken opnieuw getest moet worden.

Verwijderd schreef op zaterdag 17 maart 2012 @ 08:20:
En nogmaals, ieder zijn manieren. Maar jij begon met het verkondigen dat jouw methode beter was, terwijl dat in dit geval helemaal niet zo is.

Joh. Ik dacht dat ik inmiddels redelijk objectief aangetoond had dat dat wel degelijk zo is. Tenzij je natuurlijk alleen even snel iets kleinschaligs in elkaar aan het rammen bent wat nooit meer onderhouden gaat worden. (En dan nog; voor de low cost van 100 bytes extra zou een professional waarschijnlijk alsnog voor maintainability en robuustheid gaan...)

[Verwijderd]

R4gnax schreef op zondag 18 maart 2012 @ 17:40:
Vooraf mijn excuses aan poepkop en de lezers van deze thread, maar het lijkt er op dat ik gedwongen wordt nogmaals antwoord te geven omdat mijn woorden uit context gehaald worden. Misschien dat één van de
mods nog een threadsplit o.i.d. toe kan passen om alles weer netjes te maken.

Dat gezegd hebbende ...


[...]


Excuus, maar volgens mij moet je leren lezen. Ik had het over de filosofie achter structuren zoals OOCSS en hoe deze aansturen op het brede hergebruik van een set in CSS gedefinieerde 'componenten'. Ik gooi dus helemaal niets concreet 'op OOCSS', maar beweer precies wat jij zo vlijtig met voorbeeld hebt herhaaltd het levert problemen op bij het kunnen hergebruiken van code.

En ja, daar maakt het wel degelijk voor uit. Wanneer één bepaalde methode op honderden plekken hergebruikt wordt over tientallen pagina's, door zowel jezelf als jouw collega's, en het voor een aantal daarvan ineens omgezet moet worden is dat een precaire situatie. Dat houdt in dat je òf een andere methode er parallel aan opzet, òf de huidige methode vervangt. De eerste levert meer maintenance op voor de toekomst en onduidelijkheden zoals welke methode vanaf dan leidend wordt voor nieuw gebruik. De tweede levert (tenminste in volwassen development situaties) een meer direct probleem op, namelijk dat het gebruik van de vervangen methode op alle plekken opnieuw getest moet worden.


[...]

Joh. Ik dacht dat ik inmiddels redelijk objectief aangetoond had dat dat wel degelijk zo is. Tenzij je natuurlijk alleen even snel iets kleinschaligs in elkaar aan het rammen bent wat nooit meer onderhouden gaat worden. (En dan nog; voor de low cost van 100 bytes extra zou een professional waarschijnlijk alsnog voor maintainability en robuustheid gaan...)

Dit heeft vrij weinig zin, ik deel je visie niet. Heb ook nog nooit in een team gewerkt die deze visie deelt, om onnodige fixjes te gebruiken want stel dat... Als er iets wijzigt dan zul je het altijd moeten testen, dat hoort er bij. Ben ook nog nooit (grote) sites tegen gekomen die deze fix gebruiken ipv overflow:hidden als het niet nodig is dus volgens mij valt het allemaal wel mee. Als je er verder nog over wilt discussiëren kun je me misschien beter een DM sturen.

[poepkop]

@R4gnax en Nyce: Bedankt voor het kapen van mijn topic, ooit gehoord van PM's? Ik ga expres niet in op het clear:both verhaal, en dan zijn er blijkbaar toch lui die zich geroepen voelen om dit wel te doen...

Maargoed, iemand al een oplossing? Of is Chrome daadwerkelijk buggy?

[Bosmonster]

Aangezien het gedrag onvoorspelbaar is en zelfs wisselt per view en Chrome wat bekende float-bugs heeft denk ik dat die conclusie juist is.

Je kunt even kijken of je het in z'n geheel iets anders kunt opbouwen.

[ Voor 6% gewijzigd door Bosmonster op 21-03-2012 10:31 ]

[Verwijderd]

poepkop schreef op woensdag 21 maart 2012 @ 10:07:
@R4gnax en Nyce: Bedankt voor het kapen van mijn topic, ooit gehoord van PM's? Ik ga expres niet in op het clear:both verhaal, en dan zijn er blijkbaar toch lui die zich geroepen voelen om dit wel te doen...

Maargoed, iemand al een oplossing? Of is Chrome daadwerkelijk buggy?

Volgens mij ben ik ook de enige die met een oplossing is gekomen hoor. Graag gedaan..