Gebruik je Uploadify of zo? Die knop kun je toch gewoon stijlen?quote:Op donderdag 11 april 2013 02:05 schreef kutkloon7 het volgende:
Ik word nu ook zo'n beetje gedwongen om aan de jQuery (of andere library) te gaan: ik wil gewoon een bescheiden knop om een venster mee te openen om bestanden om up te loaden mee te kiezen, niet die joekel met 'Browse' erop. Zo ongeveer de enige nette manier is om een click event na te bootsen, en dat moet bij zo'n beetje elke browser op een andere manier...
Ik had het al bijna goed gekregen door de hele form en knop te verkrachten met CSS, alleen IE werkt weer eens niet mee
Al gekeken naar Perch? http://grabaperch.com/quote:Op woensdag 10 april 2013 21:11 schreef Tijn het volgende:
Ik vind al die CMS'en trouwens maar shitIk wil alleen een backend, de frontend bouw ik zelf wel. En die backend moet zich daadwerkelijk richten op het invullen van content ipv 101 opties te bieden voor allerlei randzaken die je misschien 1x wilt instellen maar verder nooit meer nodig hebt.
Yep, doe ik ook altijd, ik gebruik altijd Starkers als 'naked' theme. Werkt fantastisch al wil ik me ook wel eens gaan wagen aan Zurb.quote:Op donderdag 11 april 2013 11:10 schreef Catch22- het volgende:
Gewoon wordpress pakken met een HTML5 based boilerplate template. Kan je alles naar wens inrichten aan de frontend en de backend is prima.
Werkt nu prima in chrome, ff, opera, safari en zelfs IEquote:Op donderdag 11 april 2013 07:02 schreef Tijn het volgende:
[..]
Het werkt wel, maar niet voor file uploads. Het is een enorm gedoe om het file upload veld te stylen en te triggeren omdat browsers daartegen beveiligd zijn.
Als je het toch nodig blijkt is het helemaal zuur dat je 93KB moet includen voor 1 dingquote:Op donderdag 11 april 2013 12:27 schreef kutkloon7 het volgende:
[..]
En ja, ik probeer jQuery te vermijden. Ik vind het gewoon een beetje jammer om die library te gebruiken als het niet nodig is.
Precies, daarom ook een beetje. Blijft wel een stuk meer werk, omdat je dan aan de lopende band tegen problemen aanlooptquote:Op donderdag 11 april 2013 12:50 schreef Tijn het volgende:
[..]
Als je het toch nodig blijkt is het helemaal zuur dat je 93KB moet includen voor 1 ding
Screw that hoor. Zelfs voor "een simpel dingetje" is jQuery dusdanig veel makkelijker dat je de ontwikkeltijd nevernooit terug gaat verdienen t.o.v. die miliseconde extra pageload.quote:Op donderdag 11 april 2013 12:50 schreef Tijn het volgende:
[..]
Als je het toch nodig blijkt is het helemaal zuur dat je 93KB moet includen voor 1 ding
en daarom moeten websites maar enkele Mb's zijn/worden om te laden?quote:Op donderdag 11 april 2013 16:00 schreef Maringo het volgende:
En buiten dat. 93kb. We leven niet meer in 1998 met een inbelverbinding.
Maar de tijd dat mensen alleen maar op PC's vanuit thuis een website bezochten is ook voorbij. In de trein met je mobieltje kan ~100KB overhead toch voor een merkbare vertraging zorgen.quote:Op donderdag 11 april 2013 16:00 schreef Maringo het volgende:
En buiten dat. 93kb. We leven niet meer in 1998 met een inbelverbinding.
Als je een pagina met alleen tekst zou bekijken, dan zal dat inderdaad de doorslag geven. Maar de gemiddelde website heeft toch als snel een paar MB aan (nutteloze) plaatjes. Dan maakt 93kb weinig meer uit.quote:Op donderdag 11 april 2013 16:13 schreef Tijn het volgende:
[..]
Maar de tijd dat mensen alleen maar op PC's vanuit thuis een website bezochten is ook voorbij. In de trein met je mobieltje kan ~100KB overhead toch voor een merkbare vertraging zorgen.
Dat hangt er vanaf hoe je je scripts inlaadt. Als je alles in de head zet (zoals bij jQuery Mobile de bedoeling is) dan zit je daarop te wachten voordat je überhaupt iets in beeld krijgt. Als je jQuery + andere scripts pas inlaadt op het eind van je pagina, krijgt de bezoeker in elk geval al wat content in beeld en begint-ie ook alvast met het downloaden van de plaatjes.quote:Op donderdag 11 april 2013 17:03 schreef Maringo het volgende:
[..]
Als je een pagina met alleen tekst zou bekijken, dan zal dat inderdaad de doorslag geven. Maar de gemiddelde website heeft toch als snel een paar MB aan (nutteloze) plaatjes. Dan maakt 93kb weinig meer uit.
Eens. Een paar MB is ook veel. Maar je moet ze de kost geven die een responsive design willen en daardoor een shitload aan plaatjes meegeven voor het mobiele formaat.quote:Op donderdag 11 april 2013 17:07 schreef Tijn het volgende:
[..]
Dat hangt er vanaf hoe je je scripts inlaadt. Als je alles in de head zet (zoals bij jQuery Mobile de bedoeling is) dan zit je daarop te wachten voordat je überhaupt iets in beeld krijgt. Als je jQuery + andere scripts pas inlaadt op het eind van je pagina, krijgt de bezoeker in elk geval al wat content in beeld en begint-ie ook alvast met het downloaden van de plaatjes.
Een paar MB aan plaatjes voor een enkele pagina vind ik trouwens echt heel veel, maar goed.
Juist voor een responsive site die zowel mobiel als op desktops er goed uit moet zien zou ik alleen de broodnodige en kleinste versies van de plaatjes aanvankelijk aanbieden en eventueel mbv Javascript de content upgraden als blijkt dat er sprake is van een groter scherm.quote:Op donderdag 11 april 2013 17:12 schreef Maringo het volgende:
[..]
Eens. Een paar MB is ook veel. Maar je moet ze de kost geven die een responsive design willen en daardoor een shitload aan plaatjes meegeven voor het mobiele formaat.
Dat is groter dan de hele homepage van mijn site...quote:Op donderdag 11 april 2013 16:00 schreef Maringo het volgende:
En buiten dat. 93kb. We leven niet meer in 1998 met een inbelverbinding.
http://www.duft.nl/quote:Op donderdag 11 april 2013 19:48 schreef mstx het volgende:
[..]
Dat is groter dan de hele homepage van mijn site...![]()
[ afbeelding ]
Klein/groot is dus nogal relatief![]()
dat jaquote:Op donderdag 11 april 2013 13:35 schreef KomtTijd... het volgende:
...onder het motto "als iedereen het zelfde CDN gebruikt blijft het wel in de cache staan"? is idd wel een voordeel van een CDN gebruiken boven zelf distribueren.
| 1 2 3 4 | #t-header #search { position: absolute; float: right; clear: both; |
| 1 2 3 4 5 | #t-header #search { position: absolute; top: 55px; float: right; clear: both; |
Dat is de standaard code.quote:Op vrijdag 12 april 2013 14:36 schreef Catch22- het volgende:
floaten en clearen hebben geen nut als je absoluut gaat positioneren.
kan je een testcase ergens neerzetten? jsfiddle bijvoorbeeld.
Is dat zo.quote:Op vrijdag 12 april 2013 14:41 schreef KomtTijd... het volgende:
"de standaard code"? Rare standaard dan.
Oké, ik ga het proberen.quote:Op vrijdag 12 april 2013 14:45 schreef KomtTijd... het volgende:
En het is natuurlijk wel de bedoeling dat je je testcase op jsfiddle even compleet maakt met HTML en JS, zo zien we er nog niets aan.
Dat bovenste is de standaard.quote:
Een client kan nooit PHP code zien.quote:Op vrijdag 12 april 2013 17:35 schreef karton2 het volgende:
Is het mogelijk om met firebug het emailadres te achterhalen wat achter de Zendknop van een contactformulier zit?
Als ik met firebug de knop ga ontleden kom ik alleen de HTML code tegen. Een verwijzing naar het php bestand kan ik nergens vinden.
PHP is een scripttaal die HTML-code genereert op de server, de code erachter kan je dus nooit in de browser debuggen.quote:Op vrijdag 12 april 2013 17:35 schreef karton2 het volgende:
Is het mogelijk om met firebug het emailadres te achterhalen wat achter de Zendknop van een contactformulier zit?
Als ik met firebug de knop ga ontleden kom ik alleen de HTML code tegen. Een verwijzing naar het php bestand kan ik nergens vinden.
Echt zelden iemand zo onduidelijk zijn probleem zien omschrijvenquote:
als het een mailto-formulier is, dan staat dat in de form-tag. Maar gelukkig zijn mailto-formulieren zo goed als uitgestorven.quote:Op vrijdag 12 april 2013 17:35 schreef karton2 het volgende:
Is het mogelijk om met firebug het emailadres te achterhalen wat achter de Zendknop van een contactformulier zit?
Als ik met firebug de knop ga ontleden kom ik alleen de HTML code tegen. Een verwijzing naar het php bestand kan ik nergens vinden.
Het was inderdaad niet goed omschreven. Ik ben er nog niet uit. Ik was al aan het zoeken naar html code om in die website te plakken, maar er zijn geen html-bestanden in dit thema. Heb ook al filmpjes gekeken over css positioning alleen snap ik nog niet hoe ik het kan fiksen.quote:Op vrijdag 12 april 2013 18:45 schreef Merkie het volgende:
[..]
PHP is een scripttaal die HTML-code genereert op de server, de code erachter kan je dus nooit in de browser debuggen.
[..]
Echt zelden iemand zo onduidelijk zijn probleem zien omschrijven.
Rechtermuisknop > View source al geprobeerd? F12 al eens in Chrome?quote:Op vrijdag 12 april 2013 20:04 schreef Yuri_Boyka het volgende:
[..]
Het was inderdaad niet goed omschreven. Ik ben er nog niet uit. Ik was al aan het zoeken naar html code om in die website te plakken, maar er zijn geen html-bestanden in dit thema. Heb ook al filmpjes gekeken over css positioning alleen snap ik nog niet hoe ik het kan fiksen.
Element inspecteren bedoel je? Ja dus. Daarmee heb ik de aanpassingen gedaan bij 'matched CSS rules', maar die staan jammer genoeg niet in de stylesheet.quote:Op vrijdag 12 april 2013 20:14 schreef Merkie het volgende:
[..]
Rechtermuisknop > View source al geprobeerd?
Het probleem isoleren is stap 1 van de oplossing, dus probeer dat eerst.
die in jsfiddle zal niet werken omdat de #theader overal nog voor de #search staat in het CSS vak.quote:Op vrijdag 12 april 2013 20:36 schreef Yuri_Boyka het volgende:
Ik heb even gekeken en volgens mij is dit de goede javascript: http://jsfiddle.net/eEhQT/4/ Hoe moet ik nu verder? Welke stappen moet ik ondernemen om uit te zoeken hoe ik het probleem kan fiksen?
| 1 2 3 4 5 | #search { position: absolute; float: left; top: 55px; } |
| 1 | top 55px!important; |
Ja, met alleen die !important werkt die al. Dat t-header ga ik niet verwijderen aangezien het er niks voor niks staat denk ik. Zo werkt het in ieder geval. Ik neem aan dat het verder niet erg is?quote:Op vrijdag 12 april 2013 20:43 schreef Maringo het volgende:
[..]
die in jsfiddle zal niet werken omdat de #theader overal nog voor de #search staat in het CSS vak.
Als ik dit ervan maak:
[ code verwijderd ]
Doet ie het gewoon.
Misschien moet je er
[ code verwijderd ]
van maken zodat ie een ander overschrijft.
Dat gold alleen voor de jsfiddle inderdaad.quote:Op vrijdag 12 april 2013 20:46 schreef Yuri_Boyka het volgende:
[..]
Ja, met alleen die !important werkt die al. Dat t-header ga ik niet verwijderen aangezien het er niks voor niks staat. Zo werkt het in ieder geval. Ik neem aan dat het verder niet erg is?
Bedankt!
Bedankt man! Alleen vind ik het raar dat die zonder die !important niet gewoon werkt. Ik zou toch willen weten wat er dan mis is. Maakt die important nog iets uit?quote:Op vrijdag 12 april 2013 20:46 schreef Maringo het volgende:
[..]
Dat gold alleen voor de jsfiddle inderdaad.
Die important zorgt ervoor dat de 55px die je daar neer zet niet door een ander css file wordt overschreven.quote:Op vrijdag 12 april 2013 20:47 schreef Yuri_Boyka het volgende:
[..]
Bedankt man! Alleen vind ik het nog raar dat die zonder die !important niet gewoon werkt. Ik zou toch willen weten wat er dan mis is. Maakt die important nog iets uit?
Perfect! Ik heb het logo en het zoekveld nu op één lijn. Bedankt!quote:Op vrijdag 12 april 2013 20:48 schreef Maringo het volgende:
[..]
Die important zorgt ervoor dat de 55px die je daar neer zet niet door een ander css file wordt overschreven.
Dat ligt er ook aan wat het "simpele dingetje" is.quote:Op donderdag 11 april 2013 13:28 schreef KomtTijd... het volgende:
[..]
Screw that hoor. Zelfs voor "een simpel dingetje" is jQuery dusdanig veel makkelijker dat je de ontwikkeltijd nevernooit terug gaat verdienen t.o.v. die miliseconde extra pageload.
Welke versie van jQuery had je dan willen hebben?quote:'t Zou overigens wel nice zijn als browsers gewoon een locale kopie van jQuery beschikbaar zouden maken. Zou een hoop gedownload schelen.
Leuk ook voor de makers van YUI, Dojo, script.aculo.us etc.quote:Op vrijdag 12 april 2013 22:30 schreef Light het volgende:
[..]
Welke versie van jQuery had je dan willen hebben?
Dan bouw je die toch ook gewoon in?quote:Op vrijdag 12 april 2013 22:38 schreef Tijn het volgende:
[..]
Leuk ook voor de makers van YUI, Dojo, script.aculo.us etc.
Je kunt toch niet serieus menen dat alle mogelijke libraries maar in alle browsers ingebakken zouden moeten zitten?quote:
Je hebt nu ook geen 3rd party libraries nodig. Ze maken het leven alleen makkelijkerquote:Op vrijdag 12 april 2013 22:44 schreef Tijn het volgende:
[..]
Je kunt toch niet serieus menen dat alle mogelijke libraries maar in alle browsers ingebakken zouden moeten zitten?
Het lijkt me beter dat er gewoon verder wordt gewerkt aan het verbeteren van de DOM en de ECMA-standaard, zodat uiteindelijk hopelijk er überhaupt geen 3rd party libraries nodig zijn om een moderne webapplicatie te maken.
Niet zozeer ingebakken, maar een browser zou toch prima de rol van een CDN over kunnen nemen. Het zou toch makkelijk zijn als een HTML-pagina eenvoudig tegen een browser zou kunnen zeggen welke library er aangeroepen moet worden, en dat een browser deze dan vervolgens zelf downloadt. Ik bedenk maar iets. Er moet vast wel iets mogelijk zijn.quote:Op vrijdag 12 april 2013 22:44 schreef Tijn het volgende:
[..]
Je kunt toch niet serieus menen dat alle mogelijke libraries maar in alle browsers ingebakken zouden moeten zitten?
Het lijkt me beter dat er gewoon verder wordt gewerkt aan het verbeteren van de DOM en de ECMA-standaard, zodat uiteindelijk hopelijk er überhaupt geen 3rd party libraries nodig zijn om een moderne webapplicatie te maken.
waarom niet? voor die paar kb hoef je het niet te laten. En je support gewoon de nieuwste en éénna nieuwste major release. Wil ie wat anders kun je het altijd nog includen.quote:Op vrijdag 12 april 2013 22:44 schreef Tijn het volgende:
[..]
Je kunt toch niet serieus menen dat alle mogelijke libraries maar in alle browsers ingebakken zouden moeten zitten?
Het lijkt me beter dat er gewoon verder wordt gewerkt aan het verbeteren van de DOM en de ECMA-standaard, zodat uiteindelijk hopelijk er überhaupt geen 3rd party libraries nodig zijn om een moderne webapplicatie te maken.
Dat doen alle browsers al, het heet cachingquote:Op vrijdag 12 april 2013 22:55 schreef Merkie het volgende:
[..]
Het zou toch makkelijk zijn als een HTML-pagina eenvoudig tegen een browser zou kunnen zeggen welke library er aangeroepen moet worden, en dat een browser deze dan vervolgens zelf downloadt.
Dat werkt alleen als je het ook van dezelfde URL downloadt toch (dus via de Google CDN bijv.)?quote:Op vrijdag 12 april 2013 23:02 schreef Tijn het volgende:
[..]
Dat doen alle browsers al, het heet caching
Mja, zoals voor wel meer dingen geldt: dat verschilt een beetje per browserquote:Op vrijdag 12 april 2013 23:03 schreef Merkie het volgende:
[..]
Dat werkt alleen als je het ook van dezelfde URL downloadt toch (dus via de Google CDN bijv.)?
Nee, een bestand foo.js op server a is niet (noodzakelijk) hetzelfde als foo.js op server b, dus ik kan me niet voorstellen dat er ook maar een browser is die dat zou cachen.quote:Op vrijdag 12 april 2013 23:05 schreef Tijn het volgende:
[..]
Mja, zoals voor wel meer dingen geldt: dat verschilt een beetje per browser
Meest gebruikt? Volgens welke statistiek?quote:Op vrijdag 12 april 2013 22:55 schreef Merkie het volgende:
Toch zou ik gewoon jQuery overal standaard inbouwen. Meest gebruik, redelijk eenvoudig, enorm veel gebruiksgemak, niet echt nadelen t.o.v. andere libraries.
Nee, dat klopt. Ik had even snel gegoogled op verschillen tussen browsers wat betreft caching-mechanismes en daar kwam ik tegen dat niet elke browser de volledige url gebruikt als key, maar nu ik nog eens goed lees heeft dat blijkbaar vooral te maken met urls waar een querystring aan vast zit (volgens de letter van de spec zouden zulke urls überhaupt niet gecached mogen worden, maar veel browsers doen dat toch).quote:Op zaterdag 13 april 2013 00:08 schreef Light het volgende:
[..]
Nee, een bestand foo.js op server a is niet (noodzakelijk) hetzelfde als foo.js op server b, dus ik kan me niet voorstellen dat er ook maar een browser is die dat zou cachen.
http://w3techs.com/technologies/overview/javascript_library/allquote:Op zaterdag 13 april 2013 00:10 schreef Light het volgende:
[..]
Meest gebruikt? Volgens welke statistiek?
En daarnaast, welke versie van jQuery zou je dan willen inbouwen? (En wat als ze met een nieuwe versie komen?)
daarom gebruik je de versie die op de server van Google staatquote:Op zaterdag 13 april 2013 00:08 schreef Light het volgende:
[..]
Nee, een bestand foo.js op server a is niet (noodzakelijk) hetzelfde als foo.js op server b, dus ik kan me niet voorstellen dat er ook maar een browser is die dat zou cachen.
Anders is er ook geen manier om te weten dat het ook echt hetzelfde bestand isquote:Op vrijdag 12 april 2013 23:03 schreef Merkie het volgende:
[..]
Dat werkt alleen als je het ook van dezelfde URL downloadt toch (dus via de Google CDN bijv.)?
Daar zijn de Last-Modified en If-Modified-Since headers voor. Als het bestand niet is aangepast krijg je een 304 Not Modified status terug.quote:Op zaterdag 13 april 2013 14:31 schreef kutkloon7 het volgende:
Sterker nog: zelfs als het wel dezelfde url is, kan het bestand in de tussentijd ook veranderd zijn (al geloof ik dat sommige servers daar wel een trucje voor hebben, dat je kan opvragen wanneer een bestand voor het laatst veranderd is ofzo)
De ETags zijn ook voor dat doel.quote:Op zaterdag 13 april 2013 14:33 schreef mstx het volgende:
[..]
Daar zijn de Last-Modified en If-Modified-Since headers voor. Als het bestand niet is aangepast krijg je een 304 Not Modified status terug.
Dus eigenlijk zeg je gewoon dat sitebouwers een CDN (en dan wel specifiek die van Google) moeten gebruiken voor het laden van javascript frameworks.quote:Op zaterdag 13 april 2013 14:23 schreef n8n het volgende:
[..]
daarom gebruik je de versie die op de server van Google staat
dat trucje heet: http.quote:Op zaterdag 13 april 2013 14:31 schreef kutkloon7 het volgende:
[..]
Anders is er ook geen manier om te weten dat het ook echt hetzelfde bestand is
Sterker nog: zelfs als het wel dezelfde url is, kan het bestand in de tussentijd ook veranderd zijn (al geloof ik dat sommige servers daar wel een trucje voor hebben, dat je kan opvragen wanneer een bestand voor het laatst veranderd is ofzo)
(oh, dit was al gezegd)
ja, zijn vast ook alternatieven voor googlequote:Op zaterdag 13 april 2013 23:16 schreef Light het volgende:
[..]
Dus eigenlijk zeg je gewoon dat sitebouwers een CDN (en dan wel specifiek die van Google) moeten gebruiken voor het laden van javascript frameworks.
Maar dan zijn we wel van "browsers moeten standaard jQuery includen" naar "sites moeten gebruik maken van een CDN voor jQuery" gegaan. Toch net even anders, in mijn ogen.quote:Op zondag 14 april 2013 11:53 schreef n8n het volgende:
[..]
ja, zijn vast ook alternatieven voor google
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |