Chrome Dev Insider: de CSS- en UI-editie

Welkom bij de tweede editie van Chrome Dev Insider, waar we updates delen over wat er nieuw en spannend is in de community en hier bij Chrome. Dit is een nieuwe aflevering met insiderverhalen over hoe wij ons werk benaderen, en een korte blik op enkele van de belangrijkste updates waar u op moet letten.

Ik ben Rachel Andrew, de Content Lead voor web.dev en developer.chrome.com , als onderdeel van het Chrome Developer Relations-team. Ik werk al ruim twintig jaar op het web, met een focus op open webstandaarden en CSS, en ben lid van de CSS Working Group.

Twee maanden geleden hebben we Google I/O afgerond, waar we enkele van de belangrijkste updates deelden over hoe we ontwikkelaars ondersteunen bij het sneller en krachtiger maken van het internet, terwijl gebruikersinformatie veilig en privé blijft.

Een van de dingen die opviel (en we zijn blij dat de community dit heeft opgemerkt !) is de enorme hoeveelheid werk die het team doet om meer CSS- en UI-functies op internet te ondersteunen. In deze editie van Chrome Dev Insider nemen we u mee achter de schermen over wie er achter dit werk zit, hoe we werken aan de ondersteuning van CSS- en UI-ontwikkelaars en wat ons te wachten staat. Daarom ben ik blij dat ik deze editie van de Insider mag hosten.

In het nieuws

In de eerste Chrome Dev Insider hebben we enkele updates gedeeld over Compat 2021- en Interop 2022- initiatieven waarbij browserleveranciers en ecosysteemspelers samenwerken om meer functies op internet te brengen die in alle browsers worden ondersteund. Het initiatief heeft een sterke focus op CSS omdat browser-incompatibiliteit een van de grootste uitdagingen is voor CSS-ontwikkelaars .

Hoewel dit voor de meesten misschien geen nieuws is, is het spannend om te zien welke vooruitgang we al hebben geboekt in alle browsers.

Chrome Dev op 71, Firefox Nightly op 74, Safari TP op 73.
Scores voor experimentele browsers in maart 2022.
Chrome Dev op 77, Firefox Nightly op 80, Safari TP op 80.
Scores van experimentele browsers in juli 2022. Bekijk de laatste scores .

Eerder vorige maand zagen we dat Safari een bumperrelease aankondigde met Safari 16.0 Beta, die spannende functies bevat zoals Container Queries , subgrid en een flexbox-inspecteur . Recente releases van Firefox en Chrome bevatten een aantal opwindende functies en oplossingen. Ik behandel elke maand de belangrijkste zaken in stabiele en bètabrowsers in mijn serie nieuwe berichten op het webplatform .

Insider primeur: Ondersteuning van CSS- en UI-ontwikkelaars

Nu 2022 een spannend jaar blijkt te worden voor CSS-functies, vonden we het een goed moment om je mee te nemen achter de schermen. Ik sprak met Una Kravets, hoofd van DevRel voor Web UI en Devtools, en Nicole Sullivan , onze productmanager voor Web UI die zich richt op CSS- en HTML-API's, om te praten over de reis van Chrome naar het ondersteunen van UI-ontwikkelaars.

Laten we bij jullie allebei beginnen. Vertel eens iets meer over jezelf?

Nicole: Ik ben de productmanager voor Web UI in Chrome. Ik richt mij specifiek op nieuwe CSS- en HTML-API's en op ontwikkelaars en ontwerpers die UI bouwen. Het is een opwindende ruimte waar een aantal heel belangrijke API's uitkomen, zoals Container Queries , Scope en (hopelijk!) verticale ritme .

Una: Ik leid de Web UI- en DevTools DevRel-teams. We richten ons op het ondersteunen van UI-ingenieurs op het webplatform en zorgen ervoor dat ze over de tools beschikken die ze nodig hebben om succesvol te zijn. Dit omvat CSS API's en HTML-componenten samen met DevTools-functies om actieve wijzigingen en feedback te zien.

De ondersteuning van Chrome voor UI-ontwikkelaars is de afgelopen jaren in een stroomversnelling gekomen. Waarom denk je dat het zo lang duurde om hier te komen? Wat waren de grootste uitdagingen?

