W3C home > Mailing lists > Public > www-style@w3.org > November 2009

[CSSWG] Minutes and Resolutions TPAC F2F 2009-11-03: display run-in issues

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 17 Nov 2009 15:31:40 -0800
Message-ID: <4B03325C.4020605@inkedblade.net>
To: www-style@w3.org
display: run-in

   Worked through issues summarized in Bert's email

   - RESOLVED: Accept proposal at the bottom of

   - RESOLVED: Add "The content of replaced elements is not considered in the
              CSS rendering model." to the definition of "replaced element"

   - Filed http://wiki.csswg.org/spec/css2.1#issue-142

   - RESOLVED: Run-ins inherit from their document parent, not their sibling.
               It is explicitly undefined in 2.1 what happens with parent/sibling
               ::first-lines and run-ins.

====== Full minutes below =====


<RRSAgent> logging to http://www.w3.org/2009/11/03-CSS-irc

   Tab Atkins
   David Baron
   Bert Bos
   Tantek Çelik
   Arron Eicholz
   fantasai Etemad
   Sylvain Galineau
   Daniel Glazman
   Chirs Lilley
   Peter Linss
   Boris Zbarsky (Mozilla, via telephone+IRC)

display: run-in

* bz calls
<Zakim> +bzbarsky
<Zakim> +SteveZ
Scribe: TabAtkins

   <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
   Bert: As a reminder, general idea of runin is a heading followed by a
         paragraph, and you want to display the header inline, perhaps
         with styles to make it stand out.
   Bert: Another application is a dl where the dt runs into the dd that
         follows rather than above it.
   Bert: First issue: When can this happen?  When can the run-in element
         become inline in the next element, and when not?
   Bert: This depends on the element itself, and what follows.
   Bert: There must be a block afterward, for it to run into, and it
         can't contain blocks.
   Bert: Original definition wasn't precise.
   Bert: *points to email*
   Bert: The first link goes to page holding conditions for element
         following the run-in.
   <bz> which page are these links on?
   Bert: It must have a following sibling.
   Bert: Ignore anything that's not in flow.
   <bz> ah, I see, archives
   <bz> ok
   Bert: Such as floats, display:none elems, etc.
   Bert: At top of the message, first point is about run-in itself.
         Come back to that later.
   Bert: Point 2!
   Bert: You need to have an element after the run-in that is either
         block or list-item, or else the element displays as block.
   Bert: Also, it clarifies that run-in comes before any pseudo-elements
         of the following sibling, so element order is retained.
   Bert: There was discussion about whether block+list-item was sufficient.
         Frex, would run-in+run-in+block causes the two run-ins to run
         together, or would the first make the second a block, and then
         the second doesn't run in.
   Bert: Frex, an <h2> followed by an <h2>.  Perhaps the content between
         the two headers is temporarily suppressed.
   fantasai: What about <h2> followed by <h3>?
   Tantek: You can just put several run-ins in a row, right?  And they'll
           all run in?
   Bert: No, not by current language.  The first would go block, the
         second would run-in.
   Bert: The dt case makes a stronger example.  You may want multiple
         <dt>s applying to the same <dd> to run together.
   Bert: But I think the heading case is strong enough that we don't
         want to make multiple consecutive run-ins go together.

   Bert: Point 1! Conditions on the run-in, and what children it can contain.
   Bert: You have to look not only at children, but at all in-flow descendants.
   Bert: The definition is in terms of elements that are incompatible with
         run-in behavior; elements that inhibit run-in.
   Bert: If one of the children inhibits run-in, the run-in must go block.
   Bert: Again, ignore out-of-flow children.  But if one of the remaining
         children is block/list-item/table/run-in, the run-in cannot go inline.
   Bert: The remaining children must be inline, so recursively descend
         to look for children with block/list-item/etc.  If there are no
         in-flow children that inhibit, the element can run-in.
   Fantasai: You can combine a,b,d and say "all children, including :before
             and :after".
   Bert: Yeah, that's already done.
   Bert: Rewritten definition at bottom of email that has only two clauses.

   fantasai: Can we say block-level element or display type, so we're not
             tying things to a specific list?
   fantasai: The more we can do that, the better we'll be in the future
             when we introduce new types.
   tantek: That's mostly good, but it might also causes problems if a
           future display type specially should interact with run-in.
   fantasai: More things should prevent run-in than less.
   plinss: It's far more likely that something new would inhibit run-in
           than allow it.
   Bert: I haven't looked into that specifically, to see if the definition
         of "block-level" would work.
   fantasai: Yeah, we've just had a lot of problems with inline-blocks,
             because a lot of specific lists didn't take it into account.
   tantek: That's a good argument.  inline-block may act like a block
           *or* inline.
   fantasai: What we need is the ability to say something is a block on
             the outside, or a block on the inside.
   tantek: Yeah, but we didn't even know that until we made inline-block.
           We didn't realize the abstraction was even necessary.
   fantasai: You have the same problem with tables and table-cells.
             Table cells act like a block container, but it's not like
             a block on the outside.
   fantasai: I don't want to introduce a new display-type and say "Let's
             go audit CSS2.1 and fix all the places."
   fantasai: But I think for the new display types, our abstractions are
             good enough to talk about.
   plinss: If we have a new list, we're *guaranteed* to update it.  An
           abstraction *may* need to be updated.
   tantek: I'd rather have things fail obviously than subtly.
   fantasai: It's never obvious.  People look at the list of things that
             are allowed, and just assume that it's still correct.
   dbaron: We do have the terms "inline-level" and "block-level" elements,
           which can work as the excluded/included lists.
   Peter: If we had an include list and an exclude list, then people would
          notice "oh, it's missing". But if we have an include list and
          "everythingg else" is excluded, nobody notices that something's
   dbaron: I've noticed the list of Bert's seems to be wrong.  A run-in
           containing a run-in is inhibited.
   Bert: That's what is says.
   dbaron: Sorry, yeah.
   <bz> That was updated
   <bz> http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html
        has the right text

   tantek: How many implementors have some kind of run-in.
   smfr: Webkit has basic run-in behavior, but sort of broken.
   dbaron: I think everyone but Moz implements, but they all do it differently.
   tantek: And presumably the test-cases that demonstrate lack of interop
           is published?
   TabAtkins: Yeah, I think Boris published those.
   tantek: It would be good to get a pointer for that.
   <Bert> -> http://www.w3.org/Style/Group/css2-src/visuren.html#block-boxes
             Definition of "block-level elements" (9.2.1)
