/irc-logs / w3c / #css / 2011-10-30 / end

Options:

# Session Start: Sun Oct 30 00:00:00 2011
# Session Ident: #css
# [01:00] <dbaron> hmmm, so there aren't any arrival times on the wiki, so I have no idea who might be around for dinner
# [01:04] * Joins: huddler ([email protected])
# [01:06] * Parts: huddler ([email protected])
# [01:22] * Joins: arno ([email protected])
# [01:26] * Quits: arno ([email protected]) (Quit: Leaving.)
# [01:26] * Joins: cornelius ([email protected])
# [01:27] * Quits: cornelius ([email protected]) (Quit: http://www.mibbit.com ajax IRC Client)
# [01:29] * Joins: bletch ([email protected])
# [01:29] * Joins: mr_sticky ([email protected])
# [01:32] * Joins: likinit ([email protected])
# [01:39] <likinit> ?
# [01:44] * Quits: likinit ([email protected]) (Quit: http://www.mibbit.com ajax IRC Client)
# [01:47] * Quits: bletch ([email protected]) (Quit: http://www.mibbit.com ajax IRC Client)
# [01:47] * Quits: mr_sticky ([email protected]) (Quit: http://www.mibbit.com ajax IRC Client)
# [02:02] * fantasai is around
# [02:25] * Joins: arronei ([email protected])
# [02:25] * Quits: arronei_ ([email protected]) (Ping timeout)
# [02:29] <dbaron> fantasai, anyway, I think I'm just going to eat here rather than try to chase people down
# [02:29] <fantasai> ok
# [02:30] <fantasai> if you like I can go try to chase people down for you at the Mariott :)
# [02:30] <fantasai> They're probably all there.
# [02:30] * fantasai is getting grumpy and probably should eat something too
# [02:33] <dbaron> fantasai, anyway, I think I should just stay here and get some work done
# [02:33] <dbaron> dinner first, though
# [02:33] * Quits: dbaron ([email protected]) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:42] * fantasai found ppl randomly having foos at the bar, not really an organized dinner
# [04:19] * Joins: dbaron ([email protected])
# [05:40] * Joins: plinss ([email protected])
# [05:47] * Quits: dbaron ([email protected]) (Ping timeout)
# [05:56] * Joins: arno ([email protected])
# [06:10] * Joins: arronei_ ([email protected])
# [06:11] * Quits: arronei_ ([email protected]) (Quit: arronei_)
# [06:11] * Joins: arronei_ ([email protected])
# [06:12] * Joins: dbaron ([email protected])
# [06:12] * Quits: dbaron ([email protected]) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [06:14] * Quits: arronei_ ([email protected]) (Ping timeout)
# [06:28] * Quits: arno ([email protected]) (Quit: Leaving.)
# [06:47] <fantasai> hm, clearly typing on the phone sucks
# [06:47] <fantasai> s/foos/food/
# [07:06] * Joins: dodo ([email protected])
# [07:07] * Quits: dodo ([email protected]) (Quit: http://www.mibbit.com ajax IRC Client)
# [07:10] * Quits: stearns ([email protected]) (Quit: stearns)
# [07:50] * Quits: anne ([email protected]) (Client exited)
# [07:58] * Joins: anne ([email protected])
# [08:00] * Quits: anne ([email protected]) (Quit: anne)
# [08:24] * Joins: Ms2ger ([email protected])
# [09:21] * Quits: plinss ([email protected]) (Quit: plinss)
# [12:12] * Quits: jdaggett ([email protected]) (Ping timeout)
# [12:20] * Joins: jdaggett ([email protected])
# [14:17] * Joins: casper ([email protected])
# [14:18] * Parts: casper ([email protected])
# [16:03] * Joins: arronei_ ([email protected])
# [16:39] * Quits: arronei_ ([email protected]) (Ping timeout)
# [16:54] * Joins: TabAtkins_ ([email protected])
# [16:56] * Joins: arno ([email protected])
# [17:13] * Joins: plinss ([email protected])
# [17:13] * Joins: dbaron ([email protected])
# [17:15] <arno> ping
# [17:15] <Ms2ger> Pong?
# [17:15] <arno> Whoo-hoo
# [17:15] * Joins: sylvaing ([email protected])
# [17:16] * Joins: JohnJansen ([email protected])
# [17:16] <arno> ScribeNick arno
# [17:16] * Joins: stearns ([email protected])
# [17:16] * Joins: RRSAgent ([email protected])
# [17:16] <RRSAgent> logging to http://www.w3.org/2011/10/30-css-irc
# [17:16] * Joins: szilles ([email protected])
# [17:16] * Joins: Zakim ([email protected])
# [17:16] <Ms2ger> ScribeNick arno
# [17:16] * Quits: TabAtkins_ ([email protected]) (Quit: leaving)
# [17:17] * Joins: TabAtkins_ ([email protected])
# [17:17] * Joins: glazou ([email protected])
# [17:17] <Ms2ger> RRSAgent, make logs public
# [17:17] <RRSAgent> I have made the request, Ms2ger
# [17:18] <arno> vincent: 3d interest group requested to meet w/ us
# [17:18] <arno> not on the agenda?
# [17:18] <Bert> The snow in the NE has made one victim: Florian not sure he can make today (see e-mail I just forwarded)
# [17:18] <arno> :(
# [17:18] * Joins: mollydotcom ([email protected])
# [17:18] <arno> Daniel: will add to agenda for Tuesday morning
# [17:19] * Joins: vhardy ([email protected])
# [17:19] <arno> Tab: variables and hierarchy
# [17:19] <arno> (nesting selectors)
# [17:19] * Joins: arronei_ ([email protected])
# [17:19] <arno> Tab: I have a proposed spec and would like sign off on "yes, we're going to do these"
# [17:20] <arno> Tab: asking on behalf of shane and luke.
# [17:20] <arno> Daniel: adding to agenda, but gut feeling: "you are going too fast"
# [17:20] * Joins: shepazu ([email protected])
# [17:20] * Joins: kojiishi ([email protected])
# [17:20] * Joins: jarek ([email protected])
# [17:21] <arno> Peter: I have a joint meeting w/ web apps at 11am
# [17:22] <arno> ??: discussion on CSS OM on tuesday morning would require david and tab, will they be there?
# [17:22] <arno> tab: yes, there's a conflict w/ a fx meeting
# [17:22] <arno> peter: no, fx meeting is on thursday
# [17:22] <arno> daniel: please update wiki accordingly
# [17:23] <arno> daniel: I did the schedule based on interest and joint meetings, it wasn't an easy task.
# [17:23] <arno> daniel: any other extra items?
# [17:23] <arno> everyone: no.
# [17:23] * Joins: jdaggett_ ([email protected])
# [17:23] <dbaron> Should we do a brief round of introductions?
# [17:23] <arno> daniel: first, a request from sylvain: "how should wg handle issues?"
# [17:24] * Joins: Rossen ([email protected])
# [17:24] <arno> daniel: yes, let's start with intros
# [17:25] <dbaron> Luke McPherson (Google), Shane Stevens (Google), Steve Zilles (Adobe), Molly Holzschlag (Invited Expert), Mark Silverman (Adobe), Deepa Subramanian (Adobe), Bert Bos (W3C), Alan Stearns (Adobe), Arno Gourdol (Adobe), Brad Kemper (Invited Expert), Tab Atkins (Google), Elika Etemad (Mozilla), Daniel Glazman (Disruptive Innovations), Koji Ishii (Invited Expert), John Daggett (Mozilla)
# [17:27] <dbaron> David Baron (Mozilla), Arron Eicholz (Microsoft), Sylvain Galineau (Microsoft), John Jansen (Microsoft), Håkon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)
# [17:27] <dbaron> (hopefully I kept to under 10 spelling mistakes)
# [17:27] <arno> daniel: back to first issue
# [17:27] * Joins: ChrisL ([email protected])
# [17:27] <arno> sylvain: we implement a spectrum of specs at different levels
# [17:27] * Joins: shans ([email protected])
# [17:27] <arno> sylvain: when something is not Last Call, questions get asked
# [17:27] <sylvaing> # [17:28] <arno> the question above was asked, but not answered
# [17:28] <arno> "how much normative info is laying around in the mailing list that's not incorporated"
# [17:28] <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dEdQMEtSMXFFMWJyYkVpdUtrWDB4Z3c&hl=en_US#gid=1
# [17:28] <arno> sylvain: I replied "I don't know" and people freaked out.. :)
# [17:29] <arno> sylvain: did an analysis of discussion threads, and it turns out that many did not got concluded and getting it back into the spec
# [17:29] <arno> sylvain: we did that with css 2.1 where fantasai went through 10 years of archives to make sure that everything was taken into account
# [17:30] <arno> sylvain: we shouldn't have to do this. we should have a better organized way of tracking issues.
# [17:30] <arno> dagett: we already have a tracker, no?
# [17:30] * Quits: TabAtkins_ ([email protected]) (Ping timeout)
# [17:30] <arno> fantasai: but the editor does not keep up with the feedback
# [17:30] * Joins: TabAtkins_ ([email protected])
# [17:31] <arno> sylvain: difficult to resolve differences between implementations...
# [17:31] * ChrisL saw dino yesterday, wonders whether he will be here later
# [17:31] <arno> sylvain: when we get to module, we should have a link of issues
# [17:31] <fantasai> dbaron: Of all the specs I've implemented, CSS Animations has been in the worst state
# [17:31] <arno> vincent: would be nice to have one common way. i liked the suggestion to have an annotation in the spec that incorporates a link to the wiki
# [17:32] <arno> vincent: not a big fan of the wiki because it's a bit too fragile, would like better method
# [17:32] <arno> daniel: it's a human process, the editor still has to do the right thing
# [17:32] <arno> fantasai: we have multiple ways
# [17:32] <dbaron> (I think there are also a bunch of animations issue that I didn't even bother to bring up on the mailing list.)
# [17:33] * Joins: bradk ([email protected])
# [17:33] <arno> fantasai: different editors like different systems
# [17:33] <arno> fantasai: i use to track issues in a plain text file, and that worked great for me
# [17:33] <arno> vincent: i like steve's suggestion to incorporate it in the spec, because as you read the spec you can see where there are issues
# [17:34] <arno> howcome: i think email works pretty well
# [17:34] <fantasai> fantasai: The problem is that if the editor is not tracking issues, the issues aren't being tracked. Period.
# [17:34] <arno> sylvain: when it come to disposition of comments, you shouldn't have to go through email archives
# [17:34] * Quits: szilles ([email protected]) (Ping timeout)
# [17:35] <arno> howcome: it's not a lack of mechanical solution, the problem is the editor needs to do the tracking
# [17:35] <arno> dbaron: i like the idea of having it in the spec
# [17:35] <fantasai> dbaron: Not nessarily as the only place to track it but as a place to track it
# [17:35] <arno> dbaron: but that doesn't mean there shouldn't be some other way of tracking it
# [17:36] <arno> steve: we may need a mechanism to collect in a list all the issues and what their status is, and we need a way to track what the issue actually is (email, etc.. anything with a URL)
# [17:36] <fantasai> Steve: First issue I see is showing in the spec, at that place, that there is an issue there. Second we need some place that collects all the issues and tells you the status of the issues. Third is we need a way to document what the issue actually is
# [17:37] <arno> steve: putting open issues in the document is pretty important, as it allows people to do something about it. but we probably to have somewhere else also to keep track of all issues
# [17:38] <arno> chris: it's useful to be able to track issues over a long period of time, with a tracker or something else
# [17:38] <arno> jdaggett: we don't need to track all issues, especially at the very beginning of a spec, but bug tracking does make sense when you get to the end
# [17:38] <fantasai> jdaggett++
# [17:38] <arno> fantasai: i agree with this, that's what i've done
# [17:39] <arno> fantasai: but the editor still needs to response to feedback. if it doesn't happen, it doesn't matter what tracking system we have
# [17:40] <arno> fantasai: specs currently don't link to issues
# [17:40] <arno> (in general, a few do)
# [17:41] <arno> fantasai: it's unfair to expect that others will do the work of identifying issues that need to be tracked
# [17:41] * Quits: jarek ([email protected]) (Quit: jarek)
# [17:41] <JohnJansen> note: this is not just a problem with one spec, but is a more general issue
# [17:41] <arno> daggett: how to we deal w/ feature request which the editor think should be dealt with later?
# [17:41] <arno> fantasai: i dump it into tracker
# [17:41] <arno> alan: there's also some wiki pages that include level 4 ideas
# [17:42] <arno> tantek: i like wiki pages better, because it's easier to aggregate requests together, "since the future is fuzzier, a fuzzier mechanism helps"
# [17:42] * Joins: tantek ([email protected])
# [17:42] <arno> daniel: any concrete proposal?
# [17:42] <tantek> is this on? 1 10 11 check
# [17:43] <arno> sylvain: when dino is around we should discuss w/ him
# [17:43] <Ms2ger> tantek, it is :)
# [17:43] <arno> tab: should we introduce an issue tracker so that if you file an issue via email you also have to file it into the tracker?
# [17:44] <arno> tantek: it depends on where you constraint is. If it's editor's time, that's going to be the bottleneck
# [17:44] <Ms2ger> Might as well go to filing directly in bugzilla, then
# [17:44] <arno> dbaron: if there are multiple requirements to track issues (tracker, email, bugzilla, etc…) some people might use the wrong mechanism and issues may end up dropped on the floor
# [17:45] <arno> tantek: it's already in the spec: send a message to wwwstyle
# [17:45] <JohnJansen> ms2ger, the argument against that is that when a spec is young, bugzilla is too much overhead
# [17:45] <arno> tantek: i think it's up to the editor to track the messages to wwwstyle and track it
# [17:46] * Ms2ger doesn't care much about young specs
# [17:46] <arno> tantek: however the editor track the issue, it should be public and others should be able to add issues
# [17:46] <arno> moly: what about using some tools like stackoverflow, etc… to track?
# [17:47] <arno> tantek: there's only a handful of mechanism other than bugzilla, tracker, wiki
# [17:47] <arno> fantasai: i've used CVS/plaintext
# [17:47] <arno> tantek: someone could add to it?
# [17:47] <arno> fantasai: yes, a bit more cumbersome, though
# [17:47] <arno> chris: as long as it's publicly available
# [17:48] <arno> fantasai: yes, a local text file, spreadsheet, etc… would not work
# [17:48] <glazou> s/moly/molly
# [17:48] <arno> molly: each editor has process, but we need to communicate where the info is. the disparate methodology is creating a disparate problem in which we're not able to have this coalesced
# [17:49] <tantek> molly is talking about a discovery problem ("where are the issues?") rather than a diversity of mechanisms problem.
# [17:49] <tantek> what Steve Zilles said
# [17:49] <arno> steve: as part of the status section of a spec, we should include where the issues are being tracked, so that you can know where the editor tracks issues
# [17:49] <tantek> one single place to track where the issues are, not one single issue tracker
# [17:49] <arno> steve: i.e. that's a per spec issue, not an issue for all specs, right?
# [17:50] <arno> steve: i propose we have, for each spec, a clear indication of where the issues are tracked
# [17:50] <tantek> fantasai - you said there are some specs that have links from their header to their issues?
# [17:50] <tantek> examples?
# [17:50] <Ms2ger> HTML has that
# [17:50] <tantek> i.e.. which spec(s)
# [17:50] <fantasai> tantek, # [17:51] <dbaron> For # [17:51] <arno> steve: if there's a clear list of issues, people could find out what the status is and have the group (or the chair) do the policing if necessary
# [17:51] <tantek> so none of those have links from the header
# [17:52] <tantek> proposal: just as each spec must have a link to the editor's draft, right underneath that, it should link to where it tracks issues
# [17:52] <arno> fantasai: so, each spec must have a clear, publicly accessible way of tracking issues
# [17:52] <arno> fantasai: each module
# [17:52] <Ms2ger> And note that nobody reads the SotD :)
# [17:52] <fantasai> RESOLVED: Each module must have one publicly-accessible, CSSWG-editable way of tracking issues.
# [17:53] <sylvaing> # [17:53] <arno> tantek: the examples above are burried in the spec
# [17:54] <fantasai> RESOLVED: Add link to issues list from spec header
# [17:54] <arno> daniel: who's in favor of the RESOLVED issue above
# [17:54] <arno> ?
# [17:54] <arno> daniel: (from show of hands): OK, resolved
# [17:55] <arno> daniel: i'm not satisfied with a different system for each spec
# [17:55] <arno> daniel: you have to adapt yourself for each one, and it's difficult when you're tracking 30 specs
# [17:55] <arno> steve: building o the idea that there are 4 systems in use right now, could we restrict the list of acceptable issue tracking system
# [17:55] <arno> daniel: that's a good compromise
# [17:56] <arno> steve: we have 3: wiki, tracker and bugzill
# [17:56] <Ms2ger> And plaintext in CVS
# [17:56] <arno> dbaron: and there's another one: track everything in the draft
# [17:57] <arno> alan/tantek: do you keep a log of the resolved issues
# [17:57] <arno> dbaron: no, the CVS log is the log...
# [17:57] <arno> daniel: <squirms>
# [17:57] <arno> tantek: so you're saying that twitter is the log, then...
# [17:58] <tantek> here's an example of a spec which has links in the header to both editor's draft and issues list: # [17:58] <arno> tab: i use the same system as david, and it works for me
# [17:58] <arno> alexm: with multiple editors it can get complicated
# [17:58] <arno> fantasai: i use different systems, depending on the lifecycle of the spec.
# [17:59] <arno> fantasai: when we need to resolve a bunch of issues as a group, i make a list and use it in tracker for easier resolution
# [17:59] * Quits: plinss ([email protected]) (Client exited)
# [17:59] * Joins: plinss ([email protected])
# [17:59] <arno> fantasai: at the end, i use a plaintext file
# [17:59] <arno> daniel: let's close on steve's proposal
# [18:00] <tantek> I use the wiki to track issues, and have been putting links from the document like: "Related open issue: 1. " (where "1." is hyperlinked to the issue)
# [18:00] <arno> daniel: when using inline issue tracking, still indicate that in the header
# [18:00] * Joins: plinss__ ([email protected])
# [18:01] <arno> fantasai: we have the WD and the Editor's draft.
# [18:01] <arno> fantasai: they may have separate issues list
# [18:01] <arno> vincent: the current list of issues is related to the ED, not the WD
# [18:02] <arno> fantasai: it's snapshotted if you track it inline, but otherwise the link to a separate issue tracker may get out of sync
# [18:02] <arno> fantasai: maybe only have the link on the ED
# [18:03] <arno> steve: no, too many people get to the WD than the ED, and then you will end up in the wrong issue list
# [18:03] <arno> molly: agree, we need to coalesce, rather than fragment
# [18:03] * Quits: plinss ([email protected]) (Ping timeout)
# [18:03] * plinss__ is now known as plinss
# [18:03] <arno> vincent: if you do inline issue tracking, that resolves it
# [18:04] <arno> fantasai: could be resolved if the link to issues in the WD point to the ED issues list
# [18:04] * Joins: alexmog ([email protected])
# [18:05] <arno> molly: the ED is the up to date version of issues are tracked. so we could just have a link that points to the ED to find out what the current issues are
# [18:06] <arno> tantek: maybe we need a warning in the WD that makes it clear it's out of date...
# [18:06] <arno> chris: when it's published as a TR it should not include the list of issues anymore
# [18:06] <Ms2ger> Why not?
# [18:07] * Parts: alexmog ([email protected])
# [18:07] <arno> daniel: a TR has a date, so having issues there would be appropriate to reflect what the issues were for *that* version of the document
# [18:07] <arno> daniel: i don't know how to tweet this
# [18:08] <ChrisL> @ms2ger I was arguing against a static,out of date copy of the state of issues in a /TR published draft, if the editors draft has a more up to date list
# [18:08] <arno> daniel: issue trackers used: bugzilla, wiki, tracker, inline
# [18:09] <arno> RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.
# [18:09] <arno> fantasai: it was really hard with CSS 2.1
# [18:09] <arno> tantek: let's not have big specs like that anymore
# [18:09] <tantek> :)
# [18:10] * Joins: alexmog- ([email protected])
# [18:10] <arno> fantasai: how do we track 300 issues on one wiki page? doesn't seem to scale
# [18:10] <tantek> we can cross that bridge when we reach it
# [18:11] <arno> johnjansen: that's why i like bugzilla better to do the tracking
# [18:11] <arno> vincent: maybe it depends on the lifecycle, later on in the spec's life, using bugzilla may be better
# [18:12] <arno> fantasai: not asking for a WG resolution, but sharing my experience
# [18:13] <arno> steve: we have these discussions where we agree on a particular strategy, recorded in the minute, and then it slowly gets out of memory as time goes on
# [18:13] <arno> steve: could we have this recorded in the wiki or somewhere
# [18:13] <arno> daniel: i agree that best practices are needed
# [18:13] <tantek> here: http://wiki.csswg.org/spec#specification-editing
# [18:13] <arno> daniel: what should happen if an editor doesn't track issues?
# [18:13] <arno> daniel: spanking the editor?
# [18:14] <arno> steve: the chair has multiple paths: talk to the editor, talk to the AC rep, raise it to the group and replace the editor
# [18:14] <arno> tantek: after step 1 (talking to the editor), you could also suggest adding a co-editor
# [18:15] <arno> tantek: or even assign a co-editor
# [18:15] <arno> tantek: that's worked in the past
# [18:15] <arno> daniel: you need to know there's an issue with the issue tracking
# [18:15] <arno> tantek: if the ED gets more than 1 year out of date...
# [18:16] <arno> tantek: there are past signals and procedure that seem to have fixed it
# [18:16] <arno> tab: re: issue tracking and bugzilla, there's only 5 components in it right now. could we add all components?
# [18:16] <arno> johnjansen: yeah, how do we do that
# [18:17] <arno> solution: mail mike smith (or bert) to ask the components to be added in bugzilla
# [18:17] <arno> sylvain: we have 1 hour tomorrow for animation
# [18:18] <arno> sylvain: i have some technical discussion that needs to hapen
# [18:18] <arno> bert: maybe that's a topic for the plenary
# [18:18] <arno> tantek: there are several issue re: specs
# [18:18] <arno> tantek: sounds like you want to lead a discussion
# [18:18] <arno> bert: no, not really...
# [18:19] <arno> daniel: anything else about spec editing/tracking?
# [18:19] <arno> plinns: that makes me want to build a tool. would people use it?
# [18:19] <arno> tantek: might be worth looking at hixie's tool'
# [18:20] <arno> tab: it's easy to deal with
# [18:20] <arno> daniel: yes, select all and resolve as invalid :)
# [18:20] * Bert Tracker itself came out of Dean Jackson feeling like Peter feels now. :-)
# [18:20] <arno> fantasai: you could improve tracker, most of its problems are UI issues
# [18:21] <arno> fantasai: we have so many systems because all of them kinda suck
# [18:21] <arno> tantek: who does the IT for bugzilla/tracker?
# [18:21] <arno> chris: it's the systems team
# [18:21] <tantek> URL?
# [18:22] * tantek wouldn't mind seeing tracker's source/deployment moving to github.
# [18:22] <arno> daniel: let's close this agenda item and move on the next one
# [18:22] <arno> daniel: let's move to css regions
# [18:23] <arno> vincent: <showing slides>
# [18:23] <arno> my.adobe.acrobat.com/silverman
# [18:24] <arno> vincent: css regions (alex and vincent)
# [18:24] <arno> css exlcusions (rossen and vincent)
# [18:24] <arno> css fragmentations (eliak and rossen)
# [18:24] <arno> vincent: ED after the tokyo meeting
# [18:24] * Joins: howcome ([email protected])
# [18:24] <dbaron> Is positioned floats part of one of those three parts?
# [18:25] <arno> vincent: most issues have been worked out, except the ones to review today
# [18:25] <arno> vincent: 2 implementations in progress (IE and WebKit)
# [18:25] <arno> vincent: would like to resolve some issues today and publish a new WD
# [18:26] <arno> vincent: positioned floats is another module (not the three parts above)
# [18:26] <dbaron> vincent: positioned floats is a 4th part
# [18:26] * Joins: szilles ([email protected])
# [18:26] * sylvaing Skype access to the meeting available at w3c-csswg
# [18:27] <arno> vincent: issue tracked in the spec, and the wiki has a list of resolved issues and no longer in the spec
# [18:27] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
# [18:28] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
# [18:28] <arno> howcome: i have concerns with the current regions approach
# [18:29] <arno> howcome: we need them, but it doesn't discuss two issues that seem important: pagination and auto-generation of boxes
# [18:29] <arno> max: currently done by script, using OM
# [18:29] <arno> alan: to have the entire content displayed, you need a page template mechanism
# [18:30] <arno> howcome: multicol is already doing auto-generation
# [18:30] <arno> alex: we use at multiple use cases, and there are so many cases that you need script anyway
# [18:30] <arno> howcome: i'd love to see the use cases.
# [18:31] <arno> alex: for some use cases you need script, but maybe we can have a subset that does auto-generation
# [18:31] <stearns> you can display the entire content (by having the last region overflow)
# [18:32] <arno> steve: you are correct that some of the problem have do with pages. you can't know ahead of time how many pages you need. rather than picking up on region, it seems like this is something that should be handled by pages instead
# [18:32] <fantasai> didn't Bert have a proposal in css3-template that solved this kind of problem?
# [18:32] <arno> steve: some way of having master pages that can be combined through an auto-generation mechanism to do this
# [18:32] <Bert> q+
# [18:32] * Zakim sees Bert on the speaker queue
# [18:33] <arno> steve: multicol seems too weak to deal with this
# [18:34] <arno> howcome: i'd like to approach this by looking at use cases
# [18:35] <arno> vincent: we looked at what's needed for magazine, but regions are one the building blocks that's needed. pagination is useful as well.
# [18:35] <arno> vincent: there's a lot that can be done with regions, and we'd like to work on pagination as well
# [18:36] <arno> vincent: regions was a common denominator across all the use cases we looked at
# [18:36] <arno> howcome: i think two things regions must address are pagination and auto-generation
# [18:36] <arno> steve: i'm confused: neither of these things have to do with pages, pages is a separate module
# [18:37] <arno> howcome: i think we're using the terms differently
# [18:37] * alexmog- proposes action for Hakon and Alex to propose a mechanizm for autogeneration
# [18:38] <fantasai> howcome: If I take a stylesheet from one document and apply it to another that has more content, I should be able to *see the content*
# [18:38] <arno> howcome: when you apply a style sheet to another document, you should still be able to see the content
# [18:38] <arno> steve: regions doesn't resolve all problems. it's one building block, that can be chained with others.
# [18:39] <arno> steve: the intent was that the auto-generation would be done over a collection of regions, called a page, that would get auto-generated. you're correct this is not correctly specified, but it makes more sense to deal with it in the context of pages, rather than regions
# [18:40] <arno> howcome: i dont think we fundamentally disagree. we both want to do regions. i think it's possible to latch onto the multicol model with does auto-generation and paginations
# [18:41] <arno> howcome: if you can have selectors for each column, and column on each page, maybe layout-wise it's as powerful, it solves the use cases but gives you pagination and auto-generation
# [18:42] <dbaron> ack Bert
# [18:42] * Zakim sees no one on the speaker queue
# [18:42] <arno> bert: I did some work past few days to integrate regions spec in template layout
# [18:42] <arno> bert: for repeating, not completely worked out, but should possible to put a template in a column.
# [18:43] <Bert> -> # [18:43] <arno> bert: all w/ same mechanism, you only need a selector to select a column and a column in a page
# [18:44] <arno> howcome: can we see the use cases?
# [18:44] <arno> daniel: have them in the spec
# [18:44] <Bert> action bert: move template layout to dev.w3.org
# [18:44] * trackbot noticed an ACTION. Trying to create it.
# [18:44] * RRSAgent records action 1
# [18:44] <trackbot> Created ACTION-374 - Move template layout to dev.w3.org [on Bert Bos - due 2011-11-06].
# [18:45] <arno> vincent: we don't have use cases in specs in general
# [18:45] <arno> daniel: maybe in an appendix
# [18:45] <fantasai> fantasai: Can we have this draft on dev.w3.org? Bert: It's convenient to have it internal. fantasai: It's more convenient for us to have it public. Bert: I'd rather publish a WD. fantasai: Yes, let's do both. :)
# [18:45] <Ms2ger> fantasai++
# [18:45] <arno> molly: there's a convention in publishing, if it's a screenshot it's not considered proprietary
# [18:46] * Bert thanks fantasai for recording that.
# [18:46] * fantasai welcome
# [18:46] * tantek agrees with daniel
# [18:46] <arno> howcome: we need to see the use cases
# [18:46] <arno> howcome: we need to support auto-generation
# [18:46] <tantek> would be useful to capture/see the use-cases in the spec that drove the design. in an Appendix is fine.
# [18:47] <arno> howcome: we need pagination
# [18:47] <fantasai> hwocome^: Shouldn't have to resort to scripting.
# [18:47] * sylvaing dreams of specs with uses-cases appendices
# [18:47] <arno> vincent: agree with it, but our take was that pagination and auto-generation were not going to be covered in regions spec
# [18:47] <arno> steve: shouldn't it be in the paginated media module?
# [18:48] <arno> howcome: that would be fine, but the specs should evolve at the same time
# [18:49] <arno> alex: i think you're trying to do a simple page flipper, it would be great to support that
# [18:50] <fantasai> howcome: My use case is to have a fancy first page of an article, and then second and subsequent pages flow as multi-col
# [18:50] <arno> vincent: multicol serves multiple purpose, it's both a template and a way to paginate
# [18:50] <fantasai> vincent: That's issue 12, whether to have multicol as regions
# [18:50] <arno> alex: i think we need to talk about it and decide which spec it belongs to
# [18:51] <fantasai> vincent: auto-generation goes much further than just that
# [18:51] <arno> steve: i think we should record the issue that howcome is raising
# [18:52] <arno> alex: i think pagination/fragmentation is a fundamental feature of layout. the region spec is about how to provide this boundary
# [18:52] <arno> howcome: i just want to know how to print documents with regions on them
# [18:52] <arno> daniel: we have 15min remaining. let's move one.
# [18:53] <arno> s/one/on/
# [18:53] <glazou> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
# [18:53] <arno> vincent: do we want multicol elements to be regions or not
# [18:53] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions
# [18:54] <arno> fantasai: i'm in favor
# [18:54] <arno> alex: i like that idea too, add very little complexity to implementation
# [18:55] <arno> alex: if there's a region and you set column = 2, you get a region with two columns
# [18:55] <ChrisL> rrsagent, here
# [18:55] <RRSAgent> See http://www.w3.org/2011/10/30-css-irc#T17-50-04
# [18:56] <tantek> <aside> just stubbed http://wiki.csswg.org/spec/issue-tracking - please review and feel free to improve </aside>
# [18:56] <arno> rossen: overflow would be interesting in that case
# [18:56] <arno> rossen: this would lead to introducing fragmentation
# [18:56] <arno> steve: seems like the AI is "how should it be done or why it shouldn't be done"
# [18:57] * Quits: szilles ([email protected]) (Ping timeout)
# [18:58] <arno> jdaggett: is the question something with both multi-column and region, what happens?
# [18:58] <arno> jdaggett: where does the spec forbid it?
# [18:58] <arno> section 4.2
# [18:58] <tantek> <aside> also lurking in #tpac as a general back-channel for this week </aside.
# [18:58] <vhardy> # [18:59] <arno> howcome: multicol only changes how things are laid out inside the element
# [18:59] <arno> howcome: i don't understand how multicol would be any harder...
# [19:00] <arno> alex: some work needs to happen, because overflow behavior is different
# [19:00] <arno> howcome: i don't understand why we need a proposal
# [19:01] <arno> daniel: we need a proposal, alex/vincent come back to the group when you have one
# [19:01] <arno> action vincent: bring a proposal for interaction between multicol and region
# [19:01] * trackbot noticed an ACTION. Trying to create it.
# [19:01] * RRSAgent records action 2
# [19:01] <trackbot> Created ACTION-375 - Bring a proposal for interaction between multicol and region [on Vincent Hardy - due 2011-11-06].
# [19:01] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
# [19:01] <arno> alex: issue 19: special behavior of iframe.
# [19:02] <arno> alex: two implementations (IE and webkit) have different behavior. need to reconcile.
# [19:02] * Quits: shepazu ([email protected]) (Quit: shepazu)
# [19:02] <arno> alex: need some sort of indirection mechanism
# [19:02] <arno> fantasai: how does it related to the seamless attributes in HTML5
# [19:03] <arno> ??: seems like allowing flowing of content is not specific to regions
# [19:03] <fantasai> s/??/hober/
# [19:03] <fantasai> alex: seamless also allows transparency wrt scripting and style rules
# [19:03] <arno> alex: once the flow is picked up from iframe, not relevant to iframe either. maybe have a link element referring to a url with the external flow
# [19:04] <arno> alex: i would like advice
# [19:04] <arno> tab: i am scared of this, esp. re: security
# [19:04] <arno> tab: this would allow arbitrary interaction with layout
# [19:04] <arno> alex: currently restricted to same origin
# [19:04] <arno> fantasai: seems like the switch should be at the HTML level
# [19:05] <dbaron> hober: certainly not at the regions level
# [19:05] <arno> tab: i don't think we should tie a "transclusion" property with regions
# [19:05] <arno> molly: i think it should be in html5
# [19:05] <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
# [19:06] <Bert> (Sounds like this already exists: XInclude)
# [19:06] <arno> tab: we should make a separate spec for it
# [19:06] <fantasai> s/it/transclusions/
# [19:07] <arno> steve: you can put the iframe in the flow, but not the content of the iframe
# [19:07] <arno> tab: the content of iframes are a black box to css
# [19:07] <arno> johnjansen: you get the security protection by using iframe
# [19:07] <fantasai> tab: the security concern is in the other direction
# [19:08] <arno> rossen: the core of the problem is do we allow external content to flow through regions? if we do, we need a way
# [19:08] <arno> daniel: what's the use case
# [19:08] <arno> rossen: digital publishing that pick up articles from various sources, and aggregates them
# [19:08] <arno> daniel: seems like it could be a feature we add later
# [19:09] <arno> dbarron: doesn't seem specific to Regions
# [19:09] <fantasai> s/dbarron/dbaron/
# [19:09] <arno> molly: or CSS at all. seems like HTML
# [19:09] <arno> alex: looks like we don't have a proposal, and that's what IE is going to ship
# [19:09] <arno> hober: it could be anywhere it's appropriate
# [19:10] <Bert> (B.t.w., # [19:11] <arno> daniel: it reminds of the time when features where implemented before discussions
# [19:11] <arno> daniel: and it gives me a bad feeling
# [19:11] <arno> daniel: i have the gut feeling you're going too fast. there's no agreement between parties it should be the spec and you say: "it's in IE"
# [19:12] <arno> alex: i disagree w/ the statement that we don't care about it
# [19:12] * tantek agrees with daniel. this feels like we (the working group) are racing towards shipping incompatibility and legacy compat issues.
# [19:12] <fantasai> +!
# [19:12] * Zakim wonders where ! is
# [19:12] <fantasai> +1
# [19:13] <arno> action alex: remove text about special iframe behavior and alex to write proposal about the behavior of iframe
# [19:13] * trackbot noticed an ACTION. Trying to create it.
# [19:13] * RRSAgent records action 3
# [19:13] <trackbot> Created ACTION-376 - Remove text about special iframe behavior and alex to write proposal about the behavior of iframe [on Alex Mogilevsky - due 2011-11-06].
# [19:17] * Quits: tantek ([email protected]) (Quit: tantek)
# [19:17] * Quits: TabAtkins_ ([email protected]) (Ping timeout)
# [19:18] * Quits: plinss ([email protected]) (Quit: plinss)
# [19:30] * Joins: tantek ([email protected])
# [19:31] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
# [19:31] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
# [19:31] <fantasai> ScribeNick: fantasai
# [19:31] <fantasai> vhardy: Should this event be synchronous or asynchronous
# [19:32] <fantasai> vhardy: IE implemented as async, seemed to work with demos they built
# [19:32] <fantasai> alex: Not sure how to make it synchronous
# [19:32] * Bert to Daniel: can we find 2 minutes somewhere on the agenda to decide to publish a new Template Layout WD (probably conditionally, with a week's delay, so people can raise objections if needed)?
# [19:32] <fantasai> vhardy: If no convincing argument for sync, then making it async
# [19:32] <fantasai> dbaron: Are you defining exactly how it's async?
# [19:32] * glazou Bert yes, right after lunch?
# [19:32] <fantasai> alex: Sync would be defining exactly in what order it happens
# [19:33] * Bert OK
# [19:33] <fantasai> alex: async means that some layout process has happened in this region, and you're notified of that
# [19:33] * Joins: plinss ([email protected])
# [19:33] <fantasai> dbaron: i agree with making it async. Might need more detail at some point
# [19:33] <fantasai> RESOLVED: regionLayoutUpdate is an asynchronous event
# [19:33] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content
# [19:33] <fantasai> vhardy: interplay of flow-from and content
# [19:34] <fantasai> vhardy: which one has precedence?
# [19:34] <fantasai> vhardy: We had resolved to say that flow from property gets used in place of ocntent for associating an element with a flow
# [19:34] <fantasai> vhardy: We moved from using 'content' to 'flow-from', there was issue raised during meeting that not sure this was quite the right decision
# [19:34] <fantasai> vhardy: My request is to close the issue unless we have a problem to discuss?
# [19:35] <fantasai> vhardy: I'd rather close it, and reopen if you have a specific objection
# [19:35] <fantasai> fantasai: I'm ok with that.
# [19:35] <fantasai> Bert: flow-from is on regions, content is on elements. So they don't interact.
# [19:36] <fantasai> vhardy: flow-from makes something a region
# [19:36] <fantasai> Bert: There are various ways to make regions, but content is on an element.
# [19:37] <fantasai> vhardy: Right now if you wnat to flow content into an area, then you'll pick a flow and then put it in an element, which makes it into a region
# [19:37] <fantasai> howcome: Bert's point is that you're using an element to create a region. You could create a region without an element
# [19:38] <fantasai> RESOLVED: close issue 18, reopen if needed later
# [19:38] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-23should-regions-be-non-breakable
# [19:38] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence
# [19:38] <fantasai> vhardy: content vs. flow-from precedence
# [19:38] <fantasai> vhardy: On mailing list there was overwhelming preference for 'content' to take precedence
# [19:40] <fantasai> fantasai: The 'normal' value of 'content' would compute to using flow-from when available
# [19:40] <fantasai> discussion of using 'content' to override content
# [19:41] <fantasai> alex: flow-from blows away whatever content is there. Why shouldn't it be more important than 'content'.
# [19:42] * Joins: TabAtkins_ ([email protected])
# [19:42] <fantasai> vhardy: So we have a proposal from several to have 'content' != 'normal' override, and other is to have 'flow-from' always override.
# [19:43] <fantasai> alex: If we had display-inside: region, then 'content' would be irrelevant
# [19:43] <fantasai> alex: flow-from is two properties in one
# [19:44] <fantasai> fantasai: 'content' property is supposed to be the master switch for what the contents of this element ar.
# [19:44] * Joins: tcelik ([email protected])
# [19:45] * Joins: szilles ([email protected])
# [19:46] <dbaron> fantasai: I don't like having properties that unilaterally override other properties.
# [19:46] <dbaron> fantasai: That always leads to problems.
# [19:47] <fantasai> fantasai: we have this problem with 'border-image', where if someone sets 'border-image' further up in the cascade, my 'border-style: dashed' inexplicably has no effect
# [19:48] <fantasai> Bert: A different solution, apart from needing two properties, the model doesn't have to be one overriding the other.
# [19:48] <fantasai> Bert: In Template module, if two pieces of content go into the same slot, they add up
# [19:48] <fantasai> alex: So if there's content in the region, then it's appended to the flow?
# [19:48] <fantasai> vincent: You would include the element's content, and the append the flow
# [19:49] * Quits: szilles ([email protected]) (Ping timeout)
# [19:49] <fantasai> molly: from a developer perspective, 'content' should be about the content.
# [19:50] <fantasai> discussion of applying 'content' to an image
# [19:50] <fantasai> fantasai: if you write img { content: "foo" } the <img> element will cease to be a replaced element and will become an inline element containing the string "foo"
# [19:52] <fantasai> RESOLVED: If 'content' computes to 'normal', then the element takes the flow
# [19:54] * Quits: TabAtkins_ ([email protected]) (Quit: leaving)
# [19:54] * Joins: szilles ([email protected])
# [19:54] * Joins: TabAtkins_ ([email protected])
# [19:55] <fantasai> fantasai explains the 'content' property and its various values and effects on elements, pseudo-elements, replaced elements, etc.
# [19:56] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-20list-of-region-style-properties
# [19:56] <vhardy> # [19:56] <fantasai> vhardy: The @region doesn't have the pseudo-selector ppl didn't like
# [19:56] <fantasai> vhardy: The number of properties that apply listed in that link, font proeprties, background properties, simple rendering properties
# [19:56] <fantasai> vhardy: Also includs borders/marginsp/adding,
# [19:57] <fantasai> vhardy: We explain why some things that apply to layout might make sense here
# [19:58] <fantasai> vhardy: there's a simplified list of properties that can apply to regions, but it's now more than ::first-line
# [19:58] <fantasai> vhardy: In our impl experience, this has been ok
# [19:58] <fantasai> alex: multi-col properties?
# [19:58] <fantasai> vhardy: The multi-col isn't on the flow content, it's on the region itself
# [19:58] <fantasai> alex: We should have an element there, say <article> as 3 columns... flows into a 1 column region
# [19:59] <fantasai> alex: Could choose to have 1 col in one region and 3 col in another region
# [19:59] * fantasai doesn't understand this issue at all and need to read the spec before making any comment
# [19:59] <fantasai> vhardy: You can't change the layout nature, e.g. display/position
# [19:59] <fantasai> vhardy: multicol... I guess it's halfway
# [19:59] <fantasai> vhardy: I guess we could add it
# [20:00] <fantasai> dbaron: Does this specify somewhere how the cascading and inheritance works?
# [20:00] <fantasai> vhardy: yes, somewhere there
# [20:00] <fantasai> dbaron: .... specificity isn't the issue
# [20:00] <fantasai> howcome: It's multiple inheritance, isn't it.
# [20:01] <fantasai> Bert: It's the ::first-line problem.
# [20:01] <fantasai> fantasai: Can we put ::first-line into the regions spec so you can solve all the problems at the same time? :)
# [20:01] <fantasai> vhardy: If there's an issue with cascading/inheritance then I'm happy to take that as a separate issue. This one is about the list of properties.
# [20:02] <fantasai> ...
# [20:02] <fantasai> howcome: if you set 1.2em on something inside a region, what does it refer to?
# [20:02] <fantasai> vhardy: If you set the font size on the region itself, it has no effect on the content just on the layout of the region
# [20:02] <fantasai> howcome: I have a region, and I set font-size on that. And it's applied
# [20:03] <fantasai> howcome: And I have a span inside it that sets 1.2em. What is it relative to?
# [20:03] <fantasai> vhardy: If you set it on the region then it doesn't inherit
# [20:03] <fantasai> Steve: You can't have it both ways.
# [20:04] <fantasai> Steve: If you set it on the region and it affects the text, it inherits into that element
# [20:04] <fantasai> howcome: What if you set 'inhert'?
# [20:04] <fantasai> Steve: I wouldn't answer that question hastily...
# [20:04] <fantasai> Steve: ::first-line has the same problem
# [20:04] <fantasai> dbaron: This is very different from ::first-line actualy
# [20:05] <fantasai> dbaron: I'd like the example in the spec to not use pseudo-syntax, use real syntax
# [20:05] <fantasai> jdaggett agrees
# [20:05] <fantasai> jdaggett: I'd like the examples to show what an author might use, not just region1 region2
# [20:05] <fantasai> Steve: dbaron, I thought you said ::first-line effectively introduced an element around that thing, so inheritance would go to the first line
# [20:06] <fantasai> dbaron: ::first-line introduces an additional pseudo-element around it, and I forget the wording around inheritnace 'cuz we changed it so many times
# [20:06] <fantasai> dbaron: But this also has selectors inside the region rules, so you can have an element that picks up different selectors based on where it breaks.
# [20:06] * glazou we're breaking for lunch in 10mins from now
# [20:06] <fantasai> howcome: It says font size in percentages refers to inherited font-size
# [20:07] <fantasai> dbaron: I think the model here is actually relatively simple. I think it's simpler than ::first-letter. However it doesn't agree at all with the spec's existing terminology. So it's sort of hard to write about.
# [20:07] <fantasai> dbaron: This model gives elements multiple styles essentially.
# [20:07] * tcelik is a bit confused about the distinction between the "current" font-size and the "inherited" font-size.
# [20:07] <fantasai> dbaron: And 2.1 is writen assuming that an element has *a* computed value for a property
# [20:07] <fantasai> Tab: All the specs are written with that assumption
# [20:07] <fantasai> dbaron: This is more box tree stuff
# [20:08] <fantasai> fantasai: We're introducing the term "fragment" to talk about pieces of the box in the box tree when it's broken
# [20:09] <fantasai> fantasai: might help with discussing this
# [20:09] <fantasai> Bert: I also have 'vertical-align', works like in table cells
# [20:09] <fantasai> Bert: I also have 'overflow': if contents put in the region are too wide for the region, where does it go? Is it visible at all?
# [20:10] <fantasai> (talking about properties that are set on the region)
# [20:10] <fantasai> Rossen: This is about the properties that are propagated to the contents of the region
# [20:10] <fantasai> Rossen: Back to howcome's example, when you compute fonts you always have a resolved font-size no matter where you are in the tree
# [20:10] <fantasai> Rossen: If we allow regions to specify font-size, this would be equivalent to changing initial font size on the fly
# [20:10] * Joins: umbridge ([email protected])
# [20:11] <fantasai> Rossen: Once you're inside, you start again from the root
# [20:11] <fantasai> Rossen: Like howcome pointed out, this is multiple inheritance, no kidding
# [20:11] <fantasai> Rossen: you won't know your font size until you lay out the part of the element that you're computing
# [20:11] <fantasai> Rossen: Simplest example is body with 100em width
# [20:12] <fantasai> Rossen: It appears in 2 regions, one with 10px font size and one with 100px fontsize
# [20:12] <fantasai> Rossen: In this model you will have to recompute the body size
# [20:12] * Parts: umbridge ([email protected])
# [20:12] <fantasai> vhardy: No, right now all inheritance happens through the element tree
# [20:12] <fantasai> vhardy: you're adding selectors that apply to fragments
# [20:12] <fantasai> ...
# [20:13] <fantasai> vhardy: In our model, you'll set a selector: if my H1 is in this region, here's the font size that applies
# [20:13] <fantasai> howcome: in that sense you don't have multiple inheritance
# [20:13] <fantasai> Steve: the multiple inheritance is when you have different pieces of the block that get different styling
# [20:13] <fantasai> CHrisL: Similar to ::first-letter multiple inheritance
# [20:13] <fantasai> dbaron: no, I don't think it is
# [20:13] <fantasai> dbaron: Wanted to bring up 2 other things
# [20:14] <fantasai> dbaron: Thing you said about percentages relative to the original, that sounded wrong to me.
# [20:14] <fantasai> dbaron: I'd think if you have separate styles for stuff in the region, you'd compute styles in a consistent model within that tree
# [20:14] <fantasai> dbaron: Percentages etc. would compute relative to those styles until you're back outside of that region
# [20:14] <fantasai> dbaron: I don't think multiple inheritance is the right way to think about that.
# [20:14] <fantasai> dbaron: Other thing I wanted to mention is, if we think about it that way
# [20:15] <fantasai> dbaron: Then any property that takes lengths can change as a result of font-size changes.
# [20:15] <fantasai> dbaron: It seems silly to restrict that then, i.e. only allow changes as a result of font-size but not arbitrarily otherwise.
# [20:15] <fantasai> dbaron: Basically if you have @region head { body {font-size: 2em; }}
# [20:16] <fantasai> s/}}/}/
# [20:16] <fantasai> }
# [20:16] <fantasai> h1 { height: 2em; }
# [20:16] <fantasai> dbaron: Your body font size is going to be double your HTML font size as it flows into this region.
# [20:16] <fantasai> dbaron: your h1 initial font size is specifid in ems
# [20:17] <fantasai> dbaron: If you accept what steve and I say, then the h1 is going to be proportionally larger
# [20:17] <fantasai> dbaron: but what you said earlier is that it wouldn't be
# [20:17] <fantasai> Steve: So I thought what yoy said is that you're overlaying styles on these elements using selectors
# [20:17] <fantasai> Steve: so you'd walk up the tree and see the overlaid styles
# [20:17] <fantasai> vhardy: ... this is why the properties only make sense ..
# [20:18] <fantasai> vhardy: height doesn't make sense to apply to different fragments of the div
# [20:18] <fantasai> steve: height has to look somewhere for its value
# [20:18] <fantasai> vhardy: So that's something you'd have to compute relative to the parent element
# [20:18] <fantasai> vhardy: If my h1 is in the head region, will it be base don that value or the other one
# [20:18] <fantasai> vhardy: I'll take an action item on that.
# [20:19] <fantasai> howcome: We all wanted to have a use case appendix, wasn't recorded as an action item.
# [20:19] <fantasai> ACTION vhardy: Make a use case appendix
# [20:19] * RRSAgent records action 4
# [20:19] * trackbot noticed an ACTION. Trying to create it.
# [20:19] <trackbot> Created ACTION-377 - Make a use case appendix [on Vincent Hardy - due 2011-11-06].
# [20:19] <fantasai>
# [20:19] <glazou> br is empty :-)
# [20:19] * Quits: bradk ([email protected]) (Quit: Computer has gone to sleep)
# [20:20] <mollydotcom> but lunch is presentational :P
# [20:21] <ChrisL>
# [20:22] * Quits: arronei_ ([email protected]) (Ping timeout)
# [20:24] * Quits: sylvaing ([email protected]) (Ping timeout)
# [20:33] * Quits: tcelik ([email protected]) (Quit: tcelik)
# [20:34] * Quits: szilles ([email protected]) (Ping timeout)
# [20:38] * Joins: szilles ([email protected])
# [20:42] * Joins: arronei_ ([email protected])
# [20:49] * Joins: sylvaing ([email protected])
# [20:49] * Quits: tantek ([email protected]) (Quit: tantek)
# [20:57] * Quits: szilles ([email protected]) (Ping timeout)
# [21:00] * Joins: bradk ([email protected])
# [21:03] * Joins: guacamole ([email protected])
# [21:04] * Parts: guacamole ([email protected])
# [21:09] <dbaron> ScribeNick: dbaron
# [21:10] <dbaron> Topic: Orientation and unicode properties for vertical text layout
# [21:10] * Joins: szilles ([email protected])
# [21:10] <jdaggett_> http://www.unicode.org/reports/tr50/
# [21:10] <glazou> "Orientation and Unicode properties for vertical text layout"
# [21:10] * Joins: tantek ([email protected])
# [21:10] <dbaron> jdaggett: I put this on the wiki. Based on discussions from the summer. Current writing modes spec doesn't have an entirely normative defintion of orientation.
# [21:11] <dbaron> jdaggett: So it wasn't clear what exactly the default orientation should be. This means that in vertical text layout, some characters, e.g. ideographic, stay upright, whereas roman characters are rotated on their side. The question is which characters go which way.
# [21:11] <dbaron> jdaggett: The current spec has an appendix which gives an algorithm; I don't know whether it's currently marked as normative.
# [21:12] <dbaron> jdaggett: But the question is what the right way to do this is. In talking with Eric Muller (sitting in the back), it would make sense to make a Unicode property for this specifically.
# [21:12] <dbaron> jdaggett: This proposal is to make an additional property for Unicode that would specify the default orientation that the writing-modes spec could normatively reference.
# [21:12] <dbaron> jdaggett: There's a comment period now, and there will be another review period.
# [21:13] <jdaggett_> http://wiki.csswg.org/spec/utr50
# [21:13] <dbaron> Eric: Process-wise, UTC meets next week. Then produce a draft version of the TR and have another round of review.
# [21:13] <dbaron> jdaggett: These http://wiki.csswg.org/spec/utr50 are Elika's and Koji's comments as to different issues.
# [21:13] <dbaron> jdaggett: Very clear for ideographic and alphabetic characters, but there are a number of character ranges where it's more difficult to decide.
# [21:13] <jdaggett_> http://www.unicode.org/reports/tr50/bycp.html
# [21:14] <dbaron> jdaggett: http://www.unicode.org/reports/tr50/bycp.html is the proposed list of codepoints and how they change
# [21:14] <jdaggett_> # [21:14] <dbaron> jdaggett: # [21:14] * Bert daniel, don't forget the 2 minutes on the agenda for publishing css3-layout (and css3-regions, because I think Vincent had that on his agenda as well)
# [21:15] <dbaron> jdaggett: These are some general punctuation characters. Green column shows the vertical alternate that exists in the font (Hiragino Mincho, Kozuka Mincho, Meiryo).
# [21:15] <dbaron> jdaggett: Where the character in the green column is different it means there's a vertical alternate for that codepoint.
# [21:15] <dbaron> jdaggett: U+2014, em-dash, no fonts have vertical alternates for it
# [21:16] <dbaron> ?: Using the VERT feature for this?
# [21:16] <dbaron> ?: In Kozuka font, U+2014 is proportional -- covered by VRT2 but not by VERT.
# [21:16] <dbaron> ?: In vertical, you do want U+2014 rotated to go along with other Latin characters that get rotated as well.
# [21:17] <dbaron> jdaggett: On the Mac it's natural to use U+2014, on Windows it's natural to use U+2015.
# [21:17] <dbaron> ?: In our fonts it's also a distinction between proportional and full-width.
# [21:17] <dbaron> jdaggett: When you say proportional, the expectation is that it will be set sideways.
# [21:17] <dbaron> ?: do that with VRT2
# [21:18] <dbaron> jdaggett: scroll down to the arrows... high U+2190s
# [21:18] <dbaron> jdaggett: See that the arrows are ... U+2190 pointing to the text that's coming before it
# [21:18] <dbaron> jdaggett: I also have how the current IE and WebKit implementations handle this.
# [21:19] <dbaron> jdaggett: These may not be totally accurate because it's a little tricky to figure out.
# [21:19] <ChrisL> http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
# [21:19] <dbaron> jdaggett: The problem we want to solve is that we don't want different implementations handling this differently.
# [21:19] <dbaron> jdaggett: Once Unicode has a property that establishes this we have firmer ground to make text-orientation consistent across implementations.
# [21:20] <dbaron> jdaggett: We won't get a solution that works 100% of the time, but we'll get a good default that authors can still change when they need to.
# [21:21] * Joins: tcelik ([email protected])
# [21:21] * Joins: Liam ([email protected])
# [21:21] <dbaron> Bert: Looks like an issue for Unicode, not us.
# [21:21] <dbaron> jdaggett: Right now our spec is defining an equivalent of this.
# [21:21] <dbaron> fantasai: Yes, once Unicode defines this we will reference it.
# [21:22] <dbaron> jdaggett: When you go into the details there are still questions as to what the OpenType layout model is for vertical text, and questions for which way specific code ranges should go.
# [21:22] <dbaron> fantasai: Details of code ranges don't need the whole room.
# [21:23] <dbaron> SteveZ: In other words, if you think you care, look at these documents (wiki, tr50) and comment.
# [21:23] <dbaron> jdaggett: We have two browser implementations of vertical text, and it would be nice if the implementors ...
# [21:23] <dbaron> fantasai: ... looked at this and made comments as appropriate.
# [21:23] <dbaron> jdaggett: There's wide variation between existing implementations.
# [21:24] <dbaron> SteveZ: One thing that's important as a principle: we're trying to do it so the choice of whether something is rotated or upright can be made without looking at the font data. One reason for that is that it's expensive or impossible given how the font data are encoded in OpenType (and may be impossible through some OS interfaces). But it must work in the context where the fonts do things in certain circumstances, so it's a slightly messy problem.
# [21:25] <dbaron> Topic: Gradients
# [21:26] <bradk> http://wiki.csswg.org/ideas/radial-gradients
# [21:26] <dbaron> ACTION hober to review Unicode TR50 and compare to existing implementation
# [21:26] * trackbot noticed an ACTION. Trying to create it.
# [21:26] <trackbot> Created ACTION-378 - Review Unicode TR50 and compare to existing implementation [on Edward O'Connor - due 2011-11-06].
# [21:26] <dbaron> ACTION sylvain to review Unicode TR50 and compare to existing implementation
# [21:26] * trackbot noticed an ACTION. Trying to create it.
# [21:26] <trackbot> Created ACTION-379 - Review Unicode TR50 and compare to existing implementation [on Sylvain Galineau - due 2011-11-06].
# [21:26] <dbaron> Topic: ?
# [21:26] <dbaron> Bert: You said you wanted to publish regions as well?
# [21:26] <jdaggett_> s/TR/UTR/
# [21:27] <dbaron> Bert: I also wanted to ask if we could publish a new template layout module.
# [21:27] <dbaron> glazou: A little more than a week -- let's say two weeks to look at this, and then make a decision in 2 weeks?
# [21:27] <dbaron> Håkon: Can we do the action points first before we publish? I think it would be helpful for the specs to have code examples.
# [21:28] <dbaron> jdaggett: replacing the pseudo-code with real code
# [21:28] <dbaron> Håkon: maybe put in a couple of use cases
# [21:28] <dbaron> s/Topic: ?/Topic: publishing template and regions/
# [21:28] <dbaron> SteveZ (?): There are use cases on the wiki.
# [21:29] <dbaron> RESOLVED: publish regions and template if there are no objections in 2 weeks
# [21:29] <dbaron> Topic: Gradients
# [21:29] <dbaron> Tab: I assume everybody has read all the mailing list discussion on the subject. :-)
# [21:29] <dbaron> http://wiki.csswg.org/ideas/radial-gradients
# [21:29] <dbaron> Tab: We have 2 proposed syntaxes for radial gradients. The one in the draft and brad's simplification of it.
# [21:29] <dbaron> Tab: The differences between them at this point are that:
# [21:30] <dbaron> - draft allows arbitrary position; brad allows center/side/corners only
# [21:30] <dbaron> - draft allows more options sizing the gradient; Brad has just circle or ellipse that fills the box
# [21:30] <dbaron> Tab: The question is which one we're going to keep.
# [21:30] <dbaron> Tab: This is the only remaining issue with css3-images; want to move to LC.
# [21:31] <dbaron> fantasai: Do a pre-LC TR draft first.
# [21:31] <dbaron> Brad: When we did linear gradients, we simplified it and made it easy to understand and learn.
# [21:31] <dbaron> Brad: I think all the options in the draft are confusing and overcomplicated, and I think the way people use those options is really confusing.
# [21:31] <dbaron> Brad: I think the layering of different properties that affect the length of the gradient line in different ways.
# [21:31] <dbaron> Brad: In some cases position makes the gradient line larger or smaller.
# [21:32] <dbaron> Brad: To understand what's going on you have to understand what wins when background-position and background-size change it
# [21:32] <dbaron> Brad: The arguments for all this extra control seem to be centered around non-background use of radial gradients, which are, imo, edge cases.
# [21:33] <dbaron> Brad: If you want to use a radial gradient as a list-style-image, and you can't get the clipping/styling/positioning you want, I think that's a minor issue that shouldn't drive the syntax.
# [21:34] <dbaron> Tab: I disagree with that. Making all the other image-bearing properties have properties analogous to background-position and background-size (list-style-image, border-image, masks) ...
# [21:34] <dbaron> Tab: While you can do without it for the most part in backgrounds.
# [21:34] <dbaron> Tab: I think what's there isn't that hard and is sufficiently useful to justify itself.
# [21:35] <dbaron> Tab: There are 3 bits that require thinking about with a radial gradient: if you're using a position other than center then all the implicit sizing keywords and ? and ? are relatively simple to think about if you're only using 1 or 2 of them together.
# [21:36] <dbaron> Tab: The one in Lea Verou's gallery that used all 3 and was very confusing was done that way because existing browsers don't have explicit sizing.
# [21:36] <dbaron> Tab: This is the Hearts Grid example.
# [21:36] <dbaron> Tab: You can do the "Syntax A" version
# [21:37] <dbaron> Elika: Which is the position and which is the size?
# [21:37] <dbaron> Tab: position, then size
# [21:37] <dbaron> Brad: That's my whole point: we're saying that if you want explicit sizing you have to put in a value for the position, since you need that comma in there to distinguish.
# [21:37] <dbaron> Tab: The problem of positions and sizes looking similar is also in the background shorthand.
# [21:37] <dbaron> Brad: slash there, comma here?
# [21:38] <dbaron> Elika: I'd prefer something that didn't involve comma-separating everything so we could tell what's what.
# [21:38] <dbaron> Tab: Unless we did a slash I'm not sure what we'd do.
# [21:38] <dbaron> Daniel: no slash
# [21:38] <dbaron> Brad: ...
# [21:38] <dbaron> Brad: If it's a problem that we can't size images for list-style-image then it's a problem for all images, not just gradients.
# [21:39] <dbaron> Arron: It's the intrinsic size of the image.
# [21:39] <dbaron> Tab: With a gradient you can't control the intrinsic size.
# [21:39] <dbaron> Chris: I don't agree that non-background cases are minority: I think we're going to see more of that. I'm reluctant to see a solution that doesn't give full functionality to non-background images.
# [21:39] * Zakim excuses himself; his presence no longer seems to be needed
# [21:39] * Parts: Zakim ([email protected])
# [21:40] <dbaron> Brad: Won't those types of images need that functionality anyway?
# [21:40] <dbaron> Chris: There are things that know how to size themselves that are not background images.
# [21:40] <dbaron> Elika: With a PNG image, you have the same problem.
# [21:40] <dbaron> Elika: Wouldn't it be better to have a mechanism general enough to handle non-gradient images?
# [21:40] <dbaron> Brad: Better not to have to use the gradient functions to solve that problem.
# [21:41] <dbaron> Chris: Things I'm thinking of don't have that problem -- they know how big they are.
# [21:41] <dbaron> Chris: The syntax that requires background-size and background-position, then we'd be very limited using CSS gradients for 'fill' and 'stroke'.
# [21:41] <fantasai> radial-gradient(<size> <shape> from <position> as <color-stop>, <color-stop>, ...)
# [21:42] <fantasai> <size> would be one of the keywords
# [21:42] <dbaron> Chris: existing syntax has % and absolute, corresponding to SVG's userSpaceOnUse and boundingBoxRelative
# [21:42] <dbaron> (minute taker has trouble keeping up)
# [21:43] <dbaron> Brad: simplicity is a feature, makes CSS easier to learn
# [21:43] <dbaron> Elika: I'd prefer a halfway point between the two.
# [21:44] <dbaron> Brad: I already went a little towards Tab's with putting center on edge/corner.
# [21:44] <dbaron> Elika: farthest-corner, etc., make it easier for me to think about
# [21:44] * Quits: JohnJansen ([email protected]) (Quit: Page closed)
# [21:44] <dbaron> Brad: ... other colors going on past ...
# [21:45] <dbaron> Elika: put a color stop at the nearest corner?
# [21:45] <dbaron> Brad: That seems more complicated than just saying 142%
# [21:46] <dbaron> Brad: When I'm desiging things I'm doing it visually.
# [21:46] <dbaron> 1.4142135623730951
# [21:46] <tcelik> would this qualify as an irrational discussion?
# [21:46] <stearns> (that will be the tattoo for Tab's other arm)
# [21:47] <dbaron> Brad: It's can be important to hit the edges exactly when getting a circle, but matters less to be exact at the corners.
# [21:47] <dbaron> Molly: None of this makes any sense to designers/developers -- I don't think this belongs in CSS.
# [21:47] <dbaron> Molly: ok, let's leave the second point for dinner conversation
# [21:48] <dbaron> Daniel: I implemented a visual editor for the gradient proposal -- it's very complicated because of the syntax.
# [21:48] <dbaron> Daniel: I did the original WebKit proposal and the WG one afterwards.
# [21:48] <dbaron> Tab: It should be a lot easier now with explicit sizing.
# [21:48] <dbaron> Brad: I made a list of all the details I had to learn about how these parameters interact with each other.
# [21:49] <dbaron> Brad: linear gradients are simple, one side to the other
# [21:49] <dbaron> Brad: With this simplification, you're either going from one side to the other or center to the side
# [21:50] <dbaron> Brad: keeping it simple makes it much more understandable
# [21:51] <dbaron> Tab: Linear gradients are easier because it's one-dimensional.
# [21:51] <dbaron> Tab: Any linear gradient can be represented using the current syntax. Can't do that with radial gradient -- many can't be expressed in simpler form.
# [21:52] * Joins: JohnJansen ([email protected])
# [21:52] <dbaron> Brad: I'd want things more towards the simple side.
# [21:52] <dbaron> Molly: Agree. This is really SVG. We're putting it in CSS because designers want it right now. I think we need to keep it simple and respect what's in SVG.
# [21:53] <Bert> +1 to Molly
# [21:53] * Bert doesn't feel so alone anymore :-)
# [21:53] <dbaron> Molly: Designers would love the perfect WYSIWYG. As implementors you may be able to understand something, but putting it in language that people with less experience can explain... Trying to stopgap a need from designers. Concerned about simplicity and relation to SVG.
# [21:54] <dbaron> Tab: Remember, the majority of gradient usage won't use the functionality we're talking about.
# [21:54] <dbaron> Sylvain: We have 4 implementations.
# [21:55] <dbaron> Daniel: Opinions of those who make tools that design gradients?
# [21:55] * Quits: Liam ([email protected]) (Ping timeout)
# [21:55] <dbaron> Daniel: we have to reach a consensus
# [21:55] <dbaron> Arno: I'd lean towards the simpler syntax.
# [21:55] <dbaron> John: I would too
# [21:56] <dbaron> Alan: There is an SVG fallback.
# [21:57] <dbaron> Sylvain: Authors I've talked to have been more bothered by the change to bearing angles than by the complexity. What seems complex now may not in the future.
# [21:57] <dbaron> Brad: I don't think complexity goes away.
# [21:57] <dbaron> Elika: I'm confused by both syntaxes. I'd want something more readable.
# [21:58] <dbaron> Elika: How can we make it obvious which part means what?
# [21:58] <dbaron> Elika: Get away from commas, use keywords.
# [21:58] <dbaron> Elika: linear-gradient(from left as red, blue, green)
# [21:58] <dbaron> Elika: radial-gradient(circle from top left as red, blue, green)
# [21:59] <dbaron> Elika: radial-gradient(<shape>? from <position> as <color-stop-list>)
# [22:00] <dbaron> Brad: I do have the 'from' keyword, optional if not starting from the center.
# [22:01] <dbaron> Bert: Why 'circle' at all?
# [22:01] <dbaron> Elika: Otherwise it's an ellipse.
# [22:02] <dbaron> Elika: gradients have no intrinsic ratio
# [22:02] <dbaron> Elika: You can do Tab's set of functionality or Brad's with this syntax, but I think it'll be understandable
# [22:03] <dbaron> Brad: I have the idea that if you specify 'circle' it does have an intrinsic ratio.
# [22:03] <dbaron> Brad: That solves the what if you want a non-distorted circle that fills to the corners.
# [22:04] <fantasai> dbaron: I don't think giving it an intrinsic ration solves what you think it solves
# [22:05] <fantasai> dbaron: I think what you were saying is that if you want a circle that fills out to the corners of a non-square box
# [22:05] <fantasai> dbaron: so you want somehting where the extent of the graident is that *draws rectangle inscribed in an ellipse*
# [22:05] <fantasai> Brad: sorry, should have said "background-size: cover"
# [22:06] <fantasai> dbaron: that'll be smaller than what you want
# [22:06] <fantasai> Brad: I have a circle, used the circle keyword, and draw gradient to 142%
# [22:07] <fantasai> Brad: and then ..
# [22:07] <fantasai> dbaron: I don't know if we need to dig into this too much, though.
# [22:07] <fantasai> Steve: You would get what you want if the diameter of the circle covers the box.
# [22:07] <fantasai> Steve: Which is another way of saying...
# [22:07] <fantasai> dbaron: Tab's syntax has keywords for those four possibilities.
# [22:08] <fantasai> daniel: we've been working on gradient syntax for months withouth conclusion
# [22:08] <fantasai> steve: one reason we might not have a conclusions is that neither are acceptable yet
# [22:08] <fantasai> steve: there are good ideas in both, but still haven't gotten one that people understand and can communicate
# [22:08] <fantasai> daniel: Both solutions are okay. That's the problem.
# [22:09] <fantasai> daniel: But we need a resolution, and designers need this to ship
# [22:09] <fantasai> sylvain: People are using this today.
# [22:09] <fantasai> dbaron: And they're using it enough that this might wind up being the first -moz-prefixed thing we are unable to drop, given the number of changes.
# [22:10] <fantasai> fantasai: I really want to go in this direction. I can't read this stuff.
# [22:11] <fantasai> (this == using keywords)
# [22:11] <fantasai> Tab: I want to resolve on this asap.
# [22:11] <fantasai> Tantek: You're saying taking longer hurts more than complexity
# [22:11] <Ms2ger> Don't we all?
# [22:11] <fantasai> Molly: And then educators are stuck with this for eternity
# [22:12] <fantasai> daniel: What's the plan?
# [22:12] <fantasai> fantasai: I would like 24 hours with Brad and Tab and come back here tomorrow.
# [22:12] <fantasai> Tab: What I want more than anything else for my birthday is to close this issue.
# [22:13] <tantek> Dante's Inferno would have used radial gradients.
# [22:13] * hober the 9 color stops of Hell
# [22:13] <arno> :)
# [22:13] <dbaron> the closest-side, etc. could be following a 'to'
# [22:14] <dbaron> Tab: Brad's concern about complication is about position of the gradient line.
# [22:15] <dbaron> Bert: What's the difference if it's not the syntax?
# [22:15] <dbaron> fantasai: The ability to do arbitrary center, and the {farthest,closest}-{corner,side}, and explicit sizing of the ellipse.
# [22:15] * Joins: drublic ([email protected])
# [22:16] * hober an example of brad's gradient: # [22:16] <dbaron> Brad: And the fact that I'm starting from edge or center means I can go from corner to the full width of the element maintaining a circle.
# [22:17] <dbaron> dbaron: Isn't that farthest-side?
# [22:17] <dbaron> Tab: My syntax gives you the option.
# [22:17] <dbaron> Daniel: We are running in circles.
# [22:17] <dbaron> (Aren't we running in ellipses?)
# [22:18] <dbaron> Daniel: Straw poll, syntax A (Atkins) vs. syntax B (Brad)
# [22:18] <dbaron> Luke MacPherson: A
# [22:18] <dbaron> Shane: A
# [22:18] <dbaron> Steve: no comment
# [22:18] <dbaron> Molly: abstain
# [22:18] <dbaron> Bert: B (set of features, not syntax)
# [22:18] <dbaron> Stearns: abstain
# [22:19] <dbaron> Alex: to Sylvain
# [22:19] <dbaron> Arno: A
# [22:19] <dbaron> Brad: B
# [22:19] <dbaron> Tab: A
# [22:19] <dbaron> Elika: abstain
# [22:19] <dbaron> Daniel: B
# [22:19] <dbaron> Koji: A
# [22:19] <dbaron> John Daggett: don't like either, so abstain
# [22:19] <dbaron> David: I guess A.
# [22:20] <dbaron> Arron: A
# [22:20] <dbaron> Sylvain: A
# [22:20] <dbaron> John: I'll have to learn A.
# [22:20] <dbaron> Håkon: abstain
# [22:20] <dbaron> Peter: abstain
# [22:20] <dbaron> Chris: A
# [22:20] <dbaron> Vincent: A
# [22:20] <dbaron> Rossen: A
# [22:20] <dbaron> Tantek: A
# [22:20] <dbaron> Hober: A
# [22:20] <dbaron> Resolved: Stick with Tab's set of features.
# [22:21] <dbaron> ACTION Tab and Elika: discuss improvements to syntax within this set of features
# [22:21] * trackbot noticed an ACTION. Trying to create it.
# [22:21] <trackbot> Created ACTION-380 - And Elika: discuss improvements to syntax within this set of features [on Tab Atkins Jr. - due 2011-11-06].
# [22:22] <dbaron> Can we teach tracker to give actions to 2 people?
# [22:22] <fantasai> ACTION plinss: teach Tracker to give actions to multiple people
# [22:22] * trackbot noticed an ACTION. Trying to create it.
# [22:22] * RRSAgent records action 5
# [22:22] <trackbot> Created ACTION-381 - Teach Tracker to give actions to multiple people [on Peter Linss - due 2011-11-06].
# [22:22] <fantasai> :P
# [22:22] <Ms2ger> ACTION Elika and Tab: discuss improvements to syntax within this set of features
# [22:22] * trackbot noticed an ACTION. Trying to create it.
# [22:22] <trackbot> Created ACTION-382 - And Tab: discuss improvements to syntax within this set of features [on Elika Etemad - due 2011-11-06].
# [22:22] <Ms2ger> :)
# [22:23] * Quits: bradk ([email protected]) (Quit: Computer has gone to sleep)
# [22:27] * Quits: tcelik ([email protected]) (Quit: tcelik)
# [22:28] * Quits: JohnJansen ([email protected]) (Quit: Page closed)
# [22:32] * Quits: tantek ([email protected]) (Quit: tantek)
# [22:32] * Quits: plinss ([email protected]) (Quit: plinss)
# [22:51] * Joins: bradk ([email protected])
# [22:51] <dbaron> Topic: CSS Object Model
# [22:52] * Joins: BradK_ ([email protected])
# [22:52] <fantasai> [side-note wrt writing-modes] fantasai: we might want to discuss property to tailor UTR50 to handle e.g. greek/cyrillic being upright, but we can discuss that offline
# [22:52] * Quits: bradk ([email protected]) (Quit: Computer has gone to sleep)
# [22:52] * BradK_ is now known as BradK
# [22:52] <dbaron> Håkon: Anne will be at TPAC Monday and Tuesday.
# [22:52] <fantasai> jdaggett: Shouldn't Anne be here?
# [22:53] <dbaron> Daniel: Originally Scheduled for Tuesday at 9am.
# [22:53] <fantasai> howcome: I can inform him that we'll discuss this Tuesday at 9am
# [22:53] <fantasai> glazou: if he's not going to show up to discussions...
# [22:53] <fantasai> glazou: Ok, next topic
# [22:53] <fantasai> Topic: CSS Exclusions and Shapes
# [22:54] <Rossen> http://dev.w3.org/csswg/css3-exclusions
# [22:54] <dbaron> # [22:55] <fantasai> Rossen: there were two independent spec works being done by MS and Adobe before we even brought any of this to the WG, and at some point Adobe brought in original Regions and Exclusions spec, and that was halfway when almost done with our part and getting ready to propose working on Floats
# [22:55] <fantasai> Rossen: At that time we decided to see what the differences and similarities are and come up with one single spec
# [22:55] <fantasai> Rossen: CSS Exclusions was split from CSS Regions
# [22:56] <fantasai> Rossen: And since last F2F in Seattle our one major action was to redo the spec combine, css exclusions and positioned floats and present that
# [22:56] <fantasai> Rossen: And get that towards WD
# [22:56] <fantasai> Rossen: So CSS Exclusiosn and Shapes we are talking about today
# [22:56] <fantasai> Rossen: We're going to see what CSS Exclusions are and how to use them, and what the CSS Shapes are and how to use them
# [22:57] <fantasai> Rossen: The two concepts are currently separate concepts, but they actually work really well together. So keeping them in same spec for now
# [22:57] * Joins: JohnJansen ([email protected])
# [22:57] <fantasai> Rossen: CSS Exclusions
# [22:57] <fantasai> Rossen: Baic definition, it's an area that you want to preserv clear from any inline-flow layout
# [22:57] * Joins: tantek ([email protected])
# [22:57] <fantasai> Rossen: Many example sof this in magazine layouts: pull-quotes, figures with type wrapped around them, etc.
# [22:57] <vhardy> s/Baic/Basic
# [22:57] <fantasai> Rossen: In CSS we already have floats, which are like exlcusions, but we lack the ability to position them precisely
# [22:58] <fantasai> Rossen: Currently we allow exclusions to be applied to any block-level element
# [22:58] <fantasai> Rossen: so an exclusion can be any block-level element
# [22:58] * ChrisL such as ins and del
# [22:58] <fantasai> Rossen: Combined with abpso you can create some really magazine-like layouts.
# [22:58] <fantasai> Rossen: I will show slides and spec side-by-side
# [22:59] <fantasai> Rossen: So, declaring exclusions is done with the 'wrap-flow' property
# [22:59] <fantasai> Rossen: Setting it to anything other than 'auto' creates an exclusion
# [23:00] <fantasai> Rossen: 'auto' in this case is special because for regular flow elements the 'auto' value doesn't change the behavior of floats
# [23:00] <fantasai> Rossen: Exclusions can be applied on the left, right, or both sides
# [23:00] <BradK> Exclusions apply to block only, but floats turn inclines into blocks. Shouldn't they behave similarly?
# [23:01] <fantasai> Rossen: maximum picks the left or right, whichever has the most space left
# [23:01] <fantasai> Rossen: Last one is clear, which clears wrapping on both left and right
# [23:02] <TabAtkins_> scribenick: TabAtkins_
# [23:02] <TabAtkins_> jdaggett_: Is there a typo with the maximum example showing up twice?
# [23:02] <TabAtkins_> Rossen: No, the example shows what 'maximum' does when there's more room on one space or the other.
# [23:03] <TabAtkins_> szilles: 'left' and 'right' don't work vertically.
# [23:03] <TabAtkins_> fantasai: It would probably map to line-left and line-right, but it should probably just be 'start' and 'end'.
# [23:04] <TabAtkins_> fantasai: Or have them both, since they do slightly different things.
# [23:04] <TabAtkins_> jdaggett_: Why not just start and end?
# [23:04] <TabAtkins_> fantasai: If you have a design that doesn't depend on the writing direction, frex.
# [23:05] <TabAtkins_> howcome: Are there any restrictions on what elements can affect other things?
# [23:05] <TabAtkins_> Rossen: Next slide, containing model.
# [23:05] <TabAtkins_> Rossen: We're not changing things beyond what 2.1 already specifies.
# [23:05] <TabAtkins_> Rossen: We find the containing block, and that's the exclusion container too.
# [23:06] <TabAtkins_> scribenick: fantasai
# [23:06] <fantasai> Rossen: The definition we have for wrapping context is simply a collection of exclusion elements.
# [23:06] <fantasai> s/elements/areas/
# [23:06] <fantasai> Rossen: An exclusion area is the area defined by the element. Initially this is the border-box of the element
# [23:06] <fantasai> Rossen: As we'll see later on, this can be changed into a shape
# [23:06] <fantasai> howcome: I can't really parse this text here
# [23:07] <fantasai> howcome: If an abspos comse from outside, will it affect layout of a deeply-nested element?
# [23:07] <fantasai> Rossen: Does everyone understand the containing model?
# [23:07] <fantasai> Rossen: You have somewhere in a subtree of an element an abpsos element, and it positions to a containing block.
# [23:08] <fantasai> Rossen: The scope of the exclusion is the entire subtree of the containing block.
# [23:08] <fantasai> howcome: Then you have 'wrap-through' property.
# [23:08] <fantasai> Rossen: You can use that property to stop the propagation of wrap context at any level of the subtree. But in the subree only
# [23:08] * Joins: tcelik ([email protected])
# [23:09] <fantasai> Rossen shows the example of 'wrap-through' right above the 'wrap' shorthand definition
# [23:09] <fantasai> jdaggett: ...
# [23:09] <fantasai> Rossen: It's positioned and sized following CSS2.1 rules.
# [23:09] <fantasai> Rossen: Once it is positioned, it is registered as an exclusion, and the flow layout will continue from that point on, respecting that exclusion
# [23:09] <fantasai> jdaggett: The content of the exclusionary is what?
# [23:10] <fantasai> jdaggett: What goes in that div that you're absolutely positioning?
# [23:10] <TabAtkins_> Shane suggests a 'rap' property to complement 'flow'.
# [23:10] <fantasai> howcome: So 'wrap-through', it's similar to 'float-through'
# [23:10] <fantasai> Bert: No, that's different
# [23:10] * Joins: mouse ([email protected])
# [23:10] <fantasai> dbaron: That's propagation to ancestors, not descendants
# [23:10] <fantasai> howcome: If you have a and you have a float on the side, you end the element, the float continues
# [23:11] <fantasai> dbaron: Wrap through is about going through to descendants
# [23:11] <fantasai> dbaron: This model can't describe float, basically
# [23:11] <fantasai> howcome: But you're introducing a different concept.
# [23:11] <fantasai> howcome: Could we not latch onto one of the other contexts that we have?
# [23:11] <fantasai> howcome: I'm wary of introducing yet another reference model
# [23:12] * Quits: szilles ([email protected]) (Ping timeout)
# [23:12] <fantasai> vhardy: We've been bounching around on this for several months, this is what we ended up with
# [23:12] <fantasai> Rossen: We started with floats, but it had a lot of issues that we were not able to solve.
# [23:12] <fantasai> Bert: I think you're talking about something else, howcome.
# [23:13] <fantasai> Bert: The second paragraph that you (howcome) didn't draw. The wrap-through property isn't about whether the float goes through, but whether the line boxes in the second wrap around it
# [23:13] <fantasai> howcome: It's so similar to floats, we should extend floats
# [23:13] <fantasai> Rossen: .. they do create exclusions, and in this respect they're the same
# [23:13] <fantasai> Rossen: In this respect they're not completley normal. But it is the positioning that we want to address.
# [23:14] <fantasai> Rossen: Do people understand 'wrap-through'?
# [23:14] <fantasai> Rossen draws a diagram:
# [23:14] <fantasai> circle marked CB at the top
# [23:14] <fantasai> triangle extending down from it
# [23:14] <fantasai> a squiggly line extending from the circl down to a small circle inside the diagram
# [23:14] <fantasai> which then connects to the left corner of the big triangle and the middle of its base
# [23:14] <fantasai> this part is shaded
# [23:15] <fantasai> a thing on the base line on the non-shaded part points back up to the CB circl
# [23:15] * Parts: mouse ([email protected])
# [23:15] <fantasai> Rossen: wrap-through opts out of the wrapping. It's an opt-out model rather than an opt-in model.
# [23:15] <fantasai> howcome: How common is this?
# [23:15] <fantasai> howcome: If you have an exclusion, can't it just be an exclusion?
# [23:16] <fantasai> Rossen: We did have use cases for this
# [23:16] <fantasai> Bert: Say you have in that tree you draw there, the small black thing that's abspos, it pushes everything else aside.
# [23:16] <fantasai> Bert: It has wrap-flow something.
# [23:16] <fantasai> Bert: When you say wrap-trhough on the other circle, then you set wrap-flow on it.
# [23:17] <fantasai> Rossen: Then you have multiple exclusions
# [23:17] * Joins: dino ([email protected])
# [23:17] <fantasai> Alan: There was a bunch of discussion about overlapping and combining exlcusion shapes and having portions be affected by this exclusion shape and not that one, to build up more complicated layouts that have that feature that was requested.
# [23:17] <fantasai> dbaron: wrap-trhough is an attempt to do that?
# [23:17] <fantasai> Alan: You don't do it by itself, you use it with other exclusion shapes, to chose which ones you'd be affected by
# [23:18] <fantasai> Alex: ... my content doesn't wrap to anything, so the exlusions overlap but hte content flows around
# [23:18] <fantasai> Bert: THe problem I see with wrap-through, if you have a floating element there, you still want to wrap around that floating element
# [23:18] <fantasai> vhardy: Your question is if I have a float before here *draws a circle before the small circle*
# [23:19] <fantasai> vhardy: Is that float still affecting wrpaping
# [23:19] <fantasai> vhardy: In our model, we have just one wrapping context, and if you exclude them [...]
# [23:19] <fantasai> Rossen: We can scope the opt-out wrapping so that floats are not affected by it
# [23:19] <fantasai> Rossen: In otherwords, floats would still contribute as they do today
# [23:19] <fantasai> Bert: I'm still brainstorming here.
# [23:20] <fantasai> Bert: You might also on this subtree set a z-index at a high value. And then you'd be in front of the exclusion. That seems easier.
# [23:20] <fantasai> Alex: I think wrap-trhough needs a better name. I was confused for the longest time what it does.
# [23:20] <fantasai> Alex: The meaning of the property is "make this container avoid wrapping anything"
# [23:21] <fantasai> 'wrap-off'?
# [23:21] * fantasai thinks the name is fine
# [23:21] <fantasai> Rossen: wrap-through means stop the propagation of wrapping context
# [23:21] <fantasai> howcome: So it's the same as this thing I'm describing here. I'd like to have it for floats.
# [23:21] <fantasai> dbaron: What's the use case for floats?
# [23:22] <fantasai> dbaron: Why do you want this, and why do you want this here?
# [23:22] <vhardy> http://wiki.csswg.org/ideas/css3-exclusions-use-cases
# [23:23] <fantasai> Rossen shows UC2
# [23:23] <fantasai> Rossen: In this case we have 2 exclusions affecting each other as well as the context around them
# [23:24] <fantasai> *shows example of two columns of black text, wrapped around: a red circle of text in the center, which has a blue square text intersecting with it; none of the text overlaps*
# [23:24] * fantasai wants to know what happens when you increase the font size of that red circle
# [23:25] <fantasai> Rossen: One use case not in the wiki was to have for example tables, where data is really supposed to be prsented in some manner, if you want to pop out of exclusion so that the table's contents aren't affected by it
# [23:25] <fantasai> Rossen: There are layouts for which you don't want to have exclusions.
# [23:26] <fantasai> jdaggett: How does z-index affect this?
# [23:26] <fantasai> Rossen: thanks for moving us ahead
# [23:26] <fantasai> Rossen: So, once you have a wrapping context computed for an element, you have ca collection of many elements that want to be exclusions
# [23:26] <fantasai> Rossen: we need to compute their order
# [23:27] <fantasai> Rossen: By default the last item in the document will be on top of everything else
# [23:27] <fantasai> Rossen: Naturally we'd want everything else would be affected
# [23:27] <fantasai> Rossen: Ordering of exlcusions is done in painting order. And you can use z-index to reorder them
# [23:28] <fantasai> Rossen: Doing this work, at first it seemed kind of hard to wrap our heads around would z-index just work
# [23:28] <fantasai> Rossen: Interesting thing is that all of the sorting is doable just locally on that element
# [23:28] <fantasai> Rossen: You don't have to sort the entire document and figure out all of the stacking contexts in order to apply this, simply because the scope of exclusions is basically limited to the containing block
# [23:28] <fantasai> dbaron: But it covers all descendants too
# [23:28] <fantasai> dbaron: So it's not a local process. You still have to perform layout between each one.
# [23:29] <fantasai> Rossen: Not a local process. It is a two-pass layout
# [23:29] <fantasai> Rossen: in which you first lay out all of the descendants
# [23:29] <fantasai> Rossen: Not abpsos though
# [23:29] <fantasai> dbaron: Yes you do, because [...]
# [23:32] <fantasai> dbaron: because there might be an abpsos descendant that creates an exclusion, but that that abspos descendant's containing block is still a descendant of your current context, and your current context has another descendant after that also establishing an exclusion
# [23:32] <fantasai> Rossen: This second exclusion that you just discovered, its scope will be [...]
# [23:32] <fantasai> Rossen: So this exclusion cannot affect any of the sibling exclusions
# [23:32] <fantasai> dbaron: We have two abpsos containing blocks, one inside the other.
# [23:32] <fantasai> dbaron: You have an exclusion inside the first, that affects the size of it
# [23:32] <fantasai> Rossen: assume they're all abspos for simplicity
# [23:32] <fantasai> dbaron: That's one of the problems, the spec assumes that but allows for things that aren't
# [23:33] <fantasai> Rossen: Let's say that you ahve an abspos element that propagates up to this CB in the hierarchy
# [23:33] <fantasai> Rossen: These are both position absolute *dras siblings*
# [23:33] <fantasai> Rossen: And this one is also an exclusion (second one)
# [23:33] <fantasai> Rossen: When the two are to be laid out on the elvel of this containing block
# [23:33] <fantasai> Rossen: Your statement was that I also need to lay out everything inside the first abspos in rder to figure out the stacking context
# [23:34] <fantasai> dbaron: If you're doing this 2-pass thing, you just do 2 passes and get the wrong result.
# [23:34] <fantasai> Arron: The first pass finds the static position of everything.
# [23:34] <fantasai> dbaron: The static position will be wrong once you've done the second pass
# [23:34] <fantasai> dbaron: It's not just static position, it's anything that creates an exclusion that's not absoluely positioned
# [23:35] <fantasai> fantasai: Also if you position to the bottom, and your height depends on the contents.
# [23:35] <fantasai> Rossen: Oh yeah, this is a known issue.
# [23:35] <fantasai> dbaron: Fundamentally I think the absolute positioning model is the wrong thing to tie exclusions to. I'd rather connect them to the floats model.
# [23:35] <fantasai> Steve: But that gives the wrong answer
# [23:35] <fantasai> howcome: I think I support you (dbaron)
# [23:36] <fantasai> howcome: You've introduced a bunch of wrap propertis, but it doesn't affect floats, and I think it should do.
# [23:36] <fantasai> Steve: That's a separate question. Let's look at this and then see how it affects floats.
# [23:36] <fantasai> dbaron: One of the other problems with this, it sort of assumes you can apply it to things that aren't absolutely positioned.
# [23:37] <fantasai> dbaron: But if you do, that won't work well because it only affects things inside the parent
# [23:37] * fantasai didn't quite catch that
# [23:37] <fantasai> Rossen: If you want to have an exclusion which is part of the flow, say a centered float
# [23:37] <fantasai> Rossen: Today you have left float and right float, say you want a centered float.
# [23:37] <fantasai> howcome: You add float: center;
# [23:38] <fantasai> Rossen: That brings other problems. How do you interact with left and right floats?
# [23:38] <fantasai> Rossen: Right now we have left and right areas of the float which compete for space with text in the center. Now you have a region in between?
# [23:38] <fantasai> howcome: Don't you have that problem anyway?
# [23:38] <fantasai> howcome draws.
# [23:39] <fantasai> howcome: You have an exclusion here. Then you have a left float that doesn't fit. What happens?
# [23:39] <fantasai> howcome: Do you have a clear ?
# [23:39] <fantasai> howcome: By having a model that kindof interacts with floats and kindof interacts with abspos, you create all these problems in the wake
# [23:39] <fantasai> Steve: The current definition of float moves the float down until it will fit
# [23:40] <fantasai> Steve: The barrier just doesn't allow any text to appear there. So lines dont' break, but flow across it, and don't render inside it
# [23:40] <fantasai> howcome: Still sems like a viable option to me, don't see why it's not
# [23:41] <fantasai> Steve: don't have enough control over positioning
# [23:41] <fantasai> Steve: If you break it down, bunch of considerations about where things are
# [23:41] <fantasai> Steve: Takes abspos items and make them behave like floats
# [23:41] <fantasai> howcome: Why not extend floats?
# [23:41] <fantasai> Steve: Because I don't want them to move
# [23:41] <fantasai> Steve: Makes more sense to make abspos elements exclude
# [23:42] <fantasai> vhardy: A positioned float is kindof an oxymoron.
# [23:42] <fantasai> howcome: Want to explore doing it the float way
# [23:42] <fantasai> jj: that's what we've done
# [23:42] <fantasai> dbaron: Something Steve said I disagreed with
# [23:42] <fantasai> Tantek: The whole expand float vs new feature. THere are a couple methodologies to apply to think about.
# [23:43] * Quits: dino ([email protected]) (Ping timeout)
# [23:43] <fantasai> Tantek: From author's perpsective, there's a transition period. How will this behave during the transition period?
# [23:43] * Joins: bradk_ ([email protected])
# [23:43] <fantasai> Tantek: What's the fallback behavior?
# [23:43] <fantasai> Tantek: One way to explore this problem space is to consider that.
# [23:43] <fantasai> Tantek: Want to do this new exclusion thing, but not suck on these old browsers.
# [23:44] <fantasai> Tantek: Without using css-conditional, if you had two float values you can have a fallback value
# [23:44] <fantasai> Tantek: If you don't ahve a fallback, it will slow adoption.
# [23:44] <fantasai> Tantek: Other quesiton is, if new feature B is similar to old feature A. How complex is old feature A?
# [23:45] <fantasai> Tantek: If it took only a few years to do old feature A, then building on it for B make ssense.
# [23:45] <dbaron> q+ to respond to Steve's assertion that authors want it where they position it
# [23:45] <fantasai> Tantek: But if old feature A took years and years and years to get it right, then it's naive ot think new feature B can be completed quickly.
# [23:46] <fantasai> Steve: I'm wondering which of abpos and floats you think is simpler. :)
# [23:46] <fantasai> Rossen: We don't want to mess with positioning complexity of floats today. Don't want to produce yet another layer of complexity
# [23:46] <fantasai> Alex: I wanted this to CSS3 Floats module, and we should have one that includes new floats and page floats.
# [23:47] <fantasai> Alex: This spec is scoped in a way that when this new floats spec appears, it doesn't need to say anything new about exclusions.
# [23:47] <fantasai> Alex: This describes how objects with exclusions itneract with content and each other.
# [23:47] <fantasai> Alex: When we find smarter way to position floats, this should all apply.
# [23:47] <fantasai> Alex: Should be able to implement just this, and then get smarter floats.
# [23:47] <fantasai> Alex: Might be things here, like 2-pass algorithm, which is really about [...]
# [23:48] <fantasai> vhardy: One big difference with floats is that floats assume rectangular shapes, so margin collapsing [..]
# [23:48] <fantasai> fantasai: floats don't collapse margins with anything.
# [23:48] <fantasai> Steve: Point you made earlier with overlays. These are positioned. If they overlap, one takes chunk out of the other.
# [23:48] <fantasai> Steve: Simpler model, but gives you something you can't get with floats
# [23:49] <fantasai> Bert: I wonder how that example works.
# [23:49] <fantasai> Bert: The blue one is not in the flow of the containing block of the red one. The blue one has its own flow
# [23:49] <fantasai> Rossen: Wrapping context is that of the *containing block* of the exclusion.
# [23:49] <fantasai> Rossen: In this case they both hvae same containing block, so they're in the same wrapping context.
# [23:50] <fantasai> ...
# [23:50] <fantasai> howcome: So in this example, if the blue comes on top
# [23:51] <fantasai> Rossen: Then the red will wrap around it
# [23:52] <fantasai> ...
# [23:52] <fantasai> Tantek: Is the circle a fixed size? What happens to overflow?
# [23:52] * Joins: Liam ([email protected])
# [23:52] <fantasai> Rossen: haven't talked about shapes yet.
# [23:52] <fantasai> Rossen: All three elements here are exclusions, all in same containing block *shows example of three overlapping squares*
# [23:53] <fantasai> Tantek: How adaptive is this to different amounts of content?
# [23:53] <fantasai> Rossen: This one is done with overflow: hidden
# [23:53] <fantasai> howcome: If you have a newspaper article, and you want to highlight the quote, you want to make sure the full quote appears.
# [23:53] <fantasai> howcome: Your examples look good, but they cut off the text.
# [23:54] <fantasai> Tantek: So the request is to us econtent and grows it
# [23:54] <fantasai> Rossen: If the element is width or height auto, and you start excluding it, its size will change to accommodate the content.
# [23:55] <fantasai> Rossen: If the size is fixed, then it will overflow.
# [23:55] <fantasai> Tantek: I think the examples should show what designers will want, i.e. not clipping the content.
# [23:55] <fantasai> dbaron: I'd like to go back to the point Steve made about 11 minutes ago
# [23:55] * tantek wants to avoid more unintended cases of # [23:55] <fantasai> dbaron: So, when we were talkinga bout differences btw floats and positioning, Steve made the assertion that authors want things where they've positioned it.
# [23:55] <fantasai> dbaron: but thinking back to the examples Adobe showed when we met at Mozilla in the spring
# [23:56] <fantasai> dbaron: I think in a bunch of those examples, you don't want that.
# [23:56] <fantasai> dbaron: You will wind up in many cases where you're overlapping where you don't want overlap
# [23:56] <fantasai> dbaron: For example, pull quotes in the middle of a page.
# [23:57] <fantasai> dbaron: You're fine if the author can look at the resulting page on all the devices on which it will appear, and make sure there aren't two pull-quotes on the same page
# [23:57] <fantasai> dbaron: But if you have different font sizes or different page sizes and you're doing a layout like that, you don't want two pull quotes that wind up on the same page to overlap each other.
# [23:57] <fantasai> dbaron++
# [23:57] <fantasai> Steve: I agree with your example. I don't think floats do a better job, though.
# [23:58] <fantasai> Steve: If I wind up with two pull-quotes, I might want to only show one of them
# [23:59] <fantasai> Rossen and howcome discuss how to position the pull-quote
# [23:59] <fantasai> howcome: I want to put a pull-quote between 1st and 2nd column, 30% down from the top
# [23:59] <fantasai> Rossen: How many columns?
# [23:59] <fantasai> howcome: Depends on width of the screen
# [23:59] <fantasai> Steve: that gets us more into grid-addressing issue
# [23:59] * Joins: dino ([email protected])
# Session Close: Mon Oct 31 00:00:00 2011

The end :)