De Devschuur Coffee Corner - Iteratie 3

[Caelorum]

NMe schreef op dinsdag 05 februari 2013 @ 23:34:
[...]
Ik weet niet wat de serveradmins ervan vinden maar wat mij betreft komt de limiet bij 5k, wat neerkomt op ~3 maanden per topic. Let wel: het is hun keus, niet de mijne.

Laat ze maar gewoon die zoekfunctie enz. op dit topic uitzetten Het is toch een rolling slowchat waarbij wordt gerouleerd tussen een vast aantal topics met heeeeeel af en toe iets anders ^^

[Woy]

Caelorum schreef op woensdag 06 februari 2013 @ 00:26:
[...]

Laat ze maar gewoon die zoekfunctie enz. op dit topic uitzetten Het is toch een rolling slowchat waarbij wordt gerouleerd tussen een vast aantal topics met heeeeeel af en toe iets anders ^^

Ik gebruik de zoekfunctie eigenlijk juist op dit topic, dan weet ik dat er eens een linkje langs is gekomen o.i.d. en dan zoek ik die even op.

[Erwin537]

Als het zo door gaat kan dit topic het nog 10 dagen volhouden tot de 1000 posts... Dat zou ietwat overdreven zijn. Nu zal dat ongetwijfeld niet zo zijn en wordt in het weekend wat minder gepost, maar toch gaat het behoorlijk rap zo... Dat vorige topic was 26672 posts, het lijkt me dat +- 1/5 daarvan (5000) dus wel te doen moet zijn.

Anders heb je ook niets meer aan die zoekfunctie; dan weet je dat er ergens iets voorbij is gekomen, maar moet je 20.000 topics van 1000 posts gaan doorzoeken. De zoekfunctie van GoT vind ik nou ook weer niet heel goed (of ik kan er niet mee omgaan).

[Grijze Vos]

Kan die zoekfunctie niet uitgebreid worden zodat je de post kunt selecteren waar hetgeen je zoekt in voorkomt. Dat is altijd mijn grootste issue als ik iets zoek.

[Erwin537]

Grijze Vos schreef op woensdag 06 februari 2013 @ 08:42:
Kan die zoekfunctie niet uitgebreid worden zodat je de post kunt selecteren waar hetgeen je zoekt in voorkomt. Dat is altijd mijn grootste issue als ik iets zoek.

Hoe bedoel je dit? Als je weet in welke post het staat hoef je niet meer te zoeken? Of bedoel je de naam van de poster?

[Grijze Vos]

Als ik iets zoek dan staat er alleen maar het topic waar het in stond. Als daar nou een lijstje met posts waarin jouw keywords staan oid uitgeklapt kan worden, dan heb je het hele vindbaarheidsprobleem niet.

[Erwin537]

Grijze Vos schreef op woensdag 06 februari 2013 @ 09:00:
Als ik iets zoek dan staat er alleen maar het topic waar het in stond. Als daar nou een lijstje met posts waarin jouw keywords staan oid uitgeklapt kan worden, dan heb je het hele vindbaarheidsprobleem niet.

Nu snap ik hem, dat is inderdaad wel een pijn punt, als je over het hele forum zoekt zie je geen context waarin jouw keywords staan. Dit heb je wel bij topic specifiek zoeken, wat dus veel beter werkt.

[ Voor 7% gewijzigd door Erwin537 op 06-02-2013 09:04 ]

[D-Raven]

Wow, wait.. what??? nummer 3? Valt me tegen dat RobIII dit topic niet geopend heeft, zou passend zijn .

---

Highcharts is nie lief . bepaalde gedocumenteerde api methods werken niet, maar foutmeldingen?? neuh das voor mietjes.

[Struikrover]

BikkelZ schreef op dinsdag 05 februari 2013 @ 20:35:
Waarom moet het altijd helemaal in Regex? Ik vind het altijd zo'n ongedocumenteerde kluwen van karakters.

Omdat het alternatief langzamer is, en nog veel lomper, je kunt niet fatsoenlijk op herhalingen testen van een specifieke character class set zonder daar speciale functies voor te moeten schrijven. Dan vertrouw ik toch eerder op preg_match

Jan_V schreef op dinsdag 05 februari 2013 @ 20:52:
[...]

Hebben de interne urls niet een (of meerdere) vaste hostnames? Dan kun je daar toch op zoeken?
Neemt niet weg dat het een klote werkje is. Heb ooit zoiets moeten doen voor een klant, waren 4 uren voor geoffereerd, uiteindelijk ben ik er toch zeker meerdere dagen mee zoet geweest. (had toen ook nog nooit van reguliere expressies gehoord)

Nee, helaas. Hetgene dat een interne URL definieert is juist het ontbreken van een hostname. Er is één geval waarin een hostname een interne URL specificeert en dat is inderdaad in het geval dat men een absolute URL heeft geplaatst. Dit wordt echter afgeraden door de opzet van de website.
Toegestaan zijn zowel relatieve URL's als root-relatieve URL's.
Je hebt dus te maken met een situatie waarin simpelweg een woord ook al als interne URL gevalideerd kan worden: "informatie" is dus een syntactisch geldige interne URL.

Wat helpt is dat een slug alleen mag bestaan uit a-zA-Z0-9-_~() (uit mijn hoofd). Echter is er wel wat legacy die vroeger een spatie ook toestond, dus daar moet nog een warning aan gekoppeld worden.
Bovendien kwam ik er gister achter dat er ook URL's zijn waarin HTML entities zijn opgenomen: %20, %3A, die bende. Daar moet je dus ook rekening mee houden

[Korben]

Hmm, Jeff Atwood is weer goed bezig. Civilized Discourse Construction Kit. De software ziet er erg interessant uit.

[Rhapsody]

*jeej* het is nog ochtend en ik heb mijn probleem van gisteren met Team Foundation Server al gefixt... wat zal ik nu eens gaan doen....

[Alex)]

Korben schreef op woensdag 06 februari 2013 @ 09:23:
Hmm, Jeff Atwood is weer goed bezig. Civilized Discourse Construction Kit. De software ziet er erg interessant uit.

Oeh, interessante ideeën

[Evilbee]

Aj, ik kom er net achter dat een (tobe) productie server is verbonden met een QUA database.

Achtergrond: Iedere omgeving heeft een soort "zwevend" profiel. Dus een client doet een broadcast binnen het netwerk om zijn profiel te verkrijgen. En als de QUA server en de PROD server binnen hetzelfde netwerk hangen, kan de client een verkeerd profiel krijgen met een verkeerde database verbinding.

Net IT maar eens een schop gegeven dat ze hun firewalls mogen controleren...

[Flowmo]

