Chromium heeft onlangs een nieuwe functie van HTML5 geïmplementeerd: scoped stylesheets, oftewel. <style scoped> . Een webauteur kan stijlregels beperken zodat deze alleen op een deel van een pagina worden toegepast door het kenmerk 'scoped' in te stellen op een <style> -element dat het directe kind is van het hoofdelement van de subboom waarop u de stijlen wilt toepassen. Hierdoor worden de stijlen beperkt tot alleen het element dat het bovenliggende element is van het <style> -element en al zijn nakomelingen.
Voorbeeld
Hier is een eenvoudig document met standaardstijlen:
<html>
<body>
<div>a div! <span>a span!</span></div>
<div>
<style>
div { color: red; }
span { color: green; }
</style>
a div! <span>a span!</span></div>
<div>a div! <span>a span!</span></div>
</body>
</html>
De opgegeven stijlregels kleuren tekst binnen elk <div> rood en binnen elk <span> groen:
een div! een spanwijdte!
een div! een spanwijdte!
een div! een spanwijdte!
Als we echter scoped instellen op het <style> element:
<html>
<body>
<div>a div! <span>a span!</span></div>
<div>
<style scoped>
div { color: red; }
span { color: green; }
</style>
a div! <span>a span!</span></div>
<div>a div! <span>a span!</span></div>
</body>
</html>
vervolgens beperkt het de stijlregels zodat ze worden toegepast op de omsluitende <div> die de ouder is van het <style scoped> element en alles binnen dat <div> . We noemen dit 'scoped' en het resultaat ziet er als volgt uit:
een div! een spanwijdte!
een div! een spanwijdte!
een div! een spanwijdte!
Dit kan uiteraard overal in de opmaak worden gedaan. Dus als u avontuurlijk bent ingesteld, kunt u stijlen met bereik in andere delen van de markup nestelen, zo vaak als u wilt, om een nauwkeurige controle te krijgen over waar stijlen worden toegepast.
Gebruiksgevallen
Waar is dit nu goed voor?
Een veelvoorkomend gebruiksscenario is gesyndiceerde inhoud: wanneer u als webauteur inhoud van een derde partij wilt opnemen, inclusief alle bijbehorende stijlen, maar niet het risico wilt lopen dat die stijlen andere, niet-gerelateerde delen van de pagina ‘vervuilen’. Een groot voordeel hier is de mogelijkheid om inhoud van andere sites zoals yelp, twitter, ebay, etc. te combineren in één enkele pagina zonder deze te hoeven isoleren met behulp van een <iframe> of om de externe inhoud on-the-fly te bewerken.
Als u een contentmanagementsysteem (CMS) gebruikt dat u fragmenten van opmaak stuurt die allemaal samengevoegd worden tot een uiteindelijke paginaweergave, dan is dit een geweldige functie om ervoor te zorgen dat elk fragment afzonderlijk van de rest op de pagina wordt opgemaakt. Dit kan net zo nuttig zijn voor een wiki.
Als u een leuke democode op een pagina wilt schrijven, kunt u de stijlen eenvoudig beperken tot alleen de demo-inhoud. Dat laat je los met de CSS op de demo, maar niets anders op de pagina wordt beïnvloed.
Een ander gebruiksscenario is eenvoudigweg inkapseling: als uw webpagina bijvoorbeeld een zijmenu heeft, is het zinvol om stijlen die specifiek zijn voor dat menu in een <style scoped> sectie in dat deel van de markup te plaatsen. Deze stijlregels hebben geen enkel effect bij het weergeven van andere delen van de pagina, waardoor ze mooi gescheiden blijven van de hoofdinhoud!
Mogelijk is een van de meest overtuigende gebruiksscenario's het webcomponentmodel . Webcomponenten zullen een geweldige manier zijn om zaken als schuifregelaars, menu's, datumkiezers, tabbladwidgets, enz. te bouwen. Door de specifieke stijlen aan te bieden, kan een ontwerper een widget bouwen en deze samen met de bijbehorende stijlen verpakken als een op zichzelf staande eenheid die anderen kunnen deze bundelen en combineren tot een rijke webapplicatie. We zijn van plan <style scoped> intensief te gebruiken met webcomponenten en de schaduw-DOM (die al kan worden ingeschakeld door de experimentele vlag 'schaduw-DOM' in te stellen in chrome://flags). Op dit moment is er geen echt goede manier om ervoor te zorgen dat stijlen beperkt blijven tot webcomponenten zonder toevlucht te nemen tot slechte praktijken zoals inline styling, dus scoped-stijlen passen hier perfect bij.
Waarom het bovenliggende element opnemen?
De meest natuurlijke manier is om het bovenliggende element op te nemen, zodat de <style scoped> -regels bijvoorbeeld een gemeenschappelijke achtergrondkleur voor het gehele bereik kunnen instellen. Het maakt het ook mogelijk dat scoped stylesheets “defensief” worden geschreven voor browsers die <style scoped> nog niet ondersteunen, door regels vooraf te laten gaan met een ID of class selector als reserve:
<div id="menu">
<style scoped>
#menu .main { … }
#menu .sub { … }
…
Dit bootst het effect na van het gebruik van stijlen wanneer 'scoped' is geïmplementeerd, maar met enige runtime-prestaties als gevolg van de complexere selector. Het leuke van deze aanpak is dat het een elegante fallback-aanpak mogelijk maakt tot de dag waarop <style scoped> breed wordt ondersteund en de ID-kiezers eenvoudigweg kunnen worden geschrapt.
Toestand
Aangezien de implementatie van scoped stylesheets nog nieuw is, zijn ze momenteel verborgen achter een runtime-vlag in Chrome. Om ze in te schakelen, heb je een versie van Chrome nodig met versienummer 19 of hoger (momenteel Chrome Canary), en zoek vervolgens de vermelding 'Enable <style scoped> ' in chrome://flags (tegen het einde), klik op 'Inschakelen' en start de browser opnieuw.
Er zijn momenteel geen bugs bekend, maar @global en scoped-versies van @keyframes en @-webkit-region worden nog steeds geïmplementeerd. Ook @font-face wordt voorlopig genegeerd omdat de kans groot is dat de specificaties veranderen.
We willen iedereen die geïnteresseerd is in de functie aanmoedigen om het uit te proberen en ons te laten weten wat je ervaringen zijn: de goede, de slechte en (misschien) de buggy.