kaxigt.com

Jag skriver om webben för webben

HTML5.1

Postad: 15 april 2017 | HTML · html-guider | No Comments
Lästid: 3 minuter

HTML5 släpptes 2014 som ett resultat av ett samlat arbete av W3C HTML Working Group. Avsikten var då att börja publicera regelbundna och utökade uppdateringar av HTML-standarden. Dock blev det inte blev som planerat. Nu arbetar Web Platform Working Group (WP WG) mot en HTML5.1-release inom de närmaste sex månaderna, och ett allmänt arbetsflöde som innebär att vi kan släppa en stabil version av HTML som en W3C-rekommendation ungefär en gång per år.

Målen med detta

Huvudmålen för framtida HTML-specifikationer är att matcha verkligheten bättre, att kunna göra specifikationen så tydlig som möjligt för läsarna och givetvis att göra det möjligt för alla intresserade att föreslå förbättringar, och förstå vad som gör förändringar i HTML framgångsrika.

Tidslinjerna

Planen är att skicka ut en HTML5.1-rekommendation i september 2016. Det betyder att vi kommer att behöva ha en kandidatrekommendation i mitten av juni efter en gemensam överenskommelse baserat på det senaste arbetsutkastet.

För att göra det lättare för människor att granska ändringar kommer ett uppdaterat arbetsutkast att publiceras ungefär en gång i månaden. För enkelhetens skull noteras ändringarna i själva specifikationen.

På längre sikt skulle vi vilja rensa omarbeta och upprepa, vilket gör regelbundna adderande uppdateringar av HTML till en verklighet som är relativt enkel att implementera. Under tiden kan du spåra framsteg med hjälp av Github puls, eller genom att följa @HTML_commits eller @HTMLWG på Twitter.

Arbete med specen

Specifikationen finns på Github så alla som kan göra en förfrågan kan föreslå ändringar. För enkla ändringar som grammatikfixar är detta en mycket enkel process att lära sig – och enkla ändringar kommer i allmänhet att accepteras av redaktörerna utan krångel.

Om du hittar något i specifikationen som i allmänhet inte fungerar i webbläsare, vänligen skicka in problemet, eller ännu hellre, skicka in en förfrågan för att fixa det. Vi kommer i allmänhet att ta bort saker som inte har tillräckligt stöd i minst två webbläsarmotorer även om de är användbara att ha och vi hoppas att de kommer att få tillräckligt stöd i framtiden: i vissa fall kan du eller vi föreslå en släppt funktion som en framtida förlängning – se nedan angående ”inkubation”.

HTML är en mycket stor specifikation. Den är utvecklad från en uppsättning källfiler som bearbetas med Bikeshed-förprocessorn. Detta automatiserar saker som länkar mellan de olika sektionerna, exempelvis till elementdefinitioner. Betydande förändringar, även redaktionella sådana, kommer sannolikt att kräva en grundläggande kunskap om hur Bikeshed fungerar och vi kommer att fortsätta att förbättra dokumentationen speciellt för nybörjare.

HTML omfattas av W3C:s patentpolicy, så många potentiella patentinnehavare har redan sett till att det kan implementeras utan att betala någon licensavgift. För att behålla denna royaltyfria licensiering måste varje ”substantiell förändring” – en som faktiskt ändrar överensstämmelse – åtföljas av patentåtagandet som redan har gjorts av alla deltagare i Web Platform Working Group. Om du gör en förfrågan kommer detta automatiskt att kontrolleras och redaktörerna, ordföranden eller W3C-personale,n kommer att kontakta dig för att ordna detaljerna. I allmänhet är detta en ganska enkel process.

För betydande nya funktioner föredrar vi att en separat modul utvecklas, ”inkuberas”, för att säkerställa att det finns verkligt stöd från olika typer av implementerare inklusive webbläsare, författarverktyg, producenter av verkligt innehåll och användare, och när den är redo för standardisering som ska föreslås som en tilläggsspecifikation för HTML. Web Platform Incubator Community Group (WICG) skapades för detta ändamål, men givetvis när du utvecklar ett förslag är vilken plats som helst rimlig. Återigen ber vi dig att spåra tekniska bidrag till förslaget (WICG hjälper till att göra detta åt dig), så vi vet när det kommer att personer som hade en finger med i det också har förbundit sig till W3C:s royaltyfria patentlicenser och utvecklare kan med glädje implementera det utan att behöva oroa sig för om de senare kommer att drabbas av en patentprocess.

Testning

W3C:s process för att utveckla rekommendationer kräver en arbetsgrupp för att övertyga W3C:s direktör, Tim Berners-Lee, om att specifikationen:

”är tillräckligt tydlig, komplett och relevant för marknadens behov för att säkerställa att oberoende interoperabla implementeringar av varje funktion i specifikationen kommer att realiseras”

Detta måste göras för HTML 5.0. När en ändring föreslås i HTML förväntar vi oss att den har tillräckligt många tester för att visa att den förbättrar interoperabiliteten. Helst passar dessa in i ett automatiserat testsystem som ”Webapps tests” men i praktiken planerar vi att acceptera tester som visar den nödvändiga interoperabiliteten, oavsett om de är lättautomatiserade eller inte.

Fördelen med detta tillvägagångssätt är att förutom där funktioner tas bort från webbläsare, vilket är jämförelsevis sällsynt, kommer vi att ha en konsekvent ökande nivå av interoperabilitet när vi accepterar ändringar, vilket innebär att en ögonblicksbild av redaktörernas utkast bör när som helst vara en stabil grund för en förbättring.

Slutsatser

Vi vill att HTML ska vara en specifikation som författare och implementörer kan använda med lätthet och tillförsikt. Målet är inte perfektion (som trots allt är det godas fiende), utan snarare att göra HTML 5.1 bättre än HTML 5.0 – den bästa HTML-specifikationen tills vi producerar HTML 5.2…

Och vi vill att du ska känna dig välkommen att delta i att förbättra HTML, för dina egna syften och för webbens bästa.


Källa:
Chaals, Léonie, Ade – chairs
Alex, Arron, Steve, Travis – editors
[https://www.w3.org/blog/2016/04/working-on-html5-1/]