RE: [css3-flexbox] Fixing the "replaced elements may or may not be inline" issue

± From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
± Sent: Wednesday, June 27, 2012 9:51 AM
± 
± On 6/27/12 12:18 PM, Alex Mogilevsky wrote:
± > These are real issues the code has to deal with, but there is no 
± evidence that it is a problem for performance.
± 
± It's a problem only insofar as it disables a certain class of 
± optimizations that are now possible and that some UAs do in fact 
± perform.  For example, right now it's possible to share computed 
± display data across nodes that have the same rules applying to 
± them, no matter what their parents are.  This is in fact a feature 
± that non-inherited properties in CSS have in common for the most 
± part, and is the basis for a number of optimizations at least in 
± Gecko.

This particular issue is now moot -- WG has chosen to make any child element of flexbox a flex item.

But the kind of arguments you bring here are exactly the kind of arguments we should have when implementation affects design -- what can and cannot be done with a particular design. It is much healthier and more useful than knowing that some code somewhere has a problem...

I was going to bring up "has layout" as an example of something that was good for implementation... but I hope we are no getting into a fight here and can just agree that when we refer to implementations, we explain what we've learned in a way that is applicable to all implementations, existing and future...

Alex

Received on Wednesday, 27 June 2012 18:15:21 UTC