/irc-logs / w3c / #css / 2014-01-29 / end

Options:

# Session Start: Wed Jan 29 00:00:00 2014
# Session Ident: #css
# [00:00] <fantasai> ...
# [00:00] <fantasai> TabAtkins: <hr> is describable in CSS.
# [00:00] <fantasai> fantasai: No it's not. Next to a float it's not
# [00:00] <fantasai> TabAtkins: It's just a BFC
# [00:00] <fantasai> fantasai: No, width 50% on <hr> is 50% of the available line width, not CB width
# [00:00] <fantasai> TabAtkins: Anyway, are people ok with <br> becoming a flex item on its own?
# [00:01] <fantasai> TabAtkins: Rossen?
# [00:02] <fantasai> SimonSapin: Can we agree that we need a spec for <br>?
# [00:02] <fantasai> fantasai: I think we need to investigate why the HTML definition doesn't work
# [00:02] <fantasai> dbaron: I'm not sure that it doesn't. But might have some perf implications
# [00:02] <fantasai> plinss: Fine to make magic by default, as long as can opt out of magic
# [00:04] <fantasai> TabAtkins: Rossen confirms that IE does the same for <br>
# [00:05] <fantasai> TabAtkins: We might need to make it magic
# [00:05] <fantasai> fantasai: display-box: contents; content: '\A'; white-space: pre;
# [00:05] <fantasai> TabAtkins: Hm, that might work...
# [00:06] * Joins: jet (~junglecode@public.cloak)
# [00:07] <fantasai> [side discussion of interaction with display-box and display: none]
# [00:07] <fantasai> [currently display: none won't work on this, but people seem to prefer that it does]
# [00:08] <fantasai> dbaron: [something about quirks mode]
# [00:09] <SimonSapin> plinss: We don’t need to define quirks mode.
# [00:10] <fantasai> RESOLVED: No change to current behavior for issue 28, work on making <br> work as described above, no change to flexbox only to display
# [00:12] <fantasai> <br type=coffee>
# [00:12] <plinss> br { content: caffeine; }
# [00:13] * Quits: tantek (~tantek@public.cloak) (tantek)
# [00:18] * Quits: Rossen_f2f (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [00:19] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [00:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [00:24] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [00:28] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [00:29] * Joins: koji (~koji@public.cloak)
# [00:29] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [00:29] * Joins: koji (~koji@public.cloak)
# [00:32] * Quits: jet (~junglecode@public.cloak) (jet)
# [00:32] * Joins: jet (~junglecode@public.cloak)
# [00:42] * Joins: leif (~lastorset@public.cloak)
# [00:45] * Joins: tantek (~tantek@public.cloak)
# [00:46] <TabAtkins> ScribeNick: TabAtkins
# [00:46] <TabAtkins> Topic: Shapes serialization
# [00:46] <TabAtkins> astearns: I had a serialziation proposal.
# [00:46] <astearns> http://lists.w3.org/Archives/Public/www-style/2014Jan/0572.html
# [00:46] <TabAtkins> astearns: Elika and David looked at it, I made slight adjustments based on feedback.
# [00:46] <TabAtkins> astearns: I'd like to resolve to go with this email's wording, and take Shapes to LC again.
# [00:46] <TabAtkins> dbaron: You said IE and FF use keywords instead of lengths.
# [00:47] <TabAtkins> dbaron: Were you testing keyword input?
# [00:47] <TabAtkins> dbaron: There's a distinction between preserving what's specified and changing it.
# [00:47] <TabAtkins> dbaron: I don't see anything that converts - in our computed style code we serialize out percentages.
# [00:48] <TabAtkins> astearns: I looked at gCS of a declared style that used keywords.
# [00:48] <TabAtkins> fantasai: No, we looked at declared style.
# [00:48] <TabAtkins> astearns: My goal is to harmonize what we do with a <position> value in Shapes and bg-position.
# [00:48] <TabAtkins> astearns: The only commonality we saw is that the older version preferred 2-value over 1-value.
# [00:48] <TabAtkins> astearns: Browsers seemed split over keywords vs percentages.
# [00:49] <TabAtkins> astearns: I saw a split, and have a slight preference for lengths, so I used lengths.
# [00:49] <TabAtkins> dbaron: For declared style, we preserve an inputted keyword.
# [00:49] <TabAtkins> dbaron: For computed, we do length/percentages.
# [00:49] <TabAtkins> krit: Should we harmonize that?
# [00:49] <TabAtkins> dbaron: We do two versions of everything.
# [00:49] * Joins: Rossen_f2f (~Rossen_f2f@public.cloak)
# [00:50] <TabAtkins> astearns: I could take this and say it's how to serialize the computed style.
# [00:50] <TabAtkins> astearns: I'd like to normalize the computed output.
# [00:50] <TabAtkins> dbaron: We probably ought to have a larger discussion about serialization between declared and computed.
# [00:50] <TabAtkins> dbaron: I'm fine with this for computed.
# [00:50] <TabAtkins> dbaron: I feel like we may want slightly better round-tripping for declared values.
# [00:51] <TabAtkins> astearns: So would you be okay with this section noting that it's for computed style, and not defining for specified?
# [00:51] <TabAtkins> dbaron: Yeah. I'd probably be okay with saying it's for declared as well, but I'm not crazy about it.
# [00:51] <TabAtkins> astearns: We'll probably do that in our impl anyway. But I'm fine with normatively defining it to be the computed value.
# [00:51] <TabAtkins> astearns: And nothing else.
# [00:52] <TabAtkins> krit: Computed style is a good start - if we can get farther, that would be great.
# [00:52] <TabAtkins> astearns: I think anything further we do should be a global thing, not just for shape functions.
# [00:53] <TabAtkins> RESOLVED: Serialize a computed shape value per the email above.
# [00:53] <TabAtkins> RESOLVED: New LC for Shapes with a 3-week period.
# [00:54] <TabAtkins> krit: Any chance we can specify serialization for all properties?
# [00:54] <TabAtkins> dbaron: What I was clear about when Anne tried it is that it will take research.
# [00:54] <TabAtkins> dbaron: We can't take the lazy-spec approach that requires impls to break interop.
# [00:55] <TabAtkins> krit: We did an interop-breaking change for currentcolor.
# [00:55] <TabAtkins> dbaron: We had good reasons for that, we have a good reason to believe it won't break things, and we'll do experimentation.
# [00:56] <TabAtkins> dbaron: Higher chance of breakage for serialization change, and it's everywhere.
# [00:56] <TabAtkins> krit: What if browsers aren't currently interoperable?
# [00:56] <TabAtkins> dbaron: Then we can do new things.
# [00:57] <TabAtkins> dbaron: We had a problem with Anne's rule [...]
# [00:57] <TabAtkins> dbaron: Where browsers are currently interoperable, we should be explicit about deciding to change it.
# [00:57] <TabAtkins> dbaron: We should also think about the magnitude of the code changes required.
# [00:57] <TabAtkins> dbaron: A spec with a small rule that leads to thousands of lines of code changes is different than a rule that leads to a small amount of code changes.
# [00:58] <TabAtkins> dbaron: Anne's general rule was probably not tested sufficiently given the magnitude of the required changes.
# [00:59] <TabAtkins> florian: Make sure you think about rule serialization too, not just properties.
# [00:59] <TabAtkins> Topic: elements as regions
# [01:00] <TabAtkins> astearns: I am not Napolean.
# [01:00] <TabAtkins> astearns: I'm Dr. Evil, apparently.
# [01:00] <TabAtkins> astearns: I have "named flows", which will destroy the web.
# [01:00] <glenn> anyone who says he's not napolean is napolean
# [01:00] <TabAtkins> astearns: The issue is that Regions has a flow-from property that works on anything that can give it a box. Including HTML elements.
# [01:01] <TabAtkins> astearns: So we can have empty non-semantic elements providing the presentational boxes for region chains.
# [01:01] <TabAtkins> astearns: This is the only issue.
# [01:01] <TabAtkins> astearns: But I think people use it as a proxy for other issues they have with Regions.
# [01:01] <TabAtkins> ChrisL: Does anyone think CSS Zen Garden is "non-semantic"? They have tons of empty divs.
# [01:02] <TabAtkins> astearns: So let's just talk about this one single thing.
# [01:02] <TabAtkins> SimonSapin: Are there things other than elements that can take flow-from?
# [01:02] * Joins: kawabata_ (~kawabata@public.cloak)
# [01:02] <TabAtkins> astearns: It's designed to apply to anything that can generate a block container box.
# [01:02] <TabAtkins> astearns: Currently that's only ::before/after with display:block.
# [01:02] <TabAtkins> astearns: But there are proposals for lots of other things, like grid slots or page template slots.
# [01:03] <TabAtkins> astearns: If we were to resolve in favor of the issue, flow-from would apply to *some* pseudo-elements, not others, and not elements.
# [01:03] <TabAtkins> astearns: I think this issue is a big deal. Regions violates the separation of concerns, and this has to be justified.
# [01:03] <TabAtkins> astearns: Right now we do this out of necessity, because there's no other way to generate boxes. I think it's justified.
# [01:04] <TabAtkins> astearns: I'd like the poll to be "Who thinks we should resolve that Regions only apply to pseudo-elements that can generate block container boxes, and not elements?"
# [01:05] <TabAtkins> dbaron: I'm not sure I agree with either position.
# [01:05] <TabAtkins> Bert: My position is that there's no point putting out a Regions draft without a way to make regions in CSS. This leads to bad pages.
# [01:05] <dbaron> ...I think the issue is an issue, but that's not how I would want to see it solved.
# [01:05] <ChrisL> q+
# [01:06] <TabAtkins> Bert: Whatever we allow later, we should first allow people to do it the right way.
# [01:06] <TabAtkins> astearns: That's new information for me. I thought your position was that we should only have this mechanism work for in-CSS boxes.
# [01:06] <TabAtkins> Bert: With the 'content' property you can do anything. I don't think we should disallow that.
# [01:06] <TabAtkins> Bert: (With syntax quibbles.)
# [01:07] <TabAtkins> glazou: We had ::slot on the radar before.
# [01:07] <fantasai> Bert^: But my point is, before we allow people to do things the right way, we need to allow them to do it the right way.
# [01:07] <glazou> Bert's position is reasonable
# [01:07] <TabAtkins> ChrisL: The separation isn't a religious position. It has practical effects.
# [01:08] <TabAtkins> ChrisL: There isn't ever a piece of content for all possible purposes. You have to decide how much to rewrite vs restyle.
# [01:08] <TabAtkins> ChrisL: So we don't want to encourage people to write content with drastic rewriting just to restyle.
# [01:08] <glazou> major discussion about the CSS Regions frenzy right noz here
# [01:08] <TabAtkins> ChrisL: But still, we must accept that in some cases there will be rewriting - mobiles might get smaller chunks of content.
# [01:09] <TabAtkins> ChrisL: So content/style is often only one way anyway - most stylesheets are deeply connected to the content they're applied to.
# [01:09] <TabAtkins> ChrisL: But also, the important thing is just that it not *prevent* reasonable restyling without significant rewriting.
# [01:09] <TabAtkins> ChrisL: So I don't think we should preclude people putting content into HTML boxes.
# [01:10] <TabAtkins> florian: I'd like to get back to David's position.
# [01:10] * fantasai agrees with Bert, fwiw
# [01:10] <TabAtkins> dbaron: I think there are multiple pieces.
# [01:10] <TabAtkins> dbaron: One is that I think Chris's reasons for separation are incomplete - there are more.
# [01:11] <TabAtkins> dbaron: A bunch of technology designed around that separation in various ways assumes that the content is in the content.
# [01:11] <TabAtkins> dbaron: Various APIs, UIs. Selection, event models, etc.
# [01:11] <TabAtkins> ChrisL: Searching, indexing.
# [01:11] <TabAtkins> dbaron: I think some of what this issue has come to represent is that the design is very different than CSS in ways we can't quite put our finger on.
# [01:12] <TabAtkins> dbaron: We can't quite say what is weird about it.
# [01:12] <TabAtkins> dbaron: I think it's different from a bunch of things in a bunch of different ways.
# [01:12] <TabAtkins> dbaron: [something about two pieces]
# [01:12] <ChrisL> to-pieces
# [01:12] <TabAtkins> astearns: I agree that it's different, and that there are other concerns.
# [01:12] * ChrisL as in from and to
# [01:12] <TabAtkins> astearns: That do need to be addressed.
# [01:13] <fantasai> dbaron: e.g. you have to do things with two pieces, and if you don't do both (correctly), content just disappears
# [01:13] <TabAtkins> dbaron: Some concerns are about hwo it fits with APIs.
# [01:13] <TabAtkins> dbaron: How the author experience is different from the rest of CSS.
# [01:13] <TabAtkins> dbaron: And how it interacts with other layout algorithms.
# [01:13] <TabAtkins> astearns: As I said, I'd like to just talk about this one issue right now, and discuss the rest after.
# [01:14] <TabAtkins> astearns: I'd like to get past this one issue and get past it to everything else.
# [01:14] <TabAtkins> astearns: The messages you've put on the lsit recently, concerns about processing model, I'd like that to be a conversation rather than a pronouncement and then nothing.
# [01:14] <TabAtkins> dbaron: I think that whittling down a problem sets one at a time... it's troubling taking them one at a time.
# [01:15] <TabAtkins> astearns: I find it heartening, Bert, that even if we had any slot mechanism, you'd still allow that escape valve to use other boxes, such as from elements.
# [01:15] <florian> q+
# [01:16] <TabAtkins> Bert: I just think 'content' should be more powerful.
# [01:16] <TabAtkins> Bert: From that, it falls out that you can omit the content of an element by using 'content'.
# [01:16] * Joins: rhauck (~Adium@public.cloak)
# [01:16] <TabAtkins> glazou: In the past we designed a mechanism for dispatching content to various boxes.
# [01:16] <TabAtkins> glazou: You can say an element should be rendered on a page with a given selector.
# [01:17] <TabAtkins> glazou: Basically flow-from/to is the same.
# [01:17] <TabAtkins> TabAtkins: I don't think it's sufficiently close.
# [01:17] <TabAtkins> florian: As many people have been wrestling with as well, I think why I'm uncomfortable is that it seems we're introducing a new separation, in addition to styling/content.
# [01:18] <TabAtkins> florian: So far, the thing that contains your semantic document is also the thing you style.
# [01:18] <TabAtkins> florian: With regions, you have a set of elements on your page. You fetch your markup, then inject it somewhere else.
# [01:18] <TabAtkins> florian: So should that be additional elements, should it be CSS, something else?
# [01:18] <TabAtkins> florian: But it seems we're not styling the original markup. We're styling what you inject it into.
# [01:19] <TabAtkins> ChrisL: You're styling the container. You could make the same argument about abspos - it's not in its original placement anymore.
# [01:19] <dbaron> I make many arguments against absolute positioning.
# [01:19] <TabAtkins> astearns: And it's already common practice to template in HTML, slurp in content and fill out the template.
# [01:20] <TabAtkins> florian: I'm not necessarily saying this is an argument against regions, just that realizing this made it clearer to me.
# [01:20] * ChrisL @dbaron granted, you have a consistent position, but abspos has sailed
# [01:20] <TabAtkins> leif: It does seem that we are talking about a new mechanism.
# [01:20] <TabAtkins> dauwhe: There does seem to be an extra layer of indirection that feels odd, not necessarily bad or good.
# [01:20] <TabAtkins> astearns: Templating layers have been attempted before, between HTML and CSS. We haven't come up with one that works yet.
# [01:21] <TabAtkins> astearns: I expect people will continue working with that.
# [01:21] <TabAtkins> dauwhe: Yeah, we have content like a monolithic HTML file that can be rendered in many different ways. At this point it seems hard to imagine using our content with Regions.
# [01:22] <TabAtkins> astearns: I think your use-case is good for HTML templates, where you have that separate layer of concerns.
# [01:22] <TabAtkins> astearns: So, looping back to the issue.
# [01:22] <TabAtkins> astearns: It sounds like a concern that people have about the issue is that regions-as-elements is currently the only way to use flow-from, because we don't have the CSS box generation.
# [01:22] <TabAtkins> astearns: And they'd be much more comfortable with defining the CSS box generation before we continue.
# [01:22] <TabAtkins> astearns: I can sympathize with that.
# [01:23] <TabAtkins> astearns: I think grid slots are going to be a perfect mechanism to use with Regions.
# [01:23] <TabAtkins> astearns: But I don't see that happening for at least another year or two.
# [01:23] <TabAtkins> astearns: I'm a bit impatient, so I'd like to continue on with Regions without having to wait.
# [01:23] <TabAtkins> astearns: Particularly since we've defined Regions to be compatible with anything that CSS comes up with.
# [01:24] <TabAtkins> Bert: I'd rather work on 'content' first, since 'flow-from' conflicts.
# [01:25] <TabAtkins> Bert: That's a detail of the syntax. Nothing against the feature.
# [01:25] <TabAtkins> Bert: I think a missing feature is the ability to order the regions.
# [01:25] <TabAtkins> astearns: We had it, we took it out. It could go back in.
# [01:25] <TabAtkins> dbaron: Order is currently document order of the regions?
# [01:25] <TabAtkins> glazou: Yeah.
# [01:25] <dbaron> I think putting that back in makes it extra scary in terms of implementation complexity.
# [01:26] <TabAtkins> astearns: I think we should certainly have the discussions about the feature itself. I just want to close this issue itself.
# [01:26] <TabAtkins> astearns: I'm not going to ask for LC anytime soon.
# [01:26] <TabAtkins> fantasai: What's blocking us from working on this?
# [01:26] <TabAtkins> astearns: Beating us about the head about this one issue. ^_^
# [01:27] <TabAtkins> astearns: I think using flow-from on CSS-generated boxes needs to be done.
# [01:27] <TabAtkins> glazou: Alan and I put together a proposal for more pseudo-elements. Wasn't perfect, but we have to continue in that.
# [01:27] <TabAtkins> astearns: There just doesn't seem to be impl interest in generating CSS boxes. Lots of interest in Regions themselves. I think that should balance what we do first and progress with.
# [01:28] <TabAtkins> dbaron: I think they're all hard to implement.
# [01:28] <TabAtkins> dbaron: You've gone and done that work for one of them - there's demos and impls for it.
# [01:28] <TabAtkins> dbaron: To some extent that's good - stuff to test - but there's still a bias.
# [01:28] <TabAtkins> astearns: The effort we put into evangelizing it also shows the interest.
# [01:29] <TabAtkins> astearns: There are Windows devs I didn't evangelize to that started using it in IE and love it.
# [01:29] <TabAtkins> astearns: We hope people will start using it in iOS, and their use will inform the evolution.
# [01:29] <TabAtkins> glazou: I think starting from a prototype and getting usage data is very common in this WG. Happens all the time.
# [01:30] <TabAtkins> ChrisL: Something that tends to happen is that another browser does it, and you see if it's actually interoperable.
# [01:30] <TabAtkins> ChrisL: I think we have a second impl in IE, but it's based on earlier stuff. Is it comparable?
# [01:30] <TabAtkins> Rossen_: When we implemented Regions, the spec was at a much earlier stage.
# [01:30] <TabAtkins> Rossen_: I'm happy to keep moving the spec forward, and think it's favorable.
# [01:31] <TabAtkins> Rossen_: Moving our impl toward the spec won't be a problem when it stabilizes won't be a problem.
# [01:31] <TabAtkins> ChrisL: Right, but one of the things that helps stabilize is another impl actually implementing it.
# [01:31] * Joins: kawabata2 (~kawabata@public.cloak)
# [01:31] <TabAtkins> astearns: I agree. It would be fantastic for IE to move up to the current level of the spec.
# [01:31] <TabAtkins> astearns: But I understand the dev costs - twice as much to sync now and when finished.
# [01:32] <TabAtkins> astearns: We think that if you author content in Safari, it's a very light shim to make it work in IE. Just a difference about where it comes from.
# [01:33] <TabAtkins> Rossen_: From our POV, Safari just released this 2 months ago. Before that there was nothing else public. Not much incentive for us to track closely.
# [01:33] <TabAtkins> Rossen_: Apps built on it seem to be very successful.
# [01:33] * Joins: tkw (~uid24584@public.cloak)
# [01:33] <TabAtkins> Rossen_: The people developing apps are embracing elements. They have everything they need to do to make a working app.
# [01:34] <TabAtkins> astearns: And their use there should inform how we design the CSS feature.
# [01:34] * Quits: kawabata_ (~kawabata@public.cloak) ("Page closed")
# [01:35] <TabAtkins> [...]
# [01:35] <TabAtkins> Rossen_: Regions are just used in lots of applications.
# [01:35] <TabAtkins> Rossen_: All sorts of ways to present content.
# [01:35] <TabAtkins> Rossen_: They create HTML templates into which they feed content.
# [01:35] <ChrisL> "In blink we're pushing for simpler primitives that empower developers to build frameworks and applications." -- In blink we're pushing for simpler primitives that empower developers to build frameworks and applications.
# [01:35] <ChrisL> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/kTktlHPJn4Q/0r4yjDGWJFEJ
# [01:36] <TabAtkins> glazou: To summarize, I'm hearing there are use-cases for this, shipped by several vendors. We need a mechanism to create CSS boxes. But for the time being, the fact that it applies onto to HTML elements is just a side-effect of the lack of that mechanism.
# [01:36] <ChrisL> "It's important to understand that Blink has different goals than WebKit. It's not that I don't care about viewing books or magazines, it's that I'm more interested in making the web a compelling platform for applications" -- Adam Barth
# [01:36] <ChrisL> (same url)
# [01:37] <TabAtkins> astearns: Is there anyone in this discussion that would object to closing this issue, so we can focus on everything else?
# [01:39] <TabAtkins> [?]
# [01:39] <TabAtkins> leif: I don't want it to apply only to elements either, but I don't want to stop work on the spec either.
# [01:39] <TabAtkins> leif: Not sure that I caught the proposed resolution.
# [01:39] <TabAtkins> florian: So I think we have three options.
# [01:39] <fantasai> [Bert and astearns were talking about doing things in the right order. Bert agrees that some application use cases are handled well enough here, but that many others need a box generation mechanism.]
# [01:39] <TabAtkins> astearns: 1) Disallow flow-from on elements. (What the issue says.) I think we've rejected that.
# [01:39] * Bert thanks fantasai
# [01:40] <TabAtkins> astearns: 2) Close the issue with no change - allow it to apply to elements and existing block pseudos, and allow it to apply to more pseudos when they get invented.
# [01:40] <TabAtkins> astearns: 3) Allow it to apply to both, but don't close this issue until there's another method to create boxes.
# [01:41] <TabAtkins> leif: I want to maintain the separation of concerns indefinitely into the future. I think this is the biggest step CSS has made in this direction.
# [01:41] <TabAtkins> leif: I think we should give better solutions a place, rather than doing elements for temporary convenience.
# [01:42] <TabAtkins> florian: Taht matches (1). Does anyone have a fourth thing?
# [01:42] <TabAtkins> dbaron: I think fourth would be recognizing that we have a proposal with some advantages and disadvantages, and I dont' like just crossing off the disadvantages one by one.
# [01:43] <TabAtkins> szilles: We only have one solution on the table, though. Any others are off in the air so far.
# [01:43] <TabAtkins> florian: I think I share a number of David's concerns.
# [01:43] <TabAtkins> florian: I'm not yet comfortable with the general concept of Regions, but I think the point we're currently discussing is not a blocker.
# [01:44] <TabAtkins> florian: So in the interest of getting the other issues on the table, resolving this one which *is* well defined, seems like a reasonable thing to do to me.
# [01:45] <TabAtkins> fantasai: I think Regions is useful and well-designed if we have a box-generation mechanism. And if you have an iframe as a source.
# [01:46] <TabAtkins> fantasai: I think I can see an element pulling in the contents of another document and flowing things in. That makes sense to me structurally.
# [01:46] <TabAtkins> fantasai: Having a document that is then styled using box-generation mechanisms, templates, etc. also makes sense to me.
# [01:46] <TabAtkins> fantasai: Having a document with lots of empty elements doesn't make sense to me. I don't think we want that as an end result.
# [01:46] <TabAtkins> astearns: I agree. I think that third thing is only forced on us by the current state of the web platform, and I'd very much like to see it replaced by box generation.
# [01:47] <TabAtkins> fantasai: Okay. And I think Leif's point is that if a feature can be used in a bad way, we shouldn't use it, because we'll be stuck with it forever.
# [01:48] <TabAtkins> szilles: An important aspect of what Elika said - there are three components that are necessary to do this: content, styling, and template.
# [01:48] <TabAtkins> szilles: What Elika said is that one way to get all three is to have a document that's the template, and a document that's the content, and I can pour the content document into the styling document.
# [01:48] <TabAtkins> szilles: So your content document doesn't change, and you get good separation.
# [01:49] <TabAtkins> fantasai: I think the objections you're getting are largely through the flow-from capability, and not the rest of processing.
# [01:49] <TabAtkins> astearns: I disagree. The fragmentation model, the way named flows are constructed... I think David has deep-seated concerns about all of these things that I'd like to get discussed on the list.
# [01:50] <fantasai> [notes to minute-splicer - flowing content from one document into another is reader-application use case]
# [01:50] <TabAtkins> shans: I agree that you can get into a bad state by just doing things one issue at a time rather than holistically, but also with Alan's statement that we can't look at it holistically until we deal with this issue.
# [01:50] <fantasai> s/can be used/is designed/
# [01:50] <TabAtkins> s/shans/shepazu/
# [01:51] <TabAtkins> dauwhe: You said holistically - is it blasphemy to say that Regions should be attached to a document that does the box generation?
# [01:51] <fantasai> s/processing/processing and layout model/
# [01:52] <TabAtkins> Bert: I think in the ideal case we should say that the template part isn't text/html, some other format.
# [01:52] <TabAtkins> astearns: I have my opinion on what it'll end up with, but I don't think it matters for Regions specifically how that templating mechanism gets expressed.
# [01:53] <TabAtkins> Bert: Not for the spec, but for impl perhaps.
# [01:53] <TabAtkins> astearns: Certainly. That's why we've been working on the Regions processing model.
# [01:53] <TabAtkins> florian: David, you mentioned that Regions does things in an unusual way, and it makes you uncomfortable.
# [01:53] * fantasai thinks we should work on the overflow: fragments; proposal, and that would be a way of making technical progress on regions in a non-controversial way
# [01:54] <TabAtkins> florian: Is the indirection I said the same thing as what you said?
# [01:54] * hober thinks that Alan is not preventing the overflow:fragments proposal from being advanced by those who want to work on it
# [01:54] * fantasai isn't saying he is
# [01:54] <astearns> +1 hober. I like the overflow:fragments proposal :)
# [01:54] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [01:54] <astearns> I just don't think it addresses the same use cases
# [01:55] * Joins: rhauck (~Adium@public.cloak)
# [01:55] <TabAtkins> florian: What makes me feel weird is the whole indirection concept in the first place. Is that also what concerns you? Or is it something else?
# [01:55] * TabAtkins it covers a strict subset of the use-cases.
# [01:55] * fantasai is saying that using that, rather than flow-into/flow-from, as the mechanism to develop the relevant aspects of the CSS Regions spec, would be a better way to make progress
# [01:55] <TabAtkins> dbaron: There are parts of CSS where the way the spec is written is close to how it's implemented.
# [01:55] * fantasai and then once you have solved all of those problems, can move onto more problems
# [01:55] <TabAtkins> dbaron: There's not a ton of weird derivation you have to deal with.
# [01:56] <TabAtkins> dbaron: Layout systems are quite different. To implement them, you have to read separated parts of specs, and derive their interactions.
# [01:56] * fantasai also thinks, on a completely different tangent, that CSS needs a Table of Contents
# [01:56] <TabAtkins> dbaron: That's something that worries me a lot.
# [01:56] <TabAtkins> dbaron: There are a lot of implicit ordering constraints.
# [01:56] <TabAtkins> dbaron: For example, you have to lay out floats interleaved with inlines on the line they're anchored on, but abspos at the end of laying out their containing block.
# [01:57] * ChrisL an autogenerated cross-document index of defined terms would be lovely, too
# [01:57] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [01:57] <TabAtkins> dbaron: Part of what worries me is that we don't even understand the system well enough to understand the implications of changing this to allow flowing between these layout systems.
# [01:57] <TabAtkins> dbaron: And what that means for what authors expect.
# [01:58] <TabAtkins> dbaron: 'order' only applies in very limited circumstances, for Flexbox, and it barely depends on ordering anyway.
# [01:58] <TabAtkins> astearns: That's also why we took out ordering - it makes things way more complicated.
# [01:58] <TabAtkins> dbaron: I don't even fully understand the impliciations for how pagination interacts with auto-sizing.
# [01:59] <TabAtkins> dbaron: And what things would get us into interesting infinite loops if we weren't limited to 2-pass.
# [01:59] * TabAtkins ChrisL, that's possible now! (And a good argument for bikeshedding all the things.)
# [01:59] <TabAtkins> fantasai: There's a bunch of problems in Regions. Some of them are also overflow:fragments problems. Afaict, everyone thinks overflow:fragments is okay.
# [02:00] <TabAtkins> fantasai: I propose that instead of spending 2 hours every f2f, we focus on the overflow:fragments proposal for solving the technicla problems.
# [02:00] <TabAtkins> fantasai: Get that spec nailed down and solve all the regions problems.
# [02:01] <TabAtkins> fantasai: And then, when that's working, we've solved all the problems in regions, and we can look at the next chunk of things to bite off.
# [02:01] <TabAtkins> astearns: We've done that analysis. We found that overflow:fragments is not generic enough for the applications we want to put Regions to.
# [02:01] <TabAtkins> astearns: It doens't fit anything people put regions to with IE.
# [02:02] <TabAtkins> astearns: We have two impls of Regions that are being used, and devs that are super-excited about it.
# [02:02] <TabAtkins> astearns: I don't see the interest in overflow:fragments, I think because it has limitations.
# [02:02] <fantasai> TabAtkins: I don't quite agree. Regions has been sold very well, but overflow: fragments has been barely talked aobut.
# [02:02] <fantasai> TabAtkins: There are some things you can't do with it, but a lot of things you can.
# [02:03] <TabAtkins> Rossen_: Layout is the least interesting thing here. We take it for granted.
# [02:03] <TabAtkins> Rossen_: For us, if people can't use the Regions primitives, it's useless.
# [02:04] <TabAtkins> TabAtkins: Note that "fragmenting like pages" is what overflow:fragments does. ^_^
# [02:04] <TabAtkins> Rossen_: Right. But with elements you get OM, events, etc too.
# [02:04] <TabAtkins> TabAtkins: Granted.
# [02:05] <TabAtkins> astearns: We're not currently interested in just doing overflow:fragments.
# [02:05] <TabAtkins> TabAtkins: Well, we have two browses that want to use Regions, and two that want to do simpler things first.
# [02:06] <TabAtkins> fantasai: [draws a list of things on the board]
# [02:06] <TabAtkins> fantasai: #4 (elements as regions) isn't part of our eventual goal. We both agree on this.
# [02:06] <TabAtkins> astearns: Right. It's a stepping-stone.
# [02:07] <TabAtkins> smfr: I think WK is interested in having that long-term.
# [02:07] * TabAtkins wonders why he volunteered to minute this.
# [02:07] <TabAtkins> astearns: I think it's good for solving some things forever. I'd like to keep it.
# [02:07] <TabAtkins> Bert: Talking about documents, we dont' want this. Talking about GUIs, we're fine with this.
# [02:07] * ChrisL table booking in 1.5 hours, hang in there
# [02:08] <TabAtkins> fantasai: That's #2 (reader-content, document-in-document).
# [02:08] <TabAtkins> astearns: #2 can be done with #4.
# [02:08] <dauwhe> smfr: also has concerns about multiple-document approach
# [02:09] <ChrisL> scribenick: ChrisL
# [02:09] <ChrisL> (elika has 4 cases on the whiteboad)
# [02:10] <ChrisL> sylvaing: dont understand how fragments solves all the use cases
# [02:10] <dauwhe> s/whiteboad/whiteboard/
# [02:10] <ChrisL> fantasai: it doesn't
# [02:10] <ChrisL> ... alan want to close the one issue
# [02:10] <ChrisL> sylvaing: how does closing it solve those issues
# [02:11] <ChrisL> dbaron: also solved the ordering layout issues but not sure how many
# [02:11] <ChrisL> ... regions lets you flow between different types
# [02:11] <ChrisL> astearns: currently allows you to do the same thing
# [02:12] <ChrisL> sylvaing: for everything else, don't see how fragments fixes the issues
# [02:12] <ChrisL> dbaron: there are paths that would not apply to regions
# [02:12] <astearns> s/currently/fragments currently/
# [02:13] <dbaron> s/paths for fixing some of the problems/
# [02:13] <dbaron> s/paths/paths for fixing some of the problems/
# [02:13] <ChrisL> shepazu: this separation is irrelevant for svg which wants to do complex wrapped text but was blocked by css
# [02:13] <ChrisL> ... thei proposal works very well for svg and could work well in html later
# [02:13] * Quits: jet (~junglecode@public.cloak) (jet)
# [02:14] <ChrisL> smfr: sounds more like exclusions to me
# [02:14] <ChrisL> shepazu: want to see this move forward at minimum for svg
# [02:15] <ChrisL> fantasai: (draws a complex meme-worthy mind map on most of the board)
# [02:15] <ChrisL> ... with a happy place
# [02:16] <ChrisL> fantasai: for the super advanced cases, eventually work on regions
# [02:17] <ChrisL> astearns: see your point but this loooong path is much longer than the small loop because we worked on regions for 2 years with two engineering teams
# [02:17] <ChrisL> ... getting it shipping in 2 browsers, while overflow fragments is not implemented and has the longest list of issues
# [02:18] <ChrisL> astearns: a lot is already built on top of regions, and those cant be build on fragments without a lot of scripting
# [02:18] * TabAtkins Regions is the Dart/NaCl/asm.js/etc of CSS.
# [02:18] <ChrisL> florian: if we discover the happy place is actually not nice, by fixing all the "how" before examining the "should" we waste time
# [02:18] <glazou> TabAtkins, forgot Perl ?-)
# [02:19] <ChrisL> florian: not convinced its a bad idea but we need that discussion
# [02:19] * TabAtkins glazou, perl's not in the browser. ^_^
# [02:19] <ChrisL> astearns: getting examples of regions in actual use is valuable. we learn from how developers actually use them
# [02:20] <ChrisL> ... we can talk in theory about whatis good or not good, but the actual uses people put it to is more convincing
# [02:20] <ChrisL> florian: less worried than dbaron but understand his worry. Its not that we have a lot of issues, its mmore thatwe are not sure if we should be doing it at all
# [02:21] <ChrisL> astearns: have not heard that sentiment. More that there are crucial issues that affect the platform
# [02:21] <ChrisL> dbaron: am hearing that, and hearing "name specific things to fix" instead
# [02:22] <ChrisL> shepazu: what in particular is not a good idea?
# [02:22] <ChrisL> fantasai: having those elements be there in the document just to flow into
# [02:22] <ChrisL> florian: if I was alone i would drop it but want to back up dbaron
# [02:23] <ChrisL> SteveZ: what is the goal here
# [02:24] <ChrisL> shepazu: dbaron you said it was not clear from the beggining its what we should be doing. what should we be doing
# [02:24] <ChrisL> dbaron: mainly worried about the complexity
# [02:24] <ChrisL> shepazu: ok so not the funcrionality itseld, just the complexity
# [02:25] <ChrisL> shepazu: (call for straw poll, gets about 2/3 or room in favour of the functionality)
# [02:25] <ChrisL> shepazu: its necessary to have the flow, to have the shaped flow
# [02:25] <ChrisL> astearns: its in shapes level 2
# [02:26] <dbaron> dbaron: question isn't just about whether it's desirable, but whether it's the best (or reasonably good) thing we could do with the resources we put into it, relative to alternative uses of those resources
# [02:26] <ChrisL> krit: fragmentation would not help for svg, it creates pseudo boxes
# [02:26] <fantasai> s/fragmentation/overflow:fragment/
# [02:27] <ChrisL> shepazu: not hearing agreement about wanting to do flow-like things. No up to the people in the room. its up to the developers that want this feature
# [02:28] <ChrisL> glazou: shapes-like, exclusion-like stuff is all over books, magazines, will be in ebooks who are a css custoomer
# [02:28] <ChrisL> ... if we decide we dont want this, then it means we refuse to address this market or their feedback
# [02:29] <ChrisL> florian: the question alan posed has been used as a proxy for exactly that question. do we address that market or not
# [02:29] <ChrisL> ... worth answering explicitly. we have not said yes. as a group we have said maybe
# [02:29] <ChrisL> florian: pwersonally would answer yes
# [02:30] <ChrisL> ChrisL: agree
# [02:31] <ChrisL> dbaron: you are asking "does it have value" not "what is the value/cost tradeoff"
# [02:31] <ChrisL> ... compared to "content working at a range of device sizes". Some of these are not scaling
# [02:31] <ChrisL> shepazu: media queries lets you make scalable designs
# [02:31] <dbaron> and what is the tradeoff against other requirements
# [02:32] <ChrisL> astearns: chrome has decided to not do that. ff has too. safari and ie have jumped in with both feet. not clear where opera stands. so at least half the implementors thik the tradeoff is worth making
# [02:32] * Quits: MaRakow_ (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [02:33] <ChrisL> s/thik/think/
# [02:33] <ChrisL> fantasai: (example of grids changing tack)
# [02:33] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [02:33] <ChrisL> astearns: we have had actionable feedback on regions and incorporated it
# [02:34] <ChrisL> shepazu: point is, is there a consensus in the group to work on it. at least two vendors have said this is a use case they want to adderess. have not seen commitment from the others
# [02:35] <fantasai> TabAtkins: As a rep of one browser not doing it right now. We don't have problem with people working on Regions, but don't want it finalized until we're ready to implement.
# [02:35] <fantasai> TabAtkins: We are happy to let Regions continue as WD
# [02:35] <ChrisL> TabAtkins: would not like regions to go to lc until we are ready to implement but for now happy to see it continue
# [02:35] <ChrisL> krit: you want to stop it going to last call
# [02:35] <ChrisL> s/call/call?/
# [02:36] <fantasai> shepazu, I don't think anyone here things the problem of flowing content through various boxes is not worth solving
# [02:36] <fantasai> shepazu, the argument is that the Regions proposal does it in ways that do more harm than good
# [02:36] <ChrisL> krit: so you say we should wait until blink implements it to declare it stable
# [02:36] <ChrisL> peter: (rathole)
# [02:37] <ChrisL> shepazu: straw pole on whether we want to solve content flowing through disjoint boxes
# [02:38] <dbaron> fantasai: ... not the question of whether Regions is the way we want to do it
# [02:38] <ChrisL> s/pole/poll/
# [02:38] <ChrisL> (no objection)
# [02:38] * Quits: eliezerb_2nd (~Eliezer@public.cloak) ("Leaving")
# [02:38] <dbaron> no objection to taking it on as a work item
# [02:38] <ChrisL> fantasai: no-one is objecting to the problem, only the proposed solution
# [02:39] <ChrisL> Rossen_: can we get back to the originall issue then
# [02:39] <liam> [something _like_ flows and regions is very central to needs of publishing, flows through disjoint boxes]
# [02:39] <ChrisL> dbaron: not sure on tradoff to other problems worth solving
# [02:40] <ChrisL> SteveZ: each group of particuipants is pursuing their own agenda and may get another participant to ride along but we are all heading off in different directions
# [02:40] <ChrisL> ... lots of things not making much progres
# [02:41] <ChrisL> ... so your comment applies to many things on our agenda
# [02:41] * liam zakim, call liam-617
# [02:41] * liam oh
# [02:41] <ChrisL> ... concerned that 2.1 was a very focussed effort whjile post-21 has been much more diffuse. slowing down and broadening faster than we are finishing
# [02:41] <ChrisL> ... hence some concern from w3m about finishing things
# [02:42] <ChrisL> ... this is a meta comment
# [02:42] <ChrisL> TabAtkins: we have done significant consensus building around the idea of shadow dom
# [02:43] <ChrisL> dauwhe: see lots of different efforts, no sense of an overall goal
# [02:43] <ChrisL> glazou: correct
# [02:44] <ChrisL> dauwhe: coming from content creation so have my own biases and interests. wonder what the overall priorities are
# [02:44] <ChrisL> glazou: each vendor had their own strategy based on target audience. compromise is thus weak
# [02:44] <ChrisL> ... many areas of focus on the radar, everything relies on what the implementors are willing to implement and ship
# [02:45] <ChrisL> ... needs of content creators not so much considered. general feeling that a spec at last call or cr is good enough
# [02:45] <ChrisL> florian: if we ask the questions explicitly, most will say yes go ahead.
# [02:46] <ChrisL> florian: so the second question,
# [02:46] <ChrisL> dbaron: depends on wording of the poll
# [02:47] <ChrisL> astearns: would rather deal with reservation as they arise, do not want to cut off discussion
# [02:47] <ChrisL> fantasai: clear to me that there is a substantial part of wg that feels this is very important. shipping products on it. so we work on it
# [02:48] <ChrisL> ... if anyone has reservatiosn they should fix them
# [02:48] <ChrisL> ... not say stop
# [02:48] <ChrisL> fantasai: (example of vertical text. very important. can say not important)
# [02:48] * dauwhe +1 to fantasai
# [02:48] <ChrisL> s/can/can't
# [02:49] <ChrisL> fantasai: there is a point on arguing how to make a good solution peiople are happy to iimplement when it beciomes a prioority
# [02:49] <ChrisL> astearns: if we have about half the wg engaged in this and the consensus is that this technology should allow flow-from to apply to elelents as well as othe r boxes
# [02:50] <ChrisL> astearns: blocking discussion on other things
# [02:50] <ChrisL> leif: will stop being a proxy if you disallow it applying to elements
# [02:50] <ChrisL> astearns: leif you were the only one to want that disallowed
# [02:51] <ChrisL> fantasai: its blocking discussion
# [02:52] <ChrisL> astearns: blocking and the issue shjould be resolved without change because nearly everyone thinks that will be the end result anyway
# [02:52] <ChrisL> bbos: think we will not have a flow-from property
# [02:52] <ChrisL> ... want to talk about region-based styling
# [02:53] <ChrisL> astearns: dow we a) solve by waiting for a css box generation model b) no change c) stop progress on regions
# [02:54] <ChrisL> glazou: (reads earlier formulation from irc)
# [02:54] <tantek> OH: "There doesn't have to be a queue, I'm minuting."
# [02:54] <AdobeSeattle> 1) Disallow flow-from on elements. (What the issue says.) I think we've rejected that.
# [02:55] <AdobeSeattle> 2) Close the issue with no change - allow it to apply to elements and existing block pseudos, and allow it to apply to more pseudos when they get invented.
# [02:55] <tantek> welcome AdobeSeattle!
# [02:55] <AdobeSeattle> 3) Allow it to apply to both, but don't close this issue until there's another method to create boxes.
# [02:56] <ChrisL> 2 3 2 2 - 2 2 2 - 2 2 2 (3) 2 2 - 2 2 1 2 - 2 2 2
# [02:56] <ChrisL> the twoes have it
# [02:57] <ChrisL> glazou: declare a consensus
# [02:57] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [02:57] <ChrisL> (adjourned)
# [02:57] <ChrisL> rrsagent, make minutes
# [02:57] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/29-css-minutes.html ChrisL
# [02:57] <ChrisL> Bert: formal objection
# [02:57] <dbaron> I'd note that I abstained.
# [02:57] <ChrisL> resolution: the issue is closed
# [02:57] <ChrisL> rrsagent, make minutes
# [02:57] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/29-css-minutes.html ChrisL
# [02:58] <glenn> signing off
# [02:58] <glenn> rrsagent, make minutes
# [02:58] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/29-css-minutes.html glenn
# [02:58] <ChrisL> RRESOLVED: thclose issue number 1 on regions
# [02:58] <ChrisL> rrsagent, make minutes
# [02:58] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/29-css-minutes.html ChrisL
# [02:58] <fantasai> I think I probably agree with Bert
# [02:58] * Quits: glazou (~glazou@public.cloak) (glazou)
# [02:58] * Quits: stakagi (~stakagi@public.cloak) ("TakIRC")
# [02:58] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [02:58] * Quits: AdobeSeattle (~AdobeSeattle@public.cloak) ("Page closed")
# [02:58] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [02:59] * Quits: koji (~koji@public.cloak) ("")
# [02:59] <fantasai> and I don't really understand why dbaron abstains, he seemed pretty opinionated
# [02:59] * Quits: sgalinea_ (~sgalineau@public.cloak) (Client closed connection)
# [03:00] <dbaron> I hadn't decided which option of those 3 that I actually preferred.
# [03:00] <dbaron> (the other three abstentions were from observers)
# [03:02] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [03:03] <dbaron> I'd have preferred to leave the issue open
# [03:03] <dbaron> but the reason I'd want to keep it open wasn't "until there's another method to create boxes", but because it's an existing disadvantage with the spec that we should consider when deciding whether to advance the spec.
# [03:03] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [03:03] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [03:04] <dbaron> so I suppose my vote was a semi-3
# [03:04] <dbaron> except that 3 was overcostrained
# [03:04] <dbaron> overconstrained
# [03:05] * Quits: smfr (~smfr@public.cloak) (smfr)
# [03:05] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [03:06] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:08] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [03:08] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [03:11] * Quits: Rossen_f2f (~Rossen_f2f@public.cloak) (Ping timeout: 180 seconds)
# [03:13] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [03:33] * Quits: emalasky1 (~Adium@public.cloak) ("Leaving.")
# [05:04] * Joins: lmcliste_ (~lmclister@public.cloak)
# [05:11] * Quits: lmcliste_ (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [05:12] * Joins: lmcliste_ (~lmclister@public.cloak)
# [05:12] * Joins: emalasky (~Adium@public.cloak)
# [05:17] * Joins: lmclist__ (~lmclister@public.cloak)
# [05:17] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [05:20] * Quits: lmclist__ (~lmclister@public.cloak) (Client closed connection)
# [05:20] * Joins: lmcliste_ (~lmclister@public.cloak)
# [05:35] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [05:35] * Joins: rhauck (~Adium@public.cloak)
# [05:36] * Quits: nikos (~Thunderbird@public.cloak) (nikos)
# [05:38] * Joins: lmcliste_ (~lmclister@public.cloak)
# [05:40] * Joins: rhauck1 (~Adium@public.cloak)
# [05:44] * Joins: nikos (~Thunderbird@public.cloak)
# [05:45] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [05:48] * Joins: rhauck (~Adium@public.cloak)
# [05:49] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [05:51] * Joins: stakagi (~stakagi@public.cloak)
# [05:54] * Joins: tantek (~tantek@public.cloak)
# [05:55] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [05:59] * Joins: jdaggett (~jdaggett@public.cloak)
# [06:39] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [06:52] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [06:59] * Quits: tantek (~tantek@public.cloak) (tantek)
# [07:06] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [07:20] * Joins: smfr (~smfr@public.cloak)
# [07:31] * Joins: dbaron (~dbaron@public.cloak)
# [07:44] * Joins: jet (~junglecode@public.cloak)
# [07:53] * Quits: smfr (~smfr@public.cloak) (smfr)
# [07:54] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [07:55] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:58] * Joins: tantek (~tantek@public.cloak)
# [08:02] * Joins: tantek_ (~tantek@public.cloak)
# [08:06] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [08:06] * tantek_ is now known as tantek
# [08:22] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:33] * Joins: emalasky (~Adium@public.cloak)
# [08:44] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:54] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:59] * Joins: florian (~Adium@public.cloak)
# [09:05] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [09:06] * Quits: florian (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [09:16] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:16] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:24] * Joins: dauwhe (~dauwhe@public.cloak)
# [09:35] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [09:47] * Disconnected
# [09:50] * Attempting to rejoin channel #css
# [09:50] * Rejoined channel #css
# [09:50] * Topic is 'http://wiki.csswg.org/planning/seattle-2014'
# [09:50] * Set by plinss on Mon Jan 27 17:42:43
# [09:51] * Quits: krijnh (~krijnhoetmer@public.cloak) (Ping timeout: 180 seconds)
# [10:23] * Disconnected
# [10:24] * Attempting to rejoin channel #css
# [10:24] * Rejoined channel #css
# [10:24] * Topic is 'http://wiki.csswg.org/planning/seattle-2014'
# [10:24] * Set by plinss on Mon Jan 27 17:42:43
# [10:28] * Quits: krijn (~krijnhoetmer@public.cloak) (Ping timeout: 180 seconds)
# [10:29] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:36] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [11:00] * Quits: jet (~junglecode@public.cloak) (jet)
# [11:30] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:37] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [11:41] * Joins: darktears (~darktears@public.cloak)
# [12:30] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:37] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:44] * Quits: zcorpan (~zcorpan@public.cloak) ("Leaving...")
# [13:31] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:38] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [14:13] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [14:31] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:38] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [14:56] * Joins: florian (~Adium@public.cloak)
# [15:09] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:18] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [15:22] * Joins: eliezerb (~Eliezer@public.cloak)
# [15:30] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [15:32] * Joins: florian (~Adium@public.cloak)
# [15:32] * Quits: eliezerb (~Eliezer@public.cloak) (Client closed connection)
# [15:32] * Joins: eliezerb (~Eliezer@public.cloak)
# [15:52] * Joins: stakagi (~stakagi@public.cloak)
# [16:03] * leaverou_away is now known as leaverou
# [16:34] * leaverou is now known as leaverou_away
# [16:36] * leaverou_away is now known as leaverou
# [16:40] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [16:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:47] * Joins: emalasky (~Adium@public.cloak)
# [16:47] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [16:47] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:53] * Joins: stakagi (~stakagi@public.cloak)
# [16:56] * leaverou is now known as leaverou_away
# [16:56] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [17:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:11] * Joins: birtles (~uid16523@public.cloak)
# [17:14] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:16] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [17:17] * Joins: jet (~junglecode@public.cloak)
# [17:18] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:20] * Joins: AdobeSeattle (~AdobeSeattle@public.cloak)
# [17:37] * Joins: SteveZ (~SteveZ@public.cloak)
# [17:38] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [17:45] * Joins: MaRakow (~MaRakow@public.cloak)
# [17:48] * Joins: lmcliste_ (~lmclister@public.cloak)
# [17:52] * Joins: smfr (~smfr@public.cloak)
# [18:00] * Joins: Rossen_f2f (~Rossen_f2f@public.cloak)
# [18:00] * Joins: emalasky (~Adium@public.cloak)
# [18:05] * Joins: stakagi (~stakagi@public.cloak)
# [18:07] * Joins: heycam (~cam@public.cloak)
# [18:10] * Joins: sgalineau (~sgalineau@public.cloak)
# [18:10] * Joins: glazou (~glazou@public.cloak)
# [18:11] * Joins: dbaron (~dbaron@public.cloak)
# [18:11] * Quits: dbaron (~dbaron@public.cloak) (Client closed connection)
# [18:11] * Joins: dbaron (~dbaron@public.cloak)
# [18:11] <glazou> ScribeNick: SimonSapin
# [18:11] <SimonSapin> ScribeNick: SimonSapin
# [18:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:11] * Joins: florian (~Adium@public.cloak)
# [18:11] <SimonSapin> dauwhe: Talk about page selectors
# [18:12] <SimonSapin> dauwhe: Simple HTML (projecting) with <section>
# [18:12] <SimonSapin> dauwhe: When paged, the first page of the chapter is special
# [18:13] <SimonSapin> dauwhe: Several kinds of pages: left/right, start of sections, …
# [18:13] <SimonSapin> dauwhe: special graphics, bg images, colors, etc.
# [18:13] <SimonSapin> dauwhe: CSS Paged Media defines ways to select :left/:right/:first (of the document)/:blank
# [18:13] <SimonSapin> dauwhe: When we demand starting on a left page, we may create a blank right page
# [18:14] * Joins: yamamoto (~yamamoto@public.cloak)
# [18:14] <SimonSapin> dauwhe: In particular, first page of chapters
# [18:14] <SimonSapin> dauwhe: In previous GCPM drafts and some impl… Prince has idea of page groups
# [18:14] <SimonSapin> dauwhe: <section> element creates pages, forming one group
# [18:15] <SimonSapin> dauwhe: The page group is the fragmentation container of the pages
# [18:15] <SimonSapin> dauwhe: Prince has a 'page-group' property
# [18:15] * dbaron doesn't follow this page-group bit
# [18:15] <SimonSapin> dauwhe: :first will apply to the first page of the group
# [18:15] <SimonSapin> dauwhe: conflicts with 2.1 where :first is only the first of the document
# [18:16] <SimonSapin> dauwhe: also :nth() selector for pages
# [18:16] <SimonSapin> dauwhe: concerned about terminology, others have nth-something
# [18:16] <SimonSapin> dauwhe: proposing :nth-page() to clarify
# [18:16] <SimonSapin> dauwhe: This is not about styling the content of the page, only the page rule, headers, footers, etc.
# [18:17] <SimonSapin> dauwhe: if you assign an element to a named page, haven’t figured out why not automatically create page groups
# [18:17] * Joins: rhauck (~Adium@public.cloak)
# [18:17] <SimonSapin> (projecting an example)
# [18:18] <SimonSapin> dauwhe: :nth-page() on a named page, selecting withing that page group
# [18:18] <SimonSapin> dauwhe: would help to style first page of chapters
# [18:18] <dbaron> A:nth-page(1) being nth within the context of A isn't how selectors normally work...
# [18:18] <fantasai> right, I think that's a syntactic mistake
# [18:18] <SimonSapin> astearns: How there are two page group cases?
# [18:18] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:19] <fantasai> it's like expecting foo:nth-child(even) to select every other "foo"
# [18:19] <SimonSapin> dauwhe: I create a page group on a <div> element. Every new <div> creates a new page group
# [18:19] * Joins: tantek (~tantek@public.cloak)
# [18:19] <fantasai> but we're solving that with :nth-child(even of foo), we could tweak the syntax here similarly
# [18:19] <SimonSapin> dbaron: Any div that create page groups has page breaks before and after?
# [18:19] <SimonSapin> dauwhe: yes
# [18:20] <SimonSapin> fantasai: You’re proposing that giving a page name should automatically create a group
# [18:20] <SimonSapin> dauwhe: yes
# [18:20] <SimonSapin> fantasai: that’s better. No awkward binding between properties
# [18:20] <SimonSapin> fantasai: but backward compat with existing impl of css-page. If you give the same page name to sibling elements, if the fit they can be on the same page
# [18:21] <SimonSapin> fantasai: we can’t have 'page' cause a new page break every time
# [18:21] <SimonSapin> fantasai: we can still have it create a page group. It won’t force a break
# [18:21] <SimonSapin> fantasai: whatever page it starts on will be the first of that group
# [18:22] <SimonSapin> SimonSapin: 'page' does create breaks with different names
# [18:22] <SimonSapin> dbaron: how would selectors work?
# [18:22] <SimonSapin> fantasai: Match multiple page names/selectors
# [18:23] <SimonSapin> astearns: I understand why page 6 does not match (???)
# [18:23] <fantasai> s/(???)/A:nth-page(1)/
# [18:23] <SimonSapin> dauwhe: the element that created everything here is the ancestor
# [18:24] <SimonSapin> dbaron: A:nth-page(1) is not how selectors work usually
# [18:24] <SimonSapin> dbaron: people want p:nth-child(4) to match the 4th p, but it’s the 4th child
# [18:24] <SimonSapin> fantasai: we exetended :nth-child() in Selectors 4, :nth-child(4 of p)
# [18:25] <SimonSapin> dauwhe: it’s hard to know what pages are, they’re not elements in the DOM
# [18:25] <SimonSapin> dauwhe: do we like :nth-page() better than :nth()?
# [18:25] <SimonSapin> SimonSapin: yes
# [18:25] <SimonSapin> fantasai: In @page context, :nth() is clear enough
# [18:25] <SimonSapin> fantasai: :first is not :first-page
# [18:26] <SimonSapin> fantasai: not sure it should be -page
# [18:26] <SimonSapin> dauwhe: I’d be fine with that, whatever the group thinks is reasonable
# [18:26] <fantasai> SimonSapin: One issue with :nth() as it's currently specified
# [18:26] <fantasai> SimonSapin: [something about specificity?]
# [18:27] <fantasai> SimonSapin: Usually selectors are independent of each other, this is why we have :nth-child(.. of ..)
# [18:27] <SimonSapin> s/[something about specificity?]/or maybe as implemented in Prince
# [18:27] <SimonSapin> fantasai: space is optional: @page:nth()
# [18:28] <SimonSapin> fantasai: do we have a :last selector?
# [18:28] <SimonSapin> dauwhe: no. People want that. See requests all the time
# [18:28] * Joins: shepazu (schepers@public.cloak)
# [18:28] <SimonSapin> dbaron: what happens when the special style make it no longer the last page?
# [18:29] <SimonSapin> dauwhe: usually it’s about margin boxes, not affecting page count
# [18:29] <SimonSapin> SimonSapin: we still have to define what happens in "bad" cases
# [18:29] * Joins: plh (plehegar@public.cloak)
# [18:29] <SimonSapin> dbaron: It might make sense disallow changing page margins in :last
# [18:29] <SimonSapin> fantasai: or borders, or …
# [18:30] <SimonSapin> dauwhe: makes sense
# [18:30] * shepazu rrsagent, make minutes
# [18:30] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/29-css-minutes.html shepazu
# [18:30] <SimonSapin> dauwhe: objections to :nth() rather than :nth-page()?
# [18:30] <SimonSapin> dbaron: I’m fine with that, more concerned about the context thing
# [18:31] <fantasai> ScribeNick: fantasai
# [18:31] * Joins: koji (~koji@public.cloak)
# [18:31] <dbaron> dbaron: ... that A:nth(1) is the first A page rather than an A page that is also the first page
# [18:31] <SimonSapin> dbaron: that A:nth(1) with the first A page, rather than the first page that is also A
# [18:31] <fantasai> ScribeNick: SimonSapin
# [18:32] <dbaron> fantasai: We're solving the same problem with :nth-child() in selectors4; we should do the same thing here.
# [18:34] <SimonSapin> fantasai: Sounds like if ppl are ok with having 'page: name' be non-inheritable, creating a group
# [18:34] <SimonSapin> fantasai: and have :nth(An+B of name)
# [18:34] <SimonSapin> fantasai: I’d have to take an action item to update css-page
# [18:34] <SimonSapin> fantasai: and you to delete the page-group property
# [18:35] <SimonSapin> fantasai: do we want to add :first(of A) ?
# [18:35] <fantasai> s/of//
# [18:37] <SimonSapin> RESOLVED: 'page: name' is not inheritable, creates a group, but does not force page breaks between groups of the same name (for compat). First page of the group might be the last of another group.
# [18:38] <SimonSapin> RESOLVED: keep :nth() as the name, but extend it like L4 :nth-child() to solve the "first of group" problem
# [18:39] <SimonSapin> part of the previous resolution: delete the page-group property
# [18:39] <SimonSapin> RESOLVED: add :first(A)
# [18:40] <SimonSapin> s/extend it/extend functionality/
# [18:40] <SimonSapin> fantasai: within @page context there is no ambiguity in :nth()
# [18:41] <SimonSapin> heycam: is :nth() valid in style rules?
# [18:41] <SimonSapin> fantasai: no
# [18:41] <SimonSapin> SimonSapin: page selectors are completely separate from Selectors
# [18:41] * TabAtkins is finally coming to Adobe. Will be there in 20m or so.
# [18:42] <SimonSapin> heycam: I want to have the full page figure on a separate landscape page
# [18:42] * fantasai can you grab my W3C bag from the closet, TabAtkins ?
# [18:42] * fantasai forgot to bring it :(
# [18:42] * TabAtkins Yup.
# [18:42] <SimonSapin> dauwhe: It’s an issue I want to address at some point, but need input from implementers
# [18:42] * fantasai thanks!
# [18:42] <SimonSapin> dauwhe: being able to switch to a different named page without breaking the flow would enable all sorts of stuff
# [18:44] <fantasai> SimonSapin: I think page selectors belong in Paged Media spec, except that nobody's really working on that atm
# [18:44] <fantasai> SimonSapin: don't know if it's better to move them out
# [18:44] <fantasai> fantasai: I think we can work on it in GCPM, then move it over once closer to done
# [18:47] <SimonSapin> glazou: May CSS meeting, dates are firm now. Co-hosted by Samsung and W3C Korean office
# [18:48] <SimonSapin> glazou: Request to have a meetup on thursday morning. First time working group meeting in Korea, it’s a big deal
# [18:48] <SimonSapin> glazou: Suggest booking flight as soon as possible
# [18:48] <SimonSapin> plh: What do you want to do at this meetup?
# [18:49] <SimonSapin> glazou: they are interested in our view of the future of CSS, and new industries we start touching
# [18:49] * krit heycam sgalineau: Did Tav register for SVG F2F and FX TF?
# [18:49] <SimonSapin> F2F dates: May 19 to 21
# [18:49] <SimonSapin> meetup on May 22
# [18:50] <SimonSapin> glazou: you need a passport valid 6 months after leaving Korea
# [18:50] <SimonSapin> glazou: you may not need a visa, but immigration can be tough
# [18:52] <fantasai> ScribeNick: fantasai
# [18:53] * heycam krit he did not repond to the wbs page
# [18:53] <fantasai> Topic: CSS2.1
# [18:53] <fantasai> SimonSapin: When image has no size specified and has no intrinsic size, the default size is 300x150 px
# [18:53] <fantasai> SimonSapin: except if that doesn't fit the device width, in which case it is the largest 2:1 rectangle that fits the device width
# [18:54] <fantasai> SimonSapin: One issue is that it says device rather than viewport
# [18:54] <fantasai> SimonSapin: It's such a rare case that I think it's not worth the complexity
# [18:54] <fantasai> SimonSapin: Would like to simplify this to be just 300x150
# [18:54] * fantasai thinks receipt printers might fall into this category :P
# [18:54] <fantasai> SimonSapin: I couldn't get a testcase on a small enough device
# [18:54] <fantasai> SimonSapin: Some implementations do 300x150, some do completely different
# [18:54] <fantasai> SimonSapin: Don't understand Chrome's behvior, e.g.
# [18:55] <fantasai> SimonSapin: They seem to use size of viewport?
# [18:55] <fantasai> fantasai: Did you test the correct case -- no intrinsic size or aspect ratio?
# [18:55] <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Jan/0310.html
# [18:55] <fantasai> dbaron: normal case for that is an <iframe>
# [18:55] * plh fantasai, let's leave the room at 10:45, since we'll need to get on the rental car bus
# [18:55] <SimonSapin> body:after {
# [18:56] <SimonSapin> content: url('data:image/svg+xml,\
# [18:56] <SimonSapin> <svg xmlns="http://www.w3.org/2000/svg">\
# [18:56] <SimonSapin> <rect width="100%" height="100%"/>\
# [18:56] <SimonSapin> </svg>\
# [18:56] <SimonSapin> ');
# [18:56] <SimonSapin> }
# [18:56] * Joins: kazutaka (~kazutaka@public.cloak)
# [18:56] <fantasai> SimonSapin: This si my testcase, maybe someone has a better one
# [18:56] <fantasai> florian: Your proposal makes sense to me
# [18:57] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [18:57] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ciframe%20border%3E
# [18:57] * Ms2ger wonders if plh is going on a date with fantasai or something
# [18:57] * heycam krit Tav says "I would like to call in for discussions indicated with the "#" sign. I can call in for the second morning session Thursday and Friday. Thanks. Tav"
# [18:57] * heycam on the agenda page
# [18:57] * fantasai is getting a ride to the airport
# [18:57] <SimonSapin> "Otherwise, if 'width' has a computed value of 'auto', but none of the conditions above are met, then the used value of 'width' becomes 300px. If 300px is too wide to fit the device, UAs should use the width of the largest rectangle that has a 2:1 ratio and fits the device instead. " http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width
# [18:58] * krit heycam that does not include the masking discussion I suppose? He is the one objecting
# [18:58] <fantasai> smfr: iframe gives 300x150. I think SVG case is a bit special
# [18:58] <fantasai> dbaron: Or it could be that the iframe case is special :)
# [18:58] <fantasai> fantasai: I don't have a problem with making this change, does anyone object or need more time?
# [18:58] * Ms2ger oh, that's a much less fun thing to imagine :)
# [19:00] <fantasai> Bert: It's not unreasonable,
# [19:00] <fantasai> fantasai: Does anyone care besides Bert and Simon?
# [19:01] <fantasai> florian: I agree with Simon
# [19:01] * heycam krit it does not; oh well
# [19:01] <fantasai> dbaron: I remember the intent being optional rather than required
# [19:01] <fantasai> dbaron: The other option is that the spec could say that user agents designed for smaller devices may use a smaller size
# [19:01] <fantasai> Bert: I think that would solve it
# [19:01] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [19:01] <fantasai> RESOLVED: Change to MAY on this issue
# [19:01] <fantasai> smfr: Another replaced element sizing thing
# [19:02] <fantasai> smfr: One very common issue we see is that author sinclude images with very large heights and widths, with different aspect ratios
# [19:02] <fantasai> smfr: We don't have a way to resize these images in CSS
# [19:02] <fantasai> fantasai: Use max-width/max-height
# [19:03] <fantasai> smfr: It doesn't work for different aspect ratio images
# [19:03] * Joins: emalasky (~Adium@public.cloak)
# [19:03] <fantasai> fantasai: Why does "max-width: 100vw; max-height: 100vh" not work?
# [19:04] <fantasai> glazou: I don't understand the issue
# [19:07] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [19:09] * Quits: jet (~junglecode@public.cloak) (jet)
# [19:09] <fantasai> smfr: Sometimes have margins, captions, also want them to fit
# [19:09] <fantasai> dau: [agrees, gives examples]
# [19:09] <fantasai> fantasai: Use flexbox, put max-size on the flexbox, and caption + image inside.
# [19:09] <fantasai> Topic: Regions
# [19:11] <plinss> astearns: fantasai proposed last night to shift region styling out of Regions into a separate module
# [19:11] <plinss> astearns: This seems a good idea to me
# [19:11] <dbaron> (fantasai copies minutes from her laptop to plinss's)
# [19:11] <plinss> astearns: Region styling mechanism works for page-based styling, which print industry is much more excited about
# [19:11] <plinss> astearns: and would probably help drive forward
# [19:12] <plinss> astearns: What remains in Regions after shifting this out, is enough to work on at the moment
# [19:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:12] <plinss> astearns: Once page styling is defined, region styling would use the same syntax
# [19:12] <plinss> with like s/page/region/
# [19:13] <plinss> dauwhe: where would this go?
# [19:13] <plinss> astearns: Paged Media?
# [19:13] <plinss> fantasai: Not really. That module is focused on box model of pages
# [19:13] <plinss> ?: GCPM?
# [19:13] <plinss> dauwhe: Maybe for level 4?
# [19:14] <plinss> Bert: No objection to that. It sounds that cascading and inheritance would be a better home for it.
# [19:14] <plinss> Bert: That's the most difficult part of it. Other part is just syntax
# [19:15] <plinss> fantasai: Cascading 3 is in CR, so we could start an L4 draft
# [19:15] <plinss> SimonSapin: Same mechanism used for overflow: fragment, too
# [19:15] <plinss> fantasai: yes, all of these things will use the same mechanism, just with different idents
# [19:16] <plinss> fantasai: who would take this on? Alan, would you take this on as well?
# [19:16] <plinss> astearns: would certainly help, but can't focus on it
# [19:16] <plinss> dauwhe: I'd want help with the cascade part
# [19:17] <plinss> Bert: Where did :first-line and :first-letter go?
# [19:17] <plinss> fantasai: We need a new pseudo-elements draft
# [19:17] <SimonSapin> http://wiki.csswg.org/spec/css-pseudo-4
# [19:17] <plinss> glazou: It was originally in Selectors, but there are more layout stuff so...
# [19:18] <plinss> plinss: Did we have an ED of the pseudos?
# [19:18] <plinss> fantasai: Yes, but the new stuff that was proposed wasn't received very well
# [19:18] <plinss> fantasai: Probably next draft should just focus on defining existing things better, e.g. :first-letter and ::selection
# [19:19] <plinss> astearns: Sounds like this would go into Cascading L4
# [19:19] <plinss> astearns: Is there any other content that needs to go into Cascading L4?
# [19:19] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:19] <plinss> astearns: Seems that we need someone to own Cascading L4
# [19:19] <plinss> TabAtkins: that would be me and fantasai
# [19:20] <plinss> astearns: Or resolve to put it into its own module, to be shifted around at a later date
# [19:20] <plinss> TabAtkins: Cascading is fine
# [19:20] <plinss> ACTION TabAtkins: Create Cascading L4 draft via copy-pasted of css3-cascade and region styling chapter
# [19:20] * trackbot is creating a new ACTION.
# [19:20] * RRSAgent records action 4
# [19:20] <trackbot> Created ACTION-614 - Create cascading l4 draft via copy-pasted of css3-cascade and region styling chapter [on Tab Atkins Jr. - due 2014-02-05].
# [19:21] <plinss> RESOLVED: Shift Region Styling out of Regions, merge with page-based and overflow-fragment-based styling, put into css4-cascade for now
# [19:22] <plinss> Topic: Scroll Snap Points
# [19:22] <plinss> Rossen: This a spec that we talked about a few months ago
# [19:23] <plinss> Rossen: I helped Matt from our team to add to the CSS WG
# [19:23] <dbaron> http://dev.w3.org/csswg/css-snappoints/
# [19:23] <plinss> Rossen: Matt will give us an overview of the spec. There were a bunch of comments and requests that were fired away as soon as spec was intordued
# [19:23] <plinss> Rossen: I believe we addressed most of them. Hoping to get FPWD after review today
# [19:24] <plinss> Matt: Our first methodologies were snap list and snap intervals
# [19:24] <plinss> Matt: Snap list is a list of lengths at which snaps would be at
# [19:24] <plinss> Matt: Scrolling element would snap to those offsets
# [19:24] <plinss> Matt: Snap-interval was similar, but instead of lengths was offset for first one and then interval to be repeated
# [19:24] <plinss> Matt: The feedback we got was most of the scenarios people have is to snap to specific elements
# [19:24] <plinss> Matt: e.g. next photo or whatever
# [19:25] <plinss> Matt: So pushed update last night for element-based snap points proposal
# [19:25] <plinss> Matt: A number of scenarios we wanted to cover with this
# [19:25] <plinss> Matt: pagination, photo slide shows, want photo centered, or offset by some amount
# [19:25] <plinss> Matt: In Windows we often have 100px of previous section to peek in, so you know there's a prev section
# [19:26] <plinss> Matt: So defining a snap axis, which is position within scroller area, and then snap coordinate, which aligns to that snap axis
# [19:26] <plinss> Matt: Here photo album, example 2 in spec, photo slide show example
# [19:26] <plinss> Matt: snap coord is 50% through each photo in slideshow
# [19:26] <plinss> Matt: snap axis (red line) is 50% through scroller.
# [19:26] <plinss> Matt: As you page through, try to align snap coord to snap axis
# [19:27] <plinss> Matt: Only other addition here is elements value for scroll-snap-points-x and scroll-snap-points-y
# [19:27] <plinss> Matt: so you don't have elements and points simultaneously
# [19:27] <plinss> fantasai: is there a reason to disallow that?
# [19:27] <plinss> Matt: doesn't make a lot of sense to merge these
# [19:28] <plinss> Matt: Do you merge them, one wins
# [19:28] <plinss> fantasai: I think you just merge the two lists
# [19:28] <plinss> fantasai: I'm less convinced of the need for the other one, if you have element-based one, why need other one?
# [19:28] <plinss> Matt: interval one, might want one page content at a time
# [19:29] <plinss> dbaron: If you have pages, usually you have elements for that
# [19:29] <plinss> [discussion of use cases, such as images, graphic novel panels]
# [19:30] <plinss> fantasai: There's an <area> element in HTML. If you mapped that to graphic novel panels, would you be able to snap to those areas?
# [19:30] <plinss> smfr: Suppose an element and its child both have scrol-snap-points
# [19:30] <plinss> Matt: Associate them all to nearest ancestor scroller
# [19:30] <plinss> matt: You take all of the snap points into account.
# [19:30] <plinss> Matt: use case: section for news, section for sports, each have snap points. Articles within them have snap points, etc.
# [19:31] <plinss> heycam: For element-based one, can you use SVG elements?
# [19:31] <plinss> heycam: How would that work?
# [19:31] <plinss> Matt: set your snap coordinate
# [19:32] <heycam> [so you could do a 0px offset from a bounding box edge, it sounded like]
# [19:32] <plinss> fantasai: Can you have a snap area? Like say you have a very large image, you snap to that image, then can pan around freely, but it resists pulling the image off the screen. Then can swap to next image
# [19:32] <plinss> Matt: Currently only points
# [19:33] <plinss> Matt: This is only allowing a single snap point per element
# [19:33] <plinss> fantasai: This is different from multiple snap points
# [19:33] <plinss> fantasai: there's no tension, unless I try to pull the photo away from the edge
# [19:34] <plinss> smfr: Haven't ever seen that
# [19:34] <plinss> plinss: photo viewer on iPhone does that
# [19:34] <plinss> Bert: Maybe you have snap tolerance or snap area
# [19:34] <plinss> Bert: ...
# [19:34] <plinss> Matt: Haven't really thought about using these as a boundary effect
# [19:34] <plinss> Matt: Not sure if that's the same problem we're trying to solve, or something different
# [19:35] <plinss> fantasai: I think it's the same problem, just slightly different case
# [19:35] <plinss> Matt: not sure about that
# [19:35] <plinss> dbaron: It sounds like you're describing mandatory vs proximity
# [19:35] <smfr> http://dev.w3.org/csswg/css-snappoints/#scroll-snap-type0
# [19:36] <plinss> dbaron: property has droll-snap-type: none| mandatory | proximity
# [19:36] <plinss> dbaron: Mandatory means you have to rest at that point
# [19:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:36] <plinss> dbaron: proximity is that if you are near a snap point, then you snap there. If not close then don't snap to it
# [19:36] <plinss> plinss: That doesn't match what fantasai was describing
# [19:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:37] <plinss> dbaron: One comment I have is that you have different snap types in x and y dimensions
# [19:37] <plinss> dbaron: that's a comment from roc
# [19:37] <plinss> florian: x and y or block and inline?
# [19:37] <dbaron> part of roc's document at https://wiki.mozilla.org/Gecko:CSSScrollSnapping
# [19:37] <plinss> plinss: Well, it should match scrolling ones
# [19:37] <plinss> s/ones/properties/
# [19:37] <shepazu> q+ to ask about hashes
# [19:37] <plinss> smfr: This one has different points
# [19:38] <plinss> for x and y in different properties
# [19:38] <plinss> smfr: but for points we tend to use a single <position> property
# [19:38] <plinss> dbaron: ....
# [19:38] <plinss> dbaron: My impression was that roc was in favor of simpler proposal for defining where snap points are
# [19:39] <plinss> dbaron: which was to say that you can have either margin or border edges as snap points
# [19:39] <plinss> Matt: Wanted to also solve problems of centered photos in photo album, e.g.
# [19:39] <plinss> dbaron: Not quite following solution you have here
# [19:39] <plinss> Matt: Idea is that scroller element defines within its space an axis
# [19:39] <plinss> Matt: Each element defines which points it wants to match to that axis
# [19:40] <plinss> Matt: [talks through image]
# [19:40] <plinss> Matt: after you complete a scroll, align point to axis
# [19:41] <plinss> ...
# [19:41] * TabAtkins is going to Bikeshed this spec.
# [19:41] * TabAtkins (whether you like it or not)
# [19:41] <plinss> fantasai: I think roc and I are talking about having an area, where you resist leaving that area
# [19:41] * Ms2ger wait until LC
# [19:41] <plinss> fantasai: and Matt is talking about having an alignment point, you try to match to that alignment
# [19:41] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [19:42] <TabAtkins> ScribeNick: TabAtkins
# [19:42] * Ms2ger fantasai, time to go? :)
# [19:43] <TabAtkins> fantasai: [draws a diagram]
# [19:43] <TabAtkins> fantasai: [several images in the content, larger than the container]
# [19:43] <TabAtkins> fantasai: There are two types of snap points.
# [19:44] <TabAtkins> fantasai: Snap points in the middle of each image.
# [19:44] <TabAtkins> fantasai: As I sscroll around, it resists having a scroll offset that's not having the snap points centered.
# [19:44] <TabAtkins> fantasai: [describes two method, using energy potential metaphors]
# [19:45] <TabAtkins> \______/\______/\______/
# [19:45] <TabAtkins> /------\/---------\/---------\
# [19:45] <TabAtkins> First is proximity. Second is mandatory.
# [19:46] <TabAtkins> dbaron: Is that why there's an extra property tht's confusing?
# [19:46] <TabAtkins> MaRakow: [...]
# [19:46] <TabAtkins> smfr: Snap points are what you put on the thing with overflow:scroll.
# [19:46] <TabAtkins> smfr: Snap coords are on the elements inside. They provide snap points thusly.
# [19:49] * heycam the yellow line is for loading and unloading of passengers only. there is no parking on the yellow line.
# [19:50] * Joins: adenilson (~anonymous@public.cloak)
# [19:50] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:52] * Joins: adenilson (~anonymous@public.cloak)
# [19:53] <smfr> Scribenick: smfr
# [19:53] <smfr> [explanations of the spec]
# [19:53] <smfr> dbaron: trying to think of real-world examples of snapping to 90% intervals and no other points within that
# [19:53] <smfr> florian: makes more sense with proximity
# [19:54] <smfr> MaRakow: example: on redfin.com, photo viewer with set of 5 images, which are paginated
# [19:54] <smfr> MaRakow: clicking arrow goes to next image
# [19:54] <smfr> more like going to the next page, or filmstrip of images
# [19:54] <smfr> dbaron: snap points are associated with edge of images
# [19:54] <smfr> MaRakow: edge of every 5th image
# [19:55] <TabAtkins> Simplified grammar, suggested by me on the list some time ago:
# [19:55] <smfr> MaRakow: could wrap images in elements, but simpler to say you're snapping to 100%
# [19:55] <smfr> SteveZ: what if I have zoomed?
# [19:55] <smfr> MaRakow: for element based snap points, it works
# [19:55] <smfr> MaRakow: lengths are in css units, so it should be consistent
# [19:55] * Joins: leif (~lastorset@public.cloak)
# [19:55] <TabAtkins> scroll-snap-points: <lenper>+ | <lenper>* repeat(<lenper>+) | elements | elements(<lenper>)
# [19:55] <smfr> MaRakow: IE does everything in CSS units, not physical
# [19:55] <TabAtkins> scroll-snap-axis: <lenper>
# [19:56] <smfr> florian: this works in 2d, but it's defined to work in either horizontal or vertical
# [19:56] <smfr> florian: wouldn't work for a large area, and snapping to points within that
# [19:56] <TabAtkins> Lets us avoid having scroll-snap-coordinate property. Also uses simpler means than specialized functions.
# [19:57] <smfr> e.g. if 2 x and y coords, you may only want to snap to 2 of those points (not the 4 intersections)
# [19:57] <TabAtkins> Also, we never do capitalization in function names.
# [19:57] <smfr> Rossen_: you're asking for snapping for diagonal scrollling
# [19:57] <smfr> SteveZ: e.g. snapping to cities on a map
# [19:58] <smfr> MaRakow: yes, for now florian's example would give you 4 snap points
# [19:58] <smfr> plinss: no camel case (snapInternval etc)
# [19:58] <smfr> plinss: don't use commas in function notation
# [19:58] <smfr> plinss: elements it not a good term. could be other boxes
# [19:58] <smfr> s/it/is
# [19:59] <smfr> shepazu: slides and galleries is a common use case. you want to change the url hash as you do that
# [19:59] <smfr> shepazu: not CSS, but how would you integrate snap points with url hash changes
# [19:59] <smfr> MaRakow: have not thought about this
# [20:00] <smfr> smfr: some naming issues
# [20:00] <smfr> like "axis"
# [20:00] <TabAtkins> Actually, we dont' need "elements" at all.
# [20:01] <smfr> smfr: terminology needs clarification
# [20:01] <TabAtkins> Add a "none" value to the "I contribute a snap point" property, which is the initial value.
# [20:01] <smfr> florian: would be nice to have an object model, so you can get snap points from JS
# [20:01] <smfr> shepazu: would fit with the hash changes
# [20:01] <smfr> plinss: need to spec how this interacts with JS-driven scrolling
# [20:02] * TabAtkins scroll-snap-points: <lenper>+ | <lenper>* repeat(<lenper>+)
# [20:02] <TabAtkins> scroll-snap-axis: <lenper>
# [20:02] <smfr> florian: is common to have scrolling feedback (dots under the scroller), so need some OM way to hook up to these
# [20:02] <TabAtkins> scroll-snap-coordinates: none | <lenper>
# [20:02] <TabAtkins> Or better, none | <position>
# [20:02] <smfr> [discussion]
# [20:02] * Rossen_f2f did I hear someone say Java the Sript?
# [20:02] <smfr> MaRakow: have had requested for snap to next, snap to previous
# [20:03] <smfr> TabAtkins: we can simplify the syntax quite a bit
# [20:03] <smfr> [see above]
# [20:03] <smfr> TabAtkins: no need for flag on the scroller to say that it should look at its children
# [20:04] <smfr> TabAtkins: is there a use case for scroll-snap-coord to have x, y, rather than a position
# [20:04] <smfr> TabAtkins: is there a reason we have separate X and Y properties?
# [20:04] * heycam rolls eyes at <lenper>
# [20:04] <smfr> MaRakow: it's common to use in 1D scrollers hence the separate X and Y
# [20:04] <smfr> TabAtkins: is there a use case for multiple positions per element
# [20:05] <smfr> Rossen_: yes
# [20:05] <smfr> Rossen_: photo with faces
# [20:05] <smfr> TabAtkins: don't use <area>
# [20:05] <smfr> dbaron: strongly agree with what I think I heard TabAtkins saying
# [20:05] <smfr> dbaron: scroll-snap-coordinate should have initial value of "none"
# [20:06] <smfr> TabAtkins: allows you to skip some elements, rather than all or none
# [20:06] <smfr> dbaron: scroll-snap-coord should not just apply to block-level elements
# [20:06] <smfr> dbaron: i would want this to work on inline-blocks, flex boxes, etc
# [20:07] <smfr> dbaron: and inline images
# [20:07] <smfr> dbaron: would say "applies to: all elements"
# [20:07] <smfr> TabAtkins: it's defined relative to the content box, so we'd need to figure out what that means for inlines
# [20:07] <smfr> dbaron: i don't like tying this to box-sizing
# [20:08] <smfr> dbaron: box-sizing was a design mistake; it should have been a modifier to particular values
# [20:08] <smfr> dbaron: the global flag that changes all the things is bad
# [20:08] <smfr> dbaron: if you want different boxes it should be part of the value, rather than using box-sizing
# [20:08] <smfr> tantek: from a web dev or implementor perspective?
# [20:09] <smfr> dbaron: from a web developer perspective
# [20:09] <TabAtkins> scroll-snap-coordinate: none | [ <position> <box>? ]#
# [20:09] <smfr> astearns: there's value in both
# [20:09] <smfr> tantek: it makes sense for some developers
# [20:09] <smfr> florian: how does this work with fragmentation
# [20:09] <tantek> I've gotten feedback from numerous developers who think box-sizing:border-box is the way the CSS box model should have been from day 1.
# [20:10] <smfr> florian: if the elements that define the snap point have been fragmented by a fragmentainer inside the scroller, what happens?
# [20:10] <tantek> new developers too - that have no memory of the old IE box model
# [20:10] <smfr> TabAtkins: would be defined by the definition of the reference box
# [20:10] <smfr> <br type="coffee">
# [20:12] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [20:12] * Joins: koji (~koji@public.cloak)
# [20:13] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:18] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [20:19] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [20:20] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [20:25] * Joins: leif (~lastorset@public.cloak)
# [20:34] * Joins: koji (~koji@public.cloak)
# [20:38] <smfr> [logistical discussion]
# [20:41] <fantasai> tantek: i agree with them, too. its just too late to fix now
# [20:42] <smfr> TabAtkins talks about bikeshed.py
# [20:42] <tantek> fantasai - obviously we're not going to fix it now, but "box-sizing" is a pretty decent workaround
# [20:42] <tantek> whereas per-property-value hacks would be a huge pain in the a**
# [20:43] <tantek> smfr, re: bikeshed, I started this wiki page too: http://wiki.csswg.org/tools/bikeshed
# [20:43] <smfr> TabAtkins: please file bikeshed.py issues on the github tracker
# [20:44] <smfr> plinss: bikeshed gets spec data from Shepherd
# [20:44] <tantek> please feel free to add requests for documentation to the wiki page too
# [20:44] <smfr> plinss: you can tell bikeshed to update your local data
# [20:45] <smfr> Topic: Snap points (continued)
# [20:45] <smfr> Rossen_: would like to publish first public working draft. Have 8 points to address before we publish
# [20:46] <smfr> ChrisL: how many of those points require discussion
# [20:46] <smfr> Rossen_: will add issues for things like 2D panning. Some editorial things (camel case)
# [20:46] <smfr> Rossen_: naming issues, -x and -y rather than single property, multiple points per element
# [20:47] <smfr> ChrisL: do people want to review?
# [20:47] <smfr> TabAtkins: yes, i want to review. Can you request in 2 weeks at next conf call?
# [20:47] <smfr> Rossen_: OK
# [20:47] <smfr> Bert: what if next snap point is too far away (further than scroll width)
# [20:47] <smfr> MaRakow: depends on proximity
# [20:48] <smfr> Bert: is there no smart behavior?
# [20:48] <smfr> Rossen_: yes, the mandatory one. proximity is a better choice in that situation
# [20:48] <smfr> florian: would it make sense to be able to switch to mandatory and proximity per snap point
# [20:49] <smfr> MaRakow: mandatory means that it's mandatory that you end up at a snap point. Have to think it through
# [20:49] <smfr> Rossen_: we'll do the edits, and request FPWD in 2 weeks
# [20:50] <smfr> Topic: will-change proposal
# [20:50] <smfr> http://tabatkins.github.io/specs/css-will-change/
# [20:51] * Ms2ger css will never change!
# [20:51] <smfr> TabAtkins: Benoit suggested a property that authors could use to say ahead of time what operations will be done later
# [20:51] <smfr> TabAtkins: e.g. properties can cause element to be promoted to a new layer, can cause lag
# [20:51] * sgalineau "Change considered harmful"
# [20:51] * Ms2ger throws a fish at sgalineau
# [20:52] <smfr> TabAtkins goes through http://tabatkins.github.io/specs/css-will-change/#will-change
# [20:52] <smfr> TabAtkins: this is a hint to the UA and has no visible impact on the element itself
# [20:53] <smfr> TabAtkins: other than possibly creating a stacking context (e.g. will-change: opacity will create a SC)
# [20:53] <smfr> krit: that's why I would not call it a hint!
# [20:53] <smfr> florian: if things going to change are in markup, the UA could figure it out
# [20:53] <smfr> florian: if they will change via script, why isn't this an API?
# [20:53] <smfr> TabAtkins: can't always tell that something is going to happen (e.g. if they happen via :hover)
# [20:54] <smfr> TabAtkins: often it's that user is going to flip a class in JS
# [20:54] <smfr> florian: so you're doing from JS, why not do it programmatically
# [20:54] <smfr> heycam: if you have animations on transforms that haven't started yet, you don't want to create stacking context before the animation starts
# [20:54] <smfr> dbaron: the spec says you don't create a stacking context before the animation starts
# [20:55] <smfr> dbaron: the problem now is that people are using hacks, like setting transform: translateZ(0)
# [20:55] <smfr> krit: and they do the hacks because they know that it's creating a layer
# [20:55] <smfr> dbaron: but they do the hacks because they work in some engines
# [20:55] <smfr> dbaron: engines do different things e.g. between transform and opacity
# [20:56] <smfr> TabAtkins: the compositing layer is undetectable. you can tell the SC
# [20:57] <smfr> krit: use of this would cause SC in many cases, e.g. will-change: top
# [20:57] <smfr> TabAtkins: no, only properties that create SC cause one in will-change
# [20:58] <smfr> dbaron: we don't want to guarantee authors a compositing layer, because we may not have enough RAM
# [20:58] <smfr> dbaron: but we can guarantee a stacking context (SC)
# [20:58] <smfr> dbaron: it lets the author give us a hint that they care about the performance
# [20:58] <smfr> dbaron: so UAs can improve performance in some cases
# [20:59] <smfr> florian: why is it a bad idea to have a property that creates a stacking context (auto | force)
# [20:59] <smfr> TabAtkins: this creates a SC because you want consistent behavior over time
# [20:59] <smfr> TabAtkins: you're suggesting element.willChange()
# [20:59] <smfr> florian: and a separate property for creating stacking context
# [21:00] <smfr> TabAtkins: it's convenient for applying this declaratively
# [21:00] <smfr> florian: but you're JS to change the content anyway
# [21:01] <smfr> TabAtkins: not necessarily; can't use the fact that some property might be animated in the lifetime of the document
# [21:01] <smfr> TabAtkins: this is more closely scoped in time
# [21:01] <smfr> florian: on hover, the author has no more info than the UA does
# [21:01] <smfr> florian: let's introduce a property to tell the UA something it can't figure out on its own
# [21:02] <smfr> sylvaing: do you change anything when you see that you have a transition or animation
# [21:02] <smfr> sylvaing: so will-change:opacity will cause SC, transition: opacity will not
# [21:02] <smfr> TabAtkins: this could be done as a JS api, but more convenient as a property. i don't really care which way this ends up
# [21:03] <smfr> florian: we have rejected in the past things in the past that are convenience/hint properties
# [21:03] * fantasai finishes reading through the snap-points minutes
# [21:03] <smfr> TabAtkins: two questions: 1) can the UA autodetect this, and 2) should it be in DOM or CSS
# [21:04] <smfr> TabAtkins: 2 UAs think this is a reasonable perf optimization
# [21:04] <fantasai> I don't understand, from the minutes, what were the key changes requested. Could somebody at the next break (or while ignoring current discussion ;) please summarize them clearly?
# [21:04] * fantasai can't process minutes when they don't make sense
# [21:04] <glazou> fantasai, you're at SEATAC ?
# [21:04] <fantasai> yep
# [21:04] <smfr> florian: introducing JS is the point where the UA can't figure it out any more
# [21:05] * fantasai should have dialed in while en route, maybe
# [21:05] <smfr> florian: why have a property when the UA can figure it out on its own
# [21:05] * glazou fantasai lol
# [21:05] * fantasai too late now
# [21:05] <smfr> krit: implementations will change over time, and the perf characteristics change
# [21:05] * Parts: cabanier_ (~sid15093@public.cloak)
# [21:05] * Joins: cabanier_ (~sid15093@public.cloak)
# [21:05] * Quits: cabanier_ (~sid15093@public.cloak) ("")
# [21:05] <smfr> krit: this property can't address that
# [21:05] * Joins: cabanier_ (~sid15093@public.cloak)
# [21:06] * Ms2ger fantasai: dial in from the plane?
# [21:06] <smfr> krit: this property may not be necessary in future
# [21:06] * fantasai ms2ger they don't have connectivity
# [21:06] <smfr> TabAtkins: compositing isn't the only reason to have a slow start to an animation
# [21:06] <smfr> TabAtkins: we will continue to have animations that are slow to start
# [21:06] * fantasai but anyway, the snap-points discussion is over. Dialing in now wouldn't help me understand the minutes for it :)
# [21:07] <smfr> TabAtkins: this is only a hint
# [21:07] <smfr> plinss: we should divorce the SC from the hint
# [21:07] <smfr> plinss: so we have another property that forces creation of a stacking context
# [21:07] <smfr> dbaron: then using will-change without that other property is useless
# [21:08] <smfr> dbaron: the second property will make this too hard for authors to get right and they won't use it
# [21:08] <smfr> krit: we already have the isolation property that creates a SC
# [21:08] * fantasai really has nothing to contribute to the current discussion, and is assuming smart ppl like dbaron will say anything as needs be said
# [21:08] <smfr> plinss: there are a lot of implicit behaviors in CSS (e.g. containing block) that should be explicit properties
# [21:09] <smfr> TabAtkins: i agree with you
# [21:09] <smfr> TabAtkins: this is going to be cargo-culted anyway
# [21:09] <smfr> TabAtkins: so keeping it as simple as possible is good
# [21:10] <smfr> SteveZ: if you add an optional argument that says "no-stacking context"
# [21:10] <smfr> Rossen_: have you discussed with the Performance WG?
# [21:10] <smfr> dbaron: i think the Performance WG is mostly concerned with network and measurement
# [21:11] <smfr> Rossen_: not necessarily. Suggest you should talk to them.
# [21:11] <smfr> Rossen_: they have dealt with this issue, and may have valuable feedback
# [21:11] <smfr> Rossen_: it's not IE-only. other companies were quite engaged
# [21:12] <smfr> ACTION: TabAtkins to talk to the Performance WG about will-change
# [21:12] * trackbot is creating a new ACTION.
# [21:12] * RRSAgent records action 5
# [21:12] <trackbot> Created ACTION-615 - Talk to the performance wg about will-change [on Tab Atkins Jr. - due 2014-02-05].
# [21:12] <smfr> TabAtkins: want to take feedback before asking for FPWD
# [21:13] <smfr> dbaron: would like this to be a group editor's draft
# [21:13] <smfr> TabAtkins: i do have a "dream" status I can use for this
# [21:13] <smfr> krit: we want to get it reviewed, so it should be a W3C space
# [21:14] <smfr> RESOLVED: publish will-change in the CSS WG repo as a Unofficial Draft
# [21:14] * Rossen_f2f I have a dream that one day everyone WIll Change!
# [21:15] <smfr> <br type="lunch">
# [21:15] * heycam is now known as heycam|away
# [21:16] <Rossen_f2f> Feedback notes to snap points discussion:
# [21:17] <Rossen_f2f> - Don't use camel case for property names.
# [21:17] <Rossen_f2f> Use only one property to specify the point.
# [21:17] <Rossen_f2f> CSSOM - you want to know be able to read back the points and use them?
# [21:18] <Rossen_f2f> No need for the 'elements' value
# [21:18] <Rossen_f2f> Allow multiple point per element being snapped
# [21:18] <Rossen_f2f> It should be allowed to apply to all elements.
# [21:18] <Rossen_f2f> Snapping in 2D by using both scrollers at the same time. Ex. I want to pan around in a map from city to city.
# [21:19] <Rossen_f2f> Shouldn't be bound to box-sizing. See how the reference boxes are used in the shapes spec.
# [21:20] <Rossen_f2f> Should we have mandatory vs proximity per element?
# [21:20] <glazou> Rossen_f2f, you want your own w3c meme ? (re I had a dream...)
# [21:20] <Rossen_f2f> :)
# [21:21] * Rossen_f2f glazou, putting the dream status of the will change spec together gets you a meme now? lol
# [21:21] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [21:22] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [21:23] * Joins: koji (~koji@public.cloak)
# [21:30] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [21:33] <fantasai> Some additional notes:
# [21:33] <fantasai> In Grid Layout we created some naming conventions to distinguish between properties set on the container vs. on the items
# [21:34] <fantasai> might be helpful to group scroll-snap properties similarly
# [21:34] * Joins: jet (~junglecode@public.cloak)
# [21:34] * Quits: jet (~junglecode@public.cloak) (jet)
# [21:35] <fantasai> Also, might want to think about snapping area to area rather than just point to point
# [21:35] * Joins: MaRakow (~MaRakow@public.cloak)
# [21:37] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:37] <fantasai> Snap points resist having a point on the scroller move away from a point on the element
# [21:38] <fantasai> but sometimes you might want to say that the viewport resists moving away from the boundaries of an element, but as long as the element covers the screen there is no tension
# [21:39] <fantasai> if you are close to a boundary of the element (that is off screen), it does not snap to that boundary
# [21:39] <fantasai> but if you bring that boundary to the edge of the screen, it resists the viewport edge crossing that boundary (and displaying things beyond the element boundary)
# [21:39] <liam> [resumed? snap points sound similar to what's wanted for the baseline grid too]
# [21:40] * fantasai is dumping notes into IRC while everyone's at lunch
# [21:40] * liam ok
# [21:40] <fantasai> Wrt mandatory vs proximity and allowing both within an element...
# [21:40] <fantasai> it's not the snap point that has this behavior, it's the space between the snap points
# [21:41] <fantasai> If I am between a mandatory snap point and a proximity snap point, what does that mean?
# [21:41] <fantasai> In between mandatory points, it's clear that the viewport must slide to the nearest snap point
# [21:42] <fantasai> In between proximity points, it snaps to the nearest snap point if it is close enough, but doesn't accelerate to any snap point if it's far enough from either snap point
# [21:42] <fantasai> But between a mandatory point and a proximity point, what happens? Is that treated as mandatory?
# [21:43] <fantasai> Or does the behavior change at the halfway point?
# [21:43] <fantasai> Or something else?
# [21:45] <fantasai> I think the photo album example is a great use case for mandatory snap points and the axis snapping model that's in the spec.
# [21:45] <fantasai> What happens if we zoom in and the photos are no longer smaller than the viewport?
# [21:46] <fantasai> That same behavior is no longer sensible
# [21:46] <fantasai> because it resists letting the user see the parts of the photo that aren't visible when the center is snapped in
# [21:46] <fantasai> So what model would be appropriate then?
# [21:47] <fantasai> And since the user can zoom in and out, how can we make the controls we offer provide the right behavior in both cases, without the author having to detect when a photo is larger than the screen?
# [21:48] <fantasai> These are questions I think should be explored.
# [21:48] <liam> [ability for the user to scroll slightly shouldn't go away altogether]
# [21:48] <fantasai> I suspect they can be solved by area-to-area snapping rather than point-to-point snapping.
# [21:49] <fantasai> You would use <position> syntax to align the snap-point within the viewport if the snap-area is smaller than the viewport
# [21:49] <fantasai> s/would/could/
# [21:51] <fantasai> So the photo use case would use an element snap-area (rather than snap-point) consisting of the photo border-box, and a snap-position (rather than axis) of center center.
# [21:52] <fantasai> Which would cause it to try to center the border-box within the viewport when it is smaller than the viewport
# [21:53] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [21:53] <fantasai> and to rest the viewport within the photo when the viewport is smaller than the photo
# [21:53] <fantasai> s/to rest/to merely/
# [21:54] <fantasai> ...
# [21:55] * fantasai wishes there were paragraph breaks in the above wall of text, but can't insert them into the IRC log at this point, just the formatted minutes :/
# [21:55] <liam> if it's something like pinterest, with an image wall, you might want a scroll "detent" at the top of each image , or more likely just above it
# [21:55] <fantasai> ?
# [21:55] <liam> you have multiple parallel images
# [21:55] <liam> not all aligned vertically
# [21:57] * Joins: nikos_ (~chatzilla@public.cloak)
# [21:57] <fantasai> The other thing I havent' quite thought through is the two behaviors you could want at the edge of a box
# [21:58] <fantasai> In one case, you merely resist leaving the box, but don't try to align to it if you're still completley within it
# [21:58] <fantasai> In the other, if you're near an edge, you try to align the viewport edge to the box edge
# [21:58] <fantasai> kindof like how in Win7 the window box snaps to the screen edge if it gets close enough
# [21:58] <fantasai> s/box/edge/
# [21:59] <fantasai> (the first behavior would be resisting the user trying to push the window off the screen, but not being attracted to the edge of it if nearby)
# [21:59] <fantasai> s/if/if it's/
# [21:59] <fantasai> Anyway, I should go board. :)
# [21:59] <fantasai> Have a happy time discussing, CSSWG!
# [22:00] <Ms2ger> Have a good flight
# [22:02] * heycam|away is now known as heycam
# [22:02] <glazou> bye fantasai
# [22:02] * dauwhe thank you, fantasai!
# [22:03] <sgalineau> call-in instructions in Location section of http://wiki.csswg.org/planning/seattle-2014
# [22:03] * Joins: smfr (~smfr@public.cloak)
# [22:03] * Joins: ChrisL (clilley@public.cloak)
# [22:03] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:03] <TabAtkins> ScribeNick: TabAtkins
# [22:04] <TabAtkins> Topic: Blending & Compositing CR
# [22:04] * Joins: stakagi (~stakagi@public.cloak)
# [22:04] * Joins: koji (~koji@public.cloak)
# [22:05] <SimonSapin> (off topic) TabAtkins, I kinda feel display-box should be a longhand of display
# [22:05] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:05] <TabAtkins> Nope, you don't. We had discussions about this, it's a very very bad idea.
# [22:05] <TabAtkins> I can epxlain later.
# [22:05] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [22:06] <smfr> http://dev.w3.org/fxtf/compositing-1/
# [22:06] <ChrisL> spec link?
# [22:06] <TabAtkins> cabanier_: We changed the sections from 4 onward to be normative.
# [22:06] <TabAtkins> cabanier_: There was a 3-week period for comments.
# [22:06] <TabAtkins> cabanier_: There was a comment from Eric about a stale ref, which I removed.
# [22:06] <TabAtkins> cabanier_: I've prepared a DoC.
# [22:06] <TabAtkins> cabanier_: And we've been working on test cases.
# [22:07] <TabAtkins> cabanier_: People have been contributing quite a few tests.
# [22:07] <TabAtkins> cabanier_: Working on impl in 3 browsers.
# [22:07] <TabAtkins> cabanier_: Right now, FF is probably the most stable.
# [22:07] <TabAtkins> heycam: Did you do all three?
# [22:07] <TabAtkins> cabanier_: No, separate engineers.
# [22:08] <TabAtkins> cabanier_: People have begun experimenting quite a bit with it. We've done almost no evangelizing, but people get excited anyway.
# [22:08] <TabAtkins> cabanier_: Some person made a bunch of cool demos:
# [22:08] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:08] <cabanier_> codepen: http://codepen.io/collection/Kgshi/
# [22:09] <TabAtkins> cabanier_: [shows off some of the demos]
# [22:11] <TabAtkins> cabanier_: So right now I think we're ready for CR.
# [22:12] <TabAtkins> TabAtkins: I've been meaning to suggest some editorial rewrites for some time, but that shouldn't block CR.
# [22:12] <TabAtkins> smfr: You've got some theoretical sections - I'd like to see more examples showing which CSS properties I can use to get each of the effects you're talking about.
# [22:12] <TabAtkins> smfr: Like section 10.
# [22:13] <TabAtkins> krit: Canvas also uses this stuff.
# [22:13] <TabAtkins> smfr: Right, but I'd still like to see a simple CSS example.
# [22:13] <TabAtkins> ACTION rik to provide more CSS examples in the Compositing spec.
# [22:13] * trackbot is creating a new ACTION.
# [22:13] <trackbot> Error finding 'rik'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [22:14] <TabAtkins> ACTION cabanier to provide more CSS examples in the Compositing spec.
# [22:14] * trackbot is creating a new ACTION.
# [22:14] <trackbot> Error finding 'cabanier'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [22:14] <TabAtkins> ACTION rcabanier to provide more CSS examples in the Compositing spec.
# [22:14] * trackbot is creating a new ACTION.
# [22:14] <trackbot> Error finding 'rcabanier'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [22:15] <TabAtkins> ACTION krit to action Rik to provide more CSS examples in the Compositing spec.
# [22:15] * trackbot is creating a new ACTION.
# [22:15] <trackbot> Created ACTION-616 - Action rik to provide more css examples in the compositing spec. [on Dirk Schulze - due 2014-02-05].
# [22:15] <TabAtkins> heycam: What were the LC issues?
# [22:15] <TabAtkins> cabanier_: Just one from Erik, about a stale ref.
# [22:16] <TabAtkins> ChrisL: You still have a link to SVG Tiny in your abstract. It should be changed to SVG 1.1.
# [22:16] <TabAtkins> Action krit to change the Abstract link to SVG 1.1 in Compositing.
# [22:16] * trackbot is creating a new ACTION.
# [22:16] <trackbot> Created ACTION-617 - Change the abstract link to svg 1.1 in compositing. [on Dirk Schulze - due 2014-02-05].
# [22:17] <TabAtkins> heycam: The other changes in your DoC, what are they?
# [22:17] <ed> it should also use the referencing syntax in the abstract, like "...sometext... [SVG11]"
# [22:17] <TabAtkins> cabanier_: They were from the previous LC.
# [22:17] <TabAtkins> ChrisL: You'd usually start a new DoC. Helps with patent issues.
# [22:18] <TabAtkins> action krit to action rik to reduce the DoC to only the issues from this LC.
# [22:18] * trackbot is creating a new ACTION.
# [22:18] <trackbot> Created ACTION-618 - Action rik to reduce the doc to only the issues from this lc. [on Dirk Schulze - due 2014-02-05].
# [22:18] <TabAtkins> ChrisL: [something about the wording of the abstract regarding the 2dcontext reference]
# [22:19] <ChrisL> its ambiguous on which spec is the normative definition
# [22:20] <TabAtkins> plinss: How are we on tests?
# [22:20] <cabanier_> tests: https://github.com/w3c/csswg-test/tree/master/contributors/adobe/submitted/css-compositing
# [22:20] <TabAtkins> cabanier_: [brings up the repo with tests]
# [22:20] <TabAtkins> RESOLVED: Compositing to CR, pending the edit nits brought up today.
# [22:20] <TabAtkins> Topic: Masking LC/CR, remaining issues?
# [22:21] <TabAtkins> krit: During the LC period I got a comment and an objection.
# [22:22] <TabAtkins> krit: clip-mask/etc take a <shape-box> argument.
# [22:22] <TabAtkins> krit: Which determines what box the coords are resolved against.
# [22:22] <TabAtkins> krit: Currently we're using the box keywords from B&B, plus margin-box.
# [22:22] <TabAtkins> krit: SVG objected.
# [22:22] <TabAtkins> krit: They make sense for CSS/HTML, but how do they apply to SVG?
# [22:23] <TabAtkins> krit: In SVG we have "bounding box", which is a tight bound around the shape.
# [22:23] <TabAtkins> krit: This doesn't include strokes/etc, just geometry.
# [22:23] <TabAtkins> krit: So we also have "stroke bounding box" which includes stroke/markers.
# [22:24] <TabAtkins> krit: Earlier in the week, we also discussed "viewport" in SVG. People asked about using the SVG viewport as the reference shape.
# [22:24] <TabAtkins> krit: Scaling coordinates by the viewport is actually rather common in SVG.
# [22:24] <TabAtkins> krit: So SVG thought it would be confusing to have "content-box" mean "bounding box".
# [22:24] <TabAtkins> krit: Similarly for stroke-bounding-box, and viewport of the SVG.
# [22:25] <TabAtkins> krit: I personally don't want to add three more keywords.
# [22:25] * Joins: glazou_ (~glazou@public.cloak)
# [22:25] <TabAtkins> krit: I think content-box and bounding box are close enough to be useful to just use content-box.
# [22:25] <TabAtkins> krit: Similarly, I think border-box and stroke bounding box are probably close enough.
# [22:25] <TabAtkins> smfr: What about the bounds of filtered pixels?
# [22:27] <TabAtkins> krit: People suggested painted bounding box, but that's very expensive.
# [22:27] <TabAtkins> TabAtkins: Also infinite in some cases, such as blurs.
# [22:27] <TabAtkins> smfr: Does CSS define the bounds of box-shadow?
# [22:27] <TabAtkins> dbaron: No. Also, probably impossible.
# [22:28] <TabAtkins> heycam: I think I'd like to have all of the CSS-related names map to a single SVG-related one, like maybe "bounding-box", and also have SVG-specific keywords.
# [22:28] <TabAtkins> heycam: I'd like to match the names up with getBBox extensions.
# [22:28] <TabAtkins> heycam: Right now we have getBBox() and getStrokeBBox(), but we should probably have it take a dictionary of things to include.
# [22:28] * Quits: glazou (~glazou@public.cloak) (Client closed connection)
# [22:28] * glazou_ is now known as glazou
# [22:29] <TabAtkins> krit: Does that imply we need another keyword for markers?
# [22:30] <TabAtkins> krit: Does the CSSWG support doing extra SVG-only keywords?
# [22:30] <TabAtkins> TabAtkins: I'm fine with it.
# [22:30] <TabAtkins> florian: Me too.
# [22:33] <TabAtkins> heycam: Does the CSSWG think it's a good idea to do the mapping between CSS and SVG?
# [22:33] <TabAtkins> TabAtkins: I think content=>geometry and border=>stroke kinda make sense, but there's no padding analog in SVG, nor marker analog in CSS, so it's a bad idea overall.
# [22:34] <TabAtkins> TabAtkins: I suggest for the svg boxes: svg([marker || stroke]?), similar to the bbox methods.
# [22:34] <TabAtkins> krit: I think it's [marker | stroke] - one implies the other.
# [22:34] <TabAtkins> heycam: Maybe not.
# [22:34] <TabAtkins> krit: Viewport.
# [22:35] <TabAtkins> TabAtkins: Don't want it at top-level, because it's a different meaning than CSS's viewport.
# [22:35] <TabAtkins> krit: So svg([[marker || stroke] | viewport])
# [22:36] <TabAtkins> heycam: I think it's weird to name it svg().
# [22:36] * heycam is now known as heycam|away
# [22:36] * heycam|away is now known as heycam
# [22:37] <TabAtkins> krit: Fallback to the initial value (border-box) if you specify svg() on an non-SVG element. Fallback to svg() (object bounding box) for reverse.
# [22:37] <TabAtkins> krit: So we also need this in mask-origin, mask-clip.
# [22:38] <TabAtkins> krit: Example: clip-path: circle() svg(marker);
# [22:39] <TabAtkins> krit: Circle starting in the center of the marker box, radisu equal to closest side.
# [22:40] <TabAtkins> heycam: Does the default-fixing (for putting svg() on an HTML element) happen at computed-value time?
# [22:40] <TabAtkins> TabAtkins: I think so, yeah.
# [22:41] <TabAtkins> smfr: Yeah, possible.
# [22:41] <TabAtkins> dbaron: Yeah. Maybe annoying.
# [22:41] <TabAtkins> krit: We may have the same problem in SVG later.
# [22:41] <TabAtkins> krit: If we take in CSS Shapes, for example.
# [22:43] <TabAtkins> ed: Would it be worth having the "fill" keyword there as well?
# [22:43] <TabAtkins> TabAtkins: Hm, I think so.
# [22:44] <ed> having svg(fill || stroke || markers) would also match up with the paint-order property syntax
# [22:44] <TabAtkins> heycam: SVG text, the default getbbox() for text actually unions the glyph cells (rectangles). Same here?
# [22:44] <TabAtkins> krit: Yeah.
# [22:45] <ed> spec link for paint-order, for reference: https://svgwg.org/svg2-draft/painting.html#PaintOrder
# [22:46] * Quits: Rossen_f2f (~Rossen_f2f@public.cloak) ("Page closed")
# [22:46] <TabAtkins> Bert: I think it's weird to see a function without parameters inside, like "svg()".
# [22:46] * Joins: Rossen_f2f (~Rossen_f2f@public.cloak)
# [22:46] <TabAtkins> TabAtkins: You can say "svg(fill)" if you want.
# [22:47] <TabAtkins> heycam: Or just leave it alone - you'll get that behavior by default.
# [22:48] <smfr> smfr: should we use up a function called svg() for something that retuns a box? Why not svg-box()?
# [22:48] <TabAtkins> smfr: I think it's a weird namespacing hack to use svg() here.
# [22:48] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:49] <TabAtkins> krit: My pref is to just use the keywords directly, and only allow one. Define them to be hierarchical - fill is inside stroke is inside marker is inside viewport.
# [22:49] <TabAtkins> TabAtkins: Still don't like "viewport" as raw keyword.
# [22:49] <TabAtkins> krit: viewbox?
# [22:50] <TabAtkins> heycam: I think it's maybe useful which ones to include. Maybe we can defer.
# [22:50] <ChrisL> we have (geometric) bbox and decorated-bbox which includes stroke width, markers etc
# [22:51] <TabAtkins> heycam: I'd probably be okay with just keywords for now, and do union stuff later.
# [22:52] <TabAtkins> heycam: Maybe use the words boudning-box, stroke-boudning-box, decorated-bounding-box, and...?
# [22:52] <TabAtkins> krit: viewbox?
# [22:54] <TabAtkins> heycam: Too wordy. fill/stroke
# [22:55] <TabAtkins> heycam: Leave off marker for now, since I want it to actually mean the markers, not marker+stroke+fill.
# [22:55] <TabAtkins> TabAtkins: But you're okay with stroke meaning fill+stroke?
# [22:55] <TabAtkins> heycam: It does automatically - stroke bounding box is a superset of fill bounding box.
# [22:55] <TabAtkins> krit: Anyway, resolve on these and figure out details in the SVGWG meeting?
# [22:56] <TabAtkins> RESOLVED: Use the keywords fill/stroke/viewbox for clip-path/mask-origin/mask-clip.
# [22:57] <TabAtkins> ed: The viewbox keyword, is that the viewport or the viewbox?
# [22:57] <TabAtkins> krit: They're the same geometric area.
# [22:57] <TabAtkins> TabAtkins: Only difference is the coord system established in each. And the shape functions so far don't use user-space units, so you can't detect that.
# [22:57] <TabAtkins> heycam: And if we did allow, viewbox is what you'd want.
# [22:57] <TabAtkins> krit: Last issue we discussed on Monday.
# [22:58] <TabAtkins> krit: about usou and obb.
# [22:58] <TabAtkins> TabAtkins: Just do what roc said.
# [22:58] <TabAtkins> krit: [explains the issue again for SVGWG people]
# [22:59] * Quits: nikos_ (~chatzilla@public.cloak) ("ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]")
# [23:00] <TabAtkins> RESOLVED: Use roc's definition of obb/usou in HTML content - same geometry, coord space is 1 user-space unit wide/tall in obb, user-space unit = CSS px in usou.
# [23:00] <TabAtkins> krit: I'd like to publish a new WD.
# [23:01] * Joins: jcraig (~jcraig@public.cloak)
# [23:01] <TabAtkins> RESOLVED: New WD for Masking.
# [23:01] <birtles> ScribeNick: birtles
# [23:02] <birtles> topic: ability to specify gradient midpoints
# [23:02] <birtles> Scribe: birtles
# [23:03] <birtles> cabanier_: I wanted to show why there is a need for an explicit midpoint for gradients
# [23:03] <birtles> TabAtkins: this is already in CSS Images 4
# [23:03] <birtles> ... if you just omit the color
# [23:03] <birtles> cabanier_: but some people were confused by that... it doesn't really work
# [23:03] <birtles> ... I created this little application
# [23:03] <cabanier_> sample application: http://codepen.io/adobe/full/fhnBJ
# [23:03] <birtles> ... by clicking on the gradient line you can add color stuff
# [23:04] <birtles> ... and by dragging it to the left, you can see this effect as you approach the edge
# [23:04] <birtles> ... a line starts to appear
# [23:04] <birtles> ... your eyes play tricks on you
# [23:04] <birtles> ... if you copy this and enlarge in photoshop you'll see this line is actually not there
# [23:04] <birtles> ... it's just your eyes
# [23:04] <birtles> ... but to get rid of that you can add a midpoint
# [23:05] <birtles> ... and drag it along
# [23:05] <cabanier_> example of the formula: http://codepen.io/adobe/pen/ced9e76d276a1d6613b529e8524e4cad
# [23:05] <birtles> ... you fill it in with this formula
# [23:05] <birtles> ... by doing it this way you avoid the line
# [23:06] <birtles> ... you create a curve that avoids the appearance of sharp changes
# [23:06] * Joins: zcorpan (~zcorpan@public.cloak)
# [23:06] <birtles> TabAtkins: is there a theoretical justification for this formula?
# [23:06] <birtles> ChrisL: yes, it's based on a power distribution
# [23:06] <birtles> ... it gives you curves but it doesn't give you continuity at where the curves join
# [23:07] <birtles> ... it's an improvement but it doesn't accomplish everything
# [23:07] <birtles> ... people think you can fix this by adding more color stops but apart from enlarging your code
# [23:07] <birtles> smfr: if we're using CoreGraphics which doesn't have this can we support this by adding color stops in the UA?
# [23:07] <birtles> cabanier_: yes
# [23:08] <birtles> florian: getting back to Chris' point, you will still have parts that aren't smooth
# [23:09] <birtles> ... should we try to solve that in one go?
# [23:09] <birtles> cabanier_: not really, maybe in the future
# [23:11] <birtles> TabAtkins: what would happen if you added multiple stops?
# [23:11] <TabAtkins> s/stops/midpoints/
# [23:11] <birtles> ChrisL: one describes a curve, two or more--the behavior is not defined and is not used in practice
# [23:12] <birtles> TabAtkins: so more than one would be a syntax error
# [23:12] <birtles> ChrisL: yes
# [23:13] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [23:13] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [23:13] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [23:13] * Joins: koji (~koji@public.cloak)
# [23:14] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [23:14] * Joins: koji (~koji@public.cloak)
# [23:14] <birtles> leif: I saw a similar effect when dragging the stop and midpoint to the right
# [23:15] <birtles> cabanier_: that's due to the response curve since your device is not linear
# [23:15] <birtles> ... that requires a different solution
# [23:15] <birtles> heycam: we already have that in SVG, you can specify interpolation in linear or sRGB
# [23:15] <birtles> cabanier_: yes
# [23:16] <birtles> ChrisL: we don't yet have a way to ask for a smooth curve through points in a color space with C1 continuity
# [23:16] <birtles> ... although we do have that for paths now
# [23:16] <birtles> ... with Catmull-Rom curves in SVG2
# [23:16] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [23:17] <birtles> RESOLUTION: change CSS Images 4's specification of colorless color stops to use Rik's proposal (i.e. use power curves)
# [23:18] <birtles> topic: fill/stroke with background syntax
# [23:18] <birtles> krit: we decided we want to have fill/stroke properties on text in general, not just SVG shapes
# [23:19] <birtles> ... however, lately we realised we don't just want SVG paint servers but also images
# [23:19] <birtles> ... so you can use regular CSS images etc.
# [23:19] <birtles> ... the difficulty comes from referencing images that have fixed size
# [23:19] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [23:19] <birtles> ... if the area you are painting differs from the size of the image
# [23:19] <birtles> ... what do you do
# [23:20] <birtles> ChrisL: that problem has already been solved for backgrounds
# [23:20] <birtles> krit: yes that is the proposal
# [23:20] <birtles> ... but roc suggested we don't support attachment
# [23:20] <birtles> smfr: what is the property?
# [23:20] <birtles> TabAtkins: you can use 'fill' etc. on text
# [23:20] <birtles> smfr: what is the bounding box
# [23:21] <birtles> TabAtkins: I think we were going to use the box of the text?
# [23:21] <birtles> smfr: use the background bounding box
# [23:21] <birtles> heycam: with the box decoration break, it's not too much trouble to paint the text over and over again
# [23:22] <heycam> s/over again/over again?/
# [23:22] <birtles> krit: without attachment you can't simulate some behaviors of -webkit-background-clip: text
# [23:23] <birtles> smfr: the geometry of the image filling is exactly the same the geometry backgrounds will use
# [23:24] <birtles> krit: the question here is not so much about painting CSS text but first how to use fill/stroke in SVG
# [23:24] <birtles> ... what do we do in SVG for multiple fill layers?
# [23:24] <birtles> ... I would like to use the same syntax as for background but without introducing extra properties
# [23:25] <birtles> ... we can do that later
# [23:25] <dbaron> -webkit-background-clip: text -> background-clip: -webkit-text;
# [23:25] <birtles> ... for now just have the one property specifying the multiple layers
# [23:25] <birtles> heycam: what are the different parts of background?
# [23:25] <birtles> ... if we are going to do some, we should do all?
# [23:25] <birtles> ... often you want multiple backgrounds so you can layer them all at once without doing different sizes
# [23:26] <birtles> ... do we need that complexity in SVG?
# [23:26] <birtles> krit: it just falls out
# [23:26] <birtles> heycam: as long as you can re-use your existing background stuff, then it's ok
# [23:26] <birtles> TabAtkins: do you want to do the same thing for stroke?
# [23:26] <birtles> krit: yes
# [23:27] <birtles> smfr: so would you repeat the image like we do for backgrounds?
# [23:27] <birtles> krit: yes, with the same syntax
# [23:27] <birtles> TabAtkins: for SVG we'll ignore the <box> part of the production for <bg-layer>?
# [23:27] * Joins: emalasky (~Adium@public.cloak)
# [23:27] <birtles> krit: not necessarily
# [23:27] <birtles> ... you might want to repeat the image
# [23:27] <birtles> TabAtkins: that's <bg-size>
# [23:28] <birtles> ... the values for <box> don't make any sense for SVG
# [23:28] <birtles> ... do we want to add the SVG ones there?
# [23:28] <birtles> ... ('fill', 'stroke') etc.?
# [23:29] <birtles> smfr: does fill/stroke just control what gets painted?
# [23:29] <birtles> TabAtkins: yes
# [23:29] <birtles> smfr: it seems a bit odd, different to what we have in CSS
# [23:29] <birtles> ... we can't do layered borders
# [23:30] <birtles> krit: attachment doesn't make sense for SVG for now so it will just be ignored
# [23:30] <birtles> ... we might want to leave it out of the syntax
# [23:30] <birtles> heycam: perhaps later we can talk about different stroke widths for each item in the list
# [23:31] <birtles> smfr: it's interesting that you can do something in SVG that you can't do in CSS, namely repeating an image around the border
# [23:31] <birtles> krit: I wanted to bring it up today because it's a CSS property and because we will use these properties for text in the future
# [23:32] <birtles> ChrisL: it is nice for HTML to be able to color text with something other than a solid fill
# [23:32] <birtles> TabAtkins: we can add attachment later and add it later if we decide it is sufficiently useful
# [23:33] <birtles> RESOLVED: Import the background shorthand syntax for multi-fill and multi-stroke into SVG minus the attachment part of the syntax
# [23:34] <smfr> topic options: media queries, variables, CSS OM,
# [23:35] <birtles> topic: media query variables (aka queriables)
# [23:35] <dbaron> http://tabatkins.github.io/specs/css-aliases/
# [23:35] <birtles> TabAtkins: CSS variables work really well for a lot of use cases but for some CSS preprocessors are still better
# [23:36] <birtles> ... for example, if you have an extended media queries, you are out of luck
# [23:36] <birtles> ... this is a proposal to define aliases
# [23:36] <birtles> ... it includes a declarative form that is equivalent to what preprocessors can do today plus a script-based form that extends it further
# [23:37] <AdobeSeattle> s/queriables/css aliases/
# [23:37] <birtles> ... this is my current proposal for declaring a custom media query
# [23:37] <birtles> ... this is a restriction that the custom name must contain and underscore
# [23:37] <birtles> ... there is a similar restriction in HTML where you want to define custom elements without clashing
# [23:38] <birtles> ... in that case they got around this by using dashes
# [23:38] <birtles> ... you have to include a dash in a custom element name
# [23:38] <birtles> ... in the same way, this requires underscores
# [23:38] <birtles> ... <idents> can use underscores but we've never used them
# [23:39] <birtles> heycam: will you remove underscores from <ident>
# [23:39] <birtles> TabAtkins: no, <ident> still includes them but we the language never use it
# [23:41] <birtles> glazou: it seems like you're defining a media type
# [23:41] <dbaron> (glazou doesn't like the parentheses)
# [23:41] <birtles> TabAtkins: it's actually defining a media feature
# [23:41] <birtles> ... you need to use parentheses in @media since it's not a media feature
# [23:41] <birtles> ... but authors will soon stumble across that and work it out
# [23:41] <birtles> ... it should also be possible to set up a media feature via javascript
# [23:42] <birtles> ... you should then also be able to test for that feature using CSS markup including : and <
# [23:42] <birtles> ... the javascript can define a boolean, number of string
# [23:42] <birtles> ... this allows the style to react to something in its environment that can be controlled from script
# [23:42] <birtles> ... so modernizr could use this rather than defining styles on the body
# [23:43] <birtles> dbaron: is there a use case for being able to set lengths
# [23:43] <birtles> TabAtkins: probably but I'd like to defer that until I talk about OM
# [23:43] <birtles> ... I think it depends on what we decide on OM
# [23:43] <birtles> ... so I'd like to add that later
# [23:43] <dbaron> s/number of string/number or string/
# [23:43] <birtles> smfr: can you unset values?
# [23:43] <birtles> TabAtkins: this is just a map so you can just unset as usual
# [23:43] * Parts: krit (~sid15081@public.cloak)
# [23:43] * Joins: krit (~sid15081@public.cloak)
# [23:44] <birtles> SimonSapin: would the map already include the ones defined in markup
# [23:44] <birtles> TabAtkins: yes, and I'd have to define the order
# [23:45] * ChrisL customize *all the things*
# [23:45] <dbaron> dbaron: Can you put @custom-media instide other conditional rules (esp. @supports)?
# [23:46] <birtles> TabAtkins: I assume no, the definitions are probably global but I can change this depending on what is reasonable for implementation
# [23:46] <dbaron> dbaron: I'm fine with no.
# [23:46] <birtles> ... I haven't specified it here, but for example, if defined twice the last one wins, javascript wins over markup etc.
# [23:46] <birtles> ... standard precedence stuff
# [23:46] <dbaron> TabAtkins: Also, no need for custom @supports stuff because you can use CSS.customMedia.set() with results of supports queries
# [23:47] <birtles> heycam: I don't think we should have MapClass anymore
# [23:47] <birtles> ... no-one much likes it
# [23:47] <birtles> TabAtkins: I want real maps but I don't care how to markup it up in WebIDL
# [23:47] <birtles> heycam: I think we can come up with something else and then I'll let you know
# [23:48] <birtles> TabAtkins: the selectors rule works the same way for custom selectors
# [23:48] <birtles> ... this is always going to be a pseudo-class
# [23:49] <birtles> ... (presents an example of a heading pseudo-class from the draft)
# [23:49] <birtles> smfr: why is it :_heading?
# [23:49] * dbaron thinks GeographyClass is clearly a better name for MapClass
# [23:49] <birtles> TabAtkins: the _ is from the restriction I mentioned before, : is because otherwise it would be an element name
# [23:49] <birtles> krit: that's not in the production
# [23:50] <birtles> TabAtkins: yes, that should be there
# [23:50] <dbaron> ?: Why have the : in the @custom-selector, rule?
# [23:50] <dbaron> TabAtkins: Clearer that way.
# [23:50] <birtles> heycam: what if you put an <ident> directly before the custom selector?
# [23:51] <AdobeSeattle> p:_foo === p:matches(...)
# [23:51] <birtles> ... e.g. p:_heading
# [23:51] <birtles> TabAtkins: it just works because it expands to : matches
# [23:52] <birtles> glazou: there are restrictions to what are allowed in a colon matches
# [23:52] <birtles> ... you should duplicate that explicitly here so it's a syntax error where the @ rule is defined
# [23:52] <birtles> TabAtkins: sounds reasonable
# [23:52] <dbaron> glazou: @custom-selector should be a syntactically-invalid @-rule if it doesn't meet the syntax requirements for what goes inside :matches()
# [23:53] <dbaron> TabAtkins: I should special-case top-level :not() so that it expands into :not() instead of :matches() in that case.
# [23:53] <birtles> glazou: I recommend we epand the :_heading example to include an expansion without the custom selector so that people don't think it's not just a macro
# [23:53] <glazou> s/epand/expand
# [23:53] <SimonSapin> q+
# [23:54] <smfr> q+
# [23:55] <AdobeSeattle> No using custom pseudo-classes to define other custom pseudo-classes, because it hits the "no :matches() inside :matches()" rule.
# [23:55] <dbaron> TabAtkins: ... not sure what I think of that
# [23:55] <birtles> SimonSapin: why do we have that restriction: no :matches inside :matches
# [23:56] <birtles> ... this feature would be a lot more interesting without this limitation
# [23:56] <birtles> ... what is the scope of this rule?
# [23:56] <birtles> TabAtkins: document scope
# [23:57] <birtles> florian: you need to define that if a selector is not matched it is not invalid but simply not matched because it may be defined later
# [23:58] <birtles> SimonSapin: does it update dynamically?
# [23:58] <birtles> TabAtkins: yes
# [23:58] <florian> you need to define that if a selector is not defined yet it is not invalid but simply not matched because it may be defined later
# [23:59] <birtles> TabAtkins: that means you can actually define fallback
# [23:59] <birtles> smfr: I think this needs more syntactical sugar so it's easy to remember
# Session Close: Thu Jan 30 00:00:01 2014

The end :)