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.
Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.quote:
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?
jQuery is een framework/library geschreven in de taal Javascript. Dat maakt het twee verschillende dingen.quote:
JS is prima leesbaar. jQuery is merkbaar vertragend en gebruikt settimeout voor scroll events ipv RAF. 1kb kost ruwweg 1ms om te parsen en jQuery is 87kb ofzo. Dat vind ik behoorlijk wat na alle andere zaken die vertragen.quote:Op maandag 23 november 2015 22:05 schreef Catch22- het volgende:
[..]
Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.
“Specialization is for insects”.—Robert Heinlein
Een snelheidsvergelijking tussen document.getElementById('foo') en $('#foo'):quote:
[..]
Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.
http://jsperf.com/getelementbyid-vs-jquery-id/180
Tip: probeer die test ook eens andere browsers.
Ja, met zoveel iteraties ofzo merk je het wel.quote:Op dinsdag 24 november 2015 08:14 schreef Light het volgende:
[..]
Een snelheidsvergelijking tussen document.getElementById('foo') en $('#foo'):
http://jsperf.com/getelementbyid-vs-jquery-id/180
Tip: probeer die test ook eens andere browsers.
Dat klopt.quote:
[..]
JS is prima leesbaar. jQuery is merkbaar vertragend en gebruikt settimeout voor scroll events ipv RAF. 1kb kost ruwweg 1ms om te parsen en jQuery is 87kb ofzo. Dat vind ik behoorlijk wat na alle andere zaken die vertragen.
Mijn invalshoek is iets anders denk ik. Ik werk voor klanten die graag enige vorm van efficientie in bouw willen. Ik weet zeker dat als je goed en gestructureerd werkt met jQuery dat je echt niet merkbaar vertraging gaat krijgen in webapps. Het gaat wel uitmaken als je animatie-dependend websites maakt.
Ik werk nu veel met AngularJS en dat is ook niet super-performant, maar ik kan er wel erg snel mee developen en de vertraging in de UI is voor de gebruiker niet merkbaar.
Alles draait om een efficiente dom en efficiente code.
Het is altijd een afweging tussen developmenttijd en performance. Als je zelf een Proof of Concept doet en infinite tijd hebt is het heel leuk als je uren bezig kan zijn om ms van je render af te snoepen. En reallife situaties kan dat simpelweg niet uit.
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?
Met een webapp laadt en parse je al je assets als het goed is maar eenmalig, op dom updates en events na. Dan is wat laadtijd wel te doen.
Een website is niks meer dan een simpel documentje dus dan vind ik zware libraries onzin. Al die react/angular/ajax driven webpagina-navigatie vind ik ook altijd kut omdat de state niet lekker in de historie staat waardoor tussen pagina's navigeren (terug/vooruit) altijd butje is. Het kan wel, maar de praktijk wijst meestal anders uit.
Bij mijn projecten past vrijwel altijd de html, css en JS in 16kb gzipped, de css en JS zet ik dan ook mooi embedded. Afbeeldingen hebben een placeholder (kleur) dus meestal staat de volledige layout binnen 250ms voor je neus.
[ Bericht 0% gewijzigd door n8n op 25-11-2015 13:55:23 ]
Een website is niks meer dan een simpel documentje dus dan vind ik zware libraries onzin. Al die react/angular/ajax driven webpagina-navigatie vind ik ook altijd kut omdat de state niet lekker in de historie staat waardoor tussen pagina's navigeren (terug/vooruit) altijd butje is. Het kan wel, maar de praktijk wijst meestal anders uit.
Bij mijn projecten past vrijwel altijd de html, css en JS in 16kb gzipped, de css en JS zet ik dan ook mooi embedded. Afbeeldingen hebben een placeholder (kleur) dus meestal staat de volledige layout binnen 250ms voor je neus.
[ Bericht 0% gewijzigd door n8n op 25-11-2015 13:55:23 ]
“Specialization is for insects”.—Robert Heinlein
Het is natuurlijk gewoon makkelijker en efficiënter om een framework in je project te knallen dat al het 'zware werk' voor je doet. Natuurlijk kan ik zelf een functie gaan schrijven om AJAX-requests af te handelen, maar waarom zou ik dat doen als de goede mensen van jQuery - en dat zijn echt betere programmeurs dan ik ben 
- al een implementatie hebben gemaakt die door miljoenen mensen wordt gebruikt? Zelfde met data binding. Zou ik vast zelf kunnen maken, maar kost me uren/dagen. KnockoutJS en AngularJS doen dat gewoon veel beter dan ik.
Tuurlijk zijn er ook genoeg nadelen. Performance gaat erop achteruit (hoewel je je zeker niet blind moet staren op benchmarks, real world performance is het enige dat telt), en als je een of andere edge case tegenkomt en tegen bugs aan loopt ben je overgeleverd aan de grillen van de maker van het framework. Als je eigen code niet werkt heb je óók een probleem, maar dat is makkelijker te fixen
Het is, zoals Catch22 ook zegt, een afweging. Mijn baas wordt niet blij als ik anderhalf keer zo lang over een project doe omdat ik zo nodig alles zelf moet gaan zitten maken terwijl het er kwalitatief niet aantoonbaar beter van wordt Die heeft geen boodschap aan mijn mooie zelfgemaakte functies.
- al een implementatie hebben gemaakt die door miljoenen mensen wordt gebruikt? Zelfde met data binding. Zou ik vast zelf kunnen maken, maar kost me uren/dagen. KnockoutJS en AngularJS doen dat gewoon veel beter dan ik.Tuurlijk zijn er ook genoeg nadelen. Performance gaat erop achteruit (hoewel je je zeker niet blind moet staren op benchmarks, real world performance is het enige dat telt), en als je een of andere edge case tegenkomt en tegen bugs aan loopt ben je overgeleverd aan de grillen van de maker van het framework. Als je eigen code niet werkt heb je óók een probleem, maar dat is makkelijker te fixen
Het is, zoals Catch22 ook zegt, een afweging. Mijn baas wordt niet blij als ik anderhalf keer zo lang over een project doe omdat ik zo nodig alles zelf moet gaan zitten maken terwijl het er kwalitatief niet aantoonbaar beter van wordt
Die heeft geen boodschap aan mijn mooie zelfgemaakte functies.
"You wanna be bald? Do what I did: wait a while. In the meantime, there is no excuse for running around looking like a freshly circumcised dick."
Er is niks mis met het gebruiken van een framework, als je er maar nette code mee schrijft. Te vaak zie ik nog (en echt niet alleen van beginners, ook van grote bureaus) gare jQuery-code met van alles keihard in de Javascript gezet (strings, id's van elementen, URL's etc), geen namespacing, meerdere document-ready's, anonieme functies die gebind worden etc etc. Javascript is al een taal waar je heel makkelijk 'slechte' code mee kunt schrijven en een framework als jQuery maakt dat nog 10x makkelijker.
Nee.
Ajax was alleen ff kak omdat IE dwars lag. Je hebt ook micro.js of 140medly wat zeer kleine libraries zijn voor die basic dingen die je 20 keer nodig hebt.
“Specialization is for insects”.—Robert Heinlein
Die laadtijd discussie is sowieso krom. De kans dat iemand op jouw website komt die nog nooit een website met jQuery of AngularJS gezien heeft, is nihil. Als je gewoon de bekende CDN's gebruikt staat dat framework dus al lang en breed in zijn cache, misschien zelfs wel precompiled? Dik kans dus dat een jQuery functie aanroepen in de praktijk nog sneller is dan je eigen functie aanroepen die eerst nog van jouw webserver gehaald moet worden.
quote:
Ajax was alleen ff kak omdat IE dwars lag. Je hebt ook micro.js of 140medly wat zeer kleine libraries zijn voor die basic dingen die je 20 keer nodig hebt.
Maar niemand dwingt je toch om IE in deze te gebruiken als je andere alternatieven voorhanden hebt?
Maar sommige van je users gebruiken wellicht wel (een verouderde versie van) IE.quote:Op woensdag 25 november 2015 15:46 schreef Iwanius het volgende:
[..]
Tja, zeg dat tegen de klanten Als je voor een bedrijf aan de slag gaat dan kom je niet weg met "dan moet je maar een fatsoenlijke browser gebruiken", het spul dat je maakt moet gewoon goed werken in de versie van IE die ze op dat moment draaien. Al moet ik zeggen dat zelfs de meest trage organisaties die ik ken allemaal wel minimaal IE9 hebben tegenwoordig, de meeste 10 of zelfs 11. En daar valt allemaal goed voor te ontwikkelen, alleen IE8 is echt een draak van een ding.
CDN's durf ik trouwens nooit echt op te vertrouwen. Ik zal wel lichtelijk paranoïde zijn, maar wie weet hoe lang je klant jouw product wil blijven gebruiken, en wie weet wat er met zo'n CDN gebeurt in de toekomst? Ik lever frameworks altijd gewoon mee, dan moeten ze maar eenmalig een paar honderd kB méér downloaden. Better to be safe than sorry. Ik heb ook al eens meegemaakt dat de klant de CDN van Google, nota bene, gewoon doodleuk blokkeerde
Heel het product lag op zijn gat, want het prachtige Dojo framework waar het op gebaseerd is kon niet worden geladen. En dan kun je gaan lopen steggelen met de IT-afdeling en ben je weer dagen verder voordat ze hun firewall hebben aangepast, terwijl het humeur van de klant langzaam tot onder het vriespunt zakt 
Als je voor een bedrijf aan de slag gaat dan kom je niet weg met "dan moet je maar een fatsoenlijke browser gebruiken", het spul dat je maakt moet gewoon goed werken in de versie van IE die ze op dat moment draaien. Al moet ik zeggen dat zelfs de meest trage organisaties die ik ken allemaal wel minimaal IE9 hebben tegenwoordig, de meeste 10 of zelfs 11. En daar valt allemaal goed voor te ontwikkelen, alleen IE8 is echt een draak van een ding.CDN's durf ik trouwens nooit echt op te vertrouwen. Ik zal wel lichtelijk paranoïde zijn, maar wie weet hoe lang je klant jouw product wil blijven gebruiken, en wie weet wat er met zo'n CDN gebeurt in de toekomst? Ik lever frameworks altijd gewoon mee, dan moeten ze maar eenmalig een paar honderd kB méér downloaden. Better to be safe than sorry. Ik heb ook al eens meegemaakt dat de klant de CDN van Google, nota bene, gewoon doodleuk blokkeerde
Heel het product lag op zijn gat, want het prachtige Dojo framework waar het op gebaseerd is kon niet worden geladen. En dan kun je gaan lopen steggelen met de IT-afdeling en ben je weer dagen verder voordat ze hun firewall hebben aangepast, terwijl het humeur van de klant langzaam tot onder het vriespunt zakt
"You wanna be bald? Do what I did: wait a while. In the meantime, there is no excuse for running around looking like a freshly circumcised dick."
Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.quote:
[..]
“Specialization is for insects”.—Robert Heinlein
quote:Op woensdag 25 november 2015 17:01 schreef n8n het volgende:
[..]
Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.
Zelfs Microsoft zelf ondersteunt IE8 in ieder geval niet meer op hun eigen website kwam ik gister achter.
Voordeel van bedrijfsautomatisering : je kan klanten de optie geven.quote:
[..]
Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.
Support voor oude meuk
Klaar voor de toekomst
Kiezen ze vaak het tweede.
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?
quote:
[..]
Voordeel van bedrijfsautomatisering : je kan klanten de optie geven.
Support voor oude meuk
Klaar voor de toekomst
Kiezen ze vaak het tweede.
Zit hem vooral ook in de manier van uitleggen richting de klant/werkgever inderdaad.Zit nogal een verschil tussen:
1. "We sluiten nu X% van onze klanten uit omdat we ze niet ondersteunen. Wil jij hier geld in steken?"
2. "X% van onze klanten loopt nog fors achter qua browserupdates, maar volgens de statistieken daalt dit aantal best snel. Wil jij hier geld in steken?"
ik werk met gecontroleerde omgevingen natuurlijk, dat scheelt. Als de klant overal chrome, Firefox, edge of andere nieuwe browsers kan installeren is dat dus geen issue.quote:Op woensdag 25 november 2015 20:15 schreef TwenteFC het volgende:
[..]
Zit nogal een verschil tussen:
1. "We sluiten nu X% van onze klanten uit omdat we ze niet ondersteunen. Wil jij hier geld in steken?"
2. "X% van onze klanten loopt nog fors achter qua browserupdates, maar volgens de statistieken daalt dit aantal best snel. Wil jij hier geld in steken?"
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?
Die luxe heb ik dan niet, maar uitzonderingen daargelaten en mits het geen specifieke vereiste is gaan wij sowieso niet meer optimaliseren voor verouderde browsers. Als blijkt dat het in IE8 een grote bende is dan laten wij het lekker zo. Het is de investering vaak toch niet meer waard.quote:
[..]
ik werk met gecontroleerde omgevingen natuurlijk, dat scheelt. Als de klant overal chrome, Firefox, edge of andere nieuwe browsers kan installeren is dat dus geen issue.
Een grote melding in beeld met een link naar Chrome & Firefox en dat is dat.
die vergelijking klopt niet helemaal want in beide gevallen heb je applicatiecode, die van jQuery is potentieel korter, native waarschijnlijk sneller uitgevoerd. Daarnaast is er een wildgroei aan jq versies en cdn’s.quote:Op woensdag 25 november 2015 15:17 schreef KomtTijd... het volgende:
Die laadtijd discussie is sowieso krom. De kans dat iemand op jouw website komt die nog nooit een website met jQuery of AngularJS gezien heeft, is nihil. Als je gewoon de bekende CDN's gebruikt staat dat framework dus al lang en breed in zijn cache, misschien zelfs wel precompiled? Dik kans dus dat een jQuery functie aanroepen in de praktijk nog sneller is dan je eigen functie aanroepen die eerst nog van jouw webserver gehaald moet worden.
Onder de streep is het allemaal wel prima, afhankelijk van de ‘requirements’ en voorkeur.
[ Bericht 5% gewijzigd door n8n op 25-11-2015 22:43:15 ]
“Specialization is for insects”.—Robert Heinlein
Het laat wel zien dat het maken van een jQuery object een 'dure' actie is, en dat het dus slim is om die objecten te hergebruiken. En je kunt die snelheden ook in verschillende browsers vergelijken (en zien dat Firefox veel sneller is, zeker als het aankomt op document.getElementById())quote:Op dinsdag 24 november 2015 09:17 schreef Catch22- het volgende:
[..]
Ja, met zoveel iteraties ofzo merk je het wel.
Sowieso al je variabele in de lokale scope cachen, ook -zeker- in libraries.
“Specialization is for insects”.—Robert Heinlein
Ja dat sowieso. Maar dat is gewoon common sense imo. Als je geen idee hebt wat je precies aan het doen bent, kan je vanilla js ook sloom makenquote:
[..]
Het laat wel zien dat het maken van een jQuery object een 'dure' actie is, en dat het dus slim is om die objecten te hergebruiken. En je kunt die snelheden ook in verschillende browsers vergelijken (en zien dat Firefox veel sneller is, zeker als het aankomt op document.getElementById())
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?
Kun je met een .innerHTML() of .html()-functie geen text in een <input type="text"> dingetje zetten? In een <textarea> werkt het wel.
Die heeft een .value property.quote:
Kun je met een .innerHTML() of .html()-functie geen text in een <input type="text"> dingetje zetten? In een <textarea> werkt het wel.
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, weet ik. Maar die value kan ik dus niet aanpassen met .innerhtml()? Is daar een andere manier voor?quote:
[..]
Die heeft een .value property.
Op zich is <textarea> gebruiken geen groot probleem, het ziet er gewoon minder netjes uit.
dan check je toch de tagName even?quote:
[..]
Ja, weet ik. Maar die value kan ik dus niet aanpassen met .innerhtml()? Is daar een andere manier voor?
Op zich is <textarea> gebruiken geen groot probleem, het ziet er gewoon minder netjes uit.
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?
Juist. Met document.getElementById("element").value = "whatever" lukt het wel. Bedankt voor de hulp.quote:
[..]
dan check je toch de tagName even?
Ik heb genoeg code gezien waarbij dingen die common sense zouden moeten zijn dat toch niet blijken te zijn.quote:
[..]
Ja dat sowieso. Maar dat is gewoon common sense imo. Als je geen idee hebt wat je precies aan het doen bent, kan je vanilla js ook sloom maken
Het helpt overigens wel als je een IDE gebruikt die je vertelt wat je aan niet-gebruikte variabelen hebt en waar je dingen kunt optimaliseren.
Sowieso in JSHint/Lint handig, ongebruikte variabelen zou de ugliefier er uit moeten vissen.
“Specialization is for insects”.—Robert Heinlein
Dat een uglifier die variabelen er alsnog uit haalt, is maar de helft van de oplossing. Als ik die code later bekijk/bewerk, pak ik namelijk de normale versie en daar staat die variabele nog steeds in.quote:
Sowieso in JSHint/Lint handig, ongebruikte variabelen zou de ugliefier er uit moeten vissen.
Dat je tijdens development ongebruikte variabelen hebt, snap ik heel goed. Maar voordat je iets 'af' kunt noemen, moeten ze wel weg zijn. Ongeacht de programmeertaal die je gebruikt. Overigens meldt jshint unused variables ook.
Over optimalisatie gesproken, ik kwam laatst deze site tegen
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.200 requests op de homepage, 1.9MB aan javascriptbestanden, 1.7MB aan css en 4MB aan svg's
Dat logo bovenin is 1MB_____!
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.
👾
quote:
Over optimalisatie gesproken, ik kwam laatst deze site tegenDat is tegenwoordig de norm. Hebben we hier een discussie over jQuery terwijl die social button plug-ins met like indicatie easy 500kb binnenhalen met 20 requestsSPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.200 requests op de homepage, 1.9MB aan javascriptbestanden, 1.7MB aan css en 4MB aan svg's
Dat logo bovenin is 1MB
http://www.webperformance(...)b-page-1795-kb-size/
En Light, ben het dan ook helemaal met je eens.“Specialization is for insects”.—Robert Heinlein
quote:
Over optimalisatie gesproken, ik kwam laatst deze site tegenDat is zodat het logo er nog steeds goed uitziet voor de mensen met een scherm van 4000x5000px.SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.200 requests op de homepage, 1.9MB aan javascriptbestanden, 1.7MB aan css en 4MB aan svg's
Dat logo bovenin is 1MB
Anyhow, wat gebruik jij om te zien hoeveel requests/js-bestanden/etc. zo'n pagina gebruikt?
De inspector kan dat en anders heb je extensies als yslow.
De rest van de foto's is trouwens 1 grote pixelbrij, dus alleen het - SVG potentiële - logo is voor 2015 schermen
De rest van de foto's is trouwens 1 grote pixelbrij, dus alleen het - SVG potentiële - logo is voor 2015 schermen
“Specialization is for insects”.—Robert Heinlein
Het hele idee van SVG is toch dat je een hele kleine vectorafbeelding van een paar kB hebt die je oneindig kan schalen?quote:
[..]
Dat is zodat het logo er nog steeds goed uitziet voor de mensen met een scherm van 4000x5000px.
Gewoon de standaard developer tools (F12) van firefox/chromequote:Anyhow, wat gebruik jij om te zien hoeveel requests/js-bestanden/etc. zo'n pagina gebruikt?
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.
👾
quote:
Over optimalisatie gesproken, ik kwam laatst deze site tegenEen stap terug zou het design al zijn afgeschoten door een kundige UX'er.SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.200 requests op de homepage, 1.9MB aan javascriptbestanden, 1.7MB aan css en 4MB aan svg's
Dat logo bovenin is 1MBOp maandag 29 september 2008 11:45 schreef HostiMeister het volgende:
Dat is zeg maar de Nederlandse taal op een vuige keukentafel voorover buigen en hem dan zonder glijmiddel anaal verkrachten. :'(
Kundige UX-ers vind je niet bij de goedkope wordpress studio die 20 van zulke sites per jaar knalt en alleen naar awwwards themeforrest kijken wat een beetje gangbaar is.quote:
[..]
Een stap terug zou het design al zijn afgeschoten door een kundige UX'er.
“Specialization is for insects”.—Robert Heinlein
N00b-vraag: wat zijn nou de grootste doodzondes die op deze site begaan zijn, die een kundige UX'er nooit zou maken?quote:
[..]
Een stap terug zou het design al zijn afgeschoten door een kundige UX'er.
Witte tekst op een gele achtergrond for starters...quote:
[..]
N00b-vraag: wat zijn nou de grootste doodzondes die op deze site begaan zijn, die een kundige UX'er nooit zou maken?
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?
Inderdaad zeg, het contrast op die pagina is echt bizar slecht.quote:
[..]
Witte tekst op een gele achtergrond for starters...
Die footer ook, met een gele link op een lichtgrijze achtergrond
Contrast ratio zoals Catch22- en Tijn al aangeven.quote:
[..]
N00b-vraag: wat zijn nou de grootste doodzondes die op deze site begaan zijn, die een kundige UX'er nooit zou maken?
Op maandag 29 september 2008 11:45 schreef HostiMeister het volgende:
Dat is zeg maar de Nederlandse taal op een vuige keukentafel voorover buigen en hem dan zonder glijmiddel anaal verkrachten. :'(
Dat is zeg maar de Nederlandse taal op een vuige keukentafel voorover buigen en hem dan zonder glijmiddel anaal verkrachten. :'(
En hij werkt niet zonder www...
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?
Iemand enig idee waarom pagina 1 wel speciale tekens (zoals é en ¤) weergeeft, maar pagina 2 totaal niet? Ze zijn beiden aan hetzelfde css-bestand verbonden en verder zit er eigenlijk geen opmaak in de pagina's zelf verwerkt.
Pagina 1:
Pagina 2:
styles.css
Pagina 1:
Pagina 2:
styles.css
| 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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 | <style> #header { background-color:#373332; color:white; width:100%; height:7%; padding:0%; margin-left:auto; margin-right:auto; text-align:center; font-family:Arial, Helvetica, sans-serif; font-size:115%; } #section { background-color:#f5f5f5; color:#b51c54; width:90%; height:50%; padding:5%; margin-left:auto; margin-right:auto; font-family:Arial, Helvetica, sans-serif; font-size:115%; } #section2 { background-color:#f5f5f5; color:#373332; width:90%; height:50%; padding:5%; margin-left:auto; margin-right:auto; font-family:Arial, Helvetica, sans-serif; font-size:115%; } table { border-width:1%; color:#373332; font-family:Arial, Helvetica, sans-serif; font-size:115%; } input { color:#b51c54; font-family:Arial, Helvetica, sans-serif; font-size:115%; } #rozekop { color:#b51c54; } #footer { background-color:#f5f5f5; color:white; width:92%; height:6%; padding:4%; margin-left:auto; margin-right:auto; font-family:Arial, Helvetica, sans-serif; font-size:115%; } button { background-color:#b51c54; width:30%; padding:1%; border-width:0px; color:white; font-weight:bold; font-family:Arial, Helvetica, sans-serif; font-size:115%; } </style> |
Pagina's niet opgeslagen als UTF-8?quote:
Iemand enig idee waarom pagina 1 wel speciale tekens (zoals é en ¤) weergeeft, maar pagina 2 totaal niet? Ze zijn beiden aan hetzelfde css-bestand verbonden en verder zit er eigenlijk geen opmaak in de pagina's zelf verwerkt.
Pagina 1:
[ afbeelding ]
Pagina 2:
[ afbeelding ]
styles.css
[ code verwijderd ]
Op maandag 29 september 2008 11:45 schreef HostiMeister het volgende:
Dat is zeg maar de Nederlandse taal op een vuige keukentafel voorover buigen en hem dan zonder glijmiddel anaal verkrachten. :'(
Dat is zeg maar de Nederlandse taal op een vuige keukentafel voorover buigen en hem dan zonder glijmiddel anaal verkrachten. :'(
Het lijkt geen verschil te maken als ik <meta charset="UTF-8"> tussen head zet.quote:
[..]
Pagina's niet opgeslagen als UTF-8?
edit: Als ik de pagina opsla als .html-pagina (in plaats van .php) werken de tekens wel.
[ Bericht 8% gewijzigd door GuitarJJ op 30-11-2015 20:10:55 ]
De karakters hebben ook een encoding, die moet wel overeenkomen met de encoding van de pagina.quote:
[..]
Het lijkt geen verschil te maken als ik <meta charset="UTF-8"> tussen head zet.
edit: Als ik de pagina opsla als .html-pagina (in plaats van .php) werken de tekens wel.
“Specialization is for insects”.—Robert Heinlein
Stond blijkbaar op ANSI. Als ik het bestandje zelf opsla als UTF-8, krijg ik helaas de volgende melding:quote:
[..]
De karakters hebben ook een encoding, die moet wel overeenkomen met de encoding van de pagina.
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/voordegi/public_html/veapp/uitkomst.php:1) in /home/voordegi/public_html/veapp/uitkomst.php on line 2
| 1 2 3 4 5 6 | <? session_start(); $cataloguswaarde = $_SESSION["cataloguswaarde"]; $aankoopwaarde = $_SESSION["aankoopwaarde"]; $ouderdom = $_SESSION["ouderdom"]; ... |
daar is het php voor dummies voor, zou het zo niet weten.quote:
[..]
Stond blijkbaar op ANSI. Als ik het bestandje zelf opsla als UTF-8, krijg ik helaas de volgende melding:
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/voordegi/public_html/veapp/uitkomst.php:1) in /home/voordegi/public_html/veapp/uitkomst.php on line 2
[ code verwijderd ]
“Specialization is for insects”.—Robert Heinlein
Waarschijnlijk voegt je editor een Byte Order Mark (BOM) toe. Da's een onzichtbaar teken maar wel een die voor de php open tag staat en die dus meteen uitvoer start.quote:
[..]
Stond blijkbaar op ANSI. Als ik het bestandje zelf opsla als UTF-8, krijg ik helaas de volgende melding:
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/voordegi/public_html/veapp/uitkomst.php:1) in /home/voordegi/public_html/veapp/uitkomst.php on line 2
[ code verwijderd ]
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |