Gå med meg bak gardinen inn i W3C CSS-arbeidsgruppen. Historisk fylt med utfordringer, har gruppen vokst til en av de mest produktive, kraftverk arbeidsgruppene i W3Cs historie. Hva skjedde for å få til denne endringen? For å gi innsikt og oppmuntre webfolk til å delta mer i arbeidsgrupper generelt, la oss skru opp lyset på noen veldig forskjellige mennesker: CSS WG-individer, som vil over denne serien avsløre deres uavhengige, så vel som globale, visjon for CSS , og for nettet.
I dette første intervjuet besøker jeg gruppens medformann, Daniel Glazman, som hevder at han “noen ganger føler seg som en dinosaur i verden av nettstandarder, etter å ha overlevd til nesten 14 år med aktiv delirium i World Wide Web Consortium inkludert deltakelse i HTML4, CSS2 og CSS3 ". Han driver sitt eget programvareselskap, Disruptive Innovations, og bygger den standardorienterte, Gecko-baserte WYSIWYG-redaktøren, BlueGriffon.
MH: Da du først ble medformann i CSS-WG, var CSS 2.1 fremdeles uferdig, men CSS3-implementeringer tok fart utover spesifikasjonene. Hvordan klarte du å gjenopprette retning i en så vanskelig tid?
DG: Det var ikke så vanskelig, vet du. Medlemmene av CSS WG er alle her for å gjøre CSS fremgang. Riktignok er de her for å gjøre det videre for deres egen konkurransefortrinn, men de er fortsatt (veldig) smarte mennesker av (veldig) god vilje. Min formann Peter Linss og jeg hadde veldig lite å gjøre for å få arbeidsgruppen til å fokusere på det essensielle, og det essensielle var på den tiden "Release CSS 2.1 as a REC". Så vi tildelte prioriteringer, ofte eliminert ikke-kritiske diskusjoner fra møtene og konferansesamtalen, spilte litt dirigent for CSS-orkesteret, og det er alt. Alt dette fordi det var nok.
MH: Hvordan føler du at modularisering har påvirket utviklingen av CSS?
GD: Det påvirket det på to forskjellige måter:
- På den gode siden: CSS 1 var 15 sider lang, CSS2 var 200 sider lang, og CSS3 er enda mye større enn det. Å holde en enkelt spesifikasjon var tydeligvis ikke et alternativ fordi forskjellige deler av CSS3 utvikler seg med forskjellige hastigheter. Det hjalp med å få ting til å utvikle seg bedre og raskere, og det hjalp med å få advokater / redaktører for de forskjellige modulene.
- På den dårlige siden: ikke alle er interessert i alle modulene, og en bivirkning av modulering er spesialisering. For å være helt rettferdig er det også en bivirkning av kompleksitet, og noen av modulene våre, for eksempel tekst, når svært komplekse spørsmål knyttet til skriving av manus, typografisk vanlig praksis og kompleksitet er nesten uunngåelig.
MH: Som leder, hva er de tre viktigste utfordringene dine i å administrere en voksende, produktiv og lys gruppe mennesker til en slags konsensus?
DG: Jeg er ikke en "leder". Jeg leder og det er helt annerledes. CSS WG (hør medlemmene) bestemmer retningen ved konsensus selv. Det viktigste er som alltid å sørge for at det viktigste forblir det viktigste.
Det viktigste er som alltid å sørge for at det viktigste forblir det viktigste. Daniel Glazman
For å oppnå det er en stoles rolle å gjøre alt som trengs for å unngå støy, interne konflikter og eksterne angrep. Det er noen ganger vanskelig, og til og med arbeidsgruppemedlemmene vet ikke alt som skjedde bak gardinene de siste fire årene. For å oppsummere det til, ikke tre som du ba om, men fire ting, kunne jeg si: forstå brukere, fokusere, implementere, levere.
MH: Hva er din største frykt for CSS-WG?
DG: En utvikling mot arbeidsvanene til WHAT-WG. I sin ganske korte eksistens førte WHAT-WG til et stort og nesten enestående sammenstøt med IETF, og ble kvitt HTML-versjonen som jeg synes er en helt gal beslutning i hele bransjen (og jeg mener ikke nettleserleverandører, men brukere her ) vil betale dyrt i fremtiden, forsøk på å gjøre modellen sin percolate i alle nettstandarder, og til slutt en spesifikasjon som er, vel, ikke en spesifikasjon siden den aldri stabiliserer seg. Kanskje HTML ble et eksempel på Heisenbergs prinsipp: det endres når du ser på det?
Dette er bare min personlige mening her, men jeg tror dette ville være den siste tingen å gjøre for CSS.
MH: Hva er din største frykt for W3C?
GD: Det har alltid vært det samme: mangel på pragmatisme og kontraproduktiv politisk korrekthet.
MH: Daniel, du er også en utvikler som utvikler programvare ved hjelp av åpne webteknologier. Fortell litt om arbeidet ditt med å implementere funksjoner i verktøyene du bygger.
DG: Verktøyet mitt er en WYSIWYG-redaktør på tvers av plattformer, åpen kildekode for alle smaker av HTML. Den har en full GUI for CSS 2 og 3, inkludert 3D-transformasjoner, overganger og tidsfunksjoner. Den håndterer SVG og MathML også. Kjernens CSS-parser og serieiseringsprogram, JSCSSP, er resultatet av mange års tanker, selv om det ikke tok så lang tid å implementere, heldigvis.
Det hjelper meg mye når jeg oppdager feil, inkonsekvenser og tolkningsproblemer i CSS-spesifikasjoner. Noen ganger er ting som ser nesten perfekt ut i spesifikasjonen bare ikke implementerbare i en fin og forståelig GUI. Som redaktørleverandør husker jeg alltid brukerne våre er nettleserbrukere, men også nettforfattere. Denne siste kategorien fortjener gode redigeringsverktøy med vennlige GUIer. Men hvis våre tekniske spesifikasjonsvalg ikke lar redaktørleverandører som meg finne noe vennlig GUI, kan det hende vi har et problem.
MH: Utviklere har måttet lage polyfills og mixins og ikke-standardteknikker for å løse reelle problemer. Noen antyder at dette er hele feilen ved å holde variabler i CSS. Hva tenker du om dette?
DG: Jeg har alltid ønsket variabler, jeg var til og med medforfatter av et forslag om det med Dave Hyatt fra Apple. Variabler er absolutt nødvendig for bedriftsbrukere som ikke vil gjenta en gitt farge, en gitt størrelse eller en gitt URL over hele bedriftens nett. De ønsker et bedrifts stilark og forfattere som bruker variablene som er definert der, og bare der, så hvis en variabel endres, får hele bedriftens nett endringen umiddelbart.
Mixins, variabler og andre eksotiske arter - Jeg bryr meg ikke egentlig om den presise tekniske løsningen, jeg bryr meg om funksjonene. CSS ble opprinnelig designet med tanke på nesten bare nettlesere og "notepadability". Gitt, CSS er "notepadable"; men det er ikke lett å håndtere i industrikritiske miljøer. Språket savner noen få ting for å gjøre brukernes liv lettere, og jeg vil at disse tingene skal dukke opp i CSS.
MH: Noen ytterligere tanker?
DG: I begynnelsen av nettet hadde CSS konkurrenter. Det er nå det ubestridte stilspråket på nettet. Jeg forstår at noen forfattere kan bli frustrerte når de ser at funksjonen de ba om for mange år fremdeles ikke er her.Men du må forstå at dette er en absolutt kjerneteknologi på nettet som er standardisert av bare 20 personer, og det er ikke mange flere tilgjengelige fordi standardisering er en kompleks, en veldig kompleks (og noen ganger utakknemlig) oppgave.
Standardisering og implementering tar tid. Daniel Glazman
Det vi har på radaren vår, er nok til å gi oss mange års arbeid, og selv om det ikke alltid forstås, er det viktig å sørge for at boksmodellen fungerer på vertikale asiatiske språk - om ikke mye viktigere - enn å ha variabler i CSS. Som jeg sa som svar på ditt første spørsmål, er det bare et spørsmål om prioriteringer.
Vi vil til slutt gjøre alt, ingen bekymringer. Men standardisering og implementering tar tid. Det er en konstant i bransjen vår.
