De Devschuur Coffee Corner - Iteratie ➑

[OkkE]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 11:48:
Ik gebruik juist wel ID's voor waar het van toepassing is. Ik zie dit meestal als 'core elementen' denk hierbij aan #footer of #header. Als ik dat als class zie, dan denk ik gelijk van "hergebruik je dat dan op je pagina, 2 footers?".

Waarschijnlijk gebruik je dat component maar één keer ja, maar wat is het verschil tussen een class en ID, behalve dat een ID je beperkt in het gebruik (1x) en een class niet.

kwaakvaak_v2 schreef op vrijdag 01 mei 2015 @ 11:48:
[...]


Gaat prima met Drupal hoor, je moet alleen wel zelf je templates maken en vooral niet gebruiken wat er uit het systeem komt rollen

Doe maar eens een view source op http://glr.nl/ (wel ff door de HTML minificatie heen prikken)

Drupal (7) heeft naar mijn idee te veel overbodige elementen, classnames en IDs op al zijn output. En de output van sommige elementen wijzigen kost te veel tijd naar mijn neming. Het is wel mogelijk, het kost alleen een stuk meer tijd/energie dan dat ik zou willen bij een CMS.

[Douweegbertje]

ronaldlokers schreef op vrijdag 01 mei 2015 @ 12:46:
[...]


Als de kosten om iets te ondersteunen hoger zijn dan wat het opbrengt is het niet nuttig meer om een al verouderde browser nog te blijven ondersteunen.

Je geeft alleen geen antwoord op de vraag.

OkkE schreef op vrijdag 01 mei 2015 @ 12:47:
[...]

Waarschijnlijk gebruik je dat component maar één keer ja, maar wat is het verschil tussen een class en ID, behalve dat een ID je beperkt in het gebruik (1x) en een class niet.

[...]

Tja, wat is het verschil tussen iets nested doen of direct op het element. Aan de eindkant niets maar inhoudelijk weer wel. Waarom zou je een footer als class benoemen, wil je dan 2 footers? Anders 'moet' het gewoon een ID zijn, omdat het een uniek element is wat één keer voorkomt. Gewoon eigenlijk best practice maar als je dat doorvoert voorkom je ook 'foutjes' en zou technisch gezien je style wat netter worden. Daarbij kun je wat specifieker zijn op een ID bijvoorbeeld.
Los van dat zou je inderdaad overal classes kunnen gebruiken.. echter dat het werkt, simpeler is en ga zo maar door wilt nog niet zeggen dat het dan 'goed' is

Oh en je hebt ID's nodig voor bijv. tweakers.net/forum#idvanelement

[incaz]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 11:48:
Ik gebruik juist wel ID's voor waar het van toepassing is. Ik zie dit meestal als 'core elementen' denk hierbij aan #footer of #header. Als ik dat als class zie, dan denk ik gelijk van "hergebruik je dat dan op je pagina, 2 footers?".

Ik heb gewoon <footer>.

Maar nee, je hergebruikt het niet maar een class hoeft niet hergebruikt te worden natuurlijk. Het kan afhankelijk van de omstandigheden heel handig zijn om niet aan je priorities te komen of juist wel. Voor eenvormigheid van je css kan het wel gewoon makkelijk zijn om alles via classes te doen, waarom niet?

Overigens... duidelijk niet handig: verschillende forms op verschillende pagina's allemaal hetzelfde id geven. Zowel voor css als javascript niet echt handig. Ik kan het helaas ook niet veranderen omdat de backend de forms dan niet meer kan verwerken.

[Douweegbertje]

Ja waarom niet, waarom wel. Omdat het daar niet direct voor is?
Waarom zouden we niet alle int's in strings zetten. Uiteindelijk werkt het alsnog het zelfde (op misschien wat dingen na afhankelijk van je taal natuurlijk). Omdat het kan, is geen valide reden

[Soultaker]

Laurens-R schreef op vrijdag 01 mei 2015 @ 11:20:
Ik denk eerlijk gezegd dat je in de IT geen enkel bedrijf zal aantreffen die nog doet aan zo'n sociaal-communistisch relikwie als de dag van de arbeid.

Dat zal je tegenvallen; Dag van de Arbeid is in de meeste landen in de wereld een vrije dag. In Europa doen alleen Nederland en Denemarken er niet aan (ministaatjes als Vaticaanstad en Andorra even buiten beschouwing gelaten).

* Soultaker geniet dus lekker van z'n vrije dag vandaag

[OkkE]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 12:54:
[...]
Waarom zou je een footer als class benoemen, wil je dan 2 footers? Anders 'moet' het gewoon een ID zijn, omdat het een uniek element is wat één keer voorkomt. Gewoon eigenlijk best practice maar als je dat doorvoert voorkom je ook 'foutjes' en zou technisch gezien je style wat netter worden. Daarbij kun je wat specifieker zijn op een ID bijvoorbeeld.

Let's agree to disagree.

Geen zin om verder door te gaan (ik word betaald voor front-end, niet om er over te praten op GoT helaas ), we verschillen duidelijk van mening/werkwijze en we zullen beide niet (snel) veranderen. Mijn denkwijze komt iig overeen met http://cssguidelin.es/ (mocht je daar interesse in hebben)

[ Voor 5% gewijzigd door OkkE op 01-05-2015 13:13 ]

[SPee]

incaz schreef op vrijdag 01 mei 2015 @ 12:54:
[...]
Overigens... duidelijk niet handig: verschillende forms op verschillende pagina's allemaal hetzelfde id geven. Zowel voor css als javascript niet echt handig. Ik kan het helaas ook niet veranderen omdat de backend de forms dan niet meer kan verwerken.

Een id mag in de HTML niet meerdere keren voorkomen.
Je krijgt dan totaal willekeurig gedrag van de browser.
Een getElementById die de eerste of laatste teruggeeft of enkel de eerste krijgt de id en de rest een random id of css werkt mogelijk niet op die id.
Voorkomen dus.

[wackmaniac]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 12:54:
[...]


Je geeft alleen geen antwoord op de vraag.

Precies. Je opmerking heeft niets met de grootte van een afdeling te maken. Je afdeling is te groot om IE8 te ondersteunen, maar blijkbaar groot genoeg om jou om de hele week al IE8 fallbacks te verwijderen

[incaz]

SPee schreef op vrijdag 01 mei 2015 @ 13:24:
Een id mag in de HTML niet meerdere keren voorkomen.

Gaat om verschillende pagina's Geen invalid html dus.

[kwaakvaak_v2]

OkkE schreef op vrijdag 01 mei 2015 @ 12:47:
[...]

Waarschijnlijk gebruik je dat component maar één keer ja, maar wat is het verschil tussen een class en ID, behalve dat een ID je beperkt in het gebruik (1x) en een class niet.

[...]

Drupal (7) heeft naar mijn idee te veel overbodige elementen, classnames en IDs op al zijn output. En de output van sommige elementen wijzigen kost te veel tijd naar mijn neming. Het is wel mogelijk, het kost alleen een stuk meer tijd/energie dan dat ik zou willen bij een CMS.

Die site is Drupal 7 En de hoeveelheid energie valt reuze mee. De truuk is te starten met een goed schoon basis thema. Bijv. Mothership, of ik mijn geval mijn eigen twig basis thema wat bijna alle bullshit eruit mikt. En dan een child theme maken, waarin je alleen implementeert wat nodig is.

[Douweegbertje]

OkkE schreef op vrijdag 01 mei 2015 @ 13:11:
[...]


Let's agree to disagree.

Geen zin om verder door te gaan (ik word betaald voor front-end, niet om er over te praten op GoT helaas ), we verschillen duidelijk van mening/werkwijze en we zullen beide niet (snel) veranderen. Mijn denkwijze komt iig overeen met http://cssguidelin.es/ (mocht je daar interesse in hebben)

