stearns: So handling more content in a region is the same as in any other element.

08:22:49 [TabAtkins_]

stearns: So I'd liketo close this issue.

08:22:50 [kazutaka]

kazutaka has joined #css

08:22:51 [lmclister]

lmclister has joined #css

08:22:56 [TabAtkins_]

howcome: Examples?

08:23:24 [dino]

dino has joined #css

08:23:25 [TabAtkins_]

stearns: The very first example in the spec has an example - the last region is auto height and will just take the rest of the flow.

08:23:31 [TabAtkins_]

howcome: What about pagination?

08:23:41 [TabAtkins_]

stearns: No effect on printing - it'll break across pages just like a normal element.

08:23:47 [kawabata]

kawabata has joined #css

08:24:11 [TabAtkins_]

stearns: I got one response on the list from Anton saying it was reasonable.

08:24:40 [TabAtkins_]

howcome: What dimensions does it expand?

08:24:48 [TabAtkins_]

stearns: Same as an auto-height div.

08:25:13 [TabAtkins_]

stearns: The email goes into what you can do witht he last region - you can make it auto height, scrollable, overflow:visible; everything you can do with a normal element.

08:26:04 [sakih]

sakih has joined #css

08:26:06 [TabAtkins_]

TabAtkins_: I'm satisfied that this concludes the issue - the last region in a chain is no longer restricted, and you can do everything you can do with a normal element.

08:26:08 [yamaday]

yamaday has joined #css

08:26:38 [TabAtkins_]

stearns: The issue as stated is that region chains can't handle a varaible amount of content. At the time the issue was raised, this was true. It's no longer.

08:26:57 [TabAtkins_]

stearns: We could close this issue and let you raise further issues.

08:27:17 [TabAtkins_]

fantasai: Can you have a region in the middle of the chain that's auto-height with a max-height, where it overflows to the next region in the chain?

08:27:25 [TabAtkins_]

stearns: Yes, that's what the processing model now addresses.

08:27:30 [lstorset]

lstorset has joined #css

08:27:59 [TabAtkins_]

RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary amounts of content in a region chain.

08:28:59 [TabAtkins_]

Rossen: can you swap css3-ui with something in the afternoon? I'm waiting for Tantek and Sylvain.

08:29:07 [yamaday]

join #css

08:30:55 [vhardy_]

vhardy_ has joined #css

08:31:52 [TabAtkins_]

Topic: HTML & CSS

08:32:01 [TabAtkins_]

plh: HTML plans to move to CR by the end of the year.

08:32:15 [TabAtkins_]

plh: So if there are any concersn from the CSSWG, I'd like to get it now.

08:32:23 [TabAtkins_]

plh: Are there any issues from the CSSWG?

08:32:28 [TabAtkins_]

glazou: I have three issues.

08:32:33 [TabAtkins_]

glazou: The first is organization.

08:32:46 [TabAtkins_]

glazou: The liaison between html and css - there has been none.

08:32:58 [TabAtkins_]

glazou: The HTML spec concerns bits of CSS related to scoped stylesheets and selectors which were never discussed with us.

08:33:11 [TabAtkins_]

glazou: I call that a big issue, since the htmlwg charter contains a liaison with us.

08:33:23 [TabAtkins_]

glazou: Don't care what side the problem lies on, but it needs to be solved.

08:33:25 [fantasai]

s/liaison/mandatory liaison/

08:33:28 [TabAtkins_]

glazou: Second problem is technical.

08:33:34 [TabAtkins_]

glazou: The html spec contains scoped stylesheets.

08:33:53 [TabAtkins_]

glazou: There's a grammar for scoped stylesheets in html, but we don't ahve a formal definition of how they'll work in CSS.

08:34:12 [TabAtkins_]

glazou: There's no material the html spec can reference normatively.

08:34:20 [TabAtkins_]

glazou: Third point is about CSS pseudoclasses.

08:34:54 [TabAtkins_]

glazou: There are pseudoclasses inthe HTML spec - some are related to pseudos in css3-ui, but we never had a joint group or submission saying "we plan to include things that are in your charter in our spec, how can we do that, is that correct, etc."

08:35:14 [TabAtkins_]

glazou: So it seems to me the process between the two WGs are completely broken.

08:35:25 [TabAtkins_]

glazou: We dont' have these issues with the SVGWG - we work together great.

08:35:36 [TabAtkins_]

glazou: So we have two things in the HTML spec that should be defined on our side.

08:36:03 [dbaron]

TabAtkins: On selectors, we've either defined everything or HTML is just defining the host language part of it

08:36:15 [dbaron]

TabAtkins: ... in cases where things are to be defined by the host language

08:36:21 [vhardy__]

vhardy__ has joined #css

08:36:34 [TabAtkins_]

plh: I like to understand if other people in the CSSWG share your opinions.

08:36:43 [mjs]

mjs has joined #css

08:36:47 [TabAtkins_]

plh: And some of the CSSWG is in the HTMLWG, so if there's no liaison, I wonder what's oging on.

08:37:32 [TabAtkins_]

dbaron: We've been through the form control stuff before, but I agree with Tab that there's no problem there.

08:37:33 [mjs]

q+

08:37:54 [TabAtkins_]

dbaron: I don't think the <style scoped> stuff is defined well anywhere yet, or if it reflects quite what our idea of how it will work is.

08:38:30 [stearns]

TabAtkins_: Me will define

08:38:36 [TabAtkins_]

plh: Is <style scoped> handled properly in HTML?

08:38:56 [TabAtkins_]

fantasai: First thing is how selectors are scoped.

08:39:04 [TabAtkins_]

fantasai: Second is a mechanism to change how they're scoped.

08:39:08 [franremy]

(just a note: maybe we also need to speak about shadow dom and its interaction with CSS, those specs also contain quite a bite of CSS)

08:39:09 [TabAtkins_]

fantasai: Third is howt he cascade is scoped.

08:39:28 [TabAtkins_]

fantasai: The fourth is how globally scoped things like @font-face are handled.

08:39:35 [Norbert]

Norbert has joined #css

08:39:47 [yamaday]

yamaday has joined #css

08:40:04 [TabAtkins_]

fantasai: So there's four aspects of this. We have a definition for the first, and Tab and I are planning to work on a the third.

08:40:09 [TabAtkins_]

fantasai: Dunno about the second and fourth.

08:40:13 [Liam|XMLCore]

Liam|XMLCore has joined #css

08:40:16 [sakkuru_]

sakkuru_ has joined #css

08:40:18 [TabAtkins_]

TabAtkins_: The fourth is defined in hTML now - Boris got it fixed.

08:40:39 [TabAtkins_]

fantasai: It doesn't matter if the HTMLWG editor is in the room or not, if they aren't bringing things up to us for review, etc.

08:40:53 [TabAtkins_]

dbaron: I think we know about this - we don't need a formal email asking us to review it.

08:41:47 [fantasai]

dbaron: The interesting question is, is there anything else we're not aware of.

08:41:52 [glazou]

Zakim, ack mjs

08:41:52 [Zakim]

I see no one on the speaker queue

08:43:03 [dbaron]

