#css IRC Log

Index

IRC Log for 2012-10-29

Timestamps are in PDT.

[00:03] * liam Quit (Ping timeout: 60 seconds)

[00:15] * antonp has joined #css

[00:27] * leaverou is now known as leaverou_away

[00:40] * SimonSapin Quit (Ping timeout: 20 seconds)

[00:43] * antonp Quit (Ping timeout: 20 seconds)

[00:50] * krit Quit ("Leaving.")

[00:50] * JohnJansen has joined #CSS

[00:51] * tomoyuki has joined #css

[00:52] * JohnJansen Quit ("Page closed")

[00:53] * JohnJansen has joined #CSS

[00:53] * JohnJansen Quit ("Page closed")

[00:54] * JohnJansen has joined #CSS

[00:56] <JohnJansen> I'm observing in the Browser Testing and Tools WG this morning.

[01:02] * Zakim has joined #css

[01:02] <plinss> rrsagent make logs public

[01:02] <plinss> zakim, this will be style

[01:02] <Zakim> I do not see a conference matching that name scheduled within the next hour, plinss

[01:02] * Kid has joined #css

[01:02] <plinss> rrsagent, pointer?

[01:02] <RRSAgent> See http://www.w3.org/2012/10/29-css-irc#T08-02-05

[01:07] * SteveZ has joined #css

[01:08] * leaverou_away is now known as leaverou

[01:08] * shepazu has joined #css

[01:09] * shepazu Quit ()

[01:10] * shepazu has joined #css

[01:11] * liam has joined #css

[01:11] * liam is now known as Liam|XMLCore

[01:12] * cabanier has joined #css

[01:13] * Rossen has joined #css

[01:13] * krit has joined #css

[01:14] * stearns has joined #css

[01:14] * plh has joined #css

[01:15] * SimonSapin has joined #css

[01:16] * franremy has joined #css

[01:18] * glazou has joined #css

[01:19] * antonp has joined #css

[01:19] * TabAtkins_ has joined #css

[01:19] * dbaron has joined #css

[01:19] * arronei has joined #css

[01:19] <TabAtkins_> ScribeNick: TabAtkins

[01:19] <TabAtkins_> ScribeNick: TabAtkins_

[01:19] * divya has joined #css

[01:20] * rhauck has joined #css

[01:20] <TabAtkins_> Topic: Relationship with html and css wg

[01:20] * divya wonders where is the common TPAC channel is

[01:21] <TabAtkins_> glazou: We still have no definition of what a scoped stylesheet is in CSS.

[01:21] * mgylling has joined #css

[01:21] <TabAtkins_> TabAtkins: fantasai and I will take care of that next month.

[01:21] * plh will join at 9:30am with Paul Cotton to talk about html

[01:21] <TabAtkins_> glazou: Also HTML added new selectors, etc.

[01:21] <plh> (ie in 10 minutes)

[01:21] * Reinaldo has joined #css

[01:21] <TabAtkins_> glazou: PLH is also concerned about the TTA specs.

[01:22] <TabAtkins_> glazou: The length of time they're taking.

[01:22] * kensaku_ has joined #css

[01:22] <TabAtkins_> glazou: I tried to say that they were complex specs.

[01:22] <TabAtkins_> glazou: But they're already well interoperable.

[01:22] * plh will be in the css room at 9:30 for one agenda item

[01:22] * plh will come back after

[01:22] <TabAtkins_> Topic: Agenda

[01:22] * plh oop,s wrong channel

[01:22] <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0304.html

[01:22] <TabAtkins_> stearns: First issue is box generation.

[01:22] <TabAtkins_> stearns: I posted how I think this issue should be handled in the spec.

[01:23] <TabAtkins_> stearns: I don't think box generation is required for CSS regions.

[01:23] <TabAtkins_> stearns: The issue is how to handle more content than will fit in a fixed region chain.

[01:23] <TabAtkins_> stearns: We've added auto-height regions and the regions processing model to address this.

[01:23] <TabAtkins_> stearns: So handling more content in a region is the same as in any other element.

[01:23] <TabAtkins_> stearns: So I'd liketo close this issue.

[01:23] * kazutaka has joined #css

[01:23] * lmclister has joined #css

[01:23] <TabAtkins_> howcome: Examples?

[01:24] * dino has joined #css

[01:24] <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.

[01:24] <TabAtkins_> howcome: What about pagination?

[01:24] <TabAtkins_> stearns: No effect on printing - it'll break across pages just like a normal element.

[01:24] * kawabata has joined #css

[01:25] <TabAtkins_> stearns: I got one response on the list from Anton saying it was reasonable.

[01:25] <TabAtkins_> howcome: What dimensions does it expand?

[01:25] <TabAtkins_> stearns: Same as an auto-height div.

[01:26] <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.

[01:26] * sakih has joined #css

[01:26] <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.

[01:26] * yamaday has joined #css

[01:27] <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.

[01:27] <TabAtkins_> stearns: We could close this issue and let you raise further issues.

[01:28] <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?

[01:28] <TabAtkins_> stearns: Yes, that's what the processing model now addresses.

[01:28] * lstorset has joined #css

[01:28] * sakih is now known as sakkuru

[01:28] <TabAtkins_> RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary amounts of content in a region chain.

[01:29] <TabAtkins_> Rossen: can you swap css3-ui with something in the afternoon? I'm waiting for Tantek and Sylvain.

[01:29] <yamaday> join #css

[01:30] * hober yamaday: it worked!

[01:30] * divya notifies interested parties of #tpac on irc.w3.org

[01:31] * vhardy_ has joined #css

[01:32] * Liam|XMLCore Quit (Ping timeout: 60 seconds)

[01:32] <TabAtkins_> Topic: HTML & CSS

[01:32] <TabAtkins_> plh: HTML plans to move to CR by the end of the year.

[01:33] <TabAtkins_> plh: So if there are any concersn from the CSSWG, I'd like to get it now.

[01:33] <TabAtkins_> plh: Are there any issues from the CSSWG?

[01:33] <TabAtkins_> glazou: I have three issues.

[01:33] <TabAtkins_> glazou: The first is organization.

[01:33] <TabAtkins_> glazou: The liaison between html and css - there has been none.

[01:33] <TabAtkins_> glazou: The HTML spec concerns bits of CSS related to scoped stylesheets and selectors which were never discussed with us.

[01:34] <TabAtkins_> glazou: I call that a big issue, since the htmlwg charter contains a liaison with us.

[01:34] <TabAtkins_> glazou: Don't care what side the problem lies on, but it needs to be solved.

[01:34] <fantasai> s/liaison/mandatory liaison/

[01:34] <TabAtkins_> glazou: Second problem is technical.

[01:34] <TabAtkins_> glazou: The html spec contains scoped stylesheets.

[01:34] * SteveZ Quit (Ping timeout: 20 seconds)

[01:34] <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.

[01:35] <TabAtkins_> glazou: There's no material the html spec can reference normatively.

[01:35] <TabAtkins_> glazou: Third point is about CSS pseudoclasses.

[01:35] <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."

[01:36] <TabAtkins_> glazou: So it seems to me the process between the two WGs are completely broken.

[01:36] <TabAtkins_> glazou: We dont' have these issues with the SVGWG - we work together great.

[01:36] <TabAtkins_> glazou: So we have two things in the HTML spec that should be defined on our side.

[01:36] <dbaron> TabAtkins: On selectors, we've either defined everything or HTML is just defining the host language part of it

[01:37] <dbaron> TabAtkins: ... in cases where things are to be defined by the host language

[01:37] * vhardy__ has joined #css

[01:37] <TabAtkins_> plh: I like to understand if other people in the CSSWG share your opinions.

[01:37] * plh Quit (Ping timeout: 60 seconds)

[01:37] * mjs has joined #css

[01:37] <TabAtkins_> plh: And some of the CSSWG is in the HTMLWG, so if there's no liaison, I wonder what's oging on.

[01:38] <TabAtkins_> dbaron: We've been through the form control stuff before, but I agree with Tab that there's no problem there.

[01:38] <mjs> q+

[01:38] * Zakim sees mjs on the speaker queue

[01:38] <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.

[01:39] <stearns> TabAtkins_: Me will define

[01:39] <TabAtkins_> plh: Is <style scoped> handled properly in HTML?

[01:39] * yamaday Quit ("TakIRC")

[01:39] <TabAtkins_> fantasai: First thing is how selectors are scoped.

[01:39] <TabAtkins_> fantasai: Second is a mechanism to change how they're scoped.

[01:39] <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)

[01:40] <TabAtkins_> fantasai: Third is howt he cascade is scoped.

[01:40] <TabAtkins_> fantasai: The fourth is how globally scoped things like @font-face are handled.

[01:40] * Norbert has joined #css

[01:40] * yamaday has joined #css

[01:40] <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.

[01:41] <TabAtkins_> fantasai: Dunno about the second and fourth.

[01:41] * Liam|XMLCore has joined #css

[01:41] * sakkuru_ has joined #css

[01:41] <TabAtkins_> TabAtkins_: The fourth is defined in hTML now - Boris got it fixed.

[01:41] <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.

[01:41] * sakkuru Quit (Ping timeout: 20 seconds)

[01:41] <TabAtkins_> dbaron: I think we know about this - we don't need a formal email asking us to review it.

[01:42] <fantasai> dbaron: The interesting question is, is there anything else we're not aware of.

[01:42] <glazou> Zakim, ack mjs

[01:42] <Zakim> I see no one on the speaker queue

[01:43] <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.

[01:44] * TabAtkins_ Quit (Ping timeout: 20 seconds)

[01:44] * plh has joined #css

[01:44] <glazou> glazou: I think we do formal link between groups

[01:44] <plh> q?

[01:44] * Zakim sees no one on the speaker queue

[01:44] * TabAtkins_ has joined #css

[01:44] <glazou> mjs: this is first time I hear about these issues

[01:44] <glazou> glazou: no

[01:44] <fantasai> glazou: I sent them as LC comments during the vote

[01:44] <fantasai> glazou: Never got a reply

[01:45] <plh> q+ PaulCotton

[01:45] * Zakim sees PaulCotton on the speaker queue

[01:45] <fantasai> plinss: We sent comments last year as a WG, and the bug was closed WONTFIX by hixie

[01:45] <fantasai> mjs: We have a clear process for escalating issues

[01:45] <fantasai> mjs: We love technical input, but don't go out of our way to solicit it

[01:46] <fantasai> mjs invites CSSWG members to participate in HTMLWG meetings at TPAC

[01:47] <fantasai> mjs: Recently had change of editors, trying to be more open to input

[01:47] <glazou> Zakim, ack PaulCotton

[01:47] <Zakim> I see no one on the speaker queue

[01:47] <fantasai> PaulCotton: Want to be more factual here. What are the bug numbers raised on these issues?

[01:47] <fantasai> PaulCotton: What are the comments that were made for LC?

[01:48] <glazou> Zakim, q+

[01:48] <Zakim> I see glazou on the speaker queue

[01:48] <fantasai> PaulCotton: If there weren't issues raised as tracker issues, we don't pay attention to them.

[01:49] <fantasai> glazou: We discussed on HCG these issues

[01:49] <dbaron> plinss: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13693

[01:49] <fantasai> TabAtkins: Raised as email comments; you're not allowed to ignore those just because bug wasn't filed

[01:50] <fantasai> glazou: All the comments, through various channels were dismissed.

[01:50] * yamaday has left #css

[01:50] <dbaron> fantasai: I think there are three issues, 2 technical. I think selectors issue already addressed by selectors4.

[01:50] <dbaron> mjs: for record, bug doesn't mention scoped style sheets at all

[01:51] * yamaday has joined #css

[01:51] <dbaron> glazou: Then HTML is referencing a non-normative document (FPWD)

[01:51] <dbaron> plh: Where do you think selectors4 will be in 2014?

[01:51] <dbaron> fantasai: Probably last call or CR.

[01:51] <dbaron> glazou: maybe, maybe not

[01:51] <dbaron> fantasai: So that problem is solved as long as HTML correctly referencing selectors4.

[01:51] <dbaron> fantasai: Second issue is about scoped style, 4 sub-issues.

[01:52] <dbaron> ted: Already at-risk for HTML5.

[01:52] <dbaron> plh: I would ... the HTML WG to drop the feature and put in HTML.next.

[01:52] <dbaron> plh: Sounds too risky to keep in HTML 5.0.

[01:52] <dbaron> mjs: I'd like a record of the four issues.

[01:52] <dbaron> TabAtkins, fantasai: in minutes

[01:52] <plh> s/.../advocate/

[01:52] <dbaron> TabAtkins, fantasai: We should have a draft in the next month.

[01:53] <dbaron> fantasai: This is a complicated feature that ought to have a stable definition, not one writen 2 months before CR.

[01:53] <dbaron> dirk: ???

[01:53] <dbaron> fantasai: Third issue is the process issue.

[01:53] <dbaron> fantasai: Basically what's happening is that the CSS WG would like the HTML WG to take some initiative to contact us when defining things in the scope of our charter.

[01:53] <krit> s/???/Since we don't have one implementation, it may should not be in HTML5.0/

[01:53] <dbaron> fantasai: Whether HTML WG does this by assigning a task to common members or some other process. Fact is it hasn't happened.

[01:53] <dbaron> glazou: or an email

[01:54] <dbaron> PaulCotton: So in the last 2 years I've tried several times to get HTML WG to pay attention to progression of docs in other WGs.

[01:54] <dbaron> PaulCotton: As a co-chair it's pretty frustrating. I try to solicit input from HTML WG and get nothing.

[01:54] <dbaron> PaulCotton: Not even from members of other WG.

[01:54] <dbaron> q+

[01:54] * Zakim sees glazou, dbaron on the speaker queue

[01:54] <dbaron> PaulCotton: So the ??? hasn't worked in the past.

[01:54] <glazou> Zakim, ack glazou

[01:54] <Zakim> I see dbaron on the speaker queue

[01:54] <dbaron> PaulCotton: I think we probably need somebody on point here.

[01:55] <dbaron> PaulCotton: I think we need somebody to draw attention to these kinds of things.

[01:55] <dbaron> PaulCotton: We have new editors now.

[01:55] <glazou> Zakim, q+

[01:55] <Zakim> I see dbaron, glazou on the speaker queue

[01:55] <dbaron> PaulCotton: I think with new editors: bugs, interop problems, ... bring that to your attention.

[01:55] <glazou> Zakim, ack dbaron

[01:55] <Zakim> I see glazou on the speaker queue

[01:55] <dbaron> PaulCotton: I think the other route, bringing your (CSS) documents to attention of HTML WG isn't going to work.

[01:55] * hober thinks he can count the number of html5 editors who are in the csswg on one finger...

[01:55] <glazou> Zakim, q+ fantasai

[01:55] <Zakim> I see glazou, fantasai on the speaker queue

[01:56] <glazou> Zakim, q+ GlennAdams

[01:56] <Zakim> I see glazou, fantasai, GlennAdams on the speaker queue

[01:56] <TabAtkins_> dbaron: You probably heard me say this before, but I'm not a big fan of trying to make thing WG-to-WG communication.

[01:56] <fantasai> dbaron: You've probably heard me say this before, but I'm not a big fan of trying to make things WG-WG communication

[01:56] <TabAtkins_> dbaron: I think there is a lot of value in giving notice to WGs about things that are related.

[01:56] <TabAtkins_> dbaron: I don't see that the response needs to be from the WG as a whole.

[01:56] <TabAtkins_> dbaron: If there's consensus about a response, fine, it can be from the WG as a whole, but I don't worry about the whole-WG response.

[01:56] <glazou> Zakim, ack me

[01:56] <Zakim> I see fantasai, GlennAdams on the speaker queue

[01:56] <TabAtkins_> glazou: Paul, you say you'd like someone in your WG to coordinate and give us feedback.

[01:57] <TabAtkins_> glazou: I'd like the Chairs to do it. Taht's what we do - when SVG has something, Doug pings us. The chairs discuss things. It's informal, but it works well.

