- From: Øyvind Stenhaug <oyvinds@opera.com>
- Date: Tue, 21 Sep 2010 18:51:03 +0200
- To: "Peter Moulder" <peter.moulder@monash.edu>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, 21 Sep 2010 03:11:13 +0200, Peter Moulder <peter.moulder@monash.edu> wrote: > On Thu, Sep 16, 2010 at 05:41:34PM -0700, fantasai wrote: > >> | 2. Let B be the first of A's in-flow following siblings. If B > > Is the phrase "in-flow" defined in the editors' CSS2.1 text yet? Not yet from what I can see (I posted <http://lists.w3.org/Archives/Public/www-style/2010Sep/0314.html> a few days back, though). >> Replace >> # 2. C has a computed value for 'display' of 'inline' and it has >> one >> # or more children that inhibit run-in behavior. (Where >> "children" >> # includes both normal elements and :before/:after >> pseudo-elements.) >> with >> | 2. C is a non-replaced inline element and has one or more >> children >> | that inhibit run-in behavior. > > "Inline element" is not a defined term, to my knowledge. (For example, > it isn't mentioned in the proposal for issue 120 other than as text to > be removed from the spec.) If it is defined as "an element that > generates an inline box", then the "non-replaced" qualifier isredundant > (once issue 120's proposal text is in the spec) and I believe > is better removed. It's apparently taken to mean display:inline. > One possible issue concerns an interaction with a possible issue with > the new anonymous table object rules. In every user agent supporting > run-in that I've tested, an element with display:table-row inhibits > run-in. However, note that in each of these user agents, a > display:table-row element that's a child of a display:inline element > causes a block-level anonymous table box to be generated rather than > an inline-table as both the existing 17.2.1 and its draft replacement > stipulate. [Or at least, the table is placed on a line by itself > despite plenty of room.] Gecko creates an inline-table, but of course > doesn't support run-in. > > (The others that I tested were Konqueror, WebKit, and a 2005 version of > Opera. I haven't tested any version of IE or Prince, and I haven't > checked the most current version of any of them.) For what it's worth, in Opera 10.62 a display:run-in with a display:table-row child doesn't run in. (Also, given a table-row with a display:inline parent, the table-row gets an anonymous inline-table box, like in Gecko.) IE8 appears to do the same. > I can see the specified behaviour as desirable, I'm just noting that a > number of implementations do otherwise, apparently interoperably among > themselves. I think the specified behavior is ambiguous. <!doctype html> <title>table-row inside run-in</title> <span style="display:run-in"> run-in <span style="display:table-row">table-row</span> </span> <div>block</div> According to 17.2.1, whether the table-row box gets put inside an inline-table box or a regular table box depends on whether its "parent is an 'inline' box". Conversely, whether or not the outer span acts as display:block depends on whether the table-row element "generates an in-flow block-level box". So (interpreting the box parent part as best I can, and assuming "'inline' box" means inline box) it seems there are two ways of satisfying this condition: a) Run in and generate an anonymous inline-table b) Don't run in and generate an anonymous table -- Øyvind Stenhaug Core Norway, Opera Software ASA
Received on Tuesday, 21 September 2010 16:50:03 UTC