dbaron: I don't think we need a formal email to inform us of something that we've discussed multiple times that we haven't received a formal email about.

08:43:17 [plh]

plh has joined #css

08:43:19 [glazou]

glazou: I think we do formal link between groups

08:43:22 [plh]

q?

08:43:24 [TabAtkins_]

TabAtkins_ has joined #css

08:43:30 [glazou]

mjs: this is first time I hear about these issues

08:43:37 [glazou]

glazou: no

08:43:46 [fantasai]

glazou: I sent them as LC comments during the vote

08:44:05 [fantasai]

glazou: Never got a reply

08:44:26 [plh]

q+ PaulCotton

08:44:28 [fantasai]

plinss: We sent comments last year as a WG, and the bug was closed WONTFIX by hixie

08:44:39 [fantasai]

mjs: We have a clear process for escalating issues

08:44:58 [fantasai]

mjs: We love technical input, but don't go out of our way to solicit it

08:45:33 [fantasai]

mjs invites CSSWG members to participate in HTMLWG meetings at TPAC

08:46:11 [fantasai]

mjs: Recently had change of editors, trying to be more open to input

08:46:25 [glazou]

Zakim, ack PaulCotton

08:46:25 [Zakim]

I see no one on the speaker queue

08:46:40 [fantasai]

PaulCotton: Want to be more factual here. What are the bug numbers raised on these issues?

08:46:57 [fantasai]

PaulCotton: What are the comments that were made for LC?

08:47:15 [glazou]

Zakim, q+

08:47:15 [Zakim]

I see glazou on the speaker queue

08:47:40 [fantasai]

PaulCotton: If there weren't issues raised as tracker issues, we don't pay attention to them.

mjs: How would you like us to inform you of changes we need in CSS? Filing a bug?

09:07:13 [fantasai]

TabAtkins: Send an email to www-style.

09:07:45 [fantasai]

mjs asks for example

09:07:54 [fantasai]

TabAtkins: The bugs I filed against HTML are examples

09:08:04 [dbaron]

mjs (above): Can you point to an email you've sent that's an example of what you'd consider sufficient notice to you?

09:08:26 [TabAtkins_]

fantasai: Hixie has sent us emails asking for specific changes in CSS specs, and that's exactly how it should be handled.

09:08:26 [dbaron]

fantasai: Hixie sent us some emails asking for changis in CSS specs; those were exactly how it should be handled.

09:08:42 [plh]

q?

09:08:42 [dbaron]

fantasai: What wasn't handled was saying that we drafted a new CSS feature and put it in HTML5 spec.

09:08:43 [TabAtkins_]

fantasai: What wasn't handled was something informing us of some of the CSS features in HTML being drafted at all. ^_^

09:09:02 [TabAtkins_]

mjs: So what do you need to continue technically to resolve any issues in HTML?

09:09:19 [plh]

q+

09:09:42 [TabAtkins_]

mjs: As far as I know, all we've gotten so far in the HTMLWG about style scoped is that it's undefined, from Glazou.

09:09:51 [jet]

jet has joined #CSS

09:09:55 [TabAtkins_]

mjs: But today we have four things being about it.

09:10:06 [TabAtkins_]

TabAtkins_: They're four ways of saying a specific thing is undefined.

09:10:34 [TabAtkins_]

glazou: Scoped stylesheets will be a major way to copypaste stylesheets. There are multiple deep technical issues to solve about these. It won't happen today.

09:10:49 [TabAtkins_]

glazou: My take is that it's so undefined right now, and there's so much on our radar, it's at risk, but you should drop it for now.

09:11:05 [TabAtkins_]

glenn: Are there two interop impls?

09:11:20 [TabAtkins_]

TabAtkins_: No - we've specifically held back our impl because it's not interop with how we know we want it to act.

09:11:30 [hober]

So, has someone filed a "Drop <style scoped>" bug?

09:11:35 [TabAtkins_]

glazou: It's so undefined, and will take long enough to do so, that it should be dropped.

09:11:56 [TabAtkins_]

mjs: If best solution turns out that it shoudl be dropped, that's fine.

09:12:00 [TabAtkins_]

mjs: But we need a bug and to be informed about this.

09:12:42 [TabAtkins_]

mjs: I've heard several rapid-fire problems listed today, but we need those details to be brought to us.

09:13:09 [fantasai]

TabAtkins_: The original problem we're bringing up is that nobody told us about it, or asked us to define it. Just now picking it up because we have to

09:13:35 [fantasai]

TabAtkins_: But even within HTMLWG, ppl know that it's not well-enough defined to be implemented right now. bzbarsky has given feedback; Chrome is holding back implementation because it doesn't match what we want to do

09:13:54 [fantasai]

TabAtkins_: The problem is well-known within HTMLWG

09:14:02 [plh]

q+ PaulCotton

09:14:19 [fantasai]

glazou: One concrete example I said is specificity of selectors, don't know technical solution we choose, need discussion to happen, but will drastically impact solution. Not a 10-minutes discussion

09:14:35 [fantasai]

glazou: Need to find compromise that satisfies everyone.

09:14:41 [tomoyuki]

tomoyuki has joined #css

09:14:47 [fantasai]

glazou: And it's on our side, not on yours. It's about how the cascade works. Not in the HTML spec.

09:14:54 [fantasai]

glazou: Am I completely mistaken or what?

09:15:43 [TabAtkins_]

plh: It seems to me that we have information on the style scoped about whether to keep it or not.

09:15:55 [franremy]

q: can't we replace the scoped attribute with a :scope-root pseudo-class so that it doesn't have to be defined in HTML at all?

09:16:09 [TabAtkins_]

mjs: I don't think we have. You guys have told us multiple rapid-fire problems, but they haven't been listed.

09:16:21 [plh]

q?

09:16:21 [dbaron]

q+

09:16:23 [plh]

ack plh

09:16:29 [TabAtkins_]

TabAtkins_: they're all variants of "it's undefined". The specifics dont' matter. You've known it was undefined since we told you a year ago.

09:16:38 [TabAtkins_]

mjs: Okay, so what should we do specifically?

09:16:41 [TabAtkins_]

glazou: Drop it.

09:16:47 [plh]

q?

09:16:48 [TabAtkins_]

mjs: Give us that feedback specifically. Send it in.

09:17:08 [TabAtkins_]

mjs: Please submit a comment to the HTMLWG saying that and giving rationale.

09:17:13 [TabAtkins_]

glazou: I've done that multiple times.

09:17:27 [TabAtkins_]

mjs: I looked up your comments, and you didn't actually say that.

09:17:41 [TabAtkins_]

glazou: PLH, do we really discuss inter-WG things via bugs only?

09:17:50 [TabAtkins_]

glazou: I don't understand why you need more input from us.

09:19:27 [TabAtkins_]

PaulCotton: I asked for exact comments. You pointed to a bug. It was closed, you didn't reopen.

09:19:31 [evanli]

evanli has joined #css

09:20:02 [TabAtkins_]

mjs: The HTMLWG has a process. If you engage in it, we'll respond. But berating us won't solve a problem. If the problem is that it's underdefined and won't be solved in time, file a bug.