<Zakim> -SteveZ
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Sep/0018.html
   dbaron: I think Boris is waiting to publish the test-cases until he's
           sure that they're right.
   tantek: It's useful to have real examples, not just specified abstractly.
   <sylvaing> correction; a testcase from bz:
   tantek: It may turn out that once we see a real example of the prose text,
           it's not what we wanted.
   Bert: I don't have a preference for a list or a "block-level" definition.
   Bert: There's some subtlety in that it would refer to run-ins and say
         "some of the time".
   Bert: Verdict on the definition?
   fantasai: I think I'd prefer it to say "block-level elements", but I
             don't need to block this on this.  We can raise a separate
             issue for it.
   Bert: So that sounds like proposal #1?
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html
   <fantasai> accept text at bottom
   <bz> http://lists.w3.org/Archives/Public/www-style/2009Aug/0594.html
   RESOLVED accept text at bottom.

   Bert: Next issue.  Should still be easy.
   Bert: What do to with replaced elements?
   <bz> I assume we decided that behavior is ok?
   Bert: Maybe a wider issue.  In my implementation replaced elements are
         always empty.
   fantasai: No.
   Bert: I know what I think.
   fantasai: In the document tree it's not necessarily empty: textarea,
             object, etc.
   Bert: That's the issue.  Do you look in the document tree, or just in
         the things considered for rendering?
   Bert: In replaced elements, the children are thrown away.
   fantasai: And form elements may or may not be replaced, depending.
   Bert: Let's look at the proposal.  There's proposed text to clarify.
   Bert: Section 3.1
   Bert: Do we consider replaced elements as empty so we never look at its
         children, or do we look at the children of the replaced element?
   fantasai: Replaced elements are defined as children being outside of
             the scope.
   fantasai: Whether or not it has children doesn't matter
   Bert: So that seems to mean that we don't have to look at them.
   fantasai: Right, but that doesn't mean it doesn't *have* children

   <dbaron> bz, doesn't the table-cell have a block wrapping it in that case?
   <bz> dbaron, it doesn't
   <bz> dbaron: or rather....
   <bz> dbaron: the interaction is interesting
   Boris: I think the behavior is well-defined for if the run-in is into
          a table cell or not.
   Boris: It's a little weird because if it has a table child it can't
          run in, but I think it's all consistent.
   Boris: It's something to be careful with.
   <tantek> sylvaing thanks - http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html
            helps but would prefer actual live test cases we can quickly
            click and run across browsers/machines.
   dbaron: I would think that if it has any table stuff in it, except
           inline-table, it should inhibit run-in.
   Bert: But if you have a table-cell inside an inline element, it
         automatically generates an inline table.
   tantek: Did we ever define pseudo-elems for the generated wrappers for tables?
   ?: No.
   Boris: Anonymous blocks have to have something to do with what's
          going on here.
   dbaron: I don't think there's an inconsistency between boris's two cases,
           because it only occurs into inlines and not other things.
   <dbaron> bz, I don't think we're inconsistent between those two cases,
            since the recursion in Bert's proposal only recurs into inlines
   Boris: The issue raised here was addressed in Bert's proposal, and should
          both result in the run-in running in.