Ik geef gewoon mijn mening en kan binnen luttele secondes omgepraat worden als iemand een fatsoenlijke argumentatie geeft in plaats van een link waar ik zelf mag zoeken naar de specifieke content over het discussie onderwerp

Het enige wat ik in zijn blog zie is dat hij ooit een probleem heeft gehad omdat hij niet nadacht over zijn ID gebruik, waardoor hij nu ID's in zijn algemeenheid in de ban doet.

code:

#content table {}

Dat is gewoon te generiek, en heeft geen kut met ID's te maken maar met dom gebruik (snap je de pun?).

Je kan gewoon #content {} gebruiken om precies dat element te stylen, en dan gewoon een class maken voor .table bijvoorbeeld waar je dan specifieke meuk voor de table in zet. In elk geval zijn er vele manieren hoe het had gekund maar ik vind het een kul argument om vervolgens geen ID's te gebruiken.

Eigenlijk is dit het perfecte voorbeeld waarom je juist wel ID's moet gebruiken, omdat sommige hun hoofd niet gebruiken over het algemeen gebruik van elementen/benamingen en nestings. Inherent daaraan maak je dan gewoon structurele fouten die niet opvallen omdat je bijvoorbeeld classes gebruikt. Nogmaals; dat het werkt wilt nog niet zeggen dat het goed is.

Het gaat er niet eens om dat je verplicht overal maar ID's moet neer zetten. Uiteindelijk moet je gewoon al nadenken van; ga ik dit hergebruiken en bij een ja of een twijfel gebruik je een class. Anders een ID.

[Gamebuster]

OkkE schreef op vrijdag 01 mei 2015 @ 11:45:
[...]
mega stuff

Je "mag" wel declaraties toevoegen aan meerdere css selectors

.foo,
.bar { ...stuff... }

Douweegbertje schreef op vrijdag 01 mei 2015 @ 11:48:
Ik gebruik juist wel ID's voor waar het van toepassing is. Ik zie dit meestal als 'core elementen' denk hierbij aan #footer of #header. Als ik dat als class zie, dan denk ik gelijk van "hergebruik je dat dan op je pagina, 2 footers?".

Kan ik me zeker in vinden. In situaties waarbij het echt onmogelijk is om meer dan 1 ervan te hebben (door gekke positioning o.i.d.) wil ik wel eens IDs gebruiken, maar in normale situaties, zoals bij footer en header, gebruik ik gewoon classnames.

Nee, je wil er niet 2 op een pagina, maar wie weet wil je het ooit wel. Zo hadden wij een zoekbalk met extra funky dingen (dropdown met settings enzo) in de header met een ID. Later moest-ie ook in de footer. Mochten we alle ID-references gaan refactoren naar classnames. Voortaan dus altijd gewoon alle styles op een classname of element; IDs hebben in mijn ogen geen meerwaarde in CSS.

[ Voor 149% gewijzigd door Gamebuster op 01-05-2015 14:35 ]

[HuHu]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 11:48:
Ik gebruik juist wel ID's voor waar het van toepassing is. Ik zie dit meestal als 'core elementen' denk hierbij aan #footer of #header. Als ik dat als class zie, dan denk ik gelijk van "hergebruik je dat dan op je pagina, 2 footers?".

Waarom zou je de footer een ID geven en niet gewoon de footer-tag gebruiken?

[OkkE]

kwaakvaak_v2 schreef op vrijdag 01 mei 2015 @ 13:41:
[...]


Die site is Drupal 7 En de hoeveelheid energie valt reuze mee. De truuk is te starten met een goed schoon basis thema. Bijv. Mothership, of ik mijn geval mijn eigen twig basis thema wat bijna alle bullshit eruit mikt. En dan een child theme maken, waarin je alleen implementeert wat nodig is.

Misschien zit 'm dan daar het probleem; wij gebruiken een ander parent theme wat (waarschijnlijk) als nog te veel overbodige code bevat. En mijn kennis (niet heel veel) van Drupal helpt ook niet mee natuurlijk.
.

Douweegbertje schreef op vrijdag 01 mei 2015 @ 13:47:
Ik geef gewoon mijn mening en kan binnen luttele secondes omgepraat worden als iemand een fatsoenlijke argumentatie geeft in plaats van een link waar ik zelf mag zoeken naar de specifieke content over het discussie onderwerp

Die website is meer dan alleen het kleine stukje over ID-gebruik. Er staat een hele werkwijze beschreven, waar géén IDs gebruiken een onderdeel van is en wat daar imho een logisch onderdeel/oorzaak van is.

Het voornaamste punt is: dat je van plan bent iets maar één keer te gebruiken is niet relevant. Je ontwikkeld componenten (bouwstenen) van HTML+CSS, waar je een website mee "in elkaar zet". Je zet het zo op dat alles herbruikbaar is; wie weet is het ooit nodig* een component 2x te gebruiken, kwaad kan het niet en door alleen classes te gebruiken blijft je code uniform.

*) Denk bijv. aan een pagina die een Lightbox opent waar content inclusief de zelfde pagina footer in moet komen; for whatever reason.
.

Gamebuster schreef op vrijdag 01 mei 2015 @ 14:31:
[...]
Je "mag" wel declaraties toevoegen aan meerdere css selectors

.foo,
.bar { ...stuff... }

[...]

True. Wel kan je dan een situatie krijgen als:

Cascading Stylesheet:

.navigation-menu,
.navigation-submenu,
.navigation-footer,
.navigation-dropdown {
    /* ... */
}

[RobertMe]

HuHu schreef op vrijdag 01 mei 2015 @ 14:42:
[...]

Waarom zou je de footer een ID geven en niet gewoon de footer-tag gebruiken?

Hoe onderscheid je dan de footer van de pagina met de footer van bv een <article> op de pagina? Dat is dan natuurlijk wel onmogelijk (of moet je weer terug vallen op classes). <header> en <footer> zijn in principe bedoelt voor zowel de pagina an zich als voor gebruik binnen <section> elementen (waarvan <article> een derived is). Als je bv hier naar een GoT post kijkt zou je best kunnen zeggen dat het tijdstip van de post en alle acties binnen een <header> horen, en de signature binnen een <footer> (en de volledige post als <article>).

Het zou ook een beetje apart zijn als het W3C elementen gaat verzinnen puur voor de semantische waarde, dus zonder echte betekenis, terwijl je dat element dan maar 1x op een pagina gebruikt. (<title> gebruik je ook maar een keer op een pagina, maar daar doet de browser rechtstreeks wat mee, tussen <footer> en <div> zit geen verschil behalve de semantische naam)

[Voutloos]

RobertMe schreef op vrijdag 01 mei 2015 @ 15:15:
[...]

Hoe onderscheid je dan de footer van de pagina met de footer van bv een <article> op de pagina? Dat is dan natuurlijk wel onmogelijk

Eh, gewoon de ' article footer' css selector?

Het zou ook een beetje apart zijn als het W3C elementen gaat verzinnen puur voor de semantische waarde, dus zonder echte betekenis, terwijl je dat element dan maar 1x op een pagina gebruikt. (<title> gebruik je ook maar een keer op een pagina, maar daar doet de browser rechtstreeks wat mee, tussen <footer> en <div> zit geen verschil behalve de semantische naam)

Veel elementen zijn juist voor de semantiek bedacht? Wat is er uberhaupt een beetje apart?

[WernerL]

Voutloos schreef op vrijdag 01 mei 2015 @ 15:22:
[...]
Eh, gewoon de ' article footer' css selector?

[...]