09:20:11 [TabAtkins_]

mjs: If you're unwilling to engage in our process, then I won't help you.

TabAtkins_: The ones in HTML right now are all just the host-language stuff. The real new things are in WebVTT.

09:25:49 [TabAtkins_]

mjs: WebVTT is no longer a HTMLWG deliverable. It's in a CG.

09:26:11 [TabAtkins_]

glazou: This is a quite heated discussion, I agree. But we'd love to help the WG witht he HTML spec. We'd love to be pinged when it's on our scope.

09:26:13 [mjs]

mjs has joined #css

09:26:35 [Bert]

q+ to mention another (some day) coord. issue: <DETAILS>

09:26:43 [TabAtkins_]

hober: Right now we're trying to remove/drop things, not add.

09:26:53 [TabAtkins_]

plh: But in HTML.next, if ever there is something new added, tell the CSSWG.

09:27:26 [TabAtkins_]

PaulCotton: The way we're pulling from WHATWG to HTML5.1, the triage team should probably check for CSS-specific things and send an email to the CSSWG.

09:27:56 [TabAtkins_]

mjs: In the past when stuff got put into the spec, I'll be honest and say it was largely editor recalcitrance.

09:28:06 [Rossen]

Rossen has joined #css

09:28:50 [TabAtkins_]

Bert: About a year ago I sent a personal note that I think there's a better way to define the <details> element that makes it easier to style in pure CSS.

09:29:07 [TabAtkins_]

plh: Feel free to bring that up in our meeting Thu/Fri.

09:29:26 [dbaron]

break-duration: calc(15 * 60s)

09:30:20 [Bert]

q-

09:30:32 [TabAtkins_]

zakim, ack krit

09:30:32 [Zakim]

I see no one on the speaker queue

09:31:34 [tomoyuki]

tomoyuki has joined #css

09:35:39 [yaso]

yaso has joined #css

09:35:50 [rubylin]

rubylin has joined #css

09:36:57 [tomoyuki]

tomoyuki has joined #css

09:39:21 [kotakagi]

kotakagi has joined #css

09:40:40 [vhardy__]

vhardy__ has joined #css

09:47:09 [yamaday]

yamaday has joined #css

09:49:05 [yamaday]

yamaday has joined #css

09:52:41 [tomoyuki]

tomoyuki has joined #css

09:53:01 [yamaday]

aaaaaaaaaaa

09:55:34 [John_Jansen]

John_Jansen has joined #css

09:58:33 [rhauck]

rhauck has joined #css

09:59:41 [JohnJansen]

JohnJansen has joined #css

10:00:21 [kotakagi]

kotakagi has joined #css

10:00:28 [yamaday]

yamaday has joined #css

10:00:54 [drublic]

drublic has joined #css

10:03:55 [lmclister]

lmclister has joined #css

10:04:42 [rhauck]

rhauck has joined #css

10:06:51 [yamaday]

yamaday has joined #css

10:09:21 [tomoyuki]

tomoyuki has joined #css

10:10:50 [mgylling]

mgylling has joined #css

10:12:40 [cabanier]

cabanier has joined #css

10:13:20 [TabAtkins_]

TabAtkins_ has joined #css

10:13:32 [mjs]

mjs has joined #css

10:13:35 [dbaron]

</br>

10:14:06 [dbaron]

Topic: Regions issues

10:14:15 [dbaron]

Alan: 3 issues left

10:14:28 [divya]

divya has joined #css

10:14:40 [TabAtkins_]

stearns: The draft currently says that Regions create their own stacking contexts. There's an issue on the draft that perhaps we shouldn't do that, and allow them to be non-stacking.

10:15:07 [TabAtkins_]

stearns: My contention is that regions should behave more like the things that *do* create stacking contexts, like fixpos/flaots/etc, because we are taking content out of the flow and putting it somewhere else.

10:15:18 [Rossen]

Rossen has joined #css

10:15:21 [TabAtkins_]

stearns: Same justification for those applies to Regions. Little case for interleaving content.

10:15:41 [TabAtkins_]

dbaron: Floats actually create a pseudo-stacking context.

10:15:52 [TabAtkins_]

antonp: I don't think authors like stacking contexts.

10:16:10 [TabAtkins_]

hober: I think most authors don't know what a stacking context is, and when things interleave in weird ways, that's funky behavior.

10:16:19 [TabAtkins_]

hober: Will probably result in performance issue, which we can avoid...

10:16:24 [TabAtkins_]

hober: I don't think authors would interleave on purpose.

10:16:45 [TabAtkins_]

antonp: The reason the funny painting model exists is because people had overflow they weren't expecting; floats and next paragraphs and etc.

10:16:55 [TabAtkins_]

antonp: That's why text is painted after all background/borders/etc.

10:16:59 [Norbert_]

Norbert_ has joined #css

10:17:02 [TabAtkins_]

antonp: Makes overlaps less painful.

10:17:18 [TabAtkins_]

antonp: So it was historically because there was a lot of overflow, and impls thought it was better to see content.

10:17:31 [TabAtkins_]

dbaron: I'm not sure it was that logical of a process.

10:17:56 [TabAtkins_]

dbaron: There's a decent chunk that was Hixie and I interpreting a vague chunk of the spec, and coming up with the one precise definition that satisfied it, then wrote tests and got impls, and that was that.

10:18:05 [TabAtkins_]

dbaron: Never really learned how much of that was intentional.

10:18:36 [TabAtkins_]

dbaron: The spec never quite said that the backgrounds of the next paragraph drew under the text of the next paragraph, but you could infer it from a rule about floats, which was similar.

10:18:48 [TabAtkins_]

dbaron: The thing I'm slightly worried about is...

10:18:56 [TabAtkins_]

dbaron: You're talking a region being a stacking context?

10:18:59 [TabAtkins_]

dbaron: Each region?

10:19:15 [TabAtkins_]

stearns: Each region is a context for the fragment of the flow in it.

10:19:41 [TabAtkins_]

dbaron: My problem is when people put regions close to each other to give the illusion of continuous flow

10:19:51 [TabAtkins_]

TabAtkins_: Like using them to make a "non-rectangular grid cell".

10:20:00 [TabAtkins_]

dbaron: yeah. But I think there might be weird issues now.

10:20:16 [TabAtkins_]

stearns: That's only a problem if they break outside of the bounds of the region.

10:20:29 [TabAtkins_]

dbaron: Not necessarily rare, with text slightly overflowing, etc.

10:20:36 [TabAtkins_]

dbaron: Don't have a strong opinion, but I'ma little worriedabout that case.

10:20:44 [TabAtkins_]

stearns: I'm not really sure what to do about that case.

10:20:52 [rotsuya]

rotsuya has joined #css

10:21:03 [stearns]

s/to do/to say/

10:21:11 [kensaku]

kensaku has joined #css

10:21:11 [TabAtkins_]

Rossen: No real opinion...

10:21:32 [TabAtkins_]

Rossen: From the pov of having valid use-cases for where it's really interesting to have interleaving, we struggled to find such a use-case.

10:21:47 [TabAtkins_]