<Zakim> +SteveZ
   <tantek> anonymous table pseudo-elements and anonymous table-row
            pseudo-elements - that get auto-generated when an element is
            set to display:table-cell outside of any kind of table context
            for example

   <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0030.html
        has another test
   <bz> tantek: but yes, testcases that are clickable (or at least reftest-like)
        will happen
   <bz> tantek, my current estimate is we need ~100ish tests to test all
   <tantek> bz - thanks much - that will help a lot
   <tantek> ouch!
   <bz> tantek, dynamic changes make it extra fun.  ;)
   <bz> tantek, e.g. webkit gets confused if you change textnodes between
        the run-in and the block from whitespace to not or vice versa
   <tantek> bz - even just a few live static tests to start with, even
            if "exploratory" in nature (i.e. not knowing exactly what
            *should* occur) would help answer some of the design questions.
   <tantek> bz - agreed, things are much more difficult when dynamic.
   <tantek> useful to at least get the static cases figured out first
            though right?
   <bz> yeah, no point testing dynamic much till static is defined
   * tantek implemented some degree of CSS2 display:run-in in IE5/Mac about
            10 years ago.
   * tantek curious how many cases he got right/wrong.
   <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html
        has an attached testcase
   <bz> tantek, with lots of different cases tested
   <tantek> http://lists.w3.org/Archives/Public/www-style/2009Jul/att-0025/test.html
            is a good start
   <bz> tantek, sadly, without much description of what _should_ happen
   <tantek> bz - presumably red means wrong?
   <bz> tantek, sorry, no.  color is just used to tell apart the various blocks
   <bz> tantek, I should have used purple or blue.....
   <bz> tantek, all the right/wrong is in whether things run in or not.
        So whether they're on one line or two lines
   <bz> tantek, and which is contained in which border
   * bz gathered this was normal, yes.  ;)

   Bert: Back to replaced elements. Proposal is to clarify definition in
         section 3.1, where it says "out of scope"
   Bert: Definition of replaced elements in 3.1 says that content is out
         of scope.  I want to clarify that you don't have to look inside
         a replaced element to determine if it inhibits run-in.
   fantasai: I disagree with Bert's proposed text
   Bert: Proposal is that document tree is empty for CSS.
   Bert: you disagree, fantasai?
   fantasai: Yeah, in the document tree the element isn't considered empty,
             and for selectors and such you don't *want* it to be empty.
   fantasai: We'll be referring back to this later, and you can't screw
             around with the document tree for future extensions.
   Bert: But that's the definition of replaced.  The content that was there
         no longer appears.
   fantasai: But what about inline SVG?  There's obviously children there.
   Bert: But it looks empty for CSS.
   fantasai: You're talking about the rendering tree, which is different
             from the document tree.
   Bert: There is no rendering tree.
   <glazou> "There is no rendering tree" -- Bert 2009-11-03
   fantasai: If we can reword it so we don't say the element is empty,
             I may be happy with it.
   Bert: We may avoid 'empty', but need to say that the contents of a replaced
         element is ignored for CSS.
   Fantasai: Sure, just don't call it empty.
   tantek: so it's opaque
   Bert insists that it's empty
   <bz> I just have nothing to say on this; the behavior we want is obvious;
        the only question is how to define it.
   <fantasai> Let's say I have a <p> element with an <a> inside it
   <fantasai> I write a selector for <p>s that have <a>s inside them using
              Selectors 4
   <fantasai> then I say { content: url(image.png); }
   <fantasai> That makes it replaced
   <fantasai> which makes the selector no longer apply
   <fantasai> because it's replaced
   <fantasai> and now it's empty!!
   <bz> so...
   <bz> it's even simpler
   <bz> Say I have an HTML <img>
   <bz> that I style with :empty
   <bz> img:empty { border: 10px solid purple; }
   <tantek> fantasai - no selector feedback loops
   glazou: But why would this no longer apply?
   fantasai: Because we say that it's a replaced element now, and thus it
             would be empty.  No selector can target the contents anymore.
   dbaron: We should fix this issue in the run-in section, not by changing
           the definition of a replaced element.
   TabAtkins: fantasai is saying that run-ins can ignore children of replaced,
              but we shouldn't just say that the children don't exist.
   Bert: We don't care about the DOM, we care if CSS says they exist.
   fantasai: But they do exist.  You can select on them.
   Chris: Ignoring them and making them disappear are two different things.
   Bert: I just want to clarify that we're using a definition is internally
   Bert: Per CSS, whatever's inside a replaced element simply isn't there.
   <dbaron> object:empty only matches some of the time
   fantasai: Let's just say that you can't do anything with it, not say
             that it isn't there.
   dbaron: You're saying the object:empty should match *all* of the time.
   Bert: Yeah, it should say that.
   glazou: When doesn't object:empty work?
   dbaron: When <object> has fallback, frex.
   glazou: Object has children in the DOM.
   Bert: If it's replaced it has no children.
   glazou: It does.
   Bert: Does not.
   <bz> is too, is not
   Chris: We're going in circles.  Chairs?

   tantek: How do you assign different styles to an object based on whether
           the object loads or not.
   tantek: This decision is made before CSS happens.
   tantek: How do you decide?
   TabAtkins: :incomplete?
   fantasai: There was some discussion of this on www-style
   tantek: That's an old thing, right?
   fantasai: Nah, it's relatively recent. But it's out of scope of this

   Bert: Let's make it clear that you don't look at the DOM content of
         replaced elements.
   Bert: We just need to exclude children from being looked at for this.
   Bert: So how do we phrase this?
   <fantasai> "The children of replaced elements are not considered in
              the CSS rendering model."
   <fantasai> for 3.1
   Bert: But that sounds like a contradiction.  Replaced elements don't
         have children.
   glazou: Nah, everyone agrees that they do.
   dbaron: So if a <select> is a replaced element, browsers can't render
   fantasai: They're not unrenderable, just CSS won't see them.  Whatever
             draws forms will.
   Bert: In CSS1 form elements were defined as replaced, but we've
         gradually been removing that.
   tantek: And in CSS3, <select> is appearance:popup-menu.
   <tantek>  http://w3.org/TR/css3-ui
   glazou: Bert, do you have a counterproposal, since you're blocking
           this sentence?
   Bert: Can we say that the "content", not "children"?
   fantasai: Okay.