Iemand nog een postcode API nodig? Onze vrienden van FreshHeads hebben een gratis beschikbare postcode API ontwikkeld obv JSON: http://www.postcodeapi.nu/

Data komt rechtstreeks van openbaar beschikbaar gestelde data van het kadaster, dus lijkt me redelijk up to date

[Firesphere]

Flowmo schreef op woensdag 06 februari 2013 @ 10:07:
Iemand nog een postcode API nodig? Onze vrienden van FreshHeads hebben een gratis beschikbare postcode API ontwikkeld obv JSON: http://www.postcodeapi.nu/

Data komt rechtstreeks van openbaar beschikbaar gestelde data van het kadaster, dus lijkt me redelijk up to date

Ehhhh, https://api.postcode.nl/ much?

[TheNephilim]

Flowmo schreef op woensdag 06 februari 2013 @ 10:07:
Iemand nog een postcode API nodig? Onze vrienden van FreshHeads hebben een gratis beschikbare postcode API ontwikkeld obv JSON: http://www.postcodeapi.nu/

Data komt rechtstreeks van openbaar beschikbaar gestelde data van het kadaster, dus lijkt me redelijk up to date

Thanks! ^^

Firesphere schreef op woensdag 06 februari 2013 @ 10:09:
[...]

Ehhhh, https://api.postcode.nl/ much?

Alleen beschikbaar voor webshops...

[ Voor 49% gewijzigd door TheNephilim op 06-02-2013 10:13 ]

[Intru]

Dat was even schrikken vanochtend, een slotje op de Coffee Corner. Gelukkig was irritatie 3 snel gevonden

Flowmo schreef op woensdag 06 februari 2013 @ 10:07:
Iemand nog een postcode API nodig? Onze vrienden van FreshHeads hebben een gratis beschikbare postcode API ontwikkeld obv JSON: http://www.postcodeapi.nu/

Data komt rechtstreeks van openbaar beschikbaar gestelde data van het kadaster, dus lijkt me redelijk up to date

Cool, zal er eens naar kijken.

[ Voor 66% gewijzigd door Intru op 06-02-2013 10:18 ]

[Alex)]

Intru schreef op woensdag 06 februari 2013 @ 10:15:
Gelukkig was irritatie 3 snel gevonden

[TheNephilim]

Intru schreef op woensdag 06 februari 2013 @ 10:15:
Dat was even schrikken vanochtend, een slotje op de Coffee Corner. Gelukkig was irritatie 3 snel gevonden

[ Voor 9% gewijzigd door TheNephilim op 06-02-2013 10:20 ]

[Haan]

Lol ik heb nu pas door dat het vorige deel is gesloten, ik zat vanmorgen gewoon bij te lezen in het topic zonder dat het was opgevallen dat het een nieuw topic was.
Inmiddels heeft de koffie blijkbaar m'n hersens bereikt

[Firesphere]

TheNephilim schreef op woensdag 06 februari 2013 @ 10:11:
[...]


Thanks! ^^


[...]


Alleen beschikbaar voor webshops...

Ow?
Hmmm, misschien moet ik al m'n niet-webshop-implementaties dan eens aanpassen.

[TheNephilim]

Firesphere schreef op woensdag 06 februari 2013 @ 10:23:
[...]

Ow?
Hmmm, misschien moet ik al m'n niet-webshop-implementaties dan eens aanpassen.

Haha, vandaar de smiley!

Kan me ook niet voorstellen dat je eerst moet aantonen dat je een webshop hebt voordat je wat mag doen met de API.

---

Korting bij een webshop vóór of ná de btw?

[ Voor 7% gewijzigd door TheNephilim op 06-02-2013 10:58 ]

[NMe]

Caelorum schreef op woensdag 06 februari 2013 @ 00:26:
[...]

Laat ze maar gewoon die zoekfunctie enz. op dit topic uitzetten Het is toch een rolling slowchat waarbij wordt gerouleerd tussen een vast aantal topics met heeeeeel af en toe iets anders ^^

Nog naast het feit dat je niet zomaar even de search "uit kan zetten" voor één topic (en we weten allemaal hoe kostbaar devtijd is) is dat maar één van de vijf argumenten die crisp aandroeg tegen het lang open houden van topics. NMe in "De Devschuur Coffee Corner - Iteratie 2"

[Struikrover]

Ligt het aan mij of kunnen de filmpjes op de website niet meer worden afgespeeld? Overal error 2048...

EDIT: Oh, en daarna laden ze wel en kun je nogmaals op play drukken

[ Voor 26% gewijzigd door Struikrover op 06-02-2013 11:02 ]

[denyos]

Dat heb ik hier ook op het werk Struikrover. Maar dat heeft hier te maken met de proxy server.

[Flowmo]

TheNephilim schreef op woensdag 06 februari 2013 @ 10:26:
Korting bij een webshop vóór of ná de btw?

30% korting:
(100 * 0.7) * 1.21
of
(100 * 1.21) * 0.7?

Allebei 84.7

[Otherside1982]

Flowmo schreef op woensdag 06 februari 2013 @ 11:13:
[...]

30% korting:
(100 * 0.7) * 1.21
of
(100 * 1.21) * 0.7?

Allebei 84.7

Maar het BTW bedrag verschilt wel:
100 * 0.7 * 0.21 = 14.7
100 * 0.21 = 21
Korting wordt volgens mij toch berekend op bedrag inclusief BTW, anders krijgt de staat minder BTW omdat je als verkoper korting wil geven.Dat lijkt niet te kloppen als ik wat opzoekwerk doe. Hoe het juist zit zal ik me niet over uitspreken, het ligt blijkbaar niet zo eenvoudig.

[ Voor 15% gewijzigd door Otherside1982 op 06-02-2013 11:26 ]

[GateKeaper]

Otherside1982 schreef op woensdag 06 februari 2013 @ 11:20:
[...]

Maar het BTW bedrag verschilt wel:
100 * 0.7 * 0.21 = 14.7
100 * 0.21 = 21
Korting wordt volgens mij toch berekend op bedrag inclusief BTW, anders krijgt de staat minder BTW omdat je als verkoper korting wil geven.Dat lijkt niet te kloppen als ik wat opzoekwerk doe. Hoe het juist zit zal ik me niet over uitspreken, het ligt blijkbaar niet zo eenvoudig.

Het is juist heel makkelijk. Ik verkoop iets, dus ik bepaal wat ik daar voor wil hebben. De staat eist gewoon 21% van het door mij gevraagde bedrag. Dit bereken ik uiteraard door aan de klant.