[01:57] <TabAtkins_> hober: In CSS/SVG, we have the FXTF to help discuss issues.

[01:57] <TabAtkins_> glazou: Even before that.

[01:57] <TabAtkins_> glazou: It's not hard. It's just a matter of person-to-person email. It's doable.

[01:57] <glazou> Zakim, ack fantasai

[01:57] <Zakim> I see GlennAdams on the speaker queue

[01:58] <TabAtkins_> fantasai: With regards to feedback on oru specs, our resp. is to ifnorm you of spec's we're writing that might affect HTML and it's interaction.

[01:58] <TabAtkins_> fantasai: I think we've done that, but please point out if we need to improve.

[01:58] <mjs> q+

[01:58] * Zakim sees GlennAdams, mjs on the speaker queue

[01:58] <TabAtkins_> fantasai: As for responses from the WG, doesn't matter. Individual WG members were informed, had the ability to respond, but it hasn't happened.

[01:58] <TabAtkins_> fantasai: The members of the CSSWG that aren't in the HTMLWG haven't been informed about thing sin HTML that affect CSS.

[01:59] <glazou> Zakim, ack GlennAdams

[01:59] <Zakim> I see mjs on the speaker queue

[01:59] <TabAtkins_> fantasai: In particular, HTML defines things that are fundamentally not in their charter.

[01:59] <TabAtkins_> fantasai: Which may be a bit over the line.

[01:59] * glenn has joined #css

[01:59] <glazou> Zakim, q+ PaulCotton

[01:59] <Zakim> I see mjs, PaulCotton on the speaker queue

[01:59] <TabAtkins_> glenn: In that regard, Hixie has been communicating with me about things that affect the CSSOM.

[01:59] <glazou> Zakim, ack mjs

[01:59] <Zakim> I see PaulCotton on the speaker queue

[02:00] <TabAtkins_> mjs: Can someone give me an example of a time that the CSSWG has informed the HTMLWG about a relevant spec change.

[02:00] <fantasai> TabAtkins_: element function in images spec, wanted to integrate with HTML in a particular way

[02:00] <fantasai> TabAtkins_: I sent an email into HTMLWG and hixie fixed it for me

[02:00] <fantasai> TabAtkins_: Done similar things with WebApps

[02:00] <glazou> Zakim, ack PaulCotton

[02:00] <Zakim> I see no one on the speaker queue

[02:01] <fantasai> PaulCotton: Hixie is no longer an editor in the HTMLWG

[02:01] <hober> I believe TabAtkins was referring to https://www.w3.org/Bugs/Public/show_bug.cgi?id=14028

[02:01] * SteveZ has joined #css

[02:01] <fantasai> PaulCotton: If you want to communicate wrt HTML5 spec, it's no longer hixie.

[02:02] <fantasai> PaulCotton: When wanting changes with CR, need to communicate with current editors, not hixie

[02:02] <glazou> Zakim, q+

[02:02] <Zakim> I see glazou on the speaker queue

[02:02] <fantasai> q+

[02:02] * Zakim sees glazou, fantasai on the speaker queue

[02:02] <fantasai> PaulCotton: Question was what happens to changes hixie makes

[02:02] <fantasai> PaulCotton: Our editors are triaging all of those changes

[02:02] <fantasai> PaulCotton: For changes that go into 5.1, we're previewing in WG

[02:02] <fantasai> PaulCotton: But editors in WG are about to produce CR drafts

[02:03] <fantasai> PaulCotton: Those CR drafts will be only changes that are interoperability-based

[02:03] <fantasai> PaulCotton: It's possible that change from WHATWG would make it into 5.1

[02:03] <fantasai> PaulCotton: Also possible that if it's an interop problem, it would get into 5.0

[02:03] <fantasai> PaulCotton: But not guaranteed

[02:03] <glazou> Zakim, ack me

[02:03] <Zakim> I see fantasai on the speaker queue

[02:04] <fantasai> glazou: Would like us to use HTCG a bit more for communication. You are three co-chairs, but rarely attend the calls

[02:04] <fantasai> glazou: I've been sending status reports for CSSWG even when I did not attend, and these include changes to our documents. Never triggered a reaction from you.

[02:04] <fantasai> glazou: When I said in HTCG that there were problems wrt scoped styles, there was no reaction from you.

[02:05] <fantasai> glazou: We have a tool in our hands.

[02:05] <fantasai> mjs: I find the coordination calls useless

[02:05] <fantasai> glazou: Then let's do that by email

