Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3

2017-01-25 Thread Boris Zbarsky

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


Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3

2017-01-25 Thread Florian Rivoal

> On Jan 26, 2017, at 12:23, Boris Zbarsky  wrote:
> 
>  It will complicate attempts to add other, much higher value, features to 
> CSS, again both in terms of specification and implementation.

Could you elaborate on that? 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, or is there something specific with 
run-in that you think will get in the way? What kind of thing do you expect it 
to get in the way of?

> And again, I don't expect this mail to actually change anything.  But I felt 
> like I had to try one last time...

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.

—Florian

Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3

2017-01-25 Thread Boris Zbarsky

On 1/25/17 8:14 PM, fantasai wrote:

  * a 'run-in' layout model slightly less insane than the one proposed
in CSS2.0


I like the truth in advertising there.  ;)

I'd just like to reiterate my (longstanding, so unlikely to sway anyone) 
opinion that run-in, even in this "less insane" incarnation, introduces 
an amount of complexity to both specification and implementation that is 
wholly disproportionate to its value as a feature.  It will complicate 
attempts to add other, much higher value, features to CSS, again both in 
terms of specification and implementation.  I think we would be better 
off not adding this feature.


-Boris

P.S.  I don't see much point filing this as a github issue, since this 
really isn't the sort of comment that lends itself to discussion on 
github.  And again, I don't expect this mail to actually change 
anything.  But I felt like I had to try one last time...


[whatwg] [csswg][css-display] Updated WD of CSS Display L3

2017-01-25 Thread fantasai

The CSS WG has published an updated Working Draft of the CSS Display Module 
Level 3:

https://www.w3.org/TR/css-display-3/

This module describes how the CSS formatting box tree is generated from the
document element tree and defines the display property that controls it.
Additions since CSS2 include
  * a 'flow-root' value to create a block formatting context root (BFC)
  * a 'contents' value to discard the element's box but keep its children
  * inline list items
  * a 'run-in' layout model slightly less insane than the one proposed in CSS2.0

Significant changes are listed at:

  https://www.w3.org/TR/2017/WD-css-display-3-20170125/#changes

We anticipate this being the last draft before the transition to CR,
therefore this is the "last call" for comments.

Please review the draft, and send any comments to the CSSWG mailing list,
<www-st...@w3.org>, prefixed with [css-display] (as I did on this message)
or (preferably) file them in the GitHub repository at
  https://github.com/w3c/csswg-drafts/issues

For the CSS WG,
~fantasai