Wil ik 100 euro hebben, dan eist de staat 21 euro. Daarom reken ik 121 door aan de klant. Als ik besluit dat het tijd is voor een leuke aanbieding, of ik last heb van product overschot. Dan sta ik vrij om datzelfde voor 1 euro op de markt te zetten. De staat eist dan wederom 21%, dus zal tevreden moeten zijn met 21 cent. Hun kunnen en mogen de te heffen belasting niet binden aan de werkelijke waarde van een product. De waarde is dat wat ik er voor vraag, en de klant er voor geeft.

Alex) schreef op woensdag 06 februari 2013 @ 09:58:
[...]

Oeh, interessante ideeën

Moet zeggen, wel hele mooie "forum" software http://try.discourse.org

[ Voor 8% gewijzigd door GateKeaper op 06-02-2013 11:30 ]

[Korben]

Otherside1982 schreef op woensdag 06 februari 2013 @ 11:20:
[...]

Maar het BTW bedrag verschilt wel:
100 * 0.7 * 0.21 = 14.7
100 * 0.21 = 21
Korting wordt volgens mij toch berekend op bedrag inclusief BTW, anders krijgt de staat minder BTW omdat je als verkoper korting wil geven.Dat lijkt niet te kloppen als ik wat opzoekwerk doe. Hoe het juist zit zal ik me niet over uitspreken, het ligt blijkbaar niet zo eenvoudig.

Lijkt me toch vrij simpel... Je berekent BTW over het bedrag wat je de klant daadwerkelijk in rekening brengt.

[Flowmo]

Otherside1982 schreef op woensdag 06 februari 2013 @ 11:20:
[...]

Maar het BTW bedrag verschilt wel:
100 * 0.7 * 0.21 = 14.7
100 * 0.21 = 21
Korting wordt volgens mij toch berekend op bedrag inclusief BTW, anders krijgt de staat minder BTW omdat je als verkoper korting wil geven.Dat lijkt niet te kloppen als ik wat opzoekwerk doe. Hoe het juist zit zal ik me niet over uitspreken, het ligt blijkbaar niet zo eenvoudig.

Logisch, want in jouw rekensom reken je met en zonder korting.

Hoe dan ook, als de klant uiteindelijk met beide berekeningen hetzelfde betaalt, dan is op dat moment de prijs nog steeds incl 21% btw, 121% van de prijs die verkoper heeft bepaald. Wanneer je die BTW dus lostrekt van de te betalen prijs, is het BTW bedrag hetzelfde met beide berekeningen.

[RayNbow]

Vandaag op het werk:

[ Voor 3% gewijzigd door RayNbow op 06-02-2013 11:48 ]

[Korben]

RayNbow schreef op woensdag 06 februari 2013 @ 11:40:
Vandaag op het werk:
[afbeelding]

Hoop dat ze dat niet inhouden van je salaris. WTF trouwens is meer dat je moet betalen om te printen...

[Struikrover]

Hahaha -1 pagina geprint ,kost je een godsvermogen. Topsysteem

EDIT: btw, ff die ':large' uit je img URL halen, anders werkt ie bij mij niet

[ Voor 38% gewijzigd door Struikrover op 06-02-2013 11:42 ]

[RayNbow]

Korben schreef op woensdag 06 februari 2013 @ 11:41:
[...]

WTF trouwens is meer dat je moet betalen om te printen...

Alleen studenten moeten betalen (en zij hebben dan ook een saldo dat positief is). Voor werknemers is het gratis om te printen en is het slechts een administratief iets.

Wat vreemder is, is dat bij een volgende login op de printer het saldo weer "normaal" is. * RayNbow is benieuwd hoe bepaald wordt wat een foute transactie was.

[.oisyn]

Grijze Vos schreef op woensdag 06 februari 2013 @ 09:00:
Als ik iets zoek dan staat er alleen maar het topic waar het in stond. Als daar nou een lijstje met posts waarin jouw keywords staan oid uitgeklapt kan worden, dan heb je het hele vindbaarheidsprobleem niet.

Niet dat het niet beter kan, maar je kunt nu toch al gewoon op de topic klikken en daarna de "zoek in deze topic" feature gebruiken? Je keywords zijn al ingevuld, 't is gewoon een kwestie van op de zoekknop klikken.

[ Voor 5% gewijzigd door .oisyn op 06-02-2013 11:50 ]

[Hipska]

-1 geprinte pagina? Is dat dan een ingescande pagina?

[Kips]

RayNbow schreef op woensdag 06 februari 2013 @ 11:40:
Vandaag op het werk:
[afbeelding]

dat zijn veul kopjes koffie

[GateKeaper]

Hipska schreef op woensdag 06 februari 2013 @ 11:50:
-1 geprinte pagina? Is dat dan een ingescande pagina?

Dat is als je het papier van je vorige print recyclet. (hoe de f*ck schrijf je dat woord? )Fixed, ugly as hell, but it suits the law.

[ Voor 8% gewijzigd door GateKeaper op 06-02-2013 11:57 ]

[Struikrover]

http://www.mijnwoordenboek.nl/werkwoord/recyclen

recyclet dus

[Otherside1982]

Flowmo schreef op woensdag 06 februari 2013 @ 11:36:
[...]

Logisch, want in jouw rekensom reken je met en zonder korting.

Hoe dan ook, als de klant uiteindelijk met beide berekeningen hetzelfde betaalt, dan is op dat moment de prijs nog steeds incl 21% btw, 121% van de prijs die verkoper heeft bepaald. Wanneer je die BTW dus lostrekt van de te betalen prijs, is het BTW bedrag hetzelfde met beide berekeningen.

Mijn berekening is wel degelijk correct. In het eerste geval wordt de korting berekend op het bedrag exclusief BTW, in het tweede geval wordt de korting berekend op het bedrag inclusief BTW.
De BTW wordt op 2 verschillende bedragen berekend, dus is het BTW bedrag ook verschillend.

[GateKeaper]

Als je berekening gaat om het "aan de klant te rekenen bedrag", dan klopt het. Als je aan het rekenen bent voor je belastingaangifte, dan dus niet

[Otherside1982]

Ik wilde dus gewoon aangeven dat de volgorde van je korting en BTW geen invloed heeft op het bedrag dat de klant betaalt, maar wel op het BTW bedrag. Daarmee wilde ik dus aangeven dat je niet zomaar mag kiezen omdat het eindbedrag hetzelfde is.

[Dido]

Otherside1982 schreef op woensdag 06 februari 2013 @ 12:13:
Ik wilde dus gewoon aangeven dat de volgorde van je korting en BTW geen invloed heeft op het bedrag dat de klant betaalt, maar wel op het BTW bedrag. Daarmee wilde ik dus aangeven dat je niet zomaar mag kiezen omdat het eindbedrag hetzelfde is.

