TAG/MeetCandidates2023/Daniel Clark

Daniel Clark - TAG Candidate 2023

These are Daniel Clark's answers to the 2023 TAG Candidate Questions.

You can also read Daniel Clark's nomination statement here.

Quotes from the minutes are not verbatim, and may not accurately reflect the candidate's statements.

What's an interesting question about how the Web’s architecture should evolve that you've come across recently?

I've recently been working on an editing feature called EditContext, which gives developers more direct control of how to handle editing actions performed by the user and more control over how the page interacts with input tools like IMEs. It's not a trivial API to use, and there isn't really a gradual path from contenteditable-based editing to EditContext-based editing; to some extent it's one or the other.

This goes against a lot of my priors about how web APIs should be designed. In general, we should try to make things really easy to adopt for the basic use cases, and developers should be able to use them for gradual enhancement without rewriting significant chunks of their application. But EditContext highlights that for some problems this just isn't feasible, and sometimes it's necessary to build something that's used in a really different way because the problems can't be solved by just piling gradual changes on top of each other.

CSS Flexbox and Grid layout were earlier cases of this, where it was recognized that sometimes it's best if layout works in a fundamentally different way than it always has, and for many developers it will be worth it to learn the new thing.

There isn't any hard-and-fast rule for which approach is appropriate in a given scenario, but I think it's interesting to think about this dichotomy of gradual enhancement vs diverging fundamentally with the status quo.

What are the technical trends you notice are happening on the Web, and what implications do you see for the work of the W3C?

I've seen an increasingly strong interest in WebComponents in the past couple of years -- a lot of the earlier friction with these has been worked out, and I think a growing number of developers are tired with bloated frameworks and are recognizing that the DOM is much more powerful and ergonomic than it used to be. There's a growing interest in libraries like FAST element and Lit that offer a light layer on top of web components, filling in some of the missing pieces without deviating from what makes them great. I think we who are working on standards can learn a ton from libraries like these because they tell us where the developer pain points are in existing parts of the platform, and where there are opportunities to advance standards to solve problems that libraries patch over.

What should the TAG's role be in reviewing WG charters?

The TAG's main strength, and where I think their main focus should lie, is on providing technical guidance on matters relating to web architecture. Most of the time, reviewing charters falls outside of this core mission, and the TAG is already pretty busy; requests for design reviews, which should be a top priority, can go months without hearing back. Spending too much time on charter debates can cause a further loss of focus. In some cases, it will make sense for the Team or the AC to ask the TAG for their input on a particular charter, but the TAG should be careful about how much time it spends on charter reviews until it's demonstrated that the time to complete design reviews has gone down.

Maps are increasingly important, but maps are done in javascript today, making them inaccessible. How do you feel about adding maps to the web platform?

This question aligns well with work in the OpenUI Community Group. They've been trying to specify reusable, customizable UI components that could eventually be shipped in browsers, with goals of reducing the number of core UI components that get rewritten in JS over and over again and as a result are often inaccessable, buggy, and not performant. It's interesting to think about this in terms of maps. I think this fits right in with what OpenUI is trying to do, so if you're interested in this problem I'd recommend raising it for discussion in that group.

How do you think the appointed TAG seats should be used?

The appointed seats are a good opportunity to ensure that the team is as well-rounded as it can be. Appointments can help complete the TAG with a diversity of backgrounds and technical skill-sets. The current TAG can help with this; they probably know best where some of their collective weaknesses lie, so I think it's important they weigh in on this during the Team's search for candidate appointees.

Has the TAG been taking the wrong approach in any of its recent activities, and if so, what would you change?

The TAG can be much too slow to respond to requests for design reviews. This is partly a resourcing question, and I'm hopeful that the expansion of the group will help, but it's also a question of the group's priorities. For feedback to be helpful it has to be topical, and standards devs won't always stop and wait for months. A reason I'm running is that I think it's critical that the TAG give *timely* technical advice, and I'll work to refocus the group on this goal as well as spending my own time on responding promptly to reviews.

What can the TAG and W3C do about the environmental and social impacts of the Web?