Rossen: The one David is bringing up is somewhat valid for the content being laid out between the regions themselves.

10:21:52 [sakkuru]

sakkuru has joined #css

10:22:00 [toms]

toms has joined #css

10:22:07 [TabAtkins_]

Rossen: It is more interesting to see how the rest of the content outside the regions interacts with the content inside.

10:22:15 [TabAtkins_]

Rossen: This is why we'd prefer regions being their own stacking context.

10:22:26 [TabAtkins_]

Rossen: So you don't have weird interleaving between parts of the regions.

10:22:26 [hsivonen]

hsivonen has joined #css

10:22:45 [TabAtkins_]

antonp: I buy that point.

10:23:14 [TabAtkins_]

antonp: I'm kinda thinking, you got stuff flowing down the left, you got regions on the right, and you're directing flows through each, and if you've got a long word on the left it'll interleave with what's on the right.

10:23:29 [TabAtkins_]

antonp: What about a pseudo-stacking context, so abspos doesn't have to deal with it?

10:24:11 [TabAtkins_]

TabAtkins_: I think that limiting abspos is actually an important part of it.

10:24:23 [yamaday]

yamaday has joined #css

10:24:43 [TabAtkins_]

szilles: This seems a bit like the problems of composition in SVG - they introduced groups to denote what things are part of "the same thing" versus a different thing.

10:24:57 [TabAtkins_]

szilles: Conceivably one could introduce a similar property that groups things like that.

10:25:23 [TabAtkins_]

TabAtkins_: Like explicitly turning on stacking contexts without side effects?

10:25:45 [TabAtkins_]

szilles: No, other way around. Declaring that some stacking contexts are part of a group, so within that group they can interact, but they're still shielded from the rest of the group.

10:26:03 [TabAtkins_]

Rossen: To add to this, it becomes more apparent once you bring content that's not quite in the same document into regions.

10:26:18 [TabAtkins_]

Rossen: Then you have content from separate documents that can interleave.

10:26:30 [TabAtkins_]

TabAtkins_: You're talking about IE's addition that lets them flow iframes into a region flow?

10:26:40 [Bert]

q+ to compare regions with columns

10:26:41 [TabAtkins_]

Rossen: Yeah. You don't want an iframe to be interleaved with anything else.

10:26:57 [TabAtkins_]

antonp: At the very least that says you want pseudo-stacking contexts. It doesnt' necessarily talk about abspos.

10:27:23 [TabAtkins_]

antonp: abspos is a weird beast. But when people use it, they get frustrated that you can't choose where things are positioned from.

10:27:37 [TabAtkins_]

antonp: By locking it into the region box, it seems you're taking away a little of the freedom they otherwise have.

10:28:34 [TabAtkins_]

TabAtkins_: There's a workaround - flow the abspos into *another* region chain, and flow-from it somewhere outside higher in the document.

10:28:41 [TabAtkins_]

Bert: That loses the auto position, though.

10:28:56 [tomoyuki]

tomoyuki has joined #css

10:28:57 [TabAtkins_]

TabAtkins_: If you're usign the auto position, you probably don't need to worry about stacking context.

10:29:19 [TabAtkins_]

Bert: Most of the time when I use regions, I started using columns, then found a weird case, and had to replace the columns with regions.

10:29:30 [TabAtkins_]

Bert: That means that I'd like them to act like columns.

10:30:15 [TabAtkins_]

glazou: [something about columns across pages, and how regions would work the same way maybe?]

10:30:30 [TabAtkins_]

Bert: Point is that I'd like columns to act the same way as regions.

10:30:52 [TabAtkins_]

stearns: So that's an argument for Steve's suggestion - the ability to group contexts together.

10:31:10 [TabAtkins_]

dbaron: So you say that having flow-from on an element makes it a stackign context automatically?

10:31:15 [TabAtkins_]

stearns: yes, that's part of the spec right now.

10:31:24 [yaso]

yaso has joined #css

10:31:42 [TabAtkins_]

stearns: I have been arguing both sides of the issue with my teamf or months now, and I think I've come down on the side of stacking contexts.

10:32:06 [TabAtkins_]

stearns: Possibly with a future mechanism to aggregate stacking contexts.

10:32:29 [TabAtkins_]

TabAtkins_: I'm cool with that. I just don't want automatic grouping, from a performance standpoint.

10:32:45 [TabAtkins_]

stearns: Hyatt's doing some work with identical regions, which might be relevant there.

10:32:55 [TabAtkins_]

stearns: So, are there any objections to keeping what the spec currently says?

10:33:24 [TabAtkins_]

stearns: (i was arguing for the opposite position in my team, and I lost the argument)

10:34:26 [TabAtkins_]

Bert: It doesn't sound quite right - it's like an implicit relpos, which limits what you can do with abspos.

10:35:00 [TabAtkins_]

TabAtkins_: I think that there are enough implicit positioning containments already that we can argue this is a general limitation of *abspos*, not of any individual other spec, and should be fixed in abspos properly, by letting you override what you're positioning relative to.

10:35:16 [TabAtkins_]

antonp: Bear in mind that we're not just talking about positioning, but also painting.

10:35:28 [TabAtkins_]

antonp: If in the future we're going to let you throw your positioning root around, you're also changing positioning.

10:35:46 [TabAtkins_]

s/changing positioning/changing painting/

10:35:53 [TabAtkins_]

TabAtkins_: yeah, you're more or less moving it in the box tree.

10:36:29 [TabAtkins_]

Bert: Another comparison is with shapes - if you can make two regions and flow between them, or put a shape on a single paragraph that duplicates the same size, why do those act differently?

10:37:15 [TabAtkins_]

antonp: To be fair, you'll have different behavior anyway - the fragmentation is probably going to be different anyway.

10:37:24 [TabAtkins_]

Rossen: Currently in shapes there's nothing taklinga bout this.

10:37:49 [TabAtkins_]

Rossen: In the multishapes section, we're allowing multishapes.

10:37:59 [TabAtkins_]

Rossen: Like if you extract a shape from an image, and it creates two circles.

10:38:09 [TabAtkins_]

Rossen: The spec currently says its allowed, but doesn't define how it works.

10:38:44 [TabAtkins_]

Rossen: Making a comparison based on that right now is a bit premature imo.

10:39:07 [TabAtkins_]

Bert: maybe, but the examples I worked through often didn't matter - I could use multicol or regions, shapes or regions, they worked roughly equally well either way.

10:39:16 [TabAtkins_]

Bert: So I thought that if they were so similar, they should perhaps all be the same.

10:39:27 [TabAtkins_]

Bert: With their own possibilities, but the common elements should be the same.

10:39:45 [TabAtkins_]

stearns: If we have stacking contexts, the only part that might be different is that content that overlaps at the boundaries might get painted over.

10:39:59 [TabAtkins_]

stearns: That seems like a tiny edge-case for me. You generally avoid overlap.

10:40:02 [cox_]

cox_ has joined #css

10:40:11 [TabAtkins_]

Bert: I was thinking about abspos, actually.

10:40:23 [TabAtkins_]

