DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Als alternatief voor Underscore kan ik SugarJS aanbevelen.
Heeft ook de mogelijkheid om een eigen download samen te stellen door onderdelen weg te laten.
Heeft ook de mogelijkheid om een eigen download samen te stellen door onderdelen weg te laten.
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
When the student is truly ready, the teacher will disappear.
Volgens mij is het probleem dat parents niet over hun children heen kunnen vallen qua z-index. Daarom staat je plaatje altijd over de achtergrond heen, waardoor je de achtergrond niet ziet.quote:Op maandag 31 maart 2014 17:08 schreef Xaryna het volgende:
Ik was aan het prutsen voor de lol, en ik heb een probleem
Ik heb een pagina gemaakt met html/css waarbij er een zooi afbeeldingen naast elkaar staan, met float. Elke afbeelding staat in een eigen div, en alle divs met afbeeldingen staan in een div.
Nou heb ik met jQuery er een mooi dingetje opgepleurt waardoor de afbeeldingen faden naar 0,3 opacity, maar ik wil dat er achter die afbeeldingen een logo komt te staan. Dit lukt me niet! Ik heb een backgroundimg bij de afbeeldingen geprobeerd, en een afbeelding in de divs van de afbeeldingen. En het werkt niet. Als ik height en width opgeef bij de backgroundimg, float de boel niet meer. Wat doe ik verkeerd?
Voorbeeld html:
[ code verwijderd ]
Voorbeeld CSS:
[ code verwijderd ]
.producten div {} werkte ook niet en ik doe vast iets doms ergens.
Ik zou er zoiets van maken, dan heb je dit probleem niet:
| 1 2 3 4 5 6 7 8 9 10 | <ul class="producten"> <li> <img src="product1.jpg" alt="" /> <img class="logo" src="logo.png" alt="" /> </li> <li> <img src="product2.jpg" alt="" /> <img class="logo" src="logo.png" alt="" /> </li> </ul> |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | .producten li { position: relative; float: left; width: 300px; height: 200px; } .producten li .logo { position: absolute; top: 10px; left: 10px; } |
Of bedoel je dat je het logo echter ACHTER je plaatje wilt hebben? Is dat waarom je het plaatje ook doorzichtig maakt? In dat geval zou dit moeten werken:
Er zat sowieso volgens mij een fout in de syntax van je background-image-regel. Ik weet niet uit m'n hoofd wat de shorthandnotatie daarvan is, maar ik vermoed dat het alleen werkt met de key "background" en niet met "background-image".
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | .producten div { display: block; height: 200px; width: 300px; margin: 10px 0px 10px 15px; float: left; background-image: url("logo.png"); background-repeat: no-repeat; background-position: 10px 10px; } .producten img { opacity: 0.3; } |
Er zat sowieso volgens mij een fout in de syntax van je background-image-regel. Ik weet niet uit m'n hoofd wat de shorthandnotatie daarvan is, maar ik vermoed dat het alleen werkt met de key "background" en niet met "background-image".
Het werkt nu wel, ik heb nu idd de hele bups op de div gezet ipv de img. Dank je, hij doet het!quote:Op maandag 31 maart 2014 17:32 schreef Tijn het volgende:
Of bedoel je dat je het logo echter ACHTER je plaatje wilt hebben? Is dat waarom je het plaatje ook doorzichtig maakt? In dat geval zou dit moeten werken:
[ code verwijderd ]
Er zat sowieso volgens mij een fout in de syntax van je background-image-regel. Ik weet niet uit m'n hoofd wat de shorthandnotatie daarvan is, maar ik vermoed dat het alleen werkt met de key "background" en niet met "background-image".
Chocoladetaartjes.
Op donderdag 25 juli 2013 18:44 schreef trovey het volgende: Evert, de vrouwelijke versie. :P
Op donderdag 25 juli 2013 18:44 schreef trovey het volgende: Evert, de vrouwelijke versie. :P
"display: block" is trouwens niet nodig als je een element float, want hij wordt dan automatisch een block.
Ik kwam dat tegen bij zoeken naar oplossingen.quote:Op maandag 31 maart 2014 17:50 schreef Tijn het volgende:
"display: block" is trouwens niet nodig als je een element float, want hij wordt dan automatisch een block.
Het resultaat is trouwens echt foeilelijk.
Chocoladetaartjes.
Op donderdag 25 juli 2013 18:44 schreef trovey het volgende: Evert, de vrouwelijke versie. :P
Op donderdag 25 juli 2013 18:44 schreef trovey het volgende: Evert, de vrouwelijke versie. :P
Ik mis toch wel multithreading in JavaScript. Ja, je hebt workers maar dan kun je niks doen met de DOM. Ik snap het wel, omdat het anders niet thread safe is, maar toch.
Een kaartenmap die een JSON uitleest en daarvan 60.000 markers op een kaart zit. Jullie kunnen je voorstellen dat die dan even hangt.
setTimeout was geen oplossing.
Een kaartenmap die een JSON uitleest en daarvan 60.000 markers op een kaart zit. Jullie kunnen je voorstellen dat die dan even hangt.
setTimeout was geen oplossing.
Ik heb ooit een wrapper functie gemaakt die een for-loop nabootst maar op gezette intervals een setTimeout gebruikt om de browser even ruimte te geven. Je kan dan aangeven hoeveel iteraties per keer je wil laten draaien, heeft voor mij een bepaalde pagina waar duizenden records in moesten worden verwerkt een boel performance-problemen opgelost. Zal 'm even opzoeken.
Thanks! Dat zou mij erg helpen.quote:
Ik heb ooit een wrapper functie gemaakt die een for-loop nabootst maar op gezette intervals een setTimeout gebruikt om de browser even ruimte te geven. Je kan dan aangeven hoeveel iteraties per keer je wil laten draaien, heeft voor mij een bepaalde pagina waar duizenden records in moesten worden verwerkt een boel performance-problemen opgelost. Zal 'm even opzoeken.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | function fragmentedFor(arguments) { var fragmentLength, totalLoops, runEachLoop, runWhenDone, start; var init = function() { fragmentLength = arguments.fragmentLength || 10; totalLoops = arguments.totalLoops; runEachLoop = arguments.runEachLoop; runWhenDone = arguments.runWhenDone; start = arguments.start || 0; runNextFragment(); } var runNextFragment = function() { var end = start + fragmentLength; for(var i = start; i < Math.min(end, getTotal()); i++) { runEachLoop( i ); } start += fragmentLength; if(start < getTotal()) { setTimeout(runNextFragment, 1); } else { runWhenDone(); } } var getTotal = function() { // allows totalLoops argument to be either a variable or a function return typeof(mightBeAFunction) === 'function'; } init(); } |
Weet niet of 'ie een beetje netjes is, maar hij werkt als volgt:
ipv bijvoorbeeld
| 1 2 3 4 5 6 | for(var i = 0; i < 10000; i++) { console.log(i); } doeIetsNaDeForLoop(); |
doe je
| 1 2 3 4 5 6 7 8 9 | fragmentedFor({ fragmentLength: 100, // aantal iteraties door de for-loop per keer, optioneel. default is 10 totalLoops: 10000, runEachLoop: function(i) { console.log(i); }, runWhenDone: doeIetsNaDeForLoop, start: 0 // optioneel, default is al 0 }); |
runEachLoop is dus de functie die in de body van for() staat, runWhenDone is een callback functien= als 'ie klaar is.
totalLoops kan zowel een nummer als een functie zijn (die dus een getal moet returnen), dit had ik ooit nodig omdat het totaal werd verminderd doordat de runEachLoop elementen uit een array haalde en dus de loop onderweg korter werd.
Google maps? Dan kan je sowieso clusters gebruiken.quote:Op dinsdag 1 april 2014 21:19 schreef robin007bond het volgende:
Ik mis toch wel multithreading in JavaScript. Ja, je hebt workers maar dan kun je niks doen met de DOM. Ik snap het wel, omdat het anders niet thread safe is, maar toch.
Een kaartenmap die een JSON uitleest en daarvan 60.000 markers op een kaart zit. Jullie kunnen je voorstellen dat die dan even hangt.
setTimeout was geen oplossing.
En dat zijn wel lomp veel markers. Ben benieuwd naar de use-case, want dat lijkt me geen werkbare situatie.
Heel veel groetjes, Catch22
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
Ja, het lijkt mij op het eerste gezicht niet heel user friendly om 60.000 markers aan te bieden, los van de performance.quote:Op dinsdag 1 april 2014 22:40 schreef Catch22- het volgende:
[..]
Google maps? Dan kan je sowieso clusters gebruiken.
En dat zijn wel lomp veel markers. Ben benieuwd naar de use-case, want dat lijkt me geen werkbare situatie.
[ Bericht 0% gewijzigd door Tijn op 02-04-2014 00:47:10 ]
ik zou even teruggaan naar de klant.
Inderdaad. Hoe valt 60k markers in godsnaam te verantwoorden. 
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Het belang van goede tutorials om iets te lerentwitter:SlexAxton twitterde op donderdag 13-03-2014 om 21:29:32 Great. I read the wrong <canvas> tutorial and now there's oil paint all over my monitor. reageer retweet
Great. I read the wrong <canvas> tutorial and now there's oil paint all over my monitor. 
Whether or not you can become great at something, you can always become better.
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
Waarom niet?quote:Op woensdag 2 april 2014 08:35 schreef boem-dikkie het volgende:
Inderdaad. Hoe valt 60k markers in godsnaam te verantwoorden.
Je hebt databases met locaties van bomen, OV haltes, horecagelegenheden en zo nog veel meer. Dan kom je makkelijk aan de 60K. Dat het niet verstandig is om ze allemaal tegelijk te laden, dat is een ander verhaal.
Daarom dus.quote:Op woensdag 2 april 2014 18:00 schreef Maringo het volgende:
[..]
Waarom niet?
Je hebt databases met locaties van bomen, OV haltes, horecagelegenheden en zo nog veel meer. Dan kom je makkelijk aan de 60K. Dat het niet verstandig is om ze allemaal tegelijk te laden, dat is een ander verhaal.
Clusters gebruik ik al.quote:
[..]
Google maps? Dan kan je sowieso clusters gebruiken.
En dat zijn wel lomp veel markers. Ben benieuwd naar de use-case, want dat lijkt me geen werkbare situatie.
En er komen nog filteropties en dergelijke. Dus dat komt wel goed.
Die laden alleen op het moment dat de gebruiker kiest de gegevens op te halen. Maar als de gebruiker alles wil zien dan krijgt hij ook alles te zien.Zat al te denken dat ik alleen markers uit een bepaald gebied ophaal om het voor tablets wat beter te maken.
[ Bericht 6% gewijzigd door #ANONIEM op 02-04-2014 18:55:12 ]
In clusters maakt dat toch weinig uit. Voorbeeld:quote:
Je kunt een gebruiker nooit 60.000 markers presenteren op een kaart. Daar heeft niemand wat aan.
http://leaflet.github.io/(...)realworld.50000.html
Tiles doen het niet in het voorbeeld.
[ Bericht 3% gewijzigd door #ANONIEM op 02-04-2014 19:12:16 ]
Maar dan presenteer je geen 60.000 markers, dat is juist het punt
De performance van je voorbeeld is trouwens best acceptabel toch? En dat is met 50.000 markers, dus waarom zou 60.000 dan een probleem zijn?
De performance van je voorbeeld is trouwens best acceptabel toch? En dat is met 50.000 markers, dus waarom zou 60.000 dan een probleem zijn?
Oké, anders verwoord. 60.000 markers worden dus nooit in één keer gepresenteerd. Geen zorgen.quote:
Maar dan presenteer je geen 60.000 markers, dat is juist het punt
De performance van je voorbeeld is trouwens best acceptabel toch? En dat is met 50.000 markers, dus waarom zou 60.000 dan een probleem zijn?
En de performance is wel acceptabel, maar probeer het maar even op een mobiel apparaat uit.
Daarnaast is het bij mij nog een JSON die via asynchroon wordt ingelezen en waar nog wat info bij zit.
Ik zou de hele boel filteren voordat je het aan de user presenteert. Bij voorkeur al in de service die de JSON genereert. Het is gewoon veel te veel data voor een persoon om te kunnen verwerken. Je kunt denk ik beter de service een paar keer aanroepen en nieuwe data opvragen dan dit allemaal in 1x naar de client te willen pushen, laat staan het in de DOM te gooien.quote:
[..]
Oké, anders verwoord. 60.000 markers worden dus nooit in één keer gepresenteerd. Geen zorgen.
En de performance is wel acceptabel, maar probeer het maar even op een mobiel apparaat uit.
Dat is ook de bedoeling, maar er kan een user zijn die geen filteropties seelecteert.quote:
[..]
Ik zou de hele boel filteren voordat je het aan de user presenteert. Bij voorkeur al in de service die de JSON genereert. Het is gewoon veel te veel data voor een persoon om te kunnen verwerken. Je kunt denk ik beter de service een paar keer aanroepen en nieuwe data opvragen dan dit allemaal in 1x naar de client te willen pushen, laat staan het in de DOM te gooien.
En dit wordt nu al in de JSON gegenereerd server-side. Don't worry. Maar ik wil het enkel voor het zeldzame geval dat een gebruiker echt alle filteropties uitzet en vervolgens op "Gegevens ophalen" drukt o.i.d. De JSON wordt dynamisch gegenereerd op basis van de filteropties. Ik ga geen 60.000 items in een JSON iedere keer versturen.
[ Bericht 8% gewijzigd door #ANONIEM op 02-04-2014 20:07:09 ]
