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, 20 Jun 2012 02:33:27 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <2C86A15F63CD734EB1D846A0BA4E0FC8315A9FA7@BY2PRD0310MB378.namprd03.prod.outlook.com>
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Wednesday, May 16, 2012 4:11 PM
± 
± The Flexbox spec declares any child of a flexbox that is a block or 
± inline-block (more or less - I won't get into the details) to be a 
± flexbox item, while inline elements instead get wrapped into an anonymous 
± item.  Unfortunately, replaced elements are display:inline, and may not 
± even be replaced at all in some circumstances (Firefox renders <img> as a 
± non-replaced inline when the image fails to load).

I don't understand why this is an issue. Yes, some elements change from inline to replaced when content is loaded. Layout has to take that into account, and possibly get updated once content is loaded.

All browsers that pass Acid2 test [1] already know how to deal with that.

Line 54 of Acid2 specifically tests for width and height not being applicable to <object> that has failed to load its data:

   	#eyes-a object[type] { width: 7.5em; height: 2.5em; } /* should have 
	no effect since that object should fallback to being inline 
	(height/width don't apply to inlines) */

Perhaps adding hard rules on display types for replace elements would enable some optimizations (although I am not sure what exactly), but the claim in this issue is not performance, it is consistence... But for consistence with how object fallback is treated elsewhere, flexbox should not have any special rules based on element tags. 

[1] http://www.webstandards.org/files/acid2/test.html


Alex
Received on Wednesday, 20 June 2012 02:34:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:55 GMT