Bert: But I'm not sure how important it really is. I generally use abspos only as a last resort.

10:40:34 [TabAtkins_]

stearns: It's certainly a limitation, and that's why I argued against it with my team.

10:40:42 [TabAtkins_]

stearns: But finding use-cases where you want interleaved content...

10:40:44 [kotakagi]

kotakagi has joined #css

10:40:49 [plh]

plh has joined #css

10:40:56 [kotakagi2]

kotakagi2 has joined #css

10:41:03 [liam]

liam has joined #css

10:41:06 [TabAtkins_]

stearns: From another direction, in all the use-cases we looked at, when you *have* interleaving, you always *want* a stacking context to prevent that from interleaving accidentally.

10:42:22 [TabAtkins_]

TabAtkins_: So most interleaving is accidental and would benefit from stacking contexts, and the cases where it might be good are a corner-case, which might be best addressed in the future by a specialized property to group stacking contexts together.

10:42:29 [TabAtkins_]

antonp: So are columns changing any?

10:42:31 [TabAtkins_]

stearns: No.

10:42:47 [TabAtkins_]

szilles: You'd need later to define that the stacking-context-grouping property auto-groups columns by default.

10:43:21 [TabAtkins_]

arronei: Does it become a stacking context as soon as flow-from is set, even if it has no content?

10:43:31 [TabAtkins_]

stearns: Yes, but then there's no content to be stacking-contexted.

10:43:32 [r12a]

r12a has joined #css

10:43:47 [TabAtkins_]

antonp: There was a comment from Hyatt about how content that flows through a region physically belong to the region.

antonp: Is this true, or does the content just flow through the space of the region?

10:44:29 [TabAtkins_]

stearns: I think that's relevant. If you're defining Regions to have stacking contexts, then it's the principle box of the Region that contains them, and the fragments of the flow are children of that in the box tree.

10:44:43 [TabAtkins_]

antonp: Hyatt has said that would significantly complicate his implementation.

10:44:53 [TabAtkins_]

stearns: He's gone back and forth on the issue. Not sure where he is on the issue right now.

Rossen: Our model so far is that content flows through the region, and the regions are little viewports through which you view the content.

10:45:48 [TabAtkins_]

Rossen: As you interact with the region, you change how much content is in each region.

10:45:56 [TabAtkins_]

Rossen: But that doesn't mean actually changing the content in the document.

10:46:05 [TabAtkins_]

Rossen: That complicates region styling.

10:46:14 [TabAtkins_]

Rossen: Region styling has proven to be complicated for that reason.

10:47:09 [vhardy__]

vhardy__ has joined #css

10:48:15 [TabAtkins_]

TabAtkins_: Wrong level of discussion. Are the box-tree stuff from the flow children of the region's box? Or are they independent and just happen to be rendered with a geometric restriction that makes them look like the same?

10:48:23 [TabAtkins_]

