{"id":3493,"date":"2023-09-25T18:19:45","date_gmt":"2023-09-25T16:19:45","guid":{"rendered":"https:\/\/blog.tomayac.com\/2023\/09\/25\/w3c-tpac-2023-trip-report\/"},"modified":"2023-09-25T18:19:45","modified_gmt":"2023-09-25T16:19:45","slug":"w3c-tpac-2023-trip-report","status":"publish","type":"post","link":"https:\/\/tomayac.com\/wordpress\/2023\/09\/25\/w3c-tpac-2023-trip-report\/","title":{"rendered":"W3C TPAC 2023 Trip Report"},"content":{"rendered":"\n\t\t\t

Background \ud83d\udd17<\/a><\/h2>\n

The 2023 edition of the World Wide Web Consortium (W3C) Technical Plenary and\nAdvisory Committee (TPAC) meeting took place from September 11 to 15 in the\nMeli\u00e3 hotel in Seville<\/a>,\nSpain. The hotel is located right next to the\nPlaza de Espa\u00f1a<\/a>,\na major Spanish tourist destination. The setup of the meeting was hybrid, and on\nsite, strict Covid precautions were enforced, even though the pandemic was\ndeclared to be "over". Despite these methods, several people caught it. This is\nmy personal report as a representative of the Chrome DevRel team at Google.<\/p>\n

\"Panorama<\/p>\n

\"View<\/p>\n

Monday, Tuesday \ud83d\udd17<\/a><\/h2>\n

Web Applications Working Group \ud83d\udd17<\/a><\/h3>\n

I attended the\nWeb Applications Working Group<\/a> meetings on\nMonday and Tuesday. After a quick rundown of all the APIs in scope for the\nworking group, the first topic was the\nScreen Orientation API<\/a>,\nwhich was mostly driven by questions and improvement proposals the WebKit folks\nhad after implementing it.<\/p>\n

Next, the group discussed the Badging API, which is only available after\ninstallation, and browsers differ on whether they make the API detectable when\nthe app is running in a tab.<\/p>\n

An interesting corner case was debated in the context of the joint meeting with\nthe Devices and Sensors Working Group<\/a>.\nApple can't join the group due to its unwillingness to implement some of the\nAPIs and the sheer volume of proposals the team would have to review. The\nworkaround is\nshared deliverables<\/a>,\nwhere the APIs that there is<\/em> agreement on get cross-delivered by a working\ngroup Apple is part of.<\/p>\n

Following this, we talked about whether the\nScreen Wake Lock API<\/a>\nshould use\ntransient<\/a>\nor\nsticky activation<\/a>.<\/p>\n

The group made no progress on Fran\u00e7ois Beaufort's suggestion for a\nScreen Brightness API<\/a>.<\/p>\n

On the topic of\nDeviceOrientation API<\/a>\nvs. Generic Sensor API<\/a>, the\nsoft-conclusion was that the new API provides not enough advantage over the\nexisting API. There's still disagreement about whether using the API should\nrequire a permission, which is mostly used for fraud detection to determine if a\nreal user is holding a device.<\/p>\n

For the\nGeolocation API<\/a>,\nmost discussion circulated around limiting its precision by encouraging more\ncoarse data. On the opposite side, there's also still the open question of\nfloorLevel<\/code> data, which Safari exposes, but which isn't standardized. The group\nbriefly discussed a toJSON()<\/code> method for geolocation results, but it probably\nwould be a breaking change due to instanceof<\/code> checks. The\nbackground geolocation<\/a>\ndiscussion was taken over repeatedly by trolls, which made proper discussion\npartly impossible. It's a solve-worthy problem, albeit it's a heated space.\nGeolocation Sensor<\/a> had promises but\nwe're not sure it's worth bringing this over, since the callback can easily be\nwrapped.<\/p>\n

There was a joint meeting with the\nInternationalization Working Group<\/a> to\ndiscuss long-standing\nopen questions regarding translations of the Web App Manifest<\/a>\nwere investigated, which resulted in a\npotential solution<\/a>.\nI foresee challenges when looking at the "shortcuts"<\/code> member.<\/p>\n

Notes and resources \ud83d\udd17<\/a><\/h4>\n