Neen.

Het BTW-bedrag is altijd hetzelfde als het klantbedrag hetzelfde is.

Vermeningvuldigen is vermenigvuldigen.

En percentages zijn ook vermenigvuldigen.

Als je bij dezelfde klantprijs een ander BTW-bedrag krijgt is het geen 21 % btw

[Otherside1982]

Dido schreef op woensdag 06 februari 2013 @ 12:15:
[...]

Neen.

Het BTW-bedrag is altijd hetzelfde als het klantbedrag hetzelfde is.

Vermeningvuldigen is vermenigvuldigen.

En percentages zijn ook vermenigvuldigen.

Als je bij dezelfde klantprijs een ander BTW-bedrag krijgt is het geen 21 % btw

Er was sprake van 2 verschillende manieren om BTW te berekenen die dezelfde klantenprijs tot gevolg hadden. Die 2 verschillende manieren geven toch echt wel 2 verschillende BTW bedragen. Eén van de berekeningswijzes is wel fout, want BTW wordt inderdaad berekend op het bedrag met korting.

[.oisyn]

Ook bij acties in de vorm van "betaal geen BTW" krijg je eigenlijk gewoon 21% korting. 't Is niet alsof de winkel dan ineens geen BTW afdraagt en ondertussen de volledige prijs in eigen zak steekt

Otherside1982 schreef op woensdag 06 februari 2013 @ 12:18:
[...]

Er was sprake van 2 verschillende manieren om BTW te berekenen die dezelfde klantenprijs tot gevolg hadden. Die 2 verschillende manieren geven toch echt wel 2 verschillende BTW bedragen. Eén van de berekeningswijzes is wel fout, want BTW wordt inderdaad berekend op het bedrag met korting.

Het is ook handiger als je de boel gewoon omdraait. Voor elke euro die een winkelier van jou int moet hij ~17,36 cent afstaan aan de staat.

[ Voor 58% gewijzigd door .oisyn op 06-02-2013 12:21 ]

[EddoH]

.oisyn schreef op woensdag 06 februari 2013 @ 12:19:
Ook bij acties in de vorm van "betaal geen BTW" krijg je eigenlijk gewoon 21% korting. 't Is niet alsof de winkel dan ineens geen BTW afdraagt en ondertussen de volledige prijs in eigen zak steekt

Je krijgt 17.36 % korting
21% van de prijs incl btw is meer dan 21% van de prijs zonder btw.

[ Voor 8% gewijzigd door EddoH op 06-02-2013 12:31 ]

[Dido]

Otherside1982 schreef op woensdag 06 februari 2013 @ 12:18:
Er was sprake van 2 verschillende manieren om BTW te berekenen die dezelfde klantenprijs tot gevolg hadden. Die 2 verschillende manieren geven toch echt wel 2 verschillende BTW bedragen. Eén van de berekeningswijzes is wel fout, want BTW wordt inderdaad berekend op het bedrag met korting.

De vraag was natuurlijk over welk bedrag de korting berekend wordt, en eigenliijk is dat te simpel voor woorden: Er gaat x% korting af van zowel het netto-bedrag, als het bruto-bedrag, als en BTW-bedrag

Het maakt dus eigenlijk geen fluit uit naar welk bedrag je kijkt, als je het bedrag voor korting vergelijkt met het bedrag na korting zit er de x% korting tussen

[.oisyn]

EddoH schreef op woensdag 06 februari 2013 @ 12:26:
[...]


Je krijgt 17.36 % korting
21% van de prijs incl btw is meer dan 21% van de prijs zonder btw.

Zoals je in het onderste deel van mijn post al kon lezen wist ik wel hoe dat werkte

[Grijze Vos]

.oisyn schreef op woensdag 06 februari 2013 @ 11:49:
[...]


Niet dat het niet beter kan, maar je kunt nu toch al gewoon op de topic klikken en daarna de "zoek in deze topic" feature gebruiken? Je keywords zijn al ingevuld, 't is gewoon een kwestie van op de zoekknop klikken.

Hoe lang bestaat die feature al? Spot hem nu pas. (Goed, zo vaak zoek ik nou ook weer niet, zegge 2x per jaar ofzo.)

[Martijn19]

Bleghhh, school verplicht XHTML strict doctype...

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

ipv de veel simpelere

code:

<!DOCTYPE html>

Reden: als je html5 doctype gebruikt moet je ook van de HTML5 extra's (denk aan input type="date") gebruik maken....

Is er werkelijk waar nog 1 reden om niet de html5 doctype te gebruiken?

[Grijze Vos]

ja, als het geen html5 is, maar xhtml.

[BikkelZ]

m19 schreef op woensdag 06 februari 2013 @ 13:15:
Bleghhh, school verplicht XHTML strict doctype...

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

ipv de veel simpelere

code:

<!DOCTYPE html>

Reden: als je html5 doctype gebruikt moet je ook van de HTML5 extra's (denk aan input type="date") gebruik maken....

Is er werkelijk waar nog 1 reden om niet de html5 doctype te gebruiken?

Browser support in de geretardeerdere versies van Internet Explorer. Die moeten strict hebben anders slaat hun fantasie op hol.

[OkkE]

m19 schreef op woensdag 06 februari 2013 @ 13:15:
Bleghhh, school verplicht XHTML strict doctype...

[...]

Is er werkelijk waar nog 1 reden om niet de html5 doctype te gebruiken?

Omdat de school / docent achter loopt op de praktijk...

[Flowmo]

m19 schreef op woensdag 06 februari 2013 @ 13:15:
Bleghhh, school verplicht XHTML strict doctype...

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

ipv de veel simpelere

code:

<!DOCTYPE html>

Reden: als je html5 doctype gebruikt moet je ook van de HTML5 extra's (denk aan input type="date") gebruik maken....

Is er werkelijk waar nog 1 reden om niet de html5 doctype te gebruiken?

Je "moet" helemaal niks met de HTML5 doctype. Als je die input types niet wilt gebruiken, dan hoef je ze ook niet te gebruiken. Reden om bij XHTML strict te blijven is als je echt vind dat je geen <iframe> elementen e.d. mag gebruiken en ook geen "oudere" tags wilt gebruiken als bv width voor tabel cellen.

Edit: Sterker nog, met de HTML5 doctype is je XHTML Strict doctype markup ook nog gewoon geldig. De HTML5 doctype is erg soepel wat dat betreft. Dat je docent dat niet is, is zijn probleem

BikkelZ schreef op woensdag 06 februari 2013 @ 13:21:
[...]


Browser support in de geretardeerdere versies van Internet Explorer. Die moeten strict hebben anders slaat hun fantasie op hol.

