/irc-logs / w3c / #css / 2011-11-01 / end

Options:

# Session Start: Tue Nov 01 00:00:00 2011
# Session Ident: #css
# [00:00] <TabAtkins_> fantasai: For pages, there are use-cases where you want to feed the blank pages, there are larger use-cases where you *absolutely don't* want that.
# [00:00] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [00:00] * Joins: kojiishi (kojiishi@63.145.238.4)
# [00:01] <TabAtkins_> fantasai: So we should use that as the default, and possibly address the "force blank pages" later.
# [00:01] <TabAtkins_> RESOLVED: Pages work the same as columns - an element at the to pof the page with break-before won't force a blank page.
# [00:01] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
# [00:01] <TabAtkins_> howcome: Now, <div><div></div></div><style>div { break-after: all; }</style>
# [00:02] <TabAtkins_> howcome: Two breaks? Or do they collaps?
# [00:02] <TabAtkins_> fantasai: I think they do collapse. The spec seems to imply that as well.
# [00:02] <TabAtkins_> TabAtkins_: And it's consistent with the decision we just made.
# [00:04] * Joins: howard (howard_wan@63.145.238.4)
# [00:04] <TabAtkins_> alexmog: I don't think any browser currently has that behavior.
# [00:04] * Joins: tpod (tpod@63.145.238.4)
# [00:04] <TabAtkins_> fantasai: I intend to fix that in Mozilla.
# [00:04] <TabAtkins_> alexmog: I think all browsers collapse -after breaks, but not -before breaks.
# [00:05] * Joins: JohnJansen (JohnJansen@63.145.238.4)
# [00:05] * Joins: r12a (rishida@128.30.52.169)
# [00:05] <TabAtkins_> alexmog: Things like the <html> element shouldn't count as "content" before the element, forcing a break. Same with display:none elements.
# [00:06] * Joins: tantek (tantek@63.145.238.4)
# [00:06] <TabAtkins_> fantasai: For <div></div><div></div>, we shouldn't collapse - breaks shouldn't collapse through.
# [00:06] * Joins: plinss (plinss@63.145.238.4)
# [00:06] * Joins: MoZ (MoZ@63.145.238.4)
# [00:06] <fantasai> corrected example: <div>...</div><div/></div>...</div>
# [00:06] <TabAtkins_> szilles: I'm surprised at this. I would think it would be simpler to always honor the breaks, not collapse.
# [00:06] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [00:06] <TabAtkins_> alexmog: Say you have an <h1>, the first thing in the document, and you set break-before on it.
# [00:07] <TabAtkins_> alexmog: But it's *not* actually the first element. <html> and <body> precede it.
# [00:07] <TabAtkins_> szilles: Isn't that consistent with our previous case? If the <h1> is at the top of the page...
# [00:07] * Joins: r12a (rishida@128.30.52.169)
# [00:07] <fantasai> TabAtkins: This is a different case
# [00:08] <fantasai> TabAtkins: In this multicol case, the <div> is literally the first thing on the page
# [00:08] <fantasai> TabAtkins: In the other case, the <h1> is not the first thing on the page, it's wrapped by a <body> and an <html>
# [00:08] <fantasai> szilles: Define that as being at the top of the page
# [00:09] <fantasai> Alex: Orphan control shouldn't .. if you have a region with only room for one line, and we have an element with orphan that has 3 lines
# [00:09] <fantasai> alex: we're currently going to move that to the next region because we're not at the top of the page
# [00:09] * fantasai doesn' tthink the minuted version makes any sense here
# [00:10] <fantasai> alex: You have a long enough paragraph, multiple lines
# [00:10] <fantasai> alex: starts in a region which can fit just one line
# [00:10] <fantasai> alex: which is ok for titles
# [00:10] <fantasai> alex: You want that one line to still be in that region, even though with orphan control will want to keep it with the rest of the parent
# [00:11] <fantasai> alex: The resason these cases are related, is if break-before and break-after are intepreted as I think in the spec
# [00:11] <fantasai> alex: they're not "make sure there's a break here", it's "make sure this is the first thing on the page"
# [00:11] * Joins: shepazu (shepazu@128.30.52.169)
# [00:11] <fantasai> alex: For both widow/orphan and breaks, you're still looking at whether you're the first thing on the page
# [00:11] <fantasai> alex: opening tags don't count as making you not at the top of the page
# [00:12] <fantasai> szilles: That would just fall out of the deifnition, which is make sure this is the first thing on the page
# [00:12] <fantasai> howcome: ...
# [00:13] <fantasai> howcome: <chapter><section></section.</chapter>
# [00:13] <TabAtkins_> howcome: You'd like to break before/after both the sections and chapters.
# [00:13] <fantasai> howcome: You want each chapter to start on the first page, and each section to start on the first. You want to set break-before
# [00:13] <TabAtkins_> fantasai: 2.1 says that when determining breaks, you look at the break properties of all the elements that meet at the given margin.
# [00:13] <TabAtkins_> fantasai: It's pretty vague, unfortunately.
# [00:14] <TabAtkins_> alexmog: page breaks don't prevent margin collapsing, though...
# [00:15] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [00:15] <alexmog> http://www.w3.org/TR/CSS21/page.html#forced
# [00:15] <TabAtkins_> TabAtkins_: Specifically, the definition of "top of a page" is underdefined. Does a marging or border on a parent make you no longer at the to pof a page? (The correct answer is no.)
# [00:15] <fantasai> dbaron: It needs to be defined in a whole bnch of cases. Frex Mozilla has mTopOfPage, which deals solely with the possibility of somethng not fitting -- it lets us know
# [00:16] <fantasai> dbaron: if we have made any progress in putting things on the page, so that we don't keep breaking and placing no content
# [00:16] <fantasai> dbaron: For that border does count
# [00:16] * Joins: homata (homata@58.158.182.50)
# [00:16] <TabAtkins_> alexmog: Having <body> as your parent, even with ??? is honored.
# [00:17] <TabAtkins_> alexmog: If you look at break-after, which is supposed to be consistent with break-before, all browsers collapse break-after.
# [00:17] <TabAtkins_> szilles: Isn't that the same rule/difficulty in determining if something is at the end of the page?
# [00:17] <TabAtkins_> alexmog: Yes.
# [00:17] <TabAtkins_> alexmog: [some sectoin] has a very simply rule that just says a forced break occurs when any elements contributing to the current margin have a forced break.
# [00:17] <TabAtkins_> alexmog: So you go and do normal margin collapsing, then look at the result.
# [00:18] <fantasai> ...
# [00:18] <fantasai> alexmog reads from CSS2.1 spec
# [00:18] <TabAtkins_> fantasai: It wouldn't have been written with more than one element if collapsing wasn't meant to happen.
# [00:18] <fantasai> s/one/two/
# [00:19] <TabAtkins_> howcome: So we can just clarify 2.1 if it' snot fully clear.
# [00:19] * Joins: tobie (tobie@63.145.238.4)
# [00:19] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
# [00:20] <TabAtkins_> szilles: Doesn't the margin definition break if you put a border on <chapter>?
# [00:20] <TabAtkins_> TabAtkins_: Yes, and that's bad.
# [00:20] <TabAtkins_> dbaron: What happens if one says 'left' and the other says 'right'?
# [00:20] <TabAtkins_> howcome: I say you choose whichever one grants you the most pagebreaks.
# [00:21] <TabAtkins_> fantasai: When collapsing breaks there's nothing "between" your breaks. I think you should choose the last one, because it's the one closest to the next content.
# [00:22] <TabAtkins_> howcome: I'd like to have a resolution because we're in CR, and we need testcases written.
# [00:22] * Joins: szilles (chatzilla@63.145.238.4)
# [00:22] <TabAtkins_> howcome: I can live with the last one winning if there are conflicts.
# [00:22] * Quits: tobie (tobie@63.145.238.4) (Ping timeout)
# [00:23] <TabAtkins_> fantasai: The spec is pretty clear that a series of page breaks should never generate more than one page break in series.
# [00:23] <TabAtkins_> howcome: Okay, so collapsing works. Do borders stop break collapsing?
# [00:23] <TabAtkins_> alexmog: They block margin collapsing, so.
# [00:23] * Joins: dbaron (dbaron@63.145.238.4)
# [00:24] <TabAtkins_> howcome: Can't we just lean on margin collapsing's rule?
# [00:24] <TabAtkins_> fantasai: I don't think there's *ever* a use-case for having a border around a blank page with this.
# [00:24] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [00:24] <TabAtkins_> alexmog: the 2.1 definition is based on margin-collapsing.
# [00:25] <fantasai> Florian: We should prioritize authors over implementations, and authors don't want a blank page with just a border.
# [00:25] <TabAtkins_> alexmog: And if we can avoid changing the very complicated margin-collapsing, that's good.
# [00:25] <fantasai> szilles advocates for just coming up with a good definition for top-of-page
# [00:26] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [00:26] <fantasai> szilles: Definition is if you haven't put any content on the page, then you're at the top. And borders aren't content.
# [00:26] <fantasai> TabAtkins: This is still wayyy simpler than margin collapsing. There's no negatives, no zer-height elements that collapse through, none of that.
# [00:27] <fantasai> howcome: I think there's some kind of consensus here.
# [00:27] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [00:27] <fantasai> RESOLVED: page-break-before doesn't create a break if you're at the top of the page, where at the top of the page means no content has been placed. Borders do not count as content.
# [00:28] <fantasai> Zero-height content counts.
# [00:28] <fantasai> as content
# [00:28] <fantasai> dbaron: So placing an empty block counts, but placing start of a block does not count.
# [00:29] <fantasai> dbaron: Alternative def is placed either a non-phantom line box or a non-replaced block with non-zero height, or anything other than something that goes in a line box, or ...
# [00:29] <fantasai> TabAtkins: Can we just say line boxes is all we care about?
# [00:29] <fantasai> dbaron: tables? replaced blocks?
# [00:29] <fantasai> s/, or .../and isn't a non-replaced block/
# [00:30] <fantasai> TabAtkins: Why are we allowing ... collapsed through?
# [00:30] <fantasai> dbaron: Because alex waned it
# [00:30] <fantasai> Alex: I really like CSS2.1 definition because it covers lots of cases in just 2 lines
# [00:30] <fantasai> howcome: So we have one proposal which is 2.1, based on margin collapsing
# [00:31] <dbaron> I'm fine with the 2.1 definition
# [00:31] <dbaron> s/waned/wanted/
# [00:31] <fantasai> howcome: And then another, perhaps simpler, definition
# [00:31] <dbaron> s/and isn't a non-replaced block/, or something that doesn't go in a line box and isn't a non-replaced block/
# [00:32] <fantasai> howcome writes out the definitions
# [00:32] <fantasai> dbaron: One thing that seems weird is that you have start of a block, that's ok, and end of a block, that's ok, but start *and* end of block, that's not ok
# [00:33] <fantasai> ...
# [00:33] <fantasai> TabAtkins: The break-afters generate a break
# [00:33] <fantasai> TabAtkins: The break-befores don't generate a break: they're already on a new page
# [00:34] <fantasai> fantasai: The thing that's weird is collapsing anything through the content area of an element. We do that for margin collapsing, and its weird. We should not do that here.
# [00:34] <fantasai> alex: I have a problem with not counting the border as content
# [00:34] <fantasai> alex: My margin will be after that border, and while I'm asking to be the first thing on the page, I'm not really
# [00:35] <fantasai> TabAtkins: I think the potential downside of where that might be confusing is less bad than having an entirely blank page with nothing but a border on it.
# [00:35] <fantasai> fantasai: You're actually not required to print pages that have only backgrounds and borders on them
# [00:35] <fantasai> howcome: It seems you feel quite strongly about this, Alex.
# [00:36] <fantasai> howcome: Let's take a quick straw poll.
# [00:36] <fantasai> A: alex
# [00:36] <fantasai> B: steve/fantasai/tab
# [00:36] <fantasai> jj: A
# [00:37] <fantasai> alex: A
# [00:37] <fantasai> koji: abstain
# [00:37] <fantasai> Markus: abstain
# [00:37] <fantasai> Tantek: abstain
# [00:37] <fantasai> Steve: B
# [00:37] <fantasai> Alan: abstain
# [00:37] <fantasai> abstain
# [00:37] <fantasai> Florian: B
# [00:37] <fantasai> ert; abstain
# [00:37] <fantasai> ....
# [00:37] <fantasai> lots of abstain
# [00:37] <fantasai> howcome: we can collapse all the abstain
# [00:37] <fantasai> Rossen: A
# [00:38] <fantasai> dbaron: A
# [00:38] <fantasai> sylvaing: abstain
# [00:38] <fantasai> arronei: A
# [00:38] <fantasai> Tab: B
# [00:38] <fantasai> fantasai: B
# [00:38] <Bert> s/ert;/Bert:/
# [00:38] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [00:39] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [00:40] <fantasai> smfr: B
# [00:40] <fantasai> molly: B
# [00:40] <hober> hober: b
# [00:40] * Joins: gilles (gilles@63.145.238.4)
# [00:41] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [00:43] <fantasai> molly: The empty <div> is there. If we're dynamically generating things, it should have an effect
# [00:43] <fantasai> fantasai^ explains the two options
# [00:44] <fantasai> now howcome is explaining why we're collapsing at all
# [00:44] <fantasai> Alex: If you look at continuous media, where instead of page-break you have a large margin
# [00:44] <fantasai> alex: e.g. 3em margin
# [00:45] * Quits: BradK (bradk@63.145.238.4) (Quit: Buh bye)
# [00:45] <fantasai> alex: whatever comes after margin is held together by the results of margin-collapse
# [00:45] * Parts: howard (howard_wan@63.145.238.4)
# [00:45] <TabAtkins_> fantasai: If you're collapsing through this element, where is this break happening?
# [00:46] <TabAtkins_> fantasai: If you have a bunch of break-afters, and you collapse them, and you break the page, the margins that were there get truncated.
# [00:46] <TabAtkins_> fantasai: But after a forced page break, you keep margins at the top.
# [00:47] <TabAtkins_> fantasai: If you have an empty div, and you have set break-before and after on it, and the preceding and following div also have breaks, which page is the middle <div> contributing to?
# [00:47] <TabAtkins_> dbaron: And more importantly, which page is the empty div on?
# [00:48] <TabAtkins_> alexmog: Where does it say that margins are truncated after the break?
# [00:48] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [00:48] <TabAtkins_> howcome: We resolved on that.
# [00:49] <TabAtkins_> dbaron: [explains the 2.1 spec for it]
# [00:50] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
# [00:50] <TabAtkins_> dbaron: And this assumes that breaks exist *between* block-level margins, rather than being stuck somewhere *inside* of collapsed margins.
# [00:50] * Joins: mollydotcom (mollyh@63.145.238.4)
# [00:50] <dbaron> quoting 13.3.3 point 1 and the note following
# [00:50] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
# [00:50] <fantasai> jj: A
# [00:50] <TabAtkins_> new straw poll!
# [00:50] <fantasai> alex: A
# [00:50] <fantasai> steve:B
# [00:50] <fantasai> Florian: B
# [00:50] <fantasai> Bert: A
# [00:50] <fantasai> Brad: B
# [00:51] <fantasai> hober: B
# [00:51] <fantasai> smfr: B
# [00:51] <fantasai> Kim: B
# [00:51] <fantasai> Molly: B
# [00:51] <fantasai> Rossen: B
# [00:51] <fantasai> dbaron: B
# [00:51] <fantasai> arronei: A
# [00:51] <fantasai> TabAtkins_: B
# [00:51] <fantasai> TabAtkins_: B
# [00:51] <fantasai> glazou: B
# [00:51] <dbaron> s/TabAtkins_/fantasai/
# [00:51] <TabAtkins_> s/TabAtkins_:/fantasai:/
# [00:51] <dbaron> s/fantasai/TabAtkins/
# [00:51] <fantasai> 4 A, 12 B
# [00:52] <fantasai> ChrisL: B
# [00:52] <fantasai> -> 13 B
# [00:52] <fantasai> RESOLVED: B
# [00:52] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [00:53] <fantasai> ACTION fantasai: put proposal B for page-break collapsing into specs
# [00:53] * trackbot noticed an ACTION. Trying to create it.
# [00:53] * RRSAgent records action 14
# [00:53] <trackbot> Created ACTION-393 - Put proposal B for page-break collapsing into specs [on Elika Etemad - due 2011-11-07].
# [00:53] * Joins: Ruinan (Ruinan@63.145.238.4)
# [00:53] <fantasai> dbaron: We should errata 2.1
# [00:53] <dbaron> alex: can we get it written up first?
# [00:54] <fantasai> sylvaing: Column boxes define a containing block, right?
# [00:54] <fantasai> sylvaing: What if my columns are balanced and I have a percentage height?
# [00:54] <fantasai> dbaron: If it's auto height, it's auto-height
# [00:54] <fantasai> dbaron: The column boxes all occupy the full height of the multicol box
# [00:54] <fantasai> dbaron: They should have the same implicit height
# [00:55] <fantasai> sylvaing: Don't they adjust when you balance
# [00:55] <Bert> ACTION bert: create issue against CSS 2.1 corresponding to ACTION-393.
# [00:55] * trackbot noticed an ACTION. Trying to create it.
# [00:55] * RRSAgent records action 15
# [00:55] <trackbot> Created ACTION-394 - Create issue against CSS 2.1 corresponding to ACTION-393. [on Bert Bos - due 2011-11-07].
# [00:56] <fantasai> RESOLVED: percentage in block dimension is computed relative to multi-col element
# [00:57] <fantasai> Topic: GCPM
# [00:57] <fantasai> howocme: This is what I showed last night.
# [00:57] <fantasai> howcome: A few other changes we need to go through.
# [00:57] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [00:57] <fantasai> howcome: WD is a year old.
# [00:57] <fantasai> howcome: One thing that left GCPM since then is hyphenation
# [00:57] <fantasai> howcome: We should do an updated WD
# [00:57] <fantasai> howcome: A couple other things
# [00:58] <fantasai> glazou: Markus has shown me horizontal navigation in a document that is a little bit in conflict with your proposal
# [00:58] <fantasai> howcome: I don't think it's in conflict, they're going in the same way
# [00:58] <fantasai> Markus and howcome seem to be ok with the situation
# [00:58] * Quits: MoZ (MoZ@63.145.238.4) (Quit: Quitte)
# [00:58] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [00:58] <fantasai> howcome: I'm not tied to the syntax, but I think it shoudl be declarative as you say
# [00:58] <fantasai> markus: Declarative is good, but you also need JS access
# [00:58] <fantasai> howcome: First issue is with leaders
# [00:58] <fantasai> howcome: Bert brought up this point
# [00:59] <fantasai> howcome: The issue being that he wanted to have control over alignment of leaders
# [00:59] * glazou loves to see love between browser vendors ; we say "bisounours" in french :-)
# [00:59] <fantasai> howcome: If I understood correctly, Bert, you wanted to create a leader that's an arrow
# [00:59] <fantasai> howcome draws: ABC ------------> 1
# [00:59] * mollydotcom can someone post the URL for this WD please?
# [00:59] <Bert> -> http://www.w3.org/Style/Examples/007/leaders examples of leaders (hacked, of course, but showing the way I want them)
# [00:59] <fantasai> howcome: In order for this arrow, which is in the generated content,
# [00:59] <fantasai> howcome: to make this visually make sense, Bert wants the point of the arrow to connect with the line
# [01:00] <fantasai> howcome: So that you don't get that effect *draws an arrow where the head is broken from the body*
# [01:00] <fantasai> ChrisL: That assumes the horizontal lines match up with the arrows
# [01:00] * Joins: curmet (5ad8fb39@207.192.75.252)
# [01:00] <fantasai> Bert: In the Symbol fonts they do
# [01:00] <fantasai> howcome: the idea is to add a second argument to the leader function,
# [01:01] * Parts: curmet (5ad8fb39@207.192.75.252)
# [01:01] <fantasai> howcome: I think these are the values you need: 'start', 'end', 'center', 'space', 'pattern'
# [01:02] <fantasai> howcome: pattern is to make the dots align across lines
# [01:02] * Joins: karl (karlcow@128.30.54.58)
# [01:02] <fantasai> glazou: 'space' should be 'stretch'
# [01:02] <fantasai> fantasai: Stretching implies stretching the glyph. background-repeat uses 'space'
# [01:02] <fantasai> howcome: You want these leaders to align. I think this is the most common use case.
# [01:03] <fantasai> szilles: Don't understand where the space is added.
# [01:03] <fantasai> dbaron: You put as many characters as will fit. In normal case you right-align them
# [01:03] <fantasai> dbaron: In space case, you insert spaces between the leaders
# [01:04] <fantasai> szilles: Need to be clear about whether its between all the characters or between each string
# [01:04] <fantasai> Bert: Not the way it works in TeX, but it's another option
# [01:04] <fantasai> Bert: The leader unit is a fixed size, doesn't chnage size
# [01:04] <fantasai> Bert: Can put space before/after, both, etc. but not inside it
# [01:04] <fantasai> Tantek: Aren't leaders like border-images?
# [01:05] <glazou> s/'space' should be 'stretch'/'space' will mean whitespace in web author's mind, please use something else like stretch (just an example)
# [01:05] <fantasai> Tantek: why not use images
# [01:05] <fantasai> szilles: Because the common case is to use glyphs
# [01:05] <ChrisL> typographers also see decorations as glyphs
# [01:06] <fantasai> fantasai: might want both characters and images
# [01:06] <fantasai> fantasai talks about matchng the dots to the dots in the font, in size, postion, and shape
# [01:07] <fantasai> szilles: We've talked about a need for characters, there might also be a need for images
# [01:07] <fantasai> molly: I think space, which goes characters out to available space, and justification which fits inside the containing block
# [01:07] <fantasai> ????
# [01:07] <fantasai> molly: What I interpret that as meaning space out the chraacters to take up the width
# [01:07] <fantasai> howcome: That's right
# [01:08] <fantasai> howcome: The quesiton is between all characters or only where the repetition is
# [01:08] <fantasai> szilles: Why not have two values
# [01:08] <fantasai> fantasai: space and justify
# [01:08] <fantasai> fantasai: space like border-image and background-repeat
# [01:08] <fantasai> ?: letter-space and pattern-space
# [01:09] <fantasai> molly: justify makes sense
# [01:09] <fantasai> molly: This addresses both issues
# [01:09] <fantasai> howcome: Does anyone need center?
# [01:09] <fantasai> Bert: Sometimes you want as much space before the leader as well as after
# [01:10] <fantasai> dbaron: Centered absolutely or centered individually?
# [01:11] <fantasai> Florian: We're resolving to split the space into two, and not remove any other value
# [01:11] * Joins: wangsi-wei (wang@63.145.238.4)
# [01:12] <fantasai> some confusion around everything
# [01:12] * tantek provides a dot-leader example from >10 years ago: http://tantek.com/CSS/Examples/dotleaders.html
# [01:12] <tantek> (try resizing)
# [01:12] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
# [01:12] <tantek> #tablesabuse
# [01:13] <fantasai> howcome puts in string-space and letter-space
# [01:14] * Joins: cslye (cslye@192.150.10.200)
# [01:15] <fantasai> bikeshed pattern -> align
# [01:15] <fantasai> fantasai: I'd also drop the comma and use ||
# [01:15] <fantasai> fantasai: just like in properties
# [01:15] <fantasai> Bert: One more about leaders, but maybe not so easy to solve.
# [01:15] <fantasai> Bert: How to make double-ended arrows
# [01:16] * Quits: mihara (mihara@63.145.238.4) (Ping timeout)
# [01:16] <fantasai> fantasai: Just put three strings: "start" "middle" "end"
# [01:17] <fantasai> TabAtkins: image-resolution is in css3-images, so should remove from here
# [01:17] <fantasai> howcome: ok, done
# [01:18] <fantasai> szilles: One other catch with alignment
# [01:18] <fantasai> szilles: In Indic languages, the leader aligns with the hanging basline
# [01:18] <fantasai> szilles: In Japanese it would be centered
# [01:18] <fantasai> fantasai: That should be handled in the fonts
# [01:19] <fantasai> szilles: The leader needs to be aligned to the relevant baseline.
# [01:19] <fantasai> szilles: That may fall out
# [01:19] <fantasai> szilles: Just want it noted
# [01:19] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [01:20] * Joins: dbaron (dbaron@63.145.238.4)
# [01:20] <fantasai> howcome: Nothing changed in ... various sections ....
# [01:20] <fantasai> howcome: Paged Presentations
# [01:20] <fantasai> howcome: This is basically what I demoed yesterday, where we use the overflow property to set the axis onto which we put out these pages
# [01:21] <fantasai> howcome: They could be analyzed and split into two, and we could have multiple properties for them
# [01:21] * Joins: szilles (chatzilla@63.145.238.4)
# [01:21] <fantasai> howcome: We did that at some point in our implementation, but it creates many possibilities
# [01:21] <fantasai> howcome: that we aren't really going to use
# [01:21] <fantasai> howcome: So instead we have four values that cover the needs we have found
# [01:21] <fantasai> howcome: there might be others
# [01:21] * Quits: Ruinan (Ruinan@63.145.238.4) (Quit: Ruinan)
# [01:21] <fantasai> howcome: not tied to syntax, but we like the functionlity
# [01:21] <fantasai> howcome: the -controls bit adds the UI
# [01:22] <fantasai> howcome: native UI for paging
# [01:22] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
# [01:22] <fantasai> szilles: I'm concerned that it's not as standardized as scrollbars are
# [01:22] <fantasai> howcome: It's like HTML5 controls for video
# [01:22] <fantasai> glazou: that's in the markup
# [01:23] <fantasai> alex: ... overflow paginator, could be x and y
# [01:23] <fantasai> howcome: Could split these into 2 properties. Paged thing could be on 2 oveflow, and the others on a diferent property
# [01:23] <fantasai> howcome clarifies that x in paged-x is about how the pages connect, not which direction of overflow is affected
# [01:24] <fantasai> glazou: I'm very concerned about the controls bit
# [01:24] <fantasai> Florian: Does the first bit forbid the UA to have controls?
# [01:24] <fantasai> howcome: Alex asked, does touch work both places?
# [01:24] <fantasai> howcome: This just adds visual controls
# [01:24] <fantasai> dbaron: In the simplest case it could even be a scrollbar, though probably not the best idea, but it could be
# [01:24] <ChrisL> so the distnction is that the controls take up space
# [01:25] * ChrisL felt that was actually worth minuting
# [01:25] <fantasai> howcome: We have overflow: scroll;, so we are referring to controls already
# [01:25] <Bert> q+ to compare to marquee and overflow-style
# [01:25] <fantasai> fantasai: In scroll vs auto, we're distinguisshing whether the controls are visible when there's no need to scroll, not whether the UA should put controls at all when there is overflow to scroll to
# [01:26] <fantasai> dbaron: More similar to hidden
# [01:26] <glazou> q-
# [01:26] <fantasai> molly: Point out that if the controls are UA-dependent, could be a problem -- authors will want to style it
# [01:26] <glazou> ack Bert
# [01:26] <fantasai> Bert: When we introduced marquee, we added overflow-style and had it as a value of overflow-style
# [01:27] <fantasai> Bert: This seems more like additional values for overflow-style
# [01:27] * Joins: kermit (5e080aef@207.192.75.252)
# [01:27] * Parts: kermit (5e080aef@207.192.75.252)
# [01:27] <fantasai> Tantek: overflow-style: marquee-paged
# [01:27] <fantasai> Markus: In the first case (paged-x) you still want some indication of where you are
# [01:28] <fantasai> Markus: The default shouldn't be nothing.
# [01:28] <tantek> where's Tapas when you need him
# [01:28] <fantasai> dbaron: There are 2 options, in some sense there's no default. You can choose with or without controls
# [01:28] <fantasai> howcome: This is where we've built a UI through the dom. These controls have been made by the page (shows demo) whereas these are made by the UA
# [01:29] <fantasai> szilles: I'm still confused about what "this" is that you say should be in CSS
# [01:29] <fantasai> Adobe: In Acrobat the controls appear on hover
# [01:30] <fantasai> howcome: you can choose whether UA gives controls or whether author provides controls
# [01:31] <fantasai> fantasai: What if the author assumes you have a swipe interface for paging, and doesn't provide controls, but I don't have that interface? Then I'm stuck.
# [01:31] <fantasai> glazou: When you use the overflow property, you just say that the overflow should be visible in some way. You don't make any provision about the means.
# [01:31] <tantek> q+
# [01:31] <dbaron> I disagree with Daniel.
# [01:31] <fantasai> Markus: Here I'm showing you a similar solution using regions and exlucions
# [01:31] <dbaron> I don't think saying there are "controls" is too constraining.
# [01:32] <fantasai> Markus: You have a template mechanism that handles overflow.
# [01:32] <fantasai> Markus: At the bottom there is a little indicator of where you are and how many pages you have
# [01:32] <fantasai> Markus: If I use the mouse, I get a scrollbar
# [01:32] * tantek notes that Opera claims to support overflow-x and overflow-y: http://dev.opera.com/articles/view/opera-9-5-the-next-generation-of-web-s/
# [01:32] <fantasai> glazou: Here you are stopping the scrolling between two pages
# [01:32] * Joins: Ruinan (sunruinan@63.145.238.4)
# [01:32] <fantasai> (markus is demoing)
# [01:33] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [01:33] <fantasai> markus puts some experimental -ms- snap properties
# [01:33] <fantasai> markus: Now it snaps between pages
# [01:33] <fantasai> markus: But you still get a progress indicator, so you know where you are
# [01:33] <fantasai> markus: Beauty of this approach, based on regions, it's a simple JS templating model.
# [01:33] <fantasai> markus: You can inject animations, etc. etc.
# [01:34] <fantasai> markus: Not saying howcome's idea is a bad idea, but this brings more powerful
# [01:34] <fantasai> Tantek: Can we go back to howcome's demo
# [01:34] <fantasai> Tantek: You mentioned that simple values etc.
# [01:34] <fantasai> Tantek: I'm wondeirng how does that interact with overflow-x and overflow-y
# [01:34] <fantasai> Tantek: I know Opera supports those.
# [01:34] <fantasai> Tantek: If you've figured that out, I'd love to understand that interaction
# [01:35] <fantasai> howcome: These properties only belong on overflow shorthand
# [01:35] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [01:35] <fantasai> Tantek: That's why I think they should go on overflow-style
# [01:35] <fantasai> howcome ...
# [01:35] <fantasai> fantasai: I agree it should go in overflow-style
# [01:36] <fantasai> dbaron: This changes the layout model
# [01:36] <fantasai> dbaron: It's not just changing how we get to the overflow
# [01:36] <fantasai> fantasai: I have a question for Markus: what happens when you print?
# [01:37] <fantasai> Markus projects:
# [01:37] <fantasai> body {
# [01:37] <fantasai> overflow-x: auto;
# [01:37] <fantasai> overflow-y: hidden;
# [01:37] <fantasai> -ms-scroll-snap-type: mandatory;
# [01:37] <fantasai> -ms-scroll-snap-points-x: snapInterval(...)
# [01:37] <fantasai> }
# [01:37] * Joins: plinss (plinss@63.145.238.4)
# [01:37] <fantasai> Markus: In general the basics of how this app runs, it's just a simple page that brings in other html pages as templates
# [01:38] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [01:38] <fantasai> markus: We also have a default overflow template
# [01:38] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
# [01:38] <fantasai> markus: Just a little bit of JS to make this stuff work
# [01:38] <fantasai> glazou: little bit?
# [01:38] <fantasai> markus shows template pages
# [01:38] <fantasai> markus: Place my items, grid
# [01:38] <fantasai> Markus: What I showed you at the end is playing with this snap thing
# [01:39] <fantasai> Markus: You can snap after one page, multiple pages, define ranges etc.
# [01:39] <fantasai> Markus: We presented at the build conference, sdk out there, want to bring th WG as a propsoal
# [01:39] <fantasai> glazou: So this only works with JS?
# [01:39] <tantek> LOL - Håkon's pagination proposal is already in the media: www.macworld.com/article/163317/2011/10/opera_cto_kill_the_browser_scroll_bar.html
# [01:40] <fantasai> fantasai: I don't mind having JS interact with CSS, but I don't want us to build layout models here that require JavaScript in order to work.
# [01:40] <tantek> (and http://dvice.com/archives/2011/10/creator-of-css.php )
# [01:40] <fantasai> Markus: You can do interesting animations
# [01:41] <fantasai> Markus: When we started thinking about pagination, we started with something ismilar to howcome's model, but thought it would be better to have .... to create a better magazine-type experience.
# [01:41] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
# [01:41] <fantasai> hober: ...
# [01:41] <fantasai> howcome: I encourage you to add pagination to regions
# [01:41] <fantasai> alex: Pagination should be part of regions
# [01:41] <fantasai> howcome: Regions should know how to work with pages
# [01:41] * Quits: Ruinan (sunruinan@63.145.238.4) (Quit: Ruinan)
# [01:42] <fantasai> szilles: I agree with fantasai's statement that layout models shouldn't require JavaScript, but also good to define events and things to add more
# [01:42] <fantasai> glazou: Agreed, but the basic thing howcome demoed shouldn't require JavaScript
# [01:42] * tantek agrees with szilles
# [01:42] <fantasai> sylvaing: Right, it should be optional
# [01:42] <tantek> pagination events would be useful
# [01:43] <fantasai> howcome shows his api
# [01:43] <fantasai> szilles: I might want to ask questions about pages, like what links are on this page
# [01:43] <fantasai> howcome: I think that's reasonable
# [01:43] <fantasai> howcome: I object to you calling this a low-end feature, markus.
# [01:43] <fantasai> howcome: I can recreate the Economist's layout almost pixel perfect with this
# [01:43] * Joins: dcosta (dcosta@187.31.77.7)
# [01:43] <stearns> Alex's comment was that pagination should *not* be part of regions
# [01:44] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
# [01:44] <fantasai> BradK: Howcome's solution, the UA cna provid ethe UI for how the pagees get turned
# [01:44] <fantasai> bradk_: So you can even hav an ibook like experience, where it's curling and everything. Could be a high-end kind of experience
# [01:44] <fantasai> florian: high-end from control of the user, not the author (?)
# [01:44] <fantasai> bradk_: I consider an advantage, don't have to relearn how to turn pages on every website
# [01:45] <fantasai> Alan: I think whatever we build for pagination should work with multicol, work with regions, shoudl wirk without either
# [01:45] <fantasai> Alan: Could see this for slides
# [01:46] <fantasai> Markus: As soon as you want more flexibility on what thigns look like, you need regions
# [01:46] * Quits: Linuz (linuz.lee@63.145.238.4) (Quit: Linuz)
# [01:46] <fantasai> bradk_: Scrollbars are the same every page you're at, unless the author does somethng special
# [01:46] <fantasai> bradk_: I think that's good, so you don't have to figure out how to turn pages.
# [01:46] * Joins: karl (karlcow@128.30.54.58)
# [01:46] <fantasai> Szilles: If we're going to do what Brad just said, we should agree on what the compones are
# [01:46] * Quits: drublic (drublic@95.115.8.221) (Client exited)
# [01:46] <fantasai> szilles: My Kindle can do more than go back and forth between pages
# [01:47] <fantasai> szilles: A bunch of things ppl expect when paging things
# [01:47] <fantasai> szilles: Come up with some expectation of what the controls should be
# [01:47] <fantasai> szilles: controls is too open ended
# [01:47] <fantasai> [szilles says stuff about bookmarks etc]
# [01:47] <fantasai> molly: I agree.
# [01:47] <fantasai> molly: Need consistency, and say explicit about how it needss to be done
# [01:47] <fantasai> hober: HTML5 doesn't say much about what the video controls should be
# [01:48] <fantasai> howcome: Depending on what the device is, might have different controls
# [01:48] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [01:48] <fantasai> Florian: Say what capabilities it has
# [01:48] <fantasai> molly: I want to step back a moment,I understood that if you use these features and allow the UA specific ontrols, that you wil be able to style those ocntrols
# [01:49] <fantasai> Florian: If you want to style it, you build it yourself.
# [01:49] <fantasai> molly: ok
# [01:49] <fantasai> hober: Ua could provide some hook into its controls, but that's up to the UA
# [01:49] <fantasai> molly: As long as ppl can create their own controls
# [01:49] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
# [01:49] <fantasai> Bert: As longas I as the user can override what the author does
# [01:49] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
# [01:49] <fantasai> Bert: I want consistency across pages. I choose my browser.
# [01:50] <fantasai> fantasai: If the author says, don't put controls, and builds his own out of JS, and the user is lke "I can't deal with these weird controls, I want my own controls", how do you deal with that?
# [01:51] <fantasai> Florian: Turning on the UA controls is easy. Killing the author controls is not so much.
# [01:51] <fantasai> szilles: Also need ot make sure ther eare screenreader APIs for this.
# [01:51] <fantasai> discussion of accessibility apis and what they're capable of
# [01:51] <mmielke> Links to the Regions based demo (runs on win8 developer preview): http://code.msdn.microsoft.com/windowsapps/Dynamic-Region-Templates-94bc9c95
# [01:51] <fantasai> molly: When you're looking at this content anyway, the ocntent is linearized in your core document
# [01:51] <fantasai> szilles: With regions you can mix streams
# [01:52] <fantasai> alex: I think this should be a display property
# [01:52] <fantasai> alex: If it's overflow property, it applies to everything. But paging a flexbox doesn't make sense.
# [01:53] <fantasai> alex: All other kinds of layout that support overflow don't need to support paged overflow
# [01:53] <fantasai> plinss: Don't see why you can't paginate flexbox
# [01:53] <fantasai> howcome: I'd really like to publish another WD of GCPM.
# [01:54] <fantasai> howcome: We haven't gone through everything, so we can have big disclaimers about syntax and everything
# [01:54] <fantasai> howcome: But I'd like to get out another WD. First for updates to other things. But second there seems to be consensus that we want to work on this.
# [01:54] <fantasai> glazou: Don't have consensus, have interest
# [01:54] <fantasai> glazou: So provided you document all the issues and comments.
# [01:54] <fantasai> glazou: It's only a WD and we have interest in the feature
# [01:55] <fantasai> szilles: I'm def interested in the feature, but not sure where it belongs
# [01:55] <fantasai> fantasai: It can start here, and then we'll see where it goes. Just like everything else.
# [01:55] <fantasai> TabAtkins: Move counter styles to css3-lists? most is already in css3-lists. Willing to take on the next thing
# [01:56] <fantasai> dbaron: I think there's a bunch of things in this spec, and not a whole lot of interest in other things in the spec
# [01:56] <fantasai> fantasai: we're doing that already
# [01:56] <fantasai> dbaron: So we're going with the model that everything we want will go out of it?
# [01:56] * Quits: YUMA (yuma@63.145.238.4) (Quit: TakIRC)
# [01:56] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [01:56] <fantasai> howcome: Like John said, I don't think this will ever go to REC
# [01:57] <fantasai> s/this/this module/
# [01:57] <fantasai> glazou: Any objection to publishing?
# [01:57] <fantasai> RESOLVED: Publish CSS3 GCPM as soon as all edits are made
# [01:57] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
# [01:57] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Quit: JohnJansen)
# [01:57] * Joins: cslye_ (cslye@63.145.238.4)
# [01:57] * Quits: cslye_ (cslye@63.145.238.4) (Quit: cslye_)
# [01:57] <fantasai> glazou: Reminder, lot of joint meetings tomorrow, not necessarily in this room
# [01:57] <fantasai> glazou: Also FXTF on Thursday
# [01:57] <fantasai> glazou: Start here tomorrow.
# [01:58] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
# [01:58] <fantasai> glazou: We will discuss CSSOM with Anne at 9am
# [01:58] * Joins: szilles (chatzilla@63.145.238.4)
# [01:58] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [01:58] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
# [01:58] * Quits: shan (soonbo.han@63.145.238.4) (Quit: Leaving)
# [01:58] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
# [01:58] * ed agenda for the FXTF meeting: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
# [01:58] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
# [01:58] <fantasai> fantasai: jdagget, kojiishii and I will be having a joint meeting with the UTC on Thursday
# [01:59] * Quits: bradk_ (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
# [01:59] * Quits: cslye (cslye@192.150.10.200) (Ping timeout)
# [01:59] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [01:59] * Quits: dino (dino@63.145.238.4) (Quit: dino)
# [02:00] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
# [02:00] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Ping timeout)
# [02:00] * Quits: mollydotcom (mollyh@63.145.238.4) (Client exited)
# [02:01] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
# [02:01] * Quits: jun (fujisawa@63.145.238.4) (Quit: jun)
# [02:01] * Quits: wangsi-wei (wang@63.145.238.4) (Quit: wangsi-wei)
# [02:01] * Joins: wangsi-wei (wang@63.145.238.4)
# [02:01] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [02:01] * Quits: arronei (arronei@63.145.238.4) (Ping timeout)
# [02:02] * Quits: alexmog (alexmog@63.145.238.4) (Ping timeout)
# [02:03] * Joins: tpod (tpod@63.145.238.4)
# [02:04] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
# [02:04] * Quits: wangsi-wei (wang@63.145.238.4) (Ping timeout)
# [02:05] * Joins: glazou (glazou@63.145.238.4)
# [02:06] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
# [02:06] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [02:07] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
# [02:07] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
# [02:07] * Quits: tcelik (tantek_@63.145.238.4) (Quit: tcelik)
# [02:09] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [02:09] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
# [02:12] * Joins: paul_irish (paul_irish@76.14.88.222)
# [02:13] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# [02:15] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
# [02:15] * Joins: paul_irish (paul_irish@76.14.88.222)
# [02:17] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
# [02:17] * Quits: howcome (howcome@63.145.238.4) (Ping timeout)
# [02:18] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
# [02:24] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
# [02:30] * Joins: arronei (arronei@131.107.0.84)
# [02:30] * Quits: arronei_ (arronei@131.107.0.119) (Ping timeout)
# [02:32] * Joins: tpod (tpod@63.145.238.4)
# [02:37] * Joins: sylvaing (sylvaing@63.145.238.4)
# [02:38] * Joins: tpod_ (tpod@63.145.238.4)
# [02:39] * Quits: tpod (tpod@63.145.238.4) (Ping timeout)
# [02:39] * tpod_ is now known as tpod
# [02:42] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [02:43] * Quits: vhardy (vhardy@192.150.10.200) (Ping timeout)
# [02:48] * Joins: myakura (myakura@209.119.68.98)
# [02:51] * Joins: nimbupani (Adium@27.7.20.144)
# [02:52] * Joins: myakura_ (myakura@209.119.68.98)
# [02:52] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
# [02:59] * Quits: paul_irish (paul_irish@76.14.88.222) (Client exited)
# [03:00] * Quits: nimbupani (Adium@27.7.20.144) (Client exited)
# [03:00] * Joins: nimbupani (Adium@27.7.20.144)
# [03:08] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
# [03:16] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [03:16] * Joins: nimbupani (Adium@27.7.20.144)
# [03:17] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [03:25] * Joins: nimbupani (Adium@27.7.20.144)
# [03:28] * Joins: myakura (myakura@209.119.68.98)
# [03:28] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
# [03:28] * Joins: paul_irish (paul_irish@69.181.215.45)
# [03:28] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# [03:30] * Quits: paul_irish (paul_irish@69.181.215.45) (Client exited)
# [03:32] * Joins: myakura_ (myakura@209.119.68.98)
# [03:32] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
# [03:35] * Joins: homata (homata@58.158.182.50)
# [03:37] * Joins: myakura (myakura@209.119.68.98)
# [03:37] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
# [03:42] * Joins: sylvaing (sylvaing@209.119.68.98)
# [03:42] * Quits: sylvaing (sylvaing@209.119.68.98) (Quit: sylvaing)
# [03:48] * Joins: myakura_ (myakura@209.119.68.98)
# [03:48] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
# [03:50] * Joins: myakura (myakura@209.119.68.98)
# [03:50] * Quits: myakura_ (myakura@209.119.68.98) (Connection reset by peer)
# [04:01] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [04:26] * Joins: lgombos (Laszlo@209.119.68.98)
# [04:27] * Joins: nimbupani (Adium@27.7.20.144)
# [04:45] * Joins: myakura_ (myakura@209.119.68.98)
# [04:45] * Quits: myakura (myakura@209.119.68.98) (Connection reset by peer)
# [04:46] * Joins: dsinger (dsinger@68.126.183.95)
# [04:58] * Quits: lgombos (Laszlo@209.119.68.98) (Quit: Leaving)
# [05:11] * Quits: jwir3 (qw3birc@128.30.52.28) (Ping timeout)
# [05:20] * Joins: szilles (chatzilla@24.6.120.172)
# [05:23] * Quits: dcosta (dcosta@187.31.77.7) (Connection reset by peer)
# [05:24] * Quits: szilles (chatzilla@24.6.120.172) (Ping timeout)
# [05:24] * Joins: szilles (chatzilla@24.6.120.172)
# [05:27] * Joins: chsiao (chatzilla@24.6.101.192)
# [05:31] * Quits: szilles (chatzilla@24.6.120.172) (Ping timeout)
# [05:32] * Quits: chsiao (chatzilla@24.6.101.192) (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214])
# [05:34] * Joins: kojiishi (kojiishi@209.119.68.98)
# [06:07] * Joins: stearns (anonymous@209.119.68.98)
# [06:08] * Joins: dino (dino@75.16.26.133)
# [06:08] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
# [06:14] * Quits: homata (homata@58.158.182.50) (Ping timeout)
# [06:14] * Joins: homata (homata@58.158.182.50)
# [06:16] * Joins: kojiishi (kojiishi@209.119.68.98)
# [06:22] * Joins: gilles (gilles@204.14.156.63)
# [06:29] * Joins: tpod (tpod@98.210.10.195)
# [06:34] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
# [06:38] * Quits: gilles (gilles@204.14.156.63) (Client exited)
# [06:39] * Joins: gilles (gilles@204.14.156.63)
# [06:43] * Joins: arno (arno@208.87.61.130)
# [06:46] * Joins: homata_ (homata@58.158.182.50)
# [06:47] * Quits: homata (homata@58.158.182.50) (Ping timeout)
# [06:48] * Quits: homata_ (homata@58.158.182.50) (Quit: Leaving...)
# [07:05] * Quits: tpod (tpod@98.210.10.195) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [07:07] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
# [07:10] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
# [07:36] * Joins: gilles (gilles@204.14.156.63)
# [07:37] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
# [07:40] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [07:40] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
# [08:17] * Joins: tantek (tantek@70.36.139.219)
# [08:50] * Quits: dino (dino@75.16.26.133) (Quit: dino)
# [09:10] * Quits: myakura_ (myakura@209.119.68.98) (Client exited)
# [09:35] * Joins: Ms2ger (Ms2ger@91.181.84.233)
# [09:45] * Quits: plinss_ (plinss@68.107.116.103) (Ping timeout)
# [09:56] * Joins: drublic (drublic@77.2.149.184)
# [10:10] * Joins: nimbupani (Adium@27.7.20.144)
# [10:23] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [10:32] * Joins: nimbupani (Adium@27.7.20.144)
# [10:41] * Quits: drublic (drublic@77.2.149.184) (Client exited)
# [10:55] * Joins: drublic (drublic@93.132.231.203)
# [10:55] * Quits: drublic (drublic@93.132.231.203) (Client exited)
# [10:56] * Joins: drublic (drublic@93.132.231.203)
# [11:48] * Zakim excuses himself; his presence no longer seems to be needed
# [11:48] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [13:21] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [13:23] * Joins: nimbupani (Adium@27.7.20.144)
# [13:23] * Joins: gilles (gilles@204.14.156.63)
# [13:29] * Quits: gilles (gilles@204.14.156.63) (Quit: gilles)
# [13:34] * Quits: nimbupani (Adium@27.7.20.144) (Quit: Leaving.)
# [13:34] * Joins: drublic_ (drublic@77.2.128.229)
# [13:36] * Quits: drublic (drublic@93.132.231.203) (Ping timeout)
# [13:36] * Quits: drublic_ (drublic@77.2.128.229) (Client exited)
# [13:36] * Joins: drublic (drublic@77.2.128.229)
# [13:42] * Quits: drublic (drublic@77.2.128.229) (Ping timeout)
# [13:47] * Joins: drublic (drublic@77.2.147.143)
# [14:12] * Joins: miketaylr (miketaylr@206.217.92.186)
# [14:24] * Joins: karl (karlcow@128.30.54.58)
# [14:29] * Quits: Ms2ger (Ms2ger@91.181.84.233) (Quit: bbl)
# [15:09] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [15:19] * Joins: miketayl_r (miketaylr@206.217.92.186)
# [15:21] * Quits: miketaylr (miketaylr@206.217.92.186) (Ping timeout)
# [15:21] * Joins: stearns (anonymous@209.119.68.98)
# [15:26] * Quits: dsinger (dsinger@68.126.183.95) (Quit: dsinger)
# [15:27] * Quits: miketayl_r (miketaylr@206.217.92.186) (Connection reset by peer)
# [15:27] * Joins: miketaylr (miketaylr@206.217.92.186)
# [15:37] * Joins: tcelik (tantek_@70.36.139.219)
# [15:40] * Quits: tcelik (tantek_@70.36.139.219) (Quit: tcelik)
# [15:41] * Joins: plinss (plinss@63.145.238.4)
# [15:42] * Joins: arno (arno@208.87.61.130)
# [15:44] * Joins: tcelik (tantek_@70.36.139.219)
# [15:46] * Quits: tcelik (tantek_@70.36.139.219) (Quit: tcelik)
# [15:46] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
# [15:46] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
# [15:52] * Quits: miketaylr (miketaylr@206.217.92.186) (Connection reset by peer)
# [15:52] * Joins: miketayl_r (miketaylr@206.217.92.186)
# [15:52] * Joins: florian (florianr@209.119.68.98)
# [15:57] * Quits: florian (florianr@209.119.68.98) (Ping timeout)
# [15:57] * Joins: gilles (gilles@63.145.238.4)
# [15:57] * Joins: stearns (anonymous@63.145.238.4)
# [15:59] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
# [16:04] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [16:08] * Joins: r12a (rishida@128.30.52.169)
# [16:14] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
# [16:18] * Joins: mmielke (mmielke@63.145.238.4)
# [16:24] * Joins: myakura (myakura@209.119.68.98)
# [16:25] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
# [16:26] * Joins: arno (arno@192.150.10.200)
# [16:31] * Joins: stearns (anonymous@63.145.238.4)
# [16:33] * Joins: karl (karlcow@128.30.54.58)
# [16:35] * Quits: myakura (myakura@209.119.68.98) (Client exited)
# [16:39] * Joins: kojiishi (kojiishi@209.119.68.98)
# [16:43] * Joins: shan (soonbo.han@63.145.238.4)
# [16:45] * Joins: arronei_ (arronei@63.145.238.4)
# [16:49] * Joins: bradk (bradk@63.145.238.4)
# [16:52] * Joins: duga (duga@63.145.238.4)
# [16:53] * Joins: dsinger (dsinger@63.145.238.4)
# [16:53] * Joins: Ruinan (sunruinan@63.145.238.4)
# [16:54] * Joins: gilles (gilles@63.145.238.4)
# [16:55] * Joins: dbaron (dbaron@63.145.238.4)
# [16:56] * Quits: kojiishi (kojiishi@209.119.68.98) (Ping timeout)
# [16:57] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [17:02] * Joins: myakura (myakura@63.145.238.4)
# [17:02] * Joins: sylvaing (sylvaing@63.145.238.4)
# [17:02] * Joins: gilles (gilles@63.145.238.4)
# [17:03] * Joins: anne (annevk@63.145.238.4)
# [17:03] * Joins: lgombos (Laszlo@63.145.238.4)
# [17:04] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [17:04] * Joins: mihara (mihara@63.145.238.4)
# [17:05] * Joins: glazou (glazou@63.145.238.4)
# [17:06] * Joins: plinss (plinss@63.145.238.4)
# [17:06] <sylvaing> scribenick: sylvaing
# [17:06] <dbaron> Topic: CSSOM
# [17:07] * Joins: YUMA (yuma@63.145.238.4)
# [17:07] <sylvaing> annevk: the CSSOM is a collection of various CSS features exposed through script
# [17:07] <sylvaing> annevk: such as alternate stylesheets, stylesheets themselves
# [17:08] <sylvaing> annevk: and a new part is CSS values which is very new
# [17:08] <sylvaing> annevk: we are now waiting for implementation experience for CSS values
# [17:09] <sylvaing> florian: we had talked about defining serialization
# [17:09] <sylvaing> annevk: nothing new at this point
# [17:10] <sylvaing> fantasai,annevk: we had talked about defining the serialization of basic types in a Serialization module
# [17:10] * Joins: shans (qw3birc@128.30.52.28)
# [17:11] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [17:11] * Joins: Kai (chatzilla@63.145.238.4)
# [17:11] * Joins: arno (arno@192.150.10.200)
# [17:12] <sylvaing> fantasai: most of them were in CSS2.1 or should be new units in css3-values and Color
# [17:12] * Joins: jdaggett_ (jdaggett@63.145.238.4)
# [17:12] * Joins: si-wei (si-wei@63.145.238.4)
# [17:13] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
# [17:13] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [17:13] <sylvaing> jdaggett: there may a problem with the way we've modularized; some modules need to rev often than others. CSSOM is one of those
# [17:13] * Joins: vhardy (vhardy@192.150.10.201)
# [17:13] <sylvaing> Tab: some specs need to be 'living' ?
# [17:14] <sylvaing> fantasai: that was the case for many modules. hence the modularization
# [17:14] <sylvaing> jdaggett: if I add an at-rule I need a DOM interface so I'm adding things that should be in the OM
# [17:14] <sylvaing> annevk: if you add an at-rule you should define all the related OM pieces in the same place
# [17:15] <sylvaing> florian: the problem we have right now is bootstrapping. we don't have a 2.1 for serialization
# [17:15] * Joins: kojiishi (kojiishi@63.145.238.4)
# [17:15] <sylvaing> s/florian/fantasai
# [17:15] <sylvaing> fantasai: until we have that we will be discussing process
# [17:16] * Joins: miketaylr (miketaylr@206.217.92.186)
# [17:16] <sylvaing> glazou: we're also going to talk about the OM forever until we fix its issues and implement the fixes
# [17:16] * Quits: miketaylr (miketaylr@206.217.92.186) (Client exited)
# [17:16] * Quits: miketayl_r (miketaylr@206.217.92.186) (Connection reset by peer)
# [17:16] * Joins: miketaylr (miketaylr@206.217.92.186)
# [17:16] <sylvaing> glazou: we need a better OM
# [17:17] <sylvaing> tantek: I agree we need a foundational OM spec.
# [17:17] * Joins: shepazu (shepazu@128.30.52.169)
# [17:18] <fantasai> +1
# [17:18] <sylvaing> tantek: just like HTML went through a painful process of defining an OM in sync with content out there. Starting with a known feature set would be easier and establish a baseline
# [17:18] <fantasai> tantek: Instead of redrawing module lines, we should start by creating an OM for CSS 2.1
# [17:19] <sylvaing> jdaggett: we do not have a consistently defined DOM interface. some modules define new at-rules but implementations may be using different rule constants which should be coordinated across specs
# [17:19] * Joins: howard (howard_wan@63.145.238.4)
# [17:20] <sylvaing> jdaggett: there is no one looking at these features from an OM perspective. It's up to each editor and each editor's level of OM experience e.g. some modules will not define exceptions correctly
# [17:20] <sylvaing> jdaggett: so specs are inconsistent
# [17:20] <sylvaing> tantek: I suggest the common reference baseline would be a 2.1 OM
# [17:20] <sylvaing> jdaggett: how does that help with new features
# [17:21] * Joins: alexmog (alexmog@63.145.238.4)
# [17:21] <sylvaing> fantasai: like non OM features, most new OM features derive from existing features in 2.1 and you would have patterns to base new interfaces on
# [17:22] <sylvaing> jdaggett: the pattern for what you have to do to specify a new at-rule is not defined; I'm not sure a 2.1 OM defines it. how is that different from what we have now ?
# [17:22] * Joins: florian (florianr@63.145.238.4)
# [17:22] <sylvaing> jdaggett: I think we need more: at least a set of how-to guidelines e.g. if you define a new at-rule, these are the things you need to specify
# [17:23] <sylvaing> tantek: we agree on goals, we're only discussing how to get there
# [17:23] <sylvaing> jdaggett: I don't think we even have consensus on issues such as prefixed at-rules and how this relates to at-rule constants
# [17:24] <sylvaing> glazou: this should definitely be specified
# [17:24] <sylvaing> tantek: we should reach a bar where each module should define its DOM
# [17:24] <fantasai> Proposal: Modularize CSSOM. Break it up into a a Serialization module, a Values module, an At-Rules module, a Media Queries module, etc.
# [17:25] <sylvaing> tantek: keeping things separately did not help HTML
# [17:26] <sylvaing> dbaron: there are modules how define their own OM e.g. Transitions (events), Animations (OM), Fonts, Conditional....
# [17:26] <sylvaing> dbaron,annevk: Transforms has a value type but we agreed to deprecate the CSSValue type it uses
# [17:27] <sylvaing> tantek: I think we need something that is up to date with 2.1
# [17:27] <sylvaing> dbaron: part of the base problem is that DOM L2 Style has a number of features that are wrong, and a number of things we agreed to change but never fixed
# [17:27] * Joins: tcelik (tantek_@63.145.238.4)
# [17:27] <sylvaing> dbaron: we need to define this core baseline so we can build on top of it
# [17:28] <sylvaing> annevk: as far as values, we deprecated the 2003 model but never replaced it
# [17:28] <sylvaing> annevk: I didn't want to spec out the new model fully until we at least had some implementation experience with it
# [17:29] <sylvaing> tankek: is there interop among browsers for 2.1 CSSOM ?
# [17:29] <sylvaing> dbaron: what do you mean by 2.1 ?
# [17:29] <sylvaing> tantek: what is in Gecko, Webkit, Trident today ?
# [17:29] <sylvaing> dbaron: I don't know if it's that that interoperable?
# [17:30] <sylvaing> annevk: I don't see how reorganizing is going to help us vs. implementors working on it.
# [17:30] <sylvaing> annevk: there isn't even much discussion
# [17:31] <sylvaing> dbaron: also, authors don't use the OM that much
# [17:31] <sylvaing> tantek: isn't it a chicken-and-egg problem; they don't because they can't
# [17:32] <sylvaing> tantek: Tab was complaining about how many obsolete drafts we have. we have this problem here too e.g. DOM L2 Style.
# [17:33] <sylvaing> tantek: I'd like to see something that reflects the interoperable state of the world
# [17:33] <dbaron> dbaron: I think authors don't use the OM much, even what is interoperable. Authors tend to use the model that styles are static and they dynamically change the content-- and I tend to think that's a good thing.
# [17:33] * Joins: matt (matt@128.30.52.169)
# [17:33] * Joins: smfr (smfr@63.145.238.4)
# [17:33] * Parts: matt (matt@128.30.52.169)
# [17:33] <sylvaing> dbaron: if there isn't a lot of demand for it, should we spend time on it ?
# [17:33] <fantasai> http://dev.w3.org/csswg/cssom/
# [17:34] <sylvaing> tab: I know that there is demand for a new value based om that wouldn't be string-based. It's a popular author request that is currently done through libs like jQuery
# [17:34] <sylvaing> tab: we know that there is a use-case in that area
# [17:34] <sylvaing> dbaron: yes, i've seen author demand for this, as well as for variants of computed style as well as some author demand for the set of matched rules for an element
# [17:35] <sylvaing> dbaron: I can't recall authors asking for poking through rules inside a stylesheet
# [17:35] <sylvaing> tab: that is useful for CSS polyfills
# [17:35] <sylvaing> annevk,dbaron: except the features you want to polyfill are dropped
# [17:36] * Joins: cyril (chatzilla@63.145.238.4)
# [17:36] * Quits: arronei_ (arronei@63.145.238.4) (Connection reset by peer)
# [17:36] * Joins: arronei_ (arronei@63.145.238.4)
# [17:37] <sylvaing> fantasai: I'd like to document what we have right now
# [17:37] * Joins: JohnJansen (JohnJansen@63.145.238.4)
# [17:37] <sylvaing> fantasai: and the new interfaces would be in a separate document
# [17:38] <sylvaing> fantasai: and we can move the bit that's implemented in CR and beyond
# [17:39] <sylvaing> kimberly: we as implementors are looking for guidance; we need a document that reflects what browsers do in order to build compatible devices/platforms
# [17:40] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [17:40] <sylvaing> howcome: are we interested in investing this kind of effort ?
# [17:40] <fantasai> [insert^ discussion about the fact that DOM Level 2 Style is on /TR and has not been obsoleted by anything]
# [17:41] <fantasai> sylvaing: It does keep coming back.
# [17:41] <fantasai> glazou: But it keeps coming back. We've been discussing this since 10 years ago.
# [17:41] * Quits: vhardy (vhardy@192.150.10.201) (Connection reset by peer)
# [17:41] <fantasai> glazou: Anne invested a lot of time in this spec cleaning it up
# [17:41] <fantasai> glazou: Form an implementation POV, we're almost exactly at the same point
# [17:41] <fantasai> dbaron: There's a bunch of things in anne's spec that have been implemented. It's just not the core stuff
# [17:42] <sylvaing> dbaron: I think there are things in the spec that have been implemented. but a number of things have not been
# [17:42] * Joins: chsiao (chatzilla@63.145.238.4)
# [17:42] <fantasai> discussion of poking around the style sheet
# [17:42] <sylvaing> discussion of how many people need editing functionality
# [17:43] <sylvaing> alan: do we need a testsuite to get implementors interested ?
# [17:44] * Joins: arno (arno@192.150.10.200)
# [17:44] <fantasai> sylvaing: There's enough pain that this topic keeps coming back, but not enough that implementers are investing in it
# [17:44] <sylvaing> tantek: since we agree to have obsoletion noticed in old modules that aren't maintained, I think we should do that for DOM L2 Style and link from the latter to CSSOM
# [17:45] <sylvaing> bert: but then there is nothing stable anymore
# [17:45] * Joins: dino (dino@17.202.47.159)
# [17:45] <sylvaing> tantek: but that is reality and would be honest
# [17:45] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
# [17:45] * Joins: cyril_ (chatzilla@63.145.238.4)
# [17:45] * cyril_ is now known as cyril
# [17:45] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
# [17:45] <sylvaing> annevk: that would be a service to the community, I think. They would at least know what we're working on now
# [17:45] <sylvaing> bert: it's better but not enough
# [17:46] <fantasai> annevk: we should at least have a link to the obsoletion email you sent in 2003; adding a link to the CSSOM would be helpful, but not critical imo
# [17:47] <sylvaing> glazou, jdaggett: the specs are not understandable or usable hence the attraction of jQuery as a way to use the OM
# [17:47] <sylvaing> jdaggett: is it OK to mark specific sections as obsolete at least ?
# [17:48] <sylvaing> glazou: yes
# [17:48] <sylvaing> jdaggett: so CSS values in DOM L2 Style in marked invalid, not the entire spec
# [17:48] <sylvaing> hober: that can also be marked at the top
# [17:48] <sylvaing> glazou: I don't want the entire document to be obsoleted
# [17:49] <sylvaing> plinss: is the problem unaware of the Editor's Draft ? is that the problem ?
# [17:50] * Joins: MoZ (MoZ@63.145.238.4)
# [17:50] <fantasai> various people giving examples of this actually being a problem
# [17:50] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [17:50] <sylvaing> dbaron: there are 2 threads here; the value API and the representation of style sheets e.g. at-rules
# [17:51] <sylvaing> glazou: I don't understand why we don't have a requirements document for this
# [17:51] <fantasai> RESOLVED: Add obsoletion notice stating which sections of DOM Level 2 style are obsolete, links to Bert's obsoletion notice, and links to the CSSOM editor's draft
# [17:51] <sylvaing> RESOLVED: add a notice to the top DOM L2 Style indicating portions of the spec are obsolete linking to Bert's email and linking to CSSOM. Also, the specific obsolete section of DOM L2 Style must be marked as such
# [17:51] * Joins: r12a (rishida@128.30.52.169)
# [17:52] <fantasai> ACTION Tab: Draft note on DOM Level 2 Style
# [17:52] * trackbot noticed an ACTION. Trying to create it.
# [17:52] * RRSAgent records action 16
# [17:52] <trackbot> Created ACTION-395 - Draft note on DOM Level 2 Style [on Tab Atkins Jr. - due 2011-11-08].
# [17:53] <sylvaing> fantasai: once we agree on the draft notice, we can resolve a PER
# [17:54] <sylvaing> dbaron: the things people do with jQuery relates to the value API; editing tools need both the value API as well as the stylesheet traversal interface. The latter is not that hard but the current specs are inconsistent and poorly written, but 80% right
# [17:55] <sylvaing> dbaron: we decided to throw out the value API and rewrite it but the new API is a draft that no one has implemented
# [17:55] <fantasai> annevk: Only part of the values API is there
# [17:55] <fantasai> dbaron: If someone tried to implement it, what would happen?
# [17:55] <sylvaing> sylvaing: does one need to implement it in the engine or could it be experimented with in JS ?
# [17:56] <fantasai> jdaggett: If it's not a big API...
# [17:56] <sylvaing> annevk: it could be done in JS
# [17:56] <fantasai> dbaron: It's a pretty big API
# [17:57] <fantasai> jdaggett: It seems we have two modules here. I keep hearing that we need something in a firmer state, and the Values API is not in that state
# [17:57] <fantasai> annevk: I don't think we need to split the draft.
# [17:58] <sylvaing> jdaggett: I think the stylesheet traversal API has more impact on new features
# [17:58] <sylvaing> dbaron: it depends on the feature. if we implement the new values API, this would impact CSS3 Fonts features e.g. font-feature-settings would need a whole object model
# [17:59] * Joins: AnanKan (AnanKan@63.145.238.4)
# [17:59] <sylvaing> jadaggett, dbaron: there is no consistency of design among the at-rule definitions across modules
# [17:59] <sylvaing> annevk: shouldn't that be solved by review ?
# [17:59] <sylvaing> tab: we should have guidelines before review
# [18:00] * Joins: Rossen (Rossen@63.145.238.4)
# [18:00] <sylvaing> dbaron: the OM for keyframes rule looks different from what's in 2.1 but it was already implemented so I followed the same model.
# [18:01] * Joins: arno (arno@192.150.10.200)
# [18:01] <anne> I have to go in four minutes
# [18:01] <sylvaing> dbaron: as far as we can tell, it's unclear that the people who use these interfaces care about these inconsistencies
# [18:02] <fantasai> Florian: The people who care do not give sufficient feedback
# [18:02] <sylvaing> dbaron: one of the ways we judge interest in things is based on feedback on obvious problems
# [18:03] <sylvaing> glazou: and maybe they don't have to comment because there are shims like jQuery which deal with the problem
# [18:03] <fantasai> plinss: If something is bad enough, people look at it and decide it's way to unstable, way too much of a mess, to comment on
# [18:03] <sylvaing> dbaron: that is the values API, not the stylesheet interface. they're not the same thing.
# [18:04] <sylvaing> fantasai: I edit a lot of specs. I don't know what I need to put in my spec about serialization, OM, values API. I don't know what to do in CSS3 because there is nothing stable for me to build on top of
# [18:05] <sylvaing> fantasai: once I have something stable then I can reference it and update my modules.
# [18:05] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
# [18:05] <sylvaing> fantasai: maybe serialization is stable enough so I could reference it but if stable and unstable things are in the same module I don't know what to do
# [18:05] <tcelik> I've updated http://wiki.csswg.org/spec/cssom with notes about what people have claimed are author demands. More evidence / statements welcome.
# [18:06] <sylvaing> jdaggett: I think we need to have someone else co-edit to ensure we document implementation reality
# [18:07] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [18:07] <fantasai> glazou: John is proposing to have a document reflecting current implementations
# [18:07] <fantasai> glazou: I'm not sure that the current implementations are so inconsistent that this is undoable
# [18:07] <fantasai> glazou: Getting a stable spec, that only consists of the stable specs, I don't know that that's useful
# [18:08] <fantasai> Florian: If you ask me what the stable parts are, I have no idea.
# [18:08] <fantasai> jdaggett: I think there is value here. If you have a spec that focuses the set of features that have impelemtnations, even if they are inconsistent,
# [18:08] <fantasai> jdaggett: Trying to iron out those variations, that's value. Even if it's not sexy, it's still value.
# [18:08] <fantasai> jdaggett: I don't know that it has to be another spec, but we need to get the existing CSSOM spec ...
# [18:09] <fantasai> glazou: I think what you want is a better use of our time to add warning notes to the current DOM Level 2 spec than what you're proposing
# [18:09] <fantasai> arronei: This is what our test suites do
# [18:09] <fantasai> Tantek: I'm going to object John's assertion that we need another oc-editor, the editor's draft was lately updated
# [18:09] <fantasai> jdaggett: Editing the draft doesn't ensure it's moving towards something stable
# [18:10] * Joins: lgombos_ (Laszlo@63.145.238.4)
# [18:10] <fantasai> Tantek: Let's work cooperatively within existing mechanism
# [18:10] * Joins: dcosta (dcosta@187.31.77.7)
# [18:10] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
# [18:10] <fantasai> Tantek: Oftentimes when another editor is needed for something, it's not due..
# [18:10] <fantasai> Florian: Anne is not interested in documenting the existing bits,, he
# [18:11] <glazou> test
# [18:11] <sylvaing> tantek: writing down what works today, I just want to establish how. can we write it down on the wiki page ?
# [18:11] <sylvaing> tantek: i just want to capture the request that we want to know what implementations do
# [18:12] * Joins: arno (arno@192.150.10.200)
# [18:12] <fantasai> sylvaing: Anne is definitely the right guy for the values API, but he's not interested in doing the documenting existing stuff
# [18:12] <fantasai> sylvaing: Putting things on a wiki page doesn't make them happen
# [18:13] <fantasai> szilles: you can't tell whether they'll happen until you put them there
# [18:13] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [18:13] <fantasai> <br duration=5m>
# [18:14] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
# [18:16] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
# [18:17] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
# [18:20] <fantasai> </br>
# [18:20] <fantasai> Topic: IDPF Joint WG meeting
# [18:20] <fantasai> +Brady Duga
# [18:20] <fantasai> +Bill McCoy
# [18:20] <fantasai> +Peter Sorotkin
# [18:21] <fantasai> duga: The Advanced Layout group of IPDF is going to begin work shortly
# [18:21] <fantasai> duga: our members have been clamoring for more powerful design, adaptive design, for page layout
# [18:21] <fantasai> duga: Right now when people want to do high design, they go back to JPEG, abspos, things that don't work well for multiple-size devices
# [18:21] <fantasai> duga: A proposal was made by adobe in PEU3 for more adaptive layout
# [18:21] * Joins: bradk (bradk@63.145.238.4)
# [18:22] <fantasai> duga: Didn't make it into 3, but portions of it turned into CSS Regions and Exclusions
# [18:22] * Quits: dino (dino@17.202.47.159) (Client exited)
# [18:22] <fantasai> duga: There's still a whole bunch of things not in those specs
# [18:22] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
# [18:22] * Quits: MoZ (MoZ@63.145.238.4) (Quit: This computer has gone to sleep)
# [18:22] * Joins: dino (dino@17.202.47.159)
# [18:22] <fantasai> duga: There's still a lot of clamoring for advanced adaptive layout features in a very short timeframe
# [18:22] * Joins: fukuno (fukuno@63.145.238.4)
# [18:22] <fantasai> jdaggett: There's a bi disconnect that I see between the way EPUB makes their specifications and the work that actually needs to get done.
# [18:23] <fantasai> jdaggett: If you define a schedule and then try to match features to that schedule, anyone in software will tell you that that doesn't work
# [18:23] <fantasai> jdaggett: Especially where complexity is involved
# [18:23] * Joins: Rossen (Rossen@63.145.238.4)
# [18:23] * Joins: arno (arno@192.150.10.200)
# [18:23] * Joins: MoZ (MoZ@63.145.238.4)
# [18:23] <fantasai> jdaggett: And when you talk about compelx layouts in CSS, that's by def complex
# [18:23] <fantasai> bill: The reason we're here is to make sure whe ahve a connection
# [18:23] <fantasai> jdaggett: A schedule-driven process will not get you something that will be interoperable.
# [18:23] <fantasai> jdaggett: The way EPUB has operated i nthe past is on-schedule. Whatever you're delivering is built on quicksand
# [18:23] <Bert> -> http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter IDPF Advanced Adaptive Layout working group charter
# [18:24] <fantasai> jdaggett: You're referencing working drafts of this WG, and those chang.e
# [18:24] <fantasai> jdaggett: Rather than talk about scheduling, it's much more important to look at for the work of this group, where are the problems that are holding up things. And contribute from that angle. Rather than ctalking about scheduling
# [18:24] <fantasai> jdaggett: I think basically proposals are here. Would be more helpful if members at EPUB were focusing on what is needed to work out the problems associated with the various feature sthat re being proposed.
# [18:25] <fantasai> jdaggett: I see this a lot in vertical text layou. EPUB comes with a eature list, but when you have to figure out how these thigns actually work, participation is lacking.
# [18:25] <fantasai> bill: We ant to make sure participation is there and we contribute to broad open web andd assume open web wants to evolve to handle needs of publishing
# [18:25] * Joins: tantek (tantek@63.145.238.4)
# [18:25] <fantasai> bill: Over time we're getting closer and closer.
# [18:25] <fantasai> bill: EPUB2 referenced subset of CSS
# [18:26] <fantasai> bill: EPUB3 took a different approach. We followed the recommendation from the liaison to prefix things, etc.
# [18:26] <fantasai> jdaggett: We also had ppl form this group of not referencing WDs
# [18:26] <fantasai> jdaggett: Do what you want, but this will not get you interop
# [18:26] <fantasai> bill: The market demands were movin on anyway
# [18:27] <fantasai> dbaron: One thing you mentioned was seeking eventual alignment with web technology.
# [18:27] <fantasai> dbaron: One of the dangers there if you take a snapshot of a WD is that either one of two things will happen
# [18:27] <fantasai> dbaron: one is that the set of implementations doing EPUB will be different from Web technology, or same implementations plus flags
# [18:28] <fantasai> dbaron: And you'll end up with converging implementations within EPUB and converging implementations within the Web, and those two groups diverging
# [18:28] <fantasai> dbaron: The other possibility is that you'll have common implementations, and one or the other set of specs will end up bein ignored in reality
# [18:28] <fantasai> szilles: I completely agree with points by john and david, but we are sort of faced with 2 orgs trying to find an effective mechanism for cooperating. They have different constraints.
# [18:29] <fantasai> szilles: The warnings you express are valid
# [18:29] <fantasai> szilles: But more productive than trying to change how they're operating, is trying to minimize these kinds of issues or find ways for efffective coperation.
# [18:29] <fantasai> szilles: In particular one of these seems to be for EPUB to prioritize the feature list, so if we can only tackle some of it we know what to tackle fro myour side
# [18:30] <fantasai> glazou: Since I'm myself writing an EPUB2/3 editor, taken a look at all the editors , tools, renderers.
# [18:30] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [18:30] <fantasai> glazou: Most of them are based on web engines
# [18:30] <fantasai> glazou: The Web industry and EBOOK industry share the app layer
# [18:30] <fantasai> glazou: I don't think they are ogoing to be two different layers of runtimes
# [18:31] <fantasai> glazou: one for web and one for ebook
# [18:31] <fantasai> bill: We took decision in EPUB3 on buying that assumption
# [18:31] <fantasai> bill: Could have moved towards more DocBOok like vocab. Instead reference HTML5/CSS all-in
# [18:31] <fantasai> bill: Taking hoewver the reality that some of those won't be fully baked
# [18:31] <fantasai> bill: Decision was popular with vendors, lead to thinks like Apple iBooks based on WebKit
# [18:31] <fantasai> bill: Downside is that widely adopted modules that are WD
# [18:32] <fantasai> bill: CSS2.1 is baseline, but 9 modules referenced by EPUB3
# [18:32] <fantasai> bill: But all of those have some implementation
# [18:32] <fantasai> bill: We would like guidance from CSSWG.
# [18:32] <fantasai> bill: We are not W3C.
# [18:33] <fantasai> bill: As soon as there's cross-browser implementation, we're using those features
# [18:33] <fantasai> bill: We're here today because we ant to develop an optional add-on module to EPUB.
# [18:34] <fantasai> jdaggett: I'm telling you that within this group we've had ppl say "we have to do this this way because impl for EPUB already do this this way"
# [18:34] <fantasai> jdaggett: That's not the right way.
# [18:34] <fantasai> jdaggett: If it's something that's funamentally wrong, I don't buy that argument.
# [18:34] <fantasai> bill: We took the decision, knowing that our maintenance strategy for unfinished specs, would be to rev EPUB .1 .2
# [18:35] <fantasai> jdaggett: Go back to what brady said, Adaptive layout is a minefield.
# [18:35] <fantasai> jdaggett: It's very complex, it's hard to get right. if you start snapshotting, you will run into trouble.
# [18:35] <fantasai> glazou: You said cross-browser implementations, you'll add to EPUB
# [18:35] <fantasai> glazou: It's not beacuse we have cross-browser implementation of something at some point that the spec is stable
# [18:36] <fantasai> glazou: for us the only moment we can say something is stable enough is when we move from CR to PR.
# [18:36] <fantasai> glazou: The good example is gradients.
# [18:36] <fantasai> glazou: We have four incompatible specs for gradients.
# [18:36] <fantasai> glazou: At some point we may have 2 or 3 compatible implementation
# [18:36] <fantasai> glazou: If you rely on temporary stuff, if it's not a recommendation
# [18:37] <fantasai> Florian: I think Steve is a valid point. If we have a scehdule, a feature set, and a quality requirement
# [18:37] <fantasai> Florain: i.e. spec is advanced enough
# [18:37] <fantasai> Florian: We can't have these things all at the same time
# [18:37] <fantasai> Florian: Prioritizing your features is important.
# [18:37] <fantasai> Florian: We can try to push ahead faster with higher priority things.
# [18:38] <fantasai> Florian: We have a lot of things, some of which you care, some not so much.
# [18:38] <fantasai> Florian: We won't exclusively work on your things, but we can give it more wieght
# [18:38] <fantasai> Florian: We are quality-driven, you are schedule driven. The only way to work together is prioritizing
# [18:38] * Joins: mgylling (mgylling@83.251.132.182)
# [18:39] <fantasai> smfr: the othe rissue of snapshotting WDs is that it puts a burden on implementers
# [18:39] <fantasai> smfr: We have to maintain old behavior for compatibility, that we really don't want to have to maintain
# [18:39] <fantasai> smfr: In Ebkit we try to avoid flags, "we are rendering epub"
# [18:40] <fantasai> smfr: We might not even be aware that EPUB snapshotted some draft spec
# [18:40] <myakura> s/Ebkit/WebKit/
# [18:40] <fantasai> Markus: I totally understand where you guys are coming from. Because if you don't push the needle, you wind up with ... Amazon
# [18:40] <fantasai> Markus: I think he solution to this problem is prioritization Florian brought up. So if you keep separation of content and style
# [18:41] <fantasai> Markus: We of course don't work on content
# [18:41] <fantasai> Markus: That is best model to work forward
# [18:41] <fantasai> szilles: In category of requirements, might be useful to look at what Peter proposed to IDPF as kinds of things publishers are looking for
# [18:41] <fantasai> duga: Charter does list some priorities, and I epxect next few days we'll see more concrete proposal
# [18:42] <fantasai> duga: We're defining these as a vendor extesion, but will show what we might depend on.
# [18:42] <fantasai> duga: You might not do adpative layout on our schedule, but o we depend on calc(), or CSS regions,
# [18:42] <fantasai> s/duga/bill/
# [18:42] * Parts: howard (howard_wan@63.145.238.4)
# [18:42] <fantasai> bill: We need to work together with those.
# [18:43] <fantasai> szilles: We've had demos from MS and Opera of paginated documents, so they're very much on the structure.
# [18:43] <fantasai> (using CSS)
# [18:43] <fantasai> szilles: They are going in that particular direction, so showing the PGT sort of things is relevant. It's written on top of HTML and CSS
# [18:43] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [18:43] <fantasai> hober: I tihkn echoing florian and john...
# [18:43] <mmielke> Correction: Amazon is having a model that is based on REC specs (CSS2.1 capabilites) and do not rely on specs in working drafts
# [18:44] <fantasai> hober: I think there's a diff between source of dependence of WDs in EPUB3 and this new high-design module whatever
# [18:44] * Quits: dcosta (dcosta@187.31.77.7) (Quit: bbl)
# [18:44] <fantasai> hober: It's one thing to epub-prefix writing modes
# [18:44] <fantasai> hober: But this last couple days, I've seen some very interesting and very different proposals for doing these kinds fo layouts
# [18:44] <fantasai> hober: so different that even if we make an amazing amount of progres sin the next 6months, I have no idea what it's going to look like
# [18:45] * Quits: lgombos_ (Laszlo@63.145.238.4) (Ping timeout)
# [18:45] <fantasai> hober: Baking in something like regions is petrifying.
# [18:45] <jdaggett_> fantasai: our specs have different phases
# [18:46] <jdaggett_> fantasai: you really don't want to depend on something that's not in the stabilizing phase
# [18:46] <jdaggett_> fantasai: all the layout proposals are in the completely unstable phase
# [18:46] <fantasai> bill: If you say we shouldn't reference something, then we won't.
# [18:47] <fantasai> bill: We want to have publishers avoid creating proprietary features
# [18:47] <alexmog> q+
# [18:47] <fantasai> howcome: I agree with steve there is strong interested in moving to on-screen pages, so we have common interests
# [18:47] * Zakim sees alexmog on the speaker queue
# [18:47] <fantasai> howcome: My concern with some of these e.g. regions is that they are quite complex and they will take a long time to stabilize
# [18:48] <fantasai> howcome: My demo shows that we can do 90% without adding a single property in CSS
# [18:48] <fantasai> bill: The pages things in Opera is awesome. I was showing it at a conference just recently.
# [18:48] <fantasai> bill: However, that's not what makes EPUB tick. The EPUB content isn't content that paginates.
# [18:48] <Bert> q+ to ask about ways to do liaisons
# [18:48] * Zakim sees alexmog, Bert on the speaker queue
# [18:48] <fantasai> bill: It's ... orchestrated
# [18:48] <fantasai> manifest
# [18:48] <fantasai> bill: I welcome paged views, but it's not what EPUB has
# [18:49] <fantasai> bill: That's EPUB2 level. We have picturebooks, magazines, etc.
# [18:49] <dbaron> q+ jdaggett
# [18:49] * Zakim sees alexmog, Bert, jdaggett on the speaker queue
# [18:49] <fantasai> bill: template-based stuff
# [18:49] <duga> AAL charter: http://code.google.com/p/epub-revision/wiki/AdvancedAdaptiveLayoutCharter
# [18:49] * Joins: lgombos (Laszlo@63.145.238.4)
# [18:49] <fantasai> alex: I might be a little confused with teh background, what you're saying "us", is this EPUB or is this advanced adaptive layout charter group
# [18:50] <fantasai> bill: My immediate agenda item is coordination around advanced layout, but first issues raised are about genera principles of IDPF
# [18:50] <fantasai> standardization practice
# [18:50] <JohnJansen> zakim, who is on the q?
# [18:50] <Zakim> I see alexmog, Bert, jdaggett on the speaker queue
# [18:50] <dbaron> ack alexmog
# [18:50] * Zakim sees Bert, jdaggett on the speaker queue
# [18:50] <fantasai> bill: IDPF is a trade associate of publishers and ppl working in publishing. Very focused on publications, with a range from trade books to more compelx pbulications
# [18:50] <plinss> ack alexmog
# [18:50] * Zakim sees Bert, jdaggett on the speaker queue
# [18:50] <fantasai> alex: ... how much youre' going there.
# [18:51] <fantasai> alex Around 10 years ago, MS had an epub format which was subset of HTML+CSS
# [18:51] <fantasai> alex: It seems that in advanced layout is that you're willing to very divergent standizing of something
# [18:51] <fantasai> alex: is this something we should do in tihs group?
# [18:51] <fantasai> bill; that would be fantastic
# [18:51] <fantasai> bill: We asked W3C staff for review of our charter
# [18:52] <fantasai> bill: We're trying to meet the timeline of our members
# [18:52] <fantasai> bill: We are a date-driven organization, not so much quality
# [18:52] <dbaron> bill: we didn't receive comments on the charter from CSSWG members
# [18:52] <fantasai> bill: ... We're trying to get things out the door, and will accept the risks of some things fail.
# [18:52] <fantasai> bill: more like a startup
# [18:52] * Joins: szilles (chatzilla@63.145.238.4)
# [18:52] <szilles> q?
# [18:52] * Zakim sees Bert, jdaggett on the speaker queue
# [18:53] <fantasai> alex: You can have 8-month completely standard for a paginated document book and magazine layout and it will be ready for publication and have implementations? *skeptical*
# [18:53] <dbaron> q+ hober
# [18:53] * Zakim sees Bert, jdaggett, hober on the speaker queue
# [18:53] <fantasai> bill: yes. were' generalizing work that a member has already done
# [18:53] <szilles> q+ to show example document
# [18:53] * Zakim sees Bert, jdaggett, hober, szilles on the speaker queue
# [18:53] <hober> q+
# [18:53] * Zakim sees Bert, jdaggett, hober, szilles on the speaker queue
# [18:53] <fantasai> peter: I'm from adobe, I'm member of IDPF WG.
# [18:53] <dbaron> peter == Peter Sorotokin
# [18:53] <fantasai> peters: We have a lot of idfferences, not only how the standards is driven, but also how these documeents actually live
# [18:53] * hober thanks dbaron :)
# [18:53] <fantasai> peters: Complex websites get updated daily. Books don't
# [18:54] <fantasai> peters: The JS on the Web, you can't afford for books on the web.
# [18:54] <fantasai> peters: You want to publish it and forget about it, not maintain it.
# [18:54] <fantasai> peters: Puts a lot of pressure for having declartive ways of doing things.
# [18:54] <fantasai> peters: pressure is very differernt
# [18:54] <fantasai> peters: I was voicing a lot of similar concerns about referencing CSS WDs in IDPF
# [18:54] <fantasai> peters: A lot of these references come from East Asian market
# [18:55] <fantasai> peters: There are competing standards there. If we give up and not do it for 2 years, it's saying we won't do EBooks with CSS.
# [18:55] <fantasai> peters: You're lucky, there is no CSSX, nobody is trying to fork it or do someting completely different.
# [18:55] <fantasai> peters: We have this problem in ebooks, we cannot ignore
# [18:55] <fantasai> peters: One of our considerations for advanced layout proposal is to make sure it can be implemented today on top of existing browsers
# [18:56] <fantasai> peters: As long as we can do it today, we can be sure we can do it in future borwsers.
# [18:56] <fantasai> peters: That simpliefies the javascript.
# [18:56] * Quits: glazou (glazou@63.145.238.4) (Ping timeout)
# [18:56] <fantasai> peters: You'd need to augment your presentation with JS
# [18:56] <fantasai> peters: There is no requirement for JS in the publishing world as in browser
# [18:56] <fantasai> peters: iT's possible to move forward with moving creating more properties and eatures without touching the browser at all
# [18:56] <plinss> ack Bert
# [18:56] <Zakim> Bert, you wanted to ask about ways to do liaisons
# [18:56] * Zakim sees jdaggett, hober, szilles on the speaker queue
# [18:56] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
# [18:57] <jdaggett_> ack Bert
# [18:57] * Zakim sees jdaggett, hober, szilles on the speaker queue
# [18:57] <fantasai> Bert: My conclusion so far is that we can only influence each others time scales so much, so how do we limit the damange?
# [18:57] <fantasai> Bert: two wasy to do that
# [18:57] <fantasai> Bert: One is to have timely info from EPUB of what they mean, so we can within the littel flexiblity we have, to work on their things faster
# [18:58] <fantasai> Bert: Also would be a good thing if we can give advice regularly to EPUB to avoid that they make too many mistakes
# [18:58] <dbaron> q+ to ask about future epub versions
# [18:58] * Zakim sees jdaggett, hober, szilles, dbaron on the speaker queue
# [18:58] <fantasai> Bert: Steer you into somehting that's a littel bit safe. How do we make sure that happen?
# [18:58] <fantasai> Bert: Way to do that is liaisons, need people on both sides to communicate
# [18:58] <fantasai> Bert: maybe I should take some responsibility for that, it's in scope for my work anyway.
# [18:58] <fantasai> Bert: Maybe bring other people along to join meetings/telecons
# [18:59] <fantasai> Bert: Talking to each other is best way
# [18:59] <fantasai> Bert: Peter siad books cannot be changed. That means you need even more stable standards than the web browsers.
# [18:59] <fantasai> Bert: So you really need things that are extremely stable
# [18:59] <fantasai> Bert: You want to buy a book and 10 years still read it
# [18:59] <alexmog> q+
# [18:59] * Zakim sees jdaggett, hober, szilles, dbaron, alexmog on the speaker queue
# [19:00] <fantasai> bill: We had a lot of help from fantasai for EPUB3, but she was clear that she couldn't represent full bandwith of CSSWG
# [19:00] * Joins: glazou (glazou@63.145.238.4)
# [19:00] <fantasai> bill: I thin future of publishing in digital world is up for grab, some overlap with widgets and webapps
# [19:00] <fantasai> bill: various points of synergy
# [19:00] <fantasai> peterl: I in process of joining the EPUB group. I think you'll have interst in CSSWG to work with you guys. There would be good to have ppl from EPUB to join us on a regular basis
# [19:01] <plinss> ack jdaggett
# [19:01] * Zakim sees hober, szilles, dbaron, alexmog on the speaker queue
# [19:01] <fantasai> jdaggett: To your point about schedule and having things that you need to ship immediately.
# [19:01] <fantasai> jdaggett: that's ifne.
# [19:01] <plinss> ack hober
# [19:01] * Zakim sees szilles, dbaron, alexmog on the speaker queue
# [19:01] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
# [19:01] * Joins: arronei_ (arronei@63.145.238.4)
# [19:01] <fantasai> jdaggett: In the case of adaptive layout, you need to communicate to ppl in your organization, that by standardizing on your time scale, you pretty much guarantee incompat with future web standards
# [19:02] <fantasai> peters: The point we're trying to achieve, you can develop an EPUB UA on to p of the browser using JavaScript
# [19:02] <fantasai> jdaggett: Whether that's possible, I cannot tell you
# [19:02] <fantasai> jdaggett: It's not standardized
# [19:02] <fantasai> Florian: Sometimes specs are more stable and not marked at such. In this case we're alking about stuff that's really really unstable
# [19:03] <fantasai> hober: What bill said earlier, that EPUB is trying to be very agile organization. THink it's a very great term, want to hit on the vialbe part
# [19:03] <fantasai> hober: Like Florian said, if you have [3 things], there's inherent ension there.
# [19:03] <JohnJansen> s/ension/tension
# [19:03] <fantasai> hober: To resolve you're best off dropping features
# [19:03] <fantasai> ...
# [19:04] <fantasai> bill: We're clear on that, but our main focus of where compat is
# [19:04] <fantasai> bill: We want that markup produced by tool like InDesign will work in the future
# [19:04] <fantasai> bill: More important than compat with Web
# [19:04] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [19:04] <fantasai> s/future/future epub readers/
# [19:04] <plinss> ack szilles
# [19:04] <Zakim> szilles, you wanted to show example document
# [19:04] * Zakim sees dbaron, alexmog on the speaker queue
# [19:04] <fantasai> szilles: Let me try to say what peters was saying in slightly different words.
# [19:05] <fantasai> szilles: there is a presumption in a number of the comments that the features that go into EPUB3+ are features that need to go into CSS
# [19:05] * Joins: howard (howard_wan@63.145.238.4)
# [19:05] <fantasai> szilles: What peter is saying is slightly different. Pter is saying that CSS today provides enough capbility with JS to take a declarative language and present what you see on the screen
# [19:05] <tcelik> I'm a little confused about the confusion around communicating stability of CSS specs, isn't that what Beijing did/does (2007, 2010) ?
# [19:06] <fantasai> szilles: Adobe has been trying to pieces of that mechanism that are hard to replicate in JS and migrate them into CSS
# [19:06] <fantasai> szilles: on a timescale that fits with CSS. Because there are solutions that work in the interim
# [19:06] <fantasai> szilles: Regions would make these demos easier to do.
# [19:06] <fantasai> alan: But these demos don't depend on any of the new stuff
# [19:07] <fantasai> szilles: There are other things like line grid that can't be done in JS, and we'd need to move within CSSWG
# [19:07] <fantasai> szilles: So agreeing on those pieces is the most important thing we can do
# [19:08] <fantasai> Florian: What you said is imporant to me. Your highest priority is not necessary what should be our priority, since you can do much of this without us.
# [19:08] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
# [19:08] <fantasai> bill: ...
# [19:09] <fantasai> bill: From my pov, even if something's implementable in JS, if we nevertheless use a similar markup... or create our own, it could be a problem later
# [19:09] <dbaron> ack dbaron
# [19:09] <Zakim> dbaron, you wanted to ask about future epub versions
# [19:09] * Zakim sees alexmog on the speaker queue
# [19:09] <fantasai> bill: Don't want to sweep that under the table and say we're not worrying about it.
# [19:09] <fantasai> dbaron: You've mentioned that when you did EPUB3 it was essentially a different format from EPUB2. Is it backwards compatible?
# [19:10] <fantasai> bill: You could write EPUB3 that works on EPUB2 reader. Also EPUB2 books must work in EPUB3 reader
# [19:10] <fantasai> dbaron: What if EPUB3 depends on a technology that goes in a different way than this CSSWG goes?
# [19:10] <fantasai> dbaron: Would future versions of EPUB require the divergent technology? What CSSWG creates? Both?
# [19:11] <fantasai> duga: In EPUB3 we tried to point out pieces where things are likely to change incompatibly.
# [19:11] <fantasai> duga: We've committed to advancing with CSS, and pointing out to authors to beware of these potential changes
# [19:11] <glazou> q+
# [19:11] * Zakim sees alexmog, glazou on the speaker queue
# [19:11] <fantasai> bill: EPUB4 might say a ruby property is deprecated and nonconformant in content, but UAs must still implement it
# [19:11] <plinss> ack alexmog
# [19:11] * Zakim sees glazou on the speaker queue
# [19:11] <fantasai> Alex: Some questions
# [19:12] * Joins: ChrisL (ChrisL@128.30.52.169)
# [19:12] <fantasai> Alex: I'm really surprised we're talking about liaisons and you doing some significant amount of work, but also we're doing here
# [19:12] <fantasai> Alex: I'm surprised that *I'm* not involved, as someone making major progress on Regions
# [19:12] <fantasai> Alex: why not talk to us?
# [19:12] <fantasai> jdaggett: alex editors regions
# [19:12] <fantasai> alex: Whatever.. finish regions sooner, there are opportunities for us to make parallel progress
# [19:13] <fantasai> alex: We here need help as well. kindof depressing that I discuss stuff with Vincent and nobody else contributes
# [19:13] <fantasai> bill: regions is 25% of advanced adaptive layout
# [19:13] * Joins: Kai (chatzilla@63.145.238.4)
# [19:13] <ChrisL> rrsagent, here
# [19:13] <RRSAgent> See http://www.w3.org/2011/10/31-css-irc#T18-07-55
# [19:13] <fantasai> Florian: Reigons is a good example. Because it's one of the difficult pieces here, only a few people understand it rest are waiting until they're done
# [19:14] <tcelik> what's the other 75%?
# [19:14] <fantasai> Florian: I fppl in your group are working on the same thing, participating here will make these ppl feel a lot less lonely
# [19:14] * Quits: MoZ (MoZ@63.145.238.4) (Quit: Quitte)
# [19:14] <fantasai> alex: My second point is, it seems that something that will get produced in a very short time and targetted at a very specific applications, seems very similar to a company shipping product with publicly document format, designed by one company
# [19:14] <fantasai> alex: we've done this with MS office format. develpped by one company for its purposes
# [19:15] <fantasai> alex: Seems similar to me.
# [19:15] <fantasai> alex: I fyou don't have any requirements for that format to be tied to CSS WG, does it belong to W3C?
# [19:15] <stearns> tcelik: see the charter that was linked above
# [19:15] <fantasai> alex: Would it be your format that is documented and supported by reader applications, and whatever CSS or HTML requires has ...
# [19:15] <tcelik> stearns thanks
# [19:15] <plinss> ack glazou
# [19:15] * Zakim sees no one on the speaker queue
# [19:15] <fantasai> alex: ... support forever
# [19:15] <fantasai> glazou: I have quesiton of prefixed properties you're going to use
# [19:16] <fantasai> glazou: Say you'll sync with us and drop things not used anymore
# [19:16] <fantasai> glazou: What if you adopt, e.g. gradients now.
# [19:16] <fantasai> glazou: Gradients are going to drasticaly change in next 12 months, at which point your gradients are entirely incompatible
# [19:16] <fantasai> glazou: It's not about dropping version, but changing the value of that property
# [19:16] <fantasai> glazou: The books in the old eversion would be incompat with new one
# [19:16] <fantasai> bill: Alias would be maintianed
# [19:17] <fantasai> bill: One option, reader detects 3.0 vs 3.1 and ...
# [19:17] <fantasai> peters: We would wait until you reached CR, even if we have our epub gradient
# [19:17] <fantasai> peters: Once you reach CR, we would import your stuff and be done iwth it
# [19:17] <fantasai> glazou: It's unlikely between editing tools for EPUB would be different than Web
# [19:17] <fantasai> glazou: You chose HTML+CSS
# [19:17] <fantasai> glazou: Again the rendering engines are going to be the same
# [19:18] <fantasai> glazou: so having -epub-prefixed properties does not make sense
# [19:18] <fantasai> glazou: Editing tools won't deal with that
# [19:18] <fantasai> glazou: You are not doing editing tool, you're doing a converter
# [19:18] <fantasai> bill: we agree with premise of minimizing prefixed properties
# [19:18] <tcelik> stearns, captured on the CSSWG wiki: http://wiki.csswg.org/spec#idpf-epub
# [19:18] <fantasai> bill: Only 3: text, speech, and ruby are used prefixed
# [19:18] <fantasai> bill: And those are generally for east asian typography
# [19:19] <fantasai> bill: we would prefer not to have prefixed properties, no question
# [19:19] <fantasai> bill: We want EPUB ot be portable documents base don open web
# [19:19] <fantasai> szilles: Actionable items I heard were to increase liaison participation in both groups
# [19:20] <fantasai> szilles: Bert volunteered to get involved in IDPF. Can we ask IDPF group to expand liaison with our organization?
# [19:20] <fantasai> glazou: We have a lot of things to discuss together.
# [19:20] <fantasai> bill: A mechanistic point, several of the key IPDF members have presence in CSSWG
# [19:20] <fantasai> bill: Adobe, Google, Apple
# [19:20] <tcelik> Can we ask IDPF to directly participate in CSS spec discussions on www-style?
# [19:20] <tcelik> s/ask/invite
# [19:21] <fantasai> bill: Might ask for redundant representation, but not up to us
# [19:21] <fantasai> glazou: We need coordination between two groups. Not the same thing as coordination between members.
# [19:21] <fantasai> szilles: Getting more participation from ppl not reprsented at the table today, more likely to have informative opinions and users
# [19:22] <fantasai> szilles: We have a lot of technologists at the table, far less users.
# [19:22] <fantasai> szilles: Unerstanding what's being asked for is a difficulty
# [19:22] <fantasai> <br>
# [19:22] * Quits: duga (duga@63.145.238.4) (Quit: duga)
# [19:23] * Joins: howcome (howcome@63.145.238.4)
# [19:26] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
# [19:27] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
# [19:27] * Joins: mollydotcom (mollyh@63.145.238.4)
# [19:27] * Quits: mihara (mihara@63.145.238.4) (Connection reset by peer)
# [19:32] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
# [19:33] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
# [19:34] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [19:34] * Joins: mmielke (mmielke@63.145.238.4)
# [19:34] * Joins: Cathy (qw3birc@128.30.52.28)
# [19:40] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
# [19:41] * Joins: Rossen (Rossen@63.145.238.4)
# [19:42] * Quits: AnanKan (AnanKan@63.145.238.4) (Ping timeout)
# [19:46] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
# [19:48] * Joins: anne (annevk@63.145.238.4)
# [19:48] * Joins: mihara (mihara@63.145.238.4)
# [19:49] <TabAtkins_> scribenick: TabAtkins_
# [19:49] <TabAtkins_> florian: Extra agenda item - CSS3 Text, talking about text-transform
# [19:49] * Joins: bradk (bradk@63.145.238.4)
# [19:49] <TabAtkins_> sylvaing: Extra agenda item - discuss how to move some of the current specs with lots of impl xp.
# [19:51] * Joins: mmielke (mmielke@63.145.238.4)
# [19:51] <bradk> xp = experience points?
# [19:51] * Joins: cyril (chatzilla@63.145.238.4)
# [19:53] <TabAtkins_> JohnJansen: I'm thinking there are N new tests, and I'm wondering when they're going to be moved into a snapshot.
# [19:53] <TabAtkins_> JohnJansen: And what it means if we don't have two impls passing those new tests.
# [19:54] <TabAtkins_> fantasai: To the 2nd q, it doesn't mean anything - we're just moving to better interop. It doesn't revoke our Rec status.
# [19:54] <TabAtkins_> fantasai: To the 1st q, I think somebody needs to make sure everything's in order and nothing's been lost (general vetting), and then we can just create a new snapshot any time.
# [19:55] <TabAtkins_> JohnJansen: Should we have a regular schedule for that, so I can predictably work on it? Otherwise things tend to sit.
# [19:55] <TabAtkins_> fantasai: Sounds good. What schedule do you want?
# [19:55] <TabAtkins_> JohnJansen: I think it should be in conjunction with publishing errata, so tests over the new errata show up at the same time.
# [19:55] <TabAtkins_> plinss: I think that makes a lot of sense, it's a no-brainer.
# [19:56] <TabAtkins_> plinss: Gerard's been reviewing a bunch of tests, and have a bunch flagged now with problems, but no one's working on them.
# [19:56] <TabAtkins_> JohnJansen: I think one of the challenges is prioritization.
# [19:56] <TabAtkins_> JohnJansen: Gerard is making a lot of comments (others too) - some are corrections, some are improvements.
# [19:56] <TabAtkins_> JohnJansen: But they get the same prioritization. I'd like to prioritize a correction versus an optional improvement.
# [19:56] <TabAtkins_> JohnJansen: We should jump on errors.
# [19:57] <TabAtkins_> JohnJansen: When I come into work in the morning, though, I dunno if I should work on 2.1 tests or css3 new tests.
# [19:57] <TabAtkins_> JohnJansen: We've got a lot of specs approaching CR or even Rec that need tests.
# [19:57] <TabAtkins_> JohnJansen: But I've got a finite amount of time in my day.
# [19:57] <TabAtkins_> JohnJansen: So some help in prioritizing would be helpful.
# [19:57] <TabAtkins_> fantasai: You also wanted a snapshot at the time of errata pub.
# [19:58] <TabAtkins_> fantasai: I'm not sure how long it takes to go from PER to Rec, but we are *way* behind on tracking 2.1 issues.
# [19:58] <TabAtkins_> JohnJansen: Right. It's never on the agenda.
# [19:58] <TabAtkins_> fantasai: And simple, I stopped tracking them - I switched to other specs. I was never even an editor, but I was doing most of the tracking.
# [19:59] <TabAtkins_> fantasai: So we need somebody to track the issues for 2.1. They need to start now, track into the future, and move backwards to the LC deadline, which is a lot of stuff.
# [19:59] <TabAtkins_> fantasai: And once we have a list, we can do a few issues each telcon and make progress.
# [19:59] <TabAtkins_> fantasai: And make sure that resolutions end up in the errata and the draft.
# [19:59] <TabAtkins_> fantasai: And I am *not* volunteering to do that.
# [19:59] * Joins: tpod (tpod@63.145.238.4)
# [19:59] <TabAtkins_> fantasai: We can't have a new errata until someone takes it up.
# [20:00] <fantasai> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html
# [20:00] <TabAtkins_> JohnJansen: yesterday we made a decision on margin-collapsing that needs to go in, for example, and it should be tracked.
# [20:00] <TabAtkins_> fantasai: Theoretically it should be in bugzilla.
# [20:00] <TabAtkins_> Bert: I've been lax about this, but I'm going to go through and extract things to Bugzilla.
# [20:00] <TabAtkins_> Bert: I'll start when I get back to my office.
# [20:01] <dbaron> http://wiki.csswg.org/spec/css2.1 says "Last mailing list sweep 2011-01-07 – arronei "
# [20:01] <TabAtkins_> fantasai: If you can maintain a date range that you have definitely covered, that would be very useful.
# [20:01] * Quits: mmielke (mmielke@63.145.238.4) (Ping timeout)
# [20:01] <TabAtkins_> fantasai: So if somebody decides to help you, they can just start at the last date you've touched and work backwards.
# [20:02] <TabAtkins_> dbaron: I'll edit the 2.1 issues wiki to say that new issues go to Bugzilla.
# [20:02] <TabAtkins_> dbaron: But we can still keep the mailing list sweep dates here in the wiki.
# [20:02] <TabAtkins_> dbaron: And there's a bunch of open issues here in the wiki that need to migrate.
# [20:02] * Joins: szilles (chatzilla@63.145.238.4)
# [20:03] <TabAtkins_> JohnJansen: Last idea - encourage the focus to fall on CSS3 modules, from a testing perspective, rather than continuing to focus exclusively on 2.1.
# [20:03] <TabAtkins_> fantasai: One thing to keep in mind is that all tests in 2.1 are a subset of the tests we'll need in css3.
# [20:03] <TabAtkins_> fantasai: So for B&B3, we'll just take all the relevant tests from 2.1, convert to reftest if possible, and then augment with new tests.
# [20:04] <TabAtkins_> fantasai: Because that's easier than just writing entirely new tests.
# [20:05] <TabAtkins_> plinss: In most cases, that's nothing more than adding a new spec link to the existing test. No moving, no copying, just add a new link and Shepherd will pick it up and track.
# [20:05] <gsnedders> How does Shepherd cope with tests becoming reftests?
# [20:06] <TabAtkins_> JohnJansen: Even if we moved all the 2.1 tests for B&B to B&B tests, we're still not complete.
# [20:06] <plinss> not an issue, it just adds the reference
# [20:06] <TabAtkins_> JohnJansen: So should we prioritize writing more css3 tests, or continue prioritizing 2.1.
# [20:06] <TabAtkins_> fantasai: We need both, but we should prioritize writing new tests for 3.
# [20:06] * Joins: gilles (gilles@63.145.238.4)
# [20:06] <TabAtkins_> fantasai: If people outside the WG want to work on 2.1, we should support them, though.
# [20:06] <TabAtkins_> JohnJansen: Agreed, but I'm not sure that we should *encourage* them to work on 2.1.
# [20:07] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
# [20:07] <TabAtkins_> JohnJansen: As a WG, we should give guidance to people who want to participate, and we should guide them to work on 3.
# [20:07] <TabAtkins_> dbaron: Two types of tests - one is to validate the spec, and one is to improve interop.
# [20:07] <TabAtkins_> dbaron: For the former, the priority should be writing for css3. For the latter...
# [20:07] <TabAtkins_> dbaron: I don't want to discourage 2.1 tests. We're still undertesting parts of the spec.
# [20:08] <TabAtkins_> TabAtkins_: So if someone comes up and says "I want to work on tests", we should encourage specific css3 tests.
# [20:08] <TabAtkins_> TabAtkins_: But if they want to work on 2.1 tests specifically, that's cool.
# [20:09] <TabAtkins_> fantasai: We should have a list of specs that need testing help, but Gerard, for example, really wants to work on 2.1 interop, and that's fine.
# [20:09] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
# [20:09] <TabAtkins_> fantasai: We can put a list on the wiki of specs that are in maintenance and could use tests.
# [20:10] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
# [20:10] <TabAtkins_> JohnJansen: And additionally, we don't know and can't really track what parts of 2.1 need tests, we just have sort of a gut feeling.
# [20:10] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [20:10] * Parts: howard (howard_wan@63.145.238.4)
# [20:10] <TabAtkins_> JohnJansen: We can provide rough guidance there too, though.
# [20:10] <TabAtkins_> JohnJansen: My preferred idea is that we're just done with 2.1, it's Rec, and we have a regular maintenance schedule, but it's not a living spec that needs active attention.
# [20:11] <TabAtkins_> arronei: We need a per-spec maintenance schedule.
# [20:11] <TabAtkins_> plinss: Probably in conjunction with the snapshot.
# [20:11] <TabAtkins_> fantasai: We don't have anything new to snapshot yet, but we have a lot of things to errata.
# [20:12] <TabAtkins_> fantasai: I don't see anything being added to the 2010 snapshot that's not already in the 2011 snapshot.
# [20:12] <TabAtkins_> arronei: Why not put errata in there?
# [20:12] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
# [20:12] <TabAtkins_> plinss: We can have a list of "these specs are in Rec, here's their errata", etc.
# [20:13] * Quits: myakura (myakura@63.145.238.4) (Client exited)
# [20:13] <TabAtkins_> fantasai: Right now we just list the stable things and link to the spec. So that's no change.
# [20:13] * Joins: duga (duga@63.145.238.4)
# [20:14] <TabAtkins_> arronei: I think it's good to publish an annual snapshot anyway. I want to see the 2011 snapshot, not the 2010 snapshot.
# [20:14] <TabAtkins_> TabAtkins_: It's difficult to tell the difference between "there was no change, so no updates" and "the spec is dead, and it's out-of-date".
# [20:14] <TabAtkins_> JohnJansen: And without a deadline to the issue tracking, work will grow to fill the alloted time.
# [20:14] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [20:15] <TabAtkins_> JohnJansen: With a specific once-per-year date or something, we know when things are expected and have a push to get the necessary things done.
# [20:15] <TabAtkins_> arronei: I'm hearing that we want a maintenance schedule. Should we set one up for 2.1 right now?
# [20:15] <TabAtkins_> arronei: And beyond that, each spec can have its own schedule (or hook into the existing one, we can evaluate per module).
# [20:15] <TabAtkins_> arronei: But we should at least nail down 2.1's schedule.
# [20:15] <TabAtkins_> fantasai: PLH suggested republishing every year.
# [20:16] <TabAtkins_> fantasai: Should we set a goal to have all issues in the tracker by the Feb meeting? Bert, is that workable?
# [20:16] <TabAtkins_> Bert: Yes.
# [20:16] <TabAtkins_> RESOLVED: Have all 2.1 issues filed in bugzilla by the february meeting.
# [20:16] <TabAtkins_> dbaron: I think 2.1 issues are best addressed on the mailing list, not in a f2f.
# [20:17] <TabAtkins_> fantasai: Right, this is just a deadline for getting them in a tracker, not resolving them.
# [20:17] <dbaron> dbaron: We should at least attempt to deal with them on the mailing list before bringing them to a f2f meeting.
# [20:17] <TabAtkins_> RESOLVED: Publish an updated version of 2.1 and its testsuite annually.
# [20:17] * Parts: Ruinan (sunruinan@63.145.238.4)
# [20:18] * dbaron thought tab was going to say "the ideal future where we've carved it all onto stone tablets"
# [20:18] <TabAtkins_> RESOLVED: Update the site/wiki/etc to publicly prioritize testing css3 modules rather than 2.1.
# [20:19] <TabAtkins_> Bert: Once a year seems quite fast. More like every 5 years seems more reasonable.
# [20:19] <TabAtkins_> plinss: We should keep the once-a-year as a review cycle. If it turns out that the issues are tiny, okay, we'll skip publishing this year.
# [20:19] <TabAtkins_> PROPOSED EDITED RESOLUTION: Ensure that 2.1 is up-to-date yearly.
# [20:20] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [20:20] <gsnedders> IMO publishing once a year makes sense if there are non-editorial issues. Even if the issues are tiny it's probably still worth publishing if they have normative consequences.
# [20:20] <TabAtkins_> plinss: Should we commit to publishing an annual snapshot?
# [20:21] <TabAtkins_> RESOLVED: Publish a snapshot annually.
# [20:21] <TabAtkins_> fantasai: I think we should try to address 2.1 issues on the telcon each week.
# [20:21] <TabAtkins_> plinss: Once we get some together, yeah.
# [20:22] <TabAtkins_> dbaron: I think we should try to resolve them on the mailing list first.
# [20:22] <TabAtkins_> plinss: Yes. But once a proposal appears on the mailling list, quickly discuss it for telcons.
# [20:22] <TabAtkins_> JohnJansen: Another thing - I don't yet know how to prioritize the comments to the list for the current 2.1 testsuite.
# [20:23] <TabAtkins_> fantasai: If it's invalid, fix it immediately.
# [20:23] <TabAtkins_> fantasai: Tests that are imprecise (impls can pass when they actually fail the spec) should be fixed next.
# [20:23] <TabAtkins_> fantasai: And then issues with metadata or reusability are nice-to-fix, but not strictly necessary.
# [20:24] <TabAtkins_> fantasai: Every time we snapshot, the first two types should have all been fixed.
# [20:24] <TabAtkins_> fantasai: The last should be fixed as time allows.
# [20:24] <TabAtkins_> JohnJansen: I agree with that.
# [20:25] <TabAtkins_> JohnJansen: I don't yet know when I should make sure that's done by.
# [20:25] <TabAtkins_> fantasai: The last pub was June 2011, so the next will be June 2012, since we're doing yearly.
# [20:25] <fantasai> http://test.csswg.org/shepherd/
# [20:25] <TabAtkins_> RESOLUTION: All issues with the tests (not the testsuite) go to Shepherd.
# [20:25] <fantasai> s/testsuite/infrastructure/
# [20:26] <dbaron> http://test.csswg.org/shepherd/
# [20:26] <TabAtkins_> Topic: B&B issue
# [20:26] <TabAtkins_> fantasai: Issue 189.
# [20:27] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Nov/0006.html
# [20:27] <fantasai> ISSUE-89
# [20:27] <fantasai> er ISSUE-189
# [20:27] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/189
# [20:27] <fantasai> http://lists.w3.org/Archives/Public/www-archive/2011Jul/0005.html
# [20:28] * Joins: Ms2ger (Ms2ger@91.181.84.233)
# [20:28] * Quits: mgylling (mgylling@83.251.132.182) (Quit: mgylling)
# [20:29] <TabAtkins_> fantasai: Look at the pictures!
# [20:30] <TabAtkins_> fantasai: Which of these 4 looks correct?
# [20:30] <TabAtkins_> plinss: #4
# [20:30] * Joins: cyril (chatzilla@63.145.238.4)
# [20:31] <TabAtkins_> fantasai: #1 is what IE implements.
# [20:31] <TabAtkins_> fantasai: #2 seems to be hooking up the half-way points of the arc lengths.
# [20:31] <TabAtkins_> fantasai: #3 is the current spec which is totally crazy.
# [20:31] <TabAtkins_> fantasai: #4 is what I think is correct.
# [20:31] <TabAtkins_> smfr: I think we should look at different border widths.
# [20:32] <TabAtkins_> fantasai: I picked this for a specific reason.
# [20:32] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
# [20:32] <TabAtkins_> fantasai: ...
# [20:33] <TabAtkins_> smfr: Should border-radius influence what this corner-join should look like?
# [20:33] <TabAtkins_> smfr: In the absence, it's pretty obvious - you just go corner-to-corner.
# [20:33] <smfr> https://bug-9197-attachments.webkit.org/attachment.cgi?id=30423
# [20:33] <TabAtkins_> smfr: This diagram shows our logical interpretation which is independent of border-radius.
# [20:33] <TabAtkins_> dbaron: That doesn't work when one of the sides is very narrow or 0.
# [20:34] <TabAtkins_> dbaron: You get a thick border that curves down, and then suddenly changes color at these two triangles, and that looks really bad.
# [20:34] <smfr> http://jsfiddle.net/jMb8k/
# [20:34] <fantasai> fantasai^: The reason I chose equal widths is that we know the angle must vary to zero when the width of either side is zero, and there are multiple ways to map the ratio of widths onto angles, but 1:1 is definitely 45deg.
# [20:34] * Joins: AndroUser (androirc@63.145.238.4)
# [20:34] <fantasai> fantasai^: The quesiton here is how do you interpret "45deg"
# [20:35] <TabAtkins_> dbaron: Did you consider that the spec is mostly correct, but it should be looking at the curvature of the padding edge instead of border-edge?
# [20:35] <TabAtkins_> fantasai: What if there's no curvature?
# [20:36] * Quits: tpod (tpod@63.145.238.4) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [20:36] <TabAtkins_> fantasai: The underlying algorithm is to find the point on the border curve where the tangent's angle equals the ratio of the border widths.
# [20:37] <TabAtkins_> plinss: So find the angle that you would have without curvature, take the normal of that, then find the point on the outer curve with a matching tangent.
# [20:37] <TabAtkins_> fantasai: That *sounds* right, but I'm not certain off the top of my head.
# [20:39] <TabAtkins_> dbaron: Based on the fiddle, if we run the algorithm we're thinking of, it would produce the funny backwards-facing transition line that we don't want.
# [20:39] <tcelik> Frankly, I don't want to resolve this without a designer in the room.
# [20:40] <TabAtkins_> fantasai: I *think* you take the ratio of the two widths and apply that to 90deg.
# [20:40] <TabAtkins_> dbaron: Right, that's not our interpretation, and our intepretation is wrong.
# [20:40] <tcelik> If the goal is some sort of aesthetic ideal, we should base it on input from visual designer(s). Basing it on convenience of math or some approximate visual ideal is probably not a good way to resolve this.
# [20:40] <fantasai> tcelik: there's one on your left
# [20:41] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
# [20:41] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [20:41] <TabAtkins_> plinss: I think it's take the line from the inner to outer corner, invert it over the 45deg line, then take the normal and match the tangent.
# [20:41] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
# [20:42] <tcelik> fantasai - and I observe that he's scratching his head.
# [20:42] <TabAtkins_> dbaron: I think I agree with you on the outside point. I'm not certain that "closest point on the inside edge" is correct.
# [20:43] <TabAtkins_> [some unminuted discussion about inner point]
# [20:44] <tcelik> ok I think we should issue a public call for proposals for how to resolve this issue (with the visual samples above as an initial set of possibilities, open to others), and then invite visual designers to provide input (on www-style)
# [20:44] <tcelik> I don't think we should spend further time trying to resolve this among this group in the f2f - I don't think is either a good use of our f2f time, nor will it result in a visually good solution.
# [20:45] <TabAtkins_> I disagree, tcelik. This is productive so far.
# [20:45] * Quits: si-wei (si-wei@63.145.238.4) (Quit: si-wei)
# [20:47] <fantasai> plinss: You take the angle you'd have without a curve. Mirror it over 45deg (so a r45deg line won't change), then take the normal and find the tangent on the outer curve
# [20:47] <fantasai> plinss says to take the tangent on the inner curve
# [20:47] <fantasai> fantasai says she remembers trying that, and it gives bad results -- you want the shortest distance from the chosen outer point
# [20:48] <TabAtkins_> dbaron: I believe a case something like "border-width: thick thin; border-radius: thin thick;" can produce bad transitions with this rule.
# [20:48] * Quits: mollydotcom (mollyh@63.145.238.4) (Quit: mollydotcom)
# [20:49] <TabAtkins_> plinss: I think that has the right behavior. It's at least the limit behavior.
# [20:49] <TabAtkins_> dbaron: Actually, this may not be a big deal either. [mutters over details]
# [20:50] * Quits: AndroUser (androirc@63.145.238.4) (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
# [20:50] <TabAtkins_> ACTION fantasai to detail the algorithm, and produce mockups for lots of corner cases.
# [20:51] * trackbot noticed an ACTION. Trying to create it.
# [20:51] <trackbot> Created ACTION-396 - Detail the algorithm, and produce mockups for lots of corner cases. [on Elika Etemad - due 2011-11-08].
# [20:51] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
# [20:51] <dbaron> http://www.w3.org/Style/CSS/Tracker/actions/396
# [20:51] * Joins: szilles (chatzilla@63.145.238.4)
# [20:51] <florian> http://lists.w3.org/Archives/Public/www-style/2011Sep/0191.html
# [20:52] <TabAtkins_> Topic: text-transform issue
# [20:52] <TabAtkins_> florian: Look at point 4.
# [20:53] <dbaron> or, better, https://www.w3.org/Style/CSS/Tracker/actions/396 which is now "ACTION-396: Detail the algorithm options for position of color transitions on rounded borders, and produce mockups for lots of corner cases."
# [20:54] <TabAtkins_> jdaggett_: The use-case for text-transform:full-size-kana is that in ruby, small kana is mapped to full kana, because otherwise they're too small to be readable.
# [20:54] <TabAtkins_> jdaggett_: That's really the only use-case for this transform.
# [20:54] <TabAtkins_> jdaggett_: And it's relatively small.
# [20:54] <TabAtkins_> jdaggett_: I propose that instead of doing these small use-cases, we have an at-rule that lets you do arbitrary transformations.
# [20:54] <TabAtkins_> jdaggett_: So authors can handle these themselves rather than having to come to us and get it included in a spec.
# [20:55] <TabAtkins_> jdaggett_: I don't think this kana transform is unworthy, but it's a relatively small use-case.
# [20:55] <TabAtkins_> florian: I think there are two main cases for a mechanism like this.
# [20:55] <TabAtkins_> florian: First is the full-size-kana case. Well-defined and small.
# [20:55] <TabAtkins_> florian: Another place where it's useful is removing accents from letters. We can't have a generic algo for this, because it depends on language and context.
# [20:56] <tcelik> to remove accents?
# [20:56] <TabAtkins_> florian: But a specific author and specific document can do this.
# [20:56] <TabAtkins_> fantasai: Dropping accents tends to be done *per word*. It can't even be done per documnet.
# [20:56] * tcelik had a proposal to *add* accents: http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html
# [20:56] <TabAtkins_> fantasai: In Farsi, diacritics usually arn't written, but some are preserved for readability.
# [20:56] <TabAtkins_> florian: There are still useful cases where it's solveable.
# [20:57] <TabAtkins_> florian: For cases that still aren't solveable, well, they're already not solved.
# [20:57] <TabAtkins_> florian: Another case - old-fashioned long s may want to be transformed into a modern s. That's not something we'll probably ever care about as a group.
# [20:57] <fantasai> fantasai^: but in some words, they are preserved because otherwise the word would be ambiguous
# [20:57] <TabAtkins_> jdaggett_: And in Japanese you coul dhave rules that shift from one form of kana to another form. Tiny use-cases.
# [20:57] <fantasai> fantasai^: you cannot solve this use case without a dictionary
# [20:58] <TabAtkins_> jdaggett_: For i18n, it's simpler to just give people a rule. If we find people using a particular kind consistently, we can then standardize it.
# [20:58] <TabAtkins_> howcome: I think this is a good idea, and is similar to @counter-style.
# [20:58] * tcelik notes a problem report regarding text-transform: https://twitter.com/psd/status/128565170514567168
# [20:58] <TabAtkins_> jdaggett_: I propose then that we drop this property value and move towards defining this transform rule and its syntax.
# [20:58] <tcelik> specifically: text-transform: uppercase turns "0.1µF" into "0.1MF"
# [20:58] <TabAtkins_> szilles: One concern I always raise is, is this opening a security hole?
# [20:59] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [20:59] <TabAtkins_> dbaron: It seems like anything you can do here, you can do with a font.
# [20:59] <TabAtkins_> TabAtkins_: or in many cases, just ordinary javascript.
# [21:00] <TabAtkins_> dbaron: As an aside, I'm not crazy about the specific syntax being proposed, but I won't get into that now.
# [21:00] <TabAtkins_> stearns: I like this idea, but should the full-size-kana rule still be added, since it seems useful?
# [21:01] <TabAtkins_> jdaggett_: Given that the use-case is only for Ruby in japanese, and only for people who want to keep their original content that comes with small kana, I don't think we need to.
# [21:01] <TabAtkins_> szilles: A solution would be to use *this* transform as an example in the spec.
# [21:02] <TabAtkins_> fantasai: The table is non-trivial.
# [21:02] <TabAtkins_> fantasai: And the *idea* that you can ask the UA for this sort of thing is new and strange.
# [21:02] <TabAtkins_> fantasai: If it's tricky and unintuitive, nobody will do it though.
# [21:03] * Quits: fukuno (fukuno@63.145.238.4) (Ping timeout)
# [21:03] * Joins: arno (arno@63.145.238.4)
# [21:03] <TabAtkins_> jdaggett_: If there's an example, or a wiki article or something, it's a simple cut-and-paste to put it in your page.
# [21:04] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
# [21:04] <TabAtkins_> howcome: Or an @import. That works for fonts already.
# [21:04] * Joins: dsinger (dsinger@63.145.238.4)
# [21:04] <TabAtkins_> fantasai: They'll do that because it's shiny and new and cool.
# [21:04] * Joins: szilles (chatzilla@63.145.238.4)
# [21:05] <TabAtkins_> howcome: We're not fighting the functionality, just the syntax. And making it available to other languages.
# [21:05] <TabAtkins_> howcome: For example, in typesetting my Ibsen book, he used a peculiar form of punctuation. I had to edit a font to do that.
# [21:05] * tcelik notes it is now 13:00
# [21:06] <TabAtkins_> plinss: I hear many in favor, and one strong objection.
# [21:06] <TabAtkins_> [three strong objections]
# [21:07] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
# [21:07] <TabAtkins_> Bert: I think this is creeping transformations to CSS.
# [21:07] * Quits: kimberlyblessing (Kimberly@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111026191032])
# [21:07] <TabAtkins_> jdaggett_: Do you support the keyword itself?
# [21:07] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
# [21:07] * Quits: smfr (smfr@63.145.238.4) (Quit: smfr)
# [21:07] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
# [21:07] * Quits: duga (duga@63.145.238.4) (Quit: duga)
# [21:07] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
# [21:07] <TabAtkins_> Bert: You said it was necessary, so yes.
# [21:07] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
# [21:07] * Quits: shan (soonbo.han@63.145.238.4) (Quit: Leaving)
# [21:07] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
# [21:07] <TabAtkins_> <br type=lunch duration=1h>
# [21:07] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [21:07] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
# [21:08] * Quits: Cathy (qw3birc@128.30.52.28) (Ping timeout)
# [21:08] * Joins: myakura (myakura@63.145.238.4)
# [21:08] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Ping timeout)
# [21:09] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
# [21:09] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [21:09] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
# [21:09] * Quits: YUMA (yuma@63.145.238.4) (Ping timeout)
# [21:09] * Quits: kojiishi (kojiishi@63.145.238.4) (Ping timeout)
# [21:10] * Quits: florian (florianr@63.145.238.4) (Ping timeout)
# [21:10] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
# [21:16] * Quits: sylvaing (sylvaing@63.145.238.4) (Ping timeout)
# [21:17] * Quits: mihara (mihara@63.145.238.4) (Client exited)
# [21:21] * Joins: anne (annevk@63.145.238.4)
# [21:23] * Quits: alexmog (alexmog@63.145.238.4) (Ping timeout)
# [21:24] * Quits: howcome (howcome@63.145.238.4) (Ping timeout)
# [21:27] * Zakim excuses himself; his presence no longer seems to be needed
# [21:27] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [21:28] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
# [21:31] * Joins: tantek (tantek@63.145.238.4)
# [21:34] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# [21:37] * Joins: karl (karlcow@128.30.54.58)
# [21:37] * Quits: karl (karlcow@128.30.54.58) (Client exited)
# [21:38] * Joins: karl (karlcow@128.30.54.58)
# [21:40] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [21:41] * Joins: jdaggett_ (jdaggett@63.145.238.4)
# [21:43] * Joins: duga (duga@63.145.238.4)
# [21:44] * Joins: chsiao (chatzilla@63.145.238.4)
# [21:44] * Joins: ChrisL (ChrisL@128.30.52.169)
# [21:45] * Quits: duga (duga@63.145.238.4) (Quit: duga)
# [21:47] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
# [21:51] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
# [21:51] * Joins: smfr (smfr@63.145.238.4)
# [21:53] * Joins: stearns (anonymous@63.145.238.4)
# [21:57] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
# [21:58] * Joins: dsinger (dsinger@63.145.238.4)
# [21:59] * Joins: duga (duga@63.145.238.4)
# [21:59] * Joins: howard (howard_wan@63.145.238.4)
# [21:59] * Joins: bradk (bradk@63.145.238.4)
# [22:00] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
# [22:01] * Joins: szilles (chatzilla@63.145.238.4)
# [22:02] * Joins: sylvaing (sylvaing@63.145.238.4)
# [22:04] * Joins: plinss (plinss@63.145.238.4)
# [22:04] * Joins: glazou (glazou@63.145.238.4)
# [22:05] * Joins: arno (arno@63.145.238.4)
# [22:05] * Quits: chsiao (chatzilla@63.145.238.4) (Ping timeout)
# [22:07] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
# [22:07] * Joins: alexmog (alexmog@63.145.238.4)
# [22:07] * Joins: ChrisWilson (ChrisWilso@63.145.238.4)
# [22:07] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
# [22:07] * Joins: arronei_ (arronei@63.145.238.4)
# [22:07] * Joins: JohnJansen (JohnJansen@63.145.238.4)
# [22:08] * Joins: mihara (mihara@63.145.238.4)
# [22:08] * Joins: dbaron (dbaron@63.145.238.4)
# [22:09] * Joins: mmielke (mmielke@63.145.238.4)
# [22:09] * Joins: mollydotcom (mollyh@63.145.238.4)
# [22:09] * Quits: JohnJansen (JohnJansen@63.145.238.4) (Quit: JohnJansen)
# [22:10] * Joins: AnanKan (AnanKan@63.145.238.4)
# [22:10] <Bert> Scribe: Bert
# [22:10] * Joins: anne (annevk@63.145.238.4)
# [22:10] * glazou is here and as promised earlier, reads IRC and will comment here
# [22:10] * dbaron hmmm, the wireless from the AC meeting room is barely working
# [22:10] <Bert> Topic: Image Values
# [22:11] * Quits: mihara (mihara@63.145.238.4) (Client exited)
# [22:11] <Bert> [fantasai draws on whiteboard]
# [22:11] * Joins: dsinger (dsinger@63.145.238.4)
# [22:11] * Joins: szilles (chatzilla@63.145.238.4)
# [22:11] * Joins: shan (soonbo.han@63.145.238.4)
# [22:11] * Quits: arno (arno@63.145.238.4) (Ping timeout)
# [22:11] * Joins: Cathy (qw3birc@128.30.52.28)
# [22:11] * Joins: Rossen (Rossen@63.145.238.4)
# [22:11] <Bert> fantasai: Can somebody project the gradient syntax definition?
# [22:11] * Joins: cyril (chatzilla@63.145.238.4)
# [22:11] * Joins: mihara (mihara@63.145.238.4)
# [22:11] <szilles> join #ac
# [22:12] * Joins: kimberlyblessing (Kimberly@63.145.238.4)
# [22:12] * Joins: Kai (chatzilla@63.145.238.4)
# [22:12] * Quits: howard (howard_wan@63.145.238.4) (Quit: howard)
# [22:12] <fantasai> http://wiki.csswg.org/ideas/radial-gradients
# [22:12] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
# [22:13] * Rossen is now known as rossen
# [22:13] * Quits: ChrisWilson (ChrisWilso@63.145.238.4) (Quit: Leaving.)
# [22:13] <Bert> fantasai: Look at bottom of wiki page.
# [22:13] <Bert> ... Not clear what is going on in these examples.
# [22:13] <Bert> ... Some colors, som epercentages...
# [22:13] <Bert> ... So want all notations to be more obvious.
# [22:14] <Bert> ... Please look at the e-mail for some ideas.
# [22:14] * Joins: YUMA (yuma@63.145.238.4)
# [22:14] <Bert> ... Not ncecessary to have positional arguments in CSS.
# [22:15] <Bert> JohnD: Functional notation is usually interpreted as a function w/ params.
# [22:15] <Bert> ... This keyword notation is going away from that.
# [22:15] <Bert> Tab: Bu you can see it as going back more to how CSS properties work.
# [22:16] <Bert> JohnD: When I read a parentheseis, I expect a function.
# [22:16] <Bert> [Some people offering opiions]
# [22:17] * Joins: shepazu (shepazu@128.30.52.169)
# [22:17] <Bert> fantasai: Inside the func. notation it is pretty much like a value ntation.
# [22:17] <Bert> ... Not a function call, but a subset of the value.
# [22:17] <Bert> PeterL: We have other things without commas.
# [22:17] <Bert> Simon: But always commas in functions.
# [22:18] <Bert> Molly: Most people are not computer scientists.
# [22:18] <Bert> ... What is intuitive.
# [22:18] * Joins: fukuno (fukuno@63.145.238.4)
# [22:18] <Bert> ... The original proposals were completely unitutive.
# [22:18] <Bert> ... I have no context from CS. Peopel like me just need words.
# [22:19] <Bert> ... Gradient "from" here "to" there.
# [22:19] * Joins: dowan (forty4@63.145.238.4)
# [22:19] <Bert> JohnD: But look at AppleScript. It is frustrating.
# [22:19] * Joins: gilles (gilles@63.145.238.4)
# [22:19] <Bert> Tab: But isn't this the case for every proeprty?
# [22:19] <Bert> JohnD: It's different inside functional notaitons.
# [22:20] <Bert> Markus: Should avoid functional notation in general.
# [22:20] <Bert> Simon: How do you know [something]?
# [22:20] <Bert> Molly: It's the words, as long as it is logical.
# [22:20] <Bert> JohnD: Any kind of formal language needs to be consistent.
# [22:21] <Bert> ... In similar cases, you use similar notations.
# [22:21] <Bert> ... But this is mixing things together.
# [22:21] <Bert> ... Will lead to confusion.
# [22:21] <Bert> Brad: I think it rather clarifies.
# [22:21] <Bert> ... This is not AppleScript.
# [22:22] <Bert> fantasai: Looking at the exampels, I cankind of see what is going on.
# [22:22] <Bert> ... With the other ones, I have no idea.
# [22:22] <Bert> ... That's why I want to go here.
# [22:23] <Bert> ... Most functional notations we have so far, have commas in thesame way as in values without functional notations.
# [22:23] <Bert> JohnD: Do we have func. notations with keywords anywhere?
# [22:23] <Bert> Tab: We're adding that right now.
# [22:23] * Joins: arno (arno@63.145.238.4)
# [22:23] <Bert> ... Most functions sofar are pretty trivial.
# [22:24] <Bert> JohnD: So this is the first time for keywords in functional notations.
# [22:24] * Joins: brianman (brianman@131.107.0.110)
# [22:24] * Quits: gilles (gilles@63.145.238.4) (Client exited)
# [22:24] <brianman> helps to have the right port - 6665
# [22:24] <dbaron> I think keywords inside functional notation are reasonable.
# [22:24] <Bert> Simon: Slippery slope. But other way to think about it is name-value pairs.
# [22:25] * Joins: kojiishi (kojiishi@63.145.238.4)
# [22:25] <Bert> Howcome: OK with changing. We can also drop the just the parentheses here.
# [22:25] <brianman> There was a lot in e-mail. What's the current proposal?
# [22:25] <Bert> ... Programmers have traditions.
# [22:25] * Joins: JohnJansen (JohnJansen@63.145.238.4)
# [22:25] <Bert> ... We can do differently, as a string or something.
# [22:26] <Bert> PeterL: Cf Python and others.
# [22:26] <TabAtkins_> Like radial-gradient(center: 20% 20%, shape: cover ellipse, colors: blue, red, black)?
# [22:26] <Bert> JohnD: But they are specific syntaxes.
# [22:26] <Bert> PeterL: So is CSS.
# [22:26] <brianman> There's at least one problem with that syntax, Tab.
# [22:26] * glazou sees JSON percolate into CSS syntax ? :-)
# [22:26] <Bert> PeterL: The point is they are *not* parameters, because it is not a *function*.
# [22:27] <brianman> You probably want .... radial-gradient(center: 20% 20%, shape: cover ellipse, colors: |blue, red, black|) ... but something other than the pipe character.
# [22:27] * Joins: chsiao (chatzilla@63.145.238.4)
# [22:27] <dbaron> this is starting to look more like Apple's original proposal
# [22:27] * glazou waits for the curly braces proposal inside parenthesis
# [22:27] <Bert> fantasai: I hear objections to commas, because that makes it different from C. I dont' hear that my eample is unreadable.
# [22:27] <brianman> Your syntax above isn't clear on what the commas separate. Are they separating colors or the next param pair?
# [22:27] <Bert> JohnD: It's not C. It's consistency with other parts of CSS.
# [22:28] <brianman> Can you repeat your specific example, fantasai?
# [22:28] <Bert> fantasai: We dont' use commas between values in CSS.
# [22:28] <Bert> [For fantasai's idea, see e-mail linked earlier]
# [22:28] <brianman> [There are like 20 emails.]
# [22:28] <plinss> http://wiki.csswg.org/ideas/radial-gradients
# [22:29] <plinss> http://lists.w3.org/Archives/Public/www-style/2011Oct/0859.html
# [22:29] <Bert> Rossen: fantasai's is not necessarily easier.
# [22:29] * sylvaing glazou, Python functions also do that. It's a syntactical orgy over here!
# [22:29] <Bert> ... Functional syntax is hiding three gradient properties. Why do need to be in the notation, not in proeprties?
# [22:30] <brianman> Are you referring to this flavor: radial-gradient(<shape> keyword <position> keyword <stops) ?
# [22:30] <Bert> Tab: They are values, gradietns aren't properties.
# [22:30] <Bert> ... We don't add twenty-something properties for images.
# [22:30] <Bert> ... Can add @rule or point to SVG.
# [22:30] <Bert> ... But gradients are right at the edge, can still be in CSS, n a funtion.
# [22:30] * glazou sylvaing let's use reverse polish notation
# [22:31] <Bert> sylvaing: At some poijt we switch to SVG, you say. Then we need to inline SVG.
# [22:31] <Bert> ErikD: [missed]
# [22:31] * sylvaing glazou omg reverse-polish-calc() !
# [22:31] <Bert> ... Doesn't seem natural to me.
# [22:32] <Bert> Simon: Trabsforms has functional notations. But all numeric.
# [22:32] <bradk> rect() does not require commas: http://www.w3.org/TR/CSS2/visufx.html#value-def-shape
# [22:32] <dbaron> rect() is an accident from the examples and the normative prose in CSS 2.0 mismatching
# [22:32] <smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterFunction
# [22:32] <brianman> Why is "radial-gradient(circle from center as red, blue)" better than "radial-gradient(circle from center, red, blue)"? In my opinion it's worse.
# [22:33] <Bert> Tab: Filter functions shorthand in CSS looks like comma-separted now, but will change them to look more like CSS proeprty. Don't need th ecommas. Space is enough.
# [22:33] <Bert> Simon: Then we need to do that for trnasforms too, Consistency.
# [22:33] <ed> s/Doesn't seem natural to me./the "from ... as" syntax doesn't seem natural to me./
# [22:34] <Bert> Luke: Need More general syntax system than the English word thrown here and there.
# [22:34] <Bert> fantasai: Shorthand and indivisual propeties if needed.
# [22:34] <glazou> q+
# [22:34] * sylvaing image-values: spec(from almost-lc back-to endless, syntax, debate)
# [22:34] <Bert> Simon: @-rule, like keyframe [...]
# [22:34] * glazou has a comment
# [22:35] <Bert> ... Use JSON :-)
# [22:35] <plinss> ack glazou
# [22:35] <glazou> I would like to avoid "silent" tokens
# [22:35] <glazou> i.e. like in genetics, genes that express nothing
# [22:35] <glazou> if we could keep meaningful stuff only
# [22:35] * ed thinks JSON would make it easier to understand the syntax at first glance anyway
# [22:35] <glazou> please let's do that
# [22:36] <brianman> Clarify, glazou?
# [22:36] <glazou> in that light, from and as are meaningless
# [22:36] <brianman> Ah.
# [22:36] <glazou> they help readability by humans
# [22:36] <glazou> don't help the syntax
# [22:36] <brianman> I would agree on 'as' but 'from' has some value.
# [22:36] <Bert> Shane: Pretty strong relation to JSON idea. name:value idea.
# [22:36] <glazou> and also complexity parsing
# [22:36] <brianman> It solves the size version position problem with lengths.
# [22:36] <Bert> Florian: That's not what was proposed here.
# [22:37] <smfr> gradient(shape circle, from left, as red, green)
# [22:37] * Joins: Vlad (Vlad@63.145.238.4)
# [22:37] <brianman> Useless as in that version, smfr.
# [22:37] <smfr> gradient(shape circle from left as red, green)
# [22:37] <Bert> Shane: Those "silent" tokens exist in JSON, too.
# [22:37] <Bert> ... Slight difference in tokens.
# [22:38] <Bert> fantasai: Can vary order, although it looks weird with shape at the end.
# [22:38] <brianman> Sidenote: I think from is the wrong word. At is a better word.
# [22:38] <Bert> JohnD: Maye be readable, but allows syntaxes that are gibberish.
# [22:38] <brianman> In light of offset focal point in the future.
# [22:38] <Bert> PeterL: Gibberisgh is loaded term.
# [22:39] <fantasai> peterl: comma-separated numbers are gibberish to me if I'm not intimately familiar with the order of arguments
# [22:39] <Bert> Shane: Is it better if it were order-independent and we say we can use it in other situations, too?
# [22:39] <brianman> It can't be completely order independent. The color stops.
# [22:39] <Bert> JohnD: It's what an author expects.
# [22:40] <glazou> +1
# [22:40] <Bert> Molly: Solve deoendence on order with education.
# [22:40] <glazou> won't work
# [22:40] <Bert> ... And a question:
# [22:40] <Bert> ... What Simon just wrote is beutifule. What is the problem with it?
# [22:40] <Bert> Simon: Complex grouping, precendence issues...
# [22:41] <Bert> fantasai: Property values have this already.
# [22:41] <dbaron> The "shape" in what Simon wrote doesn't seem to me to add anything useful.
# [22:41] <Bert> howcome: Need to start with "from" right?
# [22:41] <brianman> @dbaron it has value here: radial-gradient(size 25px 25px, from 25px 25px, red, green)
# [22:42] <brianman> s/value/usefulness/
# [22:42] <Bert> Simon; CSS grammar doesn't restict what goes insoide (), does it?
# [22:42] <Bert> Bert: Correct.
# [22:42] <rossen> bert: didn't have time to look at the proposed syntax, would like to come back and comment in a week
# [22:42] <Bert> Florian: Should we allow ourselves the same flexibility inside () as for other values.
# [22:43] <dbaron> brianman, I was specifically referring to the "shape" rather than the other keywords
# [22:43] <Bert> howcome: Not more restrictive, just using more keywords, with may be more or less intuitive.
# [22:43] <Bert> fantasai: [missed]
# [22:43] <brianman> @dbaron - so you want "radial-gradient(circle...) and "radial-gradient(size 25px 25px, ...)" ... Meaning only a keyword in the size case?
# [22:44] <Bert> Tab: CSS is designed for English speakers.
# [22:44] <Bert> PeterL: No consensus?
# [22:44] <brianman> ... or are you saying that the from is clear enough that the other param doesn't need it?
# [22:44] <fantasai> fantasai^: gradients is a particularly tricky case because there are many arguments of the same type that need to be disambiguated
# [22:44] <TabAtkins_> A current example of using keywords in functional notation:
# [22:45] <TabAtkins_> file:///home/tabatkins/csswg/css3-lists/Overview.html#symbols-function
# [22:45] <Bert> Molly: Seems less to do with keywords, more to do with notation, i.e., the brackets.
# [22:45] * Joins: Frankie (Frankie@63.145.238.4)
# [22:45] <Bert> ... That means something for computer scientists.
# [22:45] <TabAtkins_> http://dev.w3.org/csswg/css3-lists/#symbols-function
# [22:45] <Bert> ... Simon's examples in IRC make sense to me.
# [22:45] <Bert> ... What is the pb with those?
# [22:45] <brianman> @Bert - Color stops problem.
# [22:46] <Bert> ... Is it the notation? The limitations?
# [22:46] <Bert> Simon: No consensus about needed the shape.
# [22:46] <Bert> ... We need to think about all the things that use func. notation.
# [22:46] <brianman> 1. The color stops are different from the shape/size/location params. 2. the color steps are a list.
# [22:46] <brianman> 2 - If you're trying to get order-variability support, you need to group the color stops
# [22:47] * Joins: lgombos (Laszlo@63.145.238.4)
# [22:47] <Bert> Florian: Values in general; some have just numbers, some have extra things to make it clearer. So far we didn't consider that inconstsient.
# [22:47] <brianman> 1 - I think of the color stops as a different thing than the params...just like for linear.
# [22:47] <Bert> ... Why do we think it is incosistent here?
# [22:47] * ed agrees with brianman
# [22:47] <Bert> PeterL: Transforms use a matric, that is a tradition, makes sense to people, no need to label it.
# [22:47] <Bert> ... What now?
# [22:47] <Bert> s/matic/matrix/
# [22:48] <Bert> Tab: Want to add a focal point later to gradients.
# [22:48] <Bert> ... More general discussion about notations later.
# [22:48] <brianman> For those that didn't read the e-mail, with one slight adjustment I could accept Elika's radial syntax.
# [22:48] <Bert> ... Let's settle on radial gradients now.
# [22:49] <Bert> Brad: linear gradiesnt have spaces.
# [22:49] <Bert> ... Spaces separate items in a list.
# [22:49] <fantasai> Brad: Linear gradients already has "to", already uses spaces to separate certain items, and uses commas in a way that's consistent with how we use them in other property values
# [22:49] <Bert> ... We are only putting () around them here.
# [22:49] <Bert> Tab: Poll on gradients, and general notation discussion later.
# [22:50] <brianman> Isn't tha the same as yesterday, Tab?
# [22:50] <Bert> Florian: Difficult to it in that order.
# [22:50] <brianman> (What's new in your poll.)
# [22:50] * Joins: jeff (Jeff@mcclure.w3.org)
# [22:50] <Bert> Tab: It slows down gradients. We know the features, we just discssu synatx forever.
# [22:50] * mollydotcom from Eric Meyer "I like gradient(shape circle, from left to bottom left, colors red, green)-makes sense, is very clear.
# [22:50] <Bert> .. Tjis is a minor issue.
# [22:50] <Bert> Shane: Let's get gradients out first.
# [22:51] <Bert> ... Schedule alternative syntaxes discussion.
# [22:51] <Bert> fantasai: That's terrible. Have to learn two syntaxes.
# [22:51] <brianman> @molly - sorry, your syntax confuses me terribly
# [22:51] <Bert> PeterL: Serialization issues too.
# [22:51] * Joins: howcome (howcome@63.145.238.4)
# [22:52] <brianman> ...the middle param
# [22:52] <Bert> sylvaing: Who would formally object to [???]
# [22:52] <fantasai> s/[???]/the current comma-separated syntax/
# [22:52] <brianman> the 09/08 WD you mean?
# [22:52] * Quits: dowan (forty4@63.145.238.4) (Quit: dowan)
# [22:52] <brianman> 2011/09/08
# [22:52] <Bert> PeterL: Value in readability and extensibility.
# [22:52] <fantasai> plinss: A fair question would be to ask would anyone formally object to publishing with this syntax?
# [22:53] * Quits: anne (annevk@63.145.238.4) (Quit: anne)
# [22:53] <fantasai> sylvaing: why should we change it?
# [22:53] <Bert> [two many talking at the same time]
# [22:53] <fantasai> plinss: I think it's a win for readability and understandability, and a big win for extensibility
# [22:53] <Bert> peterL: valuable to look at this and see if it blocks something later.
# [22:53] * Joins: tantek (tantek@63.145.238.4)
# [22:54] <Bert> howcome: What is the example?
# [22:54] <Bert> fantasai: Radial with offset center.
# [22:54] <dbaron> To be clear: I really don't like "shape circle", since "circle" is obviously a shape so "shape" is redundant -- unless we do something more explicitly property:value-like.
# [22:54] <Bert> Tab: circle at offset X X
# [22:54] <Bert> JohnD: At some point it gets easier to have an @-rule, as simon said.
# [22:55] <Bert> howcome: I think gradietns is already beyond readabilty.
# [22:55] <Bert> Tab; Why didn't you say that earlier?
# [22:55] <Bert> s/;/:/
# [22:55] <Bert> Tab: We settled on all this months ago.
# [22:55] <Bert> JohnD: But you also say you want to extend this.
# [22:55] <Bert> Tab: Yes, and at some point we say let's not extend any further.
# [22:56] <Bert> ... We can have that discussion in the future.
# [22:56] <Bert> ... But keep open possibility to extend in current syntax.
# [22:56] <Bert> PeterL: I want gradients done. Don't publish and change again.
# [22:56] <Bert> ... Let;s strawpoll.
# [22:56] <fantasai> Tab^: That was in the WebKit syntax, and I dropped it partly because I couldn't get a syntax that was reasonable with it.
# [22:57] <Bert> [preparing strawpoll, finding exampels to show on screen]
# [22:57] <JohnJansen> brianman, can you post what slight adjustment you need in order to accept Elika's syntax?
# [22:58] <brianman> sure
# [22:58] <TabAtkins_> Option A: radial-gradient(1em 2em, 3em 5em, red, orange, yellow)
# [22:58] <brianman> (i'll wait for tab)
# [22:58] <TabAtkins_> Option B: radial-gradient(3em 5em at 1em 2em as red, orange, yellow)
# [22:58] <TabAtkins_> Option c: radial-gradient(3em 5em at 1em 2em, red, orange, yellow)
# [22:58] <brianman> Yah, that about captures it
# [22:59] <bradk> B.2 radial-gradient(3em 5em at 1em 2em with red, orange, yellow)
# [22:59] <brianman> A=WD, I prefer A but I'm fine with C. I dislike B for at least two reasons.
# [22:59] <Bert> Tab: Second is Elika's
# [22:59] <Bert> ... 3rd is a variant, with "," instead of as
# [23:00] <Bert> Luke: Option missing is to name the first params.
# [23:00] <Bert> Florian: Not sure this is the right set of options for the poll.
# [23:00] <Bert> ... Need to eliminate.
# [23:00] <Bert> Tab: Can give multiple votes, to all the ones you like.
# [23:01] <shans> D. radial-gradient(shape 3em 5em at 1em 2em as red, orange, yellow)
# [23:01] * ed prefers option A)
# [23:02] * Quits: fukuno (fukuno@63.145.238.4) (Ping timeout)
# [23:02] * cyril prefers option A) too, and notes that compared to SVG it's missing the focal point position and compared to canvas it's missing the inner circle size
# [23:02] <brianman> @cyril - correct on SVG, canvas
# [23:02] <Bert> Bert: [question about ems in the notation]
# [23:03] <Bert> JohnJ: A
# [23:03] <Bert> howcome: Where is the "from" keyword that elika propsoed?
# [23:03] <brianman> good point
# [23:03] <fantasai> plinss: The word is unimportant, the concept is what we're voting on
# [23:03] <Bert> PeterL: The exact word is not inmportant.
# [23:03] <dbaron> how does the ellipse/circle closest-side/closest-corner/farthest-side/farthest-corner fit into this?
# [23:04] <fantasai> part of <shape>
# [23:04] <TabAtkins_> dbaron: First argument is <shape>, which includes that.
# [23:04] <Bert> PeterL B, then c then A
# [23:04] <brianman> replace "3em 5em" with the shape keyword
# [23:04] <brianman> in all the options
# [23:04] <brianman> the <shape> keywords rather
# [23:04] <Bert> s/peterL/PeterL:/
# [23:04] <Bert> howcom: a
# [23:04] <Bert> koji: A
# [23:04] <Bert> markus: a
# [23:05] <Bert> Alan: b, c
# [23:05] <Bert> soonbo: a
# [23:05] <Bert> florian: b, c, a
# [23:05] <dbaron> (I saw that as both a shape and a size, but oh well...)
# [23:05] <Bert> bert: abstain
# [23:05] <Bert> masa: abstain
# [23:05] <Bert> EricM: b
# [23:05] <bradk> Brad: C, then B
# [23:05] <Bert> brad: c, b
# [23:05] <brianman> [After the poll I'd like to address dbaron's question.]
# [23:06] <Bert> simon: a, d
# [23:06] <Bert> alex: abstain
# [23:06] <Bert> kimberley: abstain
# [23:06] <Bert> rossen: a, c
# [23:06] <TabAtkins_> (Yes, "radial-gradient(ellipse at top left, red, blue)" is fine.)
# [23:06] <Bert> sylvaing: a
# [23:06] <Bert> johnD: a c
# [23:06] <Bert> arron: b, a
# [23:06] <Bert> tab: b, c
# [23:07] <Bert> shane: b, c
# [23:07] * ed AC/DC anyone?
# [23:07] <Bert> kimberlyblessing: a
# [23:07] <glazou> abstain
# [23:07] <Bert> fantasai: b, c
# [23:07] <Bert> luke: a, d
# [23:07] * Joins: anne (annevk@63.145.238.4)
# [23:08] <fantasai> plinss: If you group b+c as one camp and a as a second, it's a dead tie
# [23:08] <Bert> PeterL: This isn't showing us anything.
# [23:08] <dbaron> my prefs are d with the b->c substitution, c, a, if I'm understanding correctly
# [23:08] <Bert> fantasai: Open up to designers on wiki.
# [23:09] <Bert> Tab: resolve in two weeks?
# [23:09] <brianman> Resolve how?
# [23:09] <fantasai> on csswg blog
# [23:09] <brianman> ah.
# [23:09] <Bert> ACTION fantasai: make post with the options, just two options.
# [23:09] * trackbot noticed an ACTION. Trying to create it.
# [23:09] * RRSAgent records action 17
# [23:09] <trackbot> Created ACTION-397 - Make post with the options, just two options. [on Elika Etemad - due 2011-11-08].
# [23:10] <brianman> The "2" in that action is troubling.
# [23:10] <brianman> Either you choose to screw B or C.
# [23:10] <Bert> [discussion about @-rule]
# [23:10] * sylvaing next: whether to use tabs or spaces
# [23:10] <Bert> RESOLVED: decide in two weeks.
# [23:10] * glazou I want to use only one Tab, thanks
# [23:11] * Ms2ger one Tab, and spaces for indentation?
# [23:11] <glazou> :)
# [23:11] <Bert> [agenda discussion]
# [23:12] * dbaron wonders when CSSWG is doing its break
# [23:12] * dbaron could come back now or in a little bti
# [23:12] <plinss> 10 mins
# [23:12] <plinss> pf joint meeting at 3:30
# [23:12] <Bert> Topic: Variables
# [23:12] <glazou> plinss: and variables ?
# [23:12] <glazou> ah ok
# [23:12] <Bert> Tab: We talked about it in Seattle. I revised things since.
# [23:12] <JohnJansen> dbaron, we're going to power through a bit of variables first, then do the joint meeting. short break before joint meeting
# [23:13] <Bert> ... Let's go over it.
# [23:13] <Bert> ... Variables were @-rules before.
# [23:13] <Bert> ... That has scoping problems, etc.
# [23:13] <Bert> ... So new idea is to define data-* properties.
# [23:14] <Bert> ... Can be any name after data-. Need to define the syntax exactly.
# [23:14] <Bert> ... Later.
# [23:14] <Bert> ... They have arbitrary name and arbitrary value.
# [23:14] <Bert> .. Attaches these proeprties to an element.
# [23:14] <Bert> ... Follows cascade, inheritance, exactly like every othe rproperty.
# [23:14] <Bert> Markus: So always inherited?
# [23:15] <Bert> Tab: Yes, always inherited.
# [23:15] <Bert> ... A data- property doens't do anything by itelf.
# [23:15] <Bert> ... But you can use them by referring to them.
# [23:15] <Bert> ... Example 1:
# [23:16] <Bert> ... Sets data-border-color on :root.
# [23:16] <Bert> ... Inherits to everything.
# [23:16] <Bert> ... An H1 later on has this property.
# [23:16] <Bert> ... Can refer to is: background: data(border-color)
# [23:16] <Bert> .. Example 2:
# [23:16] <Bert> s/.. /.../
# [23:17] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
# [23:17] <Bert> ... Easier to understand, at least when you understand cascade and inheritance. :-)
# [23:17] <Bert> ... Libraries can declare their own variables.
# [23:18] <glazou> q+
# [23:18] <Bert> ... With this system you just set it on the root, and won't interfere.
# [23:18] * Joins: arno (arno@63.145.238.4)
# [23:19] <Bert> JohnD: name collision?
# [23:19] <Bert> Tab: Still possible , but addresses the majority of them.
# [23:19] <Bert> JohnD: So each of these data-* are in the cascade and visible to any element.
# [23:19] * glazou is on the queue
# [23:19] <Bert> dbaron: Yes, all inherited.
# [23:19] * Joins: gilles (gilles@63.145.238.4)
# [23:20] <Bert> JohnD: So if you set then inside a class...
# [23:20] * Joins: howard (howard_wan@63.145.238.4)
# [23:20] <Bert> Tab: Then nothing outside that class they are not there, that's inheritance.
# [23:20] * Quits: Frankie (Frankie@63.145.238.4) (Quit: Frankie)
# [23:20] <Bert> dbaron: Some library that deals with a subtree.
# [23:20] <Bert> Tab: Such as widgets.
# [23:20] <Bert> dbaron: Tehre are other kinds of libraries.
# [23:21] <Bert> johnd: You say it resolves na,me collisions, but it simplifes, eliminates global scopes.
# [23:21] <Bert> PeterL: Not eliminated problem, bur reduced.
# [23:21] <Bert> howcome: when do you know a value is invalid?
# [23:21] <glazou> so I think this is clearly the cleanest and best CSS-integrated variables proposal since 1998 ; it's easy to understand, easy to edit, fast and easy to deploy from a web site point of view ; love it
# [23:21] <Bert> Tab: At computed value time.
# [23:22] <Bert> ... Say it recolves to color: foo
# [23:22] <Bert> ... At that point it is not a valid value, and the initial value will be used. Not the previous rule.
# [23:22] <glazou> q-
# [23:22] <Bert> fantasai: memeroy usage?
# [23:23] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
# [23:23] <Bert> Tab: Shane tried and said it was no so bad.
# [23:23] <Bert> [break]
# [23:23] * Quits: duga (duga@63.145.238.4) (Quit: duga)
# [23:23] <Bert> s/memeroy/memory/
# [23:23] * Quits: bradk (bradk@63.145.238.4) (Quit: Computer has gone to sleep)
# [23:23] <glazou> so no resolution here ?
# [23:23] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
# [23:23] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
# [23:24] <Bert> rrsagent, make minutes
# [23:24] <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/31-css-minutes.html Bert
# [23:24] <glazou> Bert: no resolution to publish variables ?
# [23:25] * Bert : we continue later.
# [23:25] <glazou> ok
# [23:25] * Bert first the joint meeting with PF
# [23:26] <glazou> thks Bert
# [23:32] * Joins: dbaron (dbaron@63.145.238.4)
# [23:33] * Joins: Mike5 (Mike5@mcclure.w3.org)
# [23:34] * myakura wonders why the minutes is dated as 31st.
# [23:34] * Quits: mihara (mihara@63.145.238.4) (Client exited)
# [23:36] * Quits: glazou (glazou@63.145.238.4) (Quit: glazou)
# [23:37] <Ms2ger> Meeting: CSSWG f2f meeting at TPAC
# [23:37] * Joins: mihara (mihara@63.145.238.4)
# [23:37] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
# [23:38] * Joins: florian (florianr@63.145.238.4)
# [23:38] * mollydotcom stepping outside it's too hot, if you need me I'll follow on IRC
# [23:38] <Bert> Topic: PF - CSS joint meeting
# [23:38] * Quits: mollydotcom (mollyh@63.145.238.4) (Client exited)
# [23:38] <Bert> Janina: We appreciate your time.
# [23:38] * Joins: vhardy (vhardy@192.150.10.200)
# [23:39] * Joins: duga (duga@63.145.238.4)
# [23:39] <Bert> ... We haven't talked to you as often as we should. Been busy with HTML5 and other things.
# [23:39] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
# [23:39] * Joins: jamesn (jamesn@63.145.238.4)
# [23:39] <Bert> ... We have a task to look at other groups' work.
# [23:39] <Bert> ... We have been trying to make up for lost time in CSS.
# [23:39] <Bert> ... Created a wiki with CSS modukes.
# [23:40] <Bert> ... Checked 50-60% so far
# [23:40] <Bert> ... Several issues, of diff. types.
# [23:40] * Joins: MichaelC (Michael@128.30.52.169)
# [23:40] <Bert> ... Soem can be done in e-mail.
# [23:40] <Bert> ... Shoild get started on the overarching issues.
# [23:40] <Bert> ... Some might involve others than just CSS and PF.
# [23:41] <Bert> ... CSS is importan to accessibility.
# [23:41] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:41] <Bert> ... CSS should be an accessibility success story.
# [23:41] * Joins: dbaron (dbaron@63.145.238.4)
# [23:41] <Bert> ... Haveong looked at the modules,
# [23:41] <Bert> ... (can we project them?)
# [23:42] <Bert> ... We should start to understand CSS 3.
# [23:42] <Bert> ... An overview would be useful.
# [23:42] <Bert> ... Michael will have a list in a second.
# [23:42] <dbaron> should we mention the snapshot?
# [23:42] <Bert> ... We're concerned about reflowing content.
# [23:43] <MichaelC> -> http://www.w3.org/WAI/PF/wiki/CSS/Spec_Review/Discussion PFWG Discussion notes on CSS accessibility
# [23:43] <Bert> ... Not a bad idea, but may negatively impact the reading order, with braille and screen readers, may affect tab order.
# [23:43] <Bert> ... May need a solution.
# [23:43] <Bert> ... We should be able to influence the reading order.
# [23:43] <Bert> PeterL: Maybe not thinking about the same terms with the same meaning.
# [23:44] <Bert> dbaron: Can you give what you think it means?
# [23:44] <Bert> SandyShelly: Concern is , let';take an example:
# [23:44] <Bert> ... flexbox
# [23:44] <Bert> ... taborder still follows source order, but screen order is different.
# [23:44] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
# [23:44] * Joins: fukuno (fukuno@63.145.238.4)
# [23:45] <Bert> ... Several places in CSS do that.
# [23:45] <Bert> ... ARIA and script can help.
# [23:45] <Bert> ... But is at differnet lvel, in HTML.
# [23:45] <Bert> dbaron: Authors who want to use different orders for some reasons,
# [23:45] <myakura> s/SandyShelly/Cynthia Shelly/
# [23:45] <Bert> ... do that intentionally.
# [23:46] <Bert> Cynthia: that breaks it for sighted users.
# [23:46] <Bert> Tab: reflow is very useful for repairing source order.
# [23:46] * Quits: jeff (Jeff@mcclure.w3.org) (Ping timeout)
# [23:46] <Bert> cynthia: Yes, good use cases, but
# [23:47] <Bert> ... some use cases not thought through, especially sighted keyboard users.
# [23:47] * Quits: howard (howard_wan@63.145.238.4) (Quit: howard)
# [23:47] <Bert> ... (who can't use a mouse)
# [23:47] <Bert> Alex: Semantic order and visual order.
# [23:47] <Bert> ... If we believe the semantic order is the right order, then follow that, otherwise follow th visual order.
# [23:48] <Bert> cynthia: Focussable elements inside that, eand keeping keyboard and scren in sync. is problematic.
# [23:48] * Joins: bradk (bradk@63.145.238.4)
# [23:48] <Bert> ... May need some things in CSS to change the tab order or flow. Rather in CSS than HTML.
# [23:48] <Bert> JamesCraig: Related properties that we wanted an explanation of: nac-index, nav-right...
# [23:48] <fantasai> http://www.w3.org/TR/css3-ui/#nav-index
# [23:49] <fantasai> http://www.w3.org/TR/css3-ui/#nav-dir
# [23:49] <Bert> Tab: Editor is Tantek, but nor here now.
# [23:49] <Bert> Florian: Semantic order and visual order both are meaningful. One is not right or wrong.
# [23:49] <Bert> ... May need to tab throught source order *and* through visual order.
# [23:50] <Bert> Cynthis: Application dependent. let user choose.
# [23:50] <Bert> Tab: Rearranging focussable things...
# [23:50] * Joins: jun_ (qw3birc@128.30.52.28)
# [23:50] <Bert> ... At leats blocks of things rearranged with media queries.
# [23:50] <Bert> Janina: Author must indeed be able to rearrnge layout.
# [23:51] <Bert> ... But some users may need to consume it differently.
# [23:51] <Bert> markus: A media-query-driven tab-order.
# [23:51] <Bert> Janina: Perjhaps. We don't have a slution.
# [23:51] * Joins: hiroki (h_yamada@128.30.52.28)
# [23:51] <Bert> cynthia: main req. is that it is in CSS layer, not HTML.
# [23:51] <Bert> s/req./requirement/
# [23:52] <Bert> fnatasi: Isn't that the nav-index property.
# [23:52] <Bert> Tab: The existing property is not quite right. We have been working on similar things. This is less useful as it can be.
# [23:53] <Bert> ... So we can do some work on it.
# [23:53] <Bert> s/fnatasi/fantasai/
# [23:54] <Bert> michael: a question on priorities of CSS specs.
# [23:54] <Bert> JohnD: yes we like to know that too :-)
# [23:54] <Bert> tab: They can easily end up reordered.
# [23:54] <dbaron> should also note that http://www.w3.org/TR/CSS/ gives an overview of the stable stuff
# [23:54] <Bert> fantasai: there is no good answer to that.
# [23:54] <Bert> MichaelC: So we prioritize our own time on the reviews.
# [23:55] <Bert> fantasai: specs that head to LC vs other specs.
# [23:55] * Ms2ger notes obsolescence notices
# [23:55] <Bert> ... We can break doewn in to 3 categories od stability.
# [23:55] <Bert> ... I have been writing that up in a blog
# [23:56] <Bert> ACTION fantasai update current work page with more granularity by stability rather than priority.
# [23:56] * trackbot noticed an ACTION. Trying to create it.
# [23:56] <trackbot> Created ACTION-398 - Update current work page with more granularity by stability rather than priority. [on Elika Etemad - due 2011-11-08].
# [23:56] * Quits: arno (arno@63.145.238.4) (Quit: Leaving.)
# [23:56] <Bert> MichaelC: User style sheets:
# [23:56] <Bert> ... User can override author, but
# [23:57] <Bert> ... if author uses an inaccessible design,
# [23:57] <Bert> ... it is not so feasible to override it.
# [23:57] <Bert> janina: is there some way to make those overrides more accessible.
# [23:57] <Bert> ... be more pro-active.
# [23:57] <Bert> Tab: I expect W3C cannot do much.
# [23:57] <Bert> ... isa UA issue.
# [23:58] <Bert> ... Browsers should do it better. Not standardization issue.
# [23:58] <Bert> MichaelC: style sheets keyed off of class etc. So difficult to override.
# [23:58] <Bert> fantasai: We are working on consitional rules.
# [23:58] <Bert> .. Designate a block for a particular URL or domain.
# [23:58] <Bert> s/../.../
# [23:59] <Bert> howcome: can even put all those in a single file.
# [23:59] <Bert> ... the file may be huge, though.
# [23:59] <Bert> Tab: Accessibility related issues for user style sheets, sites that share those.
# [23:59] <Bert> howcome: we can disable floats, go black&whiet, in Opera, e.g.
# Session Close: Wed Nov 02 00:00:00 2011

The end :)