{"id":3321,"date":"2019-09-21T18:03:15","date_gmt":"2019-09-21T16:03:15","guid":{"rendered":"https:\/\/blog.tomayac.com\/2019\/09\/21\/project-fugu-at-w3c-tpac\/"},"modified":"2019-09-21T18:03:15","modified_gmt":"2019-09-21T16:03:15","slug":"project-fugu-%f0%9f%90%a1-at-w3c-tpac","status":"publish","type":"post","link":"https:\/\/tomayac.com\/wordpress\/2019\/09\/21\/project-fugu-%f0%9f%90%a1-at-w3c-tpac\/","title":{"rendered":"Project Fugu \ud83d\udc21 at W3C TPAC"},"content":{"rendered":"\n\t\t\t

This week, I attended my now third W3C<\/abbr>\nTPAC<\/abbr>.\nAfter TPAC\u00a02017<\/a>\nin Burlingame,\u00a0CA, United States of America and\nTPAC\u00a02018<\/a> in Lyon, France,\nTPAC\u00a02019<\/a> was held in Fukuoka, Japan.\nFor the first time, I felt like I could somewhat meaningfully<\/em> contribute and\nhad at least a baseline understanding<\/em> of the underlying W3C mechanics.\nAs each year, the TPAC agenda<\/a> was crammed\nand overlaps were unavoidable.\nBelow is the write-up of the meetings I had time to attend.<\/p>\n

Day 1 \u2693<\/a><\/h4>\n

On Monday, I attended the Service Workers Working Group<\/a>\n(WG) meeting.\nThe agenda<\/a> this time\nwas a mix of implementor updates, new proposals, and a lot of discussion of special cases.\nI know Jake Archibald<\/a> is working on a summary post,\nso I leave it to him to summarize the day.\nThe\nraw meeting minutes<\/a>\nare available in case you're interested.<\/p>\n

Day 2 \u2693<\/a><\/h4>\n

On Tuesday, I visited the\nWeb Application Security Working Group<\/a>\nmeeting as an observer.\nI was mostly interested in this WG because the\nagenda<\/a>\npromised interesting proposals like Apple's\n\/.well-known\/change-password<\/code><\/a>\nthat was met with universal agreement.\nSome interesting discussion also sparked around again Apple's\nisLoggedIn()<\/code><\/a>\nAPI proposal.\nI was reminded of why on the web we can't have nice things through an attack vector\nthat leverages HSTS<\/abbr> for tracking purposes.\nLuckily there is\nbrowser mitigation<\/a>\nin place to prevent this.\nThe\nmeeting minutes<\/a>\ncover the entire day.<\/p>\n

Day 3 \u2693<\/a><\/h4>\n

Wednesday was unconference day with\n59(!) breakout sessions<\/a>.\nOther than the at times tedious working group sessions,\nI find breakout sessions to be oftentimes more interesting and an opportunity to learn new things.<\/p>\n

Breakout Session JS Built-in Modules \u2693<\/a><\/h5>\n

The first breakout session I attended was on\nJS built-in modules<\/a>,\na TC39<\/abbr> proposal by Apple for a\nJavaScript Built-in Library<\/a>.\nThe session's minutes<\/a> are available,\nin general there was a lot of discussion and disagreement around namespaces and\nhow built-in modules should be governed.<\/p>\n

Breakout Session New Module Types: JSON, CSS, and HTML \u2693<\/a><\/h5>\n

The next session was on\nnew module types for JSON, CSS, and HTML<\/a>.\nAs the developer of\n<dark-mode-toggle><\/code><\/a>,\nI'm fully in favor of getting rid of the clumsy\ninnerHTML<\/code> all the things!!!1!<\/a>\napproach that vanilla JS custom elements currently make the programmer to follow.\nIf you're likewise interested, subscribe to the\nCSS Modules issue<\/a> and the\nHTML Modules issue<\/a>\nin the Web Components WG repo.\nThe discussion circulated mostly around details how @imports<\/code> would work and\nhow to convey the type of the import to avoid security issues,\nfor example following the <link rel="preload"><\/code> way.\nThe meeting minutes<\/a>\nhave the full details.<\/p>\n

\/\/ Non-working example<\/span>
import<\/span> styles from<\/span> 'styles.css'<\/span> as<\/span> stylesheet;<\/span>
import<\/span> settings from<\/span> 'settings.json'<\/span> as<\/span> json;<\/span><\/code><\/pre>\n
Breakout Session For a More Capable Web\u2014Project Fugu \u2693<\/a><\/h5>\n
Together with Anssi Kostiainen<\/a> from Intel and\nJohn Jansen<\/a> from Microsoft,\nI organized a breakout session\nfor a more capable web<\/a>\nunder the umbrella of Project Fugu \ud83d\udc21.\nYou can see our slides embedded below.\nIn the session we argue that to remain relevant with native, hybrid, or mini apps, web apps, too,\nneed access to a comparable set of APIs.\nWe briefly touched upon the APIs being worked on by the cross-company project partners,\nand then opened the floor for an open discussion on why we see the browser-accessible web in danger\nif we don't move it forward now,\ndespite all fully acknowledged challenges around privacy, security, and compatibility.\nYou can follow the discussion in the excellent(!)\nsession minutes<\/a>, courtesy of Anssi.<\/p>\n
Breakout Session Mini App Standardization \u2693<\/a><\/h5>\n
The Mini App Standardization<\/a>\nsession, organized by the Chinese Web Interest Group<\/a>,\nwas super interesting to me.\nIn preparation of the\nGoogle Developer Days in Shanghai, China<\/a>,\nthat I spoke at right before TPAC, I have\nlooked at WeChat mini programs<\/a>\nand documented the developer experience and how close to and yet how far from the web they are.\nA couple of days before TPAC, the Chinese Web Interest Group had released a\nwhite paper<\/a> that documents their ideas.\nThe success the various mini apps platforms have achieved deserves our full respect.\nThere were, however, various voices\u2014including from the\nTAG<\/abbr>\u2014that urged the various stakeholders\nto converge their work with efforts made in the area of\nProgressive Web Apps, for example around the Web App Manifest<\/a>\nrather than create yet another manifest-like format.\nRead the full session minutes<\/a> for all details.\nOne of the results of the session was the creation of the\nMiniApps Ecosystem Community Group<\/a>\nthat I hope to join.<\/p>\n