[02:05] <fantasai> [HTCG doesn't have regular calls any more, just as needed]

[02:05] <dbaron> Present: (at table) Dean Jackson, Glenn Adams, Philippe Le Hegaret, Anton Prowse, Francois Remy, Rossen Atanassov, Simon Sapin, Lea Verou, Divya Manian, Tab Atkins, Luke MacPherson, Alan Stearns, Steve Zilles, Dirk Schultze, Bert Bos, Leif Arne Storset, Vincent Hardy, Paul Cotton, Daniel Glazman, Ted O'Connor, H��kon Lie, David Baron, Elika Etemad, Aaron Eicholz, Taichi Kawabata, Kazutaka Yamamoto, Koji Ishii, Peter Linss, Maciej Stachowiak

[02:06] <fantasai> glazou: We've had this communication channel for years; it hasn't been used.

[02:06] <glazou> Zakim, ack fantasai

[02:06] <Zakim> I see no one on the speaker queue

[02:06] <TabAtkins_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16169

[02:06] <TabAtkins_> fantasai: Maciej wanted examples of us contacting the HTMLWG about changes affecting them.

[02:06] <dbaron> Present (in back row): Rik Cabanier, ???, ???, Rebecca Hauck, ???, Israel Noto Garcia, Jet Villegas, ???, ???

[02:06] <TabAtkins_> fantasai: First, we don't include things within the scope of the HTML charter within our specs.

[02:06] * florianr has joined #css

[02:07] <TabAtkins_> fantasai: But for things where we think the HTMLWG could do a good review (such as Image Values or Selectors), we have explicitly pinged the HTMLWG for review.

[02:07] <stearns> dbaron: some ???s: Israel Noto Garcia, Laurence Mclister, Rik Cabanier

[02:07] <fantasai> mjs: How would you like us to inform you of changes we need in CSS? Filing a bug?

[02:08] <fantasai> TabAtkins: Send an email to www-style.

[02:08] <fantasai> mjs asks for example

[02:08] <fantasai> TabAtkins: The bugs I filed against HTML are examples

[02:08] <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?

[02:09] <TabAtkins_> fantasai: Hixie has sent us emails asking for specific changes in CSS specs, and that's exactly how it should be handled.

[02:09] <dbaron> fantasai: Hixie sent us some emails asking for changis in CSS specs; those were exactly how it should be handled.

[02:09] <plh> q?

[02:09] * Zakim sees no one on the speaker queue

[02:09] <dbaron> fantasai: What wasn't handled was saying that we drafted a new CSS feature and put it in HTML5 spec.

[02:09] <TabAtkins_> fantasai: What wasn't handled was something informing us of some of the CSS features in HTML being drafted at all. ^_^

[02:09] * dbaron lets TabAtkins continue minuting

[02:09] <TabAtkins_> mjs: So what do you need to continue technically to resolve any issues in HTML?

[02:10] <plh> q+

[02:10] * Zakim sees plh on the speaker queue

[02:10] <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.

[02:10] * jet has joined #CSS

[02:10] <TabAtkins_> mjs: But today we have four things being about it.

[02:10] <TabAtkins_> TabAtkins_: They're four ways of saying a specific thing is undefined.

[02:11] <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.

[02:11] <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.

[02:11] <TabAtkins_> glenn: Are there two interop impls?

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

[02:12] <hober> So, has someone filed a "Drop <style scoped>" bug?

[02:12] <TabAtkins_> glazou: It's so undefined, and will take long enough to do so, that it should be dropped.

[02:12] <TabAtkins_> mjs: If best solution turns out that it shoudl be dropped, that's fine.

[02:12] * tomoyuki Quit (tomoyuki)

[02:12] <TabAtkins_> mjs: But we need a bug and to be informed about this.

[02:13] <TabAtkins_> mjs: I've heard several rapid-fire problems listed today, but we need those details to be brought to us.

[02:14] <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

[02:14] <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

[02:14] <fantasai> TabAtkins_: The problem is well-known within HTMLWG

[02:14] <plh> q+ PaulCotton

[02:14] * Zakim sees plh, PaulCotton on the speaker queue

[02:15] <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

[02:15] <fantasai> glazou: Need to find compromise that satisfies everyone.

[02:15] * tomoyuki has joined #css

[02:15] <fantasai> glazou: And it's on our side, not on yours. It's about how the cascade works. Not in the HTML spec.

[02:15] <fantasai> glazou: Am I completely mistaken or what?

[02:16] * mjs Quit (mjs)

[02:16] * Liam|XMLCore Quit (Ping timeout: 60 seconds)

[02:16] <TabAtkins_> plh: It seems to me that we have information on the style scoped about whether to keep it or not.

[02:16] <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?

[02:17] <TabAtkins_> mjs: I don't think we have. You guys have told us multiple rapid-fire problems, but they haven't been listed.

[02:17] <plh> q?

[02:17] * Zakim sees plh, PaulCotton on the speaker queue

[02:17] <dbaron> q+

[02:17] * Zakim sees plh, PaulCotton, dbaron on the speaker queue

[02:17] <plh> ack plh

[02:17] * Zakim sees PaulCotton, dbaron on the speaker queue

[02:17] <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.

[02:17] <TabAtkins_> mjs: Okay, so what should we do specifically?

[02:17] <TabAtkins_> glazou: Drop it.

[02:17] <plh> q?

[02:17] * Zakim sees PaulCotton, dbaron on the speaker queue

[02:17] <TabAtkins_> mjs: Give us that feedback specifically. Send it in.

[02:17] <TabAtkins_> mjs: Please submit a comment to the HTMLWG saying that and giving rationale.

[02:18] <TabAtkins_> glazou: I've done that multiple times.

[02:18] <TabAtkins_> mjs: I looked up your comments, and you didn't actually say that.

[02:18] <TabAtkins_> glazou: PLH, do we really discuss inter-WG things via bugs only?

[02:18] <TabAtkins_> glazou: I don't understand why you need more input from us.

[02:19] * tomoyuki Quit (tomoyuki)

[02:20] <TabAtkins_> PaulCotton: I asked for exact comments. You pointed to a bug. It was closed, you didn't reopen.

[02:20] * evanli has joined #css

[02:20] <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.

[02:21] <TabAtkins_> mjs: If you're unwilling to engage in our process, then I won't help you.

[02:21] * dbaron q?

[02:21] * Zakim sees PaulCotton, dbaron on the speaker queue

[02:21] * fantasai doesn't understand why hober doesn't just file a bug so we can get on with it

[02:21] <plh> --> http://lists.w3.org/Archives/Public/public-html/2012May/0080.html email from Tab regarding scoped

[02:21] <dbaron> ack PaulCotton

[02:21] * Zakim sees dbaron on the speaker queue

[02:21] <TabAtkins_> PaulCotton: Idon't quite agree with Philippe about ???...

[02:21] <TabAtkins_> PaulCotton: This spec will be in CR for 18 months at least.

[02:21] * kensaku_ Quit (Client closed connection)

[02:22] * vhardy_ Quit (Ping timeout: 20 seconds)

[02:22] * vhardy__ is now known as vhardy_

[02:22] <TabAtkins_> PaulCotton: I think that marking it as at-risk with this evidence, is probably the right status.

[02:22] <divya> s/Philippe/macej

[02:22] <TabAtkins_> dbaron: I've been on the queue for 5 minutes to say that I disagree that dropping is the right thing. I'd rather see it stay for now.

[02:22] <TabAtkins_> dbaron: If you want a WG opinion, we need to take the time for that discussion. But I don't think right now is the right time for that discussion.

[02:22] <TabAtkins_> glenn: Agree. At-risk is easier than dropping and restoring.

[02:23] <TabAtkins_> mjs: It's at-risk right now. We can enhance our at-risk list with annotations for reasoning.

[02:23] <TabAtkins_> mjs: Getting dependencies right, getting implementors to implement, define it.

[02:23] * fantasai doesn't think the "at risk" list is the right place for "things we think are cool but don't have time to define correctly"

[02:24] * fantasai also doesn't understand why it's a problem to drop it here, given it'll still be in the HTML.next drafts that hixie edits

[02:24] * liam has joined #css

[02:25] <krit> Zakim, q+

[02:25] <Zakim> I see dbaron, krit on the speaker queue

[02:25] * dbaron q-

[02:25] * Zakim sees krit on the speaker queue

[02:26] <TabAtkins_> plh: Other issue is Selectors 4 having some of the HTML selectors.

[02:26] <plh> --> http://dev.w3.org/html5/spec/single-page.html#pseudo-classes

[02:26] <TabAtkins_> TabAtkins_: The ones in HTML right now are all just the host-language stuff. The real new things are in WebVTT.

[02:26] * fantasai is willing to bet that Selectors 4 will get to CR before HTML5 has enough testcases to actually test the spec

[02:26] <TabAtkins_> mjs: WebVTT is no longer a HTMLWG deliverable. It's in a CG.

[02:27] <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.

[02:27] * mjs has joined #css

[02:27] <Bert> q+ to mention another (some day) coord. issue: <DETAILS>

[02:27] * Zakim sees krit, Bert on the speaker queue

[02:27] <TabAtkins_> hober: Right now we're trying to remove/drop things, not add.

[02:27] <TabAtkins_> plh: But in HTML.next, if ever there is something new added, tell the CSSWG.

[02:27] * mjs Quit (mjs)

[02:28] <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.

[02:28] <TabAtkins_> mjs: In the past when stuff got put into the spec, I'll be honest and say it was largely editor recalcitrance.

[02:28] * Rossen Quit (Ping timeout: 20 seconds)

[02:28] * Rossen has joined #css

[02:29] <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.

[02:29] <TabAtkins_> plh: Feel free to bring that up in our meeting Thu/Fri.

[02:30] * divya Quit ("Leaving.")

[02:30] <dbaron> break-duration: calc(15 * 60s)

[02:30] * Reinaldo Quit (Ping timeout: 20 seconds)

[02:31] <Bert> q-

[02:31] * Zakim sees krit on the speaker queue

[02:31] <TabAtkins_> zakim, ack krit

[02:31] <Zakim> I see no one on the speaker queue

[02:32] * tomoyuki has joined #css

[02:32] * lmclister Quit (Ping timeout: 20 seconds)

[02:32] * rhauck Quit ("Leaving.")

[02:32] * lstorset Quit (Ping timeout: 20 seconds)

[02:33] * Norbert Quit (Ping timeout: 20 seconds)

[02:33] * kawabata Quit (Ping timeout: 20 seconds)

[02:34] * tomoyuki Quit (Ping timeout: 20 seconds)

[02:35] * cabanier Quit ("Leaving.")

[02:36] * yaso has joined #css

[02:36] * rubylin has joined #css

[02:37] * tomoyuki has joined #css

[02:40] * kotakagi has joined #css

[02:41] * vhardy__ has joined #css

[02:43] * tomoyuki Quit (tomoyuki)

[02:46] * sakkuru_ Quit (Ping timeout: 20 seconds)

[02:47] * yamaday Quit ("TakIRC")

[02:48] * yamaday has joined #css

[02:49] * yamaday Quit (Client closed connection)

[02:49] * yamaday has joined #css

[02:50] * yaso Quit (yaso)

[02:52] * mgylling Quit (mgylling)

[02:53] * tomoyuki has joined #css

[02:53] <yamaday> aaaaaaaaaaa

[02:56] * JohnJansen Quit ("Page closed")

[02:56] * John_Jansen has joined #css

[02:57] * vhardy__ Quit (vhardy__)

[02:57] * TabAtkins_ Quit (Ping timeout: 20 seconds)

[02:58] * yamaday Quit (Ping timeout: 20 seconds)

[02:58] * kotakagi Quit (Ping timeout: 20 seconds)

[02:59] * John_Jansen Quit ("")

[02:59] * rhauck has joined #css

[03:00] * JohnJansen has joined #css

[03:01] * kotakagi has joined #css

[03:01] * yamaday has joined #css

[03:01] * drublic has joined #css

[03:01] * Rossen Quit (Ping timeout: 20 seconds)

[03:03] * rhauck Quit (Ping timeout: 20 seconds)

[03:04] * lmclister has joined #css

[03:05] * tomoyuki Quit (tomoyuki)

[03:05] * rhauck has joined #css

[03:05] * liam Quit (Ping timeout: 60 seconds)

[03:07] * yamaday Quit ("TakIRC")

[03:07] * yamaday has joined #css

[03:10] * tomoyuki has joined #css

[03:11] * mgylling has joined #css

[03:13] * cabanier has joined #css

[03:14] * TabAtkins_ has joined #css

[03:14] * mjs has joined #css

[03:14] <dbaron> </br>

[03:14] <dbaron> Topic: Regions issues

[03:15] <dbaron> Alan: 3 issues left

[03:15] * divya has joined #css

[03:15] * sylvaing is now known as sylvaing_away

[03:15] <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.

[03:15] * tomoyuki Quit (Client closed connection)

[03:15] <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.

[03:16] * Rossen has joined #css

[03:16] <TabAtkins_> stearns: Same justification for those applies to Regions. Little case for interleaving content.

[03:16] <TabAtkins_> dbaron: Floats actually create a pseudo-stacking context.

[03:16] <TabAtkins_> antonp: I don't think authors like stacking contexts.

[03:17] <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.

[03:17] <TabAtkins_> hober: Will probably result in performance issue, which we can avoid...

[03:17] <TabAtkins_> hober: I don't think authors would interleave on purpose.

[03:17] <TabAtkins_> antonp: The reason the funny painting model exists is because people had overflow they weren't expecting; floats and next paragraphs and etc.

[03:17] <TabAtkins_> antonp: That's why text is painted after all background/borders/etc.

[03:17] * Norbert_ has joined #css

[03:17] <TabAtkins_> antonp: Makes overlaps less painful.

[03:18] <TabAtkins_> antonp: So it was historically because there was a lot of overflow, and impls thought it was better to see content.

[03:18] <TabAtkins_> dbaron: I'm not sure it was that logical of a process.

[03:18] <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.

[03:18] <TabAtkins_> dbaron: Never really learned how much of that was intentional.

[03:19] <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.

[03:19] <TabAtkins_> dbaron: The thing I'm slightly worried about is...

[03:19] <TabAtkins_> dbaron: You're talking a region being a stacking context?

[03:19] <TabAtkins_> dbaron: Each region?

[03:20] <TabAtkins_> stearns: Each region is a context for the fragment of the flow in it.

[03:20] <TabAtkins_> dbaron: My problem is when people put regions close to each other to give the illusion of continuous flow

[03:20] <TabAtkins_> TabAtkins_: Like using them to make a "non-rectangular grid cell".

[03:20] <TabAtkins_> dbaron: yeah. But I think there might be weird issues now.

[03:21] <TabAtkins_> stearns: That's only a problem if they break outside of the bounds of the region.

[03:21] <TabAtkins_> dbaron: Not necessarily rare, with text slightly overflowing, etc.

[03:21] <TabAtkins_> dbaron: Don't have a strong opinion, but I'ma little worriedabout that case.

[03:21] <TabAtkins_> stearns: I'm not really sure what to do about that case.

[03:21] * rotsuya has joined #css

[03:21] <stearns> s/to do/to say/

[03:22] * kensaku has joined #css

[03:22] <TabAtkins_> Rossen: No real opinion...

[03:22] <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.

[03:22] <TabAtkins_> Rossen: The one David is bringing up is somewhat valid for the content being laid out between the regions themselves.

[03:22] * sakkuru has joined #css

[03:22] * toms has joined #css

[03:22] <TabAtkins_> Rossen: It is more interesting to see how the rest of the content outside the regions interacts with the content inside.

[03:23] * sylvaing_away is now known as sylvaing

[03:23] <TabAtkins_> Rossen: This is why we'd prefer regions being their own stacking context.

[03:23] <TabAtkins_> Rossen: So you don't have weird interleaving between parts of the regions.

[03:23] * hsivonen has joined #css

[03:23] <TabAtkins_> antonp: I buy that point.

[03:24] <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.

[03:24] * florianr Quit ("")

[03:24] <TabAtkins_> antonp: What about a pseudo-stacking context, so abspos doesn't have to deal with it?

[03:24] * yamaday Quit (Client closed connection)

[03:25] <TabAtkins_> TabAtkins_: I think that limiting abspos is actually an important part of it.

[03:25] * yamaday has joined #css

[03:25] <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.

[03:25] <TabAtkins_> szilles: Conceivably one could introduce a similar property that groups things like that.

[03:26] <TabAtkins_> TabAtkins_: Like explicitly turning on stacking contexts without side effects?

[03:26] <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.

[03:26] <TabAtkins_> Rossen: To add to this, it becomes more apparent once you bring content that's not quite in the same document into regions.

[03:27] <TabAtkins_> Rossen: Then you have content from separate documents that can interleave.

[03:27] <TabAtkins_> TabAtkins_: You're talking about IE's addition that lets them flow iframes into a region flow?

[03:27] * hober runs screaming from the room (re: region flow sourced from <iframe>)

[03:27] <Bert> q+ to compare regions with columns

[03:27] * Zakim sees Bert on the speaker queue

[03:27] <TabAtkins_> Rossen: Yeah. You don't want an iframe to be interleaved with anything else.

[03:27] <TabAtkins_> antonp: At the very least that says you want pseudo-stacking contexts. It doesnt' necessarily talk about abspos.

[03:28] <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.

[03:28] <TabAtkins_> antonp: By locking it into the region box, it seems you're taking away a little of the freedom they otherwise have.

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

[03:29] <TabAtkins_> Bert: That loses the auto position, though.

[03:29] * tomoyuki has joined #css

[03:29] <TabAtkins_> TabAtkins_: If you're usign the auto position, you probably don't need to worry about stacking context.

[03:30] <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.

[03:30] <TabAtkins_> Bert: That means that I'd like them to act like columns.

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

[03:31] <TabAtkins_> Bert: Point is that I'd like columns to act the same way as regions.

[03:31] <TabAtkins_> stearns: So that's an argument for Steve's suggestion - the ability to group contexts together.

[03:32] <TabAtkins_> dbaron: So you say that having flow-from on an element makes it a stackign context automatically?

[03:32] <TabAtkins_> stearns: yes, that's part of the spec right now.

[03:32] * yaso has joined #css

[03:32] <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.

[03:32] <TabAtkins_> stearns: Possibly with a future mechanism to aggregate stacking contexts.

[03:33] <TabAtkins_> TabAtkins_: I'm cool with that. I just don't want automatic grouping, from a performance standpoint.

[03:33] <TabAtkins_> stearns: Hyatt's doing some work with identical regions, which might be relevant there.

[03:33] <TabAtkins_> stearns: So, are there any objections to keeping what the spec currently says?

[03:34] <TabAtkins_> stearns: (i was arguing for the opposite position in my team, and I lost the argument)

[03:35] <TabAtkins_> Bert: It doesn't sound quite right - it's like an implicit relpos, which limits what you can do with abspos.

[03:35] * plh Quit (Ping timeout: 60 seconds)

[03:35] <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.

[03:36] <TabAtkins_> antonp: Bear in mind that we're not just talking about positioning, but also painting.

[03:36] <TabAtkins_> antonp: If in the future we're going to let you throw your positioning root around, you're also changing positioning.

[03:36] <TabAtkins_> s/changing positioning/changing painting/

[03:36] <TabAtkins_> TabAtkins_: yeah, you're more or less moving it in the box tree.

[03:37] <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?

[03:37] * kotakagi Quit (Ping timeout: 20 seconds)

[03:38] <TabAtkins_> antonp: To be fair, you'll have different behavior anyway - the fragmentation is probably going to be different anyway.

[03:38] <TabAtkins_> Rossen: Currently in shapes there's nothing taklinga bout this.

[03:38] <TabAtkins_> Rossen: In the multishapes section, we're allowing multishapes.

[03:38] <TabAtkins_> Rossen: Like if you extract a shape from an image, and it creates two circles.

[03:39] <TabAtkins_> Rossen: The spec currently says its allowed, but doesn't define how it works.

[03:39] <TabAtkins_> Rossen: Making a comparison based on that right now is a bit premature imo.

[03:39] <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.

[03:40] <TabAtkins_> Bert: So I thought that if they were so similar, they should perhaps all be the same.

[03:40] <TabAtkins_> Bert: With their own possibilities, but the common elements should be the same.

[03:40] <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.

[03:40] <TabAtkins_> stearns: That seems like a tiny edge-case for me. You generally avoid overlap.

[03:40] * cox_ has joined #css

[03:41] <TabAtkins_> Bert: I was thinking about abspos, actually.

[03:41] <TabAtkins_> Bert: But I'm not sure how important it really is. I generally use abspos only as a last resort.

[03:41] <TabAtkins_> stearns: It's certainly a limitation, and that's why I argued against it with my team.

[03:41] <TabAtkins_> stearns: But finding use-cases where you want interleaved content...

[03:41] * kotakagi has joined #css

[03:41] * plh has joined #css

[03:41] * kotakagi2 has joined #css

[03:41] * liam has joined #css

[03:41] <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.

[03:43] <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.

[03:43] <TabAtkins_> antonp: So are columns changing any?

[03:43] <TabAtkins_> stearns: No.

[03:43] <TabAtkins_> szilles: You'd need later to define that the stacking-context-grouping property auto-groups columns by default.

[03:44] <TabAtkins_> arronei: Does it become a stacking context as soon as flow-from is set, even if it has no content?

[03:44] <TabAtkins_> stearns: Yes, but then there's no content to be stacking-contexted.

[03:44] * r12a has joined #css

[03:44] <TabAtkins_> antonp: There was a comment from Hyatt about how content that flows through a region physically belong to the region.

[03:44] <fantasai> r12a: http://wiki.csswg.org/topics/custom-ident-case-sensitivity

[03:44] <TabAtkins_> antonp: Is this true, or does the content just flow through the space of the region?

[03:45] * r12a tx fantasai

[03:45] <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.

[03:45] <TabAtkins_> antonp: Hyatt has said that would significantly complicate his implementation.

[03:45] <TabAtkins_> stearns: He's gone back and forth on the issue. Not sure where he is on the issue right now.

[03:46] <TabAtkins_> Rossen: I'm having a little trouble understanding what "physically belongs to" means.

[03:46] <TabAtkins_> Rossen: Our model so far is that content flows through the region, and the regions are little viewports through which you view the content.

[03:46] <TabAtkins_> Rossen: As you interact with the region, you change how much content is in each region.

[03:46] <TabAtkins_> Rossen: But that doesn't mean actually changing the content in the document.

[03:46] <TabAtkins_> Rossen: That complicates region styling.

[03:47] <TabAtkins_> Rossen: Region styling has proven to be complicated for that reason.

[03:48] * vhardy__ has joined #css

[03:49] <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?

[03:49] <TabAtkins_> Rossen: The former (though it's complicated).

[03:49] * cabanier Quit ("Leaving.")

[03:49] * kotakagi2 Quit (Client closed connection)

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

[03:50] * kotakagi Quit (Ping timeout: 20 seconds)

[03:50] <TabAtkins_> Bert: Is this similar to the relationship between lineboxes and inline content?

[03:50] <TabAtkins_> TabAtkins_: Yes, very similar.

[03:51] <TabAtkins_> stearns: Especially given the connection with styling ::first-line. Same exact problem as region styling.

[03:52] <TabAtkins_> stearns: So back to the issue at hand - stacking contexts. Yay/nay?

[03:52] <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.

[03:53] <TabAtkins_> Rossen: I don't think performance is a strong reason to make a decision either way.

[03:53] <TabAtkins_> TabAtkins_: yeah, not strong, but an input.

[03:53] <TabAtkins_> Rossen: Right. I'm hearing, though, that some impls prefer it for performance reasons, and some don't care.

[03:53] <TabAtkins_> RESOLVED: bug 15824 - keep the current spec text, where regions all create stackign contexts for the stuff flowed into them.

[03:54] <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858

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

[03:54] <TabAtkins_> stearns: Should creation of regions from elements be disallowed?

[03:54] <TabAtkins_> stearns: This came up about a year ago.

[03:54] <TabAtkins_> stearns: I think there's a good reason to have this.

[03:54] <TabAtkins_> stearns: It can inherit part of the structure of your document.

[03:55] <TabAtkins_> stearns: Particularly for scripting/events.

[03:55] * cabanier has joined #css

[03:55] <TabAtkins_> stearns: I think we should have the ability to flow it into css-created boxes, but we shouldn't disallow it.

[03:56] * virginie has joined #css

[03:57] <TabAtkins_> TabAtkins_: This is completely the issue I was taklign about yesterday, with changing over to dbaron's proposal.

[03:57] * lstorset has joined #css

[03:57] * lstorset Quit ("Leaving.")

[03:57] * lstorset has joined #css

[03:58] <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.

[03:58] <TabAtkins_> TabAtkins_: I'm fine with that.

[03:58] * kotakagi has joined #css

[03:58] <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.

[03:59] <TabAtkins_> stearns: There's an example by implication in note 3 about how you don't necessarily have to use dummy elements.

[04:00] <dbaron> howcome: ...

[04:00] <divya> TabAtkins: we dont need to handle eventing on pseudo-elements

[04:00] <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

[04:00] <stearns> http://wiki.csswg.org/spec/css3-regions/regions-use-cases#converting-hard-breaks-to-named-flows

[04:00] <divya> TabAtkins: if we go with dbaron's proposal we will still have ���

[04:00] <divya> howcome: if we need the DOM thing, then put up a proposal for that.

[04:01] <divya> glazou: you raised a problem then why dont you do it?

[04:01] * vhardy__ Quit (vhardy__)

[04:01] <divya> howcome: I dont have dom issue.

[04:01] <divya> glazou: this is lower in priority.

[04:01] <divya> glazou: i am just saying people like regions given ���

[04:01] <divya> 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.

[04:01] <divya> TabAtkins: i use dummy html as wrappers all the time, it is going to be necessary sometimes

[04:02] <divya> howcome: you are creating a separate structure next to content structure

[04:02] <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

[04:02] <dbaron> (Tab also said something unminuted after the "howcome: ...")

[04:02] <divya> stearns: one of the args against ��� is that you are reinventing html in css

[04:03] <divya> glazou: when you do TOCs and extract them, you do want elements.

[04:03] * cox_ Quit (Ping timeout: 20 seconds)

[04:03] * fantasai suggests adopting XSLT as a solution this ;)

[04:03] <divya> stearns: it is quite similar to what is being done in SHADOW DOM

[04:03] <Bert> (HTML could add a <toc> element.)

[04: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.

[04:03] * liam \o/ XSLT

[04:04] <divya> TabAtkins: the point of shadow dom is recognizing that you need dummy elements and taking them from the main flow.

[04:04] <divya> stearns: in MS you have two separate html documents you have content and vi���

[04:05] <divya> howcome: i dont think you can make the argument that they are semantic

[04:05] <divya> howcome: we need representation of visual structure, we should not abuse html documents for that.

[04:05] <divya> stevezilles: i am sorry visual structure is semantic

[04:05] <divya> TabAtkins: philosophically opposed but not practically opposed

[04:05] <Bert> q+ to say using an external (XML) document for the visual structure is a different case again, and OK

[04:05] * Zakim sees Bert on the speaker queue

[04:06] <divya> howcome: building on what you said, if we agree on going david's way we should do that.

[04:06] <divya> TabAtkins: within option b lets not screw around and allow that, as it is required for regions proposal to work well.

[04:06] <divya> howcome: it is not well defined if it requires html

[04:06] <divya> [lots of arguments]

[04:07] <divya> glazou: authors already use elements for layouts.

[04:07] <divya> glazou: they will continue to do it

[04:07] <divya> TabAtkins: my arg is what stearns suggests is improv over what we have right now.

[04:08] <divya> TabAtkins: you would have to explicitly break contents between the elements right now.

[04:08] <divya> TabAtkins: you have same divs sitting around, but you get better semantics with the content and more reliable styling.

[04:08] <divya> howcome: as soon as you change the font size.

[04:09] <divya> dbaron: assuming people will do things in the same proportion to they do things right now.

[04:09] <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

[04:09] <fantasai> dbaron: But this will change the rate at which people do such things.

[04:09] * divya fantasai would you like to take over

[04:09] * fantasai not really :)

[04:09] * divya has lost a few seconds

[04:09] * fantasai but could if you want

[04:09] * fantasai doesn't think anything was lost, it's in the minutes from February

[04:09] <fantasai> ;P

[04:09] * divya hahahhaa

[04:10] <divya> TabAtkins: if we are selecting columns you are using pseudo elements

[04:10] * Jirka has joined #css

[04:10] <divya> TabAtkins: there is no reason to cripple the alternative right now.

[04:10] * rotsuya Quit (Client closed connection)

[04:10] <divya> TabAtkins: if we dont need it then stop caring about it.

[04:11] <divya> glazou: all specs rely on implementation in the long run, if we dont have 2 impl. then it would go away.

[04:12] <divya> steve zilles: people being forced to divide content to make it look like what it looks like.

[04:12] <divya> steve zilles: you have restructured it in a form that defeats accessible access

[04:12] <divya> steve zilles: you want to show content for different devices and you cant do it.

[04:12] <glazou> Zakim, q+

[04:12] <Zakim> I see Bert, glazou on the speaker queue

[04:12] * rubylin Quit (Ping timeout: 20 seconds)

[04:13] <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

[04:13] <TabAtkins_> howcome: I think the page template proposal is much more sensible in that regard.

[04:13] <TabAtkins_> szilles: In that case regions would end up with addressable things - we'd get CSSOM access to them.

[04:14] <TabAtkins_> stearns: The OM stuff is in a separate spec entirely - the pseudo spec Daniel and I are doing.

[04:14] * rubylin has joined #css

[04:14] <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.

[04:15] <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.

[04:15] <TabAtkins_> szilles: You can come up with a few simple rules, but they dont' generalize right now.

[04:15] <Bert> zakim, ack me

[04:15] <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

[04:15] <TabAtkins_> Bert: Two remakrs.

[04:15] <Zakim> I see glazou on the speaker queue

[04:15] * plh Quit ("always accept cookies")

[04:15] <TabAtkins_> Bert: I've been watiing for regions for 15+ years.

[04:15] <TabAtkins_> Bert: If we're waiting for events to be defined on them, cool, let's do that. If it takes a year, okay.

[04:16] * leaverou Apologies, I have to leave a bit early

[04:16] * shepazu Quit ("is sleepy")

[04:16] <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.

[04:17] * leaverou is now known as leaverou_away

[04:17] <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.

[04:17] <glazou> Zakim, ack me

[04:17] <Zakim> I see no one on the speaker queue

[04:17] <TabAtkins_> stearns: Either way, they're separated from the meaningful HTML.

[04:17] * sylvaing "CSS Regions: they work in practice but fail in theory"

[04:17] <TabAtkins_> glazou: I was speaking at the Paris Web Conf last week.

[04:17] <TabAtkins_> glazou: I demoed Regions and other things, and people came to the end of my talk.

[04:18] <dbaron> q+

[04:18] * Zakim sees dbaron on the speaker queue

[04:19] <TabAtkins_> glazou: they said pseudos were bad because screen-readers dont' read pseudos.

[04:19] * rubylin Quit ("")

[04:19] <TabAtkins_> TabAtkins_: I think they misunderstand. The real content will still be in the DOM, in a single element.

[04:19] <dbaron> q-

[04:19] * Zakim sees no one on the speaker queue

[04:19] <TabAtkins_> stearns: By the time you get to the reader, you're not looking quite at the DOM.

[04:20] <TabAtkins_> TabAtkins_: Not quite - they vary. You usually get an accessibility tree, which is an expanded version of the DOM.

[04:20] * hober picked the best seat

[04:20] <TabAtkins_> howcome: If pseudos dont' work, then why don't multicol work? They're pseudos too.

[04:20] <TabAtkins_> dbaron: There's a long-standing problem with people trying to put *content* into the pseudos, rather than in the document.

[04:20] * shepazu has joined #css

[04:20] * tomoyuki Quit (Client closed connection)

[04:21] <dbaron> dbaron: ... ...

[04:21] <dbaron> TabAtkins: If that's a problem then we also need to throw away flexbox and grid for the same reason.

[04:21] <dbaron> TabAtkins: If people have learned that putting content in pseduos in bad, they'll interpret what you say as the same bad thing.

[04:21] <dbaron> TabAtkins: I think their concern is actually mistaken.

[04:21] <antonp> +!

[04:21] * Zakim wonders where ! is

[04:21] <antonp> +1

[04:21] <dbaron> glazou: Let's take a flow that ...

[04:22] <dbaron> glazou: The voice reador should say "moving from one column to ..."

[04:22] <dbaron> ?: why?

[04:22] * mjs Quit (mjs)

[04:22] <dbaron> TabAtkins: Regions encourages you to have a semantically whole pice of your content even if it's split visually.

[04:22] * leaverou_away is now known as leaverou

[04:22] * evanli Quit (Ping timeout: 20 seconds)

[04:22] <dbaron> TabAtkins: Accessibility could be better in general when display order is different from source order.

[04:22] <dbaron> glazou: I was just reporting what I heard

[04:23] <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.

[04:23] <TabAtkins_> stearns: The next thing is quick.

[04:23] <TabAtkins_> stearns: I think it was resolved yesterday.

[04:23] <TabAtkins_> stearns: How the regions specification defines the first region box as the ICB of the named flow.

[04:24] <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...

[04:24] <TabAtkins_> stearns: I think regions just needs to follow what is going on in pages.

[04:25] <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.

[04:25] <fantasai> fragmentaining block!

[04:26] * sylvaing fragmentaining block party!

[04:26] * divya now occurring @ Saint Clair 3A

[04:27] <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.

[04:27] * dbaron hopefully not like the sort that happened near where I live in SF a few hours ago

[04:27] * Bert : As long as "leaving the issue in the spec" doesn't mean: "we'll ask at every meeting until thee's meeting with so few people that we can officially decide to do it anyway."

[04:28] <TabAtkins_> RESOLVED: What Tab said immediately above about ICB/FCB

[04:28] * Norbert_ Quit (Ping timeout: 20 seconds)

[04:29] <dbaron> Topic: Multicol

[04:29] <TabAtkins_> Topic: multicol sizing

[04:29] <dbaron> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm

[04:29] <TabAtkins_> fantasai: The proposal is to replace the "available width" and "shrink-to-fit" variables with just "used width".

[04:29] * lmclister Quit (Ping timeout: 20 seconds)

[04:30] <TabAtkins_> fantasai: And remove lines 3-10 of the pseudo-algo and just swap out refs for "used width".

[04:30] <TabAtkins_> fantasai: Where used width is defined by referenced formulas.

[04:30] <TabAtkins_> howcome: We presume when used width is handled, so we're shuffling where things are done.

[04:30] * rhauck Quit (Ping timeout: 20 seconds)

[04:31] <TabAtkins_> howcome: So it's a simplification of multicol, and it doesn't make a compliant impl non-compliant, so I don't have a problem with it.

[04:31] <TabAtkins_> howcome: [something about min and max width]

[04:31] <TabAtkins_> fantasai: That's contained in "used width". It's the result of all the computations about what the width is going to be.

[04:31] <TabAtkins_> howcome: It seems you've been wanting to have a discussion about min-width in this spec, but maybe I'm wrong.

[04:32] * kawabata has joined #css

[04:32] <TabAtkins_> SimonSapin: When is the available width unknown?

[04:32] <TabAtkins_> SimonSapin: The spec has one example - in floats.

[04:32] <TabAtkins_> SimonSapin: but that's no longer unknown, and it's defined in Sizing.

[04:32] <TabAtkins_> howcome: So no other changes, just these removals/swaps? No additional complexities?

[04:32] * hober gnaws own arm off.

[04:32] * shepazu Quit ("is sleepy")

[04:32] <TabAtkins_> Bert: I'm not completely clear on what the change is.

[04:33] <TabAtkins_> fantasai: The available width is always known.

[04:33] <TabAtkins_> dbaron: You're removing the stuff about shrink-to-fit into Sizing, so for the purposeof this spec, available width is always known.

[04:33] * kotakagi Quit (Ping timeout: 20 seconds)

[04:33] <dbaron> fantasai, ...: yes

[04:33] <TabAtkins_> fantasai: Right, becasue this spec isn't defining things well enough, and we shouldn't be dealing with this stuff in this CR right now.

[04:34] <TabAtkins_> SimonSapin: In 2.1, what we call available width is based on containing block, but in here it's not the same.

[04:34] <TabAtkins_> howcome: Right, that's confusing.

[04:34] <TabAtkins_> Rossen: Another is the "used width", which in 2.1 terms is the final width, can still change here afterwards.

[04:34] <TabAtkins_> Rossen: If you came in with width:auto and have a column-count, it can still change here.

[04:35] <TabAtkins_> Rossen: So you're either oging to have a complete used-width spec somewhere else, and thus yank out these two usages.

[04:35] <TabAtkins_> Rossen: or redefine shrink-to-fit elsewhere and don't call it used width here.

[04:35] <TabAtkins_> fantasai: The sizing spec defines the used width (in conjunction with 2.1).

[04:35] <TabAtkins_> fantasai: The purpose of this algo is not to figure out the width of the element, but to figure out how many columns and how wide they are.

[04:35] <TabAtkins_> fantasai: So we can assume that we've already figured out the width.

[04:36] <TabAtkins_> Bert: but you need that information to figure out the width.

[04:36] <TabAtkins_> TabAtkins: Right, you do use that in Sizing to figure out the width.

[04:36] <TabAtkins_> Bert: So all that happens *before* you figure out the intrinsic size.

[04:37] * mgylling Quit (mgylling)

[04:37] <TabAtkins_> fantasai: It's more complicated. [summarizes the shrink-to-fit algo in Sizing]

[04:37] <TabAtkins_> fantasai: So this formula in multicol is technically wrong - it overflows when unnecessary in some cases.

[04:37] * yaso Quit (yaso)

[04:38] <TabAtkins_> howcome: It's not *wrong*, but it might not be what you want.

[04:38] * kensaku Quit (Client closed connection)

[04:38] * r12a Quit ()

[04:39] <fantasai> http://dev.w3.org/csswg/css3-sizing/

[04:39] <TabAtkins_> TabAtkins: Lines 5-8 aren't great. Sizing defines a slightly better definition that doesn't overflow as often.

[04:40] <TabAtkins_> fantasai: Because this definition is a bit complicated, I don't think this CR (multicol) is the right place to deal with this.

[04:40] * florianr has joined #css

[04:40] <TabAtkins_> glazou: We brought this up weeks ago, and deferred it to the f2f to resolve on it.

[04:40] <SimonSapin> q+

[04:40] * Zakim sees SimonSapin on the speaker queue

[04:40] <TabAtkins_> howcome: I agree we should kill lines 9-10.

[04:41] * oyvind has joined #css

[04:41] <TabAtkins_> howcome: I don't think we need to remove lines 3-4, seems like useful information.

[04:41] <TabAtkins_> howcome: 5-8 gives *a* definition, even if it's not ideal.

[04:41] <TabAtkins_> TabAtkins: We should kill it if we know we have a better definition, which we do in Sizing.

[04:42] <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.

[04:43] <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

[04:43] <TabAtkins_> Bert: But that's in a float situation. I asked for column counta nd width, shouldn't i get it?

[04:43] <TabAtkins_> TabAtkins: Floats dont' overflow their containing block unless absolutely necessary. Our better definition tweaks things if necessary to maintain that invariant.

[04:44] <TabAtkins_> SimonSapin: Importantly, what does "unknown width" actually mean?

[04:44] <TabAtkins_> 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".

[04:45] <TabAtkins_> dbaron: I think Simon's proposal is takign the first.

[04:45] <dbaron> I think

[04:45] <TabAtkins_> glazou: It seems that some work has to be done on this in any way, because some definitions are missing or unclear.

[04:45] * virginie Quit (Ping timeout: 20 seconds)

[04:45] <TabAtkins_> fantasai: Yes. So we should not be leaving these in the spec. We should pull them out and let Sizing define it.

[04:46] <dbaron> dbaron: I think we should take the proposal, and raise further issues as they come up.

[04:47] <TabAtkins_> glazou: Straw poll, 6 for, 1 against, many abstain/undecided

[04:47] <TabAtkins_> glazou: Those who are undecided, can you trust the group?

[04:47] <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

[04:47] <TabAtkins_> Rossen: There seems to be some conflicting terminology. It seems to be complicated.

[04:48] <TabAtkins_> Rossen: I'm interested in resolving this in favor of Sizing. I just want to minimize damage on this spec.

[04:49] <TabAtkins_> glazou: Okay, so discuss before tomorrow evening, and we will resolve. Otherwise, deferred.

[04:49] * glazou Quit (glazou)

[04:49] * divya Quit ("Leaving.")

[04:50] <dbaron> lunch break until 2pm

[04:50] * dbaron Quit ("8403864 bytes have been tenured, next gc will be global.")

[04:50] * stearns Quit (stearns)

[04:50] * yamaday Quit ("TakIRC")

[04:50] * dino Quit (dino)

[04:50] * franremy Quit (Ping timeout: 20 seconds)

[04:50] * kawabata Quit (Ping timeout: 20 seconds)

[04:50] * arronei Quit (Ping timeout: 20 seconds)

[04:51] * kensaku has joined #css

[04:51] * lstorset Quit (Ping timeout: 20 seconds)

[04:51] * Rossen Quit (Ping timeout: 20 seconds)

[04:51] * SimonSapin Quit (Ping timeout: 20 seconds)

[04:51] * sakkuru Quit (Ping timeout: 20 seconds)

[04:51] * antonp Quit (Ping timeout: 20 seconds)

[04:52] * krit Quit ("Leaving.")

[04:52] * cabanier Quit ("Leaving.")

[04:52] * SteveZ Quit (Ping timeout: 20 seconds)

[04:52] * jet Quit (jet)

[04:54] * kensaku Quit (Client closed connection)

[04:55] * TabAtkins_ Quit (Ping timeout: 20 seconds)

[04:56] * tomoyuki has joined #css

[04:57] * sylvaing is now known as sylvaing_away

[04:58] * Jirka Quit (Jirka)

[04:59] * krijnh Quit (Ping timeout: 20 seconds)

[05:01] * krijnh has joined #css

[05:01] * liam Quit (Ping timeout: 60 seconds)

[05:02] * florianr Quit ("")

[05:03] * glenn Quit (Client closed connection)

[05:09] * boblet has joined #css

[05:12] * leaverou is now known as leaverou_away

[05:14] * stearns has joined #css

[05:22] * stearns Quit (Ping timeout: 20 seconds)

[05:33] * rotsuya has joined #css

[05:34] * franremy has joined #css

[05:35] * SimonSapin has joined #css

[05:36] * tomoyuki Quit (Ping timeout: 20 seconds)

[05:37] * rotsuya_ has joined #css

[05:37] * tomoyuki has joined #css

[05:37] * SimonSapin Quit ("Leaving.")

[05:37] * SimonSapin has joined #css

[05:38] * rotsuya Quit (Ping timeout: 20 seconds)

[05:39] * mjs has joined #css

[05:41] * rotsuya has joined #css

[05:42] * kotakagi has joined #css

[05:42] * rotsuya_ Quit (Ping timeout: 20 seconds)

[05:43] * mwenge Quit (Ping timeout: 20 seconds)

[05:43] * shepazu has joined #css

[05:43] * sylvaing_away is now known as sylvaing

[05:48] * r12a has joined #css

[05:48] * franremy Quit (Ping timeout: 20 seconds)

[05:51] * arronei has joined #css

[05:52] * kensaku has joined #css

[05:54] * arronei Quit (Ping timeout: 20 seconds)

[05:55] * arronei has joined #css

[05:59] * franremy has joined #css

[06:01] * sakkuru has joined #css

[06:04] * glenn has joined #css

[06:04] * franremy Quit (Ping timeout: 20 seconds)

[06:04] * sakkuru Quit (Ping timeout: 20 seconds)

[06:05] * sakkuru has joined #css

[06:05] * cabanier has joined #css

[06:06] * yaso has joined #css

[06:06] * krit has joined #css

[06:07] * mjs Quit (mjs)

[06:07] * Jirka has joined #css

[06:08] * antonp has joined #css

[06:08] * mjs has joined #css

[06:08] * dbaron has joined #css

[06:08] * glazou has joined #css

[06:10] * mgylling has joined #css

[06:12] * TabAtkins_ has joined #css

[06:12] * franremy has joined #css

[06:13] * cabanier Quit ("Leaving.")

[06:14] * dino has joined #css

[06:14] * cabanier has joined #css

[06:14] * florianr has joined #css

[06:15] * cabanier Quit ("Leaving.")

[06:17] * divya has joined #css

[06:18] * divya Quit (Client closed connection)

[06:18] * divya1 has joined #css

[06:18] * r12a Quit (Client closed connection)

[06:18] * r12a has joined #css

[06:18] * leaverou_away is now known as leaverou

[06:19] * slightlyoff has joined #css

[06:19] * cabanier has joined #css

[06:19] <TabAtkins_> Topic: CSS Animations

[06:19] * divya1 is now known as divya

[06:19] * cox has joined #css

[06:19] * yamaday has joined #css

[06:20] * lstorset has joined #css

[06:20] * antonp Quit (antonp)

[06:20] * antonp has joined #css

[06:20] * Rossen has joined #css

[06:20] * chsiao has joined #css

[06:20] * liam has joined #css

[06:20] <JohnJansen> rumor has it that a photo was just taken...

[06:21] <TabAtkins_> Rumor has it that we did it quick before you found out...

[06:21] <JohnJansen> as long as sylvain was in it, that's cool.

[06:21] <TabAtkins_> Topic: CSS Masking

[06:21] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

[06:22] * kawabata has joined #css

[06:22] <TabAtkins_> krit: This spec aims to combine Masking in FF and Webkit, combine to a common spec. Takes from SVG Masking and Clipping, and specifies how WebKit works.

[06:22] <TabAtkins_> krit: Have a few issues left.

[06:22] <TabAtkins_> krit: First is mask-clip.

[06:22] <TabAtkins_> krit: CSs Masking in webkit is pretty similar to background and its properties.

[06:22] * Norbert has joined #css

[06:23] <TabAtkins_> krit: While a background is always limited to the border box ( you can't draw otuside of it), CSS masking might want to go outside of this box.

[06:23] <TabAtkins_> krit: For example, a child element overflowing the main element, people may want to have a mask that covers the whole thing and doesn't auto-clip away the overflow.

[06:23] <TabAtkins_> krit: But right now mask-clip only has the same property as background-clip.

[06:23] <TabAtkins_> krit: I'd like another keyword that takes into account the boxes of children.

[06:24] * shepazu Quit ()

[06:24] * shepazu has joined #css

[06:24] <TabAtkins_> TabAtkins_: So, not things like shadows? Just the union of geometry, like getboundingClientRect?

[06:24] <TabAtkins_> krit: Yes.

[06:24] <TabAtkins_> krit: Another issue - SVG percentages in a clip need to resolve against a box. I'd like to let this "union box" also be usable for resolving percentages against.

[06:24] <TabAtkins_> krit: Another related issue - set the clip area to the same as the filtered area.

[06:25] * Reinaldo_ has joined #css

[06:25] <TabAtkins_> krit: For example, be able to put a clip on a blurred element without necessarily auto-clipping the part of blur that goes outside the geometry.

[06:25] * trackbot Quit (Client closed connection)

[06:26] <TabAtkins_> krit: roc suggested a "none" value, with no automatic limitations (or UA-defined ones based on knowledge of painting). However, we still need to decide what SVG percentages are resolved against.

[06:26] * kotakagi Quit (Ping timeout: 20 seconds)

[06:26] <TabAtkins_> krit: We could use the "union box" for that too - difference being that stuff outside the 0%-100% range are actually still useful.

[06:27] * trackbot has joined #css

[06:27] * trackbot Quit (Client closed connection)

[06:28] <TabAtkins_> dbaron: That's a little weird, if the blur is part of the bounding box.

[06:28] <TabAtkins_> TabAtkins_: It's not - it's just whatever bounding client rect would return.

[06:29] <TabAtkins_> krit: Next question, origin of the coord space. Since you're referencing an SVG image, how do you position the image? x/y attributes on the root <svg> element? Is that allowed?

[06:30] <TabAtkins_> TabAtkins_: It's allowed, but I think it's meaningless right now. We could maybe fix that.

[06:30] * yamaday Quit ("TakIRC")

[06:30] <TabAtkins_> krit: And for PNG it would just sit at the 0,0 of the coord space?

[06:30] * yamaday has joined #css

[06:30] <TabAtkins_> TabAtkins_: Yes.

[06:31] <TabAtkins_> krit: Ok, but then you still can't ever mask a blur with a PNG - the blur part will always be outside of whatever boxes you use for the coord space.

[06:31] <TabAtkins_> TabAtkins_: Okay, so we might want a clip-margin then, to allow the author to manually expand the clipping box further.

[06:31] * tomoyuki Quit (tomoyuki)

[06:32] * trackbot has joined #css

[06:32] <TabAtkins_> krit: Ok, if you're willing to help me figure that out, we can leave it unresolved for now.

[06:32] * trackbot Quit (Client closed connection)

[06:32] * tomoyuki has joined #css

[06:32] <TabAtkins_> TabAtkins_: Okay, so two additions to the spec being reviewed right now:

[06:33] <TabAtkins_> TabAtkins_: 1) Add a new value to mask-clip/origin which uses the "bounding box" - same as returned by getBoundingClientRect.

[06:34] <TabAtkins_> TabAtkins_: 2) Add a new "none" value which has no auto-clipping, and which sets the origin/extent of coordinate sapce same as "bounding box" value.