Wanneer je in je CSS een selector hebt op footer en nog een op article footer kun je in die laatste een hoop styling van footer overschrijven. Dan lijkt het mij handiger om er gewoon even een classname aan te hangen. Dan kun je de tagname alsnog meenemen, dus zoiets:

footer.footer-website { ... }
footer.footer-forumpost { ...}
footer.footer-newsitem {..}
..etc.

[Voutloos]

Tja, het hangt van je documenten en stijl af of het cascaden leuk uit pakt en waar je dus voor moet kiezen.

Een class is niet altijd beter, net als dat enkel een element naam niet altijd de oplossing is. Maar dan nog kan je wel altijd de best relevante elementnaam kiezen.

[F.West98]

Ik doe het vast heel slecht maar sinds LESS bouw ik mijn CSS eigenlijk op als de HTML-DOM.

LessCss:

/* Algemene styles */
/*******Fonts********/
.left {}
.right {}
/*******Andere algemene blokken/herbruikbare delen *****/

/* Pagina opbouw */
#wrapper {
    header {
        .nav {
            li {}
        }
    }
    .content {
        .block {}
    }
    footer {}
}

/* Form styles */
input {}
.form {}

/* Specifieke styles */

Nadeel is dat je na compilen dan dit krijgt:

Cascading Stylesheet:

.content #header #navigation li#search:hover .search input {}
.content #header #navigation li#search .results a:not(.none):after {} /* .none is dan dat er geen resultaten zijn, en in de HTML is het veel overzichtelijker dan .navigation-search-results-no-results oid */

.input-box > input:disabled,
.textarea-box > input:disabled,
.dropdown-box > input:disabled,
.button-box > input:disabled,
.input-box > textarea:disabled,
.textarea-box > textarea:disabled,
.dropdown-box > textarea:disabled,
.button-box > textarea:disabled,
.input-box > select:disabled,
.textarea-box > select:disabled,
.dropdown-box > select:disabled,
.button-box > select:disabled,
.input-box > button:disabled,
.textarea-box > button:disabled,
.dropdown-box > button:disabled,
.button-box > button:disabled,
.input-box > div:disabled,
.textarea-box > div:disabled,
.dropdown-box > div:disabled,
.button-box > div:disabled,
.input-box > span.title:disabled,
.textarea-box > span.title:disabled,
.dropdown-box > span.title:disabled,
.button-box > span.title:disabled {}

Die laatste is dus 'gewoon' een algemene style voor bepaalde inputs en dan de elementen erin. De LESS is een stuk eleganter

[Douweegbertje]

OkkE schreef op vrijdag 01 mei 2015 @ 14:57:
[...]

Misschien zit 'm dan daar het probleem; wij gebruiken een ander parent theme wat (waarschijnlijk) als nog te veel overbodige code bevat. En mijn kennis (niet heel veel) van Drupal helpt ook niet mee natuurlijk.
.

[...]


Die website is meer dan alleen het kleine stukje over ID-gebruik. Er staat een hele werkwijze beschreven, waar géén IDs gebruiken een onderdeel van is en wat daar imho een logisch onderdeel/oorzaak van is.

Het voornaamste punt is: dat je van plan bent iets maar één keer te gebruiken is niet relevant. Je ontwikkeld componenten (bouwstenen) van HTML+CSS, waar je een website mee "in elkaar zet". Je zet het zo op dat alles herbruikbaar is; wie weet is het ooit nodig* een component 2x te gebruiken, kwaad kan het niet en door alleen classes te gebruiken blijft je code uniform.

*) Denk bijv. aan een pagina die een Lightbox opent waar content inclusief de zelfde pagina footer in moet komen; for whatever reason.

Die website heet niet voor niets guidelines en dan vind ik dat je met fatsoenlijke argumenten moet komen waarin je aantoont waarom jouw guideline zo "goed" is of op zijn minst waarom jij denkt dat mensen dit moeten toepassen. Er wordt duidelijk aangegeven waarom o.a. je ID's niet moet gebruiken maar de gehele argumentatie slaat nergens op. Lees anders zelf nog even dat stukje. Ik vind het echt een groot stukje onzin

In elk geval dat terzijde probeer je nu iets te verzinnen waarin een ID niet werkt. Daarop weer heel simpel het antwoord: als je zelf bedenkt dat er een lightbox moet komen met precies de zelfde footer.. dan maak je er een class van. Ik heb nooit classes verboden, ik gaf alleen aan dat je er over na moet denken en het correct moet gebruiken.

Overigens @huhu was mijn footer gewoon een simpel voorbeeld omdat dat meestal gewoon op zich zelf een uniek element is die niet > 1 voorkomt op een website.

[incaz]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 16:06:
Die website heet niet voor niets guidelines en dan vind ik dat je met fatsoenlijke argumenten moet komen waarin je aantoont waarom jouw guideline zo "goed" is of op zijn minst waarom jij denkt dat mensen dit moeten toepassen.

Van de andere kant - jij gooit net zo goed een guideline op: 'als je verwacht dat een element uniek is gebruik je een id en geen class'. Maar daarvan kun je je net zo goed afvragen waarom dat zo is. Jij zei al eerder dat classes daar 'niet voor bedoeld waren' oid, maar door wie niet bedoeld? Waar staat dat? Welke argumentatie ligt daar aan ten grondslag?

[orf]

Volgens mij staat dit er over ID's:

IDs in CSS

If we want to keep specificity low, which we do, we have one really quick-win, simple, easy-to-follow rule that we can employ to help us: avoid using IDs in CSS.

Not only are IDs inherently non-reusable, they are also vastly more specific than any other selector, and therefore become specificity anomalies. Where the rest of your selectors are relatively low specificity, your ID-based selectors are, comparatively, much, much higher.

In fact, to highlight the severity of this difference, see how one thousand chained classes cannot override the specificity of a single ID: jsfiddle.net/0yb7rque. (Please note that in Firefox you may see the text rendering in blue: this is a known bug, and an ID will be overridden by 256 chained classes.)

N.B. It is still perfectly okay to use IDs in HTML and JavaScript; it is only in CSS that they prove troublesome.

It is often suggested that developers who choose not to use IDs in CSS merely don’t understand how specificity works. This is as incorrect as it is offensive: no matter how experienced a developer you are, this behaviour cannot be circumvented; no amount of knowledge will make an ID less specific.

Opting into this way of working only introduces the chance of problems occurring further down the line, and—particularly when working at scale—all efforts should be made to avoid the potential for problems to arise. In a sentence:

It is just not worth introducing the risk.

[OkkE]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 16:06:
[...]


Die website heet niet voor niets guidelines en dan vind ik dat je met fatsoenlijke argumenten moet komen waarin je aantoont waarom jouw guideline zo "goed" is of op zijn minst waarom jij denkt dat mensen dit moeten toepassen. Er wordt duidelijk aangegeven waarom o.a. je ID's niet moet gebruiken maar de gehele argumentatie slaat nergens op. Lees anders zelf nog even dat stukje. Ik vind het echt een groot stukje onzin

Als je alleen dat kleine stukje over IDs op die website leest, is het voor jou misschien niet overtuigend. Hoewel de schrijver in mijn ogen toch een stuk meer “recht van spreken” heeft dan jij en ik. De link was vooral als achtergrond info, imho staat er een erg goede werkwijze in beschreven (en heeft mij overtuigd).

In elk geval dat terzijde probeer je nu iets te verzinnen waarin een ID niet werkt. Daarop weer heel simpel het antwoord: als je zelf bedenkt dat er een lightbox moet komen met precies de zelfde footer.. dan maak je er een class van. Ik heb nooit classes verboden, ik gaf alleen aan dat je er over na moet denken en het correct moet gebruiken.

