# [18:16] <TabAtkins> 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.

# [18:16] <TabAtkins> Bert: Also, it clarifies that run-in comes before any pseudoelements of the following sibling, so element order is retained.

# [18:17] <TabAtkins> 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.

# [18:17] <TabAtkins> Bert: Frex, an <h2> followed by an <h3>. Perhaps the content between the two headers is temporarily suppressed.

# [18:20] <TabAtkins> Bert: The definition is in terms of elements that are incompatible with run-in behavior; elements that inhibit run-in.

# [18:20] <TabAtkins> Bert: If one of the children inhibits run-in, the run-in must go block.

# [18:20] <TabAtkins> 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.

# [18:21] <TabAtkins> 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.

# [18:21] <TabAtkins> Fantasai: You can combine a,b,d and say "all children, including :before and :after".

# [18:27] <fantasai> 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.

# [18:27] <TabAtkins> tantek: How many implementors have some kind of run-in.

# [18:38] <tantek> anonymous table pseudoelements and anonymous table-row pseudoelements - that get auto-generated when an element is set to display:table-cell outside of any kind of table context for example

# [18:38] <TabAtkins> Bert: Back to replaced elements. Proposal is to clarify definition in section 3.1, where it says "out of scope"

# [18:39] <bz> tantek: but yes, testcases that are clickable (or at least reftest-like) will happen

# [18:39] <TabAtkins> Bert: Definition of replaced elements in 3.1 says that content it 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.

# [19:12] <TabAtkins> 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.

# [19:17] <TabAtkins> 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.

# [19:18] <TabAtkins> 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.

# [19:18] <TabAtkins> Bert: I think deciding that is progress already. At least we know it has to be done.

# [19:19] <TabAtkins> RESOLVED File an issue to go through the spec for this. Either Elika or Bert will take care of this. At least clarify/define the "ancestor box".

# [19:36] <TabAtkins> 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.

# [19:36] <TabAtkins> fantasai: If you have ::first-line{color:green;} on the ancestor, should it affect the run-in?

# [20:52] <Bert_lap> DavidS: So we have 'historical' and 'correct' (as keywords?).

# [20:53] <ChrisL> we don't want to encourage overiding of images, so the old proposal is not very good. Tantek's current wording is better

# [20:53] <Bert_lap> Tantek: Two values for reintroduced color-profile: default (as per Beth) and srgb, defined the way 'auto' used to be defined.

# [20:53] <ChrisL> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."

# [20:59] <tantek> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."

# [20:59] <Bert_lap> ACTION on Singer check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.