- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 17 Nov 2009 15:31:40 -0800
- To: www-style@w3.org
display: run-in
---------------
Worked through issues summarized in Bert's email
<http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html>
- RESOLVED: Accept proposal at the bottom of
http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html
- 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 =====
http://www.w3.org/2009/11/03-CSS-minutes.html
http://krijnhoetmer.nl/irc-logs/css/20091103#l-266
<RRSAgent> logging to http://www.w3.org/2009/11/03-CSS-irc
Present:
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
wrong.
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:
http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html
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
reasonably
<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
consistent.
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
conversation.
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
<option>s?
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
block.]
[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
behavior?
<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
::first-line.
<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.
<alexmog>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0Adiv%3Afirst-line%20%7Bcolor%3Agreen%7D%0D%0Ap%3Afirst-line%20%7Btext-decoration%3Aunderline%7D%0D%0Ab%20%7B%20display%3Arun-in%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%3E%0D%0A%3Cb%3Erun-in%3C%2Fb%3E%0D%0A%3Cp%3E%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20pa
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