SV_MEETING_TITLE -- 03 Nov 2009

<plinss> rrsagent make logs public

Run-ins

<dbaron> bz, conference code is above^

<TabAtkins> Scribenick: TabAtkins

<Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html

<bz> how do I mute myself?

<bz> via the phone system?

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.

<bz> aha, nice

Bert: Another application is a dl wheree the dt runs into the dd that follows rather than above it.
... First issue: When can this happen? When can the run-in element become inline in the next element, and when not?
... This dpeends on the element itself, and what follows.
... There must be a block afterward, for it to run into, and it can't contain blocks.

<bz> mmm

Bert: Original definition wasn't precise.

<dbaron> bz, can't here bert?

<bz> I can't make out any of it

<dbaron> hear

<bz> it's very quiet and pretty noisy

Bert: *points to email*

<bz> but only when speaker is talking

<bz> aha

<bz> this is better!

<bz> yes!

<bz> much better

Bert: The first link goes to pag holding conditions for element following the runin.

<bz> which page are these links on?

Bert: It must have a following sibling.
... Ignore anything that's not in flow.

<bz> ah, I see, archives

<bz> ok

Bert: Such as floats, display:none elems, etc.
... At top of the message, first point is about run-in itself. Come back to that later.
... Point 2!
... You need to have an element after the run-in that is either block or list-item, or else the element displays as block.
... Also, it clarifies that run-in comes before any pseudoelements of the following sibling, so element order is retained.
... 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.
... Frex, an <h3> followed by an <h3>. Perhaps the content between the two headers is temporarily suppressed.

<fantasai> 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.
... The dt case makes a stronger example. You may want multiple <dt>s applying to the same <dd> to run together.
... But I think the heading case is strong enough that we don't want to make multiple consecutive run-ins go together.
... Point 1! Conditions on the run-in, and what children it can contain.
... You have to look not only at children, but at all in-flow descendants.
... The definition is in terms of elements that are incompatible with run-in behavior; elements that inhibit run-in.
... If one of the children inhibits run-in, the run-in must go block.
... 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.
... 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.
... 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?
... 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 eoutside, 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.
... I don't want to introduce a new display-type and say "Let's go audit CSS2.1 and fix all the places."
... 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.

<bz> That was updated

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> http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html has the right text

<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.

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> Definition of "block-level elements" (9.2.1)

<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 exampl 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.
... There's some subtlety in that it would refer to run-ins and say "some of the time".
... 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.
... 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?
... In replaced elements, the children are thrown away.

fantasai: And form elements may or may not b replaced, depending.

Bert: Let's look at the proposal. There's proposed text to clarify.
... Section 3.1

<dbaron> bz, doesn't the table-cell have a block wrapping it in that case?

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?

<bz> dbaron: it doesn't

fantasai: Replaced elements are defined as children being outside of the scope. .

<bz> dbaron: or rather....

Bert: So that seems to mean that we don't have to look at them.

<bz> dbaron: the interaction is interesting

<fantasai> fantasai: Whether or not it has children doesn't matter

Boris: I think the behavior is well-defeined for if the runin is into a table cell or not.
... It's a little weird because if it has a table child it can't run in, but I think it's all consistent.
... 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 ahve a table-cell inside an inline element, it automatically generates an inline table.

tantek: Did we ever define pseudoelems 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 bori'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.

<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

Bert: Back to replaced elements. Proposal is to clarify definition in section 3.1, where it says "out of scope"

<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

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.

fantasai: I disagree with what Bert hasn't said yet.

<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!

Bert: Proposal is that document tree is empty for CSS.

<bz> tantek, dynamic changes make it extra fun. ;)

Bert: you disagree, fantasai?

<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

fantasai: Yeah, in the document tree the elements isn't considered empty, and for selectors and such you don't *want* it to be empty.

<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.

fantasai: We'll be referring back to this later, and you can't screw around with the document tree for future extentions.

<tantek> useful to at least get the static cases figured out first though right?

Bert: But that's the definition of replaced. The content that was there no longer appears.

<bz> yeah, no point testing dynamic much till static is defined

