W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Wed, 27 Jun 2012 18:14:41 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <2C86A15F63CD734EB1D846A0BA4E0FC8315D21E5@CH1PRD0310MB381.namprd03.prod.outlook.com>
± 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...


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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC