Aside: anyone who presents finely detailed aspects of a design they just implemented in their runtime (and presumably are about to ship) is a metaphorical danger to themselves and others. They're wrong but they don't know how (yet).
-
Show this thread
-
What this highlights is that the design phase of a feature requires malleability. Ideas need to be cheap enough to throw away. Over-tightly describing the details of a system creates pressure in the opposite direction: it increases the cost of change.
2 replies 1 retweet 5 likesShow this thread -
Specs are also written with a different audience than high-level design docs: high-level designs outline the problem being solved (and for whom), describe how the proposed design compares to alternative approaches, and close the loop by showing how the proposal satisfies needs.
1 reply 0 retweets 1 likeShow this thread -
Detailed specs, OTOH, describe to fellow implementers how the internals of a proposed design are rationalised against the spec-world. Nobody actually lives in spec-world, it turns out...yet like Klingon or Elvish, the language of it is beguiling to some and highly specific.
1 reply 0 retweets 2 likesShow this thread -
And that specificity is needed. If something doesn't make spec-world sense, it'll eventually be modified such that it does (sometimes in a breaking way; which is bad)
1 reply 0 retweets 1 likeShow this thread -
Which is the long way of saying that you need web developers to understand your design so they can pass judgement on whether or not it actually solves a real problem they have *before* investing the time to translate the high-level sketch into Specish (Specklish? Specese?)
2 replies 0 retweets 2 likesShow this thread -
The role of the Explainer is to be that pre-spec design doc. It's an essential part of a well-functioning design process and something we look for feature designers to produce at the
@w3ctag because it helps us review the spec's *intent*.1 reply 1 retweet 3 likesShow this thread -
This, incidentially, is part and parcel of why you're seeing so many new web specs lead with this sort of high-level, end-to-end description of their functionality: https://github.com/WICG/page-lifecycle … https://github.com/WICG/web-locks https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit … https://github.com/WICG/BackgroundSync/blob/master/explainer.md …
1 reply 1 retweet 3 likesShow this thread -
Well-written Explainers include loads of sample code and zero WebIDL. This makes folks most-fluent in Specish uncomfortable, but it's the correct choice for all of the previously discussed reasons. IDL doesn't tell a web developer anything about the system; sample code *does*.
2 replies 2 retweets 5 likesShow this thread -
Because we don't yet (generally) implement DOM in JS, which means a shorthand for defined coercion semantics helps to drive late-stage interop.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.