Una: We moesten wat werk verzetten om aan te tonen hoe belangrijk dit werk was en waarom het een prioriteit zou moeten zijn. We zijn in 2019 begonnen met het MDN DNA-onderzoek , waarbij de gebruikersinterface werd geïdentificeerd als een van de belangrijkste pijnpunten op het platform. En sindsdien zijn we data blijven gebruiken als leidraad voor het MDN en onze eigen interne tevredenheidsonderzoeken onder ontwikkelaars. Het resultaat van dit alles is dat we een diepere buy-in van leiderschap konden krijgen en prioriteit konden geven aan engineeringwerk rond enkele van de meest gevraagde ontwikkelaarsfuncties in de UI-ruimte, die ook het grootste deel van de focus vormen voor initiatieven als Compat 2021 en Interop 2022 .

Nicole: Naast het verkrijgen van de buy-in van het leiderschap, moesten we ook de juiste manier vinden om deze API's bij ontwikkelaars te krijgen. Toen ik voor het eerst bij Chrome kwam, heb ik dit verprutst in een project met de naam Layered APIs (of kortweg LAPIs). LAPI's waren bedoeld om ontwikkelaars een drop-in componentervaring te bieden. Ik denk nog steeds dat dit een geweldig resultaat was om op te schieten, maar we hebben veel fouten gemaakt! We concentreerden ons eerst op Toast-meldingen en een virtuele lijst . Toasts zijn bijna onmogelijk toegankelijk te maken en een virtuele lijst is een van de moeilijkste onderdelen om goed te krijgen. Onze bedoelingen waren goed, maar het hielp de ontwikkelaars niet, dus hebben we het project stopgezet. Het is moeilijk om op de harde manier te leren, maar elke fout voedt de renaissance van CSS en HTML die nu plaatsvindt.

Laten we wat meer over LAPI's praten. Wat gebeurde daar?

Nicole: Voor LAPI's wisten we dat het web een drop-in-componentontwikkelaarservaring nodig had die dichter bij het bouwen van een native UI lag. En het was duidelijk dat het opnieuw uitvinden van het wiel ontwikkelaars tegenhield. Ik kan het aantal tabbladen dat ik in mijn carrière heb opgebouwd niet tellen! Dat gezegd hebbende, hebben we geprobeerd dit op te lossen door JavaScript met de browser te verzenden, wat erg moeilijk was. Niemand had JavaScript eerder in de browser geleverd en het was niet duidelijk hoe het zou moeten interageren met de C++-code die de rendering-engine van de browser aanstuurt. We hebben naar andere browserleveranciers geluisterd (bedankt, Mozilla!) en zijn van die aanpak afgestapt en dus hebben we iets veel beters kunnen vinden met Open UI. Door te leunen op HTML en CSS komen we uit op flexibele, declaratieve oplossingen. Omdat het declaratief is, kunnen we toegankelijkheid inbouwen op een manier die met JavaScript niet zo eenvoudig zou zijn geweest. Ik ben erg enthousiast over waar dit heen gaat. We werken aan de ondersteuning van selectmenu, pop-up, tooltip, nav, accordeon, tabbladen, carrousel en toggle, wat echt essentiële UI-ontwerppatronen zijn.

We hebben dus veel geleerd. En ik weet dat er andere initiatieven op dit gebied waren, zoals CSS Houdini . Wat is het verhaal?

Una: Ja, CSS Houdini is een andere plek waar we van de gemeenschap hebben geleerd. Er zijn een heleboel nuttige Houdini-functies , maar veel ervan waren te laag om bredere acceptatie en ondersteuning te krijgen. We realiseerden ons dat het implementeren van API's op laag niveau niet noodzakelijkerwijs de wrijving voor ontwikkelaars verminderde. In plaats daarvan heeft de focus op oplossingen en behoeften op een hoger niveau bijgedragen aan het verkrijgen van ondersteuning voor meerdere browsers en de landingen die nodig zijn om de naald in het ecosysteem te verplaatsen. We houden momenteel de voortgang bij op https://ishoudinireadyyet.com/ .

Over ondersteuning voor meerdere browsers gesproken: initiatieven als Interop 2022 en Open UI lijken aanzienlijke positieve resultaten voor de gemeenschap op te leveren. Wat hoor je van ontwikkelaars?