<Zakim> -SteveZ
   <fantasai> "The content of replaced elements is not considered in the
              CSS rendering model."
   Bert: That's fine.
   Chris: So what about <foo-img src=bar><tooltip>baz</tooltip></foo-img>.
          Does this mean we can't ever style the tooltip?
   ChrisL: I think the real answer is we *can* target and style the tooltip.
           Maybe it has display:tool-tip or whatever, but it should be there.
   Bert: How do you display that image?  Does it replace the contents?
   ChrisL: Ys.
   * sylvaing expects an :nth-illegitimate-child() proposal by end of day
   Bert: Defined by the document format?
   ChrisL: Yes.
   <annevk> XBL!
   Bert: Then it has no children.
   ChrisL: But we may want to do so.
   <dbaron> So which case of run-in behavior are we trying to affect, anyway?
   Bert: Then we'll need to change CSS to do so.
   Bert: When we use CSS3 Generated Content, we'll be able to do so.
   <dbaron> The definition for whether things run in seems fine for
            replaced elements already.
   Bert: If the document language says how to display it, we can no longer
         say anything about it.
   ChrisL: I was trying to get away from <object>, because the children
           there are clearly alternates.  I wanted an example where the
           children are used alongside the content.
   glazou: What Chris is saying is that this restricts new language design.
   <fantasai> http://www.w3.org/TR/CSS21/intro.html#processing-model
   ChrisL: I'm happy to say "formatting structure" rather than "rendering tree".
           It's in *that* that replaced elements have no children.
   ChrisL: The point is that it's not the source tree, so we don't have
           to *pretend* that the document-tree has no children.
   Bert: Ok.
   <dbaron> Instead, I propose changing:
   <dbaron> C has a computed value for 'display' of 'inline' and it has one or
   <dbaron>       more children that inhibit run-in behavior
   <dbaron> to:
   <dbaron> C has a computed value for 'display' of 'inline', is non-replaced,
                  and has one or more children that inhibit run-in behavior
   <dbaron> and changing:
   <dbaron> If A has any children
   <dbaron> to:
   <dbaron> If A is non-replaced and has any children
   glazou: We were at 3.  Accept the proposal with Bert's new text?
   RESOLVED Accept Bert's new text for issue 3 in the run-in email

   <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
   Bert: Next issue.  What is the containing block of the run-in and children?
   Bert: Every box needs a containing-block.  If the run-in goes inline,
         which box is containing it?
   Bert: 10.1 supposedly defines the containing block for all elements.
   Bert: In my reading, it does, and the definition there only follows the
         document tree.  It doesn't look at the visual place it appears,
         just ancestors in the document tree.
   Bert: So the run-in will have it's normal parent as the containing block,
         not the sibling that it's flowing into.
   Bert: Do we want that, or do we want the sibling to be the containing block?
   fantasai: The second one.
   fantasai: Frex, width:50% on the run-in's inline-block child should be
             taking its width from the sibling it's flowing into.
   sylvain: So it would get its color, frex, from its parent, but other
            things would come from the eparent.
   fantasai: Yeah, we do something similar with abspos.  The containing
             block may be an ancestor far up, even though it still
             inherits from its parent.
   Boris: To be clear, I think we want to say this...
   Boris: The other question is if you have floating children of the run-in,
          then what happens with those?  Which block is the containing block
          for those floats?
   Boris: And with abspos children of the run-in.
   fantasai: For floats it should be the same - the containing sibling.
   fantasai: For abspos children, I have no opinion.  I'm happy to go with
             whatever's easiest.
   TabAtkins: For consistency, I'd prefer abspos to do the same thing.
   Bert: It seems most are in favor of taking the sibling as the containing
         element for run-in and all children?
   <bz> yay!  ;)
   RESOLVED The sibling that the run-in runs into is the containing block
            for it and all children.

   Bert: Next issue.  Boris believes 10.1 is ambiguous.  It says "ancestor box".
   Bert: In my reading it's just the ancestor.  But Boris thinks it might
         refer to the formatting structure, and so it may refer to the
         ancestor in the formatting structure.
   Bert: So should we go through the spec and look for "ancestor box",
         "parent box", etc and replace it with something umabiguous, so
         we're clear if it refers to the content or the visual structure
         or containing block.
   Bert: I don't personally think it's necessary.  I read "ancestor box"
         as referring to the document structure.
   Bert: But if others think it's ambiguous, we have to go through the
         text and replace those occurances.  Thoughts?
   fantasai, sylvain: I always interpreted that as being formatting structure.
   plinss: Especially since it says "box", not "element".
   ChrisL: Yeah, it's ambiguous, especially frex for abspos.
   dbaron: Why is "ancestor" clearly one tree and not the other?
   dbaron: I think it's clear that it's in the formatting tree.
   ChrisL: If you have an abspos element, is the ancestor the whole document?
   Bert: That's the ICB, not an ancestor.
   plinss: The fact that we're having the conversation means it's ambiguous.
   Bert: You can say that about any line in the spec.
   Bert: It's a bit of work to go through the spec.
   ChrisL: I'm okay with saying it's unambiguous if someone explains it clearly.
   plinss: If it's supposed to be the box of the ancestor, say "box of
           the ancestor".
   fantasai: For run-ins, we don't want to look up the element tree here.
             We want to look up the formatting tree.
   fantasai: Frex, with several runs of nested spans around an abspos, is
             the run-in's containing block (sibling) relpos?  That's a
             formatting ancestor, not a document ancestor.
   fantasai: We don't want to make this decision unless we're careful
             about run-ins?
   Bert: Are you saying that if we keep it how it is we don't need to
         make a change?  I think you're going opposite from me.
   Bert: I think we'll have to rewrite 10.1 anyway, at least an extra clause.
   fantasai: I'm saying for children of the run-in, frex when they're
             looking for fixpos/relpos ancestors, they're going up the
             formatting tree and will find the run-in's containing block.
   fantasai: So I guess file this as an issue and deal with it later?
             Somebody has to go through and look through the whole spec
             and figure out what we're doing all over the place.
   Bert: I think deciding that is progress already.  At least we know it
         has to be done.
   RESOLVED: File an issue to go through the spec for this.  Either fantasai
             or Bert will take care of this.  At least clarify/define the
             "ancestor box".
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-142

   Bert: Now the famous ::first-line issue.
   Bert: Consider a run-in displayed inline in the sibling.  The sibling
         has a ::first-line pseudo.  Where does the first line get its
         properties from?
   Bert: Imagine the run-in is short, so half of the first line comes from
         the run-in, and half comes from the content.
   Bert: There are 3 or 4 reasonable ways of creating that inheritance tree.
   Bert: Tab's proposal was to avoid the whole issue and just create ::run-in.
         Then ::first-line doesn't apply to run-in, just the content from
         the paragraph.
   Bert: But we don't have that pseudo in CSS2, so it's quite a change.
   fantasai: I propose just following the document tree.
   plinss: I don't know if that makes stylistic sense.
   plinss: I don't think a run-in should pick up any style from the first
           line of the paragraph that it's running in.
   Bert: What about background?
   fantasai: Run-in should be included in ::first-line in the box model,
             but shouldn't inherit from ::first-line.
   [Tab explains the issue ::run-in is trying to solve: being able
    to style the element differently when it runs in than when it is
   [Tantek says you typically use run-in when you're pretty sure
    the element *will* run in.]
   [tantek and fantasai point out that you can't have a
    pseudo-class match depending on display type]
   Peter: but you could have a pseudo-element
   Peter: that selects its contents
   RESOLVED: run-ins inherit from their document tree parent
   dbaron: what about the common ancestor's ::first-line?
   dbaron: I don't think we want to ignore the paragraph's ::first-line
           but honor the ancestor's
   fantasai: Yeah, we should either ignore all ::first-lines for run-in
             inheritance, or honor all of them
   <fantasai> bz, can you type in your example pls? :)
   <bz> <div style="color: blue">
   <bz>   <div style="display: run-in">Text</div>
   <bz>   <div style="color: yellow"></div>
   <bz> </div>
   bz: If there are no ::first-line styles, then we've just decided the
       run-in is color: blue
   bz: If there is a ::first-line style on the second <div>, what happens?
   bz: If that ::first-line style also sets color: orange (or color: yellow),
       what happens?
   plinss: I think the run-in should inherit from its parent always.  The
           remaining content of the sibling on the first-line coms from
           the sibling's ::first-line, the run-in doesn't care.
   fantasai: If you have ::first-line {color:green;} on the ancestor,
             should it affect the run-in?
   plinss: yes.
   plinss: You're in effect getting two separate first-line boxes.
   TabAtkins: Is this actually any more difficult than current ::first-line
   <bz> of course
   dbaron: I don't think we implement the full ::first-line behavior anyway,
           so we can't really say.
   <bz> first-line + inheritance is just a bad scene, no matter what
   fantasai: counterproposal is to ignore ::first-line for run-ins always.
   * annevk still likes the idea of dropping run-in :)
   TabAtkins: So the sibling's ::first-line never affects the run-in.
              The difference is whether the ancestor's ::first-line applies
              to the run-in or not.
   dbaron: I think it's more consistent to say the run-in always ignores
   <Bert> [Fantasai copies bz's mark-up to the flipover and starts drawing...]
   <bz> annevk, can we drop ::first-line too?  ;)
   <annevk> I wouldn't mind :)
   fantasai: Does ::first-line have values for properties that aren't explicitly
             set on it?
   alex: I've just tried this in several browsers.
   alex: In IE8, the run-in does inherit from parent first-line, but not
         sibling first-line
   alex: FF and Opera it doesn't make it a run-in.
   * annevk ... the way it works with inheritance and how it may have to
            depend on the property is just too hairy
   alex: In Safari, the ancestor style is ignored, and the run-in gets the
         sibling's ::first-line.
   dbaron: Just punt it as undefined and move on?
   fantasai: 2 things we can leave undefined.
   fantasai: 1 is inheritance for run-ins in general.  2 is inheritance
             for run-ins just in ::first-line.
   RESOLVED Run-ins inherit from their document parent, not their sibling.
            It is explicitly undefined what happens with parent/sibling
            ::first-lines and run-ins.
   <bz> mmm yummy undefined
   RESOLVED ADDENDUM: Undefined for CSS2.1, maybe for CSS3 (Box Module may
                      be able to take care of it.)
   * bz looks forward to implementing "the simplest thing that doesn't crash"
   <fantasai> :)
   * bz has no outstanding run-in issues
   <fantasai> yay!
   <bz> well, other than the fact that I have to write the code... ;)
   <tantek> http://wiki.csswg.org/planning/tpac-2009
  * bz is going to sign off, since we seem to be done with run-in
   <ChrisL> bz, yes we are on break now
   * bz hangs up
Received on Tuesday, 17 November 2009 23:32:23 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:41 UTC