Nightly builds van WebKit ondersteunen variabelen in css
De ontwikkelaars van WebKit hebben voor de laatste nightly builds code voorgesteld om css-variabelen te ondersteunen. Door het gebruik van variabelen moet css-code overzichtelijker worden en zou de kans op fouten verminderen.
De draft-specificatie van de W3C voor het toevoegen van variabelen aan css is nog niet goedgekeurd, waardoor WebKit genoodzaakt is zijn eigen prefix aan de nieuwe elementen toe te voegen, bijvoorbeeld @-webkit-variables. Desondanks kan er in de laatste nightly builds van de WebKit-engine geëxperimenteerd worden met het gebruik van variabelen in style sheets. Ook is een aantal testbestanden beschikbaar.
In de WebKit-implementatie kunnen variabelen in een css-bestand gedefinieerd worden. Via de functie var() kunnen de waardes uitgelezen worden, terwijl de css-variabelen ook via javascript zijn te benaderen door nieuwe functies.
Door de ondersteuning van variabelen in css kunnen waarden die vaak terugkeren, zoals font-instellingen of kleuren, aan een variabele gekoppeld worden, waarna deze waarden in declaraties gebruikt kunnen worden. Hierdoor moeten grote css-bestanden beter leesbaar worden, terwijl ook de kans op fouten wordt verkleind doordat de waarde van een variabele slechts eenmaal gewijzigd hoeft te worden.
Reacties (76)
Mooi, dit zal CSS een stuk overzichtelijker maken.
Niks moois aan, dit hoort niet thuis in CSS en het wordt niet ondersteund door andere browsers.
We gebruiken trouwens al langere tijd oplossingen als LESS.
Er is al jarenlang een discussie gaande over of variabelen wel in CSS horen. De algemene opinie is dat dat niet zo is, en het lijkt erop dat Google probeert dit toch te pushen door 't gewoon in de browser te zetten, om de standaard te forceren.
We gebruiken trouwens al langere tijd oplossingen als LESS.
Er is al jarenlang een discussie gaande over of variabelen wel in CSS horen. De algemene opinie is dat dat niet zo is, en het lijkt erop dat Google probeert dit toch te pushen door 't gewoon in de browser te zetten, om de standaard te forceren.
Binnen 10 jaar zijn we vergeten dat css geen variabelen had. En nu browsers iets regelmatiger geupdate worden, vind ik het wel kunnen dat er variabelen in css komen.
Al is dit idd niet zo vanzelfsprekend voor mensen die css al onder de knie hebben om nu te zeggen dat css weeral aan het veranderen is.
Al is dit idd niet zo vanzelfsprekend voor mensen die css al onder de knie hebben om nu te zeggen dat css weeral aan het veranderen is.
Het probleem zit niet zo zeer in de variabelen maar in de vervolgstappen. Variabelen zijn ongetwijfeld heel erg handig, maar je kan er zo weinig mee - nu kan je bijv. alleen maar een kleurtje makkelijk eventjes als variabele zetten. Om er ook echt veel mee te kunnen heb je dingen als + en - nodig. Stapje verder en je krijgt methoden om kleuren te bewerken. Dan komen er later ook nog eens functies bij. Al deze veranderingen zijn niet backwards compatible (normale CSS-wijzigingen wel), en op een bepaald moment krijg je gewoon een complete programmeertaal in CSS.
En dàt is waarom LESS zo goed is: het kan gewoon geprocessed worden op de server, waardoor het altijd gewoon weer CSS wordt. Het klopt dat het een programmeertaal is, maar het hoeft niet backwards compatible te zijn omdat het op de server zelf draait.
Een ander argument is trouwens dat variabelen helemaal niks toevoegen aan de clientside-kant en alleen maar handig zijn voor de developers. Waarom dan moeilijk doen en ze ook niet gewoon aan de kant van de developers interpreteren?
En dàt is waarom LESS zo goed is: het kan gewoon geprocessed worden op de server, waardoor het altijd gewoon weer CSS wordt. Het klopt dat het een programmeertaal is, maar het hoeft niet backwards compatible te zijn omdat het op de server zelf draait.
Een ander argument is trouwens dat variabelen helemaal niks toevoegen aan de clientside-kant en alleen maar handig zijn voor de developers. Waarom dan moeilijk doen en ze ook niet gewoon aan de kant van de developers interpreteren?
[Reactie gewijzigd door TvdW op donderdag 14 juni 2012 15:27]
Natuurlijk blijven tools zoals LESS nuttig zelfs wanneer css variabelen ondersteund. Zulke tools kunnen namelijk heel wat optimalisaties doen zodat browsers het niet moeten doen.
Ik zou zelfs zeggen dat deze tools even nuttig zouden zijn moest css ongeveer hetzelfde kunnen aanbieden. Er zullen dan wel minder mensen naar deze tool grijpen, omdat je dan enkel de css moet wijzigen zonder dat je aan de tools hoeft te prutsen.
Ik zou zelfs zeggen dat deze tools even nuttig zouden zijn moest css ongeveer hetzelfde kunnen aanbieden. Er zullen dan wel minder mensen naar deze tool grijpen, omdat je dan enkel de css moet wijzigen zonder dat je aan de tools hoeft te prutsen.
[Reactie gewijzigd door avdg-BE op donderdag 14 juni 2012 15:31]
Niet alleen plus en min, ook een assignment; op dit moment doet het me veel meer denken aan "constanten" dan aan "variabelen".Variabelen zijn ongetwijfeld heel erg handig, maar je kan er zo weinig mee - nu kan je bijv. alleen maar een kleurtje makkelijk eventjes als variabele zetten. Om er ook echt veel mee te kunnen heb je dingen als + en - nodig.
Inderdaad, Constanten was ook mijn gedachte.
Constanten ben ik voor, variabelen tegen; CSS is een opmaakbeschrijving en het argument om dit te gebruiken is altijd het scheiden van code en opmaak geweest. Moet je niet ineens CSS gaan codificeren.
Constanten ben ik voor, variabelen tegen; CSS is een opmaakbeschrijving en het argument om dit te gebruiken is altijd het scheiden van code en opmaak geweest. Moet je niet ineens CSS gaan codificeren.
Jij denkt zeker ook dat iemand die wiet rookt binnen no time aan de harddrugs zit oid, want dat is de logische vervolgstap toch?
Beetje raar om te denken dat het meteen verder en verder moet gaan...
BTW wat is er zo speciaal een LESS, bovenstaande code (uit het artikel) is binnen 10 regels PHP om te vormen naar valide CSS, wat doet LESS voor speciaals dan allemaal...
Beetje raar om te denken dat het meteen verder en verder moet gaan...
BTW wat is er zo speciaal een LESS, bovenstaande code (uit het artikel) is binnen 10 regels PHP om te vormen naar valide CSS, wat doet LESS voor speciaals dan allemaal...
[Reactie gewijzigd door watercoolertje op donderdag 14 juni 2012 15:42]
LESS is nog veel meer dan dit voorbeeld, zie: http://lesscss.org/
Mmm, als ik LESS bekijk is het eerste wat me opvalt, dat alles langer is wat code betreft en ik kan me voorstellen als je veel code hebt staan dat je de draad kwijtraakt wat variabelen betreft bij het ontwerpen van een site.
Bij alleen css komt duidelijk naar voren in de voorbeelden, dat je elke keer duidelijk kunt zien wat de instellingen zijn.
LESS is dus duidelijk voor een programmeur bedacht en niet voor een ontwerper, of het zo zinvol is dan vraag ik mij af.
Bij alleen css komt duidelijk naar voren in de voorbeelden, dat je elke keer duidelijk kunt zien wat de instellingen zijn.
LESS is dus duidelijk voor een programmeur bedacht en niet voor een ontwerper, of het zo zinvol is dan vraag ik mij af.
Als ik PHP/JSP code tussen mijn css code zet om bijvoorbeeld kleuren uit een database te halen flipt de CSS validatie van mijn IDE. En die validatie vind ik fijn omdat ik niet vaak CSS edit. Maar je kan ook gewoon met JavaScript dynamische CSS rules toevoegen nadat de pagina is geladen.
Maar waarom moet je daar dan weer een nieuw taaltje voor uitvinden? Je kunt toch ook gewoon php of van mijn part javascript code schrijven die css uitpoept? Dan kun je het zo geavanceerd maken als je zelf wil.
Idd, doen wij ook. Kan je het ook meteen strippen van dubbele spaties en enters. Ik heb echt helemaal niks met dat Less.
En deze support is leuk, maar ik denk dat iedereen zijn eigen workaround al heeft gevonden ervoor.
En deze support is leuk, maar ik denk dat iedereen zijn eigen workaround al heeft gevonden ervoor.
behalve dan dat die php code of js code die CSS uit poept hoogst waarschijnlijk kut is om te onderhouden. LESS werkt gewoon goed, is schoner, makkelijker te debuggen ect. En het word onderhouden door een 3rd party die er langer aan kan werken dan jij aan je eigen css generator zou kunnen werken.
Als je CSS genereerd verlies je:
- de mogelijkheid om direct vanuit de ontwikkel/debug-tools zoals Firebug te zien op precies welke regel iets foet is of aangepast moet worden
- de mogelijkheid om live CSS properties (zoals de variable) te veranderen om te zien wat het effect op de pagina is
Mij lijkt het handig om CSS variabelen te hebben, helemaal in het geval van sites die per sectie themakleuren willen hebben. In plaats van hele lappen CSS te kopieren en aanpassen per thema of gegenereerde CSS te gebruiken kan je dan op basis van een class op de body of door een thema-specifieke CSS file in te laden kleurenthema's implementeren. De normale CSS file kan dan specificeren of je b.v. een donkere, lichte, border, tekst of header kleur nodig hebt en de daarnaast ingeladen kleurthema CSS specificeerd de benodigde kleuren hiervoor.
CSS calculaties zitten overigens al in Firefox vanaf versie 4 met prefix:
https://developer.mozilla.org/en/CSS/-moz-calc
http://hacks.mozilla.org/2010/06/css3-calc/
Ik zie zie zelfs niet direct veel toegevoegde waarde in LESS, alhoewel het zo te zien leuke speeltjes heeft. Ik vermoed wel dat mijn baas gek ervan zou worden omdat hij met alle variabelen, kleurberekeninging, when's er niet meer uit zou komen waar nou welke instelling vandaan komt
Dan moet er een 'echte' programmeur aan te pas komen om een stylesheet aan te passen.
- de mogelijkheid om direct vanuit de ontwikkel/debug-tools zoals Firebug te zien op precies welke regel iets foet is of aangepast moet worden
- de mogelijkheid om live CSS properties (zoals de variable) te veranderen om te zien wat het effect op de pagina is
Mij lijkt het handig om CSS variabelen te hebben, helemaal in het geval van sites die per sectie themakleuren willen hebben. In plaats van hele lappen CSS te kopieren en aanpassen per thema of gegenereerde CSS te gebruiken kan je dan op basis van een class op de body of door een thema-specifieke CSS file in te laden kleurenthema's implementeren. De normale CSS file kan dan specificeren of je b.v. een donkere, lichte, border, tekst of header kleur nodig hebt en de daarnaast ingeladen kleurthema CSS specificeerd de benodigde kleuren hiervoor.
CSS calculaties zitten overigens al in Firefox vanaf versie 4 met prefix:
https://developer.mozilla.org/en/CSS/-moz-calc
http://hacks.mozilla.org/2010/06/css3-calc/
Ik zie zie zelfs niet direct veel toegevoegde waarde in LESS, alhoewel het zo te zien leuke speeltjes heeft. Ik vermoed wel dat mijn baas gek ervan zou worden omdat hij met alle variabelen, kleurberekeninging, when's er niet meer uit zou komen waar nou welke instelling vandaan komt
Dan moet er een 'echte' programmeur aan te pas komen om een stylesheet aan te passen.
Het hoort niet in CSS thuis, maar ondertussen wel oplossingen als LESS gebruiken wat eigenlijk op het zelfde neer komt 
Het hele idee van CSS was toch dat designers het gemakkelijk konden aanpassen? Als het nu een programmeertaal gaat worden, dan haken de designers af denk ik 
Maar anyway, wat ik handig vind aan LESS is dat je een soort van classes kunt maken, waardoor je in 1 keer een hele set rules kan kopieren. Hopelijk komt zoiets ook in de standaard dan.
Maar anyway, wat ik handig vind aan LESS is dat je een soort van classes kunt maken, waardoor je in 1 keer een hele set rules kan kopieren. Hopelijk komt zoiets ook in de standaard dan.
Het is een programmeertaal omdat er variabel-substitutie inzit, waardoor het voor de designers makkelijker wordt om iets aan te passen omdat je nu nog maar op 1 plek de kleur hoeft aan te passen ipv op 300 verschillende plekken? 
En als designers dan zo bang zijn voor variabelen, waarom maken er dan zoveel gebruik van LESS en SASS?
En als designers dan zo bang zijn voor variabelen, waarom maken er dan zoveel gebruik van LESS en SASS?
[Reactie gewijzigd door .oisyn op donderdag 14 juni 2012 15:21]
%s/fff/f4abc8/g ?omdat je nu nog maar op 1 plek de kleur hoeft aan te passen ipv op 300 verschillende plekken?
Voor de ontwerpers onder ons?
CSS is al veel langer te ingewikkeld voor iemand die slecht abstract kan denken. En het concept van een variabele is nou niet echt rocket science maar iets dat je met elke wiskunde/natuurkunde les krijgt.
Variabelen in css is een welkome toevoeging imo
Variabelen in css is een welkome toevoeging imo
helaas lopen veel mensen te zwoegen met wiskunde/natuurkunde.
ik vind het zelf ook vreemd maar het is wel de realiteit.
en in het voorbeeld is de toepassing als variabele niet echt terecht. een constant zou beter zijn geweest.
ik vind het zelf ook vreemd maar het is wel de realiteit.
en in het voorbeeld is de toepassing als variabele niet echt terecht. een constant zou beter zijn geweest.
Het hele idee van CSS is op markup en layout te scheiden van elkaar, niet om een soort "domme-mensensysteem" te hebben dat zelfs leken kunnen gebruiken. Die groep is trouwens blijven hangen in tables, en hebben geen degelijke notie van CSS.
Houdt je browser zich aan de standaard en houdt je website zich aan de standaard dan is er niets aan de hand.
Ja maar de standaard is zo ingewikkeld dat er een grote kans is dat je programma/site niet in 1 keer werkt op die browser, laat staan op alle browsers die de standaard "ondersteunen".
Als ze het web wat slimmer in elkaar hadden gezet, hadden ze die kans veel kleiner kunnen maken.
Nu lijkt het wel alsof we wat betrouwbaarheid betreft terug zijn in de prehistorie.
Als ze het web wat slimmer in elkaar hadden gezet, hadden ze die kans veel kleiner kunnen maken.
Nu lijkt het wel alsof we wat betrouwbaarheid betreft terug zijn in de prehistorie.
Ik weet niet hoe dat bij jou werkt maar hier zijn designers vooral aan het designen en zijn het frontenders die het bouwen. Bovendien ben je niet ineens verplicht om variabelen te gebruiken, het is optioneel.
Ik vind het aardig krom. Dat die dingen niet in css hoort vind ik echt onzin. Standaarden moeten veranderen, dat je tools zoals SASS en LESS nodig hebt is naar mijn mening gewoon om de kromme dingen heen programmeren.
Ik gebruik zelf SASS met HAML en vind het echt geweldig, maar zoiets als variabelen moet echt wel native in CSS vind ik.
Ik gebruik zelf SASS met HAML en vind het echt geweldig, maar zoiets als variabelen moet echt wel native in CSS vind ik.
Het gebruik van variablen is heus niet verplicht hoor, de oude code zoals we nu hebben werkt dus ook gewoonHet hele idee van CSS was toch dat designers het gemakkelijk konden aanpassen? Als het nu een programmeertaal gaat worden, dan haken de designers af denk ik
[Reactie gewijzigd door watercoolertje op donderdag 14 juni 2012 15:44]
Met variabelen (constanten) wordt het nog niet gelijk een programmeertaal. Daarbij komt dat het een designer vrij staat om het niet te gebruiken, mocht hij/zij dat niet wilen.
Met dat argument kun je eigenlijk iedere ontwikkeling stop zetten. Het is er niet, dus het hoort niet.
Je bedoelt dat er niets mooi is aan de huidige CSS spec, waardoor je je moet vergrijpen aan dit soort extensies of opties zoals LESS om dingen mooi, duidelijk en maintainable op te zetten?Niks moois aan, dit hoort niet thuis in CSS en het wordt niet ondersteund door andere browsers.
Sorry maar ik hecht niet zoveel waarde aan of iets algemene opinie is. Ik hoor liever argumenten. Het feit dat er vraag is naar iets zoals LESS spreekt daarentegen boekdelen.De algemene opinie is dat dat niet zo is
[Reactie gewijzigd door .oisyn op donderdag 14 juni 2012 15:16]
+1 voor deze reactie. Opties zoals LESS of SASS zouden niet zo heel erg nodig moeten zijn. CSS mag best wel iets meer van deze tijd worden.
Heb je daar een bron van wat de "algemene opinie" is ? Aan de de populariteit te zien van LESS/SASS zou ik veel eerder het omgekeerde denken. En lapmiddelen - wat LESS is - zijn in wezen nooit echt goed.Niks moois aan, dit hoort niet thuis in CSS... . De algemene opinie is
Mijn opinie is dat ik al jaren met het idee loop dat variabelen een groot gemis is in CSS, zeker als ik - voor less - voor de tiende keer bepaalde zaken op x aantal plaatsen moest gaan aanpassen.
Ik verwacht dat de niet IE browsers dit snel zullen implementeren hoor. Maakt zaken zoals LESS/SASS overbodig. En m.b.t. IE zal er wel weer een polyfill oplossing bestaan of kun je een faillback implementeren tot zolang MS het in de volgende iteratie zal ondersteunen.en het wordt niet ondersteund door andere browsers.
[Reactie gewijzigd door simplicidad op donderdag 14 juni 2012 15:40]
Ik snap niet wat het probleem is om dit te pushen, variabelen zijn al lang een gemiste functionaliteit in css... Een kleur op 200 verschillende plaatsen aanpassen is volgens mij minder gebruiksvriendelijk.
En LESS is gewoon een mogelijkheid om variabelen te implementeren, maar het er wel beter gewoon vanaf de eerste x inzitten (toch volgens mij)
En LESS is gewoon een mogelijkheid om variabelen te implementeren, maar het er wel beter gewoon vanaf de eerste x inzitten (toch volgens mij)
Webkit is niet van Google, maar ooit door Apple geforked van KHTML.De algemene opinie is dat dat niet zo is, en het lijkt erop dat Google probeert dit toch te pushen door 't gewoon in de browser te zetten, om de standaard te forceren.
En het wordt nu ontwikkeld door onder andere (uit mijn hoofd):
- Apple
- Nokia
- Google
- KDE
Blijkbaar is mijn geheugen goed:
http://trac.webkit.org/wi...contributed%20to%20WebKit
- Apple
- Nokia
- KDE
Blijkbaar is mijn geheugen goed:
http://trac.webkit.org/wi...contributed%20to%20WebKit
CSS is een opmaak taal. Nu wordt het een completere taal. Ik zie geen probleem. Overigens zouden ook complexe dingen zoals die ook in LESS zitten van mij best mogen.
Ben ik het totaal niet mee eens. Variabelen zijn een groot gebrek in CSS. Met variabelen kun je immers nu makkelijk op 1 plek je kleuren instellen die in de classes gebruikt worden. Nu staat dat hardcoded in de classes wat gewoon slordig is.
Off-topic: Zover ik weet is WebKit niet van Google maar van Apple.
On-topic: Ik zie zelf de meerwaarde niet echt van variables in CSS aangezien je niet echt vaak (altans ik) de zelfde waardes gebruikt. Ik probeer vaak te zorgen dat een inherit goed genoeg is.
On-topic: Ik zie zelf de meerwaarde niet echt van variables in CSS aangezien je niet echt vaak (altans ik) de zelfde waardes gebruikt. Ik probeer vaak te zorgen dat een inherit goed genoeg is.
Hehe ik wilde al bijna schuimbekkend reageren hierop.
Snapte wel WAAROM je vind dat variabellen niet in css thuishoren, maar niet dat het je het vervolgens met clientside javascript (nog meer?) oplost.
Na iets verder te lezen op LESS pagina dan mijn neus lang is, kom ik tot de ontdekking dat er een toolset bij hoort waarmee je LESS om kan zetten naar CSS.
In die vorm is dit best een elegante oplossingen; Geen variabellen in je compiled CSS, wel de voordelen van variabellen in LESS.
Snapte wel WAAROM je vind dat variabellen niet in css thuishoren, maar niet dat het je het vervolgens met clientside javascript (nog meer?) oplost.
Na iets verder te lezen op LESS pagina dan mijn neus lang is, kom ik tot de ontdekking dat er een toolset bij hoort waarmee je LESS om kan zetten naar CSS.
In die vorm is dit best een elegante oplossingen; Geen variabellen in je compiled CSS, wel de voordelen van variabellen in LESS.
Dit zou veel 'engines' als SASS overbodig kunnen maken, natuurlijk zorgen deze vaak ook voor een snellere manier van css'en maar voor mij was de voornaamste reden (in dit geval in Ruby On Rails) toch wel het gebruik van variabelen zodat ik makkelijker thema's kon aanpassen @textcolor, @backgroundcolor etc etc kwam toch rete handig uit
Voorlopig is het hier voor slimmer een CSS-preprocessor te gebruiken;
SASS, LESS of Stylus... voordeel daarvan is toch ook dat het backwards compatible blijft werken.
SASS, LESS of Stylus... voordeel daarvan is toch ook dat het backwards compatible blijft werken.
Je hebt gelijk wat backwards compatibility betreft, maar wat zou het toch ontzettend fijn zijn als we hier mee gewoon direct vooruit konden... Vrij logische stap dit voor CSS zou ik zeggen, meer dan welkom.
Je bent mij net voor.LESS Blijft inderdaad een geweldig hulpmiddel!
Ik zie de voordelen wel van het gebruik van variabelen in CSS, maar maakt dit het niet onnodig complex en gezien de lengte van een hoop CSS bestanden, onleesbaar? Ook weer het probleem van dat sommige browsers het wel en andere weer niet (dan wel anders) ondersteunen, moet je de boel weer redundant maken waardoor de plus punten niet naar voren komen en je het dus beter niet kan gebruiken...
Ach ja, en zo wordt CSS vanzelf een scripting taal op zichzelf.
in 1996, nog voor de publicatie van de CSS-1 recommendation heeft netscape ook 'Javascript Stylesheets' ontwikkeld en W3C voorgesteld: JSSS..
effectief was het zelfs zo dat de visuele weergave van CSS in Netscape Navigator 4 gebaseerd was op JSSS, CSS-declaraties werden intern omgevormd tot JSSS (helaas ook de oorzaak van behoorlijke vee bugs én problemen metd e dynamische weergave van CSS-Styles binnen DHTML-toepassingen, dus HTML-layers welke dynamisch veranderden)...
Hét probleem is natuurlijk dat zoiets een extra belasting kan leggen op een visuele engine, er veel meer states én mogelijk inline berekeningen bijgehouden moeten worden voor, tijdens en na het renderen van een pagina.
effectief was het zelfs zo dat de visuele weergave van CSS in Netscape Navigator 4 gebaseerd was op JSSS, CSS-declaraties werden intern omgevormd tot JSSS (helaas ook de oorzaak van behoorlijke vee bugs én problemen metd e dynamische weergave van CSS-Styles binnen DHTML-toepassingen, dus HTML-layers welke dynamisch veranderden)...
Hét probleem is natuurlijk dat zoiets een extra belasting kan leggen op een visuele engine, er veel meer states én mogelijk inline berekeningen bijgehouden moeten worden voor, tijdens en na het renderen van een pagina.
[Reactie gewijzigd door RM-rf op donderdag 14 juni 2012 15:27]
Als je het concept van variabelen niet snapt (blijkbaar), heb je ook niet het recht om iets af te doen als scripttaal want dan heb je het dus gewoon niet begrepen. Iets declareren is iets anders dan iets uitvoeren. Laat dat laatste nou vooral het idee achter een programma (en dus script) zijn.
Dat weet ik ook wel, maar het is de eerste stap op weg naar het vervullen van Zawinski's Law. Let maar op, over 20 jaar kunnen we een emailclient in CSS schrijven. 
[Reactie gewijzigd door Dreamvoid op donderdag 14 juni 2012 15:42]
Aah, met de volgende iTunes kunnen we waarschijnlijk mailen, ideaal!
Maar inderdaad, het moet niet te bloated worden. Voor workarounds waren CSS behaviours handig in IE. Maar ergens moet natuurlijk wel een duidelijke scheiding tussen functionaliteit en opmaak blijven IMHO.
Maar inderdaad, het moet niet te bloated worden. Voor workarounds waren CSS behaviours handig in IE. Maar ergens moet natuurlijk wel een duidelijke scheiding tussen functionaliteit en opmaak blijven IMHO.
Iets declareren is dan weer niet perse een variabele voor nodig. Een constante voldoet daartoe ook.
En constantes hebben (imho) minder risico om uit te groeien tot scripting engines als variabelen.
Een variabele is namelijk over het algemeen variabel. Wat moet een browser doen als ik halverwege een css een variabele herdefinieer?
En constantes hebben (imho) minder risico om uit te groeien tot scripting engines als variabelen.
Een variabele is namelijk over het algemeen variabel. Wat moet een browser doen als ik halverwege een css een variabele herdefinieer?
Dat is ook precies waar het hier over gaat, alleen noemt iedereen het variabelenIets declareren is dan weer niet perse een variabele voor nodig. Een constante voldoet daartoe ook.
[Reactie gewijzigd door .oisyn op zaterdag 16 juni 2012 01:03]
Zou het hiermee mogelijk zijn om css-waarden te binden aan waarden van andere elementen?
Zou wel mooi zijn dan moet er niet telkens met javascript geklooid worden.
Zou wel mooi zijn
dan moet er niet telkens met javascript geklooid worden.
Als ik lees wat jij geschreven hebt zou ik zeggen gebruik een komma en zet er een tweede selector neer. Maar je bedoelt waarschijnlijk iets anders.
Heb zelf eigen niet meer nodig dan het opslaan van bijvoorbeeld een kleur zodat deze later weer op meerdere plekken gebruikt kan worden. Bijvoorbeeld op de achtergrondskleur van een th gelijk te maken aan de border color van een td.
Heb zelf eigen niet meer nodig dan het opslaan van bijvoorbeeld een kleur zodat deze later weer op meerdere plekken gebruikt kan worden. Bijvoorbeeld op de achtergrondskleur van een th gelijk te maken aan de border color van een td.
Buiten LESS & SASS e.d. om, zou dit een mooie oplossing kunnen bieden.
Fonts en gebruikte (huisstijl-)kleuren eenmalig in een var zetten, en whoppa.
Fonts en gebruikte (huisstijl-)kleuren eenmalig in een var zetten, en whoppa.
CSS Variables zijn door de CSS werkgroep aangenomen, hier is dus weinig Google-specifiek aan, behalve dat het de eerste implementatie is. Andere browsers zullen vanzelf volgen.
Ik weet niet waar de tekst uit het nieuwsbericht zelf vandaan komt (waarschijnlijk van eerdere discussies), maar dit is niet wat er in WebKit geïmplementeerd is, noch wat er door de CSS werkgroep gestandardiseerd wordt. De syntax uit het huidige voorstel, waar verschillende browsers en groepen het redelijk over eens zijn, is namelijk als volgt:
Dit houdt tevens in dat de functie *uit* staat - het is voor Web ontwikkelaars nog niet mogelijk om ze te gebruiken. Totdat een andere browser vendors ook ondersteuning heeft toegevoegd zal dit zo blijven. Mensen die toch interesse hebben in het gebruik van CSS Variables, bijvoorbeeld om te kijken hoe toepasbaar het is voor eigen projecten, zitten nu nog vast aan een eigen WebKit build maken. Totdat er een run-time flag in Chrome beschikbaar wordt.
Verder is het ook noemswaardig dat de hoofdontwikkelaar van SASS actief heeft meegeholpen aan het ontwerp van de feature. Qua compatibility zal het nog een tijd duren voordat het algemeen ondersteund wordt, maar het moet natuurlijk ergens beginnen. Tevens wordt er nog nagedacht over mogelijkheden om variables aan de DOM beschikbaar te stellen, zodat je via JavaScript bijvoorbeeld waardes kunt opvragen of veranderen.
Ik weet niet waar de tekst uit het nieuwsbericht zelf vandaan komt (waarschijnlijk van eerdere discussies), maar dit is niet wat er in WebKit geïmplementeerd is, noch wat er door de CSS werkgroep gestandardiseerd wordt. De syntax uit het huidige voorstel, waar verschillende browsers en groepen het redelijk over eens zijn, is namelijk als volgt:
Hiernaast is ook de var() functie nog beschikbaar, maar deze heeft met name de mogelijkheid om standaardwaardes mee te geven indien de variable niet gevonden kan worden. WebKit wijkt hier op dit moment nog vanaf omdat de "$" prefix nog niet geimplementeerd is, en de var() functie daardoor verplicht gebruikt moet worden. De implementatie wordt echter via een iteratie-principe gedaan, wat inhoudt dat de functie nog volledig in ontwikkeling is.:root {
var-text-color: red;
var-border-color: blue;
}
section {
color: $text-color;
border: 1px solid $border-color;
}
Dit houdt tevens in dat de functie *uit* staat - het is voor Web ontwikkelaars nog niet mogelijk om ze te gebruiken. Totdat een andere browser vendors ook ondersteuning heeft toegevoegd zal dit zo blijven. Mensen die toch interesse hebben in het gebruik van CSS Variables, bijvoorbeeld om te kijken hoe toepasbaar het is voor eigen projecten, zitten nu nog vast aan een eigen WebKit build maken. Totdat er een run-time flag in Chrome beschikbaar wordt.
Verder is het ook noemswaardig dat de hoofdontwikkelaar van SASS actief heeft meegeholpen aan het ontwerp van de feature. Qua compatibility zal het nog een tijd duren voordat het algemeen ondersteund wordt, maar het moet natuurlijk ergens beginnen. Tevens wordt er nog nagedacht over mogelijkheden om variables aan de DOM beschikbaar te stellen, zodat je via JavaScript bijvoorbeeld waardes kunt opvragen of veranderen.
Eindelijk het zou eens tijd worden zeg, de W3C zou wat mij betreft wel iets sneller mogen werken aan het verbeteren van CSS aan de andere kant de meeste browser bouwer (en zeker Microsoft) kunnen ze nu al amper bijhouden. Maar dit is wel een goede ontwikkeling want het is af en toe zeker bij grotere pagina's nauwelijks te volgen welke kleuren waar en waarom gezet worden en zo...
Het W3C kan helaas niet sneller omdat dit door diezelfde browserbouwers ontwikkeld/onderhandeld wordt.
Wat mij betreft hadden we in 10 jaar al op een veel hoger niveau kunnen staan, ik bedoel: Waarom moet ik een datepicker met Javascript maken? Waarom ondersteund een browser niet out-of-the-box een multi-upload feature (ipv met een swf op de achtergrond te werken)?
Al die zaken zitten standaard al ingebakken in de SDK's van notabene complete besturingssystemen (Android, iOS) die slechts enkele jaartjes bestaan.
Dus ja, ze zijn traag maar kunnen er eigenlijk niks aan doen omdat iedere partij haar eigen belangen heeft. Andere kant van het verhaal is dan Flash, dat is wel geavanceerd maar je bent wel afhankelijk van Adobe voor de performance ervan. Overigens heb ik wel een lichte voorkeur voor Actionscript: één taal voor alles en vector-based.
Wat mij betreft hadden we in 10 jaar al op een veel hoger niveau kunnen staan, ik bedoel: Waarom moet ik een datepicker met Javascript maken? Waarom ondersteund een browser niet out-of-the-box een multi-upload feature (ipv met een swf op de achtergrond te werken)?
Al die zaken zitten standaard al ingebakken in de SDK's van notabene complete besturingssystemen (Android, iOS) die slechts enkele jaartjes bestaan.
Dus ja, ze zijn traag maar kunnen er eigenlijk niks aan doen omdat iedere partij haar eigen belangen heeft. Andere kant van het verhaal is dan Flash, dat is wel geavanceerd maar je bent wel afhankelijk van Adobe voor de performance ervan. Overigens heb ik wel een lichte voorkeur voor Actionscript: één taal voor alles en vector-based.
[Reactie gewijzigd door poepkop op donderdag 14 juni 2012 21:52]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
