- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 26 Jan 2017 00:10:22 -0500
- To: Florian Rivoal <florian@rivoal.net>
- Cc: WHAT Working Group <whatwg@whatwg.org>, public-review-announce@w3.org, "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>
On 1/25/17 10:48 PM, Florian Rivoal wrote: > Is it a general argument that adding more things to the platform always makes it harder down the road to add more things due to having to figure out more interactions It's not a general argument in this case. It's a specific argument. For example, adding any new display type has to consider how it interacts with run-in. Adding anything that rearranges things in terms of layout (e.g. shadow DOM, flexbox, grid, etc) has to consider how it interacts with run-in and whether the result makes any sense. Adding any structural pseudo-elements, have to consider run-in (note that the run-in spec already has to specify interactions with ::marker and ::before). That's on the specification side. On the implementation side, run-in makes all sorts of element insertion/removal either slow or complicated or both, because you have to deal with it affecting the run-in situation. > Who knows. Some of us are new enough to this discussion that we may not know of all the arguments that had been presented against it in the past. Anyway, what I suggest is writing _very_ thorough run-in tests, including all the dynamic mutation cases. Something akin to what you see in https://bugzilla.mozilla.org/attachment.cgi?id=421975 but targeting the current spec. I should note that at the point when I wrote those tests, they mostly failed in all implementations; a bunch of them crashed in various implementations. I'd hope the new text is at least easier to implement sanely, but I'm not holding my breath too hard on it... -Boris
Received on Thursday, 26 January 2017 05:10:57 UTC