Una: Een van de grootste pijnpunten die we van ontwikkelaars horen is 'het hetzelfde maken van het ontwerp in alle browsers'. We hebben dit aangepakt door samen te werken met andere browserleveranciers om prioriteit te geven aan enkele van de meest gevraagde ontwikkelaarsfuncties. En de feedback die we van de community hebben gehoord, is overweldigend positief. Bovendien is het, door een grote herarchitectuurinspanning genaamd RenderingNG , mogelijk geworden om sommige van deze functies veel performanter te maken. Ontwikkelaars zijn blij dat er eindelijk aan deze langverwachte functies wordt gewerkt, waar ze al jaren om vragen, en dat ze cross-browser beschikbaar komen.

Nicole: De opwinding in de gemeenschap is voelbaar. Je kunt het zien op Twitter . :)

De tweet genoemd in de vorige paragraaf.

Het werken met het ecosysteem is van cruciaal belang gebleken voor het succes dat we hebben geboekt bij het gemakkelijker maken van het leven van ontwikkelaars. Ik weet dat uw team daar veel werk heeft verricht. Wilt u enkele details delen?

Nicole: Ten eerste heb ik voortdurend ontzag voor de projecten die ontwikkelaars op internet bouwen. Van de kleinste bibliotheek tot volledige frameworks: ontwikkelaars bouwen geweldige dingen. Het is een fantastische gemeenschap van makers. En Chrome onderneemt een aantal stappen om meer verbonden te zijn met deze projecten.

Zo zijn we een paar jaar geleden begonnen met het werken met JavaScript Frameworks zoals React en Angular. En metaframeworks, bijvoorbeeld Next, Nuxt en Gatsby. Vorig jaar begonnen we hetzelfde te doen met UI-tools en -frameworks zoals Sass, Bootstrap en Material. Ik hoop dat we komend jaar kunnen samenwerken met GreenSock en andere tools die het leven van ontwikkelaars gemakkelijker maken. Ik zag zojuist Cassie Evans van GreenSock spreken op de Smashing Conference en ik werd erg enthousiast over het werken met mensen in de animatieruimte.

Dus waar zien we de grootste kansen voor het Web UI-ecosysteem?

Una: Wat de grote mogelijkheden betreft, heb ik het gevoel dat we nog maar aan het begin staan ​​van wat mogelijk is op het gebied van aanpasbare webervaringen. Nieuwe API's zoals containerquery's en de mediafuncties voor CSS-gebruikersvoorkeuren herdefiniëren de manier waarop ontwikkelaars naar responsief ontwerp kijken. Ik ben ook enthousiast over de gezamenlijke ontwerpervaringen die ontwikkelaars en ontwerpers in staat stellen om samen te werken met de gebruikers die hun websites bezoeken.

En Nicole, wat is de volgende stap op de roadmap voor jouw team?

Nicole: Niet alle verkenningen worden iets dat kan worden verzonden, maar er zijn een heleboel dingen waar ik nu heel enthousiast over ben:

Una heeft het eerste aangestipt: we maken responsief, op componenten gebaseerd ontwerp mogelijk. Het bevat tools voor het ontwerpen van kleursystemen, zodat ontwerpers kunnen reageren op gebruikersvoorkeuren, zoals de donkere modus. De OKLCH- kleurruimte zorgt er bijvoorbeeld voor dat de helderheid consistent blijft in alle tinten. Ontwerpers kunnen overstappen van het kiezen van kleuren naar het ontwerpen van relaties tussen kleuren, zonder te eindigen met modderig ogende paletten!

We werken ook aan enkele van de meest gevraagde API's, zoals containerquery's , cascadelagen , bovenliggende selector ( :has ), scoped stijlen en nesting . Ontwikkelaars hebben deze nodig zodat ze flexibele ontwerpsystemen vol herbruikbare componenten kunnen bouwen.

Scroll-gekoppelde animaties is een ander leuk gebied. Ik vind de demo van Steve Gardner erg leuk. Hij heeft boterzacht scrollen en coole vliegtuiganimaties die worden geactiveerd bij het scrollen. Hoewel deze leuk zijn, kan het lastig zijn om ze goed te krijgen, vooral als je de toegankelijkheid in gedachten houdt. Daarom voeren we nu gebruikerstests uit voor de toegankelijkheid van de functie.