Ik probeer niks te verzinnen, dat is een situatie die voor komt. En je kan zeggen “dan gebruik je in dat geval geen ID”, maar wat nu als de wens voor die Lightbox pas tijdens een update komt? Mijn vraag is: waarom zou je voor sommige situaties een ID gebruiken, terwijl een class in de meeste situatie even goed/beter werkt?

Overigens @huhu was mijn footer gewoon een simpel voorbeeld omdat dat meestal gewoon op zich zelf een uniek element is die niet > 1 voorkomt op een website.

Je gaat er van uit dat zo'n element maar één keer voor komt, wat bij zoiets als een pagina footer waarschijnlijk zo is, maar waarom jezelf beperken met de (kleine) kans dat je het later als nog moet ombouwen naar een class?

[Firesphere]

Zo, tijd voor een 87232103

[kenneth]

LOL, cheers

[Firesphere]

kenneth schreef op vrijdag 01 mei 2015 @ 16:40:
[afbeelding]

LOL, cheers

Hah, ik wist't, Tweakers gonna Tweak.

[Gamebuster]

OkkE schreef op vrijdag 01 mei 2015 @ 14:57:
True. Wel kan je dan een situatie krijgen als:

Cascading Stylesheet:

.navigation-menu,
.navigation-submenu,
.navigation-footer,
.navigation-dropdown {
    /* ... */
}

Dat is correct. Of een SCSS mixin/variable

[Douweegbertje]

OkkE schreef op vrijdag 01 mei 2015 @ 16:23:
[...]

Als je alleen dat kleine stukje over IDs op die website leest, is het voor jou misschien niet overtuigend. Hoewel de schrijver in mijn ogen toch een stuk meer “recht van spreken” heeft dan jij en ik. De link was vooral als achtergrond info, imho staat er een erg goede werkwijze in beschreven (en heeft mij overtuigd).

[...]

Ik hoef niet direct op de rest in te gaan omdat ik het daar wel mee eens ben. Alleen dan zeg ik het nog een keer, ik vind heel dat voorbeeld omtrent ID's zo'n slecht voorbeeld dat ik moeite heb om alles serieus te nemen. Noem het maar een dooddoener.
Het is niet direct dat ik hier nu de css guru ben, ik ben meer iemand met een andere mening maar als ik zijn vergelijkingen in een andere context moet plaatsen dan krijg je iets van:
Als je 3 flessen cola drinkt per dag is het ongezond, dus drink nooit cola. Echt.. much sense much.
En we zijn nu al wat reacties verder maar niemand is inhoudelijk op dit stuk in gegaan, behalve dat zijn guideline goed is. Kan het niet gewoon zo zijn dat het allemaal best netjes is maar dat hij de plank mis slaat omtrent ID gebruik?

Ik probeer niks te verzinnen, dat is een situatie die voor komt. En je kan zeggen “dan gebruik je in dat geval geen ID”, maar wat nu als de wens voor die Lightbox pas tijdens een update komt? Mijn vraag is: waarom zou je voor sommige situaties een ID gebruiken, terwijl een class in de meeste situatie even goed/beter werkt?

[...]

Je gaat er van uit dat zo'n element maar één keer voor komt, wat bij zoiets als een pagina footer waarschijnlijk zo is, maar waarom jezelf beperken met de (kleine) kans dat je het later als nog moet ombouwen naar een class?

Weer super afhankelijk van de context, maar het is gewoon netjes om een vast element dat één keer voorkomt en dus uniek is als een ID te behandelen. Als er een update komt, gooi je dan zomaar een class op een element en voila hier is je 2e footer? Meestal wil je toch nog wat aanpassingen doen immers zijn de afmetingen sowieso anders en de eventuele plaatsing ook. Qua implementatie hoeft het niet gek te zijn om een ID te hebben als:

#footer, .lbFooter {} (vanuitgaande dat je de lightbox footer vaker gaat gebruiken) met vervolgens wat specifieke css rules, en vervolgens nog misschien een class met generieke css settings.


Wellicht het verschil qua denkwijze is dat ik niet per se kijk naar de achterliggende techniek, maar meer de denkwijze wat IMO enorm belangrijk is. Uiteraard kun je alles met classes doen, en dat gaat ook werken en wellicht heb je er nooit 'problemen' mee. De enige reden dat deze discussie vaak speelt is omdat men geen 'tastbare' verschillen ziet tussen een ID en een class, overigens begrijpelijk.
Je ziet haast alleen de wat 'negatievere' eigenschappen die grotendeels voortkomen uit gemakzucht Alleen classes gebruiken zie ik soort van loosely typed terwijl het gebruik met ID's meer richting 'strict' gaat. Gezien al het gezeik op PHP verbaast het me dan dat het bij CSS opeens niet meer uitmaakt om lekker alles losjes te gaan doen.

Overigens nog een verkapte vergelijking... id = instance en class = class.

Dan nog de vraag; stel je hebt een select box die je vult met een iteratie over wat items uit de db. Zet je dan een option class of option id neer?

incaz schreef op vrijdag 01 mei 2015 @ 16:18:
[...]


Van de andere kant - jij gooit net zo goed een guideline op: 'als je verwacht dat een element uniek is gebruik je een id en geen class'. Maar daarvan kun je je net zo goed afvragen waarom dat zo is. Jij zei al eerder dat classes daar 'niet voor bedoeld waren' oid, maar door wie niet bedoeld? Waar staat dat? Welke argumentatie ligt daar aan ten grondslag?

W3C. Het niet zo zwart-wit van 'daar is het niet voor bedoeld' maar een ID is in feite voor een uniek element, of visa-versa; door een id wordt het een uniek element. Wellicht heb je daar technisch gezien niets aan (of wel juist om juist één element specifiek te beheren) maar je wilt toch eigenlijk een best practise gebruiken? Of op zijn minst de dingen gebruiken die er voor gemaakt/bedoeld zijn.
Voor mij is het zowat het zelfde om ipv van de h1 tag maar een div.kop1 aan te maken om daar wat meuk in te zetten om de h1 te vervangen.. je gebruikt toch gewon de h1 terwijl het op 100 andere manieren kan.. waarom wel de h1 gebruiken conform de 'bedoeling' en een ID niet (en sterker nog, het gewoon afschrijven/afraden..)

[ Voor 14% gewijzigd door Douweegbertje op 01-05-2015 18:19 ]

[incaz]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 18:13:
[...]
W3C. Het niet zo zwart-wit van 'daar is het niet voor bedoeld' maar een ID is in feite voor een uniek element, of visa-versa; door een id wordt het een uniek element. Wellicht heb je daar technisch gezien niets aan (of wel juist om juist één element specifiek te beheren) maar je wilt toch eigenlijk een best practise gebruiken? Of op zijn minst de dingen gebruiken die er voor gemaakt/bedoeld zijn.

Wiens best practice dan? Id's zijn belangrijk als je een specifiek element wilt targetten - dat is met javascript. Bij css is de uniciteit in principe niet relevant, en ik kan dan ook nergens vinden dat je voor alle elementen die vermoedelijk uniek zullen zijn, een id de beste keuze is.

Mocht je een bron hebben die dat onderbouwt, dan graag. Maar tot die tijd is jou 'het is gewoon netter' en 'daar is het niet voor bedoeld' in elk geval zeker niet overtuigender als guideline dan 'hou het gewoon lekker bij classes in css, dan heb je ook geen gezeur'.

Voor mij is het zowat het zelfde om ipv van de h1 tag maar een div.kop1 aan te maken om daar wat meuk in te zetten om de h1 te vervangen.. je gebruikt toch gewon de h1 terwijl het op 100 andere manieren kan.. waarom wel de h1 gebruiken conform de 'bedoeling' en een ID niet (en sterker nog, het gewoon afschrijven/afraden..)