fantasai: But what about inline SVG? There's obviously children there.

Bert: But it looks empty for CSS.

<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

fantasai: You're talking about the rendering tree, which is different from the document tre.

<tantek> http://lists.w3.org/Archives/Public/www-style/2009Jul/att-0025/test.html is a good start

Bert: There is no rendering tree.

<bz> tantek, sadly, without much description of what _should_ happen

<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.

<tantek> bz - presumably red means wrong?

Bert: We may avoid 'empty', but need to say that the contents of a replaced leement is ignored for CSS.

<bz> tantek, sorry, no. color is just used to tell apart the various blocks

Fantasai: Sure, just don't call it empty.

<bz> tantek, I should have used purple or blue.....

tantek: so it's opaque

<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

fantasai: What about the parent selector? object:has(a), should we just say this doesn't match? Selectors should work on the actual DOM.

<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); }

<bz> so...

<fantasai> That makes it replaced

<bz> it's even simpler

<fantasai> which makes the selector no longer applyl

<bz> that I style with :empty

<fantasai> because it's replaced

<fantasai> and now it's empty!!

<tantek> fantasai - no selector feedback loops

<bz> img:empty { border: 10px solid purple; }

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.
... 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.
... This decision is made before CSS happens.
... How do you decide?

TabAtkins: :incomplete?

<glazou> ChrisL: rofl

tantek: That's an old thing, right?

fantasai: Nah, it's relatively recent. But it's out of scope of the conversation.

Bert: Let's make it clear that you don't look at the DOM content of replaced elements.

fantasai: Yes.

Bert: We just need to exclude children from being looked at for this.
... 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 it does.

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.

<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.

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.
... 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 th 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: CSS2.1 model: 1) parse document, 2) I'll let fantasai reminute the list.

<fantasai> http://www.w3.org/TR/CSS21/intro.html#processing-model

<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:

ChrisL: I'm happy to say "formatting structure" rather than "rendering tree". It's in *that* that replaced elements have no children.

<dbaron> C has a computed value for 'display' of 'inline', is non-replaced, and has one or

<dbaron> more children that inhibit run-in behavior

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.

<dbaron> and changing:

<dbaron> If A has any children

<dbaron> to:

Bert: Ok.

<dbaron> If A is non-replaced and has any children

glazou: We were at 3. Accept the proposal with Bert's text?

RESOLVED Accept Bert's 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?
... Every box needs a containing-block. If the run-in goes inline, which box is containing it?
... 10.1 supposedly defines the containing block for all elements.
... 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.
... So the run-in will have it's normal parent as the containing block, not the sibling that it's flowing into.
... Do we want that, or do we want the sibling to be the containing block?

fantasai: The second one.
... 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...
... 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?
... And with abspos children of the run-in.

fantasai: For floats it should be the same - the containing sibling.
... 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".
... In my reading it's just the ancestor. But Boris thinks it might refer to the formatting structure, and so it may refer to thee ancestor in the formatting structure.
... 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.
... I don't personally think it's necessary. I read "ancestor box" as referring to the document structure.
... But if others think it's ambiguous, we have to go through the text and replace those occurences. Thoughts?

fantasai, sylvain: I always interpreted that as being formatting structure.

plinss: Especially since it says "box", not "element".

ChrisL: Yeah, it's ambiguous, especiall frex for abspos.

dbaron: Why is "ancestor" clearly one tree and not the other?
... 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.
... 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: In run-in, we dont' want to look up the element tree. We want to look up the formatting tree.
... 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.
... 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.e
... 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.
... 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 Elika or Bert will take care of this. At least clarify/define the "ancestor box".

Bert: Now the famous ::first-line issue.
... 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?

<fantasai> http://wiki.csswg.org/spec/css2.1#issue-142

Bert: Imagine the run-in is short, so half of the first line comes from th run-in, and half comes from the content.
... There are 3 or 4 reasonable ways of creating that inheritance tree.
... 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.
... But we don't have that pseudo in CSS2, so it's quite a change.

fantasai: I proposae following the document tree.