Skoez mie? Zelfs IE6 pikt de HTML5 doctype nog, alleen niet de nieuwe HTML5 elementen (uiteraard). Verder geeft Transitional ook geen problemen in die versies.

[ Voor 7% gewijzigd door Flowmo op 06-02-2013 13:27 ]

[Struikrover]

Het stomme is vaak ook dat je wel gedwongen wordt de XHTML doctype te gebruiken door je opleiding, maar dat ze er dan bijvoorbeeld niet aan denken de mimetype ook correct uit te laten sturen, waardoor dacht ik je pagina nog steeds als html geparsed wordt, en niet als XHTML.

Gelukkig zelf geen last van gelukkig, al mijn pagina' s krijgen braaf DOCTYPE html

EDIT: misschien kun je ze dus daarmee ompraten, ff de mimetype van het document checken. Is het niet 'application/xhtml+xml' maar 'text/html' ? Dan moet je ook gewoon een HTML doctype gebruiken want dan is de document encoding gewoon niet goed voor XHTML

[ Voor 40% gewijzigd door Struikrover op 06-02-2013 13:32 ]

[Martijn19]

Ik weet ook wel dat ik niets moet van HTML5. Ik vind het gewoon verschrikkelijk jammer dat hun vinden dat als ik toch die doctype gebruik dat ik ook die extra's moet gebruiken omdat er anders geen reden is om de html5 doctype te gebruiken. Jep....


edit:

Het leuke is dat hier wel een leuke poster van HTML5 vs Flash hangt, maar dat het vak Flash ook gegeven word.

[ Voor 20% gewijzigd door Martijn19 op 06-02-2013 13:29 ]

[GateKeaper]

m19 schreef op woensdag 06 februari 2013 @ 13:28:
Ik weet ook wel dat ik niets moet van HTML5. Ik vind het gewoon verschrikkelijk jammer dat hun vinden dat als ik toch die doctype gebruik dat ik ook die extra's moet gebruiken omdat er anders geen reden is om de html5 doctype te gebruiken. Jep....


edit:

Het leuke is dat hier wel een leuke poster van HTML5 vs Flash hangt, maar dat het vak Flash ook gegeven word.

En terecht.. Dat zou hetzelfde zijn als normaal rijden in een BMW. Dat doe je ook niet! Wil je normaal rijden, koop dan geen BMW (om de auto vergelijking maar weer eens aan te halen)

[BikkelZ]

Flowmo schreef op woensdag 06 februari 2013 @ 13:24:
Skoez mie? Zelfs IE6 pikt de HTML5 doctype nog, alleen niet de nieuwe HTML5 elementen (uiteraard). Verder geeft Transitional ook geen problemen in die versies.

Hmmm ik ben al die jaren zo op Strict gefocust geweest dat ik Transitional automatisch tot fout bestempel - maar in principe maakt het niks uit voor de weergave van pagina's. Koel.

Niet dat ik nu wel weer ga checken of dingen werken in IE6

[ Voor 6% gewijzigd door BikkelZ op 06-02-2013 13:40 ]

[Flowmo]

m19 schreef op woensdag 06 februari 2013 @ 13:28:
Ik weet ook wel dat ik niets moet van HTML5. Ik vind het gewoon verschrikkelijk jammer dat hun vinden dat als ik toch die doctype gebruik dat ik ook die extra's moet gebruiken omdat er anders geen reden is om de html5 doctype te gebruiken. Jep....


edit:

Het leuke is dat hier wel een leuke poster van HTML5 vs Flash hangt, maar dat het vak Flash ook gegeven word.

Je kan het argument ook omdraaien:
Als HTML5 dezelfde markup ondersteunt als XHTML Strict, maar wel nieuwer is en nog meer features heeft, waarom gebruik je dan nog XHTML? Dat je HTML5 gebruikt hoeft nog niet te betekenen dat je meteen van *alle* features gebruik *moet* gaan maken! HTML5 is gewoon meer toekomstgericht dan XHTML.

Ik zie het al voor me dat er een opdracht binnenkomt waarin de klant eist dat als we de HTML5 doctype kiezen we ook alle features moeten gaan gebruiken

"Ik wil een simpele website, maar omdat jullie HTML5 gebruiken wil ik dat de GPS coordinaten van mijn bezoekers worden opgeslagen in localStorage en dat die informatie dan via WebWorkers verwerkt wordt tot een canvas kaartje. Oh en dat canvas kaartje wil ik ook omgezet hebben naar SVG, gewoon, omdat het kan."

[GateKeaper]

Lol....

... With a simple right-click of your mouse you can “View Source…” of any website and get insight into how the developer built the site, their code, and the services they use. Through this we learn and are inspired by seeing under the hood. It’s a good argument this is why Javascript is now so popular. ...

Wist niet dat javascript echt populair is. Tjah, het nut en de fun wordt er steeds meer van ingezien. Maar populair? Laat staan dat het kunnen bekijken van de source via je browser de oorzaak daarvan is. Weer wat geleerd?!

Bron: http://blogs.esri.com/esr...ng-open-source-with-esri/

[Flowmo]

GateKeaper schreef op woensdag 06 februari 2013 @ 13:52:
Lol....


[...]


Wist niet dat javascript echt populair is. Tjah, het nut en de fun wordt er steeds meer van ingezien. Maar populair? Laat staan dat het kunnen bekijken van de source via je browser de oorzaak daarvan is. Weer wat geleerd?!

Bron: http://blogs.esri.com/esr...ng-open-source-with-esri/

Ja, Javascript is wel populair tegenwoordig: https://github.com/languages

Voor de rest een kul argument natuurlijk om te zeggen dat view-source daarvan de reden is

[ Voor 8% gewijzigd door Flowmo op 06-02-2013 13:56 ]

[Erwin537]

Flowmo schreef op woensdag 06 februari 2013 @ 13:54:
[...]

Ja, Javascript is wel populair tegenwoordig: https://github.com/languages

In Javascript zijn heel veel ontwikkelingen de laatste tijd (kijk naar de hoeveelheid frameworks en libraries die als paddestoelen de grond uit schieten). Maar github is denk ik niet echt een goed voorbeeld om naar te wijzen voor statistieken...

[curvemod]

[b]GateKeaper schreef op woensdag 06 februari 2013 @ 13:52:
Wist niet dat javascript echt populair is. Tjah, het nut en de fun wordt er steeds meer van ingezien. Maar populair? Laat staan dat het kunnen bekijken van de source via je browser de oorzaak daarvan is. Weer wat geleerd?!