Omdat h1 een semantische betekenis aangeeft, terwijl een id geen relevante semantiek draagt als er niet iets is dat die uniciteit nodig heeft. Heel concreet heeft een h1 ook betekenis voor Google en de al dan niet hypothetische screen reader.

Maar een id is alleen interessant als het ook werkelijk belangrijk is om dat specifieke element als uniek te benaderen. Dat kan als je graag een linkje naar site.com/#footer wilt, en als je met javascript content wilt laden is het meestal ook heel handig, maar in de css doet het er eigenlijk niet toe.

[Avalaxy]

CSS... Boeeiend! Ga bier drinken, het is vrijdag

[Firesphere]

Zo. KvK binnenkort maar eens weer regelen.
* Firesphere gaat weer een bedrijf officieel opstarten.

[Caelorum]

Avalaxy schreef op vrijdag 01 mei 2015 @ 19:16:
CSS... Boeeiend! Ga bier drinken, het is vrijdag

Crap... Dat ben ik vergeten te halen

Mja, dan maar whiskey...

Firesphere schreef op vrijdag 01 mei 2015 @ 19:18:
Zo. KvK binnenkort maar eens weer regelen.
* Firesphere gaat weer een bedrijf officieel opstarten.

Een boeiend bedrijf of?

[ Voor 35% gewijzigd door Caelorum op 01-05-2015 19:29 ]

[F.West98]

@CSS sluit ik me wel een beetje aan bij Douweegbertje. Ik gebruik classes vooral voor dingen waarvan er meerdere bestaan, herbruikbare elementen, of om een 'eigenschap' aan een object te geven. Ik heb dus altijd #nav, #header, #wrapper, #footer, enz, maar .block, .left(-align), .right(-align). Dingen stylen als .navigation-header-item-text ofzo vind ik ook enorm onduidelijk.
Als ik CSS (geen LESS) schrijf probeer ik ook altijd zo veel mogelijk stijlen her te gebruiken en het eigenlijk een stuk modulairder te maken. Je kan dan later makkelijk nieuwe dingen toevoegen zonder bijzonder veel nieuwe stijl te maken, en je kan bestaande dingen met veel gemak aanpassen. Waar Gamebuster dus tegenaan liep met die lange classnames, heb ik op die manier geen last van. Iets heeft dan misschien wel twee of drie classes, maar het is imo een stuk duidelijker... Beetje als Bootstrap eigenlijk.

[incaz]

F.West98 schreef op vrijdag 01 mei 2015 @ 19:46:
maar .block, .left(-align), .right(-align).

En dan ga je het responsive maken en dan krijg je

Cascading Stylesheet:

.right{
   text-align: center;
}
.block{
   display: inline;
}

Brrrr.

* incaz heeft geen bier

[.oisyn]

Een class als .left-align is pointless, gebruik dan gewoon inline styles . Dat is net zoiets als een constante FOUR gebruiken ipv de literal 4 in een programmeertaal, met als achterliggende reden dat hardcoded literals uit den boze zijn. Tja, dan heb je het gewoon niet helemaal begrepen...

[azerty]

incaz schreef op vrijdag 01 mei 2015 @ 19:59:
[...]


En dan ga je het responsive maken en dan krijg je

Cascading Stylesheet:

.right{
   text-align: center;
}
.block{
   display: inline;
}

Brrrr.

* incaz heeft geen bier

Je neemt me de woorden uit de mond

[Caelorum]

incaz schreef op vrijdag 01 mei 2015 @ 19:59:
[...]En dan ga je het responsive maken en dan krijg je

Cascading Stylesheet:

.right{
   text-align: center;
}
.block{
   display: inline;
}

Brrrr. [...]

Nee, bovenstaande ga je alleen krijgen als je idioten hebt. Je geeft hooguit het element een andere class mee, maar je gaat niet de betekenis van een .right veranderen in een center. Dan ben je gewoon dom en zou je lekker ander werk moeten gaan doen.
Overigens zou ik niet eens dat soort css gaan schrijven. .right of .block zeggen totaal niets. Dan kan je beter meteen de styling zetten.


Wat .oisyn dus zegt ^^

[F.West98]

incaz schreef op vrijdag 01 mei 2015 @ 19:59:
[...]


En dan ga je het responsive maken en dan krijg je

Cascading Stylesheet:

.right{
   text-align: center;
}
.block{
   display: inline;
}

Brrrr.

Block is meer dan een 'building block' voor de content met een bepaalde padding, bepaalde margins en bepaalde achtergronden/borders. Waarom een .right (voor de float left/right) dan ineens text-align center moet hebben snap ik niet. Zo gebruik ik het niet.

* incaz heeft geen bier

* F.West98 ook niet

.oisyn schreef op vrijdag 01 mei 2015 @ 20:26:
Een class als .left-align is pointless, gebruik dan gewoon inline styles . Dat is net zoiets als een constante FOUR gebruiken ipv de literal 4 in een programmeertaal, met als achterliggende reden dat hardcoded literals uit den boze zijn. Tja, dan heb je het gewoon niet helemaal begrepen...

.left en .right zijn vooral om het makkelijk met JS te kunnen doen, maar ook om inline styles te voorkomen in de DOM. Ik vind een class .left veel overzichtelijker dan style="float: right;", ook is het mogelijk om dan .right + * te doen en die dan een clear te geven als dat nodig is. Dat kan weer niet met de inline styles.

Maar op diezelfde manier heb ik ook classes om bijvoorbeeld een list in een list vanzelf te veranderen in een uitklapmenu oid. Nu is "block" een slecht voorbeeld, maar bijvoorbeeld .content-block oid zou zomaar in mijn CSS kunnen voorkomen.

[Firesphere]

EddoH schreef op vrijdag 01 mei 2015 @ 11:03:
Ik geef je weinig kans van slagen TBH

Niet dat je daar wat aan hebt..

Gamebuster schreef op vrijdag 01 mei 2015 @ 11:10:
@decompilen discussie: Ik denk dat het hier niet om de bestemming gaat, maar om de reis. Leuk projectje! Documenteer het en dump het in blogs. Ik ben nieuwsgierig. Zelfs als het knalhard faalt.

Wat Gamebuster dus zegt.
Het is leuk om te proberen, als het iets bruikbaars oplevert, gooi ik een blog online. Als het een complete faal oplevert, valt er natuurlijk weinig te bloggen.
En mocht het een totaal succes worden, dan draag ik weer een steentje bij aan de OS community.

Dingen doen om het doen, om het proberen, om te zien waar je terecht komt, dat vind ik persoonlijk het leukste. Leuker dan het uiteindelijke resultaat.

[incaz]

F.West98 schreef op vrijdag 01 mei 2015 @ 20:37:
[...]

Block is meer dan een 'building block' voor de content met een bepaalde padding, bepaalde margins en bepaalde achtergronden/borders. Waarom een .right (voor de float left/right) dan ineens text-align center moet hebben snap ik niet. Zo gebruik ik het niet.

Qua .block: ok, die trek ik terug.

.right is een lastigere, als je die class echt alleen maar toevoegt via javascript kan het. Ik heb om die reden ook een .hidden gemaakt. Maar rechtstreeks in de source gaat het vaak mis bij responsive design: een mobile browsersschermpje in portraitmode is smal en dus zet je daar vaak elementen onder elkaar ipv naast elkaar. Waar het op een breed scherm heel logisch kan zijn om iets naar rechts te schuiven (text-align of float) kan dat op mobile heel anders zijn. En daar zit je dan met je .right voor een element dat gewoon in het midden moet staan op mobile.

Als je het niet zo in de html-source zet, heb ik niets gezegd.

[F.West98]

incaz schreef op vrijdag 01 mei 2015 @ 21:08:
[...]