Waar ik persoonlijk het meest enthousiast over ben, zijn de ingebouwde web-UI-bedieningselementen. Ontwikkelaars blijven steeds opnieuw dezelfde tabbladset bouwen, ik denk dat de browser kan helpen. Bij Open UI werken we aan componenten zoals selectmenu, pop-up, tooltip, tabbladen, nav, accordeon en toggle. We onderzoeken hoe het eruit zou zien om toegankelijkheid in deze browserprimitieven in te bouwen, zodat het internet na verloop van tijd standaard toegankelijk zou kunnen worden. Ontwikkelaars kunnen zich dan concentreren op de meer complexe en genuanceerde problemen, terwijl de basisprincipes, zoals hoe tabbladen kunnen worden geopend, door de browser kunnen worden ondersteund. Dit heeft waarschijnlijk een eigen bericht nodig, dus daar stop ik voorlopig mee!

Ten slotte zullen we blijven investeren in interoperabiliteit tussen browsers. Het was geweldig om samen te werken met de mensen van WebKit en Gecko om consistentie in de ontwikkelaarservaring te brengen. We hebben ontwikkelaars luid en duidelijk gehoord dat ze dit willen!

Oh, en als je het nog niet hebt uitgeprobeerd: de Shared Element Transitions API van het Seamless Web-team gaat de manier veranderen waarop mensen voor het web ontwerpen. Al die subtiele kleine overgangen waarmee ontwerpers hun ontwerpen in de fysieke ruimte kunnen oriënteren, zullen niet alleen mogelijk, maar ook gemakkelijk zijn. Jake Archibald heeft een geweldige demo .

Als de normen goed gaan, kunnen we dit jaar misschien zelfs naar verticaal ritme kijken! We kunnen voortbouwen op LayoutNG, dat zoveel functies ontgrendelt.

Bedankt allebei. Ik weet zeker dat de hele gemeenschap, net als wij, enthousiast is over het vernieuwde tempo van verbeteringen en functies die naar de Web UI-wereld komen. Er is nog veel te doen, dus waar zou je zeggen dat je je reis moet beginnen?

Una: Onze Wat is er nieuw voor het webplatform- sessie op I/O behandelt de hoogtepunten van veel van de functies die dit jaar verschijnen. Adam Argyle schreef ook een geweldig artikel over alle nieuwe en aankomende CSS-landingen. Op een voortdurende basis zou ik me voorlopig concentreren op stabiele releases en me bewust zijn van het andere werk dat in de pijplijn zit. Je geweldige serie Nieuw op het webplatform is daarvoor een geweldige serie om te volgen. Als u zich abonneert op de web.dev-nieuwsbrief, komt deze inhoud ook in de inbox van de ontwikkelaars terecht. En voor ontwikkelaars die hierbij betrokken willen zijn en willen helpen, is deelname aan Open UI een van de beste manieren om dit werk te ondersteunen.

Belangrijkste aankomende updates

We houden onze traditie in stand om u op de hoogte te stellen van een komende verandering waarmee u rekening moet houden bij het opbouwen van uw webervaringen.

Beperk de maximale leeftijd voor cookies tot 400 dagen

  • De update: Wanneer cookies worden ingesteld met een expliciet Expires/Max-Age attribuut, wordt de waarde nu beperkt tot niet meer dan 400 dagen in de toekomst. Voorheen was er geen limiet en konden cookies in de toekomst meerdere millennia verlopen. Het doel van deze limiet is om een ​​evenwicht te vinden tussen algemene gebruikspatronen en respect voor de privacy van gebruikers. Elke site die vaker dan elke 400 dagen wordt bezocht, kan cookies vernieuwen om de continuïteit van de dienstverlening te garanderen. Gebruikers kunnen er zeker van zijn dat cookies niet duizenden jaren zonder gebruik in hun browser blijven hangen.
  • Geschatte tijdlijn: verzending in Chrome 104 (stabiel op 2 augustus 2022).
  • CTA voor ontwikkelaars: Ontwikkelaars moeten cookies mogelijk vaker dan voorheen proactief vernieuwen wanneer gebruikers hun websites bezoeken. Anders worden gebruikers mogelijk 400 dagen nadat de cookie voor het eerst is ingesteld, uitgelogd.

Ik hoop dat je deze editie van de Chrome Dev Insider met plezier hebt gelezen. Mocht je het gemist hebben, hier is de eerste . We kijken ernaar uit u het volgende kwartaal nog meer te bieden.

Vertel ons tot die tijd wat u vindt van deze editie van Chrome Dev Insider en wat we kunnen doen om deze te verbeteren.

Wat vond je van deze editie van The Chrome Dev Insider? Deel uw feedback .