A month ago I attended the second Extensible Web Summit, held this time in Berlin. I blogged about the first one back in April. Hopefully we’ll see more of these events in the future. All of the sessions were collaboratively minuted, so you can read through the notes and see what was discussed.
What is the Extensible Web?
The first main session was a conversation about just what an extensible web means. There has been a lot of talk about exposing underlying primitives in order to make features less magic and more extensible. I made the point that the word primitive can be a trap. It’s not always the lowest-level primitive that needs to be exposed for extensibility. Sometimes the best strategy is to provide a relatively high-level API underneath an even higher-level feature (as long as the API we expose now does not preclude going deeper in the future).
As an example, take some proposed CSS wizardry like float:bottom. We could provide a high-level feature like this with nothing more than an API to set a new ‘bottom’ keyword. Or we could delve the depths of layout mechanics and box trees to expose the primitive mechanisms from which this high-level feature could be implemented from the ground up. I don’t think either extreme is a viable approach. The highest level feature isn’t adaptable enough to be extended to new use-cases. And the lowest-level delving is way too much effort to build out one new feature.
There’s lots of room between the extremes. Analyzing the magic behind a high-level feature can help desribe a slightly lower-level feature, and you can add APIs for the next level down. It might turn out that grid layout gives enough expressive power to solve the use cases for float:bottom, while providing the necessary adaptability for similar use cases. And it might make sense to provide a bit of introspection into the details of grid layout, so that script can refine a responsive grid in ways difficult to express declaratively in CSS. Iterating on features in this way gets us closer to the lowest level primitives at each step.
Getting Developer Input
One main reason for these events is to bring developers together with standards people and browser implementors. The web needs input from the people using the platform to set priorities and evaluate proposals. One session at this event was a discussion on how to get more developer input in web standards. Robin Berjon described some of his efforts that will bring discourse-style forums to webplatform.org.
It turned out that quite a few developers at this session had worked (separately) on the difficulties of providing a good editing environment on the web. This is an area with a lot of current interest in the standards community. Hopefully the connections made at this conference will lead to a clearer set of editing APIs focused on the needs of these developers who have already put so much effort into this problem.
I had brought up the topic of a common debugging protocol at the first summit. This time I got to meet Kenneth Auchenberg, who is behind remotedebug.org (the site that sparked my interest in the topic). We talked a bit about what Mozilla has been doing mere minutes before they announced their new debugging add-on that lets you use Mozilla tools when debugging on iOS and Chrome on Android. Kenneth just gave a presentation at Fronteers detailing other efforts around making web debugging more interoperable.
The next Extensible Web Summit is tentatively planned for spring of next year in the bay area. Please consider attending if you’re near by. Sign up at specifiction and add your ideas on where the web platform should go. And please provide feedback on what we’re doing on the Web Platform Team at Adobe.