Qua .block: ok, die trek ik terug.

.right is een lastigere, als je die class echt alleen maar toevoegt via javascript kan het. Ik heb om die reden ook een .hidden gemaakt. Maar rechtstreeks in de source gaat het vaak mis bij responsive design: een mobile browsersschermpje in portraitmode is smal en dus zet je daar vaak elementen onder elkaar ipv naast elkaar. Waar het op een breed scherm heel logisch kan zijn om iets naar rechts te schuiven (text-align of float) kan dat op mobile heel anders zijn. En daar zit je dan met je .right voor een element dat gewoon in het midden moet staan op mobile.

Als je het niet zo in de html-source zet, heb ik niets gezegd.

Mijn sitejes heb ik nooit responsive gemaakt, geen tijd voor gehad dus ik heb .left en .right wel direct in de source staan soms. Maar .hidden is weer zo'n voorbeeld wat voor de JS heel handig is.

[Voutloos]

Tja, dan heb je het gewoon niet helemaal begrepen...

Heb je dan ook classes .blue en .red, en pas je dan alle html aan als je een keertje een ander kleurenschema wil?

[EddoH]

Firesphere schreef op vrijdag 01 mei 2015 @ 20:51:
[...]


[...]

Wat Gamebuster dus zegt.
Het is leuk om te proberen, als het iets bruikbaars oplevert, gooi ik een blog online. Als het een complete faal oplevert, valt er natuurlijk weinig te bloggen.
En mocht het een totaal succes worden, dan draag ik weer een steentje bij aan de OS community.

Dingen doen om het doen, om het proberen, om te zien waar je terecht komt, dat vind ik persoonlijk het leukste. Leuker dan het uiteindelijke resultaat.

Oh zeker mee eens hoor! Het was niet bedoeld om je te ontmoedigen of je te laten opgeven met ontdekken.
Ik bedoelde dat drivers, vooral zonder documentatie en domeinspecifieke kennis nogal lastig kunnen zijn. Zonder een datasheet ben je bijna nergens. Mocht je die kunnen bemachtigen ben je al een stuk verder.

[Gamebuster]

Douweegbertje schreef op vrijdag 01 mei 2015 @ 18:13:
W3C. Het niet zo zwart-wit van 'daar is het niet voor bedoeld' maar een ID is in feite voor een uniek element, of visa-versa; door een id wordt het een uniek element. Wellicht heb je daar technisch gezien niets aan (of wel juist om juist één element specifiek te beheren) maar je wilt toch eigenlijk een best practise gebruiken? Of op zijn minst de dingen gebruiken die er voor gemaakt/bedoeld zijn.
Voor mij is het zowat het zelfde om ipv van de h1 tag maar een div.kop1 aan te maken om daar wat meuk in te zetten om de h1 te vervangen.. je gebruikt toch gewon de h1 terwijl het op 100 andere manieren kan.. waarom wel de h1 gebruiken conform de 'bedoeling' en een ID niet (en sterker nog, het gewoon afschrijven/afraden..)

Wat als ik om andere redenen een element 2x wil tonen in een document: In zeer zeldzame gevallen wil je een element kunnen klonen en op dezelfde plek tonen in de DOM. Denk aan drag 'n drop functionaliteit, waarbij het clonen van een DOM element niet mogelijk wordt gemaakt omdat iemand er een ID aan heeft gehangen.

Why de fuck wil je je footer drag 'n droppen? Misschien wel in een of andere futuristische CMS waarin je zelf je pagina in elkaar kan slepen.

Het is allemaal extreem obscuur gebied uiteraard, maar waarom wel IDs gebruiken in CSS? Wat kan je met een ID wel wat je met een classname niet kan? IDs zie ik als de singleton pattern: Gebruik alleen wanneer je er echt niet meer dan 1 van kan/mag/wil kunnen maken, niet wanneer je denkt dat je er toch maar 1 van nodig hebt.

Firesphere schreef op vrijdag 01 mei 2015 @ 20:51:
Het is leuk om te proberen, als het iets bruikbaars oplevert, gooi ik een blog online. Als het een complete faal oplevert, valt er natuurlijk weinig te bloggen.
En mocht het een totaal succes worden, dan draag ik weer een steentje bij aan de OS community.

Dingen doen om het doen, om het proberen, om te zien waar je terecht komt, dat vind ik persoonlijk het leukste. Leuker dan het uiteindelijke resultaat.

Falen kan je ook bloggen; dan documenteer je waarom het faalde en welke problemen je tegenkwam. Misschien gaan anderen wel helpen!

[ Voor 18% gewijzigd door Gamebuster op 01-05-2015 23:26 ]

[Douweegbertje]

Je hebt nu weer een voorbeeld en een functie waarbij je vooraf dus al bedenkt om dus classes te gebruiken..

[F.West98]

Voutloos schreef op vrijdag 01 mei 2015 @ 21:59:
Tja, dan heb je het gewoon niet helemaal begrepen...

Heb je dan ook classes .blue en .red, en pas je dan alle html aan als je een keertje een ander kleurenschema wil?

Nee juist niet. Ik heb juist .block om zo alles in één keer een ander kleurtje te geven. Dan hoef ik zelf niet bij alles wat er zo uit ziet (.header-nav, .article-info, .....) de kleur aan te passen.
Enkel de .left en de .right zijn cheaty hacks, voornamelijk voor JS, .hidden is primarily JS (in mijn laatste site heb ik dus een selector .right + *, om dan een clear te doen, maar dat kan natuurlijk ook anders). Verder niet van dat soort classes, behalve in specifieke gevallen, zoals .big.input-box. Ik kan ook wel .input-box en .input-box-big hebben, maar dat is wat ingewikkelder in JS, en .big.input-box (.big werkt dan ook enkel met .input-box, het heeft die functie enkel in deze context) is verder ook prima leesbaar.
Ik heb dus wel classes om een functie aan een element te geven, dus .collapsable-menu, .content-block, enz. Daar horen meerdere stijlen bij als padding, margin, kleuren, enz, en in het eerste geval ook stijlen voor nested elements.

[Robbiedobbie]

Ik heb die laptop nog voor geen dag, maar ik kan wel al zeggen: Wat een ding. Wow.

Lekker snel wanneer je het nodig hebt, lekker zuinig wanneer niet. Dun, niet te zwaar, goed geluid, een geweldig scherm...

* Robbiedobbie is helemaal blij

[Firesphere]

Gamebuster schreef op vrijdag 01 mei 2015 @ 23:24:
[...]

Falen kan je ook bloggen; dan documenteer je waarom het faalde en welke problemen je tegenkwam. Misschien gaan anderen wel helpen!

Onder "falen" versta ik "totaal onbruikbaar". Dus dan is't niets waard behalve 1 zinnetje "ik heb dit geprobeerd en het leverde niets op"

[Soultaker]

Robbiedobbie schreef op zaterdag 02 mei 2015 @ 12:45:
Ik heb die laptop nog voor geen dag, maar ik kan wel al zeggen: Wat een ding. Wow.

Welke is 't dan?

[Robbiedobbie]

Soultaker schreef op zaterdag 02 mei 2015 @ 16:07:
[...]

Welke is 't dan?

pricewatch: MSI GS60 2QE-230NL (Ghost Pro)

[Gamebuster]

Firesphere schreef op zaterdag 02 mei 2015 @ 14:22:
[...]

Onder "falen" versta ik "totaal onbruikbaar". Dus dan is't niets waard behalve 1 zinnetje "ik heb dit geprobeerd en het leverde niets op"

Ik ga je natuurlijk niet dwingen een blog te schrijven, dat is niet mijn intentie. Puur ter discussie echter: Je kan natuurlijk je werkwijze documenteren en schrijven wat er is fout gegaan en/of waarom.