Considering performance as an inclusivity issue is something the TAG can drive. Many users on low-end mobile devices or on very poor internet connections are effectively locked out of parts of the modern web due the performance demands. As developers of web APIs it's easy to overlook these types of issues when working on high-powered hardware and solid connections. The TAG can have an influence by keeping performance as an important consideration during design reviews and when sharing best practices.

How do you see the TAG filling a gap in technical leadership?

It's understandable that the TAG is pulled in different directions, but I think design review is where TAG shines and where its main value lies. Latency of reviews has been a longstanding problem. Feature teams won't sit and wait forever for feedback, so taking too long is an impediment to the relevancy of the group. It's reasonable to think about where TAG can step up in terms of leadership in the W3C but this can't come at the cost of design reviews. When the TAG spends time wading into other matters it should keep a close eye on review latency and quality to make sure that focus on its core competencies isn't being lost.

What is the most important problem the Web Platform faces that the TAG could reasonably address?

Performance is major issue on the modern web. Web devs build sites on expensive hardware, and users try to access the content on slow devices, including low-end phones where much of the web can be so slow as to be unusable. The TAG needs to review standards changes with an eye towards making it easy for developers to write code that's performant by default and hard to write things that perform badly. The TAG must keep this as a priority when considering features individually, and considering how features will interact with other web APIs as well as frameworks and tools commonly used by developers.

What values will you bring to the TAG that other candidates might disagree with?

When there's a tension between moving quickly to ship a feature and moving more carefully with what some might call an overabundance of caution, I usually fall on the side of caution even if it means potentially taking more time to talk with developers and validate use cases. Shipping design mistakes can be so costly -- and I'm sure all the TAG candidates understand this -- but I've seen too much of how difficult it can be to remove something from the web platform once it's there. One way caution can manifest here is that I'm fond of shipping only the minimum-viable-API that solves the problem first, and adding more power or flexibility later if and only if it's found to be needed after the initial API has been out in the wild for a while.

What do you see as the role of the TAG in relation to regulators?

TAG's main value is technical. That's where they're best and where their time is best spent. There may be times when they can step up and help with understanding regulatory impact on an as-needed basis, but this should be limited; it's critical that they not lose focus on design reviews.

What are examples of W3C work that's not really in scope, and of work elsewhere that could be in W3C's scope?

We need to be open minded about what belongs in W3C. The number of different form factors on the web has grown rapidly and will continue doing so. We should welcome those who want to expand the web's scope, but make sure we're maintaining W3C's vision of one interoperable web for all. The TAG can help with technical aspects of this, ensuring that we're driving for convergence such that developers can still target a single common web platform.

What specific things did you accomplish in your previous TAG term, or plan to accomplish in your first TAG term?

My top priority will be getting involved in design reviews and driving down the time it takes for reviewees to get actionable feedback. I'll be looking for process changes that can make it more efficient, and will be prepared to spend plenty of my own time on reviews. I'll hold myself accountable to decreasing review latency as a goal for my first term.

What is your experience/expertise on browser-based front-end and server-backed or back-end standards?

My experience is mainly browser-based. I've worked to advance standards in the CSSWG, the Web Editing WG, in TC39 and WHATWG. I've been working on browser engines for over a decade, contributing to DOM, a11y, editing, CSS, JS, and more recently integrating AI into user-facing experiences. If elected, I look forward to working with and learning from folks on the TAG whose expertise lies elsewhere.

What organizational or technical skills will you bring to the TAG?

I've demonstrated the organizational skills necessary to advance web standards in several W3C working groups, and have helped drive consensus for features like CSS module scripts that required input from TC39, the WHATWG, and the CSSWG. I've built up a sense of what works well and what doesn't work well in these kinds of groups, which is not always the same across organizations; what works for a larger community might not be as helpful in a smaller group. I think this range of experience will be useful on the TAG.

In terms of technical skills, I've been working on the web platform for over a decade on several browser engines. I've shipped code in a wide range of browser components, from accessibility improvements in Blink, to rebuilding parts of the core DOM architecture in Trident, to user-facing features integrating generative AI in Edge. I have a deep understanding of what it takes to write code for the web platform, and I think this will give me a good intuition of the implications "under the hood" of standards that the TAG's reviewing.