Ja en ik denk dat dit nog maar het begin is. De komende jaren gaat er veel mee gebouwd worden voor mobile, voor OS'en (gebeurt al) en nog veel meer in webapps. Ik denk dat goed zijn in Javascript heel belangrijk is, zeker omdat er nog steeds weinig programmeurs zijn die het echt begrijpen Kortom, goed worden in Javascript en je zit de komende jaren goed qua werk

[ Voor 5% gewijzigd door curvemod op 06-02-2013 14:00 ]

[Flowmo]

Het lijkt me een prima bron om aan te tonen dat het grootste deel van de Github repo's Javascript bevat. Als je voor de rest de ontwikkelingen bijhoudt over Backbone, Node.js, Ember, Angular, Handlebars, etc. dan kom je al vrij snel tot de conclusie dat het wel degelijk steeds populairder wordt.

[BikkelZ]

JavaScript wordt gezien als iets wat front-end developers over de streep moet trekken om ook wat applicatiecode te gaan schrijven. Ik denk dat ik bij PHP wel genoeg heb gezien wat er gebeurt als je pure front-enders ook met databases gaat laten rommelen.

[.Gertjan.]

BikkelZ schreef op woensdag 06 februari 2013 @ 13:39:
[...]


Hmmm ik ben al die jaren zo op Strict gefocust geweest dat ik Transitional automatisch tot fout bestempel - maar in principe maakt het niks uit voor de weergave van pagina's. Koel.

Ging IE < 8 (of misschien ook 8 ) niet over in Quirks mode als je het doctype niet uitschreef? Ik kan mij voorstellen dat de pagina wel werkt, maar zodra je met paddings en borders gaat werken zul je (volgens mij) verschillen zien tussen IE en andere browsers.

[Erwin537]

Flowmo schreef op woensdag 06 februari 2013 @ 14:00:
Het lijkt me een prima bron om aan te tonen dat het grootste deel van de Github repo's Javascript bevat. Als je voor de rest de ontwikkelingen bijhoudt over Backbone, Node.js, Embers, Angular, Handlebars, etc. dan kom je al vrij snel tot de conclusie dat het wel degelijk steeds populairder wordt.

Voor op github wel ja, maar 'overall' populaire programmeertalen?

En als je kijkt naar de hoeveelheid frameworks en libraries zie je inderdaad dat het nog steeds populairder wordt... het valt gewoon niet bij te houden.

[GateKeaper]

Javascript is in opmars als je kijkt naar hoevaak en vooral hoe het toegepast wordt. Ruby is/was populair. Javascript groeit gewoon. Node.js is populair. Big difference tussen populair en in opmars.

Deze is ook leuk:

Open-Source is as simple as... "view source"

http://ajturner.github.co...ons/esri-opensource/#/2/2

[curvemod]

BikkelZ schreef op woensdag 06 februari 2013 @ 14:02:
JavaScript wordt gezien als iets wat front-end developers over de streep moet trekken om ook wat applicatiecode te gaan schrijven. Ik denk dat ik bij PHP wel genoeg heb gezien wat er gebeurt als je pure front-enders ook met databases gaat laten rommelen.

Tja, maar dan heb je de afgelopen jaren ook de nodige serieuze projecten gemist met die visie Kijk bijvoorbeeld naar Cloud9 (IDE) dat zijn toch hele grote applicaties die geschreven worden in JS en een aantal van die gasten zijn slimmer dan gemiddelde (backend) programmeur hier (mij incluus uiteraard ).

[Martijn19]

Volgens mij heb ik de feiten nu redelijk op een rij:

XHTML en HTML5 doctype word als 1 dezelfde gezien, ook door de W3C validator. Ook door IE6 en hoger.

Je mag je bij HTML5 houden aan de XHTML regels zoals lowercase, maar dat hoeft niet.

Je bent niet verplicht om de nieuwe HTML5 features zoals <video>, <section> etc te gebruiken.

text/html word geparsed als HTML en application/xhtml+xml als XML, als je als text/html serveert is er geen reden om XHTML te gebruiken, als je als application/xhtml+xml serveert dan moet je wel XHTML gebruiken.

application/xhtml+xml word zeer slecht in IE < 9 ondersteunt.

Bronnen:
http://stackoverflow.com/...tml5-syntax-html-vs-xhtml


http://webdevrefinery.com...on-html5-or-xhtml-strict/

[ Voor 11% gewijzigd door Martijn19 op 06-02-2013 14:13 ]

[zeef]

Vrienden,

Toevallig iemand hier die apps heeft ontwikkeld voor meer platformen waarover we een klein stukje kunnen publiceren op onze Techdays zone? Stuur me even een DM als je wil. Mocht je iemand buiten Tweakers kennen die in dit plaatje past, dan ben ik ook zeer geïnteresseerd.

[Flowmo]

BikkelZ schreef op woensdag 06 februari 2013 @ 14:02:
JavaScript wordt gezien als iets wat front-end developers over de streep moet trekken om ook wat applicatiecode te gaan schrijven. Ik denk dat ik bij PHP wel genoeg heb gezien wat er gebeurt als je pure front-enders ook met databases gaat laten rommelen.

Daar ga je een beetje kort door de bocht. Javascript is niet per se alleen iets voor front-end developers. Kan ook prima door back-enders geschreven worden. Verder is het gewoon een programmeertaal, niet iets om front-enders "over de streep te trekken" om te programmeren. Ik ken genoeg front-end developers die bewust bij JS vandaan blijven omdat ze zich meer willen specialiseren in HTML en CSS dan in JS. Het moet je maar net liggen.

Verder wordt JS ook meer en meer een back-end taal met ontwikkelingen als Node.js en worden dus ook back-enders "over de streep getrokken" om JS te schrijven.

[GateKeaper]

zeef schreef op woensdag 06 februari 2013 @ 14:14:
Vrienden,

Toevallig iemand hier die apps heeft ontwikkeld voor meer platformen waarover we een klein stukje kunnen publiceren op onze Techdays zone? Stuur me even een DM als je wil. Mocht je iemand buiten Tweakers kennen die in dit plaatje past, dan ben ik ook zeer geïnteresseerd.

En ik maar denken dat je hier niet mocht "werven".

[zeef]

GateKeaper schreef op woensdag 06 februari 2013 @ 14:18:
[...]


En ik maar denken dat je hier niet mocht "werven".

Het is geen werving voor een baan maar voor een interview. Dat mag wel. Overigens zoek ik ook nog steeds slachtoffers voor de Gathering of the Tweaker, maar dat geheel terzijde.

[NMe]

zeef schreef op woensdag 06 februari 2013 @ 14:22:
[...]

Het is geen werving voor een baan maar voor een interview. Dat mag wel.

...in overleg met de moderators, wat zeef overigens ook netjes heeft gedaan. Het is niet alsof we de regels buigen ofzo.

