/irc-logs / w3c / #css / 2012-05-11 / end

Options:

# Session Start: Fri May 11 00:00:01 2012
# Session Ident: #css
# [00:00] * Quits: danielfilho (danielfilh@187.31.77.7) (Quit: </html>)
# [00:03] * Quits: nimbu (Adium@192.150.10.200) (Quit: Leaving.)
# [00:08] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [00:10] * Joins: dstorey (Adium@144.189.101.1)
# [00:18] * Joins: nimbu (Adium@192.150.10.200)
# [00:23] * Quits: nimbu (Adium@192.150.10.200) (Quit: Leaving.)
# [00:40] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [00:41] * Joins: dstorey (Adium@144.189.101.1)
# [00:41] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [00:42] * Joins: dstorey (Adium@144.189.101.1)
# [00:42] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [00:45] * Joins: dstorey (Adium@144.189.101.1)
# [00:57] * Joins: arronei_ (Arron@24.17.123.244)
# [01:17] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [01:18] * Joins: dstorey (Adium@144.189.101.1)
# [01:20] * Quits: glenn (gadams@88.71.76.2) (Client exited)
# [01:50] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [02:03] * Joins: arronei_ (Arron@24.17.123.244)
# [02:25] * Quits: tantek (tantek@50.1.62.23) (Quit: tantek)
# [03:14] * Quits: isherman (Adium@216.239.45.4) (Quit: Leaving.)
# [03:14] * Joins: isherman (Adium@216.239.45.4)
# [03:18] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [03:23] * Joins: nimbu (Adium@67.169.39.98)
# [03:35] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [03:58] * Quits: nimbu (Adium@67.169.39.98) (Quit: Leaving.)
# [04:03] * Joins: nimbu (Adium@67.169.39.98)
# [04:05] * Joins: krit (krit@88.71.76.2)
# [04:18] * Joins: dstorey (Adium@67.180.84.179)
# [04:41] * Quits: krit (krit@88.71.76.2) (Quit: Leaving.)
# [04:50] * Joins: myakura (myakura@221.171.5.98)
# [05:26] * Joins: krit (krit@88.71.76.2)
# [06:22] * Joins: tantek (tantek@173.228.80.252)
# [06:27] * Joins: arronei_ (Arron@24.17.123.244)
# [06:27] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [06:42] * Joins: vhardy_ (vhardy@88.71.76.2)
# [06:53] * Joins: glenn (gadams@88.71.76.2)
# [07:05] * Joins: jet (jet@217.5.145.235)
# [07:10] * Quits: myakura (myakura@221.171.5.98) (Client exited)
# [07:11] * Quits: tantek (tantek@173.228.80.252) (Quit: tantek)
# [07:20] * Joins: alexmog_ (qw3birc@128.30.52.28)
# [07:21] * Quits: vhardy_ (vhardy@88.71.76.2) (Quit: vhardy_)
# [07:27] * Joins: shanestephens (shanesteph@85.183.206.243)
# [07:27] * Quits: glenn (gadams@88.71.76.2) (Client exited)
# [07:36] * Quits: krit (krit@88.71.76.2) (Quit: Leaving.)
# [07:36] * Joins: myakura (myakura@221.171.5.98)
# [07:59] * Quits: jet (jet@217.5.145.235) (Quit: jet)
# [08:01] * Joins: tantek (tantek@66.87.4.208)
# [08:03] * Joins: jet (jet@217.5.145.235)
# [08:09] * Quits: shanestephens (shanesteph@85.183.206.243) (Ping timeout)
# [08:09] * Quits: jet (jet@217.5.145.235) (Quit: jet)
# [08:15] * Quits: nimbu (Adium@67.169.39.98) (Quit: Leaving.)
# [08:18] * Quits: tantek (tantek@66.87.4.208) (Quit: tantek)
# [08:20] * Joins: tantek (tantek@66.87.4.208)
# [08:20] * Quits: tantek (tantek@66.87.4.208) (Quit: tantek)
# [08:21] * Quits: macpherson (macpherson@74.125.56.17) (Quit: macpherson)
# [08:56] * Joins: alexmog__ (qw3birc@128.30.52.28)
# [08:56] * plinss_away is now known as plinss
# [08:57] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
# [09:01] * Joins: vhardy_ (vhardy@193.105.139.140)
# [09:03] * Joins: glenn (gadams@193.105.139.140)
# [09:04] * Joins: dbaron (dbaron@193.105.139.140)
# [09:08] * Joins: shanestephens (shanesteph@193.105.139.140)
# [09:08] * Joins: krit (krit@192.150.10.201)
# [09:08] * Joins: Liam (liam@128.30.52.169)
# [09:13] * Joins: glazou (glazou@193.105.139.140)
# [09:14] <glazou> RRSAgent, make logs public
# [09:14] <RRSAgent> I have made the request, glazou
# [09:14] * sylvaing_away is now known as sylvaing
# [09:14] * Joins: AlexD (qw3birc@128.30.52.28)
# [09:15] <Bert> Scribe: Bert
# [09:15] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:15] <Bert> Topic: Regions
# [09:15] <plinss> zakim, room for 5?
# [09:15] <Zakim> ok, plinss; conference Team_(css)07:07Z scheduled with code 26631 (CONF1) for 60 minutes until 0807Z
# [09:15] <Bert> [Vincent sets up a telcon]
# [09:15] <Zakim> Team_(css)07:07Z has now started
# [09:16] * Joins: jet (jet@193.105.139.140)
# [09:16] <Zakim> + +49.403.063.68.aaaa
# [09:16] <plinss> zakim, aaaa is Meeting_Room
# [09:16] <Zakim> +Meeting_Room; got it
# [09:17] <Bert> [Alan prepares to project]
# [09:17] * Joins: tantek (tantek@50.1.62.23)
# [09:18] <Bert> Alan: box generation... regions vs elements... floats...
# [09:18] <Bert> ... will take max. until 11:00
# [09:18] <Bert> ... Some real-world examples from magazines.
# [09:19] <Bert> ... We're starting to formulate proposals for them.
# [09:19] * Joins: howcome (howcome@193.105.139.140)
# [09:19] <sylvaing> http://wiki.csswg.org/spec/css3-regions/regions-print-use-cases
# [09:19] <Bert> ... About box generation:
# [09:19] <vhardy_> http://wiki.csswg.org/spec/css3-regions/regions-print-use-cases
# [09:19] <Bert> ... 3 ways (at least):
# [09:19] <vhardy_> http://wiki.csswg.org/ideas/css3-exclusions-print-use-cases
# [09:19] <Bert> ... pseudos, page templates, overflow-repeat.
# [09:19] <Bert> ... We probably want all of them, at different times.
# [09:19] <alexmog__> have agenda? is there a reason for me to call in?
# [09:20] <vhardy_> alex: we are talking about regions, exclusions and box generation, good time for you to join :-)
# [09:20] <Bert> ... (Don't read the text on the screen, just the images.)
# [09:20] * Liam zakim, who is on the phone?
# [09:20] * Zakim sees on the phone: Meeting_Room
# [09:20] <tantek> is text-size-adjust on the agenda for today?
# [09:20] <Bert> ... Wired magazine example, floats, side article.
# [09:21] <tantek> Zakim, tantek is in the meeting.
# [09:21] <Zakim> I don't understand 'tantek is in the meeting', tantek
# [09:21] <Bert> ... Blurbs in the gutter or along the side.
# [09:21] <Bert> ... on a page-to-page basis these are generated, until the text runs out.
# [09:21] <Zakim> + +1.206.923.aabb
# [09:21] <Bert> ... Can do that with page templates that creat eregions.
# [09:21] <alexmog__> zakim, aabb is me
# [09:21] <Zakim> +alexmog__; got it
# [09:22] * Joins: SteveZ (chatzilla@193.105.139.140)
# [09:22] <Bert> ... Uses @template with @slots inside to define the slots.
# [09:22] <Bert> ... And then flow-from to assign named flows.
# [09:23] <Bert> ... Generates pages until the content runs out.
# [09:23] <Bert> howcome: This is paged mode? What determines that this is paged?
# [09:23] <Bert> Alan: It uses 'overflow-style: paged-x'
# [09:23] <Bert> ... Syntax of templates not really that important to me.
# [09:23] <Bert> ... Might need a "shadow DOM."
# [09:24] <Bert> ... Important is the use case.
# [09:24] * Joins: arno (arno@193.105.139.140)
# [09:24] <Bert> ... We just need a page template mechanism.
# [09:24] <Bert> howcome: It looks like @page, why call it @template?
# [09:24] <glenn> http://people.apache.org/~gadams/images/justonemore.jpg
# [09:25] <Bert> alan: @template in this example only applies to the content box of @page.
# [09:25] <vhardy_> http://dev.w3.org/csswg/css3-page-template/
# [09:25] <Bert> howcome: @page has already margin boxes, which are similar to this @template in genratting regions.
# [09:25] <Bert> Alan: I'm open to different syntaxes.
# [09:26] <Bert> ... This is one way, and it is a way without needing mark-up.
# [09:26] <Bert> howcome: Good start, it takes pages seriously, it uses CSS instead of XML. And good that you implemented it.
# [09:26] <Bert> Vincent: it's a shim, a prototype in JS.
# [09:27] <Bert> [several]: that is reasonable.
# [09:27] <Bert> Glenn: Is flow-from & flow-into necessary? Seems redundant.
# [09:27] <Bert> Alan: That's a syntax form Regions. There are ways without.
# [09:28] <Bert> ... Could use a syntax with 'overflow-style' as well.
# [09:28] <Bert> ... Without a 'flow-from', it gets the default content.
# [09:29] <Bert> ... And those regions are chained.
# [09:29] <Bert> howcome: is the order well-defined? What about @imports?
# [09:29] <Bert> Vincent: That's good point and we haven't gone through all the cases.
# [09:29] <Bert> Alan: Another thing is making sure that all the content is indeed displayed.
# [09:30] <Bert> ... This is just the general idea, one possible way.
# [09:30] <Bert> Vicnent: We'll get back to this later in the discussions.
# [09:30] <Bert> Alan: We should have a general mech. for deailing with overflow by generating a new box.
# [09:31] <Bert> howcome: Auto-generation.
# [09:31] <Bert> Alan: Yes, by means of a repeat.
# [09:31] <Bert> ... Any box couyld have a overflow style of repeat and it will duplicate.
# [09:32] <Bert> glazou: And you can style those bxoes individually? Idea from Dreamweaver.
# [09:32] <Bert> Alan: Works well with multicol, in continuous media adds more columns.
# [09:33] <Bert> ... Would like to use this in general for regions.
# [09:33] <Bert> howcome: It was rejected when I proposed that many years ago.
# [09:33] <Bert> Vincent: it is useful not just with multicol.
# [09:34] <howcome> http://lists.w3.org/Archives/Public/www-style/2008Oct/0148.html
# [09:34] <howcome> http://www.w3.org/2008/10/20-css-irc.html
# [09:34] <Bert> [Florian gives demo of a repeating block mock-up]
# [09:35] <Bert> Florian: Multicol in a fixed height, and then the repeat creates a new box with columns *below* the first.
# [09:35] <Bert> ... It is not part of multicol, it is independent.
# [09:36] * Joins: jdaggett (jdaggett@193.105.139.140)
# [09:36] <Bert> howcome: You have to position those boxes and the scrollbar of the window will not match the height of the boxes.
# [09:36] <Bert> florian: vh and overflow-style: paged
# [09:36] <Bert> Alan: The repeating boxes give the reader some context.
# [09:37] <Bert> howcome: [scrolls down the example to see four columns all cut off at the screen edge]
# [09:38] <Bert> florian: With pseudos you can style the nth copy of the box.
# [09:38] <Bert> ... Warning: my example is fake, the style rules don't really work!
# [09:39] <Bert> ... It is also backward-compatible, because the styling of the copies is inside a pseudo that old UAs don't know.
# [09:40] <fantasai> #mail::nth-copy(n) { overflow-style: repeat; height: 12em; }
# [09:40] <fantasai> #mail::nth-copy(even) { backgrond: #ddd; }
# [09:40] <Bert> ... 'nth-copy(n)' means all copies, 'nth-copy(1)' means a specific copy.
# [09:40] <fantasai> #main::nth-copy(3) { /* more special styling */ }
# [09:40] <Bert> dbaron: So you have to evaluate the pseudo for all elements to see if you have a match?
# [09:41] <Bert> florian: I was looking for something that was backward compatible.
# [09:41] <glenn> s/#mail/#main/g
# [09:41] <Bert> glazou: To answer dbaron: no, you don't have to. It is for graceful fallback. You can *also* set the style on the elts themselves.
# [09:42] <Bert> fantasai: But you need it if you only ant the last one to scroll, e.g.
# [09:42] <dbaron> I'd rather overflow-style:repeat not be able to come from :nth-copy(1), which requires we look at it for every element
# [09:42] <Bert> florian: Let's argue the details later.
# [09:43] <Bert> ... But diff. copies can be of different kind; it's as flexible as regions, probably.
# [09:43] <Bert> ... each copy is a region with its own style.
# [09:43] <Bert> ... Can do a lot, and is compatible with regions.
# [09:44] <Bert> plinss: It seems to colve a lot of use cases for regions, but it does not mean we do not need regions.
# [09:44] <Bert> Alan: We can discuss the different solutions on the mailing list.
# [09:44] <Bert> plinss: This *should* not address the same problems.
# [09:45] <Bert> ... I don't like us to go down that path.
# [09:45] <Bert> ... A new feature is fine, but that does not mean we don't mean the other feature.
# [09:46] <Bert> howcome/florian: We didn't say it replaces regions.
# [09:46] <Bert> Alan: We want to explore this. It may not replace all use cases for regions.
# [09:46] <Bert> ... Back to ways to generate regions: let's look at pseudos.
# [09:47] <Bert> ... Generating pseudos, incl. in the DOM. I think we want that.
# [09:47] <Bert> ... We can use regions with all those box generations.
# [09:47] <Bert> ... Would like to get Regions draft to the point that it uses all those, and not need the empty DIVs.
# [09:48] <Bert> howcome: Great plan!
# [09:48] <Bert> Alan: Regions is interesting in that is works with all these things. Repeating boxes is, too, becaus eit is compatible with it.
# [09:48] <dbaron> ::nth-copy() seems just like ::region() in http://dev.w3.org/csswg/css3-gcpm/#regions (and I think I might prefer the ::region() name)
# [09:48] <Bert> ... We have an issue on the Regions spec that says we cannot use elements.
# [09:49] <Bert> ... I don't want to disallow that.
# [09:49] <Bert> howcome: if you can do it withut elements, why do you still want to abuse elements.
# [09:49] <Bert> sylvaing: Want to use elements for programmatic access.
# [09:50] <Bert> vincent: There are two other issues, let's look at those first.
# [09:50] <Bert> ... How do we work on them?
# [09:51] <Bert> ... Want a reslotion where to put things like reprtion and other box generation mechanisms.
# [09:51] <Bert> ... Add it now? Possibly SPlit it later?
# [09:51] * Joins: kojiishi (kojiishi@193.105.139.140)
# [09:51] <Bert> florian: Independently useful, so maybe develop at diff. speed.
# [09:51] <Bert> fantasai: Seems to need regions to position.
# [09:52] <Bert> florian: yes, but also useful without positioning.
# [09:52] <dbaron> It's not clear to me why positioning and floating depends on regions.
# [09:52] <Bert> ... And we can do it fatser than full regions.
# [09:52] <Bert> howcome: That makes sense, even if we have too many specs already.
# [09:53] <Bert> Alan: We can start by adding more pseudos.
# [09:53] <Bert> ... Put it in Regions, in the examples.
# [09:53] <Bert> ... Progress the spec in that way.
# [09:53] <Bert> ... I think we want other pseudos as well.
# [09:53] <Bert> ... But that may split out later.
# [09:53] <Bert> ... But this could be enough for the spec that we have.
# [09:54] <Bert> florian: so: page templates spec + Regions spec?
# [09:54] <Bert> Alan: We indeed have too many specs.
# [09:54] <Bert> florian: OK, doesn't really make a difference.
# [09:54] <Bert> Alan: So should we add a single pseudo to the Regions spec?
# [09:55] <Bert> ... A 'slot' pseudo that stands for a region, similar to Template slots, but more general.
# [09:55] <Bert> howcome: What is the difference with :repetion()?
# [09:56] <Bert> Vincent: Instead of using an elet to create a region, you could use something else.
# [09:56] <Bert> howcome: You always need an elememnt.
# [09:56] <Bert> Alan: True. But there is a general need fo rmore pseudos. The 'slot' I propose would be a generic region.
# [09:57] <Bert> howcome: I don't understand. How fou solve the problems by adding one more pseudo?
# [09:57] <dbaron> What's ::slot? Has it been described today?
# [09:57] <Bert> (slot is in css3-layout)
# [09:57] <Bert> florian: We can add it and drop it, or split it, when we know more.
# [09:58] <Bert> plinss: Where there is ocmmonality it makes sense to devel together.
# [09:58] <Bert> florian: Not needed with the things we're proposing, maybe.
# [09:58] <Bert> glazou: Takes too much time during ftf. When we have 5 proposals, need to find out what overlaps.
# [09:59] <Bert> howcome: I don't mean we need to do it today, but it needs to be done in this group.
# [09:59] <Bert> plinss: As we're devoping n difference propsosal, I don't want 5 diff. ways to do the same thing.
# [09:59] <Bert> ... identify the overlap, agree on working on it, and go off and work on it.
# [10:00] <Bert> glazou: Not sure we are at that point yet,
# [10:00] <glazou> s/fou/you
# [10:01] <Bert> szilles: We see two or three diff. mecahnisms today. Overflow generates boxes. Also pagination creates pages and content flows into it. Regions generalizes that idea of layout structure. Is ortho to overflow/repeating. But there is a dependency to make them useful.
# [10:01] <Bert> ... Repeating doesn't really solve multiple flows case; you need both.
# [10:02] <Bert> ... Consider them together, because they need to work together. Cannot work on them independently.
# [10:02] <Bert> ... Templates and Grids is an example of not working together enough.
# [10:03] <Bert> Vincent: Mech. for generating boxes [scribe missed]
# [10:03] <Bert> florian: template mechanism is cool, overflow repeat is cool, too. But what is the pseudo you're talking about?
# [10:03] <Bert> szilles: That's the 3rd thing I mentioned.
# [10:04] <Bert> ... Need a way to talk about another way pieces of content and regions.
# [10:04] <Bert> ... Slots address things that do not exist as elements.
# [10:04] <Bert> vincent: Say youhave an article.
# [10:04] <Bert> ... Can set the layout to a grid.
# [10:04] <Bert> ... Grid cells can be regions.
# [10:04] <Bert> ... Can then flow content into it.
# [10:05] <Bert> ... But you need a way to address those regions.
# [10:05] <Bert> Alan: he current Regions uses elements in the examples as regions.
# [10:05] <Bert> ... If we had ::slots we could use that for styling.
# [10:06] <Bert> howcome: How can that be only one pseudo?
# [10:06] <Bert> Alan: I'm talking about a generic slot.
# [10:06] <Bert> ... Can attach a slot to anything, including another slot.
# [10:06] <Bert> florian: If you position it, where does it go?
# [10:06] <Bert> Alan: We'd need to define that, could be before after sibling, etc,
# [10:07] <Bert> fantasai: You also need to define the order.
# [10:07] <Bert> Vincent: Yes we know, we had ideas for that in aearlier versions.
# [10:07] <Bert> plinss: This is example of the overlap I'm afraid of.
# [10:07] <Bert> florian: Note that my demo is based on Adobe's idea, it's not mine.
# [10:08] <Bert> plinss: I'd rather like nth-copy to be a used as a slot.
# [10:08] <Bert> florian: We can work on that. But my example doesn't create a box *unless* there is content for it.
# [10:09] <Bert> Alan: Aut-gen and pagination are some ways, but auto-height is another.
# [10:09] <Bert> howcome: Last copy with auto height woud not egenrate mor eboxes.
# [10:10] <Bert> florian: I now understand peter's point. Let's not talk about that right now.
# [10:10] * hober plinss: something like div::foo:nth-child(2)?
# [10:10] <Bert> szilles: florian summarized as there seems to be agreement on regions and overflow repeat. Yhere is not enough detauils on what is needed or not.
# [10:10] * plinss hober, yes
# [10:10] <Bert> ... Is that indeed consensus?
# [10:11] <Bert> ... Trying to understand and come back with proposal for 3rd piece.
# [10:11] <Bert> howcome: Makes sense. Anybody can wotk on anything and come with a proposal.
# [10:11] <Bert> glazou: Seems we're all interested.
# [10:11] <Bert> ... We need written things.
# [10:12] <Bert> Vincent: We can take an action to work on slot ideas.
# [10:12] <Bert> florian: template and repeat are orhtogonal.
# [10:12] <Bert> Alan: But may wat to repeat a tmeplate, too.
# [10:13] <Bert> plinss: Otho how you generate the box. Overlap on how you *use* them once generated.
# [10:13] <Bert> ... Only one kind of thing.
# [10:13] <Bert> szilles: Also naturla DOM interface.
# [10:13] * Joins: florianr (florianr@193.105.139.140)
# [10:13] <Bert> ACION florian to work with Alan to work on overflow repeat nd consider how int intercts with slot pseduo elt.
# [10:14] <Bert> ACTION florian to work with Alan to work on overflow repeat nd consider how int intercts with slot pseduo elt.
# [10:14] * trackbot noticed an ACTION. Trying to create it.
# [10:14] <trackbot> Created ACTION-467 - Work with Alan to work on overflow repeat nd consider how int intercts with slot pseduo elt. [on Florian Rivoal - due 2012-05-18].
# [10:15] <Bert> Alan: We need something in the spec before we address the issue.
# [10:15] <Bert> ... Another issue, by Bert a few weeks ago, about disallowing elements to be regions.
# [10:15] <Bert> ... I think that would be a mistake.
# [10:16] <Bert> ... Wrapper DIVs and such.
# [10:16] <Bert> ... I don't know how to convince people, but I don't want to disallow it.
# [10:16] <Bert> ... Seems to hamstring ourselves.
# [10:16] <Bert> sylvaing: [missed]
# [10:17] <Bert> howcome: Just make it so that we don't need elements.
# [10:17] <Bert> ... That is enough. Too early to say what is in and what is out.
# [10:17] <dbaron> I agree with Håkon.
# [10:17] <Bert> sylvaing: So resolve to put everything in.
# [10:17] <Bert> howcome: I object to putting in the element approach.
# [10:18] <Bert> ... People will see that it works in IE10 and start using it.
# [10:18] <Bert> sylvaing: it is too early, you said.
# [10:18] <Bert> glazou: Let's wait and see if it indeed becomes common practice.
# [10:19] <Bert> johnd: That is bizarre logic.
# [10:19] <Bert> florian: It woul dbe wrong to put examples in the spec that show elements.
# [10:19] <Bert> ... If it doesnt do that, it seems fine.
# [10:19] <Bert> ... Imply, don't say, elements create regions.
# [10:20] <Bert> howcome: there should not be examples with elements.
# [10:20] <Bert> Alan: Examples are the only places where we still have elements.
# [10:20] <Bert> ... But no prohibition.
# [10:20] <Bert> Vincent: it is currently an issue. We can keep the issue.
# [10:21] <Bert> howcome: We don't ened to agree to remove it, we need to agree if we want to put it *in*.
# [10:21] <Bert> sziles: Issue suggests DIVs. Issue can be rewqorded to talk about "restriction on what can create rgions"
# [10:22] <Bert> howcome: No, we need to say explicilly what we need. Do not sweep under the carpet.
# [10:22] <Bert> ... It is a contentious issue.
# [10:22] <Bert> Alan: There are clearly two camps.
# [10:22] <Bert> howcome: We should not omit the word "element" from the issue?
# [10:23] <Bert> sylvaing: Are we trying to resolve the issue now already?
# [10:23] <Bert> [several]: no, just the wording of the issue.
# [10:23] <Bert> Alan: Let's leave the issue as it is then?
# [10:23] <Bert> howcome: OK
# [10:23] <Bert> Alan: On to shapes and exclusions:
# [10:24] <Bert> ... Shapes seems non-contentious.
# [10:24] <Bert> ... People want those inside and outside shapes.
# [10:24] <Bert> .. Still open how exactly you generate those shapes.
# [10:24] <Bert> s/../.../
# [10:24] <Bert> howcome: no code examples in the draft, so hard to say.
# [10:25] <Bert> ... [scrolling down to shape-inside]
# [10:25] <Bert> ... What goes in the shape? the content, the children?
# [10:26] <Bert> glazou: I understood the spec. But what is the question?
# [10:26] <Bert> fantasai: E.g., what if there is a float, what wraps around it, is the shape influenced by the float?
# [10:27] <Bert> szilles: It works exactly like exclusions today.
# [10:27] <Bert> glazou: there are exclusions in GCPM, too, end they don't say either.
# [10:27] <Bert> howcome: Right, because it depends on Shapes and Exclusions.
# [10:28] <Bert> Alan: We can add examples.
# [10:28] <Bert> howcome: the shape also shapes floating children?
# [10:29] <Bert> Alan: Yes.
# [10:29] <Bert> vincent: We specify floats and shapes, and processing model ("wrapping context").
# [10:29] <Bert> howcome: An example with a float...
# [10:29] <Bert> szilles: ... or a table...
# [10:29] <Bert> howcome: ... woild be good.
# [10:30] <Bert> szilles: in text world, each line of text is as if it has a float on its side, where it interescts the line and the shape.
# [10:31] <Bert> howcome: That is a good way to define the behavior.
# [10:31] <Bert> Alan: At leats a way to explain it and also a way people implement it today.
# [10:31] <Bert> szilles: In a BFC you need to consider the whole BFC as one.
# [10:32] <Bert> Alan: One issue is extending wrapping functionality other things than floats.
# [10:32] <Bert> ... We have a section with processing model for wrapping functionality to non-floats.
# [10:32] <Bert> ... We had an objection to that.
# [10:32] <Bert> ... WG hasn't agreed to pursue that.
# [10:33] <Bert> ... If not, we need to tighten the woridng of the note.
# [10:33] <Bert> Vincent: The obj was that the model assumes abs. pos. That is not what the spec really says.
# [10:34] <Bert> ... So hard to argue with what the spec doesb't actually say.
# [10:34] <Bert> Alan: Objection is that exclusions for abs. pos is a bad idea.
# [10:34] <Bert> ... But the spec syas exclusions can be generated to *any* box.
# [10:35] <Bert> florian: Objection probably comes from the fact that floats currently cannot influence further back than their own line.
# [10:35] <Bert> dbaron: That is a part of it, but no the main piece.
# [10:35] <Bert> ... The use of abs. pos, in this kind of thing creates fragile pages that do not resize.
# [10:36] <Bert> ... But florian's point is also valid.
# [10:36] <Bert> Vincent: Depending on how you use abspos, e.g, with percentages, it may still resize correctly.
# [10:37] <Bert> Alan: Examples in spec uses grid positining and that overlaps overlap. ANd if there is overlap, it is nice to have wrapping behaviousr as well.
# [10:37] <Bert> szilles: Media Queries allows new mechanisms to scale.
# [10:37] <Bert> dbaron: MQ is good for the case where the author things about the sizes.
# [10:38] <Bert> ... But pb occurs even in very small ranges, within a same MQ.
# [10:38] <Bert> ... So this spec *encourages* abspos where abspos is otherwise a bad idea.
# [10:39] <Bert> howcome: Related point: we also need to exclude based in background.
# [10:39] <dbaron> s/things/thinks/
# [10:39] <Bert> ... If we had that in the spec, there would be less concerna bout abspos.
# [10:39] <dbaron> s/pb occurs/the problem here occurs/
# [10:39] <Bert> szilles: If there is a simpler way that abspos, then people will use that ann not abspos.
# [10:40] <Bert> vincent: Not yet an example of using background.
# [10:40] <Bert> howcome: Masks are in there already in some other way.
# [10:40] <Bert> ... Backgrounds have become very powerful in CSS.
# [10:40] <Bert> ... We just need to "connect the dots."
# [10:41] <Bert> Alan: Extend wrapping to other things than floats is the qestion.
# [10:41] <Bert> szilles: howcome addresses dbaron's point; if we offer something simpler than abspos, people will not use abspos.
# [10:42] <Bert> vincent: we had a wiki with comparisonof solutions.
# [10:42] <Bert> szilles: The issues is not encourage wrong approaches.
# [10:42] <Bert> ... The average persoon will that the simplest solution, not nesserily the best.
# [10:43] <Bert> s/that/take/
# [10:43] <Bert> vincent: If abs pos is so terrible, let's remove it from CSS.
# [10:43] <Bert> dbaron: We haven't done anything on abspos sicne 1998 or so. This would be the 1st enhancement.
# [10:43] <dbaron> s/anything/any enhancements/
# [10:44] <Bert> vincent: similar to discussion on elements in regions.
# [10:44] <Bert> ... Why is that in these two specs we have to do things that other specs don't have to do?
# [10:44] <Bert> Tab: Diff. between definitely adding and leabing it possible.
# [10:45] <Bert> ... Background used to create exclusions is a good way. Can often use it without extra content added to dcou,ment.
# [10:45] <Bert> florian: Don't tempt people.
# [10:45] <Bert> glazou: backgrounds is not enough.
# [10:45] <Bert> howcome: Can't you put it in?
# [10:46] * Joins: Ms2ger (Ms2ger@91.181.124.114)
# [10:46] <Bert> glazou: summary: change the spec so that people use the preferred way that does not involve abspos.
# [10:47] <Bert> Alan: So issue is: do we extend exclusion to anything other than float and backgrounds?
# [10:47] <fantasai> szilles++
# [10:47] <Bert> szilles: I prefer a concrete statement about what concerns dbaron.
# [10:48] <Bert> dbaron: complzity of processing model.
# [10:48] <dbaron> dbaron: two big things are collisions and the complexity of the processing model
# [10:48] <Bert> Alan: Complexity may be too much. Collisions?
# [10:48] <Bert> dbaron: Causes fragile designs that cause collisions.
# [10:48] <Bert> Alan: That is an objection to abspos.
# [10:49] <Bert> dbaron: But exclusions make abspos more attractive by avoiding some collisions, but still others exist that you can't all test.
# [10:49] <Bert> dbaron: Take as aexample a pull quote, you test and you have a pull quote on all pages.
# [10:50] <Bert> ... But resize slightly and, sddenly the pullquotes are on top of each other.
# [10:50] <Bert> Alan: There is a way to put floats to the top of the page already.
# [10:51] <Bert> fantasai: But with abspos, you currently don't have a lot of incentive to use it.
# [10:51] <Bert> ... but the exclusions *appear* to solve their problems.
# [10:52] <Bert> dbaron: if the author doesn't see the right example, he won't use it.
# [10:52] <Bert> vincent: Today already people design on desktop and it doesn't work on a phone.
# [10:52] <Bert> dbaron: That
# [10:52] <Bert> ... is why we're working flexbox and grid, e.g.
# [10:53] <Bert> vincent: grid example is in spec. But grid allows overlap.
# [10:53] <Bert> howcome: We need to position things between two columns.
# [10:53] <Bert> Alan: No, that is not for this spec.
# [10:54] <Bert> Tab: Abspos is salvagable as a decent mechanism is in the futre.
# [10:54] <Bert> dbaron: Too fragile.
# [10:54] <Bert> ACTIOn alan to add 2 issues to more clearly define issue 1
# [10:54] * trackbot noticed an ACTION. Trying to create it.
# [10:54] <trackbot> Created ACTION-468 - Add 2 issues to more clearly define issue 1 [on Alan Stearns - due 2012-05-18].
# [10:55] <Bert> ACION alan to add background exclusion.
# [10:55] <Bert> ACTION alan to add background exclusion.
# [10:55] * trackbot noticed an ACTION. Trying to create it.
# [10:55] <trackbot> Created ACTION-469 - Add background exclusion. [on Alan Stearns - due 2012-05-18].
# [10:55] <Bert> howcome: And please add exampels for all properties.
# [10:55] <Bert> ... I think we had decided that in general.
# [10:56] <Bert> glazou: Let's take that to e-mail.
# [10:56] <Bert> vincent: Complex regions f the spec. Please, check and send feedback.
# [10:56] <Bert> vincent: See if it is implementable.
# [10:56] <Bert> ... Auto-sizing part ditto.
# [10:57] <Bert> glazou: The specs are quite readable.
# [10:57] <Bert> szilles: The choice of simplicity and efficiency over best results is woth pointing out.
# [10:57] <Bert> ... Sometimes thus less than optimal results.
# [10:57] <Bert> ... Related to dbaron's points.
# [10:58] <Bert> johnd: Follow-up on discussion about usong mailing list. I wrote something, please look at it.
# [10:59] <Bert> [break]
# [11:00] * Quits: arno (arno@193.105.139.140) (Quit: Leaving.)
# [11:04] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [11:11] * alexmog__ off to sleep. dudes and dudettes, enough fighting for what not to do, let's come up with something that works already!
# [11:11] <Zakim> -alexmog__
# [11:16] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)07:07Z
# [11:16] <Zakim> Team_(css)07:07Z has ended
# [11:16] <Zakim> Attendees were +49.403.063.68.aaaa, Meeting_Room, +1.206.923.aabb, alexmog__
# [11:23] * Joins: AlexD (qw3birc@128.30.52.28)
# [11:24] * Liam http://en.wikipedia.org/wiki/List_of_large_sailing_vessels
# [11:25] <Bert> Vincent: I sent an e-mail.
# [11:26] <Bert> ... Implementation is available for download.
# [11:26] <Bert> ... You can play with it. Source is also there.
# [11:26] <Bert> ... It is based on public Webkit trunk.
# [11:27] * Joins: vhardy__ (vhardy@193.105.139.140)
# [11:27] * Quits: vhardy_ (vhardy@193.105.139.140) (Connection reset by peer)
# [11:27] * Joins: tabatkins__ (qw3birc@128.30.52.28)
# [11:27] <vhardy__> Topic: XSLFO
# [11:27] <vhardy__> ScribeNick: vhardy
# [11:28] <Liam> http://www.w3.org/2012/Talks/05-quin-paged-media/all.txt
# [11:28] <vhardy__> liam: thanks for giving me a chance to present.
# [11:29] <vhardy__> … XML activity lead at W3C
# [11:29] <vhardy__> … chair XML print and page layout WG
# [11:29] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [11:29] <vhardy__> … informal presentation. Not trying to persuade the group. Want to share background about how XSL came to what it is.
# [11:30] <vhardy__> … very brief comparison between CSS and XSL
# [11:30] <vhardy__> … brief notes on paged media requiremetns.
# [11:30] <vhardy__> … the big question is how do we go forward and what the overall goal is.
# [11:30] <vhardy__> … want great document formatting.
# [11:31] <vhardy__> As we commoditize books, we should be able to do them with HTML and CSS. We should be able to do all of 70% of book formatting.
# [11:31] <vhardy__> I do not want to be able to do 70% of each book. We want to do the entirety of 70% of the books.
# [11:32] <vhardy__> SGML was created for publishing, became a <s>Rec</s> ISO standard in 1986
# [11:35] <vhardy__> … every documentation on parts for automobile, cruise ships, airplanes, plants etc… are done in SGML
# [11:36] <vhardy__> 3 parts of SGML on the web: Xlink, XML, XSL
# [11:42] * Joins: SimonSapin (simon@82.232.219.95)
# [11:43] * Quits: SteveZ (chatzilla@193.105.139.140) (Ping timeout)
# [11:45] <vhardy__> Footnotes, back of the book index are important requirements and complex.
# [11:46] <vhardy__> The number of publishers using XSL-FO is increasing right now. They are not moving to CSS+HTML yet because there are things like back-of-the-book-index that are not available yet.
# [11:47] <vhardy__> … publishers are waiting for XSL-FO 2.0 but they are not joining the WG.
# [11:47] <vhardy__> … the work on XSL FO 2.0 has stopped, but people want the features.
# [11:47] <vhardy__> … how can we do this in HTML + CSS.
# [11:47] <vhardy__> hakon: I have been publishing books in css since 2005.
# [11:48] <vhardy__> liam: yes, some people do that, but it is often done with extensions.
# [11:48] <vhardy__> fantasai: not everything is in the wg drafts, but a lot of it is.
# [11:49] <vhardy__> szilles: you are trying to help us identify features that, from your experience, a large user community would like. Some of the issues may have been solved, some not.
# [11:49] <vhardy__> liam: yes. The bigger problem is what should we do? I am thinking of stopping XSL-FO if we can agree that print is enough of a priority and we can address the needs with CSS+XHTML.
# [11:50] <vhardy__> … the main two possibilities are: flow becomes HTML and page masters and flow maps stay in XML. Or, some of the later part goes to CSS (e.g., regions, exclusions).
# [11:51] <vhardy__> …. we are close to closing the XSL WG. The XSL FO WG is going to be closed in the next 6 months. There is a community group. The future for those users is CSS, for most of them.
# [11:51] <vhardy__> jdagget: if you see things that are needed in CSS, please point out what these are.
# [11:51] <vhardy__> liam: I have done some of that, more work is needed.
# [11:51] <vhardy__> tab: would be good to have your list and be able to tell you what is covered and what is not.
# [11:52] <vhardy__> liam: publishers take technology and do things with it. But they do not create the technology.
# [11:52] <vhardy__> … printers make innovation. You cannot get publishers in wg.
# [11:53] <vhardy__> glazou: I think it would be good to have you in this wg and give input if what we are bringing to css is not in-line with what that user base wants.
# [11:53] <vhardy__> … it is a new industry domain that HTML+CSS could address. Seems like an area of growth.
# [11:53] <vhardy__> … Each time we touch a domain you have already seen in XSL-FO, please tell us if we are falling in traps.
# [11:53] <vhardy__> … let us know if there is a better design you know of for some features.
# [11:54] <vhardy__> … help us improve CSS.
# [11:54] <vhardy__> szilles: while XSL-FO was not conceived for browsers, it did look into things like progressive rendering.
# [11:54] <vhardy__> glazou: if you saw things during this meeting that you would like to comment on, please do it asap.
# [11:55] <vhardy__> liam: it is hard to catch up with all the current work. Is it a sensible goal to replace XSL-FO with HTML+CSS.
# [11:55] <vhardy__> hakon: I think it makes sense to publish books in HTML+CSS.
# [11:55] <vhardy__> … you should use at the GCPM specification.
# [11:55] <vhardy__> liam: how to we move on print media quickly so that it is useful for ePub.
# [11:55] * Zakim excuses himself; his presence no longer seems to be needed
# [11:55] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [11:56] <vhardy__> glazou: I think you should start with a requirements document for this working gorup.
# [11:56] <vhardy__> dbaron: don't assume that everything in GCPM is complete.
# [11:56] <vhardy__> liam: we spent 3 years talking about regions and exclusions.
# [11:57] <vhardy__> plinss: liam has a meta-questions. Print has not been addressed properly in css. What is the path forward? For him to fold things into CSS+HTML, he needs a commitment that we are going to work on that.
# [11:57] <vhardy__> … GCPM has not gotten the required attention and level of completeness.
# [11:58] <vhardy__> … I want GCPM driven to req. and not be a placeholder. SHould be a formal priority for the group and be implemented in browsers.
# [11:58] <vhardy__> … Liam wants a commitment from the group to take on that print focus.
# [11:59] <vhardy__> (comments about how recent contributions are already in the area of pagination content).
# [11:59] <vhardy__> szilles: paginated content is not just for printing. It really is about pagination. Let's focus on that piece and printing will fall out of that.
# [11:59] <vhardy__> liam: mostly, but there are a few things that are specific to printing.
# [12:00] <vhardy__> … if we get the commitment, we can talk about the mechanics to do something together on this. Separate or same list?
# [12:00] <vhardy__> glazou: I would start with a list of requirements, then get traction and people will contribute.
# [12:00] <vhardy__> tab: could you start looking at what we have and ask us where we are at with each features.
# [12:01] <vhardy__> hakon: this is a great initiative, you have a lot of expertise. My concern is that I would like this to be a CSS work item.
# [12:01] <vhardy__> liam: it would be.
# [12:01] <vhardy__> glazou agrees.
# [12:01] <vhardy__> liam: I would like to do all of books with what the css wg specifies.
# [12:02] <vhardy__> glenn: I have worked on the XSL FO for years, but I have not seen calls to use HTML+CSS. People are happy using it as is. Some people are going to work with the XPP community. I want to express that this is not exactly what Liam has been saying.
# [12:02] <vhardy__> liam: yes, some people are going to stick to XLS FO. But as browsers are commodatizing good printing, then it is worth changing.
# [12:03] <vhardy__> jdagget: we should talk about pagination, not printing.
# [12:03] <jdaggett> s/jdagget/jdaggett/
# [12:04] <vhardy__> glenn: I think that there are people willing to work on the next version of XSL FO. I would like to see work proceed in both independently and see cross affiliation as possible. There are different focuses and history in both communities.
# [12:04] <vhardy__> … may be they'll meet in the same place.
# [12:04] <vhardy__> hakon: I do not have an opinion on closing XSL-FO or not.
# [12:04] <vhardy__> liam: the wg currently only has 2 members. We cannot fund that work.
# [12:05] <vhardy__> glazou: contributions and input from you on our spec. that touch on things you have worked on in FO, that would help. If you see things that we could add, please let us know too.
# [12:05] <vhardy__> plins: we could also invite the two XSL FO invited experts to join the CSS WG.
# [12:05] <vhardy__> florian: I think this group cares about pagination.
# [12:06] <vhardy__> plinss: I want to see an increased level of commitment from the rest of the group.
# [12:06] <vhardy__> jdagget: I do not think we can do that.
# [12:06] <vhardy__> plinss: we as a group set our priorities.
# [12:06] <jdaggett> s/jdagget/jdaggett/
# [12:06] <vhardy__> tab: we are clearly committed to this.
# [12:06] <jdaggett> vhardy: ^
# [12:06] <jdaggett> vhardy__: ^
# [12:06] <vhardy__> plinss: we are bringing the rest of the expertise and folding it into css.
# [12:07] <vhardy__> glazou: can you invite your experts to join the css wg as invited experts.
# [12:07] <vhardy__> liam: yes, and I'll put together requirements.
# [12:07] <vhardy__> … I can answer questions on XSL.
# [12:09] * Joins: arno (arno@193.105.139.140)
# [12:09] <vhardy__> szilles: typically, there is a portion of the group that is not following some of the discussions. One of the possible solutions to this problem is to create a task force. The FX task force is an example. We founded a group to focus on a specific set of issues. The role of a task force is to develop proposals.
# [12:09] <vhardy__> … we work faster if there are concrete proposals on the table.
# [12:09] <vhardy__> … this may make a suitable task force.
# [12:09] <vhardy__> … just as a way to make additional progress.
# [12:09] <vhardy__> jdaggett: the other alternative is to use the mailing list more.
# [12:10] <vhardy__> (discussion about next agenda items)
# [12:11] <vhardy__> Topic: grids and XSL and pagination
# [12:11] * sylvaing is now known as sylvaing_away
# [12:11] <Bert> -> http://www.w3.org/Talks/2012/0509-CSS-ftf/ Slides on complex layout and grid templates
# [12:11] <vhardy__> (bert presenting)
# [12:11] * sylvaing_away is now known as sylvaing
# [12:12] <vhardy__> bert: I will show you that GCPM is not enough. There is still a lot to do.
# [12:12] <vhardy__> … I have looked at common patterns that are not possible yet. Looking at where the problems are.
# [12:12] <vhardy__> … I believe the solution passes by grids.
# [12:13] <vhardy__> … they are a natural way to do things. easy to learn. I'd like to explain the latest editors of the grid template.
# [12:14] * Joins: drublic (drublic@95.115.33.69)
# [12:14] <vhardy__> … I would like to do as much as possible with css as long as it is easy to do.
# [12:14] <vhardy__> e.g., Table of Content easier not done in CSS
# [12:15] <vhardy__> (slides on CSS processing model)
# [12:16] <vhardy__> (templates - basic ideas)
# [12:19] <vhardy__> vhardy: can cells in your grid overlap?
# [12:19] <vhardy__> bert: yes.
# [12:20] <vhardy__> (templates - second idea)
# [12:21] <vhardy__> (challenge 1: a simple grid?) slide
# [12:22] <vhardy__> (discussion about using a float:bottom for the last paragraph to be bottom aligned)
# [12:22] <vhardy__> bert: other examples where column content is 'justified' vertically.
# [12:23] <vhardy__> fantasai: could use a flex box in the template.
# [12:23] <vhardy__> bert: yes.
# [12:23] <vhardy__> bert shows the signature as a reverse run-in.
# [12:24] <vhardy__> vhardy: there is a proposal for that in the regions spec.
# [12:24] <vhardy__> (discussion about 'after' content that needs to reverse run-in)
# [12:25] <vhardy__> (challenge 1: HTML source) slide.
# [12:26] <vhardy__> In the visual display, the images come before the title, but they come after the title in the logical order.
# [12:27] <vhardy__> (discussing about how aligning images at the top)
# [12:27] <vhardy__> (challenge 1: CSS rules) slide
# [12:28] <vhardy__> (challenge 1: other solutions?) slide
# [12:32] <vhardy__> (challenge 2: column span)
# [12:32] <vhardy__> bert shows how all the content aligns to the bottom)
# [12:33] <vhardy__> … page number at the top: the number height is used to size the separators.
# [12:34] <vhardy__> … we need new unit to size content like this.
# [12:35] <vhardy__> s/unit/units
# [12:35] <vhardy__> tab: may be having text measure functions could be used as well.
# [12:35] <vhardy__> jdaggett: we already have that with canvas.
# [12:35] <vhardy__> szilles: this is not css.
# [12:36] <vhardy__> bert: the kerning in the running header is not easy to do.
# [12:36] <vhardy__> several: might be done with exclusions.
# [12:36] <vhardy__> jdaggett: I do not think there are automatic/scalable ways to do that.
# [12:36] <vhardy__> (challenge 2: CSS rules) slides
# [12:37] <vhardy__> (challenge 2: other solutions?) slide
# [12:37] <vhardy__> you do need GCPM top float.
# [12:39] <vhardy__> szilles: in XSL, float: top will make it automatically go to the next 'top' because the float cannot precede the call-out
# [12:39] <vhardy__> stearns: this is where you may want different page templates depending on the number of columns.
# [12:39] <vhardy__> (challenge 4: centered floating images) slide
# [12:40] <vhardy__> bert: the floats are not in their logical position in the text.
# [12:40] <vhardy__> … but they still line up. They are not floats. Exclusions might be used or regions.
# [12:40] <vhardy__> … there are other ways.
# [12:41] <vhardy__> (challenge 5: mixed horizontal & vertical) slide
# [12:42] * Quits: alexmog__ (qw3birc@128.30.52.28) (Ping timeout)
# [12:43] <vhardy__> (challenge 6: manuscript) slide
# [12:44] <vhardy__> there are several flows.
# [12:44] <vhardy__> 3, interleaved. There are drop caps which extend between regions.
# [12:45] <vhardy__> liam: this is still done in publication.
# [12:46] <vhardy__> … today.
# [12:46] <vhardy__> bert: not sure how to best model this.
# [12:46] <fantasai> sylvaing: http://qkme.me/3p8n6e ?
# [12:46] <vhardy__> stearns: we can do that with regions and excusions.
# [12:46] <vhardy__> (discussion about different solutions)
# [12:47] <vhardy__> (challenge 7: seven different sets of slots)
# [12:48] <vhardy__> jdaggett: there are multiple examples of grids where the axis of the grids are rotated and not aligned with other grids. If you look into some of the russian constructionism, you'll find these designs.
# [12:49] <vhardy__> stearns: is there any limitation to a grid item that prevents it to being transformed?
# [12:49] <vhardy__> (discussion on that topic).
# [12:49] <vhardy__> bert: would be good to do rectangular grids easily.
# [12:50] <vhardy__> (Grid Template Layout - summary, May 2012 1/2) slide.
# [12:52] <vhardy__> flow property, equivalent to flow-into in regions spec.
# [12:53] <vhardy__> grid cells can overlap. If you want an exclusion behavior, then you need something like exclusions.
# [12:53] <vhardy__> (Grid Template Layout - summary May 2012 2/2) slide.
# [12:54] * Quits: drublic (drublic@95.115.33.69) (Client exited)
# [12:55] <vhardy__> @tempalte looks a lot like @page
# [12:55] <vhardy__> chaining slots together is like in region.
# [12:56] <vhardy__> however, the chain defines the region ordering explicitly.
# [12:57] <vhardy__> (discussion about if it is best to move a region to a chain or declare the chain specifically)
# [12:57] <vhardy__> (Grid Tempalte Design) slide
# [12:58] <vhardy__> szilles: I observe that in this particular area, there seem to be that GCPM, regions, templates etc… solve parts of the problem but not the whole problem very well.
# [12:58] <vhardy__> … proponents seem stuck on their particular solution and unwilling to bring things together.
# [12:59] <vhardy__> … there are efforts in that particular direction, but I would like to propose that we set-up a week of dedicated to do education between the people pushing the different proposal and see if we can find a way to combine the pieces and put them together in a complete solution.
# [13:00] <vhardy__> grid, template, regions, exclusions, flex box, .. all the layout specs.
# [13:00] <vhardy__> + regions and exclusions.
# [13:00] <vhardy__> jdaggett: are you saying they should be unified or aligned?
# [13:00] <vhardy__> szilles: aligned at least, unified at best.
# [13:00] <vhardy__> .. this comment is triggered by having listened to the different presentations.
# [13:01] <vhardy__> glazou: this is a general comment, not on bert's presentation in particular.
# [13:01] <vhardy__> szilles: we are not making progress if we are attached to particular solutions.
# [13:01] <vhardy__> dbaron: we are going to need multiple tools. I don't think a single tool.
# [13:01] <vhardy__> szilles: I agree, but I'd need a set of pieces that I can put together.
# [13:02] <vhardy__> fantasai: understanding how things work together makes sense.
# [13:02] <vhardy__> jdaggett: in some cases, I hear things overlap enough that they should be unified.
# [13:02] <vhardy__> hakon: the fundamental issues is that the problem we are trying to resolve is very large. We need to agree on the subset we address.
# [13:03] <vhardy__> … I have talked about the use cases we want to address.
# [13:03] <vhardy__> … scans are good, but resizing needs to be addressed.
# [13:03] <vhardy__> florian: I am not sure scans will let us solve the issue.
# [13:03] <vhardy__> hakon: we could see which use cases we want to address.
# [13:04] <vhardy__> glazou: the problem with the 20 use cases is that you'll need a week to agree on the use cases.
# [13:04] <vhardy__> ted: yesterday, during the discussion about improving our working mode, I think we found there are different expertise areas.
# [13:04] <vhardy__> … the different editors could meet on a dedicated layout telecom for example.
# [13:05] <vhardy__> fantasai: I found that spending a couple days with Bert was useful. I am trying to align the grid module and the template specs.
# [13:05] <vhardy__> I did the same with Microsoft.
# [13:05] <vhardy__> ted: this is nice, but we need more general coordination.
# [13:06] <vhardy__> florian: having use cases is nice, and we should see how to solve the issue in general, not just compare solutions.
# [13:06] <vhardy__> glazou: I have a problem with use cases when we collect them ourselves. I would prefer use cases from users.
# [13:06] <vhardy__> … apple is doing magazines, Opera does things with publishing etc...
# [13:06] <vhardy__> … these people have live cases that do not reach us.
# [13:07] <vhardy__> … e.g., Wired magazine are on the web.
# [13:07] <vhardy__> arno: this is after talking with users that we brought regions/exclusions to the css wg.
# [13:07] <vhardy__> hakon: we know where to go to scan Wired for example.
# [13:07] <vhardy__> glazou: this won't tell us what wired needs the most.
# [13:08] <vhardy__> arno: Wired is a good example because they have complex print layouts. They want to translate their layouts to digital form.
# [13:08] <vhardy__> … they understand there is a difference.
# [13:08] <vhardy__> They understand they need adaptive layout.
# [13:08] <vhardy__> … their challenge is to find the tools to express that.
# [13:08] <vhardy__> … looking at the printed page is not the complete set of requirements.
# [13:09] <dbaron> arno: looking at the printed page is not ideal because the goal is not to replicate the printed page
# [13:09] <vhardy__> …. this is the way the designers look at adaptation that is important.
# [13:09] <vhardy__> krit: the use cases change over time too.
# [13:09] <vhardy__> glazou: it is related to fashion, yes.
# [13:09] <dbaron> glazou: goal not to replicate what's on paper, but replicate the coolness of the magazine
# [13:10] <vhardy__> stearns: when I was collecting examples, people sent me a printed scan and the online version which had different layouts.
# [13:10] <vhardy__> … they are interested to take the layouts on-line.
# [13:10] <vhardy__> hakon: there is the 95% cases that we need to address.
# [13:11] <vhardy__> fantasai: with regards to the template and grid module, several of us would like to discuss this in a task force. It would be nice that anyone
# [13:11] <vhardy__> … who wants to be involved can be invovled.
# [13:11] <vhardy__> …. right now it is bert, myself, holbert.
# [13:11] <vhardy__> glazou: I am interested.
# [13:11] <vhardy__> Lunch <br />
# [13:22] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [13:30] * Joins: jdaggett_ (jdaggett@193.105.139.140)
# [13:30] * Quits: jdaggett (jdaggett@193.105.139.140) (Connection reset by peer)
# [13:30] * jdaggett_ is now known as jdaggett
# [13:32] * Joins: jdaggett_ (jdaggett@193.105.139.140)
# [13:32] * Quits: jdaggett (jdaggett@193.105.139.140) (Connection reset by peer)
# [13:32] * jdaggett_ is now known as jdaggett
# [14:04] * sylvaing is now known as sylvaing_away
# [14:15] <jdaggett> scribenick: jdaggett
# [14:15] <jdaggett> topic: gcpm
# [14:15] <jdaggett> hakon introducing gcpm
# [14:15] <jdaggett> parts pragmatic, parts blue sky
# [14:16] <jdaggett> in 2007, we had how to generate lists, glossaries, toc
# [14:16] * Joins: AlexD (qw3birc@128.30.52.28)
# [14:16] <jdaggett> showing example
# [14:16] <jdaggett> using javascript
# [14:17] <jdaggett> to generate index
# [14:18] <jdaggett> shows page range rather than pages in index
# [14:18] <jdaggett> wanted to highlight feedback from implementors
# [14:18] <jdaggett> interesting - page floats
# [14:19] <jdaggett> allows use to do paginated content on page and screen
# [14:19] <jdaggett> shows demo from last f2f
# [14:19] <jdaggett> implemented from proposals in gcpm
# [14:19] <jdaggett> section 12 page and column floats
# [14:20] <jdaggett> feedback from hyatt
# [14:20] <jdaggett> use other names, based on physical values
# [14:20] <jdaggett> along with line-left, line-right
# [14:21] <jdaggett> fantasai: similar to start, end but change bidi direction
# [14:21] <jdaggett> s/change/doesn't change/
# [14:22] <jdaggett> fantasai: defined in writing modes spec
# [14:22] <jdaggett> glenn: i object, left is left, right is right
# [14:22] <jdaggett> fantasai: so what does text-align: right me in vertical?
# [14:22] <jdaggett> stevez: no, no, no
# [14:23] <jdaggett> stevez: can you say inline-left instead of line-left
# [14:23] <jdaggett> stevez: wait, my reason is wrong...
# [14:23] <jdaggett> more argument about left and right
# [14:24] <jdaggett> ho hum we've had this discussion 1,000 times
# [14:24] <jdaggett> fantasia and alex arguing more
# [14:25] <jdaggett> alex: sorry, i still think left, right are bad terms
# [14:25] <jdaggett> liam: why do you want to be bidi-independent
# [14:25] * hober tips his cap to the excellent scribing going on right now
# [14:26] <jdaggett> stevez: english text, right-aligned needs to be right-aligned not start aligned
# [14:26] <jdaggett> glenn: so you need right/left in vertical?
# [14:26] <jdaggett> stevez: i think inline- would be better
# [14:26] <jdaggett> fantasai: something about one-dimension...
# [14:27] <jdaggett> florian: do we need before/after?
# [14:27] <jdaggett> fantasai: you probably want before/after
# [14:27] <jdaggett> bert: where does it go if you say before/after?
# [14:27] <jdaggett> tabatkins: in english before is the same as top
# [14:28] <jdaggett> liam: should be block-left, block-right
# [14:28] <jdaggett> fantasai: meh, i don't care
# [14:28] <jdaggett> hakon: i just copied hyatt's proposal
# [14:28] <jdaggett> hakon: he also added the ability to span columns
# [14:28] <jdaggett> fantasai: why not use column-span
# [14:29] <Bert> (Seems 'before' means before the current block, not necessarily the top of the page/column/BFC/whatever, but the description is a bit short.)
# [14:29] <jdaggett> hakon: keep this on the float property is the proposal
# [14:29] <jdaggett> stevez: not true hakon
# [14:30] <jdaggett> stevez: with a media query, i may vary the number of columns
# [14:30] <fantasai> s/something about one-dimension/we have left and right values for text-align, whether you like them or not they need a defined meaning for vertical text/
# [14:30] <jdaggett> discussion of columns used at different sizes
# [14:31] <jdaggett> hakon: in our implementation we couldn't do column spanning
# [14:31] <jdaggett> hakon: too many weird situations
# [14:31] <jdaggett> hakon: if you span an arbitrary element in multicolumn
# [14:31] <fantasai> florian's comment wrt before/after was about over/under, I said we don't need those, as to whether we need line-left/line-right in addition to start/end, I don't care much
# [14:32] <jdaggett> stevez: you don't have enough there to fully explain the sitatuion
# [14:32] <jdaggett> hakon: if you have two properties that cascade differently, may not mesh well together
# [14:33] <jdaggett> fantasai: what about image spanning two columns, floating up?
# [14:33] <jdaggett> fantasai: width doesn't make sense here either?
# [14:34] <fantasai> fantasai: column-spanning is effectively setting the width, that's a separate thing from its property
# [14:34] <fantasai> s/property/position, which is what float is setting/
# [14:34] <jdaggett> liam: content can span columns without flowting
# [14:34] <jdaggett> hakon: in opera, two different properties
# [14:34] <jdaggett> hakon: column-spanning has to be on the float
# [14:35] <fantasai> fantasai: if you're making the argument of setting the column-relative size in 'float', why not also make argument that width should be set in 'float' too?
# [14:35] <dbaron> dbaron: if you're going to write that it's going to span columns, what's the harm of writing that in the value of the 'float' property?
# [14:35] <jdaggett> alans: if you want to span two columns you can say, column-span(2)?
# [14:36] <jdaggett> liam: i was just commenting on column-spanning content not always floating
# [14:36] * jdaggett why did i volunteer to scribe column spanning discussion….?
# [14:37] <jdaggett> stevez: you would like it to extend back
# [14:37] <fantasai> Håkon drew a 3-column box with three 2-column-spanning floats:
# [14:37] <fantasai> first float started in first column, spanned into second
# [14:37] <jdaggett> discussion on whiteboard b/t
# [14:37] <jdaggett> liam: sometimes call "negative spanning"
# [14:37] <fantasai> second float started in second column spanned into third
# [14:37] <fantasai> question was what happens with third float
# [14:38] <fantasai> which starts in third column
# [14:38] <jdaggett> liam: acm papers, tables occur where they occur in content, they span there
# [14:39] <jdaggett> hakon: related to widows/orphans behavior
# [14:39] <jdaggett> fantasai: don't use widows/orphans properties for this
# [14:40] <jdaggett> hakon: so what does snap mean?
# [14:40] <jdaggett> fantasai: within 3em you snap
# [14:40] <jdaggett> alans: you're trying to decide between syntax?
# [14:40] <jdaggett> hakon: no, an implementor has proposed it
# [14:41] <jdaggett> hakon: i think it would be good for comments to happen on the mailing list
# [14:41] <jdaggett> fantasai: three things
# [14:41] <jdaggett> (3) better syntax for snapping
# [14:41] <fantasai> (2) should use float: columns(2) or float + column-span?
# [14:42] <jdaggett> hakon: bert's issue
# [14:42] <fantasai> (1) rename line-left/line-right to inline-left/inline-right?
# [14:42] <jdaggett> hakon: about running headers
# [14:43] <jdaggett> stevez: xsl uses flow-into and you pick a slot to put it into
# [14:43] <jdaggett> hakon: do we want this parameter for regions
# [14:44] <jdaggett> arguing whether steve's xsl parameter covers the use case
# [14:44] <jdaggett> hakon: comment on example 11
# [14:44] <jdaggett> hakon: keyword approach also possible
# [14:44] <glazou> glazou: that's cloning the flow into the region instead of moving it there
# [14:44] <jdaggett> bert: don't know about syntax, want functionality
# [14:45] <jdaggett> stevez: just noting the way it was done in xsl
# [14:45] <jdaggett> hakon: this is a problem to tackle
# [14:45] <tabatkins__> ScribeNick: TabAtkins_
# [14:45] <tabatkins__> Topic: CSS Fragmentation
# [14:45] <dbaron> ScribeNick: tabatkins__
# [14:46] <tabatkins__> fantasai: One issue, what uses specified height.
# [14:46] <tabatkins__> TabAtkins_: Say I have a specified height of 500px on my element.
# [14:46] <tabatkins__> s/TabAtkins_/fantasai/
# [14:47] <tabatkins__> fantasai: And there was a large image in my content that spans a page break.
# [14:47] <tabatkins__> fantasai: So the image moves down to the next page, there's a gap left in the old page.
# [14:47] <tabatkins__> fantasai: So does that gap count against my "500px height"?
# [14:48] <tabatkins__> fantasai: Rossen and I thought it made sense to skip.
# [14:48] <tabatkins__> fantasai: when you're using box-decoration:slice, it's not very clear, but for box-decoration:clone, it seems pretty clear that we want to skip the gap when calculating height.
# [14:49] <tabatkins__> dbaron: Are any of the decoration drawn in the gap anyway?
# [14:49] <tabatkins__> dbaron: I'd prefer to skip all of that.
# [14:50] <tabatkins__> dbaron: I'm concerned about background-position interacting with that, and avoiding drawing parts of a background more than once.
# [14:50] <tabatkins__> fantasai: [explains box-decoration:clone]
# [14:50] <tabatkins__> dbaron: My gut feeling is that I want, regardless of whether it uses borders, background, or height, for it to be consistent with each other.
# [14:51] <tabatkins__> dbaron: We may want a control for the whole set later, but I think picking a default for now is fine.
# [14:51] <dbaron> s/regardless of //
# [14:52] <tabatkins__> vhardy__: Another issue on the mailing list is about, if the image moves to the next page, can the following text move back up to fill in the gap?
# [14:52] <tabatkins__> TabAtkins_: Wasn't there a float keyword proposed to do something like that?
# [14:53] <tabatkins__> fantasai: I think next-page, or if-room?
# [14:53] <tabatkins__> howcome: unless-room, but I think snap will do that now.
# [14:53] <tabatkins__> [off-topic discussion about floating]
# [14:54] <tabatkins__> fantasai: So with a specified height, I'm okay with not drawing decorations in the gap.
# [14:55] <tabatkins__> fantasai: But with an auto-height element that's multiple pages tall, with some gaps in the background would look weird.
# [14:55] <tabatkins__> dbaron: I think skipping would be normal behavior,a ctually.
# [14:56] <tabatkins__> plinss: Depends on what the background is for. If you have a fancy background on the <body>, and your element uses a white background to put something flat under the text, you'll expect it to continue without gaps.
# [14:56] <tabatkins__> fantasai: I think it doesn't make sense to slice the background in the middle of the page.
# [14:57] <tabatkins__> sziilles: For government usage, they *really* wanted a specific background (like a repeated "mandatory" image) to cover all and only the areas that are explicitly the given element.
# [14:57] <tabatkins__> szilles: So you want it to gap.
# [14:57] <tabatkins__> s/sziilles/szilles/
# [14:58] <tabatkins__> [some missed discussion about how drawing in the gap is like drawing in the margin area]
# [15:00] <tabatkins__> fantasai: [gave an example with two floats, both page-breaking to the next page but on different vertical positions]
# [15:02] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [15:19] * Joins: AlexD (qw3birc@128.30.52.28)
# [15:19] <tabatkins__> fantasai: Proposal: first, do you use up specified height for the gap? The answer is "no, never".
# [15:20] <tabatkins__> fantasai: Second, when do you draw the background/borders in the gap? Answer is, in the fixed height, no. In auto height, yes.
# [15:20] <tabatkins__> TabAtkins_: the value of this is that it preserves the invariant that dbaron wanted to preserve, while looking good for both fo the common cases.
# [15:21] <tabatkins__> RESOLVED: Accept the CSS3 Break proposal as stated in the minutes.
# [15:21] <tabatkins__> fantasai: Then can we publish a WD?
# [15:23] <tabatkins__> howcome: No comment against that particular request, but I think in general we should be asking for publication against the current WD, not against a future spec based on pending edits.
# [15:24] <tabatkins__> plinss: In general, I agree. I think it's safe to make a provisional request here.
# [15:24] <tabatkins__> RESOLVED: Publish a WD of CSS3 Break in a week if there are no objections.
# [15:24] <tabatkins__> Topic: CSS3 Text
# [15:25] <tabatkins__> fantasai: A few issues to go over.
# [15:26] <tabatkins__> fantasai: First is about jstuification and half-width characters.
# [15:26] <tabatkins__> fantasai: I'd like to close this as WONTFIX.
# [15:26] <tabatkins__> fantasai: Problem is a grid-style font whose characters are either half-width or full-width, and you try to justify by putting equal space between every character, the chars will no longer line up.
# [15:27] <tabatkins__> fantasai: Koji recommended ignoring it, because these fonts are going out of style, so it's not important enough to address right now.
# [15:27] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/98
# [15:27] <tabatkins__> ACTION vincent to run the "justification of mixed full/half-width chars" proposal past Nat. http://www.w3.org/Style/CSS/Tracker/issues/98
# [15:27] * trackbot noticed an ACTION. Trying to create it.
# [15:27] <trackbot> Created ACTION-470 - Run the "justification of mixed full/half-width chars" proposal past Nat. http://www.w3.org/Style/CSS/Tracker/issues/98 [on Vincent Hardy - due 2012-05-18].
# [15:28] <tabatkins__> fantasai: Next issue - should text-transform:capitalize apply to letters after a hyphen or underscore?
# [15:28] <tabatkins__> jdaggett: What's the existing behavior?
# [15:28] <tabatkins__> fantasai: Dunno. the issue was "should we use UAX29 to determine word boundaries?".
# [15:28] <tabatkins__> fantasai: I think the curretn spec doesn't define. It points to UAX29 as being useful, but doesn't define explicitly.
# [15:29] <tabatkins__> dbaron: I think authors have complained about the inconsistency. I don't know if their complaints were consistent in one direction or another.
# [15:29] <tabatkins__> fantasai: There's definitely cases where UAS29 doesn't work well - compare "l'enfant" with "don't", two words versus one.
# [15:29] <tabatkins__> fantasai: I don't think we have the correct rules yet, but I don't think we need to be spending much time on it either right now.
# [15:30] <tabatkins__> fantasai: You simply can't rely on it to handle more than the simplest cases correctly.
# [15:30] <tabatkins__> fantasai: So I propose closing it as WONTFIX, at least right now. It's potentially useful, but it's very big, and low-priority in my mind.
# [15:31] <tabatkins__> florianr: I think that Opera does soemthing suboptimal, and I'd appreciate a better ref, but I understand how hard it is, and how there's probably just not a good answer today.
# [15:31] <tabatkins__> fantasai: A lot of the things that look obviously wrong in Kew's testcase that look obviously wrong are already handled in the normative text.
# [15:32] <tabatkins__> fantasai: For example, a lot hinged on the text saying "capitalize the first *letter*". So you find the word boundaries, then scan for the first *letter*, not necessarily the first character.
# [15:32] <tabatkins__> jdaggett: Have you checked with Jonathan Kew that this is satisfactory? I'd like to verify that he's fine.
# [15:32] <tabatkins__> fantasai: Yeah, I can make sure. I think all of his examples were covered by that sentence.
# [15:33] <tabatkins__> RESOLVED: Pending Jonathan Kew's okay, keep text-transform:capitalize in its current form, with only an informative reference to UAX29
# [15:33] <tabatkins__> fantasai: Next is combinations of values in text-transform.
# [15:33] <tabatkins__> fantasai: Previous draft let you combine values that weren't mutually exclusive, like "capitalize full-width".
# [15:33] <tabatkins__> fantasai: There were several suggestions on the mailing list to not allow these combinations.
# [15:34] <tabatkins__> fantasai: So I propose we disallow that. There's not strong use-cases, and we can fix it later.
# [15:34] <tabatkins__> florianr: For context, I was one against the combining. I didn't dislike combining, I thought the *draft's* way of doing it wasn't good enough, and was hostile to later improvement.
# [15:34] <tabatkins__> florianr: I have a proposal for a better way, which is part of a proposal for the next level.
# [15:34] <tabatkins__> RESOLVED: Disallow combinations of values in text-transform for this level.
# [15:35] <tabatkins__> fantasai: There was an issue about currentColor and inheritance - the currentBehavior wasn't good enough.
# [15:36] <tabatkins__> fantasai: I think we were waiting for SVGWG approval, which we got, so I guess we want errata on CSS3 Color?
# [15:36] <tabatkins__> TabAtkins_: Chris said he was okay with doing the errata, he's just been unable to do it yet.
# [15:37] <tabatkins__> RESOLUTION: Changing currentColor to resolve at used-time is okay with the SVGWG; we're just waiting on Color to be errata'd.
# [15:37] <tabatkins__> fantasai: Next is an issue about where exactly you draw the letter-spacing.
# [15:37] <tabatkins__> fantasai: So if you say "I want letter-spacing in this element", is there spacing on either side of the element?
# [15:38] <tabatkins__> fantasai: Current spec says no - the spacing between elements is given by the common ancestor.
# [15:38] <tabatkins__> fantasai: A thread on the list said it might not be the right behavior for emphasis in German and perhaps others.
# [15:38] <tabatkins__> fantasai: However, you can always add spacing with padding, while it's hard to remove the letter-spacing.
# [15:38] <tabatkins__> fantasai: So I propose we close as WONTFIX, and suggest to use padding for spacing around the word.
# [15:40] <tabatkins__> TabAtkins_: I think this is fine - letter-spacing only takes <length>, so it's trivial to apply the same <length> in padding right next to it.
# [15:40] <tabatkins__> [a question from Liam that I didn't catch about the itneraction of letter/word-spacing]
# [15:41] <tabatkins__> RESOLVED: letter-spacing is kept as-is in the draft. A note should be added about using padding to put extra spacing on either side of an element, for the use-cases in which that is important.
# [15:41] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/243
# [15:41] <tabatkins__> fantasai: This is about the effect of graphical effects on text-decoration.
# [15:41] <tabatkins__> fantasai: We'd deferred an issue on how visibility applies to text-decoration from CSS2.1
# [15:42] <tabatkins__> fantasai: I thought about it, and think that if you make an element hidden, its decoration should disappear (even if the decoration came from the parent).
# [15:42] <tabatkins__> fantasai: But what about text-shadow?
# [15:42] <tabatkins__> fantasai: It's clear that if *I* create the underline, I should shadow it. But what if my parent is underlining me?
# [15:42] <tabatkins__> fantasai: And you have other effects - opacity, filters, etc.
# [15:43] <tabatkins__> dbaron: Those are both group effects, so they definitely affect the decorations.
# [15:43] <tabatkins__> fantasai: Okay, so thoughts on this?
# [15:43] <tabatkins__> dbaron: I remember thinking about these things when I was fixing up the Gecko text-decoration code during 2.1
# [15:43] <tabatkins__> dbaron: I thought we had a reasonable answer to this. I'd need to go poking around about this to see what it was.
# [15:43] <tabatkins__> fantasai: Okay. I dont' need an answer immediately, if you need to do soem research.
# [15:44] <tabatkins__> dbaron: There was a related issue with shadows - what color the underline's shadow was.
# [15:44] <tabatkins__> fantasai: Okay, so no conclusion yet. I just need feedback.
# [15:44] <tabatkins__> szilles: Is shadow the only effect?
# [15:44] <tabatkins__> dbaron: The only things that should worry about is shadows and visibility.
# [15:45] <tabatkins__> dbaron: shadows are the same thing as text-decoration.
# [15:45] <tabatkins__> fantasai: Kinda, but shadows inherit normally.
# [15:46] <tabatkins__> dbaron: The decoration model is that its' *text* that draws decorations, not the element, which is why they're consistent.
# [15:49] <tabatkins__> szilles: text-shadow is like what you can do with filters. We should be consistent with shadows and filters.
# [15:49] <tabatkins__> fantasai: From the mailing list, Brad has a strong proposal for not shadowing decorations.
# [15:49] <tabatkins__> TabAtkins_: And I had a preference for shadowing the decoration. Steve's consistency argument favors shadowing it.
# [15:49] <tabatkins__> dbaron: Then the question is whether you use the shadow's color or the decoration's color. I think the answer is to uset he shadow's color.
# [15:49] <tabatkins__> szilles: And that's consistent with filters too.
# [15:49] <tabatkins__> dbaron: Note that opinions can switch if you swap so that the shadow is on the parent and the underline is on the child.
# [15:49] <tabatkins__> fantasai: next issue is text-wrap.
# [15:50] <tabatkins__> fantasai: There are three values: normal, nowrap, avoid.
# [15:50] <tabatkins__> fantasai: The problem here is that the text-wrap property inherits.
# [15:50] <tabatkins__> fantasai: So if you have a bunch of nesting, and you set 'avoid' on the outer element, you'll get 'avoid' on the children too.
# [15:51] <tabatkins__> fantasai: I think this is bad. My proposal is to remove the 'avoid' value, and maybe pick it up for something else later.
# [15:52] <tabatkins__> fantasai: And then, once avoid is gone, there's nothing you can do with these properties that couldn't be done with vanilla whitespace, so revert to whitespace being a non-shorthand again.
# [15:52] <tabatkins__> florianr: I think this is good idea.
# [15:52] <tabatkins__> RESOLVED: Remove the 'avoid' value from text-wrap.
# [15:53] <tabatkins__> RESOLVED: Remove the longhands from white-space.
# [15:53] <tabatkins__> fantasai: Last issue is about ruby.
# [15:53] <tabatkins__> fantasai: The layout model for ruby needs a ton of work, and it's nowhere near stable.
# [15:53] <tabatkins__> fantasai: But there's one property that's simple and clear to apply even if you hardcode your ruby markup, and that's ruby-position.
# [15:54] <tabatkins__> fantasai: In a similar way how we defined table properties even before we defined table layout properly, we can say that ruby-position can be applied to ruby, and controls whether it's above or below your text.
# [15:55] <tabatkins__> fantasai: It doesn't define *any* details about alignment or sizing, just its positioning.
# [15:55] <tabatkins__> jdaggett: What's the advantage of moving this?
# [15:55] <tabatkins__> fantasai: The advantage is that this property's definition is *done* - it needs no more work.
# [15:55] <tabatkins__> jdaggett: You seem to be looking for a spec to stick this into.
# [15:56] <tabatkins__> fantasai: Yes, since epub already is using this, so we should pull it into a proper spec.
# [15:57] <tabatkins__> szilles: Can we put this into Writing Modes? It seems to make more sense.
# [15:59] <tabatkins__> jdaggett: I'm uncomfortable with this controlling ruby when ruby layout is undefined.
# [16:00] <tabatkins__> dbaron: One of the dangers with Ruby is that we've gotten feedback from the Japanese publishers wanting particular behaviors, and we're getting close to interop behavior on the *opposite* of what they want.
# [16:00] * sylvaing_away is now known as sylvaing
# [16:01] <tabatkins__> fantasai: I cant' write the whole ruby spec right now.
# [16:02] <tabatkins__> TabAtkins_: Dont' be afraid of single-property specs.
# [16:02] <tabatkins__> fantasai: I could write a Ruby-Position spec and take it to last call in two weeks. ^_^
# [16:03] <tabatkins__> szilles: Question, if we decide when we *do* write the proper Ruby spec, that this property isn't useful, what will we do?
# [16:03] <tabatkins__> fantasai: I can't offer 100% guarantees, but I am quite sure that this property will be necessary no matter what.
# [16:03] <tabatkins__> TabAtkins_: Seconded, based on my own understanding.
# [16:04] <tabatkins__> plinss: I agree with you, Steve, in general about trying to spec ahead of a good understanding of the model.
# [16:04] * sylvaing we can always put it in GCPM *cough*
# [16:04] <tabatkins__> plinss: But ePub is running ahead and possibly doing something that might diverge, so we should control it now.
# [16:05] <tabatkins__> jdaggett: So epub has its whole ruby model?
# [16:05] <tabatkins__> fantasai: No, this is the only property they use. The rest of ruby is just through markup for them.
# [16:05] <tabatkins__> jdaggett: Okay. I just don't like trying to spec ahead of the model.
# [16:06] <tabatkins__> plinss: I agree with the sentiment, but is that a strong objection?
# [16:06] <tabatkins__> jdaggett: No.
# [16:06] <tabatkins__> Liam: The XSL definition for this uses different property names.
# [16:06] <tabatkins__> Liam: [lists them]
# [16:06] <tabatkins__> fantasai: bopomofo was changed to inter-character to be understandable to non-Taiwanese.
# [16:07] <tabatkins__> fantasai: We use the line-relative values instead of logical values.
# [16:07] <Liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#ruby-position
# [16:07] <tabatkins__> Liam: [describes 'auto' behavior]
# [16:08] <tabatkins__> jdaggett: If we're going to change this property, I object to speccing it now.
# [16:08] <tabatkins__> TabAtkins_: I would prefer we don't claim 'auto' ahead of the proper layout model.
# [16:09] <tabatkins__> fantasai: Okay, moving on. overflow-wrap versus word-wrap.
# [16:09] <tabatkins__> florianr: MS invented word-wrap and did it unprefixed. Everyone else implemented it.
# [16:09] <tabatkins__> florianr: Not long ago we decided this was a bad idea, and tried to change it to overflow-wrap.
# [16:09] <tabatkins__> florianr: I've changed my mind about whether it's good to do this. I don't think it's a good idea in this instance to change it to overflow-wrap.
# [16:09] * glazou notes sylvaing is having a beer at the airport while we discuss wrapping !
# [16:10] * Quits: howcome (howcome@193.105.139.140) (Ping timeout)
# [16:10] <tabatkins__> plinss: New people are learnign CSS everyday and not all of them already know this. People in HP get confused regularly.
# [16:10] <tabatkins__> hober: Nobody implements the new name? With the same values? Same behavior? What are we doing here again?
# [16:11] <tabatkins__> TabAtkins_: I agree. It's a bad name, but it's *done*. If we want to *alias* it, that's fine, but we should say that's what we're doing and explain how to alias in the spec.
# [16:12] <tabatkins__> florianr: Agreed. aliasing isn't defined yet, but I have a good model for aliasing defined in Opera.
# [16:13] <tabatkins__> florianr: But the code review for my "alias word-wrap" patch was denied, with them saying I should tell the W3C to not do it.
# [16:14] * sylvaing 'there is a wrap for that'
# [16:14] * Joins: dstorey (Adium@67.180.84.179)
# [16:14] <tabatkins__> dbaron: I think it's potentially harmful to have permanent aliases. Gecko currently has none.
# [16:15] <tabatkins__> TabAtkins_: What are you doing about page-break-* and break-*?
# [16:15] <tabatkins__> dbaron: Not ipmlementing break-* yet. Don't know how we'll deal with that.
# [16:16] <tabatkins__> plinss: Not everyone using CSS already knows CSS. Gotta think about the future as well.
# [16:16] * Joins: ksweeney (ksweeney@63.119.10.10)
# [16:16] * Parts: ksweeney (ksweeney@63.119.10.10)
# [16:16] <tabatkins__> dbaron: When will authors actually prefer to use overflow-wrap against word-wrap?
# [16:16] <tabatkins__> florianr: When you drop prefixes on overflow-wrap.
# [16:17] <tabatkins__> plinss: So the arguments against seem to be the same as the arguments against any change.
# [16:17] <tabatkins__> TabAtkins_: Specifically, the arguments are that the benefit is sufficiently small that it's not balanced against the pain of aliases.
# [16:19] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [16:19] <tabatkins__> dbaron: I'll say that I'm okay with this, but think that if we do more than 3 rename-for-better-reading per decade, we're doing something wrong.
# [16:20] * sylvaing the bartender and I are cheering for dbaron
# [16:20] <tabatkins__> TabAtkins_: I suggest we stick with word-wrap, let the Aliasing spec define the alias, and then let Text pick up the alias next time it's able to rev.
# [16:22] <tabatkins__> RESOLUTION: Change overflow-wrap back to word-wrap. Allow CSS Property Aliasing (future spec) to define that it aliases to overflow-wrap. Next time Text revs, change the property name officially and talk about aliasing.
# [16:22] * sylvaing resolution exploded my head
# [16:23] <tabatkins__> jdaggett: We have another important topic. We've talked about text-transform:full-size-kana for a few f2fs, and we keep going around and around.
# [16:23] * tabatkins__ sylvaing I'ts just "do the rename at a point that wont' slow down Text".
# [16:23] <tabatkins__> florianr: Are you okay with doing @text-transform in level 4 if we drop full-size-kana from level 3?
# [16:23] <tabatkins__> jdaggett: yes.
# [16:24] * sylvaing i know. but it also says 'we had a name, we changed the name, now we're changing it back so we can change it again later'
# [16:24] <tabatkins__> RESOLVED: Drop the full-size-kana value from text-transform in level 3.
# [16:24] * tabatkins__ sylvaing Hah, true.
# [16:24] <tabatkins__> fantasai: One more issue. white-space:nowrap has the least consistent hyphenation in all of CSS.
# [16:24] <tabatkins__> fantasai: Flexbox also has a nowrap value. These *must* be consistent.
# [16:24] * hober sylvaing: there's a meme in there somewhere...
# [16:25] * sylvaing hober, 'a' meme?
# [16:25] * sylvaing this is a month worth
# [16:26] <tabatkins__> fantasai: So Alex and I were going to just make them both "nowrap".
# [16:26] <dbaron> dbaron: There's the problem of authors 3 years in the future trying to remember which is the one that also works in old browsers.
# [16:26] * sylvaing this is Back to the Future, CSS Edition
# [16:27] <tabatkins__> TabAtkins_: The good one will be the new one, and the shitty one will be the interoperable one.
# [16:27] <tabatkins__> [seems to be consensus to not change it]
# [16:28] * sylvaing seconds tab's implicit proposal for the -shitty prefix
# [16:28] <tabatkins__> RESOLUTION: Don't change "nowrap".
# [16:28] <Bert> ('nowrap' is certainly the keyword I can never remember: is it prewrap vs no-wrap or vice-versa?)
# [16:28] <tabatkins__> TabAtkins_: Maybe I can just change "nowrap" in flexbox to "single" like the old flexbox draft.
# [16:29] <tabatkins__> TabAtkins_: I'm renaming everything anyway. By the time I'm done this will be called the Ruby layout draft.
# [16:29] <tabatkins__> fantasai: Another issue. What do you do with ideo spaces at the end of a line, and line-breaking?
# [16:29] <tabatkins__> fantasai: Do they act like U+0020, or what?
# [16:30] <tabatkins__> TabAtkins_: Those aren't collapsed as part of whitespace collapsing?
# [16:30] <tabatkins__> fantasai: No. And the question is what to do at the end of the line.
# [16:30] <tabatkins__> kojiishi: Feedback from Japan is that people liked FF/IE behavior.
# [16:30] <tabatkins__> kojiishi: Some liked the details of FF or IE better, but everyone thought that they were both acceptable, and better than the other browsers.
# [16:30] <tabatkins__> plinss: We're out of time now, unfortunately.
# [16:31] <tabatkins__> kojiishi: There's a mailing-list post in this. We can decide on this later.
# [16:31] <tabatkins__> fantasai: Does either option make the Chinese happy?
# [16:31] <tabatkins__> kojiishi: I think so.
# [16:31] <tabatkins__> szilles: Feedback from Eric was that he didn't make that decision.
# [16:32] <tabatkins__> szilles: This *might* imply that the behavior is language-specific.
# [16:32] <tabatkins__> szilles: He was clear that UAX14 was right.
# [16:32] <tabatkins__> [disagreement on whether UAX14 says that linebreaks are possible between spaces, and what it allows between characters]
# [16:34] <tabatkins__> plinss: Resolutions?
# [16:34] <fantasai> it allows breaks between fixed-width spaces, just not U+0020
# [16:34] <fantasai> and ideographic space is indeed handled as ideographic character
# [16:35] <tabatkins__> [no resolution - koji will propose something soon]
# [16:35] <tabatkins__> Topic: Writing Modes
# [16:35] * dbaron has a few square tuitts, but no round ones
# [16:36] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/200
# [16:37] <tabatkins__> fantasai: Currently only isolate and bidi-override are usable in combination. Someone suggested that they aren't useful except in concert, so we should combine them.
# [16:39] <tabatkins__> glenn: Previous these values were isomorphic tot he unicode control characters.
# [16:39] <tabatkins__> fantasai: They will be again - unicode agreed to add isolation characters. We're just ahead of them.
# [16:40] <tabatkins__> fantasai: Previous we allowed "isolate" in combo with "plaintext", but it turns out we dont' need the ability to turn isolate on/off with plaintext, it should just always be on.
# [16:41] <tabatkins__> dbaron: Every time I look at this, I get confused. That's not a good sign.
# [16:41] <tabatkins__> [discussion about their behavior]
# [16:42] <tabatkins__> fantasai: To be consistent, 2.1 should ahve had "normal | embed | embed-override".
# [16:43] <tabatkins__> [stop talking about the behavior]
# [16:44] <tabatkins__> TabAtkins_: So it seems the current and proposed behavior are functionally equivalent. The *only* thing is that you'll have "isolate-override" instead of "isolate bidi-override".
# [16:45] <tabatkins__> dbaron: yes.
# [16:45] <tabatkins__> fantasai: [explains the values with a chart, to illustrate the axises]
# [16:48] <tabatkins__> szilles: When answering questions like this, I think we should ask what's most useful for the authors.
# [16:49] * Joins: nimbu (Adium@192.150.10.200)
# [16:49] * sylvaing is now known as sylvaing_away
# [16:51] <tabatkins__> fantasai: I think it's easiest to author with them combining.
# [16:52] <tabatkins__> RESOLUTION: Nobody cares too strongly, so fantasai should decide whether to use "isolate bidi-override" or "isolate-override" herself.
# [16:52] <tabatkins__> kojiishi: Another issue - I think we should add an auto value to text-orientation.
# [16:52] <tabatkins__> kojiishi: UAX50 is taking longer than expected - I think another 6 months or more.
# [16:53] * hober thinks it's UTR50, tab
# [16:53] <dbaron> s/UAX50/UTR50/
# [16:54] <tabatkins__> kojiishi: Right now we're in trouble because the behavior isn't defined, but content is depending on some behavior.
# [16:54] <tabatkins__> jdaggett: I don't see the value of having a new value without a definition.
# [16:55] <tabatkins__> TabAtkins_: We don't usually make 'auto' mean "whatever", it means "magic that CSS doesn't control, but which is well-defined".
# [16:55] <tabatkins__> fantasai: I'm not sure adding auto would actually help us here.
# [16:57] <tabatkins__> kojiishi: If we leave it as it is, the world will be UA-dependent anyway.
# [16:59] <tabatkins__> TabAtkins_: Do we expect impls to actually follow the explicit keyword if we add this auto?
# [17:00] <tabatkins__> fantasai: I'm not sure the value is there. If people are authoring to webkit's ipmlementation, they'll expect webkit' implementation.
# [17:00] <dbaron> fantasai: If people are writing content that's just for WebKit's implementation, nothing we do with keywords is going to change that.
# [17:01] <shanestephens> ScribeNick: shanestephens
# [17:01] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [17:01] <shanestephens> fantasai: if WebKit doesn't implement sideways values you can't do explicit orientation control
# [17:02] <shanestephens> koji: japanese vendors of epub readers are using WebKit and writing patches to implement sideways. But having trouble upstreaming to webkit
# [17:03] <shanestephens> jdaggett: so you're relying on the values working the way they are intended to. In webKit they don't.
# [17:03] <shanestephens> jdaggett: if I say upright, I don't always, based on code point and font and other stuff
# [17:03] <shanestephens> koji: upright works for asian users
# [17:04] <shanestephens> jdaggett produces a counterexample
# [17:04] <hober> the bug that jdaggett is talking about: https://bugs.webkit.org/show_bug.cgi?id=86071
# [17:06] <shanestephens> koji: I'm talking about major asian use cases
# [17:07] <shanestephens> koji: as long as you don't use mixed complex path, it just works
# [17:07] <shanestephens> TabAtkins_: This is going to be completely polluted anyway, probably need to make a new property in a few years
# [17:07] <shanestephens> jdaggett: epub is standardizing on a property that is undefined
# [17:08] <shanestephens> discussion about whether this is about ebooks or the web
# [17:08] <shanestephens> TabAtkins_: because utr50 isn't out yet people are just implementing stuff they think is reasonable
# [17:09] <shanestephens> … so if you can't wait for utr50, define something and we'll fix it later
# [17:09] <shanestephens> TabAtkins_: write down a reasonable way of doing thing
# [17:09] <shanestephens> kojiishi: problem is that defining behavior for arabic etc. is not easy
# [17:09] <shanestephens> fantasai: that's fine, just define the bits you need
# [17:09] <shanestephens> TabAtkins_: just give arabic some value, doesn't matter what
# [17:09] * Quits: jdaggett (jdaggett@193.105.139.140) (Quit: jdaggett)
# [17:10] <shanestephens> TabAtkins_: can provide use-good-arabic-vertical-text later
# [17:10] <shanestephens> fantasai: or just swap it in if it's close enough
# [17:10] <shanestephens> …I'll take an action with koji to do that
# [17:10] * Quits: Ms2ger (Ms2ger@91.181.124.114) (Ping timeout)
# [17:10] <shanestephens> jdaggett: I don't get why we can't just wait for utr50
# [17:10] <shanestephens> TabAtkins_: because of polution
# [17:10] <shanestephens> jdaggett: how is that different to what happens elsewhere?
# [17:10] <shanestephens> TabAtkins_: they're not even trying to be similar
# [17:11] <shanestephens> jdaggett: putting in stuff we remove later is busywork
# [17:11] <shanestephens> TabAtkins_: if we leave it then we'll just need to tear the property down because it'll be too inoperable
# [17:12] <shanestephens> jdaggett: I've proposed in the past an @-rule to do this
# [17:12] <shanestephens> kojiishi: I've been saying to make this UA-dependent because that's been happening for 30 years.
# [17:13] <shanestephens> TabAtkins_: jdaggett proposes an extension mechanism so stuff can be defined in the future
# [17:16] <shanestephens> … I want to propose something simple so we have a chance at keeping the keywords
# [17:16] <shanestephens> florian: what's the chance of being able to keep them?
# [17:16] <shanestephens> TabAtkins_: non-zero
# [17:16] <shanestephens> florianr: do you expect implementations do drop their heuristics and adopt your simplified ones?
# [17:17] <shanestephens> TabAtkins_: yes, I would hope that happens
# [17:17] <shanestephens> florianr: and worst case is we waste a bit of time drafting the simplified heuristics
# [17:17] <shanestephens> fantasai: even then our tables will end up being input to the UAX50 process
# [17:18] <shanestephens> jdaggett: I think the UAs will keep doing what they are doing despite what the WG does. Our best hope is for clarity - i.e. "just wait until utr50 is ready"
# [17:18] <shanestephens> jdaggett: if we give them an interim thing then they'll complain when the real standard comes out
# [17:19] <shanestephens> fantasai: the no change situation is that everyone will assume the WebKit behavior is the standard
# [17:19] <shanestephens> jdaggett: there is no standard. Things keep changing from version to version of browser.
# [17:19] <shanestephens> kojiishi: we can't file bugs with out something in the spec
# [17:20] <shanestephens> hober: we can file bugs now - I filed one recently about unexpected behavior
# [17:20] <shanestephens> stevez: that just makes the problem worse because people will think that WebKit is the standard
# [17:21] <shanestephens> TabAtkins_: so the alternatives are: 0% chance of working, will have to burn down the prefixes, vs. people might get upset with multiple updates
# [17:21] <shanestephens> jdaggett: If koji and elika take the tables and put them in the spec, I don't object. I just don't think it will solve anything
# [17:21] <shanestephens> florianr: do you think it can hurt anything?
# [17:22] <shanestephens> jdaggett: if vendors end up looking at it as a solution, it isn't, because there's no consistency between different implementations or versions of the same implementations.
# [17:22] <shanestephens> jdaggett: but I do not think we should be adding values at all
# [17:22] <shanestephens> fantasai: I agree with that
# [17:22] * Quits: nimbu (Adium@192.150.10.200) (Quit: Leaving.)
# [17:23] <shanestephens> RESOLUTION: no UA dependent values for text-orientation, and we'll put our own table of behaviors for mixed-right and upright values in the writing-modes spec
# [17:25] <shanestephens> topic: line layout
# [17:25] <shanestephens> stevez: what I'm setting out to do is determine where the baseline lies in the line
# [17:25] <shanestephens> … need to do that because that's the thing which is a line from the perspective of the linegrid
# [17:25] <shanestephens> … sorry, the dominant baseline
# [17:26] <shanestephens> … there are at least some cases that behave strangely, and I'm trying to understand why
# [17:26] <shanestephens> … I am continuing to work on it, just set up meeting with John to go over stuff by the next meeting
# [17:26] * Joins: dstorey (Adium@67.180.84.179)
# [17:26] <shanestephens> … apologize for not getting as far as I'd hoped, but that's all I wanted to talk about at this meeting
# [17:27] <shanestephens> TabAtkins_: do you think that I need to interact with you wrt changes to flex box for this?
# [17:27] <shanestephens> stevez: yes. I want to have an offline conversation because I'm concerned with the differences between doing stuff in boxes and doing the whole line
# [17:27] <shanestephens> ACTION TabAtkins_ to discuss with stevez about how line layout and line snapping should work in flexbox
# [17:27] * trackbot noticed an ACTION. Trying to create it.
# [17:27] <trackbot> Sorry, couldn't find user - TabAtkins_
# [17:28] * Joins: nimbu (Adium@192.150.10.200)
# [17:28] <shanestephens> ACTION tab to discuss with stevez about how line layout and line snapping should work in flexbox
# [17:28] * trackbot noticed an ACTION. Trying to create it.
# [17:28] <trackbot> Created ACTION-471 - Discuss with stevez about how line layout and line snapping should work in flexbox [on Tab Atkins Jr. - due 2012-05-18].
# [17:28] * Joins: nimbu1 (Adium@192.150.10.200)
# [17:28] * Quits: nimbu (Adium@192.150.10.200) (Connection reset by peer)
# [17:29] <shanestephens> dbaron: you said you were trying to understand why things behave strangely. Was that with respect to existing implementations, or specs?
# [17:29] <shanestephens> stevez: they're behaving differently to how I read the 2.1 spec, but every browser does the same thing
# [17:29] <shanestephens> dbaron: I might be able to help if you want to chat over the next few days and show me exampels
# [17:30] <shanestephens> florianr: I don't think anyone at opera has a clear understanding of our behaviour
# [17:30] <shanestephens> florianr: e.g. we behave differently on japanese and english OSs
# [17:30] <shanestephens> stevez: I'm trying to figure out what are bugs and what are genuinely interoperable behaviour
# [17:31] <shanestephens> ACTION stevez to talk to dbaron about possible reasons for surprising behavior
# [17:31] * trackbot noticed an ACTION. Trying to create it.
# [17:31] <trackbot> Created ACTION-472 - Talk to dbaron about possible reasons for surprising behavior [on Steve Zilles - due 2012-05-18].
# [17:31] <shanestephens> topic: values and units
# [17:31] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
# [17:31] <shanestephens> TabAtkins_: just a few issues to resolve
# [17:32] <shanestephens> … we skipped cycle deferred thing because dbaron proposed some solutions
# [17:32] <shanestephens> … need to look at issue 24, issue 27, issue 16
# [17:32] <fantasai> ACTION fantasai: update v&u with resolutions
# [17:32] * trackbot noticed an ACTION. Trying to create it.
# [17:32] * RRSAgent records action 8
# [17:32] <trackbot> Created ACTION-473 - Update v&u with resolutions [on Elika Etemad - due 2012-05-18].
# [17:33] <shanestephens> TabAtkins_: spec wasn't clear aout what is a number and what is a dimension. We have a very clear definition that hooks into the parser.
# [17:33] <shanestephens> … expect specific tokens after stripping whitespace
# [17:33] <shanestephens> … done that for all the cases. Is this acceptable?
# [17:33] <shanestephens> dbaron: one of the motivations for attr was to be able to represent the default HTML stylesheet using it
# [17:33] <shanestephens> … html has its own set of attribute parsing rules. Are they compatible?
# [17:34] <shanestephens> TabAtkins_: HTML's number parsing is more forgiving that CSS's number parsing. HTML just discards junk after a number, we don't
# [17:34] <shanestephens> fantasai: another case is color.
# [17:34] <shanestephens> dbaron: how much is it a goal for attr to be able to do that?
# [17:35] <shanestephens> TabAtkins_: it is theoretically, but not as an actual goal to put it in the UA style sheet
# [17:35] <shanestephens> dbaron: sounds OK with me, though we may at some point want to add additional variant types to support HTML values. Could be proprietary
# [17:35] <shanestephens> TabAtkins_: I think that's acceptable.
# [17:35] <shanestephens> fantasai: might even be able to tweak the parsing rules later.
# [17:36] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [17:36] <shanestephens> … no-one will rely on something not parsing
# [17:36] <shanestephens> TabAtkins_: wouldn't be surprised if they didn't notice when something didn't apply
# [17:36] <shanestephens> … and then stuff would turn on when we changed behavior
# [17:36] <shanestephens> fantasai: I don't' think may people will be using attr by then
# [17:37] <shanestephens> TabAtkins_: I would object to making the color type parse like HTML
# [17:37] * Quits: tantek (tantek@50.1.62.23) (Quit: tantek)
# [17:37] <shanestephens> … HTML color isn't a superset of CSS color
# [17:37] <shanestephens> dbaron: could have html-color in the future if needed
# [17:38] <shanestephens> Bert: so HTML color isn't a superset of CSS color?
# [17:38] <shanestephens> dbaron: no, for legacy reasons. HTML color accepts any keywords and looks for hex digits within that
# [17:38] <shanestephens> Bert: so what appears as an output?
# [17:38] <shanestephens> fantasai: it's exactly the string that was provided
# [17:39] <shanestephens> … this isn't the parsing part, but the part that turns it into a color
# [17:39] <dbaron> <body bgcolor="lightgoldenrod"> is interoperably light blue
# [17:39] <shanestephens> TabAtkins_: so we're suggesting no change to text->info set, but a change to infoset->value
# [17:40] <shanestephens> TabAtkins_: the HTML parser actually parses valid CSS as a completely different color
# [17:40] <shanestephens> … I don't want to have different results pulling values in from an attr e.g. for hsl
# [17:40] <shanestephens> Bert: you will anyway, I don't see a problem with it
# [17:41] <shanestephens> TabAtkins_: yes but that's for legacy reasons. I don't think you understand how horrible the HTML rules are.
# [17:41] <shanestephens> Bert: I don't care how weird they are, I think we should treat strings from attr with our rules
# [17:41] <shanestephens> TabAtkins_: that's what we're suggesting
# [17:42] <shanestephens> Bert: so no attr in UA stylesheet?
# [17:42] <shanestephens> TabAtkins_: correct
# [17:42] <shanestephens> RESOLVED: Close issue 24 with no change
# [17:42] <shanestephens> fantasai: next issue is 27.
# [17:42] <shanestephens> … suggestion to have order-sensitive "one or more, in order" combinator
# [17:43] <shanestephens> … can have this? that? both are optional, but could be empty. But can't have "this | that | this that" without writing it out in full
# [17:43] <shanestephens> … we have this || that, which means "this | that | this that | that this"
# [17:43] <shanestephens> … suggestion to have a version of this with an order that matters
# [17:44] <shanestephens> … suggestions on the list: use a triple bar, use double question marks
# [17:44] <shanestephens> … do we want to have this and if so what should the syntax be?
# [17:44] <shanestephens> dbaron: I think we should be hesitant to add new syntax to our grammar lines. It's more stuff for people to learn to be able to read our spec
# [17:44] <shanestephens> fantasai: but it's also hard to read when grammar lines get really long
# [17:44] <shanestephens> dbaron: I also think that ?? is a disaster
# [17:45] <shanestephens> … do we want to use this syntax? Seems like it's not one to encourage.
# [17:45] <shanestephens> TabAtkins_: it already exists in a few places, e.g. radial gradients.
# [17:45] <shanestephens> fantasai: and border-image
# [17:45] <shanestephens> dbaron: it's also going to be hard to read with a symbol that people don't know
# [17:45] <shanestephens> stevez: is * in the grammar?
# [17:45] <shanestephens> fantasai: yep
# [17:46] <shanestephens> stevez: if you use the double bar but add a character to the double bar that says "in this usage the order matters"
# [17:46] <shanestephens> arno: how about |&|
# [17:46] <shanestephens> (people don't like)
# [17:47] <shanestephens> TabAtkins_: if we can't agree on specific syntax right now it's not a problem
# [17:47] <shanestephens> Liam: I like the old version
# [17:47] <shanestephens> Bert: me too.
# [17:47] <shanestephens> Liam: break out long phrases into secondary rules
# [17:47] <shanestephens> TabAtkins_: we don't like doing that because it makes things harder to read
# [17:48] <shanestephens> Liam: yeah but it is harder to read anyway. I'd rather do that instead of introducing new syntax
# [17:48] <shanestephens> fantasai: how about &|
# [17:48] <shanestephens> TabAtkins_: oooooh, I liiiike that
# [17:48] <shanestephens> florianr: not sure it's immediately obvious, but it's easy to remember
# [17:49] <shanestephens> hober: and it kinda maps back to order (and-or)
# [17:49] <shanestephens> stevez: and usually means without order
# [17:49] <shanestephens> dbaron: difficult to know difference between this and &&. && is an 'and' without ordering constraint, this has ordering constraint
# [17:49] <shanestephens> TabAtkins_: maybe we should fix &&
# [17:49] <shanestephens> stevez: What about ||>
# [17:50] <shanestephens> … this conveys the ordering
# [17:50] <shanestephens> TabAtkins_: I think we should defer and keep thinking about this
# [17:50] <shanestephens> fantasai: it's an editorial change so we could splice it in during CR
# [17:50] <shanestephens> RESOLVED: defer issue 27
# [17:51] <shanestephens> TabAtkins_: next issue is 16. This is based on 12-15, which are deferred.
# [17:51] <shanestephens> dbaron: I think 12-14 are easy to resolve: 12 - you can't do that, 13 - reject proposal, 14 - fix sheet
# [17:52] <shanestephens> TabAtkins_: let's look at 15.
# [17:52] <shanestephens> … problem is cycle relies on comparing computed value with each value of cycle, which is new
# [17:52] <shanestephens> dbaron: this is a comparison of computed values. Transitions start when a computed value changes. So transitions depend on knowing that 2 computed values are different
# [17:53] <shanestephens> TabAtkins_: that shouldn't be a problem. The issue isn't about that, but about whether top left is the same as left top when cycling background position. Answer is for computed values: yes
# [17:53] <shanestephens> TabAtkins_: so should we just say "like transitions", or define this more carefully
# [17:54] <shanestephens> dbaron: the computed value line in our specs defines an information set - a set of concepts that the computed values can take
# [17:54] <shanestephens> TabAtkins_: so is transitions under defined?
# [17:54] <shanestephens> dbaron: I think it is, but it's not that hard to define
# [17:54] <shanestephens> … here and there there's probably a computed value line in a spec that isn't very clear, but the underlying definition is those lines
# [17:55] <shanestephens> TabAtkins_: so for now we can just explicitly say we're comparing computed values and get implementors to tell us if they're ever confused so we can fix that in the spec
# [17:56] <shanestephens> plinss: I think if there's 2 specs that talk about comparing computed values, and one references the other, which doesn't define that, this is bad
# [17:56] <shanestephens> dbaron: also, a definition should be in V&U, not transitions
# [17:57] <shanestephens> fantasai: what more do we need over "compare computed values"?
# [17:57] <shanestephens> dbaron: some kind of statement about what a computed value is
# [17:57] <shanestephens> plinss: there's lots to define there, e.g. is 72 points == 1 inc?
# [17:57] <shanestephens> fantasai: yes, because they get converted to absolute values
# [17:57] <shanestephens> plinss: that should be explicit
# [17:58] <shanestephens> dbaron: it is. It's more things like pairs of values
# [17:58] <shanestephens> fantasai: we need to go and fix the computed values lines to not imply an order
# [17:58] <shanestephens> TabAtkins_: that's not a problem because they'll still compute to the same thing for comparison
# [17:59] <shanestephens> dbaron: e.g. flex before it was a shorthand took 3 values in any order. It's computed value is the combination of the 3 values, not ??
# [17:59] <shanestephens> TabAtkins_: so I want to say just simply compare computed values, with a note that gets developers to come to us if they think something's weird
# [17:59] <shanestephens> fantasai: yes, just a note that says these are abstract things, not strings
# [18:00] <shanestephens> dbaron: have to be careful about computed values with optional parts. Is the presence of the optional part substantive, or can it be replaced by its default if the optional part isn't present?
# [18:00] <shanestephens> … that text could be in values spec
# [18:00] <shanestephens> fantasai: I have a question about the example on screen
# [18:01] <shanestephens> … is it valid?
# [18:01] * plinss does it blend?
# [18:02] <shanestephens> dbaron: could have designed this to work differently, but it's complicated because having a list marker is defined by a pair of properties
# [18:02] <dbaron> li > ul should be li ul
# [18:02] <shanestephens> fantasai: I want to make sure we get this right before we put it in the spec?
# [18:03] <dbaron> (display: list-item and list-style-type)
# [18:03] <shanestephens> fantasai: are we sure we want a descendant selector here, or should we find some way to work around it?
# [18:04] <shanestephens> TabAtkins_: I think it's acceptably bad. Would love not to have descendant selectors in UA stylesheets, but...
# [18:04] <shanestephens> fantasai: there's other approaches, do we want to look at those?
# [18:04] <shanestephens> TabAtkins_: not at this level
# [18:04] <shanestephens> fantasai: are we looking at stuff for the future?
# [18:04] * Joins: dstorey (Adium@144.189.101.1)
# [18:04] <shanestephens> dbaron: we might need a new function
# [18:05] <shanestephens> TabAtkins_: e.g. a function like cycle that takes several values, but first takes an identifier that gets resolved on the first use
# [18:05] <shanestephens> dbaron: this breaks the em use case
# [18:06] <shanestephens> TabAtkins_: yes. But I think cycle is a better name for that functionality and we should call the current functionality toggle, because a lot of the common cases will just be switching between 2 values anyway
# [18:06] <shanestephens> … if we want to keep this open I'd prefer that rename
# [18:07] <shanestephens> dbaron: I'm fine with that
# [18:07] <shanestephens> florianr: not constrained by existing implementations
# [18:07] <shanestephens> RESOLVED: rename cycle to toggle, leave it as is
# [18:08] <shanestephens> RESOLVED: issue 12: disallow values with commas at this level
# [18:08] <shanestephens> RESOLVED: issue 13: won't fix
# [18:08] <dbaron> ... except we're renaming to toggle() because of it
# [18:08] <shanestephens> RESOLVED: issue 14: we will fix the UA stylesheet
# [18:09] <shanestephens> RESOLVED: issue 15: add a note to define computed style comparisons better
# [18:09] <shanestephens> RESOLVED: issue 16: reject
# [18:10] <shanestephens> TabAtkins_: so we're at 0 issues before LC. When should we do CR?
# [18:10] <shanestephens> fantasai: I think we should get the edits out and let people review
# [18:10] <shanestephens> TabAtkins_: we'll be asking for CR next time we meet then
# [18:11] <shanestephens> plinss: meeting adjourned
# [18:11] * Quits: glazou (glazou@193.105.139.140) (Quit: glazou)
# [18:12] * Quits: jet (jet@193.105.139.140) (Quit: jet)
# [18:12] <tabatkins__> New UA stylesheet for ul: "ul { list-style-type: disc; } ol ul, ul ul /* and the other legacy lists that you need to list here */ { list-style-type: toggle(disc, square, circle); }"
# [18:15] * Quits: florianr (florianr@193.105.139.140) (Ping timeout)
# [18:15] * Quits: kojiishi (kojiishi@193.105.139.140) (Ping timeout)
# [18:15] * Quits: shanestephens (shanesteph@193.105.139.140) (Quit: shanestephens)
# [18:16] * Joins: shanestephens (shanesteph@193.105.139.140)
# [18:19] * Quits: shanestephens (shanesteph@193.105.139.140) (Quit: shanestephens)
# [18:23] * Quits: vhardy__ (vhardy@193.105.139.140) (Quit: vhardy__)
# [18:24] * Joins: vhardy_ (vhardy@193.105.139.140)
# [18:25] * Quits: vhardy_ (vhardy@193.105.139.140) (Quit: vhardy_)
# [18:31] * Quits: krit (krit@192.150.10.201) (Connection reset by peer)
# [18:33] * Quits: dbaron (dbaron@193.105.139.140) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:33] * plinss is now known as plinss_away
# [18:34] * Quits: glenn (gadams@193.105.139.140) (Client exited)
# [18:36] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [18:37] * Joins: dstorey (Adium@144.189.101.1)
# [18:38] * Quits: tabatkins__ (qw3birc@128.30.52.28) (Ping timeout)
# [18:38] * Quits: Liam (liam@128.30.52.169) (Ping timeout)
# [18:40] * Quits: arno (arno@193.105.139.140) (Quit: Leaving.)
# [19:06] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
# [19:11] * Quits: myakura (myakura@221.171.5.98) (Client exited)
# [19:25] * Joins: vhardy_ (vhardy@88.71.76.2)
# [19:26] * plinss_away is now known as plinss
# [19:27] * Quits: arronei (arronei@131.107.192.154) (Quit: arronei)
# [19:28] * Quits: vhardy_ (vhardy@88.71.76.2) (Quit: vhardy_)
# [19:29] * Joins: arronei (arronei@131.107.192.154)
# [19:29] * Joins: Liam (liam@128.30.52.169)
# [19:53] * Quits: Liam (liam@128.30.52.169) (Ping timeout)
# [20:06] * Quits: arronei (arronei@131.107.192.154) (Quit: arronei)
# [20:09] * plinss is now known as plinss_away
# [20:11] * Joins: drublic (drublic@95.115.33.69)
# [20:42] * Joins: tantek (tantek@159.63.23.38)
# [20:50] * Joins: arronei (arronei@131.107.192.154)
# [21:10] * Quits: nimbu1 (Adium@192.150.10.200) (Quit: Leaving.)
# [21:18] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [21:39] * Joins: dstorey (Adium@144.189.101.1)
# [21:44] * Joins: nimbu (Adium@192.150.10.200)
# [22:05] * Joins: danielfilho (danielfilh@187.31.77.7)
# [22:45] * Quits: alexmog2 (qw3birc@128.30.52.28) (Ping timeout)
# [22:48] * Quits: drublic (drublic@95.115.33.69) (Client exited)
# [23:05] * plinss_away is now known as plinss
# [23:08] * Joins: vhardy_ (vhardy@88.71.76.2)
# [23:21] * Joins: arno (arno@85.182.252.4)
# [23:21] * Joins: Ms2ger (Ms2ger@91.181.124.114)
# [23:22] * Joins: glenn (gadams@88.71.76.2)
# [23:26] * Quits: vhardy_ (vhardy@88.71.76.2) (Quit: vhardy_)
# [23:34] * Joins: kojiishi (kojiishi@91.62.77.116)
# [23:52] * Quits: arno (arno@85.182.252.4) (Ping timeout)
# [23:53] * Quits: Ms2ger (Ms2ger@91.181.124.114) (Ping timeout)
# [23:58] * Joins: arno (arno@85.182.252.4)
# Session Close: Sat May 12 00:00:00 2012

The end :)