[Gamebuster]

Zijn er hier happy gebruikers van SCons ipv Make(file)?

[Matis]

Gamebuster schreef op zaterdag 02 mei 2015 @ 20:31:
Zijn er hier happy gebruikers van SCons ipv Make(file)?

Ik gebruik alleen maar Makefile, geen wrappers of platform onafhankelijke applicaties (CMake etc)

[WernerL]

Ik kom zojuist deze xkcd tegen:




Vandaag weer bezig geweest met Scala. Week 3 van de reactive course ook weer afgerond.

[StM]

Ik moet bekennen me nogal eens schuldig te maken aan het in elkaar klussen van custom, totaal niet portable shell scripts om de boel te compilen Voor de rest alleen maar Makefiles. In het verleden wel SCons gebruikt, maar is de ontwikkeling er van weer opgepakt want ik dacht dat het redelijk outdated was?

[Firesphere]

Gamebuster schreef op zaterdag 02 mei 2015 @ 17:47:
[...]

Ik ga je natuurlijk niet dwingen een blog te schrijven, dat is niet mijn intentie. Puur ter discussie echter: Je kan natuurlijk je werkwijze documenteren en schrijven wat er is fout gegaan en/of waarom.

Hah, het dwingen moet ik nog zien

Maar als ik ook maar iets bruikbaars heb, ga ik er wel over schrijven ja. Ik heb voorlopig alleen m'n eigen rapportages, en die zeggen vooral "decompile onsuccesvol" of "decompile leverde vooral een hoop onbruikbare code op". Ik denk da'k eens een decompile in Windows ga draaien, eens zien wat dat oplevert

[StM]

Waar decompile je mee? Mijn ervaring is dat er maar 1 product is dat enigsinds bruikbaar is en dat is die van Hex Rays. Met bijbehorend prijskaartje

[Firesphere]

Ik heb disassembly en exetoc geprobeerd, tot nu toe. IDA ziet er interessant uit, maar ik hou't voor nu nog even bij open spul of free-to-try

Wel even een note, een decompile kan soms enkele dagen duren Maar dat kan ook aan mijn ervaring met decompilen liggen.

Mocht ik denken dat't echt de moeite waard is en ik er meer mee ga doen, dan is IDA een optie. Voor nu is het alleen maar trial-and-error, voor 1 specifieke kaart (een obscure/oude realtek die niet ondersteund is), daar ga ik geen 600 euro betalen

[StM]

De decompiler kost je nog een paar k extra Ik moet je alleen sterk teleurstellen met de gratis tools die er zijn. Hopper (ik weet niet of de Windows en Linux versie nog wordt onderhouden) produceert wel nog enigszins begrijpbare resultaten en die heeft een 30min demo. Maar dat is meer een soort pseudo C met inline high level assembly.

*edit* er was ook nog een webviewer die wel redelijke resultaten produceerde, maar volgens mij was dat een demo van een academisch project dat commercieel (wilde) gaan. Eens kijken of ik die nog kan vinden.

[ Voor 23% gewijzigd door StM op 02-05-2015 23:38 ]

[Firesphere]

Ach, ik ben maar aan't spelen met decompilers en hoop op een lucky shot Het is voor mij niet belangrijk.

Maar meer dan 2k ga ik (eventueel) niet uitgeven aan een decompiler. Ik wil eerst even een huisje kopen

[StM]

Goh, wat verbazingwekkend ;-)

Probeer deze eens: https://retdec.com/decompilation/

Geen idee of hij ook met drivers overweg kan, IDA en HR iig wel. Het helpt wel heel erg als je ook de bijbehorende pdb kan vinden.

[ Voor 13% gewijzigd door StM op 02-05-2015 23:43 ]

[Firesphere]

Ga ik van de week even proberen Ik ben nu te lam om iets nuttigs te doen. Dutch Craft Beer Festival hakt er in

[azerty]

IDA heeft trouwens een oudere gratis versie (met beperkingen)... Die al uitgeprobeerd?

[Firesphere]

Vandaag even met iets anders bezig. Database migraties

Dit is best een dure update

[F.West98]

Tijdens kloten met SSL en alles HSTS aangezet op de server via een handige plugin. Nu had deze geen optie om preload in de header toe te voegen, dus zelf even wat dingetjes gefrutseldmaakt en nu zit dat er in én heb ik wat bugs geplet
* F.West98 happy

[ Voor 8% gewijzigd door F.West98 op 04-05-2015 02:49 ]

[Hoogie2004]

Lekker rustig hier. Iedereen vrij, of is iedereen de ultieme pc voor 999 euro aan het samenstellen?

[Ryur]

Hoogie2004 schreef op maandag 04 mei 2015 @ 10:33:
Lekker rustig hier. Iedereen vrij, of is iedereen de ultieme pc voor 999 euro aan het samenstellen?

Hier druk aan het werk. Ben zo'n beetje als enige in support. Heel druk vandaag!

[EddoH]

F.West98 schreef op maandag 04 mei 2015 @ 02:48:
Tijdens kloten met SSL en alles HSTS aangezet op de server via een handige plugin. Nu had deze geen optie om preload in de header toe te voegen, dus zelf even wat dingetjes gefrutseldmaakt en nu zit dat er in én heb ik wat bugs geplet
* F.West98 happy

En wat nieuwe geintroduceerd?

code:

-   executable file("${System.env.WIX}bin\\candle.exe")
+   executable file("C:\\Program Files (x86)\\WiX Toolset v3.9\\bin\\candle.exe")

Ja ik verveel me.

[dev10]

Dat moment dat een tweet van je geretweet wordt door een account met meer dan 8 miljoen volgers. Binnen tien minuten 20 volgers erbij en m'n telefoon wordt leip van de favorites en retweets...

[TheNephilim]

EddoH schreef op maandag 04 mei 2015 @ 11:04:
[...]


En wat nieuwe geintroduceerd?

code:

-   executable file("${System.env.WIX}bin\\candle.exe")
+   executable file("C:\\Program Files (x86)\\WiX Toolset v3.9\\bin\\candle.exe")

Ja ik verveel me.

Haha, ik was ook nieuwsgierig en die viel mij ook op

[dcm360]

Hoogie2004 schreef op maandag 04 mei 2015 @ 10:33:
Lekker rustig hier. Iedereen vrij, of is iedereen de ultieme pc voor 999 euro aan het samenstellen?

Met een kort berekeningetje op een kladblaadje ben ik er al vlot achter dat het nogal krap is om met dat budget iets snellers dan mijn huidige pc in elkaar te klikken... Twee weken terug nog voor 400 euro enkel een moederbord, voeding en CPU aangeschaft omdat er iets daarvan defect was

[ZaZ]

dev10 schreef op maandag 04 mei 2015 @ 11:10:
Dat moment dat een tweet van je geretweet wordt door een account met meer dan 8 miljoen volgers. Binnen tien minuten 20 volgers erbij en m'n telefoon wordt leip van de favorites en retweets...

7 retweets. Ik zou maar een stoel pakken en het effe verwerken kerel

[kenneth]

Ik had ooit een heel flauwe tweet die werd geretweet door Fox (het filmbedrijf) en opeens had ik honderden retweets, m'n telefoon reageerde niet meer door honderden notifications en mentions binnen tien minuten

edit:

Tweet kan ik niet meer vinden, hij staat nog wel hierrr.

[ Voor 27% gewijzigd door kenneth op 04-05-2015 11:27 ]

[EddoH]

ZaZ schreef op maandag 04 mei 2015 @ 11:21:
[...]

7 retweets. Ik zou maar een stoel pakken en het effe verwerken kerel

[TheNephilim]

ZaZ schreef op maandag 04 mei 2015 @ 11:21:
[...]

