/irc-logs / w3c / #css / 2009-11-03 / end

Options:

# Session Start: Tue Nov 03 00:00:00 2009
# Session Ident: #css
# [00:00] <dbaron> jdaggett: I'm not keen on writing a spec for that, at least initially.
# [00:00] <dbaron> Håkon: When I said I wanted to go down the @font-face route, I meant that only for arbitrary features, not for features that we standardize.
# [00:00] <dbaron> Håkon: For the features we standardize, I think we should absolutely have properties that work the normal way.
# [00:00] <dbaron> SteveZ: So it sounds like we're mostly in agreement.
# [00:00] <dbaron> ChrisL: So we can start moving this stuff into the spec?
# [00:01] <dbaron> jdaggett: I still don't have a sense of the alternates...
# [00:01] <dbaron> ChrisL: I think it's time to start moving it into a spec now.
# [00:01] <dbaron> fantasai: I agree with that.
# [00:01] <dbaron> ChrisL: exposes it to more people, get wider review
# [00:01] <dbaron> jdaggett: Still not confident of ...
# [00:01] <dbaron> dbaron: Put big red issues in the spec so people know.
# [00:02] <fantasai> fantasai: That's why we have class="issue" :)
# [00:02] <ChrisL> Don't let that put you off. Lets get it into the spec
# [00:02] <dbaron> Topic: multicol
# [00:02] <dbaron> Håkon: Yes, I want to advance it.
# [00:03] <dbaron> Peter: So all the comments have been addressed?
# [00:03] <dbaron> Håkon: yes
# [00:03] <dbaron> fantasai: Do you have a disposition of comments?
# [00:03] <dbaron> Håkon: It's linked from the wiki page.
# [00:03] <howcome> http://dev.w3.org/csswg/css3-multicol/last-call.html
# [00:04] <dbaron> ChrisL: What are the uncolored rows?
# [00:04] <Zakim> -[Mozilla]
# [00:05] <dbaron> Håkon: They're not really comments, just questions.
# [00:05] <dbaron> ChrisL: put that in the grid at the top
# [00:05] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
# [00:05] <dbaron> ChrisL: Sylvain, could you send email about whether you're ok with that resolution.
# [00:05] <dbaron> Håkon: The other orange... he sent a message saying it was ok.
# [00:06] <dbaron> fantasai: I disagree with Håkon's disagreements.
# [00:06] <dbaron> Håkon: I'm happy to change.
# [00:06] <dsinger> comment #1: change "coing" to "going"
# [00:07] <dbaron> Daniel: some green rows have no action
# [00:07] <dbaron> Håkon: didn't result in changes
# [00:07] <dbaron> Daniel: so put "no changes needed"
# [00:08] <dbaron> Daniel: Don't use "white". Use "green".
# [00:08] * Joins: Kangchan (Kangchan@72.254.83.174)
# [00:09] * Parts: Kangchan (Kangchan@72.254.83.174)
# [00:10] <dbaron> ChrisL: Also need CR exit criteria.
# [00:10] <dbaron> fantasai: We have boilerplate for that.
# [00:11] <dbaron> Håkon: Should I prepare a CR draft then?
# [00:11] <dbaron> Bert: Yes, everything except the status.
# [00:11] <Zakim> -Hakon_Lie
# [00:11] <dbaron> fantasai: Bert can take care of the status right before publication.
# [00:11] <dbaron> RESOLVED: Advance css3-multicol to CR
# [00:11] <dbaron> Zakim, who is on the phone?
# [00:11] <Zakim> On the phone I see Salon_9
# [00:11] <glazou> #howcome { color-replace: white green; }
# [00:12] <Zakim> -Salon_9
# [00:12] <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
# [00:12] <Zakim> Attendees were Hakon_Lie, Salon_9, [Mozilla]
# [00:12] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
# [00:12] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
# [00:12] <ChrisL> zakim, remind us in 3 hours to go home
# [00:12] <Zakim> ok, ChrisL
# [00:13] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
# [00:13] <dbaron> <break duration="17min" />
# [00:13] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
# [00:14] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
# [00:19] * Joins: dethbakin (dethbakin@72.254.115.244)
# [00:20] * Joins: glazou (glazou@72.254.115.247)
# [00:27] * Quits: glazou (glazou@72.254.115.247) (Ping timeout)
# [00:31] * Joins: glazou (glazou@72.254.115.247)
# [00:35] * Joins: smfr (smfr@72.254.115.22)
# [00:35] * Quits: hyatt (hyatt@98.201.21.231) (Quit: hyatt)
# [00:36] <dsinger> zakim, you should have told us that break is over
# [00:36] <Zakim> I don't understand you, dsinger
# [00:40] * Quits: dethbakin (dethbakin@72.254.115.244) (Client exited)
# [00:41] * Joins: bradk (bradk@72.254.115.105)
# [00:41] * Joins: dethbakin (dethbakin@72.254.115.244)
# [00:44] <fantasai> ScribeNick: fantasai
# [00:44] <fantasai> Topic: grid, flexbox, css3-layout
# [00:45] * Joins: tantek (tantek@72.254.62.180)
# [00:45] * Curt`|away is now known as Curt`
# [00:45] <fantasai> Alex: Are there specific issues about these specs being inconsistent, overlapping, etc?
# [00:45] * Joins: Arron (arronei@72.254.111.4)
# [00:45] <fantasai> glazou: THe issue is that these specs are in limbo for 2 years
# [00:45] <fantasai> Tab: I added it to see if there is any way to unify the concepts, esp. between template, flexbox, and tables
# [00:46] <fantasai> Tab: These are 3 separate ways of dealing with layout, was wondering if we can combine them
# [00:46] <fantasai> dbaron: Tables have so many backwards-compatibility constraints that you probably don't want to do that
# [00:46] <fantasai> Alex: Flexbox is the first concept of layout that is completely independent of the rest of CSS
# [00:46] <fantasai> ...
# [00:46] <fantasai> Alex: There are two exceptions to that: table and flexbox
# [00:47] <fantasai> Alex: each uses its own algorithm to do layout
# [00:47] <fantasai> Alex: Which keeps its really simple: only layout concepts of this model apply
# [00:47] <fantasai> Alex: It's awesome
# [00:47] <fantasai> Alex: It's cool if this same model applies to something else
# [00:47] <fantasai> Alex: If it can be added as its own model without added any complexity of interference with other features
# [00:48] <fantasai> Tab: So you prefer the layoud modes bein completely separate from each other?
# [00:48] <fantasai> Markus: Depends on how you want to apply it
# [00:48] <fantasai> Markus: Flexbox is great for layout
# [00:48] <fantasai> Markus: Then use flow layout for the content inside
# [00:48] <fantasai> Alex: yes, I prefer different models separate
# [00:48] <fantasai> Alex: We can certainly discuss how this applies to CSS, where mostly everything applies to everything in combination
# [00:48] <fantasai> Alex: This is great for flow content
# [00:48] <fantasai> Alex: but the there are other systems like Silverlight, WPF, etc.
# [00:49] <fantasai> Alex: Where most layout models are self-contained and independent
# [00:49] <fantasai> Alex: Everyone has hits own model and it's extensible, you add a model
# [00:49] <fantasai> Alex: Is it good to go forward to have both system in CSS .. and ad flexbox and add somethign else and add something else... I don't know
# [00:50] <fantasai> Alex: I think the existence of flexbox as something separate is good. I would be worried if we tried to integrate with regular CSS layout
# [00:50] <fantasai> Tab: Ok, seems reasonable
# [00:50] <fantasai> Alex: Flexbox is a parent that has complete control of its descendents (?)
# [00:50] <fantasai> Alex: The model of the ocntainer overrides the contents
# [00:50] <fantasai> Alex: Abspos has that kind of gray area
# [00:50] <fantasai> Tab: That makes sense, esp within the context of flexbox
# [00:50] <fantasai> Tab: Jumping over to template
# [00:51] <fantasai> Tab: we have some definite parallels with how tables work
# [00:51] <fantasai> Tab: Might makes sense to align
# [00:51] <fantasai> Tab: E.g. apply table border concepts to template slots
# [00:51] <fantasai> Tab: Do we want to redesign this, or treat them as applying to both
# [00:51] <fantasai> Peter: things like border-collapse could apply to flexbox too
# [00:52] <fantasai> Tab: Anytime I use a table, I'm almost always border-collapsing
# [00:52] <fantasai> Tab: I think most times for templates I'd want to collapse the borders
# [00:52] * Joins: CesarAcebal (acebal@85.152.177.207)
# [00:53] <fantasai> fantasai isn't sure if that's the case, a lot of designs put margins around their boxes
# [00:53] <fantasai> Tab: I think the biggest problem is making sure the drafts have some life into them
# [00:53] <fantasai> Tab: All three are extremely important to me as a web design
# [00:53] <fantasai> Tab: Static design right now is workable, but bloats my markup and requires many compromises
# [00:53] <fantasai> Tab: I would make many sites faster and easier if I had layout modes like flexbox and template, and even tables now that they're implemented widely
# [00:54] <fantasai> Tab: I want these specs to move and be implemented well so I can use them in a few years
# [00:54] <fantasai> Bert: For the spec writing part of that, I've been thinking it should be possible to merge grid and template together
# [00:54] <fantasai> Bert: flexbox is different, but some can also be used with template and grid
# [00:54] <fantasai> Bert: I was thinking to put them in all in one spec. What to do with flexbox display values they are rather separate
# [00:54] <fantasai> Bert: But the flex property can be applied to other things
# [00:55] <fantasai> Tab: That makes sense I think. Grid matches really well with template
# [00:55] <fantasai> Tab: Grid positioning basically does a static template
# [00:55] <fantasai> Tab: Template just has some extra magic with slot pseudo elements
# [00:56] <fantasai> fantasai: There are some things you can do with grid that you can't do with template
# [00:56] <fantasai> fantasai: Although template would be better for some of the examples Alex had, last time he showed some interesting examples
# [00:56] <fantasai> (they are minuted in the last F2F minutes)
# [00:57] <fantasai> Alex describes some things you can do with grid and .e.g multicol interactions
# [00:58] <fantasai> fantasai: Another thing about grid is that it creats a grid that you can use to align things
# [00:58] <fantasai> fantasai: have a snap-to-grid feature
# [00:58] <fantasai> fantasai: That you could use for flow content
# [00:58] <fantasai> fantasai: e.g. say this box should fit its content, but should snap to the grid
# [00:58] <fantasai> fantasai: and you adjust the margins to make that happen
# [00:58] <fantasai> ...
# [00:58] <fantasai> Bert: I wanted to do abspos the right way.
# [00:59] <fantasai> Bert: You want to position not by numbers, but say "this is next to that", and "this is just as tall as that"
# [00:59] <fantasai> Bert: I wanted to have that abstraction there.
# [00:59] <glazou> hum hum http://daniel.glazman.free.fr/weblog/position__new.html
# [00:59] <fantasai> Bert: you can put any element anywhere, but they align to each other
# [00:59] <fantasai> Markus: I'm not sure we should merge them
# [00:59] <fantasai> Markus: They each have their use cases
# [01:00] <fantasai> Markus: Grid is very much a pixel-perfect wireframe thing
# [01:00] <smfr> grid: http://www.w3.org/TR/css3-grid/
# [01:00] <fantasai> Markus: I think if we merge them, we might lose the original use cases
# [01:00] <fantasai> Markus: I see the benefit of what you say
# [01:00] <smfr> template layout: http://www.w3.org/TR/css3-layout/
# [01:00] <fantasai> ...
# [01:01] <fantasai> Markus: Grid was intended to be a positioning system over whatever positioning scheme you use
# [01:01] <fantasai> ...
# [01:01] * glazou thinks that we would not have this discussion if CSS was able to position an element relatively to any other element, like P language did 20 years ago
# [01:01] <fantasai> Alex: could just as well be the other way, the grid defined as a side-effect of something else, e.g. a template
# [01:01] <fantasai> Alex: Currently it's explicit, but it doesn't have to be
# [01:02] <fantasai> shepazu: Have you guys talked about a fallback mechanism?
# [01:03] <fantasai> Alex: I'm not sure it makes sense to do fallback at the property level, you'd probably need an entirely separate style sheet
# [01:03] <fantasai> shepazu: What about for authoring tools?
# [01:03] <fantasai> glazou: Depends on if you need to preserve ... relation of prose
# [01:04] <fantasai> glazou: If I used this I wouldn't care about legacy browsers
# [01:04] <fantasai> shepazu asks when can browsers be relied on to support this stuff
# [01:06] <fantasai> fantasai: You'd need a media-query-like thing
# [01:06] <fantasai> fantasai: for something like this
# [01:07] <fantasai> shepazu: Yes. Is that a stupid question?
# [01:07] <fantasai> glazou: No, it's important
# [01:07] <fantasai> glazou: This has come up many times before
# [01:07] <fantasai> (shift that sentence up 2)
# [01:07] <fantasai> ...
# [01:07] <fantasai> shepazu: It's come up in dom3 events
# [01:07] * glazou said it's not the 1st time we want to do one thing if one couple (property/value) is parsed and something else if not
# [01:07] <fantasai> shepazu: Before, hasFeature only worked on a very gross level
# [01:07] <fantasai> shepazu: e.g. do you support Mouse Events?
# [01:08] <fantasai> shepazu: if you support 5 events and not 1, then can you say you support them?
# [01:08] * glazou just for the record http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/04/CssHackz
# [01:08] <fantasai> shepazu: It's very hard to say at a group level whether a feature is supported
# [01:08] <fantasai> shepazu: but if you have granularity, do you support this aspect of grid, then it's much easier to get an accurate response from the browser
# [01:08] <fantasai> Tab: You'd still run into bugs
# [01:08] * glazou and http://www.glazman.org/weblog/dotclear/index.php?post/2009/03/22/CssHackz-2
# [01:09] <fantasai> Tab: That's something that JS-based feature testing can do
# [01:09] * Joins: Kai (chatzilla@72.254.114.142)
# [01:09] <fantasai> Tab: Maybe you just defer to JS
# [01:09] <fantasai> Brad: Then JS has to be turned on
# [01:11] <fantasai> fantasai, glazou: testing at the property: value level is probably good enough
# [01:11] <fantasai> fantasai: If you need to detect specific bugs, then use a JS library
# [01:11] <fantasai> fantasai: but at the property: value level, then it's probably usable
# [01:12] <fantasai> fantasai: it's unlikely a browser would lie about hat
# [01:12] <fantasai> Peter: back on target
# [01:13] <fantasai> Tab: Personally I like the idea of template being built on top of grid and aligning a grid onto a box
# [01:13] <fantasai> Tab: Then you can align other boxes onto that grid (????)
# [01:13] <fantasai> Tab: But it works the other way for tables ...
# [01:13] * fantasai is not understanding enough to minute correctly
# [01:13] <fantasai> Alex: I don't think merging the specs would help to resolve these questions
# [01:13] <fantasai> Alex: I prefer keeping it separate as a coordinate system
# [01:13] <fantasai> Alex: doesn't say what you use it for
# [01:13] <fantasai> Alex: or where it's coming from
# [01:13] <fantasai> Alex: Just defines a grid
# [01:13] <fantasai> Alex: make sesnse and can be implemented
# [01:14] <fantasai> Alex; they don't have to merge to be able to interact
# [01:14] <fantasai> Tab: The only problem I have
# [01:14] <fantasai> Tab: Is if you have e.g. on the body both a template and a type grid
# [01:14] <fantasai> fantasai: I think you should be able to have multiple grids on a element, name them, and be able to align differnet things to different grids
# [01:15] <fantasai> Markus: Keeping the specs separate also makes implementing easier
# [01:15] <fantasai> faster
# [01:15] <fantasai> Tab: I think multiple grids is useful and important
# [01:15] <fantasai> Tab: And should be addressed if we want grid and template to interact nicely
# [01:15] <fantasai> shepazu: While I appreciate your case, just from a deployment standpoint,
# [01:16] <fantasai> shepazu: I'd rather see something like this implemented at a simple level
# [01:16] <fantasai> shepazu: Than talk about how to merge them
# [01:16] <fantasai> shepazu: It seems to me that grid is solving a lot of cases designers care about
# [01:16] <fantasai> shepazu: slowing it down to add templates doesn't seem like a good idea
# [01:16] <fantasai> Tab: I want template to be done
# [01:16] <fantasai> shepazu: I don't know template as well :)
# [01:16] <fantasai> Tab: A table defines its grid along its borders.
# [01:16] * Quits: Kai (chatzilla@72.254.114.142) (Ping timeout)
# [01:17] <fantasai> Tab: A type grid, you align your table cells along that grid
# [01:17] <fantasai> Tab: you give the table width and height to that grid
# [01:17] <fantasai> Tab: In that case you want multiple grids
# [01:17] <fantasai> Tab: you'll be introducing other grids along the way
# [01:17] <fantasai> Tab: I think it's useful to do so
# [01:17] <fantasai> Tab: but you still want to maintain access to your original type grid
# [01:17] <fantasai> Markus: To move these specs forward.. what are you asking for?
# [01:18] <fantasai> Tab: Do you have specific feedback on this? Then we can look at your comments and address them and move forward
# [01:18] <fantasai> s/Tab/Markus/
# [01:18] <fantasai> Markus: or are you asking ... or are you asking just how they itneract
# [01:18] <fantasai> Tab: Right now there's a note in the spec saying that it interacts with other specs
# [01:18] <fantasai> Tab: And thats the area where I want more attention
# [01:18] <fantasai> Markus: TO move theses things forward, we need to go through the process to maek that happen
# [01:18] <fantasai> markus: Here that means working through the issues
# [01:19] <fantasai> Markus: If there are no issues, then we leave the note and do nothing
# [01:19] <fantasai> ...
# [01:19] <fantasai> Tab: The note suggests right now an interaction that I don't think is good
# [01:19] <fantasai> Alex: The note just says the interaction might not happen, removing it doesn't change anything.
# [01:19] <fantasai> Tab: If grid and table don't interact and there are no plans for it, I'd like to keep it that way
# [01:20] <fantasai> Alex: Maybe someone comes in and implements that.
# [01:20] <fantasai> Steve: I'm losing track of where this discussion is going
# [01:20] <fantasai> Steve: I don't see any concrete proposal to discuss
# [01:20] <fantasai> Tab: I'm getting there
# [01:20] <fantasai> Chris: I think the discussion start with "shouldn't we merge them because they do the same thing" and has gotten to "no they're doing different things" and now we should move on
# [01:21] <fantasai> Tab: If we're going for simplicity, I'd there not to be a suggestion that tables create a gird
# [01:21] <fantasai> Tab: I want it either removed, or something stating that it will be added later
# [01:21] <fantasai> motion to remove note
# [01:21] <fantasai> RESOLVED: remove note about interaction between grid and tables
# [01:22] <fantasai> Peter: While we're on the topic, can we get better traction on these modules?
# [01:22] <fantasai> Chris, to MSFT: You could ship your experimental implementation.
# [01:22] <fantasai> Steve: There are two things missing
# [01:23] <fantasai> Steve: One is an agreement that people will focus their attention on at least one particular one of the mechanisms and make some progress there
# [01:23] <fantasai> Steve: I tend to agree with Tab's comment that there are too many mechanisms there
# [01:23] <fantasai> Steve: There are too many, so people say there are too many, and I won't do anything
# [01:23] <fantasai> Steve: The lack of agreement on one thing everyone will try and do is one of the blocks.
# [01:23] <fantasai> Steve: Second thing is, esp with grid, there are open questions on syntax etc.
# [01:24] <fantasai> Steve: Some things talked about in 2007 that need to get addressed.
# [01:24] <fantasai> Steve: e.g. backwards intrusions of flaots
# [01:24] <fantasai> Alex: Grid invites that kind of positioning ...
# [01:24] <fantasai> Steve: syntax and sizing...
# [01:25] <fantasai> Steve: Basically there are still open issues on grid
# [01:25] <fantasai> shepazu: experimental implementations would help
# [01:25] <fantasai> Bert: There are three prototypes for template
# [01:26] <fantasai> Bert: Cesar's JS implementation, a JQuery implementation, and Andrew's htmllayout implementation
# [01:26] <fantasai> shepazu: MSFT is interested in grid. Mozilla or Apple?
# [01:26] <fantasai> shepazu: Is it a matter of priorities, or a matter of not liking the technology?
# [01:27] <fantasai> dbaron: I don't know enough about the tech to answer
# [01:28] <fantasai> ACTION Alex: remove note from grid wrt table interaction sect 4.something
# [01:28] * RRSAgent records action 4
# [01:28] * trackbot noticed an ACTION. Trying to create it.
# [01:28] <trackbot> Created ACTION-192 - Remove note from grid wrt table interaction sect 4.something [on Alex Mogilevsky - due 2009-11-10].
# [01:28] <fantasai> Topic: run-in definition
# [01:28] * Quits: arronei (arronei@131.107.0.82) (Ping timeout)
# [01:28] <plinss> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
# [01:29] <fantasai> 4.2 and 4.3
# [01:30] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [01:31] <fantasai> dbaron motions to shift discussion to later, maybe get bz on the phone
# [01:31] <fantasai> bert would also like more time to prepare
# [01:32] <fantasai> steve: 9am?
# [01:32] <fantasai> resolved: move to 9am tomorrow
# [01:32] <fantasai> Topic: Size to Fit (for text)
# [01:33] <fantasai> Bert: it's basically to do what John was showing: make each line the same size
# [01:33] <fantasai> Bert: Useful for titles especially
# [01:33] <fantasai> Bert: Mostly used in advertisements
# [01:34] * Joins: Kai (chatzilla@72.254.114.142)
# [01:34] <fantasai> Bert: You make a block of text look like a block of text by varying font size until it fits
# [01:34] <fantasai> Bert: We had a proposals for that
# [01:34] <fantasai> Bert: It was given with last-line-align
# [01:34] * Joins: arronei (arronei@131.107.0.80)
# [01:34] <fantasai> Bert: and we had min and max font properties
# [01:36] <fantasai> fantasai doesn't understand why you would want to apply only to the last line
# [01:37] <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#last-line-alignment-prop
# [01:37] <fantasai> 'size' value
# [01:37] <fantasai> fantasai: Why would you want only the last line at the bottom to blow up in size, even though the rest of the paragraph is a small type size?
# [01:41] <fantasai> fantasai: It should apply to all lines
# [01:42] <fantasai> someone argues that it's only one line of text
# [01:42] <fantasai> because of forced breaks
# [01:42] <fantasai> fantasai argues that on web pages, which are flex layout, you don't want to force breaks everywhere
# [01:43] <fantasai> the title should be able to adapt to the available space
# [01:43] <fantasai> and with css3-text's text-wrap: suppress, you can get the title to break in the appropriate places as the available space shrinks
# [01:44] <fantasai> in such a case, if you wanted each line to size up to fill, you'd want the sizing to apply to all lines
# [01:44] <fantasai> not just the last line
# [01:45] <fantasai> Steve discusses another case where you size up the whole paragraph
# [01:45] <fantasai> to fill space
# [01:46] <fantasai> ?
# [01:47] <dbaron> copyfit: none | size-each | size-largest
# [01:47] <dbaron> text-justify-last: ...
# [01:48] <TabAtkins> You'd want a min/max size on the copyfit too, to avoid runaway craziness.
# [01:48] <fantasai> There was a discussion somewhere of a last-line-length
# [01:48] <fantasai> Which would trigger rejustification if the last line was too short
# [01:49] <fantasai> Peter: Another case is wanting to trigger justification on the last line or not based on how long it is; e.g. if it's 70% of the line, justify it, if it's only 2 words, left-align
# [01:49] <fantasai> fantasai: If I was adding this to the spec, I would add 'size' as a keyword to text-justify
# [01:50] <fantasai> fantasai: text-align: justify turns on justification
# [01:50] <fantasai> fantasai: text-justify specifies how you justify: which algorithm
# [01:52] <fantasai> ....
# [01:52] * Quits: Curt` (curt@76.243.219.200) (Quit: Sleep)
# [01:52] <fantasai> dbaron: There's been a bunch of discussion of changing the last line behavior
# [01:52] <fantasai> s/behavior//justification/
# [01:52] <fantasai> dbaron: and then discussion of changing the size of the text.
# [01:52] <fantasai> dbaron: These seem largely independent
# [01:52] <fantasai> dbaron: I suggested a copy-fit property
# [01:52] <fantasai> dbaron: one value is none, which is now
# [01:52] * Joins: shepazu (schepers@128.30.52.169)
# [01:52] <fantasai> dbaron: One is size the largest thing to fill thes pace
# [01:53] <fantasai> dbaron: and then everything else size up to match
# [01:53] * Quits: shepazu (schepers@128.30.52.169) (Client exited)
# [01:54] <fantasai> s/thing/line/
# [01:54] <fantasai> dbaron: the last one is to scale each line independently
# [01:55] <fantasai> dbaron: explicit letter-spacing happens before this, justification afterward
# [01:56] <fantasai> ACTION fantasai: Add this stuff as notes in css3-text
# [01:56] * trackbot noticed an ACTION. Trying to create it.
# [01:56] * RRSAgent records action 5
# [01:56] <trackbot> Created ACTION-193 - Add this stuff as notes in css3-text [on Elika Etemad - due 2009-11-10].
# [01:57] <fantasai> pierre: You often want to do this in certain ratios
# [01:57] <fantasai> mentions of character stretching and compression for justification
# [01:58] * Joins: shepazu (schepers@128.30.52.169)
# [01:58] <fantasai> Steve: There are properties other than size that you'd want to tweak for this
# [01:59] <fantasai> Steve: Perhaps have a value to add to properties saying how much to tweak
# [01:59] <fantasai> or whether
# [02:00] <fantasai> dbaron: Not sure if we want this available on blocks or inlines
# [02:00] <fantasai> Tab: was thinking of chaining techniques, specify in detail how you want something justified
# [02:00] <fantasai> ....
# [02:01] <fantasai> Steve: In InDesign the size of the window doesn't change
# [02:01] <fantasai> dsinger: right, you're designing for a specific size of paper for print
# [02:01] <fantasai> Tab: I think the techniques we're talking about right now are enough for cases where you want that effect. For a movie poster, you'd not use CSS
# [02:02] <fantasai> Bert: I made a collection of examples... trying to find it
# [02:02] <fantasai> Peter: I think that's it for the day
# [02:03] <tantek> http://wiki.csswg.org/planning/tpac-2009
# [02:03] <Bert_lap> http://www.w3.org/Style/Group/2009/Santa-Clara.html
# [02:03] <Bert_lap> http://wiki.csswg.org/planning/tpac-2009
# [02:04] <fantasai> Tantek: Color draft?
# [02:05] <fantasai> Steve: your issue with color, gamma paragraph?
# [02:06] <fantasai> ...
# [02:06] <fantasai> Steve: since I won't be here for that discussion
# [02:06] <fantasai> Steve: Don't break plugins
# [02:06] <fantasai> Steve: work with them to fix the problem
# [02:07] * Quits: glazou (glazou@72.254.115.247) (Quit: glazou)
# [02:07] * Parts: TabAtkins (chatzilla@72.254.56.183)
# [02:07] * Quits: bradk (bradk@72.254.115.105) (Quit: Computer has gone to sleep)
# [02:07] * Quits: plinss (plinss@72.254.111.33) (Quit: plinss)
# [02:08] * Quits: jdaggett (jdaggett@72.254.115.101) (Quit: jdaggett)
# [02:09] <Bert_lap> -> http://www.w3.org/Style/Group/1999/10/copyfit-examples.html justifying by font size
# [02:09] * Quits: sylvaing (sylvaing@72.254.116.25) (Ping timeout)
# [02:10] * Joins: myakura (myakura@114.163.221.102)
# [02:11] * Quits: dsinger (dsinger@72.254.95.64) (Quit: dsinger)
# [02:12] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [02:13] * Quits: smfr (smfr@72.254.115.22) (Quit: smfr)
# [02:13] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
# [02:13] * Quits: mmielke (mmielke@72.254.83.160) (Ping timeout)
# [02:13] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
# [02:14] * Quits: alexmog (alexmog@72.254.94.79) (Ping timeout)
# [02:15] * Joins: tantek (tantek@72.254.62.180)
# [02:16] * Quits: szilles (chatzilla@72.254.62.158) (Ping timeout)
# [02:17] * Quits: tantek (tantek@72.254.62.180) (Quit: tantek)
# [02:19] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
# [02:20] * Quits: myakura (myakura@114.163.221.102) (Ping timeout)
# [02:21] * Parts: Kai (chatzilla@72.254.114.142)
# [02:23] * Joins: myakura (myakura@118.15.135.158)
# [02:23] * Quits: dethbakin (dethbakin@72.254.115.244) (Quit: dethbakin)
# [02:27] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [02:34] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:39] * Parts: jfkthame (jonathan@66.207.206.178)
# [02:40] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
# [02:40] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [02:59] * Quits: myakura (myakura@118.15.135.158) (Quit: Leaving...)
# [03:12] <Zakim> ChrisL, you asked to be reminded at this time to go home
# [03:15] * Zakim excuses himself; his presence no longer seems to be needed
# [03:15] * Parts: Zakim (rrs-bridgg@128.30.52.30)
# [03:17] * Joins: sylvaing (sylvaing@72.254.116.25)
# [03:20] * Joins: tantek (tantek@98.248.34.230)
# [03:20] * Parts: anne (annevk@72.254.94.228)
# [03:23] * Quits: hamaji (hamaji@72.254.84.191) (Ping timeout)
# [04:07] * Quits: tantek (tantek@98.248.34.230) (Quit: tantek)
# [04:38] * Joins: mmielke (mmielke@72.254.107.105)
# [04:38] * Joins: Arron (arronei@72.254.111.4)
# [04:47] * Joins: jdaggett (jdaggett@12.229.246.2)
# [04:51] * Quits: mmielke (mmielke@72.254.107.105) (Ping timeout)
# [04:52] * Joins: mmielke (mmielke@72.254.107.105)
# [05:08] * Joins: dsinger (dsinger@68.126.189.44)
# [05:43] * Joins: mjs (mjs@69.181.42.237)
# [06:03] * Quits: mmielke (mmielke@72.254.107.105) (Ping timeout)
# [06:39] * Joins: TabAtkins (chatzilla@72.254.56.183)
# [07:00] <fantasai> http://www.w3.org/Style/CSS/Specs/Read
# [07:10] * Quits: sylvaing (sylvaing@72.254.116.25) (Ping timeout)
# [07:34] * Joins: TabAtkins_ (chatzilla@72.254.56.183)
# [07:34] * Quits: TabAtkins (chatzilla@72.254.56.183) (Connection reset by peer)
# [07:34] * TabAtkins_ is now known as TabAtkins
# [08:03] * Quits: TabAtkins (chatzilla@72.254.56.183) (Ping timeout)
# [08:11] * Joins: shepazu (schepers@128.30.52.169)
# [08:27] * Joins: TabAtkins (chatzilla@72.254.56.183)
# [08:38] * Joins: TabAtkins_ (chatzilla@72.254.56.183)
# [08:38] * Quits: TabAtkins (chatzilla@72.254.56.183) (Connection reset by peer)
# [08:38] * TabAtkins_ is now known as TabAtkins
# [08:54] * Parts: howcome (howcome@80.203.19.119)
# [09:47] * Quits: TabAtkins (chatzilla@72.254.56.183) (Ping timeout)
# [09:50] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
# [11:28] * RRSAgent excuses himself; his presence no longer seems to be needed
# [11:28] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [11:47] * Joins: Arron (arronei@72.254.111.4)
# [11:50] * Quits: Arron (arronei@72.254.111.4) (Ping timeout)
# [11:53] * Quits: CesarAcebal (acebal@85.152.177.207) (Quit: CesarAcebal)
# [12:15] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
# [14:32] * Joins: annevk (opera@72.254.82.30)
# [15:30] * Joins: kohei (kohei@67.203.153.14)
# [15:30] * Parts: kohei (kohei@67.203.153.14)
# [15:30] * Joins: kohei (kohei@67.203.153.14)
# [15:30] * kohei changes topic to ''
# [15:30] * kohei changes topic to ''
# [16:01] * Joins: sylvaing (sylvaing@72.254.86.181)
# [16:22] * Quits: jdaggett (jdaggett@12.229.246.2) (Quit: jdaggett)
# [16:22] * Quits: dsinger (dsinger@68.126.189.44) (Quit: dsinger)
# [16:23] * Joins: jdaggett (jdaggett@12.229.246.2)
# [16:27] * Joins: shepazu (schepers@128.30.52.169)
# [16:28] * Joins: mmielke (mmielke@72.254.124.123)
# [16:30] * Quits: jdaggett (jdaggett@12.229.246.2) (Ping timeout)
# [16:36] * Quits: kohei (kohei@67.203.153.14) (Quit: Computer goes to sleep!)
# [16:51] * Joins: MoZ (chatzilla@82.230.92.154)
# [16:52] * Joins: TabAtkins (chatzilla@72.254.99.227)
# [17:01] <annevk> lots of questions so early in the morning TabAtkins :)
# [17:02] <TabAtkins> They're from Elika. She's too lazy to get out of bed. ^_^
# [17:03] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
# [17:04] <annevk> I see :)
# [17:10] * Joins: Arron (arronei@72.254.101.153)
# [17:10] * Parts: Yves (ylafon@128.30.52.169)
# [17:23] * Joins: dsinger (dsinger@17.197.23.228)
# [17:23] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
# [17:23] * Joins: sylvaing (sylvaing@72.254.86.181)
# [17:27] * Joins: bradk (bradk@72.254.101.220)
# [17:28] * Joins: hamaji (hamaji@72.254.92.142)
# [17:28] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [17:30] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
# [17:31] * Joins: kohei (kohei@72.254.59.20)
# [17:33] * Quits: Arron (arronei@72.254.101.153) (Ping timeout)
# [17:36] * Joins: smfr (smfr@72.254.92.79)
# [17:38] * Quits: mmielke (mmielke@72.254.124.123) (Ping timeout)
# [17:45] * Joins: sylvaing (sylvaing@72.254.86.181)
# [17:47] * Joins: mmielke (mmielke@72.254.93.74)
# [17:47] * mmielke is now known as markusm
# [17:48] * Joins: Arron (arronei@72.254.101.153)
# [17:48] * Joins: dbaron (dbaron@63.245.220.11)
# [17:49] * Joins: Bert_lap (bert@128.30.52.169)
# [17:55] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [17:56] * Joins: bradk (bradk@72.254.101.220)
# [17:57] * Joins: jdaggett (jdaggett@72.254.82.75)
# [17:58] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
# [17:59] * Joins: plinss (plinss@72.254.59.50)
# [17:59] * Joins: dethbakin (dethbakin@72.254.103.251)
# [18:01] * Joins: bz (bzbarsky@66.92.65.154)
# [18:05] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [18:06] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [18:06] <RRSAgent> logging to http://www.w3.org/2009/11/03-CSS-irc
# [18:06] <plinss> rrsagent make logs public
# [18:06] * Joins: TabAtkins (chatzilla@72.254.99.227)
# [18:06] <plinss> zakim, this will be style
# [18:06] <Zakim> ok, plinss; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 6 minutes ago
# [18:07] <fantasai> Topic: Run-ins
# [18:07] <dbaron> Zakim, what is the number?
# [18:07] <Zakim> I don't understand your question, dbaron.
# [18:07] <dbaron> Zakim, what is the phone number?
# [18:07] <Zakim> I don't understand your question, dbaron.
# [18:07] * Joins: glazou (glazou@72.254.63.160)
# [18:07] <dbaron> Zakim, passcode?
# [18:07] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dbaron
# [18:08] <plinss> zakim, dial salon 9
# [18:08] <Zakim> I don't understand 'dial salon 9', plinss
# [18:08] <fantasai> Zakim, dial Salon_9
# [18:08] <Zakim> ok, fantasai; the call is being made
# [18:08] <dbaron> bz, conference code is above^
# [18:08] * Quits: annevk (opera@72.254.82.30) (Ping timeout)
# [18:09] <dbaron> Zakim, who is on the phone?
# [18:09] <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
# [18:09] <Zakim> On IRC I see glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, bradk, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
# [18:09] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [18:09] <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
# [18:09] * bz calls
# [18:09] * Joins: Kai (chatzilla@72.254.88.78)
# [18:10] <dbaron> Zakim, who is on the phone?
# [18:10] <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
# [18:10] <Zakim> On IRC I see Kai, glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
# [18:10] <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
# [18:10] * Joins: bradk (bradk@72.254.101.220)
# [18:10] <dbaron> Zakim, this is Style
# [18:10] <Zakim> ok, dbaron; that matches Styl_CSS-FP(TPAC)12:00PM
# [18:10] <dbaron> Zakim, who is on the phone?
# [18:10] <Zakim> On the phone I see SteveZ, Salon_9, +1.617.487.aaaa
# [18:10] <dbaron> Zakim, aaaa is bzbarsky
# [18:10] <Zakim> +bzbarsky; got it
# [18:11] * Joins: annevk (opera@72.254.82.30)
# [18:11] * Joins: Lachy (Lachlan@72.254.56.137)
# [18:12] * Joins: tantek (tantek@72.254.103.162)
# [18:12] <TabAtkins> Scribenick: TabAtkins
# [18:12] <dbaron> Zakim, who is noisy?
# [18:12] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
# [18:12] <Zakim> dbaron, listening for 10 seconds I heard sound from the following: SteveZ (37%), Salon_9 (20%)
# [18:13] <bz> how do I mute myself?
# [18:13] <bz> via the phone system?
# [18:13] <dbaron> Zakim, mute bzbarsky
# [18:13] <Zakim> bzbarsky should now be muted
# [18:13] * dsinger zakim, mute me
# [18:13] * Zakim sorry, dsinger, I do not know which phone connection belongs to you
# [18:13] <dbaron> Zakim, unmute bzbarsky
# [18:13] <Zakim> bzbarsky should no longer be muted
# [18:13] <TabAtkins> 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.
# [18:13] <bz> aha, nice
# [18:13] <bz> zakim, mute bzbarsky
# [18:13] <Zakim> bzbarsky should now be muted
# [18:13] <TabAtkins> Bert: Another application is a dl wheree the dt runs into the dd that follows rather than above it.
# [18:13] <TabAtkins> Bert: First issue: When can this happen? When can the run-in element become inline in the next element, and when not?
# [18:13] <TabAtkins> Bert: This dpeends on the element itself, and what follows.
# [18:14] * bz wonders whether he should be able to tell what's being said right now..
# [18:14] <TabAtkins> Bert: There must be a block afterward, for it to run into, and it can't contain blocks.
# [18:14] * fantasai ideally, yes
# [18:14] <bz> mmm
# [18:14] <TabAtkins> Bert: Original definition wasn't precise.
# [18:14] * Joins: alexmog (alexmog@72.254.94.217)
# [18:14] * fantasai bert is just summarizing, Tab's got the minutes pretty good
# [18:14] <dbaron> bz, can't here bert?
# [18:14] <bz> I can't make out any of it
# [18:14] <dbaron> hear
# [18:14] <bz> it's very quiet and pretty noisy
# [18:14] <TabAtkins> Bert: *points to email*
# [18:14] <bz> but only when speaker is talking
# [18:14] * sylvaing dubs Tab's desktop theme 'Chernobyl'
# [18:15] <bz> aha
# [18:15] <bz> this is better!
# [18:15] <bz> yes!
# [18:15] <bz> much better
# [18:15] * glazou waves at bz :)
# [18:15] <TabAtkins> Bert: The first link goes to pag holding conditions for element following the runin.
# [18:15] <bz> which page are these links on?
# [18:15] <TabAtkins> Bert: It must have a following sibling.
# [18:15] <TabAtkins> Bert: Ignore anything that's not in flow.
# [18:15] <bz> ah, I see, archives
# [18:15] <bz> ok
# [18:15] <TabAtkins> Bert: Such as floats, display:none elems, etc.
# [18:16] <TabAtkins> Bert: At top of the message, first point is about run-in itself. Come back to that later.
# [18:16] <TabAtkins> Bert: Point 2!
# [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:18] <fantasai> s/h2/h3/
# [18:18] <fantasai> fantasai: What about <h2> followed by <h3>?
# [18:18] <TabAtkins> Tantek: You can just put several run-ins in a row, right? And they'll all run in?
# [18:18] <TabAtkins> Bert: No, not by current language. The first would go block, the second would run-in.
# [18:19] <TabAtkins> Bert: The dt case makes a stronger example. You may want multiple <dt>s applying to the same <dd> to run together.
# [18:19] <TabAtkins> Bert: But I think the heading case is strong enough that we don't want to make multiple consecutive run-ins go together.
# [18:19] <TabAtkins> Bert: Point 1! Conditions on the run-in, and what children it can contain.
# [18:19] <TabAtkins> Bert: You have to look not only at children, but at all in-flow descendants.
# [18:20] * Joins: shepazu (schepers@128.30.52.169)
# [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:21] <TabAtkins> Bert: Yeah, that's already done.
# [18:22] <TabAtkins> Bert: Rewritten definition at bottom of email that has only two clauses.
# [18:22] <TabAtkins> fantasai: Can we say block-level element or display type, so we're not tying things to a specific list?
# [18:22] <TabAtkins> fantasai: The more we can do that, the better we'll be in the future when we introduce new types.
# [18:22] <TabAtkins> tantek: That's mostly good, but it might also causes problems if a future display type specially should interact with run-in.
# [18:23] <TabAtkins> fantasai: More things should prevent run-in than less.
# [18:23] <TabAtkins> plinss: It's far more likely that something new would inhibit run-in than allow it.
# [18:23] <TabAtkins> Bert: I haven't looked into that specifically, to see if the definition of "block-level" would work.
# [18:23] <TabAtkins> 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.
# [18:24] <TabAtkins> tantek: That's a good argument. inline-block may act like a block *or* inline.
# [18:24] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
# [18:24] <TabAtkins> fantasai: What we need is the ability to say something is a block on the eoutside, or a block on the inside.
# [18:24] <TabAtkins> tantek: Yeah, but we didn't even know that until we made inline-block. We didn't realize the abstraction was even necessary.
# [18:25] <TabAtkins> 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.
# [18:25] <TabAtkins> fantasai: I don't want to introduce a new display-type and say "Let's go audit CSS2.1 and fix all the places."
# [18:25] <TabAtkins> fantasai: But I think for the new display types, our abstractions are good enough to talk about.
# [18:25] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
# [18:26] * Joins: Lachy (Lachlan@72.254.56.137)
# [18:26] <TabAtkins> plinss: If we have a new list, we're *guaranteed* to update it. An abstraction *may* need to be updated.
# [18:26] <TabAtkins> tantek: I'd rather have things fail obviously than subtly.
# [18:26] <TabAtkins> fantasai: It's never obvious. People look at the list of things that are allowed, and just assume that it's still correct.
# [18:26] <TabAtkins> dbaron: We do have the terms "inline-level" and "block-level" elements, which can work as the excluded/included lists.
# [18:27] <bz> That was updated
# [18:27] <TabAtkins> dbaron: I've noticed the list of Bert's seems to be wrong. A run-in containing a run-in is inhibited.
# [18:27] <TabAtkins> Bert: That's what is says.
# [18:27] <TabAtkins> dbaron: Sorry, yeah.
# [18:27] <bz> http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html has the right text
# [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:27] <TabAtkins> smfr: Webkit has basic run-in behavior, but sort of broken.
# [18:28] <TabAtkins> dbaron: I think everyone but Moz implements, but they all do it differently.
# [18:28] <TabAtkins> tantek: And presumably the test-cases that demonstrate lack of interop is published?
# [18:28] <TabAtkins> TabAtkins: Yeah, I think Boris published those.
# [18:28] <TabAtkins> tantek: It would be good to get a pointer for that.
# [18:28] <Bert> -> http://www.w3.org/Style/Group/css2-src/visuren.html#block-boxes Definition of "block-level elements" (9.2.1)
# [18:28] <Zakim> -SteveZ
# [18:28] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Sep/0018.html
# [18:29] * Joins: mjs (mjs@72.254.84.91)
# [18:29] <TabAtkins> dbaron: I think Boris is waiting to publish the test-cases until he's sure that they're right.
# [18:29] <TabAtkins> tantek: It's useful to have real examples, not just specified abstractly.
# [18:29] <sylvaing> correction; a testcase from bz: http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html
# [18:29] <TabAtkins> tantek: It may turn out that once we see a real exampl of the prose text, it's not what we wanted.
# [18:29] <TabAtkins> Bert: I don't have a preference for a list or a "block-level" definition.
# [18:30] <TabAtkins> Bert: There's some subtlety in that it would refer to run-ins and say "some of the time".
# [18:30] <TabAtkins> Bert: Verdict on the definition?
# [18:31] <TabAtkins> 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.
# [18:32] <TabAtkins> Bert: So that sounds like proposal #1?
# [18:32] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html
# [18:32] <fantasai> accept text at bottom
# [18:32] <bz> http://lists.w3.org/Archives/Public/www-style/2009Aug/0594.html
# [18:32] <TabAtkins> RESOLVED accept text at bottom.
# [18:32] <TabAtkins> Bert: Next issue. Should still be easy.
# [18:32] <TabAtkins> Bert: What do to with replaced elements?
# [18:32] <bz> I assume we decided that behavior is ok?
# [18:33] <bz> Zakim, unmute bz
# [18:33] <Zakim> bzbarsky should no longer be muted
# [18:33] <TabAtkins> Bert: Maybe a wider issue. In my implementation replaced elements are always empty.
# [18:33] <TabAtkins> fantasai: No.
# [18:33] <TabAtkins> Bert: I know what I think.
# [18:33] <TabAtkins> fantasai: In the document tree it's not necessarily empty: textarea, object, etc.
# [18:33] <TabAtkins> Bert: That's the issue. Do you look in the document tree, or just in the things considered for rendering?
# [18:33] <TabAtkins> Bert: In replaced elements, the children are thrown away.
# [18:34] <TabAtkins> fantasai: And form elements may or may not b replaced, depending.
# [18:34] <TabAtkins> Bert: Let's look at the proposal. There's proposed text to clarify.
# [18:34] <TabAtkins> Bert: Section 3.1
# [18:34] <dbaron> bz, doesn't the table-cell have a block wrapping it in that case?
# [18:34] <TabAtkins> 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?
# [18:35] <bz> dbaron: it doesn't
# [18:35] <TabAtkins> fantasai: Replaced elements are defined as children being outside of the scope. Per CSS, there aren't any children.
# [18:35] <bz> dbaron: or rather....
# [18:35] <TabAtkins> Bert: So that seems to mean that we don't have to look at them.
# [18:35] <bz> dbaron: the interaction is interesting
# [18:35] <fantasai> s/Per CSS, there aren't any children//
# [18:35] <fantasai> fantasai: Whether or not it has children doesn't matter
# [18:35] <TabAtkins> Boris: I think the behavior is well-defeined for if the runin is into a table cell or not.
# [18:36] <TabAtkins> 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.
# [18:36] <TabAtkins> Boris: It's something to be careful with.
# [18:36] <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.
# [18:36] <TabAtkins> dbaron: I would think that if it has any table stuff in it, except inline-table, it should inhibit run-in.
# [18:36] <TabAtkins> Bert: But if you ahve a table-cell inside an inline element, it automatically generates an inline table.
# [18:37] <TabAtkins> tantek: Did we ever define pseudoelems for the generated wrappers for tables?
# [18:37] <TabAtkins> fantasai: No.
# [18:37] <TabAtkins> Boris: Anonymous blocks have to have something to do with what's going on here.
# [18:37] <fantasai> s/fantasai/?/
# [18:37] <TabAtkins> dbaron: I don't think there's an inconsistency between bori's two cases, because it only occurs into inlines and not other things.
# [18:37] <dbaron> bz, I don't think we're inconsistent between those two cases, since the recursion in Bert's proposal only recurs into inlines
# [18:38] <TabAtkins> Boris: The issue raised here was addressed in Bert's proposal, and should both result in the run-in running in.
# [18:38] <Zakim> +SteveZ
# [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, http://lists.w3.org/Archives/Public/www-style/2009Jul/0030.html has another test
# [18:39] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
# [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.
# [18:39] * Joins: Lachy (Lachlan@72.254.56.137)
# [18:39] <TabAtkins> fantasai: I disagree with what Bert hasn't said yet.
# [18:39] <bz> tantek, my current estimate is we need ~100ish tests to test all reasonably
# [18:40] <tantek> bz - thanks much - that will help a lot
# [18:40] <tantek> ouch!
# [18:40] <TabAtkins> Bert: Proposal is that document tree is empty for CSS.
# [18:40] <bz> tantek, dynamic changes make it extra fun. ;)
# [18:40] <TabAtkins> Bert: you disagree, fantasai?
# [18:40] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
# [18:40] <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
# [18:40] <TabAtkins> 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.
# [18:40] <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.
# [18:40] <tantek> bz - agreed, things are much more difficult when dynamic.
# [18:41] <TabAtkins> fantasai: We'll be referring back to this later, and you can't screw around with the document tree for future extentions.
# [18:41] <tantek> useful to at least get the static cases figured out first though right?
# [18:41] * Joins: glazou (glazou@72.254.63.160)
# [18:41] <TabAtkins> Bert: But that's the definition of replaced. The content that was there no longer appears.
# [18:41] <bz> yeah, no point testing dynamic much till static is defined
# [18:41] <TabAtkins> fantasai: But what about inline SVG? There's obviously children there.
# [18:41] * tantek implemented some degree of CSS2 display:run-in in IE5/Mac about 10 years ago.
# [18:41] <TabAtkins> Bert: But it looks empty for CSS.
# [18:41] * tantek curious how many cases he got right/wrong.
# [18:41] <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html has an attached testcase
# [18:42] <bz> tantek, with lots of different cases tested
# [18:42] <TabAtkins> fantasai: You're talking about the rendering tree, which is different from the document tre.
# [18:42] <tantek> http://lists.w3.org/Archives/Public/www-style/2009Jul/att-0025/test.html is a good start
# [18:42] <TabAtkins> Bert: There is no rendering tree.
# [18:42] <bz> tantek, sadly, without much description of what _should_ happen
# [18:42] <glazou> "There is no rendering tree" -- Bert 2009-11-03
# [18:42] <TabAtkins> fantasai: If we can reword it so we don't say the element is empty, I may be happy with it.
# [18:42] <tantek> bz - presumably red means wrong?
# [18:42] <TabAtkins> Bert: We may avoid 'empty', but need to say that the contents of a replaced leement is ignored for CSS.
# [18:42] <bz> tantek, sorry, no. color is just used to tell apart the various blocks
# [18:42] <TabAtkins> Fantasai: Sure, just don't call it empty.
# [18:43] <bz> tantek, I should have used purple or blue.....
# [18:43] <TabAtkins> tantek: so it's opaque
# [18:43] <bz> tantek, all the right/wrong is in whether things run in or not. So whether they're on one line or two lines
# [18:43] <bz> tantek, and which is contained in which border
# [18:43] * bz gathered this was normal, yes. ;)
# [18:44] <TabAtkins> fantasai: What about the parent selector? object:has(a), should we just say this doesn't match? Selectors should work on the actual DOM.
# [18:44] <bz> I just have nothing to say on this; the behavior we want is obvious; the only question is how to define it.
# [18:44] <fantasai> Let's say I have a <p> element with an <a> inside it
# [18:45] <fantasai> I write a selector for <p>s that have <a>s inside them using Selectors 4
# [18:45] <fantasai> then I say { content: url(image.png); }
# [18:45] <bz> so...
# [18:45] <fantasai> That makes it replaced
# [18:45] <bz> it's even simpler
# [18:45] <fantasai> which makes the selector no longer applyl
# [18:45] <bz> Say I have an HTML <img>
# [18:45] <bz> that I style with :empty
# [18:45] <fantasai> because it's replaced
# [18:45] <fantasai> and now it's empty!!
# [18:45] <tantek> fantasai - no selector feedback loops
# [18:45] <bz> img:empty { border: 10px solid purple; }
# [18:45] * Joins: ChrisL (ChrisL@128.30.52.169)
# [18:45] <TabAtkins> glazou: But why would this no longer apply?
# [18:46] <TabAtkins> fantasai: Because we say that it's a replaced element now, and thus it would be empty. No selector can target the contents anymore.
# [18:47] <TabAtkins> dbaron: We should fix this issue in the run-in section, not by changing the definition of a replaced element.
# [18:48] <TabAtkins> TabAtkins: fantasai is saying that run-ins can ignore children of replaced, but we shouldn't just say that the children don't exist.
# [18:48] <TabAtkins> Bert: We don't care about the DOM, we care if CSS says they exist.
# [18:48] <TabAtkins> fantasai: But they do exist. You can select on them.
# [18:49] <TabAtkins> Chris: Ignoring them and making them disappear are two different things.
# [18:49] <TabAtkins> Bert: I just want to clarify that we're using a definition is internally consistent.
# [18:49] <TabAtkins> Bert: Per CSS, whatever's inside a replaced element simply isn't there.
# [18:49] <dbaron> object:empty only matches some of the time
# [18:49] <TabAtkins> fantasai: Let's just say that you can't do anything with it, not say that it isn't there.
# [18:50] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:50] <TabAtkins> dbaron: You're saying the object:empty should match *all* of the time.
# [18:50] <TabAtkins> Bert: Yeah, it should say that.
# [18:50] <TabAtkins> glazou: When doesn't object:empty work?
# [18:50] <TabAtkins> dbaron: When <object> has fallback, frex.
# [18:51] <TabAtkins> glazou: Object has children in the DOM.
# [18:51] <TabAtkins> Bert: If it's replaced it has no children.
# [18:51] <TabAtkins> glazou: It does.
# [18:51] <TabAtkins> Bert: Does not.
# [18:51] <bz> is too, is not
# [18:51] <TabAtkins> Chris: We're going in circles. Chairs?
# [18:52] * Joins: dbaron (dbaron@63.245.220.11)
# [18:52] * ChrisL your MOM has no children!!!
# [18:52] <TabAtkins> tantek: How do you assign different styles to an object based on whether the object loads or not.
# [18:52] <TabAtkins> tantek: This decision is made before CSS happens.
# [18:52] <TabAtkins> tantek: How do you decide?
# [18:52] <TabAtkins> TabAtkins: :incomplete?
# [18:52] <glazou> ChrisL: rofl
# [18:53] <TabAtkins> tantek: That's an old thing, right?
# [18:53] <TabAtkins> fantasai: Nah, it's relatively recent. But it's out of scope of the conversation.
# [18:53] <TabAtkins> Bert: Let's make it clear that you don't look at the DOM content of replaced elements.
# [18:53] <TabAtkins> fantasai: Yes.
# [18:53] <TabAtkins> Bert: We just need to exclude children from being looked at for this.
# [18:53] <TabAtkins> Bert: So how do we phrase this?
# [18:54] <fantasai> "The children of replaced elements are not considered in the CSS rendering model."
# [18:54] <fantasai> for 3.1
# [18:55] <TabAtkins> Bert: But that sounds like a contradiction. Replaced elements don't have children.
# [18:55] <TabAtkins> glazou: Nah, everyone agrees that it does.
# [18:55] <TabAtkins> dbaron: So if a <select> is a replaced element, browsers can't render <option>s.
# [18:56] <TabAtkins> fantasai: They're not unrenderable, just CSS won't see them. Whatever draws forms will.
# [18:56] <TabAtkins> Bert: In CSS1 form elements were defined as replaced, but we've gradually been removing that.
# [18:56] <TabAtkins> tantek: And in CSS3, <select> is appearance:popup-menu.
# [18:57] <tantek> http://w3.org/TR/css3-ui
# [18:57] <TabAtkins> glazou: Bert, do you have a counterproposal, since you're blocking this sentence?
# [18:57] <TabAtkins> Bert: Can we say that the "content", not "children"?
# [18:57] <TabAtkins> fantasai: Okay.
# [18:57] <Zakim> -SteveZ
# [18:58] <fantasai> "The content of replaced elements is not considered in the CSS rendering model."
# [18:58] <TabAtkins> Bert: That's fine.
# [18:59] <TabAtkins> Chris: So what about <foo-img src=bar><tooltip>baz</tooltip></foo-img>. Does this mean we can't ever style the tooltip?
# [18:59] <TabAtkins> 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.
# [19:00] <TabAtkins> Bert: How do you display that image? Does it replace the contents?
# [19:00] <TabAtkins> ChrisL: Ys.
# [19:00] * sylvaing expects an :nth-illegitimate-child() proposal by end of day
# [19:00] <TabAtkins> Bert: Defined by the document format?
# [19:00] <TabAtkins> ChrisL: Yes.
# [19:00] <annevk> XBL!
# [19:00] <TabAtkins> Bert: Then it has no children.
# [19:00] <TabAtkins> ChrisL: But we may want to do so.
# [19:00] <dbaron> So which case of run-in behavior are we trying to affect, anyway?
# [19:01] <TabAtkins> Bert: Then we'll need to change CSS to do so.
# [19:01] <TabAtkins> Bert: When we use CSS3 Generated Content, we'll be able to do so.
# [19:01] <dbaron> The definition for whether things run in seems fine for replaced elements already.
# [19:01] <TabAtkins> Bert: If th document language says how to display it, we can no longer say anything about it.
# [19:02] <TabAtkins> 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.
# [19:02] <TabAtkins> glazou: What Chris is saying is that this restricts new language design.
# [19:02] <TabAtkins> fantasai: CSS2.1 model: 1) parse document, 2) I'll let fantasai reminute the list.
# [19:02] <fantasai> http://www.w3.org/TR/CSS21/intro.html#processing-model
# [19:02] <dbaron> Instead, I propose changing:
# [19:03] <dbaron> C has a computed value for 'display' of 'inline' and it has one or
# [19:03] <dbaron> more children that inhibit run-in behavior
# [19:03] <dbaron> to:
# [19:03] <TabAtkins> ChrisL: I'm happy to say "formatting structure" rather than "rendering tree". It's in *that* that replaced elements have no children.
# [19:03] <dbaron> C has a computed value for 'display' of 'inline', is non-replaced, and has one or
# [19:03] <dbaron> more children that inhibit run-in behavior
# [19:03] <TabAtkins> 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.
# [19:03] <dbaron> and changing:
# [19:03] <dbaron> If A has any children
# [19:03] <dbaron> to:
# [19:03] <TabAtkins> Bert: Ok.
# [19:03] <dbaron> If A is non-replaced and has any children
# [19:03] * Quits: tantek (tantek@72.254.103.162) (Client exited)
# [19:04] <TabAtkins> glazou: We were at 3. Accept the proposal with Bert's text?
# [19:04] * Quits: jdaggett (jdaggett@72.254.82.75) (Quit: jdaggett)
# [19:04] * Joins: tantek (tantek@72.254.103.162)
# [19:04] <TabAtkins> RESOLVED Accept Bert's text for issue 3 in the run-in email
# [19:04] <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
# [19:05] <TabAtkins> Bert: Next issue. What is the containing block of the run-in and children?
# [19:05] <TabAtkins> Bert: Every box needs a containing-block. If the run-in goes inline, which box is containing it?
# [19:05] <TabAtkins> Bert: 10.1 supposedly defines the containing block for all elements.
# [19:05] <TabAtkins> 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.
# [19:06] <TabAtkins> Bert: So the run-in will have it's normal parent as the containing block, not the sibling that it's flowing into.
# [19:06] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
# [19:06] <TabAtkins> Bert: Do we want that, or do we want the sibling to be the containing block?
# [19:06] <TabAtkins> fantasai: The second one.
# [19:06] * Joins: Lachy (Lachlan@72.254.56.137)
# [19:07] <TabAtkins> fantasai: Frex, width:50% on the run-in should be taking its width from the sibling it's flowing into.
# [19:07] <TabAtkins> sylvain: So it would get its color, frex, from its parent, but other things would come from the eparent.
# [19:07] <TabAtkins> 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.
# [19:08] <fantasai> s/run-in/run-in's inline-block child/
# [19:08] <TabAtkins> Boris: To be clear, I think we want to say this...
# [19:08] <TabAtkins> 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?
# [19:08] <TabAtkins> Boris: And with abspos children of the run-in.
# [19:09] <TabAtkins> fantasai: For floats it should be the same - the containing sibling.
# [19:09] <TabAtkins> fantasai: For abspos children, I have no opinion. I'm happy to go with whatever's easiest.
# [19:09] <TabAtkins> TabAtkins: For consistency, I'd prefer abspos to do the same thing.
# [19:10] <TabAtkins> Bert: It seems most are in favor of taking the sibling as the containing element for run-in and all children?
# [19:10] <bz> yay! ;)
# [19:10] <TabAtkins> RESOLVED The sibling that the run-in runs into is the containing block for it and all children.
# [19:10] <TabAtkins> Bert: Next issue. Boris believes 10.1 is ambiguous. It says "ancestor box".
# [19:11] <TabAtkins> 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 thee ancestor in the formatting structure.
# [19:11] * Joins: jdaggett (jdaggett@72.254.82.75)
# [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:12] <TabAtkins> Bert: I don't personally think it's necessary. I read "ancestor box" as referring to the document structure.
# [19:12] <TabAtkins> Bert: But if others think it's ambiguous, we have to go through the text and replace those occurences. Thoughts?
# [19:13] <TabAtkins> fantasai, sylvain: I always interpreted that as being formatting structure.
# [19:13] <TabAtkins> plinss: Especially since it says "box", not "element".
# [19:13] <TabAtkins> ChrisL: Yeah, it's ambiguous, especiall frex for abspos.
# [19:13] * tantek changes topic to 'display:run-in'
# [19:13] <TabAtkins> dbaron: Why is "ancestor" clearly one tree and not the other?
# [19:14] <TabAtkins> dbaron: I think it's clear that it's in the formatting tree.
# [19:14] <TabAtkins> ChrisL: If you have an abspos element, is the ancestor the whole document?
# [19:14] <TabAtkins> Bert: That's the ICB, not an ancestor.
# [19:14] <TabAtkins> plinss: The fact that we're having the conversation means it's ambiguous.
# [19:14] <TabAtkins> Bert: You can say that about any line in the spec.
# [19:15] <TabAtkins> Bert: It's a bit of work to go through the spec.
# [19:15] <TabAtkins> ChrisL: I'm okay with saying it's unambiguous if someone explains it clearly.
# [19:15] <TabAtkins> plinss: If it's supposed to be the box of the ancestor, say "box of the ancestor".
# [19:15] <TabAtkins> fantasai: In run-in, we dont' want to look up the element tree. We want to look up the formatting tree.
# [19:16] <TabAtkins> 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.
# [19:16] <TabAtkins> fantasai: We don't want to make this decision unless we're careful about run-ins?
# [19:17] <TabAtkins> 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
# [19:17] <TabAtkins> Bert: I think we'll have to rewrite 10.1 anyway, at least an extra clause.
# [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:20] <TabAtkins> Bert: Now the famous ::first-line issue.
# [19:20] <TabAtkins> 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?
# [19:20] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-142
# [19:20] <TabAtkins> Bert: Imagine the run-in is short, so half of the first line comes from th run-in, and half comes from the content.
# [19:21] <TabAtkins> Bert: There are 3 or 4 reasonable ways of creating that inheritance tree.
# [19:22] <TabAtkins> 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.
# [19:22] <TabAtkins> Bert: But we don't have that pseudo in CSS2, so it's quite a change.
# [19:22] <TabAtkins> fantasai: I proposae following the document tree.
# [19:22] <TabAtkins> plinss: I don't know if that makes stylistic sense.
# [19:23] <TabAtkins> 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.
# [19:23] <TabAtkins> Bert: What about background?
# [19:23] <TabAtkins> fantasai: Run-in should be included in ::first-line, but shouldn't inherit from ::first-line.
# [19:27] <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.]
# [19:27] * Quits: dsinger (dsinger@17.197.23.228) (Quit: dsinger)
# [19:27] * Joins: dsinger (dsinger@17.197.23.228)
# [19:27] * Quits: dsinger (dsinger@17.197.23.228) (Quit: dsinger)
# [19:27] <Bert> [Tantek says you typically use run-in when you're pretty sure the element *will* run in.]
# [19:28] <fantasai> [tantek and fantasai point out that you can't have a pseudo-element match depending on display type]
# [19:28] <fantasai> s/element/class/
# [19:29] <fantasai> Peter: but you could have a pseudo-element
# [19:29] <fantasai> Peter: that selects its contents
# [19:30] <fantasai> RESOLVED: run-ins inherit from their document tree parent
# [19:30] <fantasai> dbaron: what about the ancestor's ::first-line?
# [19:32] <fantasai> s/ancestor/common ancestor/
# [19:32] <fantasai> dbaron: I don't think we want to ignore the paragraph's ::first-line but honor the ancestor's
# [19:32] <fantasai> fantasai: Yeah, we shoudl either ignore all ::first-lines for run-in inheritance, or honor all of them
# [19:33] <fantasai> bz, can you type in your example pls? :)
# [19:33] <bz> <div style="color: blue">
# [19:33] <bz> <div style="display: run-in">Text</div>
# [19:33] <bz> <div style="color: yellow"></div>
# [19:33] <bz> </div>
# [19:33] <fantasai> bz: If there aer no ::first-lien styles, then we've just decided the run-in is color: blue
# [19:34] <fantasai> bz: If there is a ::first-line style on the second <div>, what happens?
# [19:34] <fantasai> bz: If that ::first-line style also sets color: orange, what happens?
# [19:34] <fantasai> (orcolor: yellow; )
# [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?
# [19:36] <TabAtkins> plinss: yes.
# [19:36] <TabAtkins> plinss: You're in effect getting two separate first-line boxes.
# [19:37] <TabAtkins> TabAtkins: Is this actually any more difficult than current ::first-line behavior?
# [19:38] <bz> of course
# [19:38] <TabAtkins> dbaron: I don't think we implement the full ::first-line behavior anyway, so we can't really say.
# [19:38] <bz> first-line + inheritance is just a bad scene, no matter what
# [19:38] <TabAtkins> fantasai: counterproposal is to ignore ::first-line for run-ins always.
# [19:38] * annevk still likes the idea of dropping run-in :)
# [19:40] <TabAtkins> 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.
# [19:40] * Quits: markusm (mmielke@72.254.93.74) (Ping timeout)
# [19:40] <TabAtkins> dbaron: I think it's more consistent to say the run-in always ignores ::first-line.
# [19:42] <Bert> [Fantasai copies bz's mark-up to the flipover and starts drawing...]
# [19:43] <bz> annevk, can we drop first-line too? ;)
# [19:44] <annevk> I wouldn't mind :)
# [19:44] <TabAtkins> fantasai: Does ::first-line have values for properties that aren't epxlicitly set on it?
# [19:45] <TabAtkins> alex: I've ejust tried this in several browsers.
# [19:46] <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
# [19:46] <TabAtkins> alex: In IE8, the run-in does inherit from parent first-line, but not sibling first-line
# [19:46] <TabAtkins> alex: FF and Opera it doesn't make it a run-in.
# [19:46] * annevk ... the way it works with inheritance and how it may have to depend on the property is just too hairy
# [19:47] <TabAtkins> alex: IN Safari, the ancestor style is ignored, and the run-in gets the sibling's ::first-line.
# [19:47] <TabAtkins> dbaron: Just punt it as undefined and move on?
# [19:47] <TabAtkins> fantasai: 2 things we can leave undefined.
# [19:48] <TabAtkins> fantasai: 1 is inheritance for run-ins in general. 2 is inheritance for run-ins just in ::first-line.
# [19:49] <TabAtkins> 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.
# [19:49] <bz> mmm yummy undefined
# [19:49] <TabAtkins> RESOLVED ADDENDUM: Undefined for CSS2.1, maybe for CSS3 (Box Module may be able to take care of it.)
# [19:50] * bz looks forward to implementing "the simplest thing that doesn't crash"
# [19:50] <fantasai> :)
# [19:50] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
# [19:50] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [19:50] * Quits: kohei (kohei@72.254.59.20) (Quit: Computer goes to sleep!)
# [19:50] * bz has no outstanding run-in issues
# [19:50] <fantasai> yay!
# [19:50] <bz> well, other than the fact that I have to write the code... ;)
# [19:50] * Joins: bradk (bradk@72.254.101.220)
# [19:50] * Quits: plinss (plinss@72.254.59.50) (Quit: plinss)
# [19:51] <tantek> http://wiki.csswg.org/planning/tpac-2009
# [19:51] * fantasai thinks her next contract should be "deal with outstanding css2.1 issues"
# [19:51] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [19:52] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
# [19:53] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
# [19:55] * bz is going to sign off, since we seem to be done with run-in
# [19:57] <ChrisL> bz, yes we are on break now
# [19:58] * Joins: markusm (mmielke@72.254.124.123)
# [19:58] <dbaron> bz, yep
# [19:58] <dbaron> Zakim, who is on the phone?
# [19:58] <Zakim> On the phone I see Salon_9, bzbarsky
# [19:58] * Quits: mjs (mjs@72.254.84.91) (Quit: mjs)
# [19:58] <dbaron> Zakim, disconnect Salon_9
# [19:58] <Zakim> Salon_9 is being disconnected
# [19:58] <Zakim> -Salon_9
# [19:59] * bz hangs up
# [19:59] <bz> time for another meeting in 2 mins, yay
# [20:02] * Joins: kohei (kohei@72.254.59.20)
# [20:05] * Joins: glazou (glazou@72.254.63.160)
# [20:06] * Joins: mjs (mjs@72.254.84.91)
# [20:10] * Joins: bradk (bradk@72.254.101.220)
# [20:15] * Joins: dsinger (dsinger@72.254.82.131)
# [20:16] * Joins: plinss (plinss@72.254.59.50)
# [20:17] <dbaron> Zakim, who is on the phone?
# [20:17] <Zakim> On the phone I see bzbarsky
# [20:17] <dbaron> Zakim, disconnect bzbarsky
# [20:17] <Zakim> bzbarsky is being disconnected
# [20:17] <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
# [20:17] <Zakim> Attendees were SteveZ, Salon_9, +1.617.487.aaaa, bzbarsky
# [20:17] <dbaron> Zakim, remind us in 7 hours to go home
# [20:17] <Zakim> ok, dbaron
# [20:17] <dbaron> RRSAgent, pointer?
# [20:17] <RRSAgent> See http://www.w3.org/2009/11/03-CSS-irc#T19-17-50
# [20:18] <dbaron> RRSAgent, make logs public
# [20:18] <RRSAgent> I have made the request, dbaron
# [20:18] <dbaron> RRSAgent, this meeting spans midnight
# [20:18] <RRSAgent> ok, dbaron; I will not start a new log at midnight
# [20:18] * Joins: TabAtkins (chatzilla@72.254.99.227)
# [20:21] <Bert> Scribe: Bert
# [20:21] <Bert_lap> Scribe: Bert_lap
# [20:22] <Bert_lap> [Discussion about which issues need discussion]
# [20:24] * tantek changes topic to 'selectors'
# [20:24] <Bert_lap> Topic: Selectors
# [20:24] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2009Nov/0022.html
# [20:24] <TabAtkins> Default attribute thread
# [20:25] <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
# [20:25] <Bert_lap> http://www.w3.org/mid/4AEFE294.8070104@inkedblade.net
# [20:25] <Bert_lap> Fantasai: Default attributes, e.g., colspan is default 1. Can you match against them?
# [20:26] <Bert_lap> ... Spec leaves it open.
# [20:26] <Bert_lap> ... Should we allow both behaviors?
# [20:26] <Bert_lap> ... Most impl. don't match default attrs.
# [20:27] <Bert_lap> Tantek: Impl. shouldn't be required to read DTD, so they don't necessarily know the default.
# [20:27] <Bert_lap> ... That's the background behind the current spec.
# [20:27] <Bert_lap> Glazou: You *can* check if an attribute is absent.
# [20:28] <Bert_lap> DavidB: But need to select all unknowns, can get a long selector...
# [20:28] <Bert_lap> Fantasai: So agreed that spec allows both matching and not matching?
# [20:28] * Parts: glazou (glazou@72.254.63.160)
# [20:28] * Joins: glazou (glazou@72.254.63.160)
# [20:28] * Parts: glazou (glazou@72.254.63.160)
# [20:28] <Bert_lap> Arron: Are you goin gto send proposed text?
# [20:28] <Bert_lap> Fantasai: Yes, I will.
# [20:29] * Joins: glazou (glazou@72.254.63.160)
# [20:29] <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
# [20:29] <Bert_lap> Fantasai: Next is impl. reports. Looks like Opera fails several. Do we have other impls.?
# [20:29] <Bert_lap> ChrisL: Webkit was not tested yet.
# [20:29] <Bert_lap> DaivdB: Webkit seems pretty good.
# [20:29] <Bert_lap> ChrisL/DavidB: 15C may not matter
# [20:30] <Bert_lap> [DavidB trying out things in webkit.]
# [20:30] <dbaron> we don't have 2 impls for 174a, 174b, and d3
# [20:30] <dbaron> also 0 impls for 15c, but I don't think that matters
# [20:30] <dbaron> Mozilla is the only impl passing 174a, 174b, and d3 that I know of
# [20:31] <Bert_lap> Glazou: I am trying to get impl. report from zoomorama(sp?}
# [20:31] <Bert_lap> Fantasai: Should we also look at Prince?
# [20:32] <Bert_lap> Glazou: Yes, Prince is interesting.
# [20:32] <Bert_lap> ... May also look at Andrew Fedoniouk's HTMLayout.
# [20:32] <Bert_lap> [Several discussions at the same time]
# [20:33] <Bert_lap> Fantasai: I'll run tests on Prince.
# [20:33] <Bert_lap> ChrisL: I can try Webkit.
# [20:34] <Bert_lap> [Discussion about most efficient way to quickly press keys.]
# [20:34] <Bert_lap> Fantasai: We need another impl. for some tests. Webkit not enough.
# [20:34] * Joins: Kai (chatzilla@72.254.88.78)
# [20:34] <Bert_lap> ChrisL: I talked to Opera about their failures. Maybe they can do something about it.
# [20:35] <Bert_lap> Beth: I tested the failures and they still fail in latest build.
# [20:35] <Bert_lap> Topic: Color and gamma correction
# [20:35] * tantek changes topic to 'CSS3 Color and gamma correction'
# [20:35] <Bert_lap> DavidB: Gamma may not be the right term.
# [20:36] <Bert_lap> ... Colors are in sRGB.
# [20:36] <Bert_lap> ... But nobody really impleents it.
# [20:36] <dsinger> see 3.1.1 in http://www.w3.org/TR/css3-color/
# [20:36] * Quits: markusm (mmielke@72.254.124.123) (Ping timeout)
# [20:36] <Bert_lap> ... Do we relax the spec?
# [20:36] <Bert_lap> ChrisL: On many platforms sRGB is right by default.
# [20:37] <Bert_lap> Beth: Not on the mac.
# [20:37] <Bert_lap> DavidB: 2nd question is do we give authors a way to opt in?
# [20:37] <Bert_lap> ... Plugins are a known problem.
# [20:38] <Bert_lap> ... The right thing would be to treat CSS colors as well as untagged images to be in sRGB.
# [20:38] <Bert_lap> ... I don't know what Flash defines.
# [20:38] <Bert_lap> ChrisL: Nothing.
# [20:38] <Bert_lap> DavidB: Flash guys may be interested in defining something.
# [20:38] <Bert_lap> ... But we may also want to give authors a choice.
# [20:38] <ChrisL> s/Nothing/No color management, currently/
# [20:39] <fantasai> Prince passes 174a and 174b and 15c
# [20:39] <fantasai> fails d3 (since it's dynamic)
# [20:39] <Bert_lap> DavidS/Beth: A vague idea we had:
# [20:39] <Bert_lap> ... An ability to turn it on with a property.
# [20:39] <Bert_lap> ... Not crazy about the idea, but needed it for a client.
# [20:39] <Bert_lap> Tantek: So you needed it per element?
# [20:40] <fantasai> Konqueror passes d3
# [20:40] <Bert_lap> ChrisL: A need per element maybe because of video, of which there is more and more,as well as tagged images.
# [20:41] <Bert_lap> DavidS: And if you it on body, it applies to everything?
# [20:41] <Bert_lap> ... Example: a background behind a flash, and only that, should be uncorrected.
# [20:42] <Bert_lap> Beth: We don't want to override color profiles when explicit in an image.
# [20:42] <ChrisL> Need to override *tagged* immages is minimal
# [20:42] <Bert_lap> DaviDS: There are also many incorrectly tagged images.
# [20:42] <Bert_lap> DavidB: Gecko now corrects tagged images.
# [20:42] <Bert_lap> Tantek: DavidS, what do you want, more precisely?
# [20:43] <ChrisL> Not clear that there are many incorrectly tagged images
# [20:43] <Bert_lap> DavidS: You can say that the color space of this element is such and such, or is 'none'.
# [20:43] <Bert_lap> Tantek: And if the image is tagged, it will override?
# [20:43] <Bert_lap> ... So you described the 'auto' value that we had in a previous draft.
# [20:44] <Bert_lap> DavidB: But we also need our current behavior.
# [20:44] <Bert_lap> ... Which is not interoperable.
# [20:44] <Bert_lap> DavidS: But it is consistent in a single browser.
# [20:46] * dsinger does anyone have a pointer to the previous version that had this feature?
# [20:46] <Bert_lap> Beth: We want 'auto' to match whatever browser decides to do. Which may even change over time...
# [20:46] <Bert_lap> Tantek: If you use 'auto', you cannot count on any specific behavior.
# [20:47] <Bert_lap> DavidB: You can count on it being consistent with a single browser.
# [20:47] <Bert_lap> DavidS: We may want to force platform-specific colors.
# [20:47] <Bert_lap> DavidB: Not sure we want that.
# [20:47] * Joins: myakura (myakura@72.254.84.172)
# [20:48] <Bert_lap> Tantek: Would there be no standardized value in the UA style sheet?
# [20:48] * glazou just noticed tantek has two macs in front of him, the good ol'days are back :-)
# [20:48] <Bert_lap> ChrisL: Difference between platform color spce and platform specific behavior, which may be color managed.
# [20:49] <Bert_lap> DavidB: Mozilla changed to be compatible with Webkit and go a lot of negative feedback.
# [20:49] <Bert_lap> Tantek: 'Default' could be another keyword.
# [20:50] <Bert_lap> ... It means you cannot count on cross-platform conistency.
# [20:50] <Bert_lap> Beth: Sounds good.
# [20:50] <Bert_lap> ... It means: what UA would do if the property weren't specified at all.
# [20:50] <Bert_lap> ... That can change over time.
# [20:50] <Bert_lap> ... E.g., at the moment we don't do color managament at att.
# [20:50] <Bert_lap> ... But we may do so in the future.
# [20:51] <Bert_lap> s/att/all/
# [20:51] <Bert_lap> Tantek: So 'auto' means treat as sRGB, except for images that are tagged.
# [20:51] <Bert_lap> ... And 'sRGB' means override the image tags.
# [20:52] <ChrisL> Pointer to the relevant part of the old spec http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
# [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:53] <Bert_lap> Tantek: a'uto' exactly as that quoted text.
# [20:54] <Bert_lap> Tantek: And just two values seems enough.
# [20:54] <Bert_lap> Brad: Wrong tags in images?
# [20:54] <dsinger> note that the correct application of color spaces in plugins is the responsibility of the plugin and not the browser
# [20:55] <ChrisL> Brad is concerned about images saves with incorrect profiles, which was not noticed because browsers only started dealing with tagged images fairly recently
# [20:55] <Bert_lap> DavidB: That will never cause probelsm on some machine but not others. You will see the problem immediately.
# [20:55] <dsinger> note that the color spaces used in video are different, and the color correction of video is handled by the video subsystem
# [20:55] <Bert_lap> Peter: Didn't you, DavidB, say there were tools that generated wrongly tagged images?
# [20:55] <Bert_lap> DavidB: I think I said there were many untagged images.
# [20:56] <Bert_lap> chrisL: Most common tag is Adobe RGB.
# [20:56] <Bert_lap> DavidS: I want authors to tag images correctly.Not provide a work-around.
# [20:56] <ChrisL> most common after untagged, or tagged as sRGB, is AdobeRGB
# [20:57] <Bert_lap> [Discussion of DavidS text above]
# [20:57] <Bert_lap> ChrisL: Untagged video is almost sRGB in practice.
# [20:58] <Bert_lap> Tantek: Can DavidS find out if it is OK to treat unagged video as sRGB?
# [20:58] <ChrisL> its the same primaries (CCIR 709 primaries) the transfer curve is slightly different
# [20:58] <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
# [20:58] <tantek> specifically
# [20:59] <tantek> 'sRGB'
# [20:59] <Bert_lap> ACTION on DavidS check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
# [20:59] * trackbot noticed an ACTION. Trying to create it.
# [20:59] <trackbot> Sorry, couldn't find user - on
# [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.
# [20:59] * trackbot noticed an ACTION. Trying to create it.
# [20:59] <trackbot> Sorry, couldn't find user - on
# [21:00] <ChrisL> ACTION: DavidS to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
# [21:00] * trackbot noticed an ACTION. Trying to create it.
# [21:00] <trackbot> Sorry, couldn't find user - DavidS
# [21:00] * RRSAgent records action 1
# [21:00] <ChrisL> trackbot, status
# [21:00] * trackbot knows about the following 39 users: Alex, Chris, Timothy, Masayuki, Elika, Peter, Anne, Daniel, Yasuhiro, Steve, Cesar, Shinyu, Beth, Svante, Saloni, Jeff, Tokushige, David, Robert, Arron, Giorgi, Øyvind, David, Ian, John, Bert, Sylvain, Tab, Molly, Markus, Brad, Chris, David, Emily, Håkon Wium, Ben, Dean, Simon, Tona
# [21:00] <ChrisL> ACTION: Dsinger to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
# [21:00] * trackbot noticed an ACTION. Trying to create it.
# [21:00] <trackbot> Sorry, couldn't find user - Dsinger
# [21:00] * RRSAgent records action 2
# [21:00] <ChrisL> ACTION: singer to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
# [21:00] * trackbot noticed an ACTION. Trying to create it.
# [21:00] * RRSAgent records action 3
# [21:00] <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].
# [21:01] * ChrisL finally!
# [21:02] <Bert_lap> RESOLUTION: re-add a 'color-profile'-like property with the two values 'auto' and 'srgb'
# [21:02] <smfr> s/auto/default
# [21:03] <Bert_lap> Beth: We are working on -webkit- prefixed property, May be available by end of week.
# [21:03] <ChrisL> s/color-profile/color-correction/
# [21:03] <Bert_lap> ChrisL: Name should not clash with SVG.
# [21:04] <Bert_lap> Tantek: Other name is fine.
# [21:04] <Bert_lap> Tantek: call it 'color-correction'
# [21:05] <Bert_lap> DavidB: Per element is harder than per document.
# [21:05] <Bert_lap> ChrisL: Won't be changed very often.
# [21:06] <Bert_lap> [Dicussion about allowing UA to only do per document.]
# [21:06] <Bert_lap> Tantek: So require per-element?
# [21:06] <ChrisL> please lets
# [21:07] <Bert_lap> DavidB: I don't want to have to check it for every color paint.
# [21:08] <tantek> also proposed: drop section 3.1.1 Gamma correction
# [21:08] <Bert_lap> Bert: How do you get untagged images to match CSS text?
# [21:08] <tantek> http://www.w3.org/TR/2008/WD-css3-color-20080721/#gamma
# [21:09] <Bert_lap> Tantek: You say 'color-correction: srgb'
# [21:10] <Bert_lap> ChrisL: Do we have sufficient text for this property?
# [21:10] <Bert_lap> Tantek: Yes, everything is in IRC [above]
# [21:10] <Bert_lap> DavidB: Another last call for Color?
# [21:10] <Bert_lap> Tantek: Can we not go to CR with this change?
# [21:10] <Bert_lap> ChrisL: It's a change, needs a WD.
# [21:11] <Bert_lap> ... But can go straight to PR after the LC, if we have implementation reports.
# [21:11] <Bert_lap> .. So, write the test, and make sure UAs pass them, in particular Safari and Firefox.
# [21:12] <Bert_lap> ... Opera doesn't do color management. I want to try to get them to change.
# [21:12] <tantek> write tests including vendor prefixed properties for color-correction to allow for those implementations to enable passing the tests.
# [21:12] <Bert_lap> ... Some of the platforms it runs on are hard to determine.
# [21:12] <Bert_lap> Arron: We don't do color management either.
# [21:13] <Bert_lap> DavidB: Is 'srgb' the right keyword?
# [21:13] <ChrisL> s/needs a WD/needs a Last Call/
# [21:13] <Bert_lap> Tantek: We can always add 'srgb-force-damnit'...
# [21:13] <Bert_lap> DaviDB: Also, retract that comment.
# [21:13] <Bert_lap> Glazou: Next steps?
# [21:14] <Bert_lap> ChrisL: Some editing, test cases, LC, and PR.
# [21:14] <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Color/current/
# [21:15] <ChrisL> http://www.w3.org/Style/CSS/Test/CSS3/Color/20081014/reports/
# [21:15] <Bert_lap> RESOLUTION: drop section 3.1.1
# [21:17] <Bert_lap> Topic: Media Quries in HTML5 video
# [21:17] <Bert_lap> DavidS: Proposal is to add media query to VIDEO element.
# [21:17] <Bert_lap> ... And then also add queries for the user's special needs.
# [21:18] <Bert_lap> Glazou: Seems like a good idea. I never thought it was just the media, always the context.
# [21:18] <Bert_lap> Tantek: So DavidS want some new terms to be added to the spec.
# [21:19] <Bert_lap> ... And then a new LC.
# [21:19] <Bert_lap> Several: Or a second version.
# [21:19] <Bert_lap> General agreement to not change the current spec, but write a new one.
# [21:19] <Bert_lap> ChrisL: So just a draft for the new values, not repating the old ones?
# [21:19] <Bert_lap> Glazou: Yes.
# [21:20] <Bert_lap> Topic: ftf dates 2010
# [21:21] <Bert_lap> Old proposal was 22-24 March, but AC is 21-22 March, and in Boston, not in California.
# [21:22] <Bert_lap> DavidS: 23-25 in Boston is possible, if we have a host...
# [21:22] <Bert_lap> DavidB: Do we have the list of conflicts still from last time we discussed this?
# [21:23] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0179.html
# [21:24] <Bert_lap> DavidB: SXSW is Mar 12-16, WWW2010 is Apr 26-30
# [21:24] <Bert_lap> ... How many people *will* be at AC?
# [21:25] <Bert_lap> DavidS: I will need to be at AC, but need not be in CSS WG.
# [21:25] <Bert_lap> Fantasai: I'd like to be on east coast around that time.
# [21:26] <Bert_lap> Bert: Organizing at W3C is likely to be possible.
# [21:26] <dsinger> http://www.w3.org/Member/Eventscal
# [21:27] <Bert_lap> ChrisL: Co-locating with WWW2010, in Raleigh, NC?
# [21:28] <Bert_lap> DavidB: How many will go there?
# [21:28] <Bert_lap> [Discussion about weather in Boston in March.]
# [21:29] <Bert_lap> Fantasai: How many would come in Calif? How many would come in Boston?
# [21:29] <Bert_lap> DavidS: 24-26 March, the rest of the week after AC.
# [21:29] <Bert_lap> [Looking for Easter dates.]
# [21:30] <Bert_lap> Glazou: And August?
# [21:30] <Bert_lap> DavidB: SteveZ had a family event conflict.
# [21:31] * annevk wonders when CSS will have lunch
# [21:31] <Bert_lap> [Currently scheduled for Oslo, Aug 18-20]
# [21:31] * Bert_lap : right now, in theory.
# [21:31] * annevk cool, me too
# [21:31] <Bert_lap> DavidS: I also have a conflict for Aug.
# [21:32] * Quits: Lachy (Lachlan@72.254.56.137) (Quit: This computer has gone to sleep)
# [21:32] <Bert_lap> Glazou: Let's keep August as it is for now. Now Håkon here anyway.
# [21:32] * sylvaing .csswg { transition: lunch 1mn; }
# [21:32] <glazou> s/Now/not
# [21:32] <Bert_lap> DavidS: 2 questions for W3C: host in March? and is there a TPAC end of the year?
# [21:32] * Quits: dethbakin (dethbakin@72.254.103.251) (Quit: dethbakin)
# [21:33] <Bert_lap> LUNCH
# [21:33] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
# [21:33] * Quits: dbaron (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [21:33] * Quits: jdaggett (jdaggett@72.254.82.75) (Quit: jdaggett)
# [21:33] * Quits: smfr (smfr@72.254.92.79) (Quit: smfr)
# [21:33] * Quits: dsinger (dsinger@72.254.82.131) (Quit: dsinger)
# [21:33] * Quits: plinss (plinss@72.254.59.50) (Quit: plinss)
# [21:34] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [21:34] * Quits: TabAtkins (chatzilla@72.254.99.227) (Ping timeout)
# [21:34] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [21:35] * Quits: kohei (kohei@72.254.59.20) (Quit: Computer goes to sleep!)
# [21:35] * Quits: annevk (opera@72.254.82.30) (Quit: annevk)
# [21:35] * Quits: tantek (tantek@72.254.103.162) (Quit: tantek)
# [21:35] * Quits: Kai (chatzilla@72.254.88.78) (Ping timeout)
# [21:35] * Quits: sylvaing (sylvaing@72.254.86.181) (Ping timeout)
# [21:35] * Quits: Arron (arronei@72.254.101.153) (Ping timeout)
# [21:35] * Quits: alexmog (alexmog@72.254.94.217) (Ping timeout)
# [21:37] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [21:38] * Quits: hamaji (hamaji@72.254.92.142) (Ping timeout)
# [21:38] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [21:40] * Quits: Bert_lap (bert@128.30.52.169) (Ping timeout)
# [21:40] * Quits: mjs (mjs@72.254.84.91) (Quit: mjs)
# [21:54] * Quits: myakura (myakura@72.254.84.172) (Quit: Leaving...)
# [22:02] * Joins: jdaggett (jdaggett@72.254.82.75)
# [22:10] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
# [22:15] * Joins: TabAtkins (chatzilla@72.254.99.227)
# [22:15] * Joins: Curt` (curt@76.241.65.125)
# [22:15] * Joins: bradk (bradk@72.254.101.220)
# [22:15] * Joins: markusm (mmielke@72.254.93.74)
# [22:20] * Joins: Kai (chatzilla@72.254.88.78)
# [22:20] * Quits: TabAtkins (chatzilla@72.254.99.227) (Connection reset by peer)
# [22:21] * Joins: mjs (mjs@72.254.84.91)
# [22:21] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [22:22] * Joins: bradk (bradk@72.254.101.220)
# [22:22] * Joins: Arron (arronei@72.254.101.153)
# [22:23] * Joins: dbaron (dbaron@63.245.220.11)
# [22:27] * Joins: Lachy (Lachlan@72.254.56.137)
# [22:29] * Joins: dethbakin (dethbakin@72.254.103.251)
# [22:30] * Joins: glazou (glazou@72.254.63.160)
# [22:30] * Joins: hamaji (hamaji@72.254.92.142)
# [22:31] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
# [22:32] * Joins: annevk (opera@72.254.82.30)
# [22:32] * Quits: bradk (bradk@72.254.101.220) (Quit: Computer has gone to sleep)
# [22:33] * Joins: shepazu (schepers@128.30.52.169)
# [22:33] * Joins: tantek (tantek@72.254.103.162)
# [22:34] * Joins: TabAtkins (chatzilla@72.254.99.227)
# [22:34] * Joins: plinss (plinss@72.254.59.50)
# [22:35] * Joins: dsinger (dsinger@72.254.82.131)
# [22:36] * Joins: Bert_lap (bert@128.30.52.169)
# [22:36] * Joins: alexmog (alexmog@72.254.94.217)
# [22:37] * Joins: smfr (smfr@72.254.92.79)
# [22:38] * Joins: glazou (glazou@72.254.63.160)
# [22:38] * Joins: bradk (bradk@72.254.101.220)
# [22:38] * Joins: ChrisL (ChrisL@128.30.52.169)
# [22:39] * Joins: kohei (kohei@72.254.59.20)
# [22:39] <dsinger> followed by a break for non-persistent cookies
# [22:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# [22:40] * Joins: ChrisL (ChrisL@128.30.52.169)
# [22:40] <ChrisL> Scribe: Chris
# [22:40] <ChrisL> ScribeNick: ChrisL
# [22:40] <ChrisL> Topic: Test suite status
# [22:43] <ChrisL> Aaron: What's that staus, who has reviewed their tests
# [22:43] * tantek changes topic to 'Test suite status'
# [22:43] <ChrisL> Elika: I'm doing a coverage report
# [22:43] <ChrisL> AAron: Still targetting 15 January?
# [22:43] <ChrisL> Elika: yes
# [22:44] <ChrisL> s/Aaron/Arron/
# [22:44] * Joins: bradk_ (bradk@72.254.102.156)
# [22:44] <dbaron> s/AAron/Arron/
# [22:44] <ChrisL> action: arron to create a template fr CSS 2.1 test suite reports
# [22:44] * trackbot noticed an ACTION. Trying to create it.
# [22:44] * RRSAgent records action 4
# [22:44] <trackbot> Created ACTION-195 - Create a template fr CSS 2.1 test suite reports [on Arron Eicholz - due 2009-11-10].
# [22:44] <ChrisL> s/Aaron/Arron/
# [22:44] <glazou> BTW, not sure everyone in the WG got news from Robert Stevahn : http://twitpic.com/o63vs :-)
# [22:45] <ChrisL> Elika: we have implementations for all selectors tests, counting prince, webkit, opea and firefox
# [22:45] * Joins: sylvaing (sylvaing@72.254.86.181)
# [22:45] <ChrisL> ... appart from the 15c subtest which needs multiple id support, already listed as feature at risk
# [22:46] <ChrisL> glazou: champagne
# [22:46] * Quits: bradk_ (bradk@72.254.102.156) (Quit: Colloquy for iPhone - http://colloquy.mobi)
# [22:47] <ChrisL> http://www.cardsunlimited.com/largeimage/Champagne.jpg
# [22:48] * dbaron thought the resolution was 1400x1050 :-)
# [22:48] <ChrisL> Resolution: Advance to Proposed Recommendation for the Selectors spe
# [22:48] <ChrisL> s/spe/spec/
# [22:50] <ChrisL> Topic: Gradients and Image Sprites
# [22:50] <ChrisL> Arron: recall this had to but not sure what it is
# [22:51] <ChrisL> David: Who added it
# [22:51] <ChrisL> Tab: Not sure what it means either
# [22:51] <ChrisL> (we are all confused)
# [22:52] <ChrisL> Tab: Asked Shepazu to help with SVG equivalents of the gradient examples
# [22:52] <ChrisL> ... for sprites, its choosing between options
# [22:52] <ChrisL> Elika: No, i just liked to the various proposals
# [22:52] <ChrisL> David: We implemented moz-image-rect
# [22:53] <ChrisL> Elika: the URI based syntax has no fallback. Could addit by putting it im the image not in the URI
# [22:53] <ChrisL> Elika: no need to a separate functional notation.
# [22:53] <dbaron> s/moz-image-rect/-moz-image-rect()/
# [22:53] <ChrisL> ... if linked to image functional notation and require both to be iplemented
# [22:54] <ChrisL> ... waiting for media fragments wg to publish a spec
# [22:54] <ChrisL> Elika: Image sprites should make it more efficient that specifying explicit coods in the stylesheet
# [22:54] <ChrisL> ... not so much to discuss therefore
# [22:55] * Joins: szilles (chatzilla@72.254.83.13)
# [22:55] <ChrisL> Simon: I have some feedback, will send on list
# [22:55] <ChrisL> ACTION: Simon to send gradients feedback to www-style
# [22:55] * trackbot noticed an ACTION. Trying to create it.
# [22:55] * RRSAgent records action 5
# [22:55] <trackbot> Created ACTION-196 - Send gradients feedback to www-style [on Simon Fraser - due 2009-11-10].
# [22:56] <bradk> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
# [22:56] <ChrisL> Topic: Drop shadows
# [22:56] <ChrisL> (brad demonstrates)
# [22:59] <ChrisL> brad: we want something that casts a shadow under the element, casts from background and border
# [23:00] <ChrisL> ... transparecy affects the color of the shadow where it overlaps. based on alpha channel
# [23:00] <ChrisL> (brad fiddles with the drop shadow dialog in photoshop)
# [23:01] <ChrisL> Brad: shadow has translucency
# [23:02] <ChrisL> ... inner version of a shadow
# [23:03] <ChrisL> Chris: Please define how you are using the term inner
# [23:03] <fantasai> CSS2.1 coverage report (thrown rather haphazardly together, somewhat incomplete): http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0002/index.xht
# [23:03] <ChrisL> Brad: the shape is cut out of the background and the shadow is on that
# [23:04] <ChrisL> Chris: the shadow is in fact still on top
# [23:04] <ChrisL> Brad: yes
# [23:04] <ChrisL> (we discover the projector really needs color management)
# [23:06] <ChrisL> Brad: so this is easy with sharp edges. with soft edges people seemed to be confused
# [23:06] <ChrisL> Chris: its the same copy, remove color, add color, blur, opacity operation
# [23:08] <ChrisL> Chris: notice you are using blending modes - svg has those
# [23:11] <ChrisL> (discussion on what exactly is happening in photoshop as people get their heads around it)
# [23:11] <ChrisL> Simon: Easier to look at the actual proposal
# [23:14] <ChrisL> Tab: the shadow is cast by a negative of the alpha channel, then clipped to the actual alphs channel
# [23:16] <ChrisL> John: what is the use case for this?
# [23:17] <ChrisL> ... the photoshop is not convincing me of the utility
# [23:17] <ChrisL> Elika: We have box shadows already
# [23:17] <ChrisL> David: And we implement that, but lets decide if this part is useful before deciding exactly how it works
# [23:18] <ChrisL> (brad demonstrates inner shadow on text)
# [23:19] <ChrisL> Simon: With box and text shadow, the shadow does not depend on the transparency of the element
# [23:19] <ChrisL> ... fully transparent text still casts a shadow, with text-shadow
# [23:20] <ChrisL> Brad: suppose you want just the border, or the background, or *one* of the backgrounds shaddowed
# [23:20] <ChrisL> Simon: That seems more useful in the filters discussion
# [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
# [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
# [23:21] <bradk> apply-to(border + foreground, background-image + background-color)
# [23:21] <ChrisL> Brad: pluses mean the shapes composite before shadow calculation, commas mean they each have their own shadow
# [23:23] <ChrisL> David; apply-to gives the z-order?
# [23:23] <ChrisL> .. what if you apply to things that are not z-ordered together?
# [23:23] <ChrisL> Elika: you cant composite the text and the background and composite onto the border
# [23:24] <ChrisL> Simon: this is trying to get photoshop into css, i don't see the use case. Separate elements can be used to do this
# [23:25] <ChrisL> 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
# [23:25] <ChrisL> Elika: So SVG filters can be used but we lack the ability to select parts of the border
# [23:25] <ChrisL> John: If the goal is to do something this complex, is CSS the right language?
# [23:27] <ChrisL> Chris: We are headed for a fairly complex selector model if we do this, to get at parets of the border
# [23:28] <ChrisL> Elika: getting the whole border would be sufficient, but we need to address the different background layers
# [23:29] <bradk> ::apply-to(border + foreground, background-image + background-color)
# [23:30] <ChrisL> Chris: could imageine pseudo elements to address the border, the background(s) and the content
# [23:31] <fantasai> Then how do you turn it off?
# [23:31] <fantasai> How many pseudo-elements do you need to write to turn it off?
# [23:31] <fantasai> dbaron: I don't think this is the right way to do it...
# [23:31] <ChrisL> Brad: just targetting the whole border would satisfy my needs
# [23:32] <fantasai> fantasai: The pieces we'd need to address, in various combinations: background layers, border (one piece), content (one piece)
# [23:32] <ChrisL> Brad: we don't want to implement all of svg in css, sure. We want to be eble to use parts of them
# [23:33] <ChrisL> David: we already do SVG filters on any element
# [23:33] <ChrisL> Brad: but only the whole parts
# [23:33] <ChrisL> David: add to source-graphic source-alpha etc to add source-border, source-background ......
# [23:34] <fantasai> dbaron attempts to summarize how svg filters work
# [23:34] <smfr> http://www.w3.org/TR/SVG/filters.html#FilterPrimitivesOverview
# [23:34] <smfr> (scroll down)
# [23:34] <ChrisL> Simon: fill-apint and stroke-paint
# [23:34] * Quits: glazou (glazou@72.254.63.160) (Quit: glazou)
# [23:35] <ChrisL> David: things to address the border, background or contents
# [23:35] <ChrisL> Tab: Could we use parameters with that
# [23:36] <ChrisL> Chris: Sure
# [23:36] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Oct/0072.html
# [23:36] <ChrisL> Elika: need a way to aprameterise that so we have a library of effects and apply them, without writing new filters
# [23:37] <ChrisL> Simon: background image in SVG is what has already been painted by other elements
# [23:38] <ChrisL> Elika: roc has some name suggestions
# [23:38] <ChrisL> Chris: please pass those on to the SVG WG. The editor is Erik Dahlstrom from Opera. We can add them
# [23:38] <ChrisL> David: Put them in the order you want and thats how they end up
# [23:39] <shepazu> [I'd be happy to talk to the CSS about my SVG parameters specification, which could pass parameters through a CSS property]
# [23:39] <jdaggett> shepazu: cmon down dear
# [23:39] <ChrisL> Elika: does not make sense for a border to cast a shadow *under* the background
# [23:40] <fantasai> border casts a shadow immediately under the border, i.e. over the background
# [23:40] <ChrisL> Brad; we should retain the natural stacking order
# [23:41] <fantasai> if border and background ar composited, then their shadow casts underneath the composited layer
# [23:41] <fantasai> i.e. directly underneat the background
# [23:42] * sylvaing next year, Tab's t-shirt: "Shadow. It drops, bitches"
# [23:42] <ChrisL> (discussion on how to pass opacity to a filter)
# [23:46] <ChrisL> Sion: how to get the putput of the filter int he right place
# [23:47] <ChrisL> s/Sion/Simon/
# [23:48] <ChrisL> Shepazu: we are adding more canned filter effects, we could add more if you identify the. Adds a merge for the border etc
# [23:48] * Quits: arronei (arronei@131.107.0.80) (Ping timeout)
# [23:48] <ChrisL> Elika: a filter to make the border and background partly transparent
# [23:49] <ChrisL> Shepazu: filters can be computationally intensive. Though canned filters can be optimised. need to warn authors
# [23:49] <ChrisL> Tab: Yes
# [23:50] <ChrisL> ... but won't trigger unexpectedly. Its clearly an opt-in
# [23:50] <ChrisL> Shepazu: Need to make a tradeoff between power, speed and authoring ease
# [23:50] * Quits: annevk (opera@72.254.82.30) (Quit: annevk)
# [23:50] <ChrisL> Simon: want to see blur and colour manip filters
# [23:51] <ChrisL> Shepazu: sepia, b&w
# [23:51] <ChrisL> Brad: so value in having a simple drop shadow?
# [23:51] <ChrisL> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
# [23:51] * Quits: Lachy (Lachlan@72.254.56.137) (Connection reset by peer)
# [23:52] * Joins: Lachy (Lachlan@72.254.56.137)
# [23:52] <ChrisL> Shepazu: need review from Erik and Anthony
# [23:52] * Quits: alexmog (alexmog@72.254.94.217) (Ping timeout)
# [23:53] <ChrisL> Brad: syntax there is more similar to the existing box-shadow property. Illustrations were done in photoshop
# [23:53] <ChrisL> Shepazu: Need to discuss, only now introducing canned filter effects so open to syntax that makes sense for CSS authors
# [23:53] * Joins: arronei (arronei@131.107.0.104)
# [23:56] <ChrisL> (we look at innter shadow on text again)
# [23:56] <ChrisL> Simon: for canned filters we would likely go to core graphics
# [23:57] <Bert_lap> s/innter/inner/
# [23:58] <ChrisL> Elika: happy to join any SVG telcons about this
# [23:58] * Quits: MoZ (chatzilla@82.230.92.154) (Quit: ChatZilla 0.9.85 [Firefox 3.5.4/20091016081620])
# [23:58] <ChrisL> filters spec is here http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html
# [23:59] * Quits: MikeSmith (MikeSmithX@mcclure.w3.org) (Ping timeout)
# [23:59] <dbaron> http://lists.w3.org/Archives/Public/public-fx/
# [23:59] <ChrisL> Shepazu: there is a public-fx@w3.org list
# [23:59] * Curt` is now known as Curt`|away
# [23:59] <ChrisL> http://lists.w3.org/Archives/Public/public-fx/
# Session Close: Wed Nov 04 00:00:00 2009

The end :)