plinss: I don't know if that makes stylistic sense.
... 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, but shouldn't inherit from ::first-line.

<Bert> [Tab explains the issue ::run-in is trying to solve: being able to style the element differently when it run in than when it is block.]

<Bert> [Tantek says you typically use run-in when you're pretty sure the element *will* run in.]

<fantasai> [tantek and fantasai point out that you can't have a pseudo-class match depending on display type]

<fantasai> Peter: but you could have a pseudo-element

<fantasai> Peter: that selects its contents

<fantasai> RESOLVED: run-ins inherit from their document tree parent

<fantasai> dbaron: what about the common ancestor's ::first-line?

<fantasai> dbaron: I don't think we want to ignore the paragraph's ::first-line but honor the ancestor's

<fantasai> fantasai: Yeah, we shoudl either ignore all ::first-lines for run-in inheritance, or honor all of them

<fantasai> bz, can you type in your example pls? :)

<fantasai> bz: If there aer no ::first-lien styles, then we've just decided the run-in is color: blue

<fantasai> bz: If there is a ::first-line style on the second <div>, what happens?

<fantasai> bz: If that ::first-line style also sets color: orange, what happens?

<fantasai> (orcolor: yellow; )

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.
... 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.

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 epxlicitly set on it?

alex: I've ejust 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
... FF and Opera it doesn't make it a run-in.
... 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.
... 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.)

<fantasai> :)

<fantasai> yay!

<bz> well, other than the fact that I have to write the code... ;)

<tantek> http://wiki.csswg.org/planning/tpac-2009

<ChrisL> bz, yes we are on break now

<dbaron> bz, yep

<bz> time for another meeting in 2 mins, yay

<Bert> Scribe: Bert

<Bert_lap> Scribe: Bert_lap

[Discussion about which issues need discussion]

Selectors

<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2009Nov/0022.html

<TabAtkins> Default attribute thread

<fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/

http://www.w3.org/mid/4AEFE294.8070104@inkedblade.net

Fantasai: Default attributes, e.g., colspan is default 1. Can you match against them?
... Spec leaves it open.
... Should we allow both behaviors?
... Most impl. don't match default attrs.

Tantek: Impl. shouldn't be required to read DTD, so they don't necessarily know the default.
... That's the background behind the current spec.

Glazou: You *can* check if an attribute is absent.

DavidB: But need to select all unknowns, can get a long selector...

Fantasai: So agreed that spec allows both matching and not matching?

Arron: Are you goin gto send proposed text?

Fantasai: Yes, I will.

<fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/

Fantasai: Next is impl. reports. Looks like Opera fails several. Do we have other impls.?

ChrisL: Webkit was not tested yet.

DaivdB: Webkit seems pretty good.

ChrisL/DavidB: 15C may not matter

[DavidB trying out things in webkit.]

<dbaron> we don't have 2 impls for 174a, 174b, and d3

<dbaron> also 0 impls for 15c, but I don't think that matters

<dbaron> Mozilla is the only impl passing 174a, 174b, and d3 that I know of

Glazou: I am trying to get impl. report from zoomorama(sp?}

Fantasai: Should we also look at Prince?

Glazou: Yes, Prince is interesting.
... May also look at Andrew Fedoniouk's HTMLayout.

[Several discussions at the same time]

Fantasai: I'll run tests on Prince.

ChrisL: I can try Webkit.

[Discussion about most efficient way to quickly press keys.]

Fantasai: We need another impl. for some tests. Webkit not enough.

ChrisL: I talked to Opera about their failures. Maybe they can do something about it.

Beth: I tested the failures and they still fail in latest build.

Color and gamma correction

DavidB: Gamma may not be the right term.
... Colors are in sRGB.
... But nobody really impleents it.

<dsinger> see 3.1.1 in http://www.w3.org/TR/css3-color/

DavidB: Do we relax the spec?

ChrisL: On many platforms sRGB is right by default.

Beth: Not on the mac.

DavidB: 2nd question is do we give authors a way to opt in?
... Plugins are a known problem.
... The right thing would be to treat CSS colors as well as untagged images to be in sRGB.
... I don't know what Flash defines.