[denyos]

@zeef
Misschien dat je de sprekers van deze techdays sessie even kan benaderen: http://www.microsoft.com/...etail.aspx?sessionId=3390

[.Gertjan.]

GateKeaper schreef op woensdag 06 februari 2013 @ 14:08:
Javascript is in opmars als je kijkt naar hoevaak en vooral hoe het toegepast wordt. Ruby is/was populair. Javascript groeit gewoon. Node.js is populair. Big difference tussen populair en in opmars.

Is toch ook niet zo vreemd? Steeds meer wordt gedaan in HTML en technieken als SilverLight en Flash zijn dood verklaard (of iig redelijk eol). Om enigzins dynamisch gedrag aan te bieden in een HTML app moet je wel met JavaScript aan de slag.

Er wordt minder "pure" javascript geschreven en men zal meer en meer af gaan hangen van frameworks, maar ook die worden gewoon in js aangeroepen.

Voor mobiele apps, maar ook voor Windows 8 is HTML gewoon een erg toegankelijke manier om je tool te bouwen. Tel daarnaast de grote hoeveelheid (mobiele) websites en het is niet echt verwonderlijk dat er veel JS is te vinden. En waar veel van te vinden is zal ook een grote hoeveelheid frameworks/libraries opleveren

[Bosmonster]

Flowmo schreef op woensdag 06 februari 2013 @ 14:14:
[...]
Ik ken genoeg front-end developers die bewust bij JS vandaan blijven omdat ze zich meer willen specialiseren in HTML en CSS dan in JS. Het moet je maar net liggen.

Meer dat laatste dan dat eerste lijkt me. Zonder JS kennis kun je eigenlijk niet meer spreken van een front-end developer mijns inziens, maar ga je terug naar de basis "html'er".

Javascript heeft zo'n enorme synergie met je DOM-opbouw en CSS, dat het erg lastig is alleen dat deel aan een ander over te laten. Wat dat betreft is het hetzelfde als een back-end developer zonder kennis van databases, of een Flash-developer die geen ActionScript kan/wil. Dan hou je ook niks meer over dan een veredelde animator.

Wat betreft de doctype-discussie: Ik zie geen reden waarom je in z'n geheel nog de oude (en gefaalde) XHTML-doctype zou gebruiken. Je beperkt jezelf onnodig (een simpel data-attribuut of YouTube-iframe is al een probleem) en bent 0,0 future-proof. Dat ze op scholen achterlopen is niks nieuws, maar de docent mag wel weten dat zodra je aan het werk gaat je die doctype nooit meer zult gebruiken.

[ Voor 45% gewijzigd door Bosmonster op 06-02-2013 14:36 ]

[zeef]

denyos schreef op woensdag 06 februari 2013 @ 14:25:
@zeef
Misschien dat je de sprekers van deze techdays sessie even kan benaderen: http://www.microsoft.com/...etail.aspx?sessionId=3390

Dat kan zeker. Het leek ons alleen leuk om eens te kijken of we niet iemand uit de community zouden kunnen vragen. Vandaar mijn oproep.

[MrAmos]

ziek thuis, ben erachter gekomen dat ziek zijn en programmeren alles behalve een goeie combi is..
en wauw, een dag het topic niet volgen en er is een nieuwe

[GateKeaper]

Maargoed, m.b.t. de populairiteit van javascript. Ging het mij meer om het feit dat ze beweren dat het komt omdat het per definitie "opensource" zou zijn, omdat je d.m.v. rechtsklik in de "bron" kan zien. (view source).

Daar geloof ik dus echt geen fluit van. Denk eerder dat het komt door de opmars van goede libraries (jquery bijvoorbeeld) waardoor ontwikkeling eenvoudiger wordt. Betere debugging tools, en vooral de betere support, featureset en performance van browser. Ook node.js zal z'n bijdrage hebben doordat het nu als "volwaardiger" kan worden gezien.

Eneuhm, m.b.t. 't werven verhaal. Geintje hoor

[Flowmo]

Die bewering klopt inderdaad van geen kanten. Javascript is per definitie al niet open-source, dat hangt af van de licentie die de ontwikkelaar van JS-code aan zijn code hangt. Dat je de bron kan bekijken, wil nog niet zeggen dat het open-source is, die definitie is breder dan "je kan het bekijken". Als ik mijn JS minify en je dat probeert te bekijken, nou succes!

[HMS]

GateKeaper schreef op woensdag 06 februari 2013 @ 14:52:
Maargoed, m.b.t. de populairiteit van javascript. Ging het mij meer om het feit dat ze beweren dat het komt omdat het per definitie "opensource" zou zijn, omdat je d.m.v. rechtsklik in de "bron" kan zien. (view source).

*surft naar www.google.nl, opent view source, spuugt koffie tegen beeldscherm*

[Erwin537]

GateKeaper schreef op woensdag 06 februari 2013 @ 14:52:
Maargoed, m.b.t. de populairiteit van javascript. Ging het mij meer om het feit dat ze beweren dat het komt omdat het per definitie "opensource" zou zijn, omdat je d.m.v. rechtsklik in de "bron" kan zien. (view source).

Daar geloof ik dus echt geen fluit van. Denk eerder dat het komt door de opmars van goede libraries (jquery bijvoorbeeld) waardoor ontwikkeling eenvoudiger wordt. Betere debugging tools, en vooral de betere support, featureset en performance van browser. Ook node.js zal z'n bijdrage hebben doordat het nu als "volwaardiger" kan worden gezien.

Eneuhm, m.b.t. 't werven verhaal. Geintje hoor

Nu moet ik zeggen dat ik minified JS niet bepaald open source vindt... Je kan het wel weer formatten, maar dan nog is het lastig lezen. Dan kan je het ook nog helemaal over schrijven en de variabelen/methodes weer hernoemen etc, maar dat zal toch wel behoorlijk lastig zijn.

EDIT:
En daar komt inderdaad nog bij dat Open Source meer is dan alleen de code kunnen bekijken.

[ Voor 4% gewijzigd door Erwin537 op 06-02-2013 14:59 ]

[Struikrover]

Het is wel open source, maar niet werkbaar. Het wordt pas werkbaar als je gewoon doorlinkt naar een GitHub repo met fatsoenlijke documentatie IMO

[Flowmo]

Struikrover schreef op woensdag 06 februari 2013 @ 14:59:
Het is wel open source, maar niet werkbaar. Het wordt pas werkbaar als je gewoon doorlinkt naar een GitHub repo met fatsoenlijke documentatie IMO

Nee, open source != "ik kan de broncode bekijken". Open source is een filosofie, niet het feit dat je met een paar klikken toegang hebt tot de code.

