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.
Ikzelf zou dit oplossen door overflow:hidden toe te voegen aan #maincontent. Of zeg ik nou wat geks? Zo los ik dat altijd op iig.
Ik las hier overheen, vond het al zo vreemd dat niemand dat nog genoemd had.quote:Op dinsdag 12 maart 2013 11:41 schreef KomtTijd... het volgende:
Elementen toevoegen voor stijl is lelijk. Een <br> is een semantisch element, dus dat maakt het driedubbel lelijk (gebruik dan een span of div). Maar iedereen gebruikt toch al honderd jaar gewoon overflow:hidden op de parent voor dit probleem?
2000 light years from home
Ik gebruik ook overflow: hidden;
Volgens mij heb ik zelfs nog nooit zo iets als een br clearfix gebruikt.
Volgens mij heb ik zelfs nog nooit zo iets als een br clearfix gebruikt.
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
overflow:hidden lijkt me ook niet de gewenste oplossing.
Soms wil je juist dat elementen buiten het parent element niet worden afgekapt, zoals hier (het slotje):
Soms wil je juist dat elementen buiten het parent element niet worden afgekapt, zoals hier (het slotje):
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Daar gebruik ik ook geen overflow hidden.
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Dat zijn over het algemeen ook niet de situaties waarin je een "clearfix"-achtige oplossing nodig hebt.quote:Op dinsdag 12 maart 2013 12:15 schreef mstx het volgende:
overflow:hidden lijkt me ook niet de gewenste oplossing.
Soms wil je juist dat elementen buiten het parent element niet worden afgekapt, zoals hier (het slotje):
[ afbeelding ]
Ik ga aan de slag met Meteor, maar kan daar nu nog weinig zinnigs over zeggen.quote:Op dinsdag 12 maart 2013 08:50 schreef Scorpie het volgende:
[..]
Ook goedheb zelf ervaring met Socket.IO, NowJS & Node zeg maar
Is het "slecht"/ongewenst om het volgende te doen:
| 1 2 3 4 5 | var blaat = true; if(blaat === true){ return "iets"; } |
Ik snap je vraag niet helemaal.quote:Op woensdag 13 maart 2013 18:33 schreef TwenteFC het volgende:
Is het "slecht"/ongewenst om het volgende te doen:
[ code verwijderd ]
Misschien een beetje onduidelijk uitgelegd ja.quote:
Maar ik kreeg als feedback op mijn code dat ik niet
| 1 2 3 4 5 | var blaat = true; if(blaat === true){ return "iets"; } |
maar
| 1 2 3 4 5 | var blaat = true; if(blaat){ return "iets"; } |
Moest doen, omdat het anders verwarring kon opleveren.
Maar persoonlijk vind ik voorbeeld 1 veel duidelijker om te lezen.
Als je zeker weet dat iets altijd waar- of niet waar is, dan zou ik ook voor het tweede voorbeeld gaan. Maar het blijft een persoonlijke keuze.
Maar je weet eigenlijk niet eens of er wel een boolean inzit, een string zou ook doorgaan voor true. Dat was mijn gedachte er achter.quote:
Als je zeker weet dat iets altijd waar- of niet waar is, dan zou ik ook voor het tweede voorbeeld gaan. Maar het blijft een persoonlijke keuze.
Was voor een schoolopdracht, en zit er een beetje mee dat ik minpunten kreeg omdat dit voor verbetering vatbaar was.
Op mijn werk hebben we juist als standaard dat je zo strikt mogelijk moet zijn, dus het eerste voorbeeld heeft bij ons de voorkeur.
Ook mijn gedachte, maar het is dus echt puur een keuze?quote:
Op mijn werk hebben we juist als standaard dat je zo strikt mogelijk moet zijn, dus het eerste voorbeeld heeft bij ons de voorkeur.
Ook in een Loose Typed taal als Javascript?
In Java of iets dergelijks waar de variable al gecast is als een boolean dan kan ik het nog begrijpen dat voorbeeld 2 misschien makkelijker is.
Het is een keuze in zoverre dat 95% van de tijd het wel goed zal komen, mits je een beetje fatsoenlijk met je variabelen omgaat. Maar juist die 5% die ontzettend veel debuggen kan vereisen is ons het niet waard, waardoor we liever voor de zekereid wat strikter werken.
quote:
Zie ook http://stackoverflow.com/(...)en-and-in-javascript
Ik snap het verschil tussen == en ===.Als ik == had geschreven dan had ik ze gelijk gegeven, want if(val) is inprincipe het zelfde als if(val == true).
Maar die === had ik dus puur gedaan om ook te controleren of het een boolean is.
Bedankt voor het antwoorden ik weet genoeg, morgen de leraar maar even aanspreken.
Op stackoverflow zijn ze het ook niet allemaal met elkaar eens:http://stackoverflow.com/(...)n-in-an-if-statement
Ik moet zeggen dat hun antwoorden wel hout snijden. Als je je variabele altijd zelf zet als true of false weet je dus altijd dat het een boolean is. Het wordt anders als je ingewikkeldere scripts hebt waarbij je niet 100% weet hoe een variabele binnenkomt. Maar ik vind het wel wat overtrokken van je docent om hier minpunten op te geven.
Als je zeker weet dat je true of false terugkrijgt kun je best if(blaa) gebruiken. Wat is input van je if? Dan kunnen we bekijken of je morgen je docent terecht mag afbranden of niet.
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
quote:Op woensdag 13 maart 2013 23:46 schreef boem-dikkie het volgende:
Als je zeker weet dat je true of false terugkrijgt kun je best if(blaa) gebruiken. Wat is input van je if? Dan kunnen we bekijken of je morgen je docent terecht mag afbranden of niet.
We zijn er al uit, als je geen === true doet dan komt hij niet door de unit test.
Passen ze dan voor de unittest een variabele in je functie aan of gebruik je iets dat (te) globaal van scope is?quote:
[..]
Er moet gewoon een bepaalde uitkomst uit die functie komen, wat niet correct gebeurt als je er bijv. een string in gooit.quote:
[..]
Passen ze dan voor de unittest een variabele in je functie aan of gebruik je iets dat (te) globaal van scope is?
En als je moet vergelijken met === heb je het over een variabele die van buiten de functie kan worden beinvloed. Zoals een parameter.quote:
[..]
Er moet gewoon een bepaalde uitkomst uit die functie komen, wat niet correct gebeurt als je er bijv. een string in gooit.
Hij zit in een array, die die inderdaad globaal te bereiken is ja.quote:
[..]
En als je moet vergelijken met === heb je het over een variabele die van buiten de functie kan worden beinvloed. Zoals een parameter.