ChrisL: No color management, currently.

DavidB: Flash guys may be interested in defining something.
... But we may also want to give authors a choice.

<fantasai> Prince passes 174a and 174b and 15c

<fantasai> fails d3 (since it's dynamic)

DavidS/Beth: A vague idea we had:

scribe: An ability to turn it on with a property.
... Not crazy about the idea, but needed it for a client.

Tantek: So you needed it per element?

<fantasai> Konqueror passes d3

ChrisL: A need per element maybe because of video, of which there is more and more,as well as tagged images.

DavidS: And if you it on body, it applies to everything?
... Example: a background behind a flash, and only that, should be uncorrected.

Beth: We don't want to override color profiles when explicit in an image.

<ChrisL> Need to override *tagged* immages is minimal

DaviDS: There are also many incorrectly tagged images.

DavidB: Gecko now corrects tagged images.

Tantek: DavidS, what do you want, more precisely?

<ChrisL> Not clear that there are many incorrectly tagged images

DavidS: You can say that the color space of this element is such and such, or is 'none'.

Tantek: And if the image is tagged, it will override?
... So you described the 'auto' value that we had in a previous draft.

DavidB: But we also need our current behavior.
... Which is not interoperable.

DavidS: But it is consistent in a single browser.

Beth: We want 'auto' to match whatever browser decides to do. Which may even change over time...

Tantek: If you use 'auto', you cannot count on any specific behavior.

DavidB: You can count on it being consistent with a single browser.

DavidS: We may want to force platform-specific colors.

DavidB: Not sure we want that.

Tantek: Would there be no standardized value in the UA style sheet?

ChrisL: Difference between platform color spce and platform specific behavior, which may be color managed.

DavidB: Mozilla changed to be compatible with Webkit and go a lot of negative feedback.

Tantek: 'Default' could be another keyword.
... It means you cannot count on cross-platform conistency.

Beth: Sounds good.
... It means: what UA would do if the property weren't specified at all.
... That can change over time.
... E.g., at the moment we don't do color managament at all.
... But we may do so in the future.

Tantek: So 'auto' means treat as sRGB, except for images that are tagged.
... And 'sRGB' means override the image tags.

<ChrisL> Pointer to the relevant part of the old spec http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color

DavidS: So we have 'historical' and 'correct' (as keywords?).

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

Tantek: Two values for reintroduced color-profile: default (as per Beth) and srgb, defined the way 'auto' used to be defined.

<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."

Tantek: a'uto' exactly as that quoted text.
... And just two values seems enough.

Brad: Wrong tags in images?

<dsinger> note that the correct application of color spaces in plugins is the responsibility of the plugin and not the browser

<ChrisL> Brad is concerned about images saves with incorrect profiles, which was not noticed because browsers only started dealing with tagged images fairly recently

DavidB: That will never cause probelsm on some machine but not others. You will see the problem immediately.

<dsinger> note that the color spaces used in video are different, and the color correction of video is handled by the video subsystem

Peter: Didn't you, DavidB, say there were tools that generated wrongly tagged images?

DavidB: I think I said there were many untagged images.

chrisL: Most common tag is Adobe RGB.

DavidS: I want authors to tag images correctly.Not provide a work-around.

<ChrisL> most common after untagged, or tagged as sRGB, is AdobeRGB

[Discussion of DavidS text above]

ChrisL: Untagged video is almost sRGB in practice.

Tantek: Can DavidS find out if it is OK to treat unagged video as sRGB?

<ChrisL> its the same primaries (CCIR 709 primaries) the transfer curve is slightly different

<tantek> re-introduce 'color-profile' property, two values. 'default' per Beth's definition, and 'sRGB' per definition of 'auto' from http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color

<tantek> specifically

<tantek> 'sRGB'

ACTION on DavidS check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.

<trackbot> Sorry, couldn't find user - on

<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."

ACTION on Singer check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.

<trackbot> Sorry, couldn't find user - on

<ChrisL> ACTION: DavidS to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [recorded in http://www.w3.org/2009/11/03-CSS-minutes.html#action01]

<trackbot> Sorry, couldn't find user - DavidS

<ChrisL> trackbot, status

<ChrisL> ACTION: Dsinger to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [recorded in http://www.w3.org/2009/11/03-CSS-minutes.html#action02]

<trackbot> Sorry, couldn't find user - Dsinger

<ChrisL> ACTION: singer to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [recorded in http://www.w3.org/2009/11/03-CSS-minutes.html#action03]

<trackbot> Created ACTION-194 - Check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [on David Singer - due 2009-11-10].

RESOLUTION: re-add a 'color-correction'-like property with the two values 'default' and 'srgb'

Beth: We are working on -webkit- prefixed property, May be available by end of week.

ChrisL: Name should not clash with SVG.

Tantek: Other name is fine.
... call it 'color-correction'

DavidB: Per element is harder than per document.

ChrisL: Won't be changed very often.

[Dicussion about allowing UA to only do per document.]

Tantek: So require per-element?

<ChrisL> please lets

DavidB: I don't want to have to check it for every color paint.

<tantek> also proposed: drop section 3.1.1 Gamma correction

Bert: How do you get untagged images to match CSS text?

<tantek> http://www.w3.org/TR/2008/WD-css3-color-20080721/#gamma

Tantek: You say 'color-correction: srgb'

ChrisL: Do we have sufficient text for this property?

Tantek: Yes, everything is in IRC [above]

DavidB: Another last call for Color?

Tantek: Can we not go to CR with this change?

ChrisL: It's a change, needs a Last Call.
... But can go straight to PR after the LC, if we have implementation reports.
... So, write the test, and make sure UAs pass them, in particular Safari and Firefox.
... Opera doesn't do color management. I want to try to get them to change.

<tantek> write tests including vendor prefixed properties for color-correction to allow for those implementations to enable passing the tests.

ChrisL: Some of the platforms it runs on are hard to determine.

Arron: We don't do color management either.

DavidB: Is 'srgb' the right keyword?

Tantek: We can always add 'srgb-force-damnit'...

DaviDB: Also, retract that comment.

Glazou: Next steps?

ChrisL: Some editing, test cases, LC, and PR.

<dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Color/current/

<ChrisL> http://www.w3.org/Style/CSS/Test/CSS3/Color/20081014/reports/

RESOLUTION: drop section 3.1.1

Media Quries in HTML5 video

DavidS: Proposal is to add media query to VIDEO element.
... And then also add queries for the user's special needs.

Glazou: Seems like a good idea. I never thought it was just the media, always the context.

Tantek: So DavidS want some new terms to be added to the spec.
... And then a new LC.

Several: Or a second version.

General agreement to not change the current spec, but write a new one.

ChrisL: So just a draft for the new values, not repating the old ones?

Glazou: Yes.

ftf dates 2010

Old proposal was 22-24 March, but AC is 21-22 March, and in Boston, not in California.

DavidS: 23-25 in Boston is possible, if we have a host...

DavidB: Do we have the list of conflicts still from last time we discussed this?

<dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0179.html

DavidB: SXSW is Mar 12-16, WWW2010 is Apr 26-30
... How many people *will* be at AC?

DavidS: I will need to be at AC, but need not be in CSS WG.

Fantasai: I'd like to be on east coast around that time.

Bert: Organizing at W3C is likely to be possible.

<dsinger> http://www.w3.org/Member/Eventscal

ChrisL: Co-locating with WWW2010, in Raleigh, NC?

DavidB: How many will go there?

[Discussion about weather in Boston in March.]

Fantasai: How many would come in Calif? How many would come in Boston?

DavidS: 24-26 March, the rest of the week after AC.

[Looking for Easter dates.]

Glazou: And August?

DavidB: SteveZ had a family event conflict.

[Currently scheduled for Oslo, Aug 18-20]

DavidS: I also have a conflict for Aug.

Glazou: Let's keep August as it is for now. not Håkon here anyway.

DavidS: 2 questions for W3C: host in March? and is there a TPAC end of the year?

LUNCH

<dsinger> followed by a break for non-persistent cookies

<ChrisL> Scribe: Chris

<ChrisL> ScribeNick: ChrisL

Test suite status

Arron: What's that staus, who has reviewed their tests

Elika: I'm doing a coverage report

Arron: Still targetting 15 January?

Elika: yes

<scribe> ACTION: arron to create a template fr CSS 2.1 test suite reports [recorded in http://www.w3.org/2009/11/03-CSS-minutes.html#action04]

<trackbot> Created ACTION-195 - Create a template fr CSS 2.1 test suite reports [on Arron Eicholz - due 2009-11-10].

s/Aaron/Arron/

<glazou> BTW, not sure everyone in the WG got news from Robert Stevahn : http://twitpic.com/o63vs :-)

Elika: we have implementations for all selectors tests, counting prince, webkit, opea and firefox
... appart from the 15c subtest which needs multiple id support, already listed as feature at risk

glazou: champagne

http://www.cardsunlimited.com/largeimage/Champagne.jpg

Resolution: Advance to Proposed Recommendation for the Selectors spec

Gradients and Image Sprites

Arron: recall this had to but not sure what it is

David: Who added it

Tab: Not sure what it means either

(we are all confused)

Tab: Asked Shepazu to help with SVG equivalents of the gradient examples
... for sprites, its choosing between options

Elika: No, i just liked to the various proposals

David: We implemented -moz-image-rect()

Elika: the URI based syntax has no fallback. Could addit by putting it im the image not in the URI
... no need to a separate functional notation.
... if linked to image functional notation and require both to be iplemented
... waiting for media fragments wg to publish a spec
... Image sprites should make it more efficient that specifying explicit coods in the stylesheet
... not so much to discuss therefore

Simon: I have some feedback, will send on list

<scribe> ACTION: Simon to send gradients feedback to www-style [recorded in http://www.w3.org/2009/11/03-CSS-minutes.html#action05]

<trackbot> Created ACTION-196 - Send gradients feedback to www-style [on Simon Fraser - due 2009-11-10].

<bradk> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html

Drop shadows

(brad demonstrates)

brad: we want something that casts a shadow under the element, casts from background and border
... transparecy affects the color of the shadow where it overlaps. based on alpha channel

(brad fiddles with the drop shadow dialog in photoshop)

Brad: shadow has translucency
... inner version of a shadow

Chris: Please define how you are using the term inner

<fantasai> CSS2.1 coverage report (thrown rather haphazardly together, somewhat incomplete): http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0002/index.xht

Brad: the shape is cut out of the background and the shadow is on that

Chris: the shadow is in fact still on top

Brad: yes

(we discover the projector really needs color management)

Brad: so this is easy with sharp edges. with soft edges people seemed to be confused

Chris: its the same copy, remove color, add color, blur, opacity operation
... notice you are using blending modes - svg has those

(discussion on what exactly is happening in photoshop as people get their heads around it)

Simon: Easier to look at the actual proposal

Tab: the shadow is cast by a negative of the alpha channel, then clipped to the actual alphs channel

John: what is the use case for this?
... the photoshop is not convincing me of the utility

Elika: We have box shadows already

David: And we implement that, but lets decide if this part is useful before deciding exactly how it works

(brad demonstrates inner shadow on text)

Simon: With box and text shadow, the shadow does not depend on the transparency of the element
... fully transparent text still casts a shadow, with text-shadow

Brad: suppose you want just the border, or the background, or *one* of the backgrounds shaddowed

Simon: That seems more useful in the filters discussion

<bradk> apply-to(border + foreground, background-image + background-color)

Brad: pluses mean the shapes composite before shadow calculation, commas mean they each have their own shadow

David; apply-to gives the z-order?

scribe: what if you apply to things that are not z-ordered together?

Elika: you cant composite the text and the background and composite onto the border

Simon: this is trying to get photoshop into css, i don't see the use case. Separate elements can be used to do this

John: This sort of effect is better done in SVG, we don't need another language to do this. its a complex mechanism that duplicates something which already exists

Elika: So SVG filters can be used but we lack the ability to select parts of the border

John: If the goal is to do something this complex, is CSS the right language?

Chris: We are headed for a fairly complex selector model if we do this, to get at parets of the border

Elika: getting the whole border would be sufficient, but we need to address the different background layers

<bradk> ::apply-to(border + foreground, background-image + background-color)

Chris: could imageine pseudo elements to address the border, the background(s) and the content

<fantasai> Then how do you turn it off?

<fantasai> How many pseudo-elements do you need to write to turn it off?

<fantasai> dbaron: I don't think this is the right way to do it...

Brad: just targetting the whole border would satisfy my needs

<fantasai> fantasai: The pieces we'd need to address, in various combinations: background layers, border (one piece), content (one piece)

Brad: we don't want to implement all of svg in css, sure. We want to be eble to use parts of them

David: we already do SVG filters on any element

Brad: but only the whole parts

David: add to source-graphic source-alpha etc to add source-border, source-background ......

<fantasai> dbaron attempts to summarize how svg filters work

<smfr> http://www.w3.org/TR/SVG/filters.html#FilterPrimitivesOverview

<smfr> (scroll down)

Simon: fill-apint and stroke-paint

David: things to address the border, background or contents

Tab: Could we use parameters with that

Chris: Sure

<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Oct/0072.html

Elika: need a way to aprameterise that so we have a library of effects and apply them, without writing new filters

Simon: background image in SVG is what has already been painted by other elements

Elika: roc has some name suggestions

Chris: please pass those on to the SVG WG. The editor is Erik Dahlstrom from Opera. We can add them

David: Put them in the order you want and thats how they end up

<shepazu> [I'd be happy to talk to the CSS about my SVG parameters specification, which could pass parameters through a CSS property]

<jdaggett> shepazu: cmon down dear

Elika: does not make sense for a border to cast a shadow *under* the background

<fantasai> border casts a shadow immediately under the border, i.e. over the background

Brad; we should retain the natural stacking order

<fantasai> if border and background ar composited, then their shadow casts underneath the composited layer

<fantasai> i.e. directly underneat the background

(discussion on how to pass opacity to a filter)

Simon: how to get the putput of the filter int he right place

Shepazu: we are adding more canned filter effects, we could add more if you identify the. Adds a merge for the border etc

Elika: a filter to make the border and background partly transparent

Shepazu: filters can be computationally intensive. Though canned filters can be optimised. need to warn authors

Tab: Yes
... but won't trigger unexpectedly. Its clearly an opt-in

Shepazu: Need to make a tradeoff between power, speed and authoring ease

Simon: want to see blur and colour manip filters

Shepazu: sepia, b&w

Brad: so value in having a simple drop shadow?

http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html

Shepazu: need review from Erik and Anthony

Brad: syntax there is more similar to the existing box-shadow property. Illustrations were done in photoshop

Shepazu: Need to discuss, only now introducing canned filter effects so open to syntax that makes sense for CSS authors

(we look at inner shadow on text again)

Simon: for canned filters we would likely go to core graphics

Elika: happy to join any SVG telcons about this

filters spec is here http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html

<dbaron> http://lists.w3.org/Archives/Public/public-fx/

Shepazu: there is a public-fx@w3.org list

http://lists.w3.org/Archives/Public/public-fx/

Chris: canned effecxts are great, though people should be able to use arbitrary filters as well

Topic; F2f dates, the re-re-run

Szilles: the proposed dates clash with the AB meeting. next week would be fine

Now moved to Cupertino, 29-31 March 2010

SVG Params

(Doug walks through http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html )

David, PLH: using ? in the URI mesans its server side, not client side

foo.svg#param(name, value; name,value)

<dbaron> might you want to svg:use foo.svg#element with parameters?

john: is there an expression language?

shepazu: not yet

<Bert_lap> (Use an SVG file that consists of "param(x)" and nothing more, than pass <param name=x value="A bit of SVG..."> :-) )

Peter: would be great to pass in the currently cascaded color for example

adjourned!

- DRAFT -

SV_MEETING_TITLE

03 Nov 2009

Attendees

Contents