[06:34] <TabAtkins_> plinss: So the initial suggestion was just to add a "none" keyword?

[06:35] <TabAtkins_> RESOLVED: Add the two new values to mask-clip/origin as described above.

[06:35] * yaso Quit (yaso)

[06:35] * jfmoy has joined #css

[06:35] * jfmoy has left #css

[06:35] * trackbot has joined #css

[06:36] <TabAtkins_> TabAtkins_: Has anyone asked for the "bounding rect" clip?

[06:36] * stearns has joined #css

[06:36] * trackbot Quit (Client closed connection)

[06:36] * kotakagi has joined #css

[06:36] <TabAtkins_> krit: Firefox does the "none" value right now.

[06:36] <TabAtkins_> TabAtkins_: Okay, so maybe just do the "none" value now, and reserve the explicit "bounding rect" clip for later.

[06:37] <TabAtkins_> RESOLVED: Amend previous resolution - only agree to add the "none" value.

[06:37] <TabAtkins_> Bert: Do we need to coordinate with SVG on this?

[06:37] <TabAtkins_> krit: SVG already decided on it - this is SVG coming to CSS to sanity-check/bless it.

[06:37] <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#ClipProperty

[06:38] <TabAtkins_> krit: The 'clip' property only applies to abspos elements, using the rect() function.

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

