14:15:20 <RRSAgent> RRSAgent has joined #css
14:15:20 <RRSAgent> logging to http://www.w3.org/2012/02/06-css-irc
14:15:26 <florian> howcome: in functional notation, commas should separated ordered parameters, just like they do in other languages
14:16:00 <florian> howcome: the proposal makes some sense, but the cost of changing is too hight compared to the benefit
14:16:39 <florian> tab: most properties try to have arguments that can be reordered, unless that gives some ambiguity
14:16:52 <florian> tab: functions should do the same, but currently, they don't
14:16:53 <Bert> s/hight/high/
14:17:56 <florian> fantasai: allowing reordering within functional notation also makes it possible for things to be optional
14:18:34 <fantasai> fantasai: optionality makes it possible to extend functionality later
14:19:48 <florian> steeve: with a naive understanding of functions, I expect ordering
14:19:56 <florian> florain: these are not functions
14:20:07 <florian> glazou: people will still see them as such
14:21:25 <florian> howcome: don't change the meaning of commas
14:21:45 <florian> fantasai: let's look at some examples
14:22:12 <sgalineau> I think the combination of CSS2.1 precedent and average JS programmer habit creates an expectation of commas a separators between each value
14:22:29 <nimbu> nimbu has joined #css
14:22:51 <florian> fantasai: see the wiki for examples
14:23:16 <florian> dbaron: it would have been ok to  change a few years ago, but not now
14:23:45 <florian> dbaron: we should push transforms 3 as it is, and introduce a new syntax in a later level
14:23:51 <florian> *: general agreement
14:24:57 <florian> howcome: how are they done in fortran
14:25:02 <florian> ?
14:26:25 <florian> sylvian: are users going to remember this?
14:26:29 <howcome> howcome has joined #css
14:26:34 <florian> florian: they do for regular properties
14:26:55 <florian> tab: the benefits are reordering and optionality
14:28:20 <florian> tantek: did we ever get stuck due to the lack of reordering or optionality?
14:28:25 <florian> tab: on gradients
14:28:39 <dbaron> dbaron: I'm not comfortable using the word "fixed" for gradients
14:28:41 <sgalineau> the issue is not whether the new notation helps feature design, but whether it may confuse feature users
14:28:47 <dbaron> s/not comfortable/not yet comfortable/
14:29:34 <florian> jdagget: of the things on this wiki, I don't see any that benefit from the extensibility argument
14:30:33 <florian> plinss: you don't know what you want to extend until you try to
14:31:01 <florian> glazou: translate(x,y) to translate(x y) is useless
14:31:15 <florian> fantasai: it is for consistency with other places that have an x and a y
14:31:26 <fantasai> background-position, background-size
14:32:33 <florian> plinss: even if some case don't benefit individually, consistency is good
14:33:17 <florian> tab: we didn't suggest any change to gcpm because everything was either ok or consistent with some established thing
14:34:05 <florian> fantasai reads the proposal for animations (steps and cubic-bezier)
14:35:09 <florian> tab: polygons would be nicer as a list of points than a list of numbers
14:35:10 <dbaron> So how many browser implementations of cubic-bezier() do we have now?  4, right?
14:36:47 <florian> florian: let's not break support for things that are interoperably implemented, even if they are currently prefixed
14:38:00 <florian> glazou: does any tool support this syntax already?
14:38:06 <florian> tab: no, it is a new proposall
14:38:43 <florian> plinss: on matrices, commas, spaces, whatever doesn't really matter
14:39:45 <florian> fantasai: if we want to make commas optionals, we need to do it now, otherwise people won't ever use it?
14:40:23 <florian> plinss: I don't want to hold specs due to this
14:41:06 <Bert> s/proposall/proposal/
14:41:26 <florian> plinss: as a general principle, as soon as we have experimental implementations, it should be the focus of the wg to drive that to rec asap
14:42:07 <florian> tab: there are a few ones that haven't been implemented yet
14:42:45 <florian> fantasai: merge the rectangle notation with the rect notation in exclusions
14:44:05 <smfr> css2 rect: http://www.w3.org/TR/CSS2/visufx.html#clipping
14:44:49 <smfr> exclusions rectangle: http://dev.w3.org/csswg/css3-exclusions/#shapes-from-svg-syntax
14:45:35 <florian> vincent: overall, we are ok with the changes suggested for exclusions
14:47:35 <dbaron> http://www.w3.org/TR/WD-positioning-970131
14:47:51 <florian> tab: let's drop the suggestion to merge with rect
14:49:38 <florian> fantasai: for values and units, in attr, we want to drop the comma between the name and the type, because they are paired, and keep the comma that separates that from the fallback
14:50:39 <florian> fantasai: also good for extensibility, especially if the fallback value can contain commas
14:53:09 <florian> howcome: this would break prince's implementation
14:53:47 <dbaron> howcome: put the type outside the parenthesis
14:53:58 <dbaron> Bert: should put the type in the function name (is that what howcome meant?)
14:54:55 <dbaron> Tab, Peter: would like to get some resolutions
14:55:17 <dbaron> Tab: can we resolved that exclusions, attr(), and the steps() function from transitions/animations can change?
14:55:43 <dbaron> dbaron: Gecko has implemented steps() since Firefox 5
14:55:56 <dbaron> smfr: I think WebKit would end up supporting both syntaxes for steps()
14:56:18 <dbaron> howcome: So you dropped the proposal to use 'as' as a keyword?
14:56:35 <dbaron> howcome: This would break target-counter() which has 2 implementations, which has href inside ...?...
14:56:41 <florian> howcome: we'd be breaking 2 implementatiosn
14:56:51 <dbaron> howcome: It's what you use to generate "see page 83"
14:57:35 <dbaron> howcome: They're not prefixed -- functions inside the content() property.  Prince and antennahouse.
14:57:58 <dbaron> howcome: I think it's the same as the other argument that we're breaking implementations, so I would object to the change.
14:58:30 <dbaron> TabAtkins: previously when printing devices have implemented something unprefixed we've let them alias -- we care about the Web more than print implementations
14:58:43 <dbaron> howcome, ?: I disagree.
14:59:04 <dbaron> peterl: Over half of what comes out of HP printers is Web pages, mostly from browsers.
14:59:11 <dbaron> Peterl: We do care about offline renderers.
14:59:24 <dbaron> peterl: However, I'm fine with breaking people who shipped things unprefixed before they should have.
14:59:51 <dbaron> florian: We should still consider them before breaking them.
14:59:54 <dbaron> peterl: understod
15:00:58 <dbaron> peterl: Can't distinguish name,type,default from name,default,moredefault
15:01:12 <szilles> szilles has joined #css
15:01:19 <dbaron> howcome: ?
15:01:25 <dbaron> Tab: should just specify attr(href url)
15:01:42 <dbaron> TabAtkins: I think we should make this change.
15:01:48 <dbaron> peterl: ambiguous
15:02:09 <dbaron> TabAtkins: could say "if fallback value is the token 'url'" ... ?
15:02:31 <dbaron> howcome: We're not helping adaptation with implementors if we come in after 5 years and make arbitrary changes for little purpose.
15:03:03 <dbaron> Tantek: Why isn't the spec in CR?
15:03:10 <dbaron> howcome: lack of implementations
15:03:22 <dbaron> Tantek: then what's the problem?
15:03:26 <dbaron> howcome: non-browser implementations
15:03:46 <dbaron> howcome: values & units should be the last css3 spec out
15:03:51 <dbaron> dbaron: I think we all disagree with you on that
15:04:21 <dbaron> TabAtkins: exclusions, ignore the crazy rect()/rectangle() suggestion
15:04:24 <dbaron> TabAtkins: make changes for exclusions
15:04:27 <dbaron> TabAtkins: make changes for attr()
15:04:32 <dbaron> TabAtkins: maybe make changes for steps()
15:04:42 <dbaron> TabAtkins: for the rest, let things progress to CR and maybe make a compatible change in level 4
15:04:58 <dbaron> fantasai: if the concern is impls you could put it in the spec and mark it at risk
15:05:37 <dbaron> (We should do a third of them with ideographic commas to add to the mix. :-)
15:05:54 <dbaron> peterl: I'm happy with the proposed resolution but concern with the attr() thing
15:06:18 <dbaron> TabAtkins: I believe implementations could support both attr() without breaking
15:06:29 <dbaron> peterl: I think we should leave attr() for discussion
15:07:02 <dbaron> peterl: I think we should also resolve to accept the principles
15:07:21 <dbaron> peterl: And adapt them to old properties as we can and as it makes sense.
15:08:00 <dbaron> RESOLUTION: adopt the principles in http://wiki.csswg.org/ideas/functional-notation
15:08:18 <dbaron> RESOLUTION: adopt the proposed changes to exclusions in http://wiki.csswg.org/ideas/functional-notation except for the part on unifying rect() and rectangle()
15:08:36 <dbaron> ACTION Tab to investigate if we can change functional notation in steps() in line with http://wiki.csswg.org/ideas/functional-notation
15:08:36 <trackbot> Created ACTION-419 - Investigate if we can change functional notation in steps() in line with http://wiki.csswg.org/ideas/functional-notation [on Tab Atkins Jr. - due 2012-02-13].
15:08:59 <dbaron> ACTION Tab to work with howcome and AntennaHouse to see if we can change attr() as suggested in http://wiki.csswg.org/ideas/functional-notation
15:08:59 <trackbot> Created ACTION-420 - Work with howcome and AntennaHouse to see if we can change attr() as suggested in http://wiki.csswg.org/ideas/functional-notation [on Tab Atkins Jr. - due 2012-02-13].
15:18:05 <smfr> smfr has joined #css
15:20:48 <Rossen> Rossen has joined #css
15:25:27 <plinss> plinss has joined #css
15:26:26 <sylvaing_away> sylvaing_away has joined #css
15:26:57 <vhardy_away> vhardy_away has joined #css
15:28:11 <shans_away> shans_away has joined #css
15:29:12 <kojiishi> kojiishi has joined #css
15:31:07 <TabAtkins_> ScribeNick: TabAtkins_ 
15:31:21 <dbaron> dbaron has joined #css
15:31:42 <alexmog_away> alexmog_away has joined #css
15:31:52 <TabAtkins_> Topic: V&U Issues before LC
15:32:03 <TabAtkins_> TabAtkins_: fantasai and I hav eonly the one issue about attr()
15:32:20 <tantek> tantek has joined #css
15:32:24 <TabAtkins_> [no one else has any issues, apparently]
15:32:28 <Bert> s/hav eonly/have only/
15:33:12 <TabAtkins_> plinss: Let's discuss the attr() issue now, see if we can resolve the legacy issues.
15:33:17 <fantasai> target-counter(href, ...) instead of target-counter(attr(href, url), ...)
15:34:58 <TabAtkins_> plinss: Anyone object to going to LC after the attr() issue?
15:34:59 <fantasai> ACTION fantasai: Add example of background-position with calc()
15:34:59 <trackbot> Created ACTION-421 - Add example of background-position with calc() [on Elika Etemad - due 2012-02-13].
15:35:09 <TabAtkins_> sylvaing: I think there was an issue about calc() and background-position.
15:35:23 <TabAtkins_> TabAtkins_: Elika pointed out that if you lawyer the spec correctly, it's not a problem at all.
15:35:35 <TabAtkins_> fantasai: I can add an example with an explanation.
15:35:57 <TabAtkins_> plinss: We'll come back to attr() on next telcon.
15:36:15 <TabAtkins_> Topic: Regions scope
15:36:26 <dbaron> I'm not crazy about the intro to css3-values section 8 (functional notations) using url() as an example of a function
15:36:27 <TabAtkins_> vhardy: There's been feedback on region scope.
15:36:33 <dbaron> given how special url() is
15:36:45 <TabAtkins_> vhardy: On our end we'd like to present our working assumptions.
15:37:03 <TabAtkins_> vhardy: And, per a request from Hakon, what we think the bigger picture is and how that would work in the larger group.
15:37:19 <TabAtkins_> vhardy: So, to recap would take about 20 minutes.
15:38:24 <TabAtkins_> Rossen: [shows some slides]
15:38:34 <TabAtkins_> Rossen: [recaps CSS regions]
15:38:55 <vhardy_> vhardy_ has joined #css
15:39:24 <TabAtkins_> Rossen: An Element that is able to receive and output content from other elements is a Named Flow.
15:40:11 <TabAtkins_> Rossen: Fragmenter - boxes produced by a region can fragment their content.
15:40:41 <TabAtkins_> fantasai: Page boxes, column boxes, regions are all fragmenters.
15:41:00 <TabAtkins_> Rossen: In regions it can be controlled with 'region-break'
15:41:49 <ChrisL> ChrisL has joined #css
15:41:51 <TabAtkins_> Rossen: [shows the canon region example, highlighting the boxes containing text]
15:42:12 <ChrisL> rrsagent, here
15:42:12 <RRSAgent> See http://www.w3.org/2012/02/06-css-irc#T15-42-12
15:42:30 <ChrisL> rrsagent, make logs public
15:42:34 <TabAtkins_> Rossen: There is region styling on the first region, changing the font-size.
15:42:50 <TabAtkins_> Rossen: Out of scope of regions is the breaking rules - specified in CSS3 Fragmentation.
15:43:13 <TabAtkins_> Rossen: That spec should cover *all* breaking rules - pages, columns, regions, and future stuff.
15:43:34 <TabAtkins_> Rossen: Finally, out-of-scope is auto-generation, conditional-generation, or grouping of regions.  This should be covered by a Page Templates module.
15:44:20 <TabAtkins_> florian: Defining them in a separate document seems fine to me, as long as we do it simultaneously and know aproximately what we're doing.
15:45:29 <TabAtkins_> Bert: When you say Fragmention, is that a new name for Paged Media?
15:45:45 <TabAtkins_> fantasai: No, new spec.  This is specifically about breaking.  Paged Media is now just about the page boxes themselves.
15:46:16 <TabAtkins_> Bert: So the break properties, and widows and orphans. Anything more?
15:46:26 <TabAtkins_> Rossen: Some text about variable-width containers, etc., but that's about it.
15:46:33 <TabAtkins_> vhardy: [shows some different slides]
15:46:48 <TabAtkins_> vhardy: Here's context about why we brought them to the group.
15:46:56 <TabAtkins_> vhardy: There were two features we couldnt script our way around.
15:47:44 <TabAtkins_> vhardy: Our people tried to have multiple aspect ratios, and multiple form factors.
15:48:11 <TabAtkins_> vhardy: [shows a slide of a fairly large screen with three columns of text, some pull-quotes]
15:49:23 <TabAtkins_> vhardy: In this example, the content uses three templates.
15:50:08 <TabAtkins_> vhardy: But on smaller content, you have substantially different templates.
15:50:20 <TabAtkins_> s/content/screens/
15:51:26 <TabAtkins_> vhardy: There's also justification for page templates being conditional - based on the content, you may use different templtaes.
15:51:48 <smfr_> smfr_ has joined #css
15:51:53 <TabAtkins_> vhardy: The regions offers the way of pulling content into the template.
15:52:47 <TabAtkins_> vhardy: So one approach that could work here is GCPM - use paged overflow and media queries to swap out templates.
15:53:25 <TabAtkins_> vhardy: The @page rule would contain a template and specify how areas of the template are regions.
15:54:03 <TabAtkins_> vhardy: In our experience, trying to do magazine content, there's reason to do conditional content.
15:54:18 <TabAtkins_> vhardy: For exapmle, if a page's content has a pull-quote region, use the templtae meant for pull-quotes.
15:55:09 <TabAtkins_> vhardy: Further, one can leverage regions and pseudo-elements to control the flowing in th epage templates.
15:56:13 <TabAtkins_> vhardy: So the core notion is that you would use CSS (@page and pseudos) to define the templates, and use regions to pull content into them.
15:56:33 <TabAtkins_> vhardy: This is important, because the people asking us for these abilities want very precise control over how things are laid out.
15:57:04 <TabAtkins_> szilles: The WebApps group is also looking at templates in this context, and there's an opportunity for discussion.
15:57:24 <TabAtkins_> szilles: HTML-based templates, shadow DOM, etc.
15:57:48 <TabAtkins_> Bert: Two comments.
15:58:26 <TabAtkins_> Bert: Regarding ::slot(), I had resolved to put it directly after the @page token. This avoids mixing with @page styles, and also makes it look more like a selector.
15:58:55 <TabAtkins_> Bert: The other comment is looking at the "nth(2)", and wondering if this is what we wanted.
15:59:19 <TabAtkins_> Bert: I thought we had ideas about named pages.
15:59:46 <TabAtkins_> Bert: Another comment, XSL already has things like this.
15:59:53 <TabAtkins_> Bert: We should probably look at what they've done already.
16:00:15 <TabAtkins_> szilles: I think the main thing is what vincent already hinted at - conditional choice pages.
16:00:33 <TabAtkins_> szilles: His example of small and large templates was primitive, but obviously useful.
16:00:51 <TabAtkins_> szilles: The XSL mechanism had extremely primitive questions you could ask.
16:01:15 <TabAtkins_> szilles: But in general you want to be able to see if the next page's content contains images, particular flows, etc., and select your template based on that.
16:01:48 <TabAtkins_> szilles: We don't need to get into specifics now, but the notion of conditioning based on content is important.
16:02:43 <TabAtkins_> vhardy: [shows some demos]
16:03:43 <TabAtkins_> vhardy: [first demo shows regions being created/destroyed dynamically based on the length of the content]
16:04:09 <TabAtkins_> vhardy: It uses the regions OM to tell when there is overflow/underflow so it can create/destroy "columns" and "pages" with script.
16:04:29 <TabAtkins_> vhardy: If we could do all this declaratively, it would be great.
16:05:33 <tantek> tantek has joined #css
16:05:54 <TabAtkins_> vhardy: [shows another demo]
16:06:02 <TabAtkins_> florian: I think this demo can be done with overflow:paged, too.
16:07:25 <glazou> jdaggett, dbaron, florian, vhardy : 119 people registered for wednesday evening at La Cantine
16:07:50 <TabAtkins_> howcome: [shows a similar demo using display:table and multicol to achieve a result similar to the english/french stuff.
16:08:15 <jdaggett> glazou: wow!
16:08:54 <TabAtkins_> astearns: In the template example, different pages were split in different ways.  That seems incompatible.
16:08:56 <jdaggett> glazou: will there be enough air in the room?
16:09:02 <TabAtkins_> howcome: There may be changes needed, yes.
16:09:33 <TabAtkins_> howcome: I think if we can just agree on the general shape of CSS syntax for making region targets is good, so we don't need to have dummy elements.
16:10:44 <TabAtkins_> vhardy: We found that often you need to nest the containers needed for complex but realistic layouts.  That makes it hard to work with pseudos.
16:11:04 <TabAtkins_> glazou: [talks about HTML-to-CSS templates]
16:11:19 <TabAtkins_> Bert: I think you are putting up a hack as a solution.
16:11:26 <TabAtkins_> glazou: I think they're using it because it's simple.
16:11:47 <TabAtkins_> fantasai: People are using those for actual HTML templates - that's the markup they want.
16:12:44 <TabAtkins_> howcome: There's a finite number of elements in the page.  You still are forced to use JS to create new elements as necessary.
16:13:24 <TabAtkins_> astearns: The idea is that regions are primitives.  They could be elements or pseudo-elements or what-have-you.
16:13:31 <TabAtkins_> astearns: We don't want to limit what Regions can be.
16:14:07 <TabAtkins_> astearns: We just want these primitive region concepts that can be used *now* with JS, and *soon* with page templates, etc.
16:14:34 <TabAtkins_> howcome: If a property can only be used in practice with JS, I think that's wrong.  CSS has always been able to create boxes as we need them.
16:14:53 <TabAtkins_> vhardy: I think it would be great to have slots and such.  
16:15:05 <TabAtkins_> vhardy: We tried to push it far in the earlier proposals, but it got *ugly*.
16:16:09 <TabAtkins_> vhardy: For simple things, using ::slot() or similar with regions is great.  For more complex things like Wired Magazine, HTML seems very good for setting this.
16:17:01 <alexmog_> alexmog_ has joined #css
16:17:01 <TabAtkins_> vhardy: the way we script things currently is that we have a custom CSS syntax, and we parse that and then generate things in the DOM based on that.
16:17:15 <TabAtkins_> vhardy: If we had shadow DOM, or some way to use boxes without elements, we'd use that.
16:17:57 <TabAtkins_> florian: For all the examples you have, the most tricky ones may be complicated, but everything else is doable with existing stuff.
16:19:00 <TabAtkins_> alexmog_: The purpose of this was just to introduce our ideas. We'll have future conversations about how to address templates and such.
16:20:09 <TabAtkins_> alexmog_: [some discussion I missed]
16:20:30 <TabAtkins_> florian: It seems to me that if you have a different solution, you'll always find some cases that you nee dyour solution for.
16:20:43 <dbaron> s/nee dyour/need your/
16:20:56 <TabAtkins_> florian: But it seems that in *most* cases, you can solve them with simpler things.
16:22:32 <fantasai> dbaron: AFAICT, you went through a presentation very quickly, not giving ppl a chance to comment, and now saying we have to move on without asking questions.
16:22:52 <TabAtkins_> alexmog_: I'm trying to separate these conversations because...
16:22:58 <TabAtkins_> dbaron: What convos are you trying to separate?
16:23:14 <TabAtkins_> alexmog_: I want to delay discussions on use-cases and solutions until a longer solution with Hakon about what is happening.
16:23:32 <TabAtkins_> alexmog_: I would be happy to analyze specific use-cases now if we have time, to show that only Regions can solve those.
16:23:49 <TabAtkins_> alexmog_: I think that preparing for that would be more productive with a small session first.
16:24:01 <TabAtkins_> alexmog_: These use-cases are posted in the wiki.
16:24:42 <tantek> URL?
16:24:50 <Rossen> http://wiki.csswg.org/spec/page-view
16:24:58 <TabAtkins_> vhardy: We are trying to make progress on Regions, and what the spec covers or not is in question.
16:25:05 <astearns> http://wiki.csswg.org/spec/css3-region-templates
16:25:20 <TabAtkins_> vhardy: So we need to see if we can address things like auto-height, tiling, etc., or if we need to go back further in the idea.
16:25:33 <TabAtkins_> dbaron: Okay, I heard that, and then it delved into very specific examples, and it wasn't clear how they connected.
16:26:22 <TabAtkins_> vhardy: One of the big questions that hakon has asked is how you generate regions, how you paginate, etc., and so I tried to show that.
16:27:28 <TabAtkins_> sylvaing: At TPAC we said that certain things are out-of-scope of regions, and so the presentation showed that those out-of-scope things are needed for some of the questions being raised.
16:28:12 <Bert> (So I think Regions is about: (1) given that there are regions on the canvas (created with a grid template or in some other way), we need a way to chain them together so content flows from one to the next; (2) given that there are regions, we want to assign style to them that overrides the style set on the elements whose content ends up in those regions.)
16:28:15 <TabAtkins_> howcome: but you need the page templates for evaluating regions.
16:28:53 <TabAtkins_> astearns: My take is that there are problems you can poke at with our examples, and with GCPM, but there's a need for both to have a primitive thing to flow content through.
16:29:12 <TabAtkins_> astearns: In multicol it's a column element.  Regions are a further abstraction - it's not a multicol, it's bare columns that can be put anywhere.
16:29:53 <TabAtkins_> astearns: It's the multicol layout scheme that isn't generic enough, so we needed to go further down and have simple, primitive flow-through boxes.
16:30:04 <TabAtkins_> howcome: In doing so, you lose the fundamental scalability of the web.
16:30:15 <TabAtkins_> howcome: Look at this example (the canon regions example).
16:30:44 <TabAtkins_> howcome: If the screen gets wider, you can't add another column to the right.
16:30:59 <TabAtkins_> Rossen: This is what page templates are going toward.
16:31:31 <TabAtkins_> howcome: But we haven't seen them! We can't evaluate a non-existing spec.
16:31:40 <TabAtkins_> alexmog_: First, we'd like to work with you for a complete solution.
16:31:51 <TabAtkins_> alexmog_: Second, regions as they are are following the same pattern as everything else in CSS.
16:32:10 <TabAtkins_> alexmog_: Following existing typography tradition being described in a language.
16:33:06 <TabAtkins_> howcome: Right now we have multiple plans, and I think we should talk about just the declarative stuff right now.
16:33:42 <TabAtkins_> szilles: If you want declarative, why do you have an OM?
16:33:59 <TabAtkins_> howcome: It allows more functionality.  But it's not required to display things.
16:34:22 <TabAtkins_> howcome: What I fear is that IE will ipmlement the script-centric approach and nothing else.
16:35:08 <TabAtkins_> alexmog_: What you are suggesting does not yet address all the use-cases we've presented.
16:35:19 <TabAtkins_> howcome: I've been away for a bit, but I've answered many of them.
16:35:53 <TabAtkins_> howcome: Number one example of an exclusion is a pullquote that comes out of some text and goes between two columns.
16:36:01 <TabAtkins_> howcome: It can't be done in your approach.
16:36:19 <arno> arno has joined #css
16:36:51 <fantasai> Tab: What is the point of this discussion? I don't want to minute random meanderings.
16:37:12 <TabAtkins_> florian: The problem I see is that we're introducing various pieces that are meant to be combined, but we're not considering them together.
16:37:15 <arron> arron has joined #css
16:37:30 <TabAtkins_> florian: As long as we discuss them separately, we aren't dealing with it.
16:37:56 <TabAtkins_> alexmog_: We know we disagree somewhat.  Can we move past that?
16:38:02 <TabAtkins_> howcome: We could if we agreed on the declarative approach.
16:38:31 <TabAtkins_> vhardy: On your end, hakon, you take existing content and figure out how to paginate on multiple devices, as automated as possible, with as little knowledge as possible.
16:38:50 <TabAtkins_> vhardy: Where we're coming from is different - design houses that want precise control over content when it's paginated.
16:41:07 <TabAtkins_> TabAtkins_: Within the context of epub, we explicitly rejected the "precise design" use-case as a thing for CSS to worry about.  Why are we worrying about that in the context of Regions?
16:41:48 <TabAtkins_> szilles: Not precise control, but a design that will scale over a reasonable set of form factors, combined with media queries.
16:42:12 <TabAtkins_> florian: I agree, but I don't see how you go from there to "you need this type of regions"
16:42:37 <TabAtkins_> szilles: Some people believe that there aren't reasonable ways to use columns.
16:42:41 <TabAtkins_> florian: Using current columns, yes.
16:42:56 <TabAtkins_> szilles: I see columns as combining two things.  They do columns, and they do auto-generation.
16:43:01 <kojiishi> kojiishi has joined #css
16:43:12 <TabAtkins_> szilles: I think it's more powerful to separate those two things into building blocks.
16:43:24 <TabAtkins_> szilles: And use things like conditional page templates for auto-generation.
16:43:50 <TabAtkins_> howcome: That' s afine approach, but it doesn't need script.
16:44:04 <TabAtkins_> szilles: I don't think we know the set of templates or rules that we'll need yet.
16:44:33 <TabAtkins_> vhardy: Multicol gives us a lot of the abilities we need, but with a single, particular layout solution, when we have use-cases for lots of different layouts.
16:44:56 <TabAtkins_> vhardy: If the last region is always overflow/auto-scroll/etc, there will always be a way to show the additional content.
16:45:15 <TabAtkins_> howcome: How does the content get onto the next page?
16:45:35 <TabAtkins_> alexmog_: How it gets onto the next page is the next thing we need to write.
16:45:39 <TabAtkins_> florian: That's what we can't accept!
16:46:17 <TabAtkins_> fantasai: You need script to do something like fancy regions on page 1, and then just simple columns on the rest.
16:46:31 <TabAtkins_> vhardy: There are different problems and concerns.
16:46:45 <TabAtkins_> vhardy: Regions is trying to be agnostic about the boxes it's flowing into. Anything that can take 'flow-from' is a region container.
16:47:13 <TabAtkins_> florian: The least-effort way of doing things doesn't get you what you want.
16:47:51 <TabAtkins_> macpherson: You *could* generate the rest with JS, or have it do automatically with columns.
16:48:09 <TabAtkins_> fantasai: Solutions like putting a bunch of extra <div>s that may or may not work isn't a good solution.
16:48:19 <TabAtkins_> macpherson: One problem is that we currently don't have good multicol integration.
16:48:27 <TabAtkins_> macpherson: But CSS already doesn't solve this case.
16:48:51 <TabAtkins_> fantasai: What we're saying is that the cases that are easy to solve in CSS is still hard in Regions.
16:49:20 <TabAtkins_> fantasai: We're seeing part of a solution and being assured that the rest will come eventually, but right now the piece we know isn't capable of doing robust layout.
16:49:24 <TabAtkins_> vhardy: But regions aren't layout.
16:49:51 <TabAtkins_> fantasai: Agreed. But based on what we have right now, Regions makes it possible to create very *non-robust* layouts.
16:50:08 <TabAtkins_> howcome: If there's one thing we've learned, scripting isn't robust.
16:50:24 <TabAtkins_> macpherson: What's the problem with having the last thing be auto-sized?
16:50:34 <TabAtkins_> howcome: If that's the approach, I'm happy.  I just don't like the script-centric thing.
16:52:09 <TabAtkins_> sylvaing: without dom elements, you can't receive clicks, etc.
16:52:37 <TabAtkins_> antonp: The problem right now is that, based on what we have right now, it seems that scripts are required.
16:52:57 <glazou> arron: LOL
16:53:52 <TabAtkins_> antonp: Is the objection about a theoretical problem with regions right now, or practical issues?
16:54:32 <TabAtkins_> astearns: I think finding a good, complete solution can only be furthered by having the primitives right now, even if scripts are needed to use them *right now*.
16:54:45 <TabAtkins_> astearns: So get a set of functionality in place, and then extend it.
16:55:29 <TabAtkins_> florian: It seems that in the future we're pointing at the same needs.  But what you proposed is that, on day 1, you can use tools to create great stuff on the kindle, but not on the web.  We're wanting to make sure that it scales better across the web/devices on day 1 as well.
16:55:53 <TabAtkins_> florian: Our ideas don't support quite as fancy stuff as yours on day 1, but they do handle better scaling on day 1.
16:56:01 <TabAtkins_> vhardy: We have a solution today which is fully scripted.
16:56:07 <TabAtkins_> vhardy: We feel that this isn't a good solution.
16:56:14 <TabAtkins_> vhardy: Even without regions.
16:56:24 <TabAtkins_> vhardy: If we don't do this, we'll stick with fully-scripted.
16:57:10 <TabAtkins_> vhardy: [shows example with the last region taking the rest of the content and scrolling]
16:57:40 <TabAtkins_> vhardy: If we had th elast region be auto-height, it wouldn't need to be scrolled.  It could be multicol.
16:57:47 <TabAtkins_> howcome: It doesn't work today?
16:57:53 <TabAtkins_> vhardy: Not per spec.
16:58:12 <glazou> arron: we have so much on the list of proposals that we establish it on the fly every day
16:58:23 <glazou> arron: we won't be able to do everything in 3 days
16:58:41 <glazou> arron, ChrisL : we adjourn in 2 mins
16:59:05 <ChrisL> thanks. mostly caught up by IRC logs now.
16:59:11 <glazou> cool
16:59:23 <arron> glazou: that doesn't shock me too much. we are getting more issues
16:59:26 <TabAtkins_> Bert: The assumption of regions is that the spec is a way to make regions, and then you can style/position them later.
16:59:32 <kojiishi> kojiishi has joined #css
16:59:43 <TabAtkins_> Bert: I'm predicting that once we know how to make regions, we'll know how to do these things, and they'll fall out.
17:00:06 <TabAtkins_> vhardy: I think that the automatic generation of boxes is useful, but not just for regions.  It can be used for more things.
17:01:28 <fantasai> Tab: Afaict, layouts should only need Grid. What's missing?
17:02:11 <Bert> s/that the spec/that somewhere else there/
17:02:13 <glazou> ADJOURN
17:44:45 <kojiishi> kojiishi has joined #css
17:47:56 <TabAtkins_> TabAtkins_ has joined #css
18:04:38 <tantek> tantek has joined #css
18:06:33 <TabAtkin1_> TabAtkin1_ has joined #css
18:07:09 <kojiishi_> kojiishi_ has joined #css
18:07:09 <tantek_> tantek_ has joined #css
19:03:08 <arno> arno has joined #css
19:04:30 <arno> arno has joined #css
19:21:05 <arno> arno has joined #css
19:29:14 <arronei_> arronei_ has joined #css
19:59:21 <jdaggett> jdaggett has joined #css
20:02:58 <jdaggett_> jdaggett_ has joined #css
20:05:28 <jdaggett> jdaggett has joined #css
20:09:30 <arno> arno has joined #css
20:14:29 <glenn> glenn has joined #css
20:14:52 <Ms2ger> Ms2ger has joined #css
20:16:28 <jdaggett> jdaggett has joined #css
20:28:49 <Ms2ger> Ms2ger has joined #css
20:50:06 <tantek> tantek has joined #css
20:52:52 <TabAtkins_> TabAtkins_ has joined #css
20:58:30 <jarek> jarek has joined #css
21:36:29 <Rossen> Rossen has joined #css
21:36:41 <kojiishi> kojiishi has joined #css
21:51:11 <tantek> tantek has joined #css