7 retweets. Ik zou maar een stoel pakken en het effe verwerken kerel

Keurig

[Laurens-R]

Verplichte training aan het doen voor een klant... ik word altijd een beetje suf van de politiek correcte afbeeldingen van "zie ons eens even professioneel en divers zijn" die je echt overal ziet btw.. (maakt niet uit voor wie of waar je een training volgt)

[ Voor 20% gewijzigd door Laurens-R op 04-05-2015 11:38 ]

[CodeCaster]

Van die stockfoto's met zeven lachende mensen in pak, met headset op, in vijf huidtinten en drie verschillende geslachten, bedoel je?

[ Voor 18% gewijzigd door CodeCaster op 04-05-2015 11:43 ]

[Geerrrt]

CodeCaster schreef op maandag 04 mei 2015 @ 11:43:
Van die stockfoto's met zeven lachende mensen in pak, met headset op, in vijf huidtinten en drie verschillende geslachten, bedoel je?

Vergeet de kokerrok niet

[Laurens-R]

CodeCaster schreef op maandag 04 mei 2015 @ 11:43:
Van die stockfoto's met zeven lachende mensen in pak, met headset op, in vijf huidtinten en drie verschillende geslachten, bedoel je?

die ja....

en vergeet ook niet dat ze altijd bovengemiddeld knap zijn...

[.Gertjan.]

StM schreef op zaterdag 02 mei 2015 @ 23:42:
Goh, wat verbazingwekkend ;-)

Probeer deze eens: https://retdec.com/decompilation/

Geen idee of hij ook met drivers overweg kan, IDA en HR iig wel. Het helpt wel heel erg als je ook de bijbehorende pdb kan vinden.

Mooie manier om andermans code te verzamelen . Zou zelf niet zo snel een executable daar doorheen gooien, je weet nooit wat er aan de andere kant mee gebeurt...

[dev10]

ZaZ schreef op maandag 04 mei 2015 @ 11:21:
[...]

7 retweets. Ik zou maar een stoel pakken en het effe verwerken kerel

Dat was binnen tien minuten heh. Ik heb nooit zoveel reacties op m'n tweets, dus ik had echt zoiets van 'Wut?'

[Douweegbertje]

Daar lig ik nog niet zo wakker van.. wel toen ooit eens een site een link van mijn website plaatste waardoor ik per uur 10.000 hits moest gaan verwerken in plaats van 10.

[EddoH]

Afgerond 3 hits per seconde. Das niet zo spannend?

[OkkE]

Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

[ZaZ]

OkkE schreef op maandag 04 mei 2015 @ 13:32:
Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

Dus beide uitkomsten van de hash beginnen met een 0, dus zal wel waarde 0 zijn en 0 is gelijk aan 0 dus true?

[.oisyn]

OkkE schreef op maandag 04 mei 2015 @ 13:32:
Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

Uit de comments

PHP:

    $a = "2d9"; 
    $a++; 
    echo $a . "\n"; 
    $a++; 
    echo $a . "\n";

Hilarisch

[Laurens-R]

OkkE schreef op maandag 04 mei 2015 @ 13:32:
Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

Het is toch altijd tijd om PHP the bashen?

[Cloud]

OkkE schreef op maandag 04 mei 2015 @ 13:32:
Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

Holy cow Waarom verbaast het me eigenlijk nog?

.oisyn schreef op maandag 04 mei 2015 @ 13:44:
[...]


Uit de comments

PHP:

    $a = "2d9"; 
    $a++; 
    echo $a . "\n"; 
    $a++; 
    echo $a . "\n";

Hilarisch

Even voor de duidelijkheid de magische output erbij:
Output:

code:

2e0
3

[Douweegbertje]

EddoH schreef op maandag 04 mei 2015 @ 13:18:
Afgerond 3 hits per seconde. Das niet zo spannend?

Wel op een simpele VPS met een niet geweldig geoptimaliseerde website, waarbij er nog xx-aantal andere websites daarnaast draaien. Los van dat zou ik het niet redden qua dataverkeer als dat een x-aantal dagen zou doorgaan.
Uiteindelijk ging er ook niets down, wel iets trager.

[kenneth]

OkkE schreef op maandag 04 mei 2015 @ 13:32:
Is het al weer tijd om PHP te bashen? Ja? Mooi!

md5('240610708') == md5('QNKCDZO')

En weer minstens een persoon die zegt dat je maar de documentatie moet lezen

Ik draaide mijn stuur naar links maar de auto ging rechtsaf!
- Mja? Staat gewoon in de documentatie hoor.

[NMe]

.oisyn schreef op maandag 04 mei 2015 @ 13:44:
[...]


Uit de comments

PHP:

    $a = "2d9"; 
    $a++; 
    echo $a . "\n"; 
    $a++; 
    echo $a . "\n";

Hilarisch

* NMe kon bijna ijsthee van zijn scherm vegen. Hoe zit die eerste überhaupt? Dat 2e0 magisch omgezet wordt naar 2*10⁰ snap ik nog wel, maar hoe kom je in hemelsnaam van 2d9 naar 2e0?

kenneth schreef op maandag 04 mei 2015 @ 14:10:
[...]

En weer minstens een persoon die zegt dat je maar de documentatie moet lezen

Nouja, dat strings die beginnen met een getal naar dat getal evalueren is niks nieuws. Compleet onwenselijk gedrag in dit soort situaties maar het is geen nieuwe issue. Ik verbaas me vooral een beetje over een hoop commenters daar die niet begrijpen wat de onderliggende oorzaak is.

[ Voor 34% gewijzigd door NMe op 04-05-2015 14:14 ]

[Hipska]

Dat is hexadecimaal.. ow nee, bij nader inzien lijkt het meer een combinatie van hex en dec :-S

[NMe]

Hipska schreef op maandag 04 mei 2015 @ 14:14:
Dat is hexadecimaal.. ow nee, bij nader inzien lijkt het meer een combinatie van hex en dec :-S

Als het als een hexadecimale notatie gezien werd zou het 2da worden, niet 2e0.

[Hipska]

Eerste 2 digits hex en laatste digit decimaal lijkt het wel

[Aiolos]

Ook geen Hex, gewoon alfabetisch:

PHP:

$a = "n9";
   $a++;
   echo $a . "\n";
   $a++;
   echo $a . "\n";

resultaat:

code:

o0
o1

[.oisyn]

Dat is een feature die ze uit Perl hebben geleend. Staat ook gewoon gedocumenteerd.

Op zich leuk. Ware het niet dat die feature compleet incompatible is met het feit dat een getal gevolgd door de letter 'e' wordt geïnterpreteerd als exponent-notatie (en dat staat dan weer niet gedocumenteerd )

[ Voor 7% gewijzigd door .oisyn op 04-05-2015 14:28 ]

[kenneth]

Wauw, er wordt gehakt gemaakt van de review van de Surface 3. Zo fel heb ik het niet eerder gezien op t.net of lees ik gewoon te weinig reviews?

[_David_]

De felheid is er altijd bij reviews van microsoft producten, zie ook de reviews van de lumia's of die telefoon camera roundup.

[F.West98]

EddoH schreef op maandag 04 mei 2015 @ 11:04:
[...]


En wat nieuwe geintroduceerd?

code:

-   executable file("${System.env.WIX}bin\\candle.exe")
+   executable file("C:\\Program Files (x86)\\WiX Toolset v3.9\\bin\\candle.exe")

Ja ik verveel me.

Ja en die ook weer teruggedraaid hoor
https://github.com/FWest9...7d137e29aaa8cf7e82f1931c4

[.oisyn]

-> De Devschuur Coffee Corner - Iteratie ➒

[ Voor 79% gewijzigd door .oisyn op 05-05-2015 20:06 ]