Ja, je mag er naar kijken. Nee, je mag het niet zomaar gebruiken, tenzij de ontwikkelaar heeft aangegeven dmv een licentie dat dat wel mag. Wanneer dit allebei wel mag, spreek je pas van open source. En zelfs dan nog kan de ontwikkelaar geld vragen voor het gebruik van zijn code.

[ZaZ]

Ik vind het ontwikkelen voor het web sowieso een bij elkaar geraapt zooitje. Een hele shitload aan talen en technieken etc dwars door elkaar en daar tegenaan weer een zooitje frameworks om terkortkomingen van bijna elk van die technieken en talen te 'vermakkelijken'
CSS zonder variabelen, barba pappa JS en ga zo maar door.

[Struikrover]

You gotta learn to love it, zullen we maar zeggen

[HMS]

ZaZ schreef op woensdag 06 februari 2013 @ 15:11:
Ik vind het ontwikkelen voor het web sowieso een bij elkaar geraapt zooitje. Een hele shitload aan talen en technieken etc dwars door elkaar en daar tegenaan weer een zooitje frameworks om terkortkomingen van bijna elk van die technieken en talen te 'vermakkelijken'
CSS zonder variabelen, barba pappa JS en ga zo maar door.

Gelukkig zijn er nog voorvechters als Vanilla JS: http://vanilla-js.com/

[curvemod]

HMS schreef op woensdag 06 februari 2013 @ 15:32:
[...]
Gelukkig zijn er nog voorvechters als Vanilla JS: http://vanilla-js.com/

Ja dat is nog eens een mooi klein 'framework', misschien dat het met Ecmascript 6 ook werkbaar wordt voor iedereen. Ben zelf wel erg te spreken over Typescript, mooi stukje code van Microsoft

[.oisyn]

Mooi ook hoe die paar examples al meteen precies laten zien wat er mis is met vanilla JS

[Firesphere]

HMS schreef op woensdag 06 februari 2013 @ 14:56:
[...]


*surft naar www.google.nl, opent view source, spuugt koffie tegen beeldscherm*

volgende keer de / me tag gebruiken

En inderdaad, WTF!?

[Barryvdh]

ZaZ schreef op woensdag 06 februari 2013 @ 15:11:
Ik vind het ontwikkelen voor het web sowieso een bij elkaar geraapt zooitje. Een hele shitload aan talen en technieken etc dwars door elkaar en daar tegenaan weer een zooitje frameworks om terkortkomingen van bijna elk van die technieken en talen te 'vermakkelijken'
CSS zonder variabelen, barba pappa JS en ga zo maar door.

Ah ik vind het tegenwoordig wel prima, met LESS/SCSS heb je variabelen in je CSS, met jQuery werkt je javascript op alle browsers hetzelfde en met een goed css boilerplate/framework werkt je website 9 van de 10 keer 'goed genoeg' op IE7+ zonder er veel extra moeite in te steken.

[GateKeaper]

Barryvdh schreef op woensdag 06 februari 2013 @ 16:19:
[...]

Ah ik vind het tegenwoordig wel prima, met LESS/SCSS heb je variabelen in je CSS, met jQuery werkt je javascript op alle browsers hetzelfde en met een goed css boilerplate/framework werkt je website 9 van de 10 keer 'goed genoeg' op IE7+ zonder er veel extra moeite in te steken.

Toch precies wat ZaZ zegt.

ZaZ schreef op woensdag 06 februari 2013 @ 15:11:
... Een hele shitload aan talen en technieken etc dwars door elkaar en daar tegenaan weer een zooitje frameworks om terkortkomingen van bijna elk van die technieken en talen te 'vermakkelijken'...

Dat je inmiddels een acceptabele manier hebt gevonden waarmee je om de tekortkomingen heen kunt werken, wil niet zeggen dat die tekortkomingen er niet zijn.

[ZaZ]

Barryvdh schreef op woensdag 06 februari 2013 @ 16:19:
[...]

Ah ik vind het tegenwoordig wel prima, met LESS/SCSS heb je variabelen in je CSS, met jQuery werkt je javascript op alle browsers hetzelfde en met een goed css boilerplate/framework werkt je website 9 van de 10 keer 'goed genoeg' op IE7+ zonder er veel extra moeite in te steken.

Hiermee bevestig je toch wat ik zeg? Je hebt van alles nodig omdat het bruikbaar te maken en dan nog blijft JS gewoon FUGLY

[Struikrover]

Als je heel eerlijk bent, ik denk niet dat de kans bestaat dat JS nog eens wordt vervangen door een andere programmeertaal om als client-side scripttaal te dienen. Je kunt dan denk ik het beste hopen op een opvolger van JS die de tekortkomingen grondig durft aan te pakken. Zoals jhuiting hierboven ook al zei

[RobIII]

RobIII schreef op woensdag 30 januari 2013 @ 19:31:
[...]

Er zijn iig al 2* van deze onderweg:
[afbeelding]

_{* 1 voor mij, 1 voor m'n collega die a.s. vrijdag begint}

* RobIII Marco Borsato stem opzet... "Binnuuuuuh!"

[Barryvdh]

ZaZ schreef op woensdag 06 februari 2013 @ 16:23:
[...]
Hiermee bevestig je toch wat ik zeg? Je hebt van alles nodig omdat het bruikbaar te maken en dan nog blijft JS gewoon FUGLY

Ik zeg toch ook niet dat je niet vanalles nodig hebt om het goed werkend te maken, alleen dat ik het tegenwoordig prima vind om mee te werken. Paar jaar geleden was het veel erger, toen die tools er nog niet waren en het altijd gekut was in IE6 en andere browsers. Nu is het meer een kwestie van je eigen boilerplate laden met evt van fallbacks en je niet meer zo druk hoeven te maken over dat je site niet meer werkt op oude browsers.

[R4gnax]

ZaZ schreef op woensdag 06 februari 2013 @ 16:23:
[...]

Hiermee bevestig je toch wat ik zeg? Je hebt van alles nodig omdat het bruikbaar te maken en dan nog blijft JS gewoon FUGLY

Jij hebt niet een probleem met JavaScript. Jij hebt een probleem met DOM. Significant verschil!

En ja; DOM zuigt.

[ Voor 3% gewijzigd door R4gnax op 06-02-2013 16:37 ]

[Pizzalucht]

Wat krijgen we nu, Apache doet niks meer, en stoppen/restarten doet hij ook niet.

Gelukkig is het een development server

De tweaker in mijn wil dit oplossen zonder de server te restarten, iemand een idee?

killall -9 apache2 en kill -9 [pid] heb ik al geprobeerd.