[06:38] <TabAtkins_> s/clip-path()/'clip-path'/

[06:39] <TabAtkins_> TabAtkins_: So do we want to unify the two properties?

[06:39] * yaso has joined #css

[06:40] <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).

[06:41] <TabAtkins_> TabAtkins_: Okay, so you're suggesting deprecating 'clip' and using only 'clip-path'.

[06:43] * Zakim excuses himself; his presence no longer seems to be needed

[06:43] * Zakim has left #css

[06:43] <TabAtkins_> plinss: Sorta sad - clip was the first one that we ever did with the intention of being extended with more functions like this.

[06:44] * glazou loves how zakim quites the channel first and apologizes for that later

[06:44] <glazou> s/quites/quits

[06:45] * Zakim has joined #css

[06:45] * dbaron Zakim, remind us in 191 minutes to go home

[06:45] * Zakim ok, dbaron

[06:46] <TabAtkins_> RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.

[06:47] <TabAtkins_> TabAtkins_: Related to this, can we add an inset-rectangle()?

[06:47] * yamaday Quit ("TakIRC")

[06:47] <TabAtkins_> dbaron: We have a standing resolution from 2001 to add an inset-rect()

[06:47] <dbaron> Redwood City in 2001

[06:47] * yamaday has joined #css

[06:48] <dbaron> (which was only the second WG meeting I attended in person)

[06:48] <TabAtkins_> everyone: sounds good, make Rossen do it.

[06:49] <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec.

[06:49] * fantasai suggests just calling it 'inset()'

[06:49] * trackbot has joined #css

[06:49] <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec. (or just inset()).

[06:49] * trackbot noticed an ACTION. Trying to create it.

[06:49] <trackbot> Created ACTION-514 - Add inset-rectangle(top, right, bottom, left) to the Shapes spec. (or just inset()). [on Rossen Atanassov - due 2012-11-05].

[06:50] <TabAtkins_> RESOLVED: Add inset() or inset-rectangle() to the Shapes module.

[06:50] <TabAtkins_> krit: Last issue is the 'mask' shorthand.

[06:50] <TabAtkins_> krit: 'maks' property in SVG takes a ref to a <mask> element.

[06:50] <TabAtkins_> krit: Webkit takes just CSS images.

[06:51] <TabAtkins_> krit: roc complained that these are not fully compatible with each other

[06:51] <TabAtkins_> krit: it's not fully clear when pointing to an SVG document whether to use it as an "image" or as an "image source" (a CSS image, in other words).

[06:51] * yamaday Quit ("TakIRC")

[06:52] * yamaday has joined #css

[06:52] <krit> TabAtkins: If you have a URL fucntion with an hash, it is not clear if you refer an SVG element or an paint server, or an resource

[06:52] * mjs Quit (mjs)

[06:52] <krit> TabAtkins: CSS would like to integrate into SVG further

[06:52] <krit> TabAtkins: fill and stroke would take CSS IMages

[06:52] <krit> TabAtkins: this needs two different code pathes

[06:53] <fantasai> TabAtkins^: Use SVG paint servers as CSS images

[06:53] <krit> TabAtkins: Is the SVG file referencing an resource, paint sserver or element

[06:53] <krit> TabAtkins: but depndent on the context, the file needs to be treated differently

[06:53] * mjs has joined #css

[06:53] <krit> TabAtkins: this might be a problem in more impementation

[06:54] <krit> TabAtkins: that's why he want to know on parse time which code pah we need

[06:54] <fantasai> TabAtkins: On mailing list, roc has proposal we're working through on how to segregate SVG references based on structure of frag id as to whether it's a paint server or ?

[06:54] <krit> TabAtkins: roc has a proposal to differ the file interpretation on #

[06:54] <fantasai> TabAtkins: If it's a frag id, assume it's a paint server

[06:55] <fantasai> TabAtkins: If it's a media fragment or SVG functional notation, it's a [picture]

[06:55] * yamaday Quit ("TakIRC")

[06:55] <fantasai> ChrisL: What if you have a normal fragment ID that points to an SVGView element?

[06:55] <fantasai> s/picture/SVG view/

[06:55] * yamaday has joined #css

[06:55] <fantasai> TabAtkins: ... use :target pseudo-class to get similar facts

[06:55] <fantasai> TabAtkins: Probably safe to shut that down

[06:56] <fantasai> TabAtkins: Let's discuss this soon, decide on something that's good for SVG, and incorporate here.

[06:56] <fantasai> TabAtkins: If you're interested in this, contribute to mailing list thread on www-style

[06:57] * ChrisL has joined #css

[06:57] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html

[06:57] <TabAtkins_> Relevant thread: http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html

[06:58] <fantasai> SteveZ: Appears to me you wnat to distinguish paint servers, things that SVG can fill

[06:58] <dbaron> http://lists.w3.org/Archives/Public/www-svg/2012Oct/thread.html#msg19

[06:58] <fantasai> SteveZ: my experience is that heuristics is a fragile way to distinguish

[06:58] <fantasai> SteveZ: Why not add something to referencing mechanism?

[06:58] <dbaron> looks like the first few messages on the thread were www-svg only, then it was both www-svg and www-style for the rest

[06:58] <fantasai> TabAtkins: SVG and CSS are already ambiguous in how they handle this

[06:59] <fantasai> TabAtkins: Luckily way SVG uses CSS URLs is usually referring to a paint server

[06:59] <fantasai> TabAtkins: So works already

[06:59] <fantasai> krit: SVGStack

[06:59] <fantasai> TabAtkins: mechanism for spriting SVG, using :target to hide everything else

[06:59] <fantasai> TabAtkins: These would break, because need to load those as an image, not as a paint server

[07:00] <fantasai> TabAtkins: But afaict the uses of these in the wild are in <object> tags, etc.

[07:00] <fantasai> krit: we've seen a lot of blog posts and bug reports complaining that we don't implement this

[07:00] <ed> TabAtkins: yes, that's true, but the use outside of CSS doesn't use the url()-notation, so it's different

[07:00] <ed> use of svg stacks that is

[07:01] <fantasai> fantasai: We have several functions that allow referencing images

[07:01] <fantasai> fantasai: Distinguish based on that

[07:01] <fantasai> TabAtkins: roc suggests element() interprets as paint server, image() as view

[07:02] <fantasai> fantasai: make url() do the legacy thing

[07:02] <fantasai> TabAtkins: both are legacy things

[07:02] * fantasai is confused

[07:02] * chsiao Quit (Ping timeout: 20 seconds)

[07:02] <fantasai> plinss: Interpreting things differently based on fragment ID is an architectural faux-pas

[07:02] <fantasai> plinss: Interpretation of frag ID should be registered with media type

[07:03] <fantasai> plinss: Let's not do something that breaks the Web architecture

[07:03] <fantasai> TabAtkins: Two legacy behaviors are bg-image: url(svg); treats as an image

[07:03] <fantasai> TabAtkins: fill: url(svg); treats as a paint server

[07:04] <fantasai> fantasai: Then per-property, define handling of url() per property

[07:04] <fantasai> TabAtkins: doesn't work for masking -- could load svg as a mask path, or as an image

[07:05] <fantasai> fantasai: So pick a default, and then can use other function names to do something different

[07:05] <fantasai> ChrisL: ...

[07:05] <fantasai> krit: Mozilla also has to consider CORS, which is one reason need to know ahead of time

[07:05] * ChrisL sigh

[07:05] * fantasai missed ChrisL's comment

[07:05] * fantasai invites ChrisL to type it in

[07:05] <fantasai> krit: So let's leave this issue open for now

[07:06] <fantasai> krit: Can we publish a FPWD with changes we resolved today?

[07:06] <fantasai> plinss: any objections?

[07:06] <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

[07:06] <fantasai> RESOLVED: FPWD Masking

[07:06] <fantasai> plinss: Have similar issue wrt shortname

[07:07] <fantasai> ...

[07:07] <fantasai> TabAtkins: It's a Level 1 spec

[07:07] <fantasai> TabAtkins: So could just call it css-mask

[07:07] <fantasai> RESOLVED: call it css-mask

[07:07] <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

[07:08] * kensaku Quit ("Leaving...")

[07:08] * kensaku has joined #css

[07:08] * rotsuya Quit (Client closed connection)

[07:08] * divya Quit ("Leaving.")

[07:08] <cabanier> slides for blending discussion: http://cabanier.github.com/blending/#/

