Generate a subset of the Design Principles doc for web developers

[LeaVerou]

This is a spinoff from the discussion for #177. A lot of our design principles apply to developer code as well, not just spec authors. E.g. things like JS API design and naming are more broadly useful. It may be good to annotate these principles so that in the future we can generate a version of the design principles doc targeting web developers (akin to the subset of the HTML spec aimed at web developers).

[LeaVerou]

Thankfully, Bikeshed can do that really easily: https://tabatkins.github.io/bikeshed/#conditional

[LeaVerou]

@ylafon and I started going through the principles to see what might be relevant to web developers and what is not, we recorded our work so far in this google doc.

It's a shame that a lot of HTML principles that would be useful to web authors designing web components are not there yet.

[LeaVerou]

As discussed in today's breakout between @torgo @plinss @rhiaro @ylafon :
It appears there are often things brought to or discussed in the TAG that are essentially design principles for web developers exclusively, and do not apply to spec writers at all. Some examples:

• What should be the principles be about appropriate use cases for the canvas element? #369
• Some of the Guidelines for creating web platform compatible components
• And several other findings

Perhaps we should have a task force with prominent web developers to come up with a design principles document that targets web developers, which will not be a subset of the design principles, but a standalone document that will pull in some of the design principles.

[LeaVerou]

Btw we started working on this with @cynthia in the July 2022 F2F. We ran into some Bikeshed issues wrt conditional inclusion, but @tabatkins will fix them.

[eemeli]

Does the end result need to be a subset of the Design Principles doc, or could it include additional concerns that aren't relevant for the development of the platform itself?

In particular I'm thinking about a section like "Don't make future development of the platform more difficult", which could e.g. guide library developers away from extending the base JS Object and Array with method names that can't then easily be used when extending the JavaScript language itself.

[LeaVerou]

Yup, check out my comment above which talks about this very thing (having additional principles that are only present in the web developer version): #268 (comment)
The one you mention about built-ins is also a good candidate for that!

[torgo]

So we discussed on today's call and reiterated the consensus that this document is primarily aimed at web platform developers - that is, those designing new technologies for the web platform - and that some of the principles may be additionally useful for web developers. In general, principles should be considered in scope if they affect future decisions about the design of web platform features. For example, the canvas principle suggested above could be in scope under that thinking, but we should also not make this a comprehensive list of all principles to take into account when writing all code.