Rossen: The former (though it's complicated).

10:48:47 [TabAtkins_]

antonp: Makes sense - otherwise you get weird effects with things like a float "belonging" to another box entirely, which changes the rendering order.

10:49:38 [TabAtkins_]

Bert: Is this similar to the relationship between lineboxes and inline content?

10:49:42 [TabAtkins_]

TabAtkins_: Yes, very similar.

10:50:20 [TabAtkins_]

stearns: Especially given the connection with styling ::first-line. Same exact problem as region styling.

10:51:16 [TabAtkins_]

stearns: So back to the issue at hand - stacking contexts. Yay/nay?

10:51:49 [TabAtkins_]

dbaron: I dont' have strong opinions. I don't think we ahve a strong performance reason to prefer full stacking context versus pseudo. But I'd have to ask roc about it.

10:52:19 [TabAtkins_]

Rossen: I don't think performance is a strong reason to make a decision either way.

10:52:24 [TabAtkins_]

TabAtkins_: yeah, not strong, but an input.

10:52:37 [TabAtkins_]

Rossen: Right. I'm hearing, though, that some impls prefer it for performance reasons, and some don't care.

10:53:05 [TabAtkins_]

RESOLVED: bug 15824 - keep the current spec text, where regions all create stackign contexts for the stuff flowed into them.

howcome: [something along the lines of I'm not sure whether pseudo-stacking contexts would be good enough, rather than full stacking contenxts]

10:53:26 [TabAtkins_]

stearns: Should creation of regions from elements be disallowed?

10:53:50 [TabAtkins_]

stearns: This came up about a year ago.

10:53:55 [TabAtkins_]

stearns: I think there's a good reason to have this.

10:54:03 [TabAtkins_]

stearns: It can inherit part of the structure of your document.

10:54:09 [TabAtkins_]

stearns: Particularly for scripting/events.

10:54:10 [cabanier]

cabanier has joined #css

10:55:07 [TabAtkins_]

stearns: I think we should have the ability to flow it into css-created boxes, but we shouldn't disallow it.

10:56:06 [virginie]

virginie has joined #css

10:56:17 [TabAtkins_]

TabAtkins_: This is completely the issue I was taklign about yesterday, with changing over to dbaron's proposal.

10:56:48 [lstorset]

lstorset has joined #css

10:56:56 [lstorset]

lstorset has joined #css

10:57:12 [TabAtkins_]

stearns: Actually, you were doing an either-or. Either do dbaron's thing (no explicit region flow at all) or do Regions thing (explicit flow, with elements and such). So I'd like to resolve that, *if* we do that latter, we can use elements.

10:57:17 [TabAtkins_]

TabAtkins_: I'm fine with that.

10:57:20 [kotakagi]

kotakagi has joined #css

10:57:46 [TabAtkins_]

TabAtkins_: I'm not happy about being forced to use dummy elements, but it's better in my book than the alternatives, given the lack of dedicated pseudo-element creation right now.

10:58:29 [TabAtkins_]

stearns: There's an example by implication in note 3 about how you don't necessarily have to use dummy elements.

10:59:12 [dbaron]

howcome: ...

10:59:22 [divya]

TabAtkins: we dont need to handle eventing on pseudo-elements

10:59:42 [divya]

TabAtkins: if we end up going with current regions proposal there are a lot of things that wont work well and wont work accessibly if we just stick to pseudo elements

howcome: I am never going to agree to a solution based on dummy html elements you are not going to get my okay for that.

11:01:07 [divya]

TabAtkins: i use dummy html as wrappers all the time, it is going to be necessary sometimes

11:01:24 [divya]

howcome: you are creating a separate structure next to content structure

11:01:40 [divya]

stearns: that visual structure in a lot of interesting pieces has to have a structure, you have to have nesting in child-parent rels

11:01:42 [dbaron]

(Tab also said something unminuted after the "howcome: ...")

11:01:57 [divya]

stearns: one of the args against … is that you are reinventing html in css

11:02:20 [divya]

glazou: when you do TOCs and extract them, you do want elements.

11:02:36 [divya]

stearns: it is quite similar to what is being done in SHADOW DOM

11:02:58 [Bert]

(HTML could add a <toc> element.)

11:03:03 [divya]

stearns: you have an insertion point that is an empty element in your shadow dom tree. that seems to be something people want as well. we are providing a similar facility.

11:03:20 [divya]

TabAtkins: the point of shadow dom is recognizing that you need dummy elements and taking them from the main flow.

11:03:54 [divya]

stearns: in MS you have two separate html documents you have content and vi…

11:04:20 [divya]

howcome: i dont think you can make the argument that they are semantic

11:04:32 [divya]

howcome: we need representation of visual structure, we should not abuse html documents for that.

11:04:49 [divya]

stevezilles: i am sorry visual structure is semantic

11:04:58 [divya]

TabAtkins: philosophically opposed but not practically opposed

11:05:07 [Bert]

q+ to say using an external (XML) document for the visual structure is a different case again, and OK

11:05:09 [divya]

howcome: building on what you said, if we agree on going david's way we should do that.

11:05:28 [divya]

TabAtkins: within option b lets not screw around and allow that, as it is required for regions proposal to work well.

11:05:44 [divya]

howcome: it is not well defined if it requires html

11:06:05 [divya]

[lots of arguments]

11:06:45 [divya]

glazou: authors already use elements for layouts.

11:06:49 [divya]

glazou: they will continue to do it

11:07:05 [divya]

TabAtkins: my arg is what stearns suggests is improv over what we have right now.

11:07:20 [divya]

TabAtkins: you would have to explicitly break contents between the elements right now.

11:07:37 [divya]

TabAtkins: you have same divs sitting around, but you get better semantics with the content and more reliable styling.

11:07:55 [divya]

howcome: as soon as you change the font size.

11:08:08 [divya]

dbaron: assuming people will do things in the same proportion to they do things right now.

11:08:13 [fantasai]

dbaron: The strictly better than right now is assuming that people will do things in the same proportion to te rate they do them right now

11:08:24 [fantasai]

dbaron: But this will change the rate at which people do such things.

11:09:00 [fantasai]

;P

11:09:18 [divya]

TabAtkins: if we are selecting columns you are using pseudo elements

11:09:28 [Jirka]

Jirka has joined #css

11:10:01 [divya]

TabAtkins: there is no reason to cripple the alternative right now.

11:10:07 [divya]

TabAtkins: if we dont need it then stop caring about it.

11:10:24 [divya]

glazou: all specs rely on implementation in the long run, if we dont have 2 impl. then it would go away.

11:11:11 [divya]

steve zilles: people being forced to divide content to make it look like what it looks like.

11:11:26 [divya]

steve zilles: you have restructured it in a form that defeats accessible access

11:11:43 [divya]

steve zilles: you want to show content for different devices and you cant do it.

11:11:55 [glazou]

Zakim, q+

11:11:55 [Zakim]

I see Bert, glazou on the speaker queue

11:12:23 [divya]

steve zilles: html as a suitable lang to express viz structure, it is possible to explore restricting the use of regions to page templates and in that context require they be empty boxes

11:12:36 [TabAtkins_]

howcome: I think the page template proposal is much more sensible in that regard.

11:12:57 [TabAtkins_]

szilles: In that case regions would end up with addressable things - we'd get CSSOM access to them.

11:13:12 [TabAtkins_]

stearns: The OM stuff is in a separate spec entirely - the pseudo spec Daniel and I are doing.

11:13:37 [rubylin]

rubylin has joined #css

11:13:49 [TabAtkins_]

szilles: The main reason for this is exactly what Tab said - from a practical viewpoint, elements work today, and they're eventable/scriptable/etc. This needs to be there for a lot of use-cases.

11:14:09 [TabAtkins_]

szilles: If you're paginating a complex structure, you don't know what the use-cases are today, and we won't know what they are until we see them in the wild.

11:14:23 [TabAtkins_]

szilles: You can come up with a few simple rules, but they dont' generalize right now.

11:14:36 [Bert]

zakim, ack me

11:14:36 [Zakim]

Bert, you wanted to compare regions with columns and to say using an external (XML) document for the visual structure is a different case again, and OK

11:14:37 [TabAtkins_]

Bert: Two remakrs.

11:14:39 [Zakim]

I see glazou on the speaker queue

11:14:44 [TabAtkins_]

Bert: I've been watiing for regions for 15+ years.

11:15:01 [TabAtkins_]

Bert: If we're waiting for events to be defined on them, cool, let's do that. If it takes a year, okay.

11:16:01 [TabAtkins_]

Bert: going back to an example from alan was using an external document to define the regions. This seems fine to me as well, as long as those extra element are clearly marked as being in a document which is defined as being for layout, not meaning.

11:16:35 [TabAtkins_]

stearns: Certainly something MS has been working on - content in one doc and visual structure in the other - and we've been doing experiments with Shadow DOM, with similar effects.

11:16:36 [glazou]

Zakim, ack me

11:16:36 [Zakim]

I see no one on the speaker queue

11:16:44 [TabAtkins_]

stearns: Either way, they're separated from the meaningful HTML.

11:16:55 [TabAtkins_]

glazou: I was speaking at the Paris Web Conf last week.

11:17:05 [TabAtkins_]

glazou: I demoed Regions and other things, and people came to the end of my talk.

11:17:29 [dbaron]

q+

11:18:08 [TabAtkins_]

glazou: they said pseudos were bad because screen-readers dont' read pseudos.

11:18:22 [TabAtkins_]

TabAtkins_: I think they misunderstand. The real content will still be in the DOM, in a single element.

11:18:48 [dbaron]

q-

11:18:50 [TabAtkins_]

stearns: By the time you get to the reader, you're not looking quite at the DOM.

11:19:18 [TabAtkins_]

TabAtkins_: Not quite - they vary. You usually get an accessibility tree, which is an expanded version of the DOM.

dbaron: There's a long-standing problem with people trying to put *content* into the pseudos, rather than in the document.

11:20:04 [shepazu]

shepazu has joined #css

11:20:16 [dbaron]

dbaron: ... ...

11:20:25 [dbaron]

TabAtkins: If that's a problem then we also need to throw away flexbox and grid for the same reason.

11:20:46 [dbaron]

TabAtkins: If people have learned that putting content in pseduos in bad, they'll interpret what you say as the same bad thing.

11:20:53 [dbaron]

TabAtkins: I think their concern is actually mistaken.

11:20:57 [antonp]

+!

11:21:03 [antonp]

+1

11:21:05 [dbaron]

glazou: Let's take a flow that ...

11:21:20 [dbaron]

glazou: The voice reador should say "moving from one column to ..."

11:21:22 [dbaron]

?: why?

11:21:42 [dbaron]

TabAtkins: Regions encourages you to have a semantically whole pice of your content even if it's split visually.

11:21:58 [dbaron]

TabAtkins: Accessibility could be better in general when display order is different from source order.

11:22:06 [dbaron]

glazou: I was just reporting what I heard

11:22:21 [TabAtkins_]

stearns: Unless anyone has something to continue in this discussion, I'd like to close it. Leave the issue in the spec and continue on.

11:22:26 [TabAtkins_]

stearns: The next thing is quick.

11:22:31 [TabAtkins_]

stearns: I think it was resolved yesterday.

11:22:48 [TabAtkins_]

stearns: How the regions specification defines the first region box as the ICB of the named flow.

11:23:08 [TabAtkins_]

stearns: I wasn't sure if that was exactly necessary, but in the discussion yesterday about paged media and the talk about first page and ICB and such...

11:23:45 [TabAtkins_]

stearns: I think regions just needs to follow what is going on in pages.

11:24:15 [TabAtkins_]

TabAtkins_: I think arronei thought up a name for the concept you need: "fragmentation containing block". For the concept syou need to pull from the ICB, without the *full* assortment of baggage from it.

11:25:07 [fantasai]

fragmentaining block!

11:26:11 [TabAtkins_]

TabAtkins_: So we need to define exactly what parts of the current ICB concept need to be pulled out into FCB, because non-initial pages/regions/etc need them. Then write that down and reference it in Page and Regions.

TabAtkins: We should kill it if we know we have a better definition, which we do in Sizing.

11:41:38 [TabAtkins_]

dbaron: The definition in 19-23 is more complicated - you dont' want to get a different result from 5-8 as from 19-23, once you get a definite width.

11:42:08 [fantasai]

The point is, that this pseudo-algorithm should restrict itself to determining the number and width of the columns, because the rules for sizing a multi-col are not clear, not interoperable, and not agreed-upon

11:42:33 [TabAtkins_]

Bert: But that's in a float situation. I asked for column counta nd width, shouldn't i get it?

dbaron: You could interpret it as two different things, one is "you are currently doing preferred / minimum intrinsic width calculation", the other is "that, plus you have a shrink-to-fit width or any sort".

11:44:09 [TabAtkins_]

dbaron: I think Simon's proposal is takign the first.

11:44:14 [dbaron]

I think

11:44:31 [TabAtkins_]

glazou: It seems that some work has to be done on this in any way, because some definitions are missing or unclear.

11:45:05 [TabAtkins_]

fantasai: Yes. So we should not be leaving these in the spec. We should pull them out and let Sizing define it.

11:46:00 [dbaron]

dbaron: I think we should take the proposal, and raise further issues as they come up.

11:46:25 [TabAtkins_]

glazou: Straw poll, 6 for, 1 against, many abstain/undecided

11:46:40 [TabAtkins_]

glazou: Those who are undecided, can you trust the group?

11:46:56 [fantasai]

The proposal is, remove lines 3-10 in the pseudo-algorithm, use the term "used-width' rather than "available-width", and define in css3-multicol that "used-width" is undefined; work on it in css3-sizing

11:47:06 [TabAtkins_]

Rossen: There seems to be some conflicting terminology. It seems to be complicated.

11:47:26 [TabAtkins_]

Rossen: I'm interested in resolving this in favor of Sizing. I just want to minimize damage on this spec.

11:48:42 [TabAtkins_]

glazou: Okay, so discuss before tomorrow evening, and we will resolve. Otherwise, deferred.

krit: The 'clip' property only applies to abspos elements, using the rect() function.

13:37:43 [TabAtkins_]

krit: But clip-path() works on everything, with more shape functions and an SVG <clipPath> element reference.

13:38:03 [TabAtkins_]

s/clip-path()/'clip-path'/

13:38:32 [TabAtkins_]

TabAtkins_: So do we want to unify the two properties?

13:38:38 [yaso]

yaso has joined #css

13:39:54 [TabAtkins_]

krit: I think I don't - people might be confused about using both rect() and another shape (doing one on :hover, for instance) and not knowing why one doesn't work (since rect() would, for legacy reasons, only work on abspos elements).

13:40:14 [TabAtkins_]

TabAtkins_: Okay, so you're suggesting deprecating 'clip' and using only 'clip-path'.

13:42:28 [Zakim]

Zakim has left #css

13:42:36 [TabAtkins_]

plinss: Sorta sad - clip was the first one that we ever did with the intention of being extended with more functions like this.

13:43:50 [glazou]

s/quites/quits

13:44:42 [Zakim]

Zakim has joined #css

13:45:19 [TabAtkins_]

RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.

13:46:33 [TabAtkins_]

TabAtkins_: Related to this, can we add an inset-rectangle()?

13:46:56 [TabAtkins_]

dbaron: We have a standing resolution from 2001 to add an inset-rect()

plinss: Interpreting things differently based on fragment ID is an architectural faux-pas

14:02:01 [fantasai]

plinss: Interpretation of frag ID should be registered with media type

14:02:23 [fantasai]

plinss: Let's not do something that breaks the Web architecture

14:02:35 [fantasai]

TabAtkins: Two legacy behaviors are bg-image: url(svg); treats as an image

14:02:46 [fantasai]

TabAtkins: fill: url(svg); treats as a paint server

14:03:15 [fantasai]

fantasai: Then per-property, define handling of url() per property

14:03:55 [fantasai]

TabAtkins: doesn't work for masking -- could load svg as a mask path, or as an image

14:04:14 [fantasai]

fantasai: So pick a default, and then can use other function names to do something different

14:04:17 [fantasai]

ChrisL: ...

14:04:32 [fantasai]

krit: Mozilla also has to consider CORS, which is one reason need to know ahead of time

14:05:04 [fantasai]

krit: So let's leave this issue open for now

14:05:11 [fantasai]

krit: Can we publish a FPWD with changes we resolved today?

14:05:17 [fantasai]

plinss: any objections?

14:05:30 [ChrisL]

ChrisL: why not add a keyword with several values, he initial value is auto which means do the magic thing but you can add specific keywords for paint server or image if auto does the wrong thing for you

14:05:33 [fantasai]

RESOLVED: FPWD Masking

14:05:53 [fantasai]

plinss: Have similar issue wrt shortname

14:06:16 [fantasai]

...

14:06:20 [fantasai]

TabAtkins: It's a Level 1 spec

14:06:52 [fantasai]

TabAtkins: So could just call it css-mask

14:07:04 [fantasai]

RESOLVED: call it css-mask

14:07:05 [TabAtkins_]

dbaron: (to ChrisL) we already have the image()/element() functions to distinguish them, so I don't think we need further keywords to distinguish

sylvaing: This is about dynamic changes to animation properties or keyframes.

14:54:15 [TabAtkins_]

sylvaing: Spec since the beginning requires animation property or keyframes to be snapshotted at the start of the animation.

14:54:29 [TabAtkins_]

sylvaing: David and Simon agree that it should be more open to dynamic changes while it's running, such as changing the duration.

14:54:34 [TabAtkins_]

sylvaing: We haven't defined in detail how that works.

14:55:12 [TabAtkins_]

dbaron: I believe FF's model is that, at the first moment in which the animation-name appears in the animation list, we determine the start-time for the animation.

14:55:18 [TabAtkins_]

dbaron: This is the start time at the end of the delay (I think).

14:55:32 [TabAtkins_]

dbaron: As long as that animation name stays in th elist of animations, that's the start time we use for the animation.

14:55:39 [TabAtkins_]

dbaron: And we continue using that start time for all other things.

14:55:50 [TabAtkins_]

dbaron: I think basically anything else can change.

14:56:09 [TabAtkins_]

dbaron: So I *think* if you change the delay it has no effect, because we compute the "start" time as the end of the delay.

14:56:12 [TabAtkins_]

dbaron: But I'd have to confirm.

14:56:25 [lstorset]

lstorset has joined #css

14:56:52 [TabAtkins_]

dbaron: Effectively, you just recompute all the parametersof the animation at every moment based on the current values.

14:57:03 [ChrisL]

all the parameters are recomputed at each tick in the animation

14:57:36 [TabAtkins_]

dbaron: Exception is pausing. When running->paused, record the time you paused. Switch from paused->running, adjust the start time forward by the amount of time it was paused.

14:58:31 [TabAtkins_]

plinss: if you change things while paused, it can put you in a different position?

14:58:52 [TabAtkins_]

dbaron: Yes. Change the animation-duration while it's paused, and it'll live-move you to the new position.

14:59:35 [TabAtkins_]

dino: I don't like starting it at the end of the delay.

14:59:53 [TabAtkins_]

dbaron: I agree - I probably should have made it record from the start of the delay instead, so it can take delay changes into account.

15:00:05 [TabAtkins_]

dino: We snapshot right now, but the underlying engine supports modification.

15:00:32 [TabAtkins_]

dino: We have all the infrastructure so we can expose it to JS.

15:00:58 [TabAtkins_]

sylvaing: I'm okay with making the animation properties dynamic.

15:01:05 [mishida]

mishida has joined #css

15:01:06 [TabAtkins_]

sylvaing: We need some prose in the spec to b emore explicit.

15:01:08 [Norbert]

Norbert has joined #css

15:01:55 [TabAtkins_]

sylvaing: For example, "animation-name: b, c, d; animation-duration: 2s, 3s, 4s;", then I change to "animation-name: a, b, c, d;", does it restart b, c, d, or does it consider them as having never left the animation list?

15:02:15 [hiroki]

hiroki has joined #css

15:02:20 [TabAtkins_]

dbaron: b,c,d never left the lsit.

15:02:24 [TabAtkins_]

sylvaing: Okay, we need that written down.

15:03:00 [TabAtkins_]

dbaron: I wonder what brian birtle thinks about this, given his work.

15:03:14 [TabAtkins_]

TabAtkins_: Based on me working with him, I think this is in line with what he wants.

15:04:04 [TabAtkins_]

dino: Further wrinkles. What happens if your animation is almost done, you shrink its duration so it's already over? Do you get an end event?

15:04:16 [TabAtkins_]

TabAtkins_: I think *not* delivering one would result in bad accidental bugs.

15:04:19 [knobuta2]

knobuta2 has joined #css

15:04:46 [TabAtkins_]

dino: Okay, further answer. Animations with many iterations. Just befor ethe first iteration ends, you shrink the duration so that the entire animatino is over. Do you get tons of iterations events, one after the other?

15:05:26 [TabAtkins_]

TabAtkins: I can be argued either way on whether to deliver iteration events that didn't "actually" pass. I think it might be acceptable to have those inconsistent.

15:05:38 [TabAtkins_]

dino: Okay. So there are multiple things like this that need to be resolved and specified.

15:05:58 [TabAtkins_]

sylvaing: Right - right now everything is simple, because they can't change.

15:06:24 [TabAtkins_]

dino: We'll have to check every state transition - an animation that is done but filling (still technically running), but then has its duration changed so that it should still be running?

15:06:49 [TabAtkins_]

dino: Need to work out the full state machine for all of this.

15:07:11 [TabAtkins_]

plinss: (re: iteration events) maybe only deliver the last iteration, updating you to the current state.

15:08:35 [TabAtkins_]

ChrisL: Scrubbing was one of the things that SMIL got wrong - time resolution was permanent, so if you scrubbed and then ran it, it would jump back to the time it had gotten itself to.

15:08:49 [TabAtkins_]

dbaron: [draws a table of states on the whiteboard]

15:09:02 [TabAtkins_]

dbaron: If we define what fires for every transition between these cells, is that sufficient?

ACTION sylvain to define what happens when animation properties are changed dynamically.

15:11:39 [oyvind]

and @keyframes?

15:11:48 [TabAtkins_]

oyvind, getting there.

15:11:56 [oyvind]

alright

15:12:04 [TabAtkins_]

sylvaing: So, keyframes.

15:12:12 [TabAtkins_]

sylvaing: Changing those on the fly while animation is running.

15:12:37 [TabAtkins_]

sylvaing: The concept makes sense when the animation iterates - when the next interval takes the changes into account.

15:12:49 [TabAtkins_]

sylvaing: If you have an animation that runs once, I dunno.

15:13:14 [TabAtkins_]

dino: It sounds testable, sure, but internally it's actually kinda difficult - animation may be running on another thread, and there's a disconnect in processing times.

15:13:45 [JohnJansen]

JohnJansen has joined #css

15:13:55 [TabAtkins_]

TabAtkins_: Conceptually, I don't see anything wrong with changing them mid-animation.

15:14:51 [TabAtkins_]

glazou: I have a use-case. A long-running webapp animation may have a large duration. If you change it, you don't want to wait for an entire iteration to go by.

15:15:09 [divya1]

divya1 has joined #css

15:15:22 [TabAtkins_]

sylvaing: Are there any animation functions in @keyframes?

15:15:27 [TabAtkins_]

TabAtkins_: Only the timing function.

15:16:18 [TabAtkins_]

glazou: I think that dynamic changes of animations will actually be a reasonably common case (editting is hard right now, but CSSOM will improve)

15:18:12 [kensaku]

kensaku has joined #css

15:18:42 [TabAtkins_]

sylvaing: So what about changes of keyframes during an iteration event, intending for the next iteration to use new values?

15:18:59 [kensaku]

kensaku has joined #css

15:19:08 [TabAtkins_]

TabAtkins_: There may by a delay if you need to deliver the changes to a separate animation thread, but otherwise it should work fine.

15:19:28 [TabAtkins_]

TabAtkins_: I think we're doing work on our end that should make it automatically do a smooth transition over to the new values when it discovers that it's overshot and needs to change tracks.

15:19:32 [TabAtkins_]

dino: But then we need to specify that.

15:19:58 [TabAtkins_]

TabAtkins_: We'll have non-interop a bit anyway, because of timing issues based on whether you do animatino on a separate thread or not. I think we can leave it alone and spec after things have shaken out.

TabAtkins_: The reason why it's problematic is that border-style is not animatable. Thus, since the default (pre-animation) value of border-style is none, the animatino doesn't change it to solid. And, since it's "none", the border-width computes to 0, and so no animation happens at all.

15:33:03 [oyvind]

dbaron, ok, I misunderstood somewhat

15:33:03 [TabAtkins_]

leaverou: Authors find this super-confusing in my experience.

15:33:08 [TabAtkins_]

dbaron: There's an even more subtle issue here.

15:33:21 [TabAtkins_]

dbaron: Related to the processing model.

15:33:31 [florianr]

florianr has joined #css

15:34:00 [TabAtkins_]

dbaron: When animating from A to B, there's an idea that it overrides some of the properties, and only those.