[07:08] * glazou Quit (glazou)

[07:08] <fantasai> <br duration=22m>

[07:09] * cabanier Quit ("Leaving.")

[07:09] * cabanier has joined #css

[07:09] * cabanier Quit ("Leaving.")

[07:09] * rotsuya has joined #css

[07:10] * leaverou is now known as leaverou_away

[07:10] * TabAtkins_ Quit (Ping timeout: 20 seconds)

[07:12] * sakkuru Quit (Ping timeout: 20 seconds)

[07:15] * Norbert Quit (Ping timeout: 20 seconds)

[07:16] * stearns Quit (stearns)

[07:17] * kotakagi Quit (Ping timeout: 20 seconds)

[07:18] * sakkuru has joined #css

[07:20] * kotakagi has joined #css

[07:23] * Jirka has left #css

[07:26] * stearns has joined #css

[07:26] * florianr Quit ("")

[07:28] * tomoyuki Quit (tomoyuki)

[07:28] * rotsuya Quit (Client closed connection)

[07:30] * yamaday Quit ("TakIRC")

[07:32] * tomoyuki has joined #css

[07:34] * leaverou_away is now known as leaverou

[07:35] * TabAtkins_ has joined #css

[07:35] * cabanier has joined #css

[07:37] * divya has joined #css

[07:38] * glazou has joined #css

[07:38] <cabanier> http://cabanier.github.com/blending/#/

[07:38] <TabAtkins_> Topic: Compositing

[07:39] <TabAtkins_> cabanier: Blending spec currently says that blending/compositing always happens in a non-isolated group. I propose that they happen in an isolated group.

[07:39] * krit The question for scribes get more and more rhetoric

[07:39] <TabAtkins_> cabanier: Two reasons - non-isolated are much more expensive to do.

[07:39] <TabAtkins_> cabanier: Two, some OS frameworks (such as Cairo) can't do them natively, so they'd have to be done by hand.

[07:39] <TabAtkins_> cabanier: So I fear that they would be non-implementable as written today.

[07:43] <TabAtkins_> cabanier: [goes through his slides]

[07:45] <TabAtkins_> cabanier: So in isolated groups, as soon as you have a stacking context, the elements in there only blend/composite with each other, not with elements outside the stacking context.

[07:45] * tomoyuki Quit (tomoyuki)

[07:45] <TabAtkins_> cabanier: (in SVG, the relevant group is the <g> element)

[07:45] <TabAtkins_> cabanier: Authors generally *prefer* non-isolated groups, but the implementability just seems to be too painful right now.

[07:46] <TabAtkins_> TabAtkins_: So we might still want to have a proeprty that merges groups?

[07:46] * tomoyuki has joined #css

[07:47] <TabAtkins_> cabanier: Already exists. I'm just asking to change the default.

