16:10:46 <RRSAgent> RRSAgent has joined #css
16:10:46 <RRSAgent> logging to http://www.w3.org/2011/10/30-css-irc
16:10:49 <szilles> szilles has joined #css
16:10:53 <Zakim> Zakim has joined #css
16:11:02 <Ms2ger> ScribeNick arno
16:11:28 <TabAtkins_> TabAtkins_ has joined #css
16:11:54 <glazou> glazou has joined #css
16:12:13 <Ms2ger> RRSAgent, make logs public
16:12:33 <arno> vincent: 3d interest group requested to meet w/ us
16:12:39 <arno> not on the agenda?
16:12:47 <Bert> The snow in the NE has made one victim: Florian not sure he can make today (see e-mail I just forwarded)
16:12:53 <arno> :(
16:12:58 <mollydotcom> mollydotcom has joined #css
16:13:13 <arno> Daniel: will add to agenda for Tuesday morning
16:13:28 <vhardy> vhardy has joined #css
16:13:52 <arno> Tab: variables and hierarchy
16:14:00 <arno> (nesting selectors)
16:14:08 <arronei_> arronei_ has joined #css
16:14:22 <arno> Tab: I have a proposed spec and would like sign off on "yes, we're going to do these"
16:14:36 <arno> Tab: asking on behalf of shane and luke.
16:14:50 <arno> Daniel: adding to agenda, but gut feeling: "you are going too fast"
16:14:51 <shepazu> shepazu has joined #css
16:15:05 <kojiishi> kojiishi has joined #css
16:15:16 <jarek> jarek has joined #css
16:15:59 <arno> Peter: I have a joint meeting w/ web apps at 11am
16:16:26 <arno> ??: discussion on CSS OM on tuesday morning would require david and tab, will they be there?
16:16:38 <arno> tab: yes, there's a conflict w/ a fx meeting
16:17:01 <arno> peter: no, fx meeting is on thursday
16:17:08 <arno> daniel: please update wiki accordingly
16:17:39 <arno> daniel: I did the schedule based on interest and joint meetings, it wasn't an easy task.
16:17:57 <arno> daniel: any other extra items?
16:18:00 <arno> everyone: no.
16:18:11 <jdaggett_> jdaggett_ has joined #css
16:18:14 <dbaron> Should we do a brief round of introductions?
16:18:20 <arno> daniel: first, a request from sylvain: "how should wg handle issues?"
16:18:41 <Rossen> Rossen has joined #css
16:18:45 <arno> daniel: yes, let's start with intros
16:20:02 <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)
16:21:09 <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)
16:21:21 <dbaron> (hopefully I kept to under 10 spelling mistakes)
16:21:26 <arno> daniel: back to first issue
16:21:48 <ChrisL> ChrisL has joined #css
16:21:49 <arno> sylvain: we implement a spectrum of specs at different levels
16:22:06 <shans> shans has joined #css
16:22:08 <arno> sylvain: when something is not Last Call, questions get asked
16:22:09 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Apr/0359.html
16:22:34 <arno> the question above was asked, but not answered
16:23:00 <arno> "how much normative info is laying around in the mailing list that's not incorporated"
16:23:07 <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dEdQMEtSMXFFMWJyYkVpdUtrWDB4Z3c&hl=en_US#gid=1
16:23:13 <arno> sylvain: I replied "I don't know" and people freaked out.. :)
16:23:49 <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
16:24:18 <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
16:24:34 <arno> sylvain: we shouldn't have to do this. we should have a better organized way of tracking issues.
16:24:58 <arno> dagett: we already have a tracker, no?
16:25:08 <arno> fantasai: but the editor does not keep up with the feedback
16:25:08 <TabAtkins_> TabAtkins_ has joined #css
16:25:36 <arno> sylvain: difficult to resolve differences between implementations...
16:25:47 <arno> sylvain: when we get to module, we should have a link of issues
16:25:52 <fantasai> dbaron: Of all the specs I've implemented, CSS Animations has been in the worst state
16:26:20 <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
16:26:34 <arno> vincent: not a big fan of the wiki because it's a bit too fragile, would like better method
16:27:01 <arno> daniel: it's a human process, the editor still has to do the right thing
16:27:21 <arno> fantasai: we have multiple ways
16:27:21 <dbaron> (I think there are also a bunch of animations issue that I didn't even bother to bring up on the mailing list.)
16:27:28 <bradk> bradk has joined #css
16:27:34 <arno> fantasai: different editors like different systems
16:27:49 <arno> fantasai: i use to track issues in a plain text file, and that worked great for me
16:28:20 <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
16:28:29 <arno> howcome: i think email works pretty well
16:28:33 <fantasai> fantasai: The problem is that if the editor is not tracking issues, the issues aren't being tracked. Period.
16:29:08 <arno> sylvain: when it come to disposition of comments, you shouldn't have to go through email archives
16:29:29 <arno> howcome: it's not a lack of mechanical solution, the problem is the editor needs to do the tracking
16:29:47 <arno> dbaron: i like the idea of having it in the spec
16:30:04 <fantasai> dbaron: Not nessarily as the only place to track it but as a place to track it
16:30:06 <arno> dbaron: but that doesn't mean there shouldn't be some other way of tracking it
16:30:52 <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)
16:31:02 <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
16:31:52 <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
16:32:29 <arno> chris: it's useful to be able to track issues over a long period of time, with a tracker or something else
16:33:06 <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
16:33:17 <fantasai> jdaggett++
16:33:21 <arno> fantasai: i agree with this, that's what i've done
16:33:48 <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
16:34:38 <arno> fantasai: specs currently don't link to issues
16:34:45 <arno> (in general, a few do)
16:35:31 <arno> fantasai: it's unfair to expect that others will do the work of identifying issues that need to be tracked
16:35:53 <JohnJansen> note: this is not just a problem with one spec, but is a more general issue
16:35:56 <arno> daggett: how to we deal w/ feature request which the editor think should be dealt with later?
16:36:06 <arno> fantasai: i dump it into tracker
16:36:21 <arno> alan: there's also some wiki pages that include level 4 ideas
16:36:53 <arno> tantek: i like wiki pages better, because it's easier to aggregate requests together, "since the future is fuzzier, a fuzzier mechanism helps"
16:37:01 <tantek> tantek has joined #css
16:37:10 <arno> daniel: any concrete proposal?
16:37:19 <tantek> is this on? 1 10 11 check
16:37:39 <arno> sylvain: when dino is around we should discuss w/ him
16:37:43 <Ms2ger> tantek, it is :)
16:38:04 <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?
16:38:35 <arno> tantek: it depends on where you constraint is. If it's editor's time, that's going to be the bottleneck
16:38:38 <Ms2ger> Might as well go to filing directly in bugzilla, then
16:39:23 <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
16:39:39 <arno> tantek: it's already in the spec: send a message to wwwstyle
16:39:52 <JohnJansen> ms2ger, the argument against that is that when a spec is young, bugzilla is too much overhead
16:40:12 <arno> tantek: i think it's up to the editor to track the messages to wwwstyle and track it
16:40:57 <arno> tantek: however the editor track the issue, it should be public and others should be able to add issues
16:41:19 <arno> moly: what about using some tools like stackoverflow, etc… to track?
16:41:36 <arno> tantek: there's only a handful of mechanism other than bugzilla, tracker, wiki
16:41:44 <arno> fantasai: i've used CVS/plaintext
16:41:52 <arno> tantek: someone could add to it?
16:42:03 <arno> fantasai: yes, a bit more cumbersome, though
16:42:14 <arno> chris: as long as it's publicly available
16:42:29 <arno> fantasai: yes, a local text file, spreadsheet, etc… would not work
16:42:36 <glazou> s/moly/molly
16:43:17 <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
16:43:51 <tantek> molly is talking about a discovery problem ("where are the issues?") rather than a diversity of mechanisms problem.
16:43:56 <tantek> what Steve Zilles said
16:43:57 <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
16:44:07 <tantek> one single place to track where the issues are, not one single issue tracker
16:44:21 <arno> steve: i.e. that's a per spec issue, not an issue for all specs, right?
16:44:44 <arno> steve: i propose we have, for each spec, a clear indication of where the issues are tracked
16:44:54 <tantek> fantasai - you said there are some specs that have links from their header to their issues?
16:44:57 <tantek> examples?
16:45:14 <Ms2ger> HTML has that
16:45:16 <tantek> i.e.. which spec(s)
16:45:24 <fantasai> tantek, http://www.w3.org/TR/css3-background/
16:45:51 <dbaron> For http://dev.w3.org/csswg/css3-conditional/ I've just been tracking all the issues in <p class=issue>s in the editor's draft.
16:46:06 <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
16:46:12 <tantek> so none of those have links from the header
16:46:32 <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
16:46:42 <arno> fantasai: so, each spec must have a clear, publicly accessible way of tracking issues
16:46:53 <arno> fantasai: each module
16:46:58 <Ms2ger> And note that nobody reads the SotD :)
16:47:09 <fantasai> RESOLVED: Each module must have one publicly-accessible, CSSWG-editable way of tracking issues.
16:47:25 <sylvaing> http://dev.w3.org/csswg/css3-positioning/
16:47:31 <arno> tantek: the examples above are burried in the spec
16:48:38 <fantasai> RESOLVED: Add link to issues list from spec header
16:48:40 <arno> daniel: who's in favor of the RESOLVED issue above
16:48:42 <arno> ?
16:48:56 <arno> daniel: (from show of hands): OK, resolved
16:49:30 <arno> daniel: i'm not satisfied with a different system for each spec
16:49:51 <arno> daniel: you have to adapt yourself for each one, and it's difficult when you're tracking 30 specs
16:50:15 <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
16:50:20 <arno> daniel: that's a good compromise
16:50:36 <arno> steve: we have 3: wiki, tracker and bugzill
16:50:45 <Ms2ger> And plaintext in CVS
16:51:14 <arno> dbaron: and there's another one: track everything in the draft
16:51:50 <arno> alan/tantek: do you keep a log of the resolved issues
16:52:02 <arno> dbaron: no, the CVS log is the log...
16:52:06 <arno> daniel: <squirms>
16:52:20 <arno> tantek: so you're saying that twitter is the log, then...
16:52:26 <tantek> here's an example of a spec which has links in the header to both editor's draft and issues list: http://dev.w3.org/csswg/css3-ui/ 
16:52:30 <arno> tab: i use the same system as david, and it works for me
16:52:39 <arno> alexm: with multiple editors it can get complicated
16:53:06 <arno> fantasai: i use different systems, depending on the lifecycle of the spec. 
16:53:28 <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
16:53:40 <plinss> plinss has joined #css
16:53:41 <arno> fantasai: at the end, i use a plaintext file
16:54:04 <arno> daniel: let's close on steve's proposal
16:54:41 <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)
16:54:42 <arno> daniel: when using inline issue tracking, still indicate that in the header
16:55:24 <plinss__> plinss__ has joined #css
16:55:41 <arno> fantasai: we have the WD and the Editor's draft.
16:55:59 <arno> fantasai: they may have separate issues list
16:56:21 <arno> vincent: the current list of issues is related to the ED, not the WD
16:56:54 <arno> fantasai: it's snapshotted if you track it inline, but otherwise the link to a separate issue tracker may get out of sync
16:57:03 <arno> fantasai: maybe only have the link on the ED
16:57:28 <arno> steve: no, too many people get to the WD than the ED, and then you will end up in the wrong issue list
16:57:43 <arno> molly: agree, we need to coalesce, rather than fragment
16:58:03 <arno> vincent: if you do inline issue tracking, that resolves it
16:58:33 <arno> fantasai: could be resolved if the link to issues in the WD point to the ED issues list
16:59:14 <alexmog> alexmog has joined #css
16:59:41 <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
17:00:25 <arno> tantek: maybe we need a warning in the WD that makes it clear it's out of date...
17:00:46 <arno> chris: when it's published as a TR it should not include the list of issues anymore
17:01:13 <Ms2ger> Why not?
17:01:46 <alexmog> alexmog has left #css
17:01:47 <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
17:02:17 <arno> daniel: i don't know how to tweet this
17:02:47 <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
17:02:50 <arno> daniel: issue trackers used: bugzilla, wiki, tracker, inline
17:03:32 <arno> RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.
17:04:04 <arno> fantasai: it was really hard with CSS 2.1
17:04:12 <arno> tantek: let's not have big specs like that anymore
17:04:16 <tantek> :)
17:04:38 <alexmog-> alexmog- has joined #css
17:05:06 <arno> fantasai: how do we track 300 issues on one wiki page? doesn't seem to scale
17:05:22 <tantek> we can cross that bridge when we reach it
17:05:38 <arno> johnjansen: that's why i like bugzilla better to do the tracking
17:06:06 <arno> vincent: maybe it depends on the lifecycle, later on in the spec's life, using bugzilla may be better
17:06:59 <arno> fantasai: not asking for a WG resolution, but sharing my experience
17:07:28 <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
17:07:43 <arno> steve: could we have this recorded in the wiki or somewhere
17:07:52 <arno> daniel: i agree that best practices are needed
17:07:58 <tantek> here: http://wiki.csswg.org/spec#specification-editing
17:08:08 <arno> daniel: what should happen if an editor doesn't track issues?
17:08:16 <arno> daniel: spanking the editor?
17:08:52 <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
17:09:18 <arno> tantek: after step 1 (talking to the editor), you could also suggest adding a co-editor
17:09:30 <arno> tantek: or even assign a co-editor
17:09:35 <arno> tantek: that's worked in the past
17:09:51 <arno> daniel: you need to know there's an issue with the issue tracking
17:10:07 <arno> tantek: if the ED gets more than 1 year out of date...
17:10:25 <arno> tantek: there are past signals and procedure that seem to have fixed it
17:10:52 <arno> tab: re: issue tracking and bugzilla, there's only 5 components in it right now. could we add all components?
17:11:03 <arno> johnjansen: yeah, how do we do that
17:11:53 <arno> solution: mail mike smith (or bert) to ask the components to be added in bugzilla
17:12:04 <arno> sylvain: we have 1 hour tomorrow for animation
17:12:27 <arno> sylvain: i have some technical discussion that needs to hapen
17:12:56 <arno> bert: maybe that's a topic for the plenary
17:13:06 <arno> tantek: there are several issue re: specs
17:13:16 <arno> tantek: sounds like you want to lead a discussion
17:13:20 <arno> bert: no, not really...
17:13:43 <arno> daniel: anything else about spec editing/tracking?
17:14:06 <arno> plinns: that makes me want to build a tool. would people use it?
17:14:20 <arno> tantek: might be worth looking at hixie's tool'
17:14:47 <arno> tab: it's easy to deal with
17:14:59 <arno> daniel: yes, select all and resolve as invalid :)
17:15:13 <arno> fantasai: you could improve tracker, most of its problems are UI issues
17:15:34 <arno> fantasai: we have so many systems because all of them kinda suck
17:15:48 <arno> tantek: who does the IT for bugzilla/tracker?
17:16:02 <arno> chris: it's the systems team
17:16:13 <tantek> URL?
17:16:40 <arno> daniel: let's close this agenda item and move on the next one
17:16:51 <arno> daniel: let's move to css regions
17:18:13 <arno> vincent: <showing slides>
17:18:22 <arno> my.adobe.acrobat.com/silverman
17:18:36 <arno> vincent: css regions (alex and vincent)
17:18:45 <arno> css exlcusions (rossen and vincent)
17:18:58 <arno> css fragmentations (eliak and rossen)
17:19:11 <arno> vincent: ED after the tokyo meeting
17:19:11 <howcome> howcome has joined #css
17:19:15 <dbaron> Is positioned floats part of one of those three parts?
17:19:34 <arno> vincent: most issues have been worked out, except the ones to review today
17:19:46 <arno> vincent: 2 implementations in progress (IE and WebKit)
17:20:12 <arno> vincent: would like to resolve some issues today and publish a new WD
17:20:44 <arno> vincent: positioned floats is another module (not the three parts above)
17:20:44 <dbaron> vincent: positioned floats is a 4th part
17:21:00 <szilles> szilles has joined #css
17:21:26 <arno> vincent: issue tracked in the spec, and the wiki has a list of resolved issues and no longer in the spec
17:21:46 <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
17:22:56 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
17:22:57 <arno> howcome: i have concerns with the current regions approach
17:23:26 <arno> howcome: we need them, but it doesn't discuss two issues that seem important: pagination and auto-generation of boxes
17:23:55 <arno> max: currently done by script, using OM
17:24:17 <arno> alan: to have the entire content displayed, you need a page template mechanism
17:24:31 <arno> howcome: multicol is already doing auto-generation
17:24:52 <arno> alex: we use at multiple use cases, and there are so many cases that you need script anyway
17:25:05 <arno> howcome: i'd love to see the use cases.
17:25:44 <arno> alex: for some use cases you need script, but maybe we can have a subset that does auto-generation
17:25:48 <stearns> you can display the entire content (by having the last region overflow)
17:26:43 <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
17:27:04 <fantasai> didn't Bert have a proposal in css3-template that solved this kind of problem?
17:27:15 <arno> steve: some way of having master pages that can be combined through an auto-generation mechanism to do this
17:27:15 <Bert> q+ 
17:27:39 <arno> steve: multicol seems too weak to deal with this
17:28:41 <arno> howcome: i'd like to approach this by looking at use cases
17:29:52 <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.
17:30:10 <arno> vincent: there's a lot that can be done with regions, and we'd like to work on pagination as well
17:30:37 <arno> vincent: regions was a common denominator across all the use cases we looked at
17:30:59 <arno> howcome: i think two things regions must address are pagination and auto-generation
17:31:19 <arno> steve: i'm confused: neither of these things have to do with pages, pages is a separate module
17:31:35 <arno> howcome: i think we're using the terms differently
17:32:30 <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*
17:32:36 <arno> howcome: when you apply a style sheet to another document, you should still be able to see the content
17:33:20 <arno> steve: regions doesn't resolve all problems. it's one building block, that can be chained with others.
17:34:11 <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
17:34:49 <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
17:35:42 <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
17:36:25 <dbaron> ack Bert
17:36:44 <arno> bert: I did some work past few days to integrate regions spec in template layout
17:37:18 <arno> bert: for repeating, not completely worked out, but should possible to put a template in a column.
17:37:40 <Bert> -> https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#repeating-templates note about combining columns and regions (i.e., templates)
17:37:52 <arno> bert: all w/ same mechanism, you only need a selector to select a column and a column in a page
17:38:48 <arno> howcome: can we see the use cases?
17:38:59 <arno> daniel: have them in the spec
17:39:02 <Bert> action bert: move template layout to dev.w3.org
17:39:03 <trackbot> Created ACTION-374 - Move template layout to dev.w3.org [on Bert Bos - due 2011-11-06].
17:39:27 <arno> vincent: we don't have use cases in specs in general
17:39:41 <arno> daniel: maybe in an appendix
17:39: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. :)
17:40:07 <Ms2ger> fantasai++
17:40:25 <arno> molly: there's a convention in publishing, if it's a screenshot it's not considered proprietary
17:41:03 <arno> howcome: we need to see the use cases
17:41:17 <arno> howcome: we need to support auto-generation
17:41:23 <tantek> would be useful to capture/see the use-cases in the spec that drove the design. in an Appendix is fine.
17:41:25 <arno> howcome: we need pagination
17:41:46 <fantasai> hwocome^: Shouldn't have to resort to scripting.
17:42:04 <arno> vincent: agree with it, but our take was that pagination and auto-generation were not going to be covered in regions spec
17:42:20 <arno> steve: shouldn't it be in the paginated media module?
17:42:38 <arno> howcome: that would be fine, but the specs should evolve at the same time
17:43:42 <arno> alex: i think you're trying to do a simple page flipper, it would be great to support that
17:44:31 <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
17:44:32 <arno> vincent: multicol serves multiple purpose, it's both a template and a way to paginate
17:44:48 <fantasai> vincent: That's issue 12, whether to have multicol as regions
17:44:58 <arno> alex: i think we need to talk about it and decide which spec it belongs to
17:45:29 <fantasai> vincent: auto-generation goes much further than just that
17:45:43 <arno> steve: i think we should record the issue that howcome is raising
17:46:53 <arno> alex: i think pagination/fragmentation is a fundamental feature of layout. the region spec is about how to provide this boundary
17:47:10 <arno> howcome: i just want to know how to print documents with regions on them
17:47:20 <arno> daniel: we have 15min remaining. let's move one.
17:47:26 <arno> s/one/on/
17:47:28 <glazou> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
17:47:55 <arno> vincent: do we want multicol elements to be regions or not
17:48:06 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions
17:48:26 <arno> fantasai: i'm in favor
17:48:57 <arno> alex: i like that idea too, add very little complexity to implementation
17:49:56 <arno> alex: if there's a region and you set column = 2, you get a region with two columns
17:50:04 <ChrisL> rrsagent, here
17:50:04 <RRSAgent> See http://www.w3.org/2011/10/30-css-irc#T17-50-04
17:50:27 <tantek> <aside> just stubbed http://wiki.csswg.org/spec/issue-tracking - please review and feel free to improve </aside>
17:50:33 <arno> rossen: overflow would be interesting in that case
17:51:06 <arno> rossen: this would lead to introducing fragmentation
17:51:20 <arno> steve: seems like the AI is "how should it be done or why it shouldn't be done"
17:52:26 <arno> jdaggett: is the question something with both multi-column and region, what happens?
17:52:45 <arno> jdaggett: where does the spec forbid it?
17:53:04 <arno> section 4.2
17:53:04 <tantek> <aside> also lurking in #tpac as a general back-channel for this week </aside.
17:53:08 <vhardy> http://dev.w3.org/csswg/css3-regions/#the-flow-from-property
17:53:43 <arno> howcome: multicol only changes how things are laid out inside the element
17:54:12 <arno> howcome: i don't understand how multicol would be any harder...
17:54:33 <arno> alex: some work needs to happen, because overflow behavior is different
17:55:01 <arno> howcome: i don't understand why we need a proposal
17:55:28 <arno> daniel: we need a proposal, alex/vincent come back to the group when you have one
17:55:47 <arno> action vincent: bring a proposal for interaction between multicol and region
17:55:47 <trackbot> Created ACTION-375 - Bring a proposal for interaction between multicol and region [on Vincent Hardy - due 2011-11-06].
17:55:51 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
17:56:14 <arno> alex: issue 19: special behavior of iframe.
17:56:36 <arno> alex: two implementations (IE and webkit) have different behavior. need to reconcile.
17:56:58 <arno> alex: need some sort of indirection mechanism
17:57:09 <arno> fantasai: how does it related to the seamless attributes in HTML5
17:57:38 <arno> ??: seems like allowing flowing of content is not specific to regions
17:57:44 <fantasai> s/??/hober/
17:58:04 <fantasai> alex: seamless also allows transparency wrt scripting and style rules
17:58:14 <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
17:58:30 <arno> alex: i would like advice
17:58:46 <arno> tab: i am scared of this, esp. re: security
17:58:58 <arno> tab: this would allow arbitrary interaction with layout
17:59:06 <arno> alex: currently restricted to same origin
17:59:18 <arno> fantasai: seems like the switch should be at the HTML level
17:59:29 <dbaron> hober: certainly not at the regions level
17:59:59 <arno> tab: i don't think we should tie a "transclusion" property with regions
18:00:06 <arno> molly: i think it should be in html5
18:00:07 <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
18:00:26 <Bert> (Sounds like this already exists: XInclude)
18:00:30 <arno> tab: we should make a separate spec for it
18:01:00 <fantasai> s/it/transclusions/
18:01:31 <arno> steve: you can put the iframe in the flow, but not the content of the iframe
18:01:51 <arno> tab: the content of iframes are a black box to css
18:02:10 <arno> johnjansen: you get the security protection by using iframe
18:02:24 <fantasai> tab: the security concern is in the other direction
18:02:35 <arno> rossen: the core of the problem is do we allow external content to flow through regions? if we do, we need a way
18:02:41 <arno> daniel: what's the use case
18:03:00 <arno> rossen: digital publishing that pick up articles from various sources, and aggregates them
18:03:12 <arno> daniel: seems like it could be a feature we add later
18:03:27 <arno> dbarron: doesn't seem specific to Regions
18:03:32 <fantasai> s/dbarron/dbaron/
18:03:33 <arno> molly: or CSS at all. seems like HTML
18:03:56 <arno> alex: looks like we don't have a proposal, and that's what IE is going to ship
18:04:12 <arno> hober: it could be anywhere it's appropriate
18:04:33 <Bert> (B.t.w., https://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-width-and-height-properties defines 'height: complex' to deal with SEAMLESS (although it predates the invention of that attribute.)
18:05:26 <arno> daniel: it reminds of the time when features where implemented before discussions
18:05:40 <arno> daniel: and it gives me a bad feeling
18:06:08 <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"
18:06:30 <arno> alex: i disagree w/ the statement that we don't care about it
18:06:50 <fantasai> +!
18:06:53 <fantasai> +1
18:07:30 <arno> action alex: remove text about special iframe behavior and alex to write proposal about the behavior of iframe
18:07:30 <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].
18:25:11 <tantek> tantek has joined #css
18:26:02 <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
18:26:02 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
18:26:10 <fantasai> ScribeNick: fantasai
18:26:22 <fantasai> vhardy: Should this event be synchronous or asynchronous
18:26:35 <fantasai> vhardy: IE implemented as async, seemed to work with demos they built
18:26:41 <fantasai> alex: Not sure how to make it synchronous
18:26:57 <fantasai> vhardy: If no convincing argument for sync, then making it async
18:27:04 <fantasai> dbaron: Are you defining exactly how it's async?
18:27:14 <fantasai> alex: Sync would be defining exactly in what order it happens
18:27:31 <fantasai> alex: async means that some layout process has happened in this region, and you're notified of that
18:27:33 <plinss> plinss has joined #css
18:27:47 <fantasai> dbaron: i agree with making it async. Might need more detail at some point
18:28:00 <fantasai> RESOLVED: regionLayoutUpdate is an asynchronous event
18:28:15 <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content
18:28:24 <fantasai> vhardy: interplay of flow-from and content
18:28:28 <fantasai> vhardy: which one has precedence?
18:28:44 <fantasai> vhardy: We had resolved to say that flow from property gets used in place of ocntent for associating an element with a flow
18:29:06 <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
18:29:21 <fantasai> vhardy: My request is to close the issue unless we have a problem to discuss?
18:29:53 <fantasai> vhardy: I'd rather close it, and reopen if you have a specific objection
18:29:58 <fantasai> fantasai: I'm ok with that.
18:30:12 <fantasai> Bert: flow-from is on regions, content is on elements. So they don't interact.
18:30:29 <fantasai> vhardy: flow-from makes something a region
18:31:24 <fantasai> Bert: There are various ways to make regions, but content is on an element.
18:31:49 <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
18:32:08 <fantasai> howcome: Bert's point is that you're using an element to create a region. You could create a region without an element
18:32:32 <fantasai> RESOLVED: close issue 18, reopen if needed later
18:32:34 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-23should-regions-be-non-breakable
18:32:54 <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence
18:32:59 <fantasai> vhardy: content vs. flow-from precedence
18:33:14 <fantasai> vhardy: On mailing list there was overwhelming preference for 'content' to take precedence
18:34:43 <fantasai> fantasai: The 'normal' value of 'content' would compute to using flow-from when available
18:35:25 <fantasai> discussion of using 'content' to override content
18:36:13 <fantasai> alex: flow-from blows away whatever content is there. Why shouldn't it be more important than 'content'.
18:36:29 <TabAtkins_> TabAtkins_ has joined #css
18:37:06 <fantasai> vhardy: So we have a proposal from several to have 'content' != 'normal' override, and other is to have 'flow-from' always override.
18:37:29 <fantasai> alex: If we had display-inside: region, then 'content' would be irrelevant
18:38:03 <fantasai> alex: flow-from is two properties in one
18:38:59 <fantasai> fantasai: 'content' property is supposed to be the master switch for what the contents of this element ar.
18:39:06 <tcelik> tcelik has joined #css
18:39:45 <szilles> szilles has joined #css
18:40:47 <dbaron> fantasai: I don't like having properties that unilaterally override other properties.
18:41:02 <dbaron> fantasai: That always leads to problems.
18:41:32 <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
18:42:31 <fantasai> Bert: A different solution, apart from needing two properties, the model doesn't have to be one overriding the other.
18:42:42 <fantasai> Bert: In Template module, if two pieces of content go into the same slot, they add up
18:42:55 <fantasai> alex: So if there's content in the region, then it's appended to the flow?
18:43:06 <fantasai> vincent: You would include the element's content, and the append the flow
18:43:26 <fantasai> molly: from a developer perspective, 'content' should be about the content.
18:44:56 <fantasai> discussion of applying 'content' to an image
18:45:18 <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"
18:46:46 <fantasai> RESOLVED: If 'content' computes to 'normal', then the element takes the flow
18:48:44 <szilles> szilles has joined #css
18:48:48 <TabAtkins_> TabAtkins_ has joined #css
18:49:57 <fantasai> fantasai explains the 'content' property and its various values and effects on elements, pseudo-elements, replaced elements, etc.
18:50:28 <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-20list-of-region-style-properties
18:50:39 <vhardy> http://dev.w3.org/csswg/css3-regions/#the-at-region-style-rule
18:51:00 <fantasai> vhardy: The @region doesn't have the pseudo-selector ppl didn't like
18:51:16 <fantasai> vhardy: The number of properties that apply listed in that link, font proeprties, background properties, simple rendering properties
18:51:23 <fantasai> vhardy: Also includs borders/marginsp/adding, 
18:51:37 <fantasai> vhardy: We explain why some things that apply to layout might make sense here
18:52:30 <fantasai> vhardy: there's a simplified list of properties that can apply to regions, but it's now more than ::first-line
18:52:46 <fantasai> vhardy: In our impl experience, this has been ok
18:52:57 <fantasai> alex: multi-col properties?
18:53:07 <fantasai> vhardy: The multi-col isn't on the flow content, it's on the region itself
18:53:22 <fantasai> alex: We should have an element there, say <article> as 3 columns... flows into a 1 column region
18:53:32 <fantasai> alex: Could choose to have 1 col in one region and 3 col in another region
18:53:55 <fantasai> vhardy: You can't change the layout nature, e.g. display/position
18:54:01 <fantasai> vhardy: multicol... I guess it's halfway
18:54:13 <fantasai> vhardy: I guess we could add it
18:54:50 <fantasai> dbaron: Does this specify somewhere how the cascading and inheritance works?
18:55:03 <fantasai> vhardy: yes, somewhere there
18:55:09 <fantasai> dbaron: .... specificity isn't the issue
18:55:18 <fantasai> howcome: It's multiple inheritance, isn't it.
18:55:29 <fantasai> Bert: It's the ::first-line problem.
18:55:52 <fantasai> fantasai: Can we put ::first-line into the regions spec so you can solve all the problems at the same time? :)
18:56:17 <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.
18:56:43 <fantasai> ...
18:56:53 <fantasai> howcome: if you set 1.2em on something inside a region, what does it refer to?
18:57:08 <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
18:57:24 <fantasai> howcome: I have a region, and I set font-size on that. And it's applied
18:57:43 <fantasai> howcome: And I have a span inside it that sets 1.2em. What is it relative to?
18:58:11 <fantasai> vhardy: If you set it on the region then it doesn't inherit
18:58:18 <fantasai> Steve: You can't have it both ways.
18:58:34 <fantasai> Steve: If you set it on the region and it affects the text, it inherits into that element
18:58:52 <fantasai> howcome: What if you set 'inhert'?
18:59:06 <fantasai> Steve: I wouldn't answer that question hastily...
18:59:13 <fantasai> Steve: ::first-line has the same problem
18:59:23 <fantasai> dbaron: This is very different from ::first-line actualy
18:59:32 <fantasai> dbaron: I'd like the example in the spec to not use pseudo-syntax, use real syntax
18:59:40 <fantasai> jdaggett agrees
18:59:49 <fantasai> jdaggett: I'd like the examples to show what an author might use, not just region1 region2
19:00:07 <fantasai> Steve: dbaron, I thought you said ::first-line effectively introduced an element around that thing, so inheritance would go to the first line
19:00:31 <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
19:00:50 <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.
19:01:06 <fantasai> howcome: It says font size in percentages refers to inherited font-size
19:01:38 <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.
19:01:47 <fantasai> dbaron: This model gives elements multiple styles essentially.
19:02:00 <fantasai> dbaron: And 2.1 is writen assuming that an element has *a* computed value for a property
19:02:06 <fantasai> Tab: All the specs are written with that assumption
19:02:16 <fantasai> dbaron: This is more box tree stuff
19:03:20 <fantasai> fantasai: We're introducing the term "fragment" to talk about pieces of the box in the box tree when it's broken
19:03:26 <fantasai> fantasai: might help with discussing this
19:03:47 <fantasai> Bert: I also have 'vertical-align', works like in table cells
19:04:15 <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?
19:04:28 <fantasai> (talking about properties that are set on the region)
19:04:44 <fantasai> Rossen: This is about the properties that are propagated to the contents of the region
19:05:08 <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
19:05:20 <fantasai> Rossen: If we allow regions to specify font-size, this would be equivalent to changing initial font size on the fly
19:05:23 <umbridge> umbridge has joined #css
19:05:33 <fantasai> Rossen: Once you're inside, you start again from the root
19:05:44 <fantasai> Rossen: Like howcome pointed out, this is multiple inheritance, no kidding
19:06:02 <fantasai> Rossen: you won't know your font size until you lay out the part of the element that you're computing
19:06:17 <fantasai> Rossen: Simplest example is body with 100em width
19:06:30 <fantasai> Rossen: It appears in 2 regions, one with 10px font size and one with 100px fontsize
19:06:39 <fantasai> Rossen: In this model you will have to recompute the body size
19:06:39 <umbridge> umbridge has left #css
19:06:53 <fantasai> vhardy: No, right now all inheritance happens through the element tree
19:07:04 <fantasai> vhardy: you're adding selectors that apply to fragments
19:07:14 <fantasai> ...
19:07:27 <fantasai> vhardy: In our model, you'll set a selector: if my H1 is in this region, here's the font size that applies
19:07:44 <fantasai> howcome: in that sense you don't have multiple inheritance
19:07:59 <fantasai> Steve: the multiple inheritance is when you have different pieces of the block that get different styling
19:08:07 <fantasai> CHrisL: Similar to ::first-letter multiple inheritance
19:08:11 <fantasai> dbaron: no, I don't think it is
19:08:16 <fantasai> dbaron: Wanted to bring up 2 other things
19:08:28 <fantasai> dbaron: Thing you said about percentages relative to the original, that sounded wrong to me.
19:08:45 <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
19:08:55 <fantasai> dbaron: Percentages etc. would compute relative to those styles until you're back outside of that region
19:09:08 <fantasai> dbaron: I don't think multiple inheritance is the right way to think about that.
19:09:25 <fantasai> dbaron: Other thing I wanted to mention is, if we think about it that way
19:09:37 <fantasai> dbaron: Then any property that takes lengths can change as a result of font-size changes.
19:09:55 <fantasai> dbaron: It seems silly to restrict that then, i.e. only allow changes as a result of font-size but not arbitrarily otherwise.
19:10:20 <fantasai> dbaron: Basically if you have @region head { body {font-size: 2em; }}
19:10:36 <fantasai> s/}}/}/
19:10:43 <fantasai> }
19:10:50 <fantasai> h1 { height: 2em; }
19:11:03 <fantasai> dbaron: Your body font size is going to be double your HTML font size as it flows into this region.
19:11:15 <fantasai> dbaron: your h1 initial font size is specifid in ems
19:11:29 <fantasai> dbaron: If you accept what steve and I say, then the h1 is going to be proportionally larger
19:11:36 <fantasai> dbaron: but what you said earlier is that it wouldn't be
19:11:53 <fantasai> Steve: So I thought what yoy said is that you're overlaying styles on these elements using selectors
19:12:07 <fantasai> Steve: so you'd walk up the tree and see the overlaid styles
19:12:19 <fantasai> vhardy: ... this is why the properties only make sense ..
19:12:29 <fantasai> vhardy: height doesn't make sense to apply to different fragments of the div
19:12:36 <fantasai> steve: height has to look somewhere for its value
19:12:49 <fantasai> vhardy: So that's something you'd have to compute relative to the parent element
19:13:04 <fantasai> vhardy: If my h1 is in the head region, will it be base don that value or the other one
19:13:13 <fantasai> vhardy: I'll take an action item on that.
19:13:30 <fantasai> howcome: We all wanted to have a use case appendix, wasn't recorded as an action item.
19:13:38 <fantasai> ACTION vhardy: Make a use case appendix
19:13:38 <trackbot> Created ACTION-377 - Make a use case appendix [on Vincent Hardy - due 2011-11-06].
19:13:46 <fantasai> <br type=lunch>
19:13:56 <glazou> br is empty :-)
19:14:52 <mollydotcom> but lunch is presentational :P
19:15:27 <ChrisL> <br type="lunch" dur="60min" />
19:33:05 <szilles> szilles has joined #css
19:36:58 <arronei_> arronei_ has joined #css
19:43:31 <sylvaing> sylvaing has joined #css
19:55:15 <bradk> bradk has joined #css
19:58:14 <guacamole> guacamole has joined #css
19:59:03 <guacamole> guacamole has left #css
20:04:21 <dbaron> ScribeNick: dbaron
20:04:28 <dbaron> Topic: Orientation and unicode properties for vertical text layout
20:04:31 <szilles> szilles has joined #css
20:04:32 <jdaggett_> http://www.unicode.org/reports/tr50/
20:04:34 <glazou> "Orientation and Unicode properties for vertical text layout"
20:04:37 <tantek> tantek has joined #css
20:05:05 <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.
20:05:41 <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.
20:05:58 <dbaron> jdaggett: The current spec has an appendix which gives an algorithm; I don't know whether it's currently marked as normative.
20:06:27 <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.
20:06:50 <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.
20:07:05 <dbaron> jdaggett: There's a comment period now, and there will be another review period.
20:07:26 <jdaggett_> http://wiki.csswg.org/spec/utr50
20:07:28 <dbaron> Eric: Process-wise, UTC meets next week.  Then produce a draft version of the TR and have another round of review.
20:07:42 <dbaron> jdaggett: These http://wiki.csswg.org/spec/utr50 are Elika's and Koji's comments as to different issues.
20:08:02 <dbaron> jdaggett: Very clear for ideographic and alphabetic characters, but there are a number of character ranges where it's more difficult to decide.
20:08:10 <jdaggett_> http://www.unicode.org/reports/tr50/bycp.html
20:08:30 <dbaron> jdaggett: http://www.unicode.org/reports/tr50/bycp.html is the proposed list of codepoints and how they change
20:08:39 <jdaggett_> http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf
20:09:10 <dbaron> jdaggett: http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf is a PDF that shows ... scroll down to U+2000 ...
20:09:49 <dbaron> jdaggett: These are some general punctuation characters.  Green column shows the vertical alternate that exists in the font (Hiragino Mincho, Kozuka Mincho, Meiryo).
20:10:04 <dbaron> jdaggett: Where the character in the green column is different it means there's a vertical alternate for that codepoint.
20:10:22 <dbaron> jdaggett: U+2014, em-dash, no fonts have vertical alternates for it
20:10:28 <dbaron> ?: Using the VERT feature for this?
20:10:54 <dbaron> ?: In Kozuka font, U+2014 is proportional -- covered by VRT2 but not by VERT.
20:11:17 <dbaron> ?: In vertical, you do want U+2014 rotated to go along with other Latin characters that get rotated as well.
20:11:31 <dbaron> jdaggett: On the Mac it's natural to use U+2014, on Windows it's natural to use U+2015.
20:11:40 <dbaron> ?: In our fonts it's also a distinction between proportional and full-width.
20:12:02 <dbaron> jdaggett: When you say proportional, the expectation is that it will be set sideways.
20:12:09 <dbaron> ?: do that with VRT2
20:12:31 <dbaron> jdaggett: scroll down to the arrows... high U+2190s
20:13:10 <dbaron> jdaggett: See that the arrows are ... U+2190 pointing to the text that's coming before it
20:13:19 <dbaron> jdaggett: I also have how the current IE and WebKit implementations handle this.
20:13:34 <dbaron> jdaggett: These may not be totally accurate because it's a little tricky to figure out.
20:13:42 <ChrisL> http://www.microsoft.com/typography/otspec/features_uz.htm#vert  http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
20:13:49 <dbaron> jdaggett: The problem we want to solve is that we don't want different implementations handling this differently.
20:14:11 <dbaron> jdaggett: Once Unicode has a property that establishes this we have firmer ground to make text-orientation consistent across implementations.
20:14:32 <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.
20:15:33 <tcelik> tcelik has joined #css
20:15:41 <Liam> Liam has joined #css
20:15:56 <dbaron> Bert: Looks like an issue for Unicode, not us.
20:16:06 <dbaron> jdaggett: Right now our spec is defining an equivalent of this.
20:16:19 <dbaron> fantasai: Yes, once Unicode defines this we will reference it.
20:16:56 <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.
20:17:09 <dbaron> fantasai: Details of code ranges don't need the whole room.
20:17:25 <dbaron> SteveZ: In other words, if you think you care, look at these documents (wiki, tr50) and comment.
20:17:51 <dbaron> jdaggett: We have two browser implementations of vertical text, and it would be nice if the implementors ...
20:17:59 <dbaron> fantasai: ... looked at this and made comments as appropriate.
20:18:10 <dbaron> jdaggett: There's wide variation between existing implementations.
20:19:22 <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.
20:19:42 <dbaron> Topic: Gradients
20:20:31 <bradk> http://wiki.csswg.org/ideas/radial-gradients
20:20:33 <dbaron> ACTION hober to review Unicode TR50 and compare to existing implementation
20:20:33 <trackbot> Created ACTION-378 - Review Unicode TR50 and compare to existing implementation [on Edward O'Connor - due 2011-11-06].
20:20:39 <dbaron> ACTION sylvain to review Unicode TR50 and compare to existing implementation
20:20:39 <trackbot> Created ACTION-379 - Review Unicode TR50 and compare to existing implementation [on Sylvain Galineau - due 2011-11-06].
20:21:12 <dbaron> Topic: ?
20:21:20 <dbaron> Bert: You said you wanted to publish regions as well?
20:21:24 <jdaggett_> s/TR/UTR/
20:21:40 <dbaron> Bert: I also wanted to ask if we could publish a new template layout module.
20:21:58 <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?
20:22:21 <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.
20:22:29 <dbaron> jdaggett: replacing the pseudo-code with real code
20:22:38 <dbaron> Håkon: maybe put in a couple of use cases
20:22:53 <dbaron> s/Topic: ?/Topic: publishing template and regions/
20:23:13 <dbaron> SteveZ (?): There are use cases on the wiki.
20:23:26 <dbaron> RESOLVED: publish regions and template if there are no objections in 2 weeks
20:23:35 <dbaron> Topic: Gradients
20:23:45 <dbaron> Tab: I assume everybody has read all the mailing list discussion on the subject. :-)
20:23:49 <dbaron> http://wiki.csswg.org/ideas/radial-gradients
20:24:14 <dbaron> Tab: We have 2 proposed syntaxes for radial gradients.  The one in the draft and brad's simplification of it.
20:24:23 <dbaron> Tab: The differences between them at this point are that:
20:24:33 <dbaron>  - draft allows arbitrary position; brad allows center/side/corners only
20:24:46 <dbaron>  - draft allows more options sizing the gradient; Brad has just circle or ellipse that fills the box
20:24:55 <dbaron> Tab: The question is which one we're going to keep.
20:25:14 <dbaron> Tab: This is the only remaining issue with css3-images; want to move to LC.
20:25:27 <dbaron> fantasai: Do a pre-LC TR draft first.
20:25:41 <dbaron> Brad: When we did linear gradients, we simplified it and made it easy to understand and learn.
20:26:00 <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.
20:26:13 <dbaron> Brad: I think the layering of different properties that affect the length of the gradient line in different ways.
20:26:21 <dbaron> Brad: In some cases position makes the gradient line larger or smaller.
20:26:50 <dbaron> Brad: To understand what's going on you have to understand what wins when background-position and background-size change it
20:27:09 <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.
20:27:48 <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.
20:28:40 <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) ...
20:29:02 <dbaron> Tab: While you can do without it for the most part in backgrounds.
20:29:22 <dbaron> Tab: I think what's there isn't that hard and is sufficiently useful to justify itself.
20:30:13 <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.
20:30:31 <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.
20:30:40 <dbaron> Tab: This is the Hearts Grid example.
20:31:21 <dbaron> Tab: You can do the "Syntax A" version
20:31:29 <dbaron> Elika: Which is the position and which is the size?
20:31:32 <dbaron> Tab: position, then size
20:31:57 <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.
20:32:07 <dbaron> Tab: The problem of positions and sizes looking similar is also in the background shorthand.
20:32:14 <dbaron> Brad: slash there, comma here?
20:32:37 <dbaron> Elika: I'd prefer something that didn't involve comma-separating everything so we could tell what's what.
20:32:52 <dbaron> Tab: Unless we did a slash I'm not sure what we'd do.
20:32:55 <dbaron> Daniel: no slash
20:33:09 <dbaron> Brad: ...
20:33:23 <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.
20:33:29 <dbaron> Arron: It's the intrinsic size of the image.
20:33:43 <dbaron> Tab: With a gradient you can't control the intrinsic size.
20:34:15 <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.
20:34:22 <Zakim> Zakim has left #css
20:34:27 <dbaron> Brad: Won't those types of images need that functionality anyway?
20:34:39 <dbaron> Chris: There are things that know how to size themselves that are not background images.
20:34:50 <dbaron> Elika: With a PNG image, you have the same problem.
20:35:05 <dbaron> Elika: Wouldn't it be better to have a mechanism general enough to handle non-gradient images?
20:35:19 <dbaron> Brad: Better not to have to use the gradient functions to solve that problem.
20:35:28 <dbaron> Chris: Things I'm thinking of don't have that problem -- they know how big they are.
20:35:56 <dbaron> Chris: The syntax that requires background-size and background-position, then we'd be very limited using CSS gradients for 'fill' and 'stroke'.
20:36:12 <fantasai> radial-gradient(<size> <shape> from <position> as <color-stop>, <color-stop>, ...)
20:36:48 <fantasai> <size> would be one of the keywords
20:36:48 <dbaron> Chris: existing syntax has % and absolute, corresponding to SVG's userSpaceOnUse and boundingBoxRelative
20:37:01 <dbaron> (minute taker has trouble keeping up)
20:37:35 <dbaron> Brad: simplicity is a feature, makes CSS easier to learn
20:38:07 <dbaron> Elika: I'd prefer a halfway point between the two.
20:38:30 <dbaron> Brad: I already went a little towards Tab's with putting center on edge/corner.
20:39:02 <dbaron> Elika: farthest-corner, etc., make it easier for me to think about
20:39:24 <dbaron> Brad: ... other colors going on past ...
20:39:31 <dbaron> Elika: put a color stop at the nearest corner?
20:39:43 <dbaron> Brad: That seems more complicated than just saying 142%
20:40:25 <dbaron> Brad: When I'm desiging things I'm doing it visually.
20:40:57 <dbaron> 1.4142135623730951
20:41:18 <tcelik> would this qualify as an irrational discussion?
20:41:19 <stearns> (that will be the tattoo for Tab's other arm)
20:41:30 <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.
20:41:55 <dbaron> Molly: None of this makes any sense to designers/developers -- I don't think this belongs in CSS.
20:42:18 <dbaron> Molly: ok, let's leave the second point for dinner conversation
20:42:46 <dbaron> Daniel: I implemented a visual editor for the gradient proposal -- it's very complicated because of the syntax.
20:43:00 <dbaron> Daniel: I did the original WebKit proposal and the WG one afterwards.
20:43:09 <dbaron> Tab: It should be a lot easier now with explicit sizing.
20:43:21 <dbaron> Brad: I made a list of all the details I had to learn about how these parameters interact with each other.
20:43:36 <dbaron> Brad: linear gradients are simple, one side to the other
20:43:52 <dbaron> Brad: With this simplification, you're either going from one side to the other or center to the side
20:44:48 <dbaron> Brad: keeping it simple makes it much more understandable
20:45:27 <dbaron> Tab: Linear gradients are easier because it's one-dimensional.
20:45: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.
20:46:26 <JohnJansen> JohnJansen has joined #css
20:46:42 <dbaron> Brad: I'd want things more towards the simple side.
20:47:15 <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.
20:47:48 <Bert> +1 to Molly
20:48:21 <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.
20:48:52 <dbaron> Tab: Remember, the majority of gradient usage won't use the functionality we're talking about.
20:48:58 <dbaron> Sylvain: We have 4 implementations.
20:49:29 <dbaron> Daniel: Opinions of those who make tools that design gradients?
20:50:05 <dbaron> Daniel: we have to reach a consensus
20:50:20 <dbaron> Arno: I'd lean towards the simpler syntax.
20:50:22 <dbaron> John: I would too
20:50:28 <dbaron> Alan: There is an SVG fallback.
20:51:28 <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.
20:51:47 <dbaron> Brad: I don't think complexity goes away.
20:52:25 <dbaron> Elika: I'm confused by both syntaxes.  I'd want something more readable.
20:52:34 <dbaron> Elika: How can we make it obvious which part means what?
20:52:44 <dbaron> Elika: Get away from commas, use keywords.
20:53:07 <dbaron> Elika: linear-gradient(from left as red, blue, green)
20:53:16 <dbaron> Elika: radial-gradient(circle from top left as red, blue, green)
20:53:26 <dbaron> Elika: radial-gradient(<shape>? from <position> as <color-stop-list>)
20:55:00 <dbaron> Brad: I do have the 'from' keyword, optional if not starting from the center.
20:55:34 <dbaron> Bert: Why 'circle' at all?
20:55:52 <dbaron> Elika: Otherwise it's an ellipse.
20:56:40 <dbaron> Elika: gradients have no intrinsic ratio
20:57:06 <dbaron> Elika: You can do Tab's set of functionality or Brad's with this syntax, but I think it'll be understandable
20:57:52 <dbaron> Brad: I have the idea that if you specify 'circle' it does have an intrinsic ratio.
20:58:19 <dbaron> Brad: That solves the what if you want a non-distorted circle that fills to the corners.
20:59:17 <fantasai> dbaron: I don't think giving it an intrinsic ration solves what you think it solves
20:59:36 <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
20:59:58 <fantasai> dbaron: so you want somehting where the extent of the graident is that *draws rectangle inscribed in an ellipse*
21:00:08 <fantasai> Brad: sorry, should have said "background-size: cover"
21:00:30 <fantasai> dbaron: that'll be smaller than what you want
21:01:13 <fantasai> Brad: I have a circle, used the circle keyword, and draw gradient to 142%
21:01:27 <fantasai> Brad: and then ..
21:01:36 <fantasai> dbaron: I don't know if we need to dig into this too much, though.
21:01:46 <fantasai> Steve: You would get what you want if the diameter of the circle covers the box.
21:01:54 <fantasai> Steve: Which is another way of saying...
21:02:04 <fantasai> dbaron: Tab's syntax has keywords for those four possibilities.
21:02:35 <fantasai> daniel: we've been working on gradient syntax for months withouth conclusion
21:02:48 <fantasai> steve: one reason we might not have a conclusions is that neither are acceptable yet
21:03:03 <fantasai> steve: there are good ideas in both, but still haven't gotten one that people understand and can communicate
21:03:25 <fantasai> daniel: Both solutions are okay. That's the problem.
21:03:44 <fantasai> daniel: But we need a resolution, and designers need this to ship
21:04:01 <fantasai> sylvain: People are using this today.
21:04:24 <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.
21:05:20 <fantasai> fantasai: I really want to go in this direction. I can't read this stuff.
21:05:27 <fantasai> (this == using keywords)
21:05:32 <fantasai> Tab: I want to resolve on this asap.
21:05:52 <fantasai> Tantek: You're saying taking longer hurts more than complexity
21:05:54 <Ms2ger> Don't we all?
21:06:05 <fantasai> Molly: And then educators are stuck with this for eternity
21:06:38 <fantasai> daniel: What's the plan?
21:07:01 <fantasai> fantasai: I would like 24 hours with Brad and Tab and come back here tomorrow.
21:07:12 <fantasai> Tab: What I want more than anything else for my birthday is to close this issue.
21:07:29 <tantek> Dante's Inferno would have used radial gradients.
21:08:06 <arno> :)
21:08:17 <dbaron> the closest-side, etc. could be following a 'to'
21:08:45 <dbaron> Tab: Brad's concern about complication is about position of the gradient line.
21:09:33 <dbaron> Bert: What's the difference if it's not the syntax?
21:09:57 <dbaron> fantasai: The ability to do arbitrary center, and the {farthest,closest}-{corner,side}, and explicit sizing of the ellipse.
21:10:15 <drublic> drublic has joined #css
21:11:18 <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.
21:11:25 <dbaron> dbaron: Isn't that farthest-side?
21:11:31 <dbaron> Tab: My syntax gives you the option.
21:11:48 <dbaron> Daniel: We are running in circles.
21:11:52 <dbaron> (Aren't we running in ellipses?)
21:12:26 <dbaron> Daniel: Straw poll, syntax A (Atkins) vs. syntax B (Brad)
21:12:42 <dbaron> Luke MacPherson: A
21:12:45 <dbaron> Shane: A
21:12:50 <dbaron> Steve: no comment
21:12:52 <dbaron> Molly: abstain
21:13:12 <dbaron> Bert: B (set of features, not syntax)
21:13:16 <dbaron> Stearns: abstain
21:13:37 <dbaron> Alex: to Sylvain
21:13:38 <dbaron> Arno: A
21:13:51 <dbaron> Brad: B
21:13:53 <dbaron> Tab: A
21:13:57 <dbaron> Elika: abstain
21:14:00 <dbaron> Daniel: B
21:14:03 <dbaron> Koji: A
21:14:10 <dbaron> John Daggett: don't like either, so abstain
21:14:24 <dbaron> David: I guess A.
21:14:28 <dbaron> Arron: A
21:14:31 <dbaron> Sylvain: A
21:14:37 <dbaron> John: I'll have to learn A.
21:14:42 <dbaron> Håkon: abstain
21:14:44 <dbaron> Peter: abstain
21:14:46 <dbaron> Chris: A
21:14:52 <dbaron> Vincent: A
21:14:55 <dbaron> Rossen: A
21:14:57 <dbaron> Tantek: A
21:15:02 <dbaron> Hober: A
21:15:16 <dbaron> Resolved: Stick with Tab's set of features.
21:15:58 <dbaron> ACTION Tab and Elika: discuss improvements to syntax within this set of features
21:15:58 <trackbot> Created ACTION-380 - And Elika: discuss improvements to syntax within this set of features [on Tab Atkins Jr. - due 2011-11-06].
21:16:42 <dbaron> Can we teach tracker to give actions to 2 people?
21:16:58 <fantasai> ACTION plinss: teach Tracker to give actions to multiple people
21:16:59 <trackbot> Created ACTION-381 - Teach Tracker to give actions to multiple people [on Peter Linss - due 2011-11-06].
21:16:59 <fantasai> :P
21:17:23 <Ms2ger> ACTION Elika and Tab: discuss improvements to syntax within this set of features
21:17:23 <trackbot> Created ACTION-382 - And Tab: discuss improvements to syntax within this set of features [on Elika Etemad - due 2011-11-06].
21:17:24 <Ms2ger> :)
21:45:50 <bradk> bradk has joined #css
21:46:01 <dbaron> Topic: CSS Object Model
21:47:11 <BradK_> BradK_ has joined #CSS
21:47:13 <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
21:47:23 <dbaron> Håkon: Anne will be at TPAC Monday and Tuesday.
21:47:24 <fantasai> jdaggett: Shouldn't Anne be here?
21:47:30 <dbaron> Daniel: Originally Scheduled for Tuesday at 9am.
21:47:34 <fantasai> howcome: I can inform him that we'll discuss this Tuesday at 9am
21:48:01 <fantasai> glazou: if he's not going to show up to discussions...
21:48:08 <fantasai> glazou: Ok, next topic
21:48:12 <fantasai> Topic: CSS Exclusions and Shapes
21:49:00 <Rossen> http://dev.w3.org/csswg/css3-exclusions
21:49:01 <dbaron> http://dev.w3.org/csswg/css3-exclusions/
21:49:56 <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
21:50:12 <fantasai> Rossen: At that time we decided to see what the differences and similarities are and come up with one single spec
21:50:19 <fantasai> Rossen: CSS Exclusions was split from CSS Regions
21:50:42 <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
21:50:49 <fantasai> Rossen: And get that towards WD
21:50:58 <fantasai> Rossen: So CSS Exclusiosn and Shapes we are talking about today
21:51:16 <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
21:51:35 <fantasai> Rossen: The two concepts are currently separate concepts, but they actually work really well together. So keeping them in same spec for now
21:51:39 <JohnJansen> JohnJansen has joined #css
21:51:46 <fantasai> Rossen: CSS Exclusions
21:51:57 <fantasai> Rossen: Baic definition, it's an area that you want to preserv clear from any inline-flow layout
21:52:07 <tantek> tantek has joined #css
21:52:11 <fantasai> Rossen: Many example sof this in magazine layouts: pull-quotes, figures with type wrapped around them, etc.
21:52:14 <vhardy> s/Baic/Basic
21:52:25 <fantasai> Rossen: In CSS we already have floats, which are like exlcusions, but we lack the ability to position them precisely
21:52:43 <fantasai> Rossen: Currently we allow exclusions to be applied to any block-level element
21:52:49 <fantasai> Rossen: so an exclusion can be any block-level element
21:52:59 <fantasai> Rossen: Combined with abpso you can create some really magazine-like layouts.
21:53:21 <fantasai> Rossen: I will show slides and spec side-by-side
21:53:59 <fantasai> Rossen: So, declaring exclusions is done with the 'wrap-flow' property
21:54:11 <fantasai> Rossen: Setting it to anything other than 'auto' creates an exclusion
21:54:41 <fantasai> Rossen: 'auto' in this case is special because for regular flow elements the 'auto' value doesn't change the behavior of floats
21:55:02 <fantasai> Rossen: Exclusions can be applied on the left, right, or both sides
21:55:15 <BradK> Exclusions apply to block only, but floats turn inclines into blocks. Shouldn't they behave similarly?
21:55:39 <fantasai> Rossen: maximum picks the left or right, whichever has the most space left
21:55:53 <fantasai> Rossen: Last one is clear, which clears wrapping on both left and right
21:56:39 <TabAtkins_> scribenick: TabAtkins_
21:56:59 <TabAtkins_> jdaggett_: Is there a typo with the maximum example showing up twice?
21:57:17 <TabAtkins_> Rossen: No, the example shows what 'maximum' does when there's more room on one space or the other.
21:57:42 <TabAtkins_> szilles: 'left' and 'right' don't work vertically.
21:58:00 <TabAtkins_> fantasai: It would probably map to line-left and line-right, but it should probably just be 'start' and 'end'.
21:58:30 <TabAtkins_> fantasai: Or have them both, since they do slightly different things.
21:58:35 <TabAtkins_> jdaggett_: Why not just start and end?
21:59:11 <TabAtkins_> fantasai: If you have a design that doesn't depend on the writing direction, frex.
21:59:50 <TabAtkins_> howcome: Are there any restrictions on what elements can affect other things?
21:59:59 <TabAtkins_> Rossen: Next slide, containing model.
22:00:07 <TabAtkins_> Rossen: We're not changing things beyond what 2.1 already specifies.
22:00:22 <TabAtkins_> Rossen: We find the containing block, and that's the exclusion container too.
22:00:37 <TabAtkins_> scribenick: fantasai 
22:00:37 <fantasai> Rossen: The definition we have for wrapping context is simply a collection of exclusion elements.
22:00:51 <fantasai> s/elements/areas/
22:01:02 <fantasai> Rossen: An exclusion area is the area defined by the element. Initially this is the border-box of the element
22:01:12 <fantasai> Rossen: As we'll see later on, this can be changed into a shape
22:01:18 <fantasai> howcome: I can't really parse this text here
22:01:35 <fantasai> howcome: If an abspos comse from outside, will it affect layout of a deeply-nested <p> element?
22:01:46 <fantasai> Rossen: Does everyone understand the containing model?
22:02:13 <fantasai> Rossen: You have somewhere in a subtree of an element an abpsos element, and it positions to a containing block.
22:02:26 <fantasai> Rossen: The scope of the exclusion is the entire subtree of the containing block.
22:02:45 <fantasai> howcome: Then you have 'wrap-through' property.
22:03:05 <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
22:03:07 <tcelik> tcelik has joined #css
22:03:42 <fantasai> Rossen shows the example of 'wrap-through' right above the 'wrap' shorthand definition
22:03:51 <fantasai> jdaggett: ...
22:04:00 <fantasai> Rossen: It's positioned and sized following CSS2.1 rules.
22:04:18 <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
22:04:25 <fantasai> jdaggett: The content of the exclusionary is what?
22:04:35 <fantasai> jdaggett: What goes in that div that you're absolutely positioning?
22:04:44 <TabAtkins_> Shane suggests a 'rap' property to complement 'flow'.
22:04:49 <fantasai> howcome: So 'wrap-through', it's similar to 'float-through'
22:04:57 <fantasai> Bert: No, that's different
22:04:58 <mouse> mouse has joined #css
22:05:03 <fantasai> dbaron: That's propagation to ancestors, not descendants
22:05:19 <fantasai> howcome: If you have a <p> and you have a float on the side, you end the element, the float continues
22:05:29 <fantasai> dbaron: Wrap through is about going through to descendants
22:05:45 <fantasai> dbaron: This model can't describe float, basically
22:05:57 <fantasai> howcome: But you're introducing a different concept.
22:06:11 <fantasai> howcome: Could we not latch onto one of the other contexts that we have?
22:06:20 <fantasai> howcome: I'm wary of introducing yet another reference model
22:06:33 <fantasai> vhardy: We've been bounching around on this for several months, this is what we ended up with
22:06:45 <fantasai> Rossen: We started with floats, but it had a lot of issues that we were not able to solve.
22:06:58 <fantasai> Bert: I think you're talking about something else, howcome.
22:07:29 <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 <p> wrap around it
22:07:49 <fantasai> howcome: It's so similar to floats, we should extend floats
22:08:09 <fantasai> Rossen: .. they do create exclusions, and in this respect they're the same
22:08:25 <fantasai> Rossen: In this respect they're not completley normal. But it is the positioning that we want to address.
22:08:35 <fantasai> Rossen: Do people understand 'wrap-through'?
22:08:41 <fantasai> Rossen draws a diagram:
22:08:47 <fantasai> circle marked CB at the top
22:08:51 <fantasai> triangle extending down from it
22:09:06 <fantasai> a squiggly line extending from the circl down to a small circle inside the diagram
22:09:17 <fantasai> which then connects to the left corner of the big triangle and the middle of its base
22:09:20 <fantasai> this part is shaded
22:09:40 <fantasai> a thing on the base line on the non-shaded part points back up to the CB circl
22:09:49 <mouse> mouse has left #css
22:09:58 <fantasai> Rossen: wrap-through opts out of the wrapping. It's an opt-out model rather than an opt-in model.
22:10:04 <fantasai> howcome: How common is this?
22:10:16 <fantasai> howcome: If you have an exclusion, can't it just be an exclusion?
22:10:27 <fantasai> Rossen: We did have use cases for this
22:10:58 <fantasai> Bert: Say you have in that tree you draw there, the small black thing that's abspos, it pushes everything else aside.
22:11:05 <fantasai> Bert: It has wrap-flow something.
22:11:21 <fantasai> Bert: When you say wrap-trhough on the other circle, then you set wrap-flow on it.
22:11:26 <fantasai> Rossen: Then you have multiple exclusions
22:11:29 <dino> dino has joined #css
22:11:53 <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.
22:12:07 <fantasai> dbaron: wrap-trhough is an attempt to do that?
22:12:23 <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
22:12:35 <fantasai> Alex: ... my content doesn't wrap to anything, so the exlusions overlap but hte content flows around
22:12:57 <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
22:13:22 <fantasai> vhardy: Your question is if I have a float before here *draws a circle before the small circle*
22:13:29 <fantasai> vhardy: Is that float still affecting wrpaping
22:13:43 <fantasai> vhardy: In our model, we have just one wrapping context, and if you exclude them [...]
22:14:03 <fantasai> Rossen: We  can scope the opt-out wrapping so that floats are not affected by it
22:14:11 <fantasai> Rossen: In otherwords, floats would still contribute as they do today
22:14:15 <fantasai> Bert: I'm still brainstorming here.
22:14:36 <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.
22:14:50 <fantasai> Alex: I think wrap-trhough needs a better name. I was confused for the longest time what it does.
22:15:10 <fantasai> Alex: The meaning of the property is "make this container avoid wrapping anything"
22:15:30 <fantasai> 'wrap-off'? 
22:16:03 <fantasai> Rossen: wrap-through means stop the propagation of wrapping context
22:16:16 <fantasai> howcome: So it's the same as this thing I'm describing here. I'd like to have it for floats.
22:16:23 <fantasai> dbaron: What's the use case for floats?
22:16:44 <fantasai> dbaron: Why do you want this, and why do you want this here?
22:17:07 <vhardy> http://wiki.csswg.org/ideas/css3-exclusions-use-cases
22:17:59 <fantasai> Rossen shows UC2
22:18:10 <fantasai> Rossen: In this case we have 2 exclusions affecting each other as well as the context around them
22:18:49 <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*
22:19:54 <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
22:20:20 <fantasai> Rossen: There are layouts for which you don't want to have exclusions.
22:20:32 <fantasai> jdaggett: How does z-index affect this?
22:20:38 <fantasai> Rossen: thanks for moving us ahead
22:21:08 <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
22:21:16 <fantasai> Rossen: we need to compute their order
22:21:28 <fantasai> Rossen: By default the last item in the document will be on top of everything else
22:21:39 <fantasai> Rossen: Naturally we'd want everything else would be affected
22:21:55 <fantasai> Rossen: Ordering of exlcusions is done in painting order. And you can use z-index to reorder them
22:22:29 <fantasai> Rossen: Doing this work, at first it seemed kind of hard to wrap our heads around would z-index just work
22:22:40 <fantasai> Rossen: Interesting thing is that all of the sorting is doable just locally on that element
22:23:09 <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
22:23:14 <fantasai> dbaron: But it covers all descendants too
22:23:25 <fantasai> dbaron: So it's not a local process. You still have to perform layout between each one.
22:23:34 <fantasai> Rossen: Not a local process. It is a two-pass layout
22:23:52 <fantasai> Rossen: in which you first lay out all of the descendants
22:23:58 <fantasai> Rossen: Not abpsos though
22:24:18 <fantasai> dbaron: Yes you do, because [...]
22:25:53 <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 
22:26:13 <fantasai> Rossen: This second exclusion that you just discovered, its scope will be [...]
22:26:24 <fantasai> Rossen: So this exclusion cannot affect any of the sibling exclusions
22:26:37 <fantasai> dbaron: We have two abpsos containing blocks, one inside the other.
22:26:46 <fantasai> dbaron: You have an exclusion inside the first, that affects the size of it
22:27:09 <fantasai> Rossen: assume they're all abspos for simplicity
22:27:19 <fantasai> dbaron: That's one of the problems, the spec assumes that but allows for things that aren't
22:27:36 <fantasai> Rossen: Let's say that you ahve an abspos element that propagates up to this CB in the hierarchy
22:27:46 <fantasai> Rossen: These are both position absolute *dras siblings*
22:27:53 <fantasai> Rossen: And this one is also an exclusion (second one)
22:28:04 <fantasai> Rossen: When the two are to be laid out on the elvel of this containing block
22:28:20 <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
22:28:31 <fantasai> dbaron: If you're doing this 2-pass thing, you just do 2 passes and get the wrong result.
22:28:43 <fantasai> Arron: The first pass finds the static position of everything.
22:28:54 <fantasai> dbaron: The static position will be wrong once you've done the second pass
22:29:13 <fantasai> dbaron: It's not just static position, it's anything that creates an exclusion that's not absoluely positioned
22:29:37 <fantasai> fantasai: Also if you position to the bottom, and your height depends on the contents.
22:29:43 <fantasai> Rossen: Oh yeah, this is a known issue.
22:30:06 <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.
22:30:12 <fantasai> Steve: But that gives the wrong answer
22:30:20 <fantasai> howcome: I think I support you (dbaron)
22:30:45 <fantasai> howcome: You've introduced a bunch of wrap propertis, but it doesn't affect floats, and I think it should do.
22:31:02 <fantasai> Steve: That's a separate question. Let's look at this and then see how it affects floats.
22:31:19 <fantasai> dbaron: One of the other problems with this, it sort of assumes you can apply it to things that aren't absolutely positioned.
22:31:38 <fantasai> dbaron: But if you do, that won't work well because it only affects things inside the parent
22:31:56 <fantasai> Rossen: If you want to have an exclusion which is part of the flow, say a centered float
22:32:09 <fantasai> Rossen: Today you have left float and right float, say you want a centered float.
22:32:14 <fantasai> howcome: You add float: center;
22:32:28 <fantasai> Rossen: That brings other problems. How do you interact with left and right floats?
22:32:51 <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?
22:33:03 <fantasai> howcome: Don't you have that problem anyway?
22:33:16 <fantasai> howcome draws.
22:33:29 <fantasai> howcome: You have an exclusion here. Then you have a left float that doesn't fit. What happens?
22:33:38 <fantasai> howcome: Do you have a clear ?
22:34:00 <fantasai> howcome: By having a model that kindof interacts with floats and kindof interacts with abspos, you create all these problems in the wake
22:34:13 <fantasai> Steve: The current definition of float moves the float down until it will fit
22:35:01 <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
22:35:17 <fantasai> howcome: Still sems like a viable option to me, don't see why it's not
22:35:26 <fantasai> Steve: don't have enough control over positioning
22:35:40 <fantasai> Steve: If you break it down, bunch of considerations about where things are
22:35:50 <fantasai> Steve: Takes abspos items and make them behave like floats
22:35:55 <fantasai> howcome: Why not extend floats?
22:36:04 <fantasai> Steve: Because I don't want them to move
22:36:18 <fantasai> Steve: Makes more sense to make abspos elements exclude 
22:36:30 <fantasai> vhardy: A positioned float is kindof an oxymoron.
22:36:53 <fantasai> howcome: Want to explore doing it the float way
22:36:58 <fantasai> jj: that's what we've done
22:37:11 <fantasai> dbaron: Something Steve said I disagreed with
22:37:25 <fantasai> Tantek: The whole expand float vs new feature. THere are a couple methodologies to apply to think about.
22:37:43 <fantasai> Tantek: From author's perpsective, there's a transition period. How will this behave during the transition period?
22:37:47 <bradk_> bradk_ has joined #css
22:37:50 <fantasai> Tantek: What's the fallback behavior?
22:38:00 <fantasai> Tantek: One way to explore this problem space is to consider that.
22:38:15 <fantasai> Tantek: Want to do this new exclusion thing, but not suck on these old browsers.
22:38:50 <fantasai> Tantek: Without using css-conditional, if you had two float values you can have a fallback value
22:38:57 <fantasai> Tantek: If you don't ahve a fallback, it will slow adoption.
22:39:15 <fantasai> Tantek: Other quesiton is, if new feature B is similar to old feature A. How complex is old feature A?
22:39:32 <fantasai> Tantek: If it took only a few years to do old feature A, then building on it for B make ssense.
22:39:41 <dbaron> q+ to respond to Steve's assertion that authors want it where they position it
22:40:19 <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.
22:40:36 <fantasai> Steve: I'm wondering which of abpos and floats you think is simpler. :)
22:41:01 <fantasai> Rossen: We don't want to mess with positioning complexity of floats today. Don't want to produce yet another layer of complexity
22:41:13 <fantasai> Alex: I wanted this to CSS3 Floats module, and we should have one that includes new floats and page floats.
22:41:28 <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.
22:41:42 <fantasai> Alex: This describes how objects with exclusions itneract with content and each other.
22:41:51 <fantasai> Alex: When we find smarter way to position floats, this should all apply.
22:42:01 <fantasai> Alex: Should be able to implement just this, and then get smarter floats.
22:42:16 <fantasai> Alex: Might be things here, like 2-pass algorithm, which is really about [...]
22:42:42 <fantasai> vhardy: One big difference with floats is that floats assume rectangular shapes, so margin collapsing [..]
22:42:48 <fantasai> fantasai: floats don't collapse margins with anything.
22:43:07 <fantasai> Steve: Point you made earlier with overlays. These are positioned. If they overlap, one takes chunk out of the other. 
22:43:18 <fantasai> Steve: Simpler model, but gives you something you can't get with floats
22:43:26 <fantasai> Bert: I wonder how that example works. 
22:43:41 <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
22:43:57 <fantasai> Rossen: Wrapping context is that of the *containing block* of the exclusion.
22:44:10 <fantasai> Rossen: In this case they both hvae same containing block, so they're in the same wrapping context.
22:45:09 <fantasai> ...
22:45:20 <fantasai> howcome: So in this example, if the blue comes on top
22:45:27 <fantasai> Rossen: Then the red will wrap around it
22:46:32 <fantasai> ...
22:46:43 <fantasai> Tantek: Is the circle a fixed size? What happens to overflow?
22:46:44 <Liam> Liam has joined #css
22:46:49 <fantasai> Rossen: haven't talked about shapes yet.
22:47:21 <fantasai> Rossen: All three elements here are exclusions, all in same containing block *shows example of three overlapping squares*
22:47:34 <fantasai> Tantek: How adaptive is this to different amounts of content?
22:47:50 <fantasai> Rossen: This one is done with overflow: hidden
22:48:08 <fantasai> howcome: If you have a newspaper article, and you want to highlight the quote, you want to make sure the full quote appears.
22:48:19 <fantasai> howcome: Your examples look good, but they cut off the text.
22:48:54 <fantasai> Tantek: So the request is to us econtent and grows it
22:49:15 <fantasai> Rossen: If the element is width or height auto, and you start excluding it, its size will change to accommodate the content.
22:49:27 <fantasai> Rossen: If the size is fixed, then it will overflow.
22:49:38 <fantasai> Tantek: I think the examples should show what designers will want, i.e. not clipping the content.
22:49:48 <fantasai> dbaron: I'd like to go back to the point Steve made about 11 minutes ago
22:50:10 <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.
22:50:26 <fantasai> dbaron: but thinking back to the examples Adobe showed when we met at Mozilla in the spring
22:50:37 <fantasai> dbaron: I think in a bunch of those examples, you don't want that.
22:50:55 <fantasai> dbaron: You will wind up in many cases where you're overlapping where you don't want  overlap
22:51:02 <fantasai> dbaron: For example, pull quotes in the middle of a page.
22:51:32 <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
22:51:58 <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.
22:52:03 <fantasai> dbaron++
22:52:15 <fantasai> Steve: I agree with your example. I don't think floats do a better job, though.
22:52:54 <fantasai> Steve: If I wind up with two pull-quotes, I might want to only show one of them
22:53:39 <fantasai> Rossen and howcome discuss how to position the pull-quote
22:53:56 <fantasai> howcome: I want to put a pull-quote between 1st and 2nd column, 30% down from the top
22:54:00 <fantasai> Rossen: How many columns?
22:54:04 <fantasai> howcome: Depends on width of the screen
22:54:14 <fantasai> Steve: that gets us more into grid-addressing issue
22:54:17 <dino> dino has joined #css
22:56:16 <fantasai> howcome explains his use case in more detail
22:56:44 <fantasai> howcome: You have the gr unit, yes.
22:56:59 <fantasai> Steve: There's a separation between the positioning model and the ability to exclude
22:57:50 <fantasai> Tantek and howcome discuss the issue, howcome says you can do this with gcpm
22:58:10 <fantasai> Rossen: That solves horizontal position, but not vertical
22:58:37 <tantek> and Håkon claims GCPM has the ability to do this.
22:58:42 <fantasai> Rossen: If you can do something with abspos today, you can exclude it
22:58:55 <fantasai> vhardy: We're not talking about positioning, just the exclusions aprt
22:59:00 <fantasai> s/aprt/part/
22:59:11 <fantasai> howcome: We have an opportunity to make floats better
22:59:16 <fantasai> Tantek: floats are so fragile, we shouldn't touch them
22:59:19 <pudgetta> pudgetta has joined #css
22:59:29 <fantasai> howcome: We need floats to the top/bottom of the colu,n
22:59:46 <fantasai> Rossen: You could have 'float' value to top/bottom/left/right
22:59:53 <fantasai> Rossen: But that's orthogonal to what we're doing here
23:00:34 <fantasai> howcome: This case is the most common case for pull-quotes in newspapers
23:01:04 <fantasai> ...
23:01:17 <fantasai> Tantek: I'm willing to accept that examples exist, but I want documentation that they're common
23:01:34 <plinss> plinss has joined #css
23:01:41 <fantasai> Steve: I can provide examples in multiple scripts
23:02:35 <fantasai> howcome: go to wikipedia and search for pull-quote
23:02:40 <ChrisL> http://en.wikipedia.org/wiki/Pull_quote
23:02:49 <fantasai> Alan: This spec is about, not where the pull quote is, but how things wrap aorundit
23:02:58 <ChrisL> http://en.wikipedia.org/wiki/File:Pull-Quote.PNG
23:03:22 <fantasai> Tantek: My experience is that pull-quotes are positioned relative to the page, not the columns
23:03:48 <fantasai> dbaron: Does somebody have the Sunday NYT?
23:04:02 <fantasai> howcome: You can do this already
23:04:13 <szilles> szilles has joined #css
23:04:32 <bradk_> http://blog.psprint.com/wp-content/uploads/2009/01/pull-quote.jpg
23:04:58 <fantasai> ...
23:05:15 <fantasai> vhardy: Positioning is in a separate module. We're not trying to improve positioning at all.
23:05:31 <tantek> nice example bradk
23:05:45 <fantasai> dbaron: I'm suspicious of the claim that we should think about positioning separately because the whole multi-pass layout issue is very tied into the positionng model we're using
23:06:16 <fantasai> dbaron: Using a 2-pass approach will have different amounts of approximaion error. In some models it'll be close, in others your content will be somewhere completely unrelated.
23:06:44 <fantasai> Rossen: We had this note about 2-pass implementation. Almost all of the concerns I saw on the mailing list was about scaling this for interactive media
23:06:49 <stearns> the wikipedia pull quote example is incredibly ugly
23:07:08 <fantasai> Rossen: Based on that, Dave Hyatt and you were asking how do we make this not exponential ...
23:07:23 <fantasai> Rossen: because abspos elements' positions, once they're exclusions, can be affected by themselves.
23:07:34 <fantasai> Rossen: We're proposing this approximation to solve the exponential problem.
23:07:49 <fantasai> Rossen: Can it be improved, sure. Would like to keep running times fairly linear and keep approximation better.
23:08:04 <tantek> does "how do we make this not exponential…" mean "how do we make this not max out the CPU and fans on our laptops" ?
23:08:14 <fantasai> dbaron: I agree that we shouldn't have an exponential performance problem. But I'd rather solve that by coming up with a system that doesn't need it than by coming up with the wrong results.
23:08:51 <fantasai> dbaron: ... If people want to z-index things, they'll use relpos ...
23:09:04 <fantasai> dbaron: If you use exclusions with in-flow things, you'll still end up off.
23:09:24 <fantasai> ...
23:09:42 <fantasai> Alex: Better algorithm is known to exist, but isn't used due to perf.
23:09:57 <fantasai> Alex: For exmaple if you do layout for floats, you can have O(n) or more than that.
23:10:05 <fantasai> Alex: I'm still worried about it.
23:10:29 <fantasai> vhardy: Maybe best way is to publish WD and collect issues
23:10:53 <fantasai> vhardy: There were 3 proposals that were considered, we went over them in Seattle, and this is the result of consolidating
23:11:04 <fantasai> vhardy: Our request is to publish as WD so we can have comments and iterate on it
23:11:19 <fantasai> vhardy: People say its hard or complicated, put it to the test by implementing.
23:12:01 <fantasai> dbaron: Basically once we decide to publish something as a WD, it keeps moving whether we like it or not. So to some extent, that's the point we decide whether this a model that we want.
23:12:10 <fantasai> dbaron: And I'm not at all convinced that this is a model that we want.
23:12:17 <fantasai> Steve: What exactly are you not convinced about?
23:12:24 <fantasai> dbaron: Largely the tie-in to the abpos model
23:12:46 <fantasai> Molly: Is that a preference for a float model, or not specific?
23:12:52 <fantasai> Rossen: What's the alternative?
23:13:08 <fantasai> Alex: Would you prefer this kind of exclusions to only apply a new kind of floats and define that to have a better behavior?
23:13:27 <fantasai> dbaron: I would like to see some of this stuff work in terms of new types of floats, like what howcome's done with page floats.
23:13:36 <fantasai> Alex: this doesn't do anything about float collisions, they overlap
23:13:43 <fantasai> Alex: There are issues with error accumulation
23:13:59 <fantasai> Alex: I think both are really almost out of scope of the exclusions spec. they define what happens with shapes
23:14:17 <fantasai> Alex: If we define new kind of layout, still have to figure out these problems of overlap and positioning backwards.
23:14:58 <fantasai> Alex: There are problems in the spec. If the things exclusions apply to, if they were not anything including abspos. If they only applied e.g. to page floats, it would still have these problems, right?
23:15:15 <fantasai> dbaron: Not exactly, because the page float model still has places in document order I believe
23:15:19 <fantasai> Alex: can you have them overlap?
23:15:38 <fantasai> howcome: Only if you do negative margins. By nature they avoid each other
23:15:47 <fantasai> Rossen: Would they affect each others' wrapping?
23:15:50 <fantasai> howcome: no
23:16:00 <fantasai> Bert: All the examples of exclusions seem to be doable with shapes
23:16:12 <fantasai> Bert: maybe you only need shapes
23:16:31 <fantasai> vhardy: ...
23:16:51 <fantasai> Bert: assume this is one <p> element with 2 columns. THe shape is a donut shape, but it's still the shape of the <p> itself. don't need any other elements for it
23:17:08 <fantasai> Bert: Advantage of that is you don't need to invent some pseudo-element to create that circle.
23:17:35 <fantasai> Bert: oh, you're using an empty element. Oh that is a no-no. Don't create elements just to create shapes.
23:18:21 <fantasai> several: It's just an example
23:18:37 <fantasai> Bert: In the next example, you don't need exclusions, you just need three shapes
23:19:15 <fantasai> Rossen: What you're suggesting was also suggested by glazou. He suggested using bg image as exclusion.
23:19:20 <fantasai> Arno: Works for static layout only
23:19:33 <fantasai> dbaron: I don't think this works for interactive media either.
23:19:40 <fantasai> Bert: The circle there is not expanding.
23:19:49 <fantasai> Rossen: It's percent sized
23:19:58 <fantasai> Tantek: In terms of content.
23:20:45 <fantasai> fantasai: So I see several concerns here.
23:20:53 <fantasai> fantasai: One is error accumulation vs. performance
23:20:55 <TabAtkins_> scribenick: TabAtkins_ 
23:21:15 <TabAtkins_> fantasai: Another one is the actual fluidity of the layout with respect to different amts of content, different font sizes, page sizes, etc.
23:21:27 <TabAtkins_> fantasai: I see a lot fo example here that have fixed sizes, that wouldn't work well if you increased the font size.
23:21:46 <TabAtkins_> arno: That's just an example with the examples, though, right?
23:22:10 <TabAtkins_> fantasai: Not necessarily.  A circle would have an explicit size in real content.  You may need a shrink-to-fit circle.
23:22:34 <TabAtkins_> fantasai: To see that the spec authors aren't considering this kind of concerns me, because you have to make sure that dynamic unpredictable content is handled.
23:22:54 <TabAtkins_> Rossen: We're not doing anything to prevent shrink-to-fit.  Any abspos will, by default, be shrink-to-fit.
23:23:01 <TabAtkins_> Rossen: So making it an exclusion won't change that.
23:23:16 <TabAtkins_> Rossen: What you may be actually concerned about is a problem with *shapes*, not exclusions.
23:23:45 <fantasai> fantasai^: because that's the kind of environment we operate in
23:24:32 <TabAtkins_> Topic: CSS Shapes
23:25:18 <TabAtkins_> Rossen: Shapes are a way to define geometry for exclusions (how stuff outside the element wraps around it) or the inside (how contents are wrapped inside of it).
23:25:41 <fantasai> Note, shouldn't the term "flow container" be "block container" per 2.1?
23:25:49 <TabAtkins_> Rossen: We are proposing 2 ways to define the shape itself.
23:26:03 <TabAtkins_> Rossen: An SVG-like syntax, with functions matching the SVG geom primitives.
23:26:18 <TabAtkins_> Rossen: And a way to reference an image (raster or SVG) that defines the shape automatically.
23:26:43 <TabAtkins_> Rossen: The idea here is that wrapping around elements becomes quickly boring if done solely around rectangles.
23:27:00 <ChrisL> Chris: can it point to  path in that case
23:27:05 <ChrisL> Rossen: yes
23:27:14 <TabAtkins_> Rossen: So for that, we're introducing 'shape-outside', which can be applied to exclusions.
23:27:25 <TabAtkins_> Rossen: Initial value is 'auto', which computes to the box of the element.
23:27:48 <TabAtkins_> Rossen: 'shape-inside' has the same values plus one, ''outside-shape'', which refers to the outer shape.
23:28:12 <shepazu> shepazu has joined #css
23:28:13 <TabAtkins_> Rossen: By default, we want content that is nicely wrapped around as a circle to also wrap its contents as a circle.
23:28:23 <tantek> developed soon after / based on: http://tantek.com/CSS/Examples/polygons.html
23:28:25 <TabAtkins_> Rossen: You can do that, or define an entirely new shape.
23:28:58 <TabAtkins_> Rossen: -inside and -outside are coupled by default, but you can give different values if you want.
23:29:25 <TabAtkins_> jdaggett_: With 'shape-inside', if you have a donut, does text flow around the hole?
23:30:20 <TabAtkins_> fantasai: The 'outside shape' represents the border box/margin box.
23:30:38 <TabAtkins_> fantasai: Shape-inside shapes the content box.
23:31:05 <fantasai> fantasai^: outside shape shapes the impact of the element on surrounding content
23:31:18 <fantasai> fantasai^: inside shape affects the containing block shape for the content of the element
23:31:24 <TabAtkins_> Rossen: [shows an example from the spec with "C" shapes and content flowing into the "space".
23:32:02 <TabAtkins_> vhardy: [explains the example in more detail]
23:32:41 <gamakichi> gamakichi has joined #css
23:33:46 <gamakichi> gamakichi has left #css
23:34:13 <TabAtkins_> Rossen: The contents of an element with a donut shape fill in the entire area of the shape.
23:34:33 <TabAtkins_> jdaggett_: I'd like to use this with a type shape, like having a giant A with text flowing around and through the holes.
23:34:41 <TabAtkins_> Rossen: Yes, that can be done if you extract the shape.
23:34:57 <TabAtkins_> jdaggett_: It would be nice to have text as a built-in shape.
23:35:23 <TabAtkins_> Bert: Q about shape-outside.
23:35:27 <dbaron> q+ to ask about commas
23:35:34 <TabAtkins_> Bert: Some time ago we came up with the case that the shape to wrap around is an image.
23:37:00 <TabAtkins_> Bert: So it looks like you'd have to repeat the url of the image both in <img> and in 'shape-outside'.  We previously had a value called 'contour' that would automatically grab the image when specified on an image.
23:37:27 <ChrisL> If you point to a raster image, does it threashold the alpha map to get the image shape?
23:37:30 <TabAtkins_> <img id=shape-me url=foo><style>#shape-me { shape-outside: contour; }</style> //equal to 'shape-outside: url(foo)'
23:38:31 <ChrisL> Vincent: Yes there is a threashold
23:39:06 <fantasai> ACTION: Make attr() function do the right thing wrt resolving relative URLs
23:39:06 <trackbot> Sorry, couldn't find user - Make
23:39:31 <fantasai> ACTION fantasai: Make attr() function do the right thing wrt resolving relative URLs
23:39:32 <trackbot> Created ACTION-383 - Make attr() function do the right thing wrt resolving relative URLs [on Elika Etemad - due 2011-11-06].
23:39:42 <TabAtkins_> So that would be shape-outside: attr(src as url);
23:40:42 <TabAtkins_> bradk_: Another feature request - have a keyword to grab the background image, rather than repeating yourself.
23:40:49 <TabAtkins_> Bert: What about if there are multiple background images?
23:41:13 <TabAtkins_> Rossen: Daniel brought that up in the last f2f - there were a lot of limitations.
23:41:53 <TabAtkins_> dbaron: In CSS2 there was a property called 'clip', where the examples had commas and the formal syntax didn't.  We resolved that by allowing both.
23:42:00 <TabAtkins_> dbaron: This spec has the same problem, but the other way around.
23:42:25 <szilles> szilles has joined #css
23:43:13 <TabAtkins_> TabAtkins_: I'd prefer to match SVG and make commas optional.
23:44:00 <TabAtkins_> Rossen: Our preference now is to move forward on a WD.
23:44:07 <TabAtkins_> howcome: What if we throw out shapes and only do images?
23:45:04 <fantasai> Tab: I'll note the spec is silent on what to do for animated GIFs
23:45:30 <TabAtkins_> Rossen: We looked at a lot of examples  in print media, where wrapping around images was used a lot.
23:45:41 <TabAtkins_> Rossen: Like SI with lots of athletes with text around them.
23:46:20 <TabAtkins_> Rossen: But with shapes, it makes it nice to have a really simple way to do this.
23:46:24 <TabAtkins_> ChrisL: Agreed.
23:46:41 <TabAtkins_> Rossen: Maybe we could reduce the set of types to circle, maybe polygon?
23:48:08 <TabAtkins_> TabAtkins_: While hakon was joking about animated gifs, I'm not.  That needs to be defined.  Maybe first frame?
23:48:27 <TabAtkins_> jdaggett_: What about animating shapes in Transitions?
23:48:39 <TabAtkins_> TabAtkins_: SVG knows how to animate shapes, so we can do that.
23:48:49 <TabAtkins_> ChrisL: I'd like to see this pushed out for wider review at this point.
23:49:29 <TabAtkins_> dbaron: I'm scared that what's happened lately is that pushing something to TR means we're calling for implementations.
23:50:54 <fantasai> TabAtkins_: Could we address dbaron's concern by adding a scary notice?
23:51:17 <fantasai> glazou: It's a Working Draft. It's already a *Draft*.
23:51:41 <fantasai> glazou: Proposal is to publish FPWD provided the issues list is updated
23:52:07 <fantasai> RESOLVED: Publish FPWD of Exclusions
23:52:46 <fantasai> Topic: Style Attributes
23:53:04 <fantasai> Arron: I didn't finish the implementation report yet, but I ran all the tests, all three of them.
23:53:18 <fantasai> Arron: There needs to be three other tests, but all browsers pass except one case which is passed by 2
23:53:23 <JohnJansen> JohnJansen has joined #css
23:53:47 <fantasai> dbaron: Is there a test for rejecting if there are braces around it?
23:53:47 <szilles> szilles has joined #css
23:53:48 <fantasai> fantasai: yes.
23:53:55 <fantasai> Arron: I'll try to finish off tonight.
23:54:38 <fantasai> ACTION Arron: finish implementation report and tests
23:54:39 <trackbot> Created ACTION-384 - Finish implementation report and tests [on Arron Eicholz - due 2011-11-06].
23:54:48 <fantasai> ACTION fantasai: Publish test suite and implementation report on w3.org
23:54:48 <trackbot> Created ACTION-385 - Publish test suite and implementation report on w3.org [on Elika Etemad - due 2011-11-06].
23:54:56 <fantasai> Topic: Selectors 4
23:55:21 <fantasai> glazou: Selectors L4 triggered a major reaction from web designer community because of subject selector and :matches()
23:55:40 <fantasai> glazou: I can see that people don't really understand that presence of a feature in a WD doesn't mean it will be in an implementation
23:56:00 <fantasai> glazou: I would like us to, at least for :matches() and subject selector, to clean up things asap
23:56:30 <fantasai> glazou: If it's not going to be implemented by browser vendors because it doesn't fit into your strategy or impl architecture, 
23:56:37 <fantasai> glazou: then remove it from the spec quickly
23:57:28 <fantasai> fantasai: :matches() is already implemented
23:57:46 <TabAtkins_> glazou: My fear is just that if we have something nice on paper that we find is too expensive to code, we should remove it quickly.
23:58:32 <TabAtkins_> fantasai: I think trying to cut off brainstorming work because people will interpret it wrong is bad.
23:59:04 <fantasai> fantasai: the subject indicator may wind up in batch processors
23:59:06 <TabAtkins_> glazou: I'm not saying that, just that if our brainstorming finds something isn't implementable we should remove it as quickly as possible.
23:59:14 <fantasai> fantasai: could be done in browsers, but will require careful optimization work
23:59:37 <fantasai> fantasai: so may take awhile to find out
23:59:47 <TabAtkins_> arno: Do we know if anyone's currently planning to implement it?