[07:47] <TabAtkins_> cabanier: (Also, that property probably won't be implemented yet, and may be removed from this level.)

[07:48] <TabAtkins_> cabanier: I know some of the graphics people will be unhappy, but they can work around it by putting things in the same stacking context.

[07:48] <TabAtkins_> cabanier: This weirdness already exists sometimes - z-index can be disrupted by opacity creating a new stack.

[07:48] * hober an oldie but a goodie: http://w3cmemes.tumblr.com/post/22708671971

[07:49] <TabAtkins_> TabAtkins_: Relevant Moz implementor would be roc, right?

[07:49] <TabAtkins_> krit: Cairo was cited as the problem. Direct3d will have the same problem.

[07:50] <TabAtkins_> lstorset: Will this affect existing SVG impls?

[07:50] <TabAtkins_> cabanier: It's a new property, so no.

[07:50] * rotsuya has joined #css

[07:51] * Rossen Quit (Ping timeout: 20 seconds)

[07:51] <TabAtkins_> RESOLVED: Turn the Compositing default to be isolated groups.

[07:51] * chsiao has joined #css

[07:51] <TabAtkins_> dino: What about publishing the spec?

[07:51] <TabAtkins_> cabanier: It's already a WD.

[07:52] <TabAtkins_> cabanier: And I'll request a new WD when I make edits.

[07:52] <TabAtkins_> Topic: Animations

[07:53] * lstorset Quit (Ping timeout: 20 seconds)

[07:53] <TabAtkins_> sylvaing: What do we do for TTA? Something every week?

[07:54] <TabAtkins_> plinss: If there are issues, our policy is to bring them up. We just confirmed through prioritization that TTA is our top priorities, so they'll get interrupt priority.

[07:54] * yamaday has joined #css

[07:54] * JohnJansen Quit (Ping timeout: 20 seconds)

[07:54] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713

[07:54] <TabAtkins_> sylvaing: This is about dynamic changes to animation properties or keyframes.

[07:55] <TabAtkins_> sylvaing: Spec since the beginning requires animation property or keyframes to be snapshotted at the start of the animation.

[07:55] <TabAtkins_> sylvaing: David and Simon agree that it should be more open to dynamic changes while it's running, such as changing the duration.

[07:55] <TabAtkins_> sylvaing: We haven't defined in detail how that works.

[07:55] * mgylling Quit (mgylling)

[07:56] * yaso Quit (yaso)

[07:56] <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.

[07:56] <TabAtkins_> dbaron: This is the start time at the end of the delay (I think).

[07:56] <TabAtkins_> dbaron: As long as that animation name stays in th elist of animations, that's the start time we use for the animation.

[07:56] <TabAtkins_> dbaron: And we continue using that start time for all other things.

[07:56] <TabAtkins_> dbaron: I think basically anything else can change.

[07:57] <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.

[07:57] <TabAtkins_> dbaron: But I'd have to confirm.

[07:57] * lstorset has joined #css

[07:57] <TabAtkins_> dbaron: Effectively, you just recompute all the parametersof the animation at every moment based on the current values.

[07:57] <ChrisL> all the parameters are recomputed at each tick in the animation

[07:58] * Reinaldo_ Quit (Ping timeout: 20 seconds)

[07:58] <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.

[07:59] <TabAtkins_> plinss: if you change things while paused, it can put you in a different position?

[07:59] <TabAtkins_> dbaron: Yes. Change the animation-duration while it's paused, and it'll live-move you to the new position.

[08:00] <TabAtkins_> dino: I don't like starting it at the end of the delay.

[08:00] <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.

[08:00] <TabAtkins_> dino: We snapshot right now, but the underlying engine supports modification.

[08:01] <TabAtkins_> dino: We have all the infrastructure so we can expose it to JS.

[08:01] <TabAtkins_> sylvaing: I'm okay with making the animation properties dynamic.

[08:01] * mishida has joined #css

[08:01] <TabAtkins_> sylvaing: We need some prose in the spec to b emore explicit.

[08:02] * Norbert has joined #css

[08:02] * trackbot Quit (Client closed connection)

[08:02] <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?

[08:03] * hiroki has joined #css

[08:03] <TabAtkins_> dbaron: b,c,d never left the lsit.

[08:03] <TabAtkins_> sylvaing: Okay, we need that written down.

[08:03] <TabAtkins_> dbaron: I wonder what brian birtle thinks about this, given his work.

[08:04] <TabAtkins_> TabAtkins_: Based on me working with him, I think this is in line with what he wants.

[08: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?

[08:05] <TabAtkins_> TabAtkins_: I think *not* delivering one would result in bad accidental bugs.

[08:05] * knobuta2 has joined #css

[08:05] <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?

[08:06] <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.

[08:06] <TabAtkins_> dino: Okay. So there are multiple things like this that need to be resolved and specified.

[08:06] <TabAtkins_> sylvaing: Right - right now everything is simple, because they can't change.

[08:07] <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?

[08:07] <TabAtkins_> dino: Need to work out the full state machine for all of this.

[08:08] <TabAtkins_> plinss: (re: iteration events) maybe only deliver the last iteration, updating you to the current state.

[08:09] <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.

[08:09] <TabAtkins_> dbaron: [draws a table of states on the whiteboard]

[08:09] <TabAtkins_> dbaron: If we define what fires for every transition between these cells, is that sufficient?

[08:09] <TabAtkins_> dino: Yes.

[08:10] <TabAtkins_> dino: (But there may be another column or two on that graph.)

[08:10] <dbaron> columns: before / 1st iter / 2nd iter / 3rd iter / after

[08:11] <dbaron> rows: running / paused

[08:11] <dbaron> or maybe

[08:11] <dbaron> rows: running / paused, happens immediately / paused, happens when unpaused

[08:11] <TabAtkins_> sylvaing: Okay, so I think there's agreement to make these properties dynamic.

[08:11] <dbaron> And I think there's agreement that the recorded start is the start before the delay

[08:11] <TabAtkins_> RESOLUTION: Change the animation properties to be dynamically changable, details TBD.

[08:12] <TabAtkins_> ACTION sylvain to define what happens when animation properties are changed dynamically.

[08:12] <oyvind> and @keyframes?

[08:12] <TabAtkins_> oyvind, getting there.

[08:12] * ChrisL trackbot, self.reboot()

[08:12] <oyvind> alright

[08:12] <TabAtkins_> sylvaing: So, keyframes.

[08:13] <TabAtkins_> sylvaing: Changing those on the fly while animation is running.

[08:13] <TabAtkins_> sylvaing: The concept makes sense when the animation iterates - when the next interval takes the changes into account.

[08:13] <TabAtkins_> sylvaing: If you have an animation that runs once, I dunno.

[08: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.

[08:14] * JohnJansen has joined #css

[08:14] <TabAtkins_> TabAtkins_: Conceptually, I don't see anything wrong with changing them mid-animation.

[08:15] <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.

[08:15] * divya Quit (Client closed connection)

[08:16] * divya1 has joined #css

[08:16] <TabAtkins_> sylvaing: Are there any animation functions in @keyframes?

[08:16] <TabAtkins_> TabAtkins_: Only the timing function.

[08:16] * kensaku Quit (Client closed connection)

[08:17] <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)

[08:17] * divya1 is now known as divya

[08:19] * kensaku has joined #css

[08:19] <TabAtkins_> sylvaing: So what about changes of keyframes during an iteration event, intending for the next iteration to use new values?

[08:19] * kensaku Quit (Client closed connection)

[08:19] * kensaku has joined #css

[08:20] <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.

[08:20] <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.

[08:20] <TabAtkins_> dino: But then we need to specify that.

[08:20] * stearns Quit (Ping timeout: 60 seconds)

[08:20] <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.

[08:21] * kensaku_ has joined #css

[08:21] <TabAtkins_> RESOLVED: @keyframes can be dynamically changed

[08:21] <glazou> yay

[08:21] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15846

[08:22] <TabAtkins_> sylvaing: Next. Transition events report what pseudo-element of the element the transition is running against.

[08:22] <TabAtkins_> sylvaing: We don't have it for animation events at the moment.

[08:22] * stearns has joined #css

[08:22] <TabAtkins_> dbaron: We should just copy it.

[08:22] <TabAtkins_> RESOLVED: Copy over the pseudo-element info from transition events to animation events.

[08:22] * Rossen has joined #css

[08:22] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html

[08:23] <TabAtkins_> sylvaing: What happens when you have duplicate animation names in the animation-name property.

[08:23] <TabAtkins_> sylvaing: Seems that last one wins.

[08:23] * ChrisL imagines animating font-size on :first-line

[08:23] * kensaku Quit (Ping timeout: 60 seconds)

[08:24] * yaso has joined #css

[08:24] * kensaku_ Quit (Client closed connection)

[08:24] * divya Quit ("Leaving.")

[08:24] * kensaku has joined #css

[08:24] <TabAtkins_> dbaron: I think we resolved that and I edited it already.

[08:24] * SimonSapin is glad not to implement that

[08:25] * kotakagi Quit ("TakIRC")

[08:25] <TabAtkins_> dbaron: A similar thing is which animation property's length is the winner. I propose that animation-name define the number of animations, and every other property gets padded/clipped to that length.

[08:25] <TabAtkins_> dbaron: This matches what backgrounds/etc do.

[08:25] <TabAtkins_> dbaron: I may have already editted this into the draft.

[08:26] * dbaron Quit (Ping timeout: 60 seconds)

[08:26] * divya has joined #css

[08:26] * smfr has joined #css

[08:27] <TabAtkins_> RESOLVED: animation-name's length is authoritative. Other animations properties are adjusted to its length.

[08:27] <TabAtkins_> ACTION Sylvain to make sure that animation-name's length is definitive, and edit it to be so otherwise.

[08:28] * Norbert Quit (Norbert)

[08:28] <TabAtkins_> RESOLVED: When you encounter duplicate animations names, last one wins.

[08:28] * kensaku Quit (Client closed connection)

[08:28] <oyvind> that last resolution seems unclear

[08:28] * kensaku has joined #css

[08:28] * dbaron has joined #css

[08:28] <glazou> oyvind: explain ?

[08:29] <oyvind> current draft says that the last wins *at any particular point in time, for a particular property*

[08:29] <dbaron> http://dev.w3.org/csswg/css3-animations/#list-matching already has the first of those two resolutions edited in, actually

[08:29] <TabAtkins_> oyvind, when assembling the set of property values that define the animation, the index of the last occurence of the animation name is what is used.

[08:29] <dbaron> oyvind, oh, it's about what happens if the same animation-name is specified twice in the list

[08:29] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14599

[08:29] <dbaron> oyvind, which duration, delay, timing-function, etc., does it use

[08:29] * glazou oyvind: 'animation-name: foo foo"

[08:29] <sylvaing> http://jsfiddle.net/leaverou/jwHva/2/

[08:30] <dbaron> oyvind, the answer is that it's the last occurrence of that animation-name in the list

[08:30] <TabAtkins_> sylvaing: In this example, if you remove border-style:solid, the animation stops working.

[08:31] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html

[08:32] <TabAtkins_> dbaron: I think I wrote a response for why this is crazy.

[08:32] * yaso Quit (yaso)

[08:33] <TabAtkins_> 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.

[08:33] <oyvind> dbaron, ok, I misunderstood somewhat

[08:33] <TabAtkins_> leaverou: Authors find this super-confusing in my experience.

[08:34] <TabAtkins_> dbaron: There's an even more subtle issue here.

[08:34] <TabAtkins_> dbaron: Related to the processing model.

[08:34] * florianr has joined #css

[08:34] <TabAtkins_> dbaron: When animating from A to B, there's an idea that it overrides some of the properties, and only those.

[08:35] <TabAtkins_> dbaron: So this animation actually overrides 13 properties. border-image, border-top-style, border-top-color, etc.

[08:35] <TabAtkins_> dbaron: For each keyframe, you get a computed value from it, and then you animate the computed values between.

[08:35] <TabAtkins_> dbaron: However, in some cases, for border-width, the computed value depends on border-style.

[08:36] <TabAtkins_> dbaron: Which value are you using? The base value, or the value that the keyframe is overriding?

[08:36] * kotakagi has joined #css

[08:36] <TabAtkins_> dbaron: And this gets more confusing.

[08:36] <TabAtkins_> dbaron: Say you have a 50% keyframe here with only a "border-width: 10px;" property.

[08:36] <TabAtkins_> dbaron: What border-style is this resolved against?

[08:36] * knobuta2 Quit ("Page closed")

[08:37] * knobuta2 has joined #css

[08:37] * dbaron Quit (Ping timeout: 60 seconds)

[08:37] <TabAtkins_> dbaron: Gecko currently resolves it against the base value.

[08:37] <TabAtkins_> dbaron: (It also does this for the other keyframes.)

[08:38] <TabAtkins_> dbaron: The spec's processing model just doesn't really care about the fact that computed values can depend on other computed values.

[08:38] * dbaron has joined #css

[08:38] <TabAtkins_> dbaron: I think it should, but I doubt any browser really does it.

[08:39] <TabAtkins_> dbaron: I think a testcase that covers only the issue I was talking about would be one that animates font-size and some length in ems.

[08:40] * florianr Quit ("")

[08:40] * Norbert has joined #css

[08:42] <TabAtkins_> ChrisL: In SMIL anything can be animated. It just switch halfway through.

[08:43] <dbaron> dbaron: halfway through the timing function (which makes step-start and step-end magically work)

[08:43] <TabAtkins_> TabAtkins_: Worst case, can we separate this out, so that non-animatable properties with constant value are still paid attention to and "animate".

[08:43] <TabAtkins_> ChrisL: That sounds like doing 3/4 of the work and just stopping.

[08:44] <TabAtkins_> glazou: We could also just say non-animatable properties freeze at their first keyframe value.

[08:45] <dbaron> dbaron: The thing about font-size and length in ems -- need to test with both in-the-same-@keyframes and in-different-@keyframes

[08:45] <TabAtkins_> dbaron: Regarding font-size and length in ems, make sure you test both when the two proeprties are in the same keyframe, and when they're not.

[08:45] <dbaron> ... and in different @keyframes on different elements.

[08:46] <TabAtkins_> TabAtkins_: So 3 cases of increasing complexity.

[08:47] <TabAtkins_> glazou: So what about my "freeze at frame 0" idea?

[08:47] <TabAtkins_> dbaron: I think that has a higher chance of web compat problems.

[08:47] <TabAtkins_> dbaron: The problem with all of these is potential web compat.

[08:49] <TabAtkins_> glazou: Can we seriously not do better than just making this work?

[08:49] <ChrisL> I'm arguing for fixing it now by defining animation of enumerated values

[08:50] <TabAtkins_> ChrisL: Are you saying that people are relying on the behavior in that fiddle?

[08:50] <TabAtkins_> dbaron: I don't know.

[08:50] <TabAtkins_> dbaron: Webdevs often try things, find they don't work, and then don't remove them.

[08:50] * toms Quit ("ChatZilla 0.9.88.2 [Firefox 10.0.4/20120420145309]")

[08:50] <TabAtkins_> ChrisL: So if we fix it, something might suddenly start working and break a page.

[08:51] <TabAtkins_> dbaron: I suspect we could get away with making this change in animations.

[08:51] <TabAtkins_> dbaron: I suspect not in transitions, because it defaults to "all".

[08:51] <TabAtkins_> dbaron: I suspect that if we fix it, we're adding a minimum of 4 months to the spec.

[08:51] <TabAtkins_> ChrisL: Yes, but that avoids 3+ years of us explaining why it's stupid.

[08:52] <TabAtkins_> dino: I don't think many authors have hit this particular case. Or they do and they screw around until it works.

[08:52] <sylvaing> cool border transitions: http://thecodeplayer.com/walkthrough/simple-yet-amazing-css3-border-transition-effects

[08:53] <TabAtkins_> leaverou: I think this change's impact will be smaller than gradient angles flipping. ^_^

[08:53] <TabAtkins_> dino: I'd like to get some compat data on this first.

[08:54] <TabAtkins_> TabAtkins_: Can we put a time limit on this?

[08:54] * mollydotcom has joined #css

[08:55] <TabAtkins_> dbaron: Do you know why Gecko doesn't allow you to style the color of the radio button dot?

[08:55] <TabAtkins_> dbaron: Because hotmail.com styled all their radio buttons with "background-color: green; color: green;", presumably on the theory that *one* of them would work.

[08:56] <TabAtkins_> TabAtkins_: Okay, so suggestion is this: Allow all properties (except maybe animation properties) to be animatable. Discrete properties swap their values halfway through the transition function (to match SMIL).

[08:57] <dbaron> (doesn't apply to transitions)

[08:57] <dbaron> s/transition function/timing function/

[08:59] <TabAtkins_> dino: I don't object to putting this in the spec, but would then like time to investigate compat.

[08:59] * plh has joined #css

[09:00] * Bert thinks that leaves a small pb to decide at 50%: '0% {border: 10px solid} 50% {border-width: 5px} 100% {border: 0px none}' is the border already none at 50% or only at 50.00001% ?

[09:00] <dbaron> depending on whether timing function output is greater or less than 0.5

[09:00] <TabAtkins_> leaverou: If you have cubic-bezier with out-of-range params, you can have it hit 50% multiple times. What happens there?

[09:00] <dbaron> so it might swap more than once

[09:01] <dbaron> (though we don't think so)

[09:01] <TabAtkins_> dbaron: It takes the first/last value depending on whether progress is currently above/below 50%, so it'll flip multiple times.

[09:01] <leaverou> example of timing function that reaches 50% multiple times: http://cubic-bezier.com/#0,1.8,1,-0.79

[09:02] <TabAtkins_> RESOLVED: Make *animations* transition *all* properties. Unless otherwise specified, properties take their starting values below 50% timing function progress, and end values above 50% timing function progress.

[09:02] <dbaron> cubic-bezier(0.25, 3, 0.75, -2)

[09:02] <dbaron> (you can cross 50% more than once)

[09:03] * leaverou dbaron that's what I just said :)

[09:03] <Bert> q+ to ask if we can now remove the Animatable line from table.propdef.

[09:03] * Zakim sees Bert on the speaker queue

[09:03] <dbaron> Bert, no, we can't

[09:04] <dbaron> q+ to go back to the processing model issue

[09:04] * Zakim sees Bert, dbaron on the speaker queue

[09:04] <glazou> http://www.w3.org/2012/10/TPAC/meetup-Lyon.html#logistics

[09:05] <dino> leaverou, is that your site? cubic-bezier.com?

[09:05] * leaverou is now known as leaverou_away

[09:05] <TabAtkins_> ack bert

[09:05] <Zakim> Bert, you wanted to ask if we can now remove the Animatable line from table.propdef.

[09:05] * Zakim sees dbaron on the speaker queue

[09:06] <TabAtkins_> dbaron: No, really it's about how to interpolate the property.

[09:06] * divya Quit (Ping timeout: 60 seconds)

[09:07] <dbaron> we could maybe rename Animatable: to Interpolation:

[09:07] <dbaron> ack dbaron

[09:07] <Zakim> dbaron, you wanted to go back to the processing model issue

[09:07] * Zakim sees no one on the speaker queue

[09:07] <plinss> ack dbaron

[09:07] * Zakim sees no one on the speaker queue

[09:07] <TabAtkins_> dbaron: Do we at least have an issue filed on the processing model stuff we're discussing?

[09:07] * SimonSapin Quit (Ping timeout: 60 seconds)

[09:07] <TabAtkins_> dbaron: How you compute the base values for the properties that we were discussing a moment ago?

[09:08] * chsiao Quit ("ChatZilla 0.9.89 [Firefox 16.0.2/20121025205401]")

[09:08] * Kid Quit ("Leaving...")

[09:08] <TabAtkins_> ACTION tab to test the processing model of animations where computed values of animated properties depend on each other.

[09:09] * shepazu Quit ("is sleepy")

[09:11] * hober ok, smfr, you're up

[09:11] <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271

[09:11] <fantasai> ScribeNick: fantasai

[09:11] * Norbert Quit (Norbert)

[09:12] * hober plinss: would you please project http://jsfiddle.net/fNxAQ/1/ for smfr?

[09:12] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328

[09:12] <fantasai> smfr: We think that the only real substantive issue in the transforms spec is this bug

[09:12] <fantasai> smfr: which talks about the containing block terminology used in 3D transforms rendering part of the spec

[09:12] <smfr> http://jsfiddle.net/fNxAQ/3/

[09:12] <fantasai> smfr: and to illustrate that, jsfiddle that Ted just linked to, hopefully someone can project

[09:13] <fantasai> smfr: The issue here is related to 3D rendering contexts and

[09:13] <fantasai> smfr: how 3D transforms propagate across containing blocks,

[09:13] * SimonSapin has joined #css

[09:13] <fantasai> smfr: Is that jsfiddle on the screen?

[09:13] * SimonSapin Quit (Client closed connection)

[09:13] <fantasai> [yes]

[09:13] * SimonSapin has joined #css

[09:14] <fantasai> [fiddling with example]

[09:15] <fantasai> smfr: 2 containers here,

[09:15] <SimonSapin> Sorry to early, going to the city hall to prepare talks

[09:15] <fantasai> smfr: border box with perspective

[09:15] <fantasai> smfr: Top intemrediate div with no style

[09:15] <fantasai> smfr: ... with rotate-y

[09:15] * mishida Quit (Ping timeout: 60 seconds)

[09:15] <fantasai> smfr: issue here is whether perspective on grandparent affects rendering of that transform

[09:16] <fantasai> smfr: i.e. whether the intermediate box flattens it

[09:16] <fantasai> smfr: i.e. whether the intermediate and the box are members of the same 3D context

[09:16] * kotakagi Quit (Ping timeout: 60 seconds)

[09:16] <fantasai> smfr: I believe in FF, intermediate box causes flattening to occur, b/c it's the containing block of the blue box

[09:16] <fantasai> smfr: in Webkit it doesn't

[09:16] <fantasai> smfr: FF more close to wording in current spec

[09:16] <fantasai> smfr: Transforms looks at containing block hierarchy

[09:16] <fantasai> smfr: in bottom example, container, then inside an image, and image has a block sibling

[09:17] <fantasai> smfr: image gets an anonymous block container

[09:17] <fantasai> smfr: in this case the containing block for the image is anonymous

[09:17] <fantasai> smfr: question here is whether that anon box prevents transform

[09:17] <fantasai> smfr [... gecko]

[09:18] <krit> http://jsfiddle.net/fNxAQ/6/

[09:18] <fantasai> dbaron: Gecko doesn't actually create an anonymous box here

[09:18] <fantasai> [fantasai explains what gecko does, why it doesn' tmake that box]

[09:18] * hober plinss: updated jsfiddle link above

[09:18] <fantasai> smfr: implementation does't matter much; but if you adhere to strict wording of spec, there's an anon box that's your containing block

[09:19] <fantasai> smfr: Webkit's implementation is falling out of some other things going on

[09:19] <fantasai> smfr: Detail is something like we're looking at ancestors that are transformed or that are positioned or that have other properties that create stacking contexts

[09:19] <fantasai> smfr: So it's not conforming to the spec, and not always predictable

[09:19] <fantasai> dbaron: You say you're looking for ancestors starting ...

[09:20] <fantasai> dbaron: starting from thing that has a 3D transform?

[09:20] <fantasai> smfr: Any of those things between that and the transform will cause flattening to occur

[09:20] <fantasai> smfr: so webkit won't flatten otherwise

[09:20] <krit> Zakim, q+

[09:20] <Zakim> I see krit on the speaker queue

[09:20] <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4

[09:20] <fantasai> smfr: wording in spec is very tight, maybe need something in between

[09:21] <fantasai> smfr: Aryeh suggests defining a new type of container called transform parent, and then make a list of things that make something a transform parent

[09:21] <fantasai> smfr: [quotes]

[09:21] <fantasai> smfr: [...]

[09:22] <fantasai> smfr: Aryeh's suggestion.. A is closer to what authors expect, and B doesn't have anon containing block problem

[09:22] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c0

[09:22] * koji has joined #css

[09:22] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4

[09:23] <fantasai> smfr: Jsut got browser shots from IE10

[09:23] <fantasai> smfr: Which is similar to FF behavior

[09:23] <fantasai> smfr: Opera shot didn't show any support for 3D transforms

[09:24] <fantasai> smfr: Question here is whether we try to cook up some wording similar to Aryeh's suggestion

[09:24] <fantasai> smfr: or whta

[09:24] <fantasai> smfr: input from other implementers

[09:24] <fantasai> [...]

[09:24] <fantasai> sylvaing: Our rendering in this case is not really related

[09:25] <sylvaing> s/is not/may not be

[09:25] <fantasai> krit: Do we want to follow Webkit, or different approach?

[09:25] <fantasai> fantasai: Seems to me that webkit's behavior is closer to what authors want; wouldn't want everything to flatten all the time, right?

[09:26] * mishida has joined #css

[09:26] <fantasai> dbaron: Authoring perspective, want it never to flatten, but problem is it's too expensive.

[09:26] <fantasai> smfr: Want it to flatten in certain cases

[09:26] <fantasai> dbaron: You'd want the default to be the other way around

[09:26] <fantasai> smfr: when we were designing this transform property, did think it would be good to not flatten always, but didn't do that b/c thought it would be fairly significant change to CSS

[09:26] <fantasai> smfr: Webpages are typically flatt, and having them not-flat would be strange

[09:26] <fantasai> smfr: That's why default style is to be flat

[09:27] <dbaron> those two lines from me were questions

[09:27] <fantasai> smfr: Time authors use preserve3d is when they build up 3d hierarchies of objects they want to sit in the same perspective

[09:27] <fantasai> smfr: It's fairly unusual for someone to put perspective on document and expect theo whole thing to be 3d

[09:27] <fantasai> smfr: Generally have islands of 3D

[09:28] <fantasai> smfr: So we expect authors to sprinkle around preserve3d between things with perspective and objects they want to show in 3d

[09:28] <fantasai> smfr: not too bad, usually only 1-3 levels of elements in between

[09:28] <fantasai> dbaron: Substantive implementation differences. If we pick a different rule, would it be more burdensome?

[09:28] <fantasai> smfr: I think a rule like Aryeh's it'd be a little work for us, but not too bad. Have to flatten a little more than we're doing

[09:29] <fantasai> smfr: The obvious flaw with using contianing block in case where you have an anon containing block, there's no way author can style that to make it preserve3d

[09:29] * rotsuya Quit (Client closed connection)

[09:29] <fantasai> dbaron: Other reason bz pointed out is that containing block is not an element, it's a rectangle

[09:29] <fantasai> smfr: didn't anton fix some things wrt that?

[09:29] <fantasai> antonp: yep, but nothing published yet

[09:29] <fantasai> antonp: but could work around that, if that's what you want

[09:29] * Rossen Quit (Ping timeout: 60 seconds)

[09:29] <fantasai> smfr: If no one has any more input, then action is on me to write up wording for spec ~ Aryeh's comment #4

[09:30] * mjs Quit (mjs)

[09:30] * Tav Quit (Ping timeout: 60 seconds)

[09:30] <dbaron> sounds good to me

[09:30] <fantasai> krit: Can we resolve on some kind of wording ?

[09:30] <fantasai> plinss: Do we have wording?

[09:30] <fantasai> dbaron: Simon was proposing to take an action to propose wording

[09:31] <fantasai> ACTION smfr: propose wording for 3d perpsective containing block thing

[09:31] * RRSAgent records action 2

[09:31] * lmclister has joined #css

[09:31] <fantasai> RESOLVED: Accept Aryeh's proposal, exact wording TBD

[09:31] * divya has joined #css

[09:31] <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271

[09:32] <fantasai> krit: Some other items on issues list

[09:32] <fantasai> krit: Did some wording on it, but needs review from implementers

[09:32] <fantasai> krit: Not necessarily an issue, but should be reviewed

[09:32] * mjs has joined #css

[09:32] * koji Quit (Ping timeout: 60 seconds)

[09:33] <fantasai> ACTION sylvain: look into bug 15605

[09:33] * RRSAgent records action 3

[09:33] * yamaday Quit ("TakIRC")

[09:34] <fantasai> dbaron: I truest Aryeh on this

[09:34] <dbaron> s/truest/trust/

[09:34] <fantasai> dean: We're happy with this

[09:34] * SimonSapin Quit (Ping timeout: 60 seconds)

[09:34] * tomoyuki Quit (tomoyuki)

[09:35] <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17017

[09:35] <fantasai> krit: Next issue is concern of dbaron's

[09:35] <fantasai> krit: we have some interpolation code, how you can interpolate between 3d matrices

[09:36] <fantasai> krit: But don't say how to interpolate between 2d and 2d matrices

[09:36] <fantasai> krit: So, I looked a bit at source code from FF and Webkit

[09:36] <fantasai> krit: FF has ... like 2d interpolation, modified to work on 2d

[09:36] <fantasai> krit: Webkit operates on 3d all the time

[09:36] <fantasai> krit: We have 4x4 matrix

[09:37] <fantasai> krit: we transform everything to 3d first, then take 2d values from the resulting matrix

[09:37] <fantasai> dbaron: I had testcases; possible it's been fixed but;

[09:37] <ChrisL> do you assume the three unused values are 0 0 1?

[09:37] <fantasai> dbaorn: If you do 2d transform in webkit between certain positions, it'll do something ike this [handwave] and then snap to that position

[09:37] <fantasai> dbaron: If you transition between matrices where sign of determinant is different

[09:37] <ChrisL> because they miight not be if you had scaling in there,

[09:38] <fantasai> dbaron: The matrix algorithm will produce interpolation that will spin you around x or y axis, and webkit will then throw out the 3d part of that

[09:38] <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant

[09:38] <fantasai> dbaron: Chrome seems to get these right now, but it didn't used to

[09:39] <smfr> chrome and safari do different things with the bottom row

[09:39] <fantasai> dbaron: That said, bottom row is looking ike it's doing something 3d to me

[09:39] <fantasai> dbaron: so I think Chromium is interpolating the bottom in 3d

[09:39] <fantasai> dbaron: Firefox is interpolating in 2d

[09:39] <smfr> in safari, middle row 2nd from right is weird

[09:40] * rotsuya_ has joined #css

[09:41] <fantasai> [random discussion of these cases and what's happening in various browsers/versions]

[09:41] <fantasai> ChrisL: Promoting to 3d and then interpolating doesn't necessarily give you the wrong answer, just depends how you do it

[09:41] * nsakai has joined #css

[09:41] <fantasai> krit: Do we want to define an algorithm for this?

[09:41] <fantasai> krit: It seems to be hard in webkit atm

[09:42] <fantasai> dbaron: Seems we should say what happens, how you interpolate between these things

[09:42] <fantasai> krit: Are implementations willing to change?

[09:42] <fantasai> dean: FF must have extra code to handle this

[09:42] <fantasai> dbaron: We have separate paths for 2d vs 3d

[09:43] <fantasai> dean: What's 3d vs 2d?

[09:43] * mjs Quit (mjs)

[09:43] * divya Quit (Ping timeout: 60 seconds)

[09:44] <fantasai> dbaron: The test for 2d is based on the components of the matrix

[09:45] <fantasai> dbaron: one other reason we want this code is... I don't think we support 3d transforms in all cases... though maybe we do

[09:46] <fantasai> [...]

[09:46] * Rossen has joined #css

[09:46] <fantasai> dean: It coudl be that the 3d interpolation is ok for enough cases

[09:46] <fantasai> dean: and we're just seing some bugs in webkit's implementation

[09:46] * franremy Quit (Ping timeout: 60 seconds)

[09:46] <fantasai> dean: would sitll like to know why chose to customize algorithm for 2d

[09:46] <fantasai> dbaron: he's in New Zealand...

[09:47] <fantasai> dean: I don't trust anyone from New Zealand

[09:47] <fantasai> dean: I accept the resolution

[09:47] <fantasai> krit: Even if we have interpolation in 3d space, still need to specify how get 2d components for e.g. getComputedStyle

[09:48] * stearns Quit (stearns)

[09:48] * SimonSapin has joined #css

[09:48] <fantasai> krit: It's the main thing left

[09:48] <fantasai> krit: I'd like to have just one algorithm in the spec, not multiple algorithms. 3d is already complex enough

[09:49] <fantasai> plinss: Anyone take an action to do research and get back?

[09:49] <fantasai> krit: What do you expect as the result?

[09:49] <fantasai> dbaron: Are we interoperable on 3d interpolation, in general?

[09:49] <smfr> sounds like we need some test cases!

[09:49] <fantasai> krit: Webkit is mostly following the algorithm in the spec

[09:50] <fantasai> dean: Made an effort to match the algorithm from you, although we may have bugs

[09:51] <fantasai> [more discussion of browser versions]

[09:51] <fantasai> krit: They look different. That might be a bug

[09:51] <fantasai> dbaron: Looking at our code, looks like we're still doing quaternian thing for both 2d and 3d, just do a different decomposition

[09:51] <fantasai> dean: Is the decomposition for speed or aesthetics?

[09:51] <fantasai> dbaron: Think it's for aesthetics

[09:51] <fantasai> dbaron: we use a decomposition that never generates a perspective

[09:52] <fantasai> dbaron: sometimes the 3d comp will generate a negative 1 perspective instead of 1

[09:52] <fantasai> dbaron: that's what leads to weird zoom-in-zoom-out behavior

[09:52] * glazou has left #css

[09:52] <fantasai> ChrisL: That's not perspective, that's scale, right?

[09:52] * fantasai is so glad not working on this spec

[09:52] * SimonSapin Quit (Ping timeout: 60 seconds)

[09:52] * glazou has joined #css

[09:52] * leaverou_away is now known as leaverou

[09:53] <fantasai> dbaron: Or maybe it's [this other] component that's affected

[09:53] <fantasai> ChrisL: Looks like it's the scale factor

[09:53] <fantasai> dean: I think if you get anything other than 1 in 4,4, you're done

[09:53] * SimonSapin has joined #css

[09:53] * rotsuya__ has joined #css

[09:53] <fantasai> dbaron: It's something where you can take a 2d matrix, run 3d decomp, and get a -1 instead of a 1 in some parts

[09:54] * dbaron Quit (Ping timeout: 60 seconds)

[09:54] <fantasai> krit: Webkit always assumes 3d, even if given 2d

[09:54] * rotsuya_ Quit (Ping timeout: 60 seconds)

[09:54] <fantasai> krit: You could use algorithm from 3d transforms and do some weird stuff like setting 1 for perspective

[09:54] <fantasai> krit: at the moment it's undefined

[09:54] <fantasai> Options are

[09:55] <fantasai> 1. Define 2d decompositing algorithm

[09:55] <fantasai> 2. Leave it undefined

[09:55] <fantasai> 3. Use 3d decomposing algorithm everywhere

[09:56] <fantasai> krit: Could also defer this issue to next level

[09:56] <fantasai> dean: Dunno. It is an interop issue.

[09:56] <fantasai> dean: If you query getComputedStyle halfway through a transition, would get different values on different browsers

[09:56] * Zakim dbaron, you asked to be reminded at this time to go home

[09:57] <fantasai> dbaron: Other thing is that algorithm could be tweaked so that the 3d algorithm will always work

[09:59] * nsakai Quit ("")

[09:59] <fantasai> dbaron: I'd like to at least email Matt Woodrow and Tim and ask them why we're doing what we're doing

[09:59] <fantasai> ACTION dbaron: investigate motivations for gecko approach to 2d matrix interpolation

[09:59] * RRSAgent records action 4

[10:00] * krit Quit ("Leaving.")

[10:00] <fantasai> Meeting closed.

[10:00] * cabanier Quit ("Leaving.")

[10:00] * hiroki Quit ()

[10:00] * antonp Quit (antonp)

[10:00] * mishida Quit ("Page closed")

[10:01] * kazutaka Quit ("CHOCOA")

[10:01] * glazou Quit (glazou)

[10:01] * dbaron has joined #css

[10:02] <TabAtkins_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1871

[10:02] * dino Quit (dino)

[10:02] <TabAtkins_> dbaron ^^^

[10:02] * mollydotcom wishes everyone a nice evening ~~~~

[10:02] * knobuta2 Quit (Ping timeout: 60 seconds)

[10:03] * arronei Quit (Ping timeout: 60 seconds)

[10:03] * glenn Quit (Client closed connection)

[10:04] * mollydotcom Quit ("Page closed")

[10:04] * ChrisL Quit (Ping timeout: 60 seconds)

[10:05] * lstorset Quit (Ping timeout: 60 seconds)

[10:05] * cox Quit (Ping timeout: 60 seconds)

[10:06] * sakkuru Quit (Ping timeout: 60 seconds)

[10:07] * nsakai has joined #css

[10:07] * plh Quit (Ping timeout: 60 seconds)

[10:08] * r12a Quit ()

[10:08] * sylvaing is now known as sylvaing_away

[10:08] * nsakai Quit ("")

[10:09] * TabAtkins_ Quit (Ping timeout: 60 seconds)

[10:11] * kawabata Quit (Ping timeout: 60 seconds)

[10:14] * liam Quit (Ping timeout: 60 seconds)

[10:14] * sylvaing_away is now known as sylvaing

[10:17] * lmclister Quit (Ping timeout: 60 seconds)

[10:18] * SimonPieters Quit (Client closed connection)

[10:19] * rotsuya__ Quit (Client closed connection)

[10:19] * kensaku Quit (Client closed connection)

[10:22] * dbaron Quit ("8403864 bytes have been tenured, next gc will be global.")

[10:23] * JohnJansen Quit (Ping timeout: 60 seconds)

[10:25] * Rossen Quit (Ping timeout: 60 seconds)

[10:28] * Rossen has joined #css

[10:31] * smfr Quit (smfr)

[10:33] * glenn has joined #css

[10:34] * antonp has joined #css

[10:38] * SimonSapin Quit (Ping timeout: 60 seconds)

[10:41] * smfr has joined #css

[10:41] * smfr Quit (smfr)

[10:48] * leaverou is now known as leaverou_away

[10:48] * darktears_ Quit (Client closed connection)

[10:49] * darktears_ has joined #css

[10:49] * Rossen Quit (Ping timeout: 60 seconds)

[10:53] * stearns has joined #css

[10:55] * drublic Quit (Client closed connection)

[10:56] * stearns Quit (Client closed connection)

[10:56] * stearns has joined #css

[10:57] * Norbert has joined #css

[11:01] * trackbot has joined #css

[11:05] * antonp Quit (Ping timeout: 60 seconds)

[11:06] * glenn Quit (Client closed connection)

[11:10] * antonp has joined #css

[11:11] * Kid has joined #css

[11:12] * antonp1 has joined #css

[11:13] * leaverou_away is now known as leaverou

[11:14] * antonp Quit (Ping timeout: 60 seconds)

[11:14] * leaverou is now known as leaverou_away

[11:20] * drublic has joined #css

[11:28] * sylvaing is now known as sylvaing_away

[11:29] * sylvaing_away is now known as sylvaing

[11:42] * Norbert Quit (Norbert)

[11:52] * sylvaing is now known as sylvaing_away

[12:28] * SimonSapin has joined #css

[12:39] * SamB_Mac_ has joined #css

[12:39] * SamB_MacG5 Quit (Client closed connection)

[12:39] * SimonSapin Quit (Ping timeout: 60 seconds)

[13:00] * sylvaing_away is now known as sylvaing

[13:13] * Norbert has joined #css

[13:27] * Ms2ger has joined #css

[13:42] * antonp has joined #css

[13:44] * tantek has joined #css

[13:45] * antonp1 Quit (Ping timeout: 60 seconds)

[13:45] * glenn has joined #css

[13:53] * r12a has joined #css

[13:59] * sylvaing is now known as sylvaing_away

[14:09] * krit has joined #css

[14:12] * cabanier has joined #css

[14:18] * sylvaing_away is now known as sylvaing

[14:20] * antonp1 has joined #css

[14:22] * antonp Quit (Ping timeout: 60 seconds)

[14:28] * sylvaing is now known as sylvaing_away

[14:30] * drublic Quit (Client closed connection)

[14:31] * drublic has joined #css

[14:34] * rotsuya has joined #css

[14:35] * drublic Quit (Ping timeout: 60 seconds)

[14:35] * antonp has joined #css

[14:36] * antonp1 Quit (Ping timeout: 60 seconds)

[14:38] * r12a Quit ()

[14:38] * tomoyuki has joined #css

[14:41] * mwenge Quit (Ping timeout: 60 seconds)

[14:45] * rotsuya Quit (Client closed connection)

[14:48] * rotsuya has joined #css

[14:51] * antonp1 has joined #css

[14:52] * antonp Quit (Ping timeout: 60 seconds)

[14:53] * dino has joined #css

[14:53] * Norbert Quit (Norbert)

[14:54] * krit Quit ("Leaving.")

[15:00] * liam has joined #css

[15:02] * glenn Quit (Client closed connection)

[15:14] * hiroki has joined #css

[15:23] * rotsuya Quit (Client closed connection)

[15:32] * glenn has joined #css

[15:33] * hiroki Quit ()

[15:33] * kensaku has joined #css

[15:34] * antonp1 Quit (antonp1)

[15:44] * Ms2ger Quit ("nn")

[15:46] * dino Quit (dino)

[16:04] * tantek Quit (Ping timeout: 60 seconds)

[16:04] * cabanier Quit (Ping timeout: 60 seconds)

[16:04] * tomoyuki Quit (Ping timeout: 60 seconds)

[16:09] * cabanier has joined #css

[16:20] * isherman1 Quit ("Leaving.")

[16:30] * cabanier Quit (Ping timeout: 60 seconds)

[16:38] * cabanier has joined #css

[16:47] * SimonSapin has joined #css

[17:10] * SimonSapin1 has joined #css

[17:10] * SimonSapin Quit (Client closed connection)

[17:12] * Kid Quit (Client closed connection)

[17:14] * SimonSapin1 Quit (Ping timeout: 60 seconds)

[17:19] * cabanier Quit (Ping timeout: 60 seconds)

[17:22] * yaso has joined #css

[17:23] * yaso Quit (yaso)

[17:26] * cabanier has joined #css

[17:39] * cabanier Quit (Ping timeout: 60 seconds)

[17:40] * cabanier has joined #css

[17:40] * shepazu has joined #css

[18:09] * isherman has joined #css

[18:39] * glenn Quit (Ping timeout: 60 seconds)

[18:44] * kensaku Quit (Client closed connection)

[19:09] * shepazu Quit ("is sleepy")

[19:36] * glenn has joined #css

[19:56] * kensaku has joined #css

[20:14] * cabanier Quit (Ping timeout: 60 seconds)

[20:15] * kensaku Quit (Client closed connection)

[20:47] * Norbert has joined #css

[20:56] * paul___irish Quit ("ZNC - http://znc.sourceforge.net")

[21:04] * paul___irish has joined #css

[21:33] * Norbert Quit (Ping timeout: 60 seconds)

[21:39] * rotsuya has joined #css

[21:47] * Norbert has joined #css

[22:21] * sylvaing_away is now known as sylvaing

[22:29] * tomoyuki has joined #css

[22:34] * Disconnected.

[22:34] * CSSWG_LogBot has joined #css

[22:34] * Topic is '#css We tjoml we [refer s;ogjt;u tje pver;fpw regopms a[[rpacj tp tje exact sumtax tjat regopms os isomg rogjt mpw. becaise ot'

[22:34] * Set by glazou on Sun Oct 28 09:26:36 PDT 2012

[22:34] * leaverou_away Quit (Ping timeout: 60 seconds)

[22:34] * boblet has joined #css

[22:35] * shans_away has joined #css

[22:35] * shans_away is now known as shans

[22:35] * plinss Quit (Ping timeout: 60 seconds)

[22:35] * sylvaing Quit (Ping timeout: 60 seconds)

[22:36] * leaverou_away has joined #css

[22:36] * leaverou_away is now known as leaverou

[22:36] * plinss has joined #css

[22:36] * sylvaing has joined #css

[22:41] * tomoyuki Quit (tomoyuki)

[22:47] * yamaday has joined #css

[22:47] * rotsuya Quit (Ping timeout: 60 seconds)

[22:51] * glenn Quit (Ping timeout: 60 seconds)

[22:54] * Norbert Quit (Norbert)

[22:58] * rotsuya has joined #css

[23:00] * rotsuya Quit (Client closed connection)

[23:03] * glenn has joined #css

[23:08] * yamaday Quit ("TakIRC")

[23:21] * plh has joined #css

[23:22] * Norbert has joined #css

[23:26] * plh Quit (Ping timeout: 60 seconds)

[23:29] * Norbert Quit (Norbert)

[23:29] * kensaku has joined #css

[23:33] * plh has joined #css

[23:35] * kensaku Quit (Client closed connection)

[23:50] * SimonSapin has joined #css

[23:57] * plh Quit (Ping timeout: 60 seconds)

These logs were automatically created by CSSWG_LogBot on irc.w3.org using the Java IRC LogBot.