02:44:49 <krit> krit has joined #css
03:43:33 <krit1> krit1 has joined #css
05:21:43 <isherman1> isherman1 has joined #css
06:15:31 <krit> krit has joined #css
06:17:09 <cabanier> cabanier has joined #css
06:27:33 <SimonSapin> SimonSapin has joined #css
07:15:00 <antonp> antonp has joined #css
07:49:47 <JohnJansen> JohnJansen has joined #CSS
07:50:16 <tomoyuki> tomoyuki has joined #css
07:52:29 <JohnJansen> JohnJansen has joined #CSS
07:53:49 <JohnJansen> JohnJansen has joined #CSS
07:55:20 <JohnJansen> I'm observing in the Browser Testing and Tools WG this morning.
08:01:26 <Zakim> Zakim has joined #css
08:01:38 <plinss> rrsagent make logs public
08:01:47 <plinss> zakim, this will be style
08:01:47 <Zakim> I do not see a conference matching that name scheduled within the next hour, plinss
08:01:54 <Kid> Kid has joined #css
08:02:05 <plinss> rrsagent, pointer?
08:02:05 <RRSAgent> See http://www.w3.org/2012/10/29-css-irc#T08-02-05
08:06:43 <SteveZ> SteveZ has joined #css
08:08:02 <shepazu> shepazu has joined #css
08:09:26 <shepazu> shepazu has joined #css
08:10:19 <liam> liam has joined #css
08:11:41 <cabanier> cabanier has joined #css
08:12:14 <Rossen> Rossen has joined #css
08:12:33 <krit> krit has joined #css
08:13:36 <stearns> stearns has joined #css
08:13:53 <plh> plh has joined #css
08:15:03 <SimonSapin> SimonSapin has joined #css
08:15:22 <franremy> franremy has joined #css
08:18:03 <glazou> glazou has joined #css
08:18:19 <antonp> antonp has joined #css
08:18:20 <TabAtkins_> TabAtkins_ has joined #css
08:18:27 <dbaron> dbaron has joined #css
08:18:56 <arronei> arronei has joined #css
08:18:58 <TabAtkins_> ScribeNick: TabAtkins
08:19:03 <TabAtkins_> ScribeNick: TabAtkins_
08:19:06 <divya> divya has joined #css
08:19:53 <rhauck> rhauck has joined #css
08:20:00 <TabAtkins_> Topic: Relationship with html and css wg
08:20:19 <TabAtkins_> glazou: We still have no definition of what a scoped stylesheet is in CSS.
08:20:26 <mgylling> mgylling has joined #css
08:20:29 <TabAtkins_> TabAtkins: fantasai and I will take care of that next month.
08:20:36 <TabAtkins_> glazou: Also HTML added new selectors, etc.
08:20:46 <plh> (ie in 10 minutes)
08:20:49 <Reinaldo> Reinaldo has joined #css
08:20:52 <TabAtkins_> glazou: PLH is also concerned about the TTA specs.
08:21:09 <TabAtkins_> glazou: The length of time they're taking.
08:21:14 <kensaku_> kensaku_ has joined #css
08:21:15 <TabAtkins_> glazou: I tried to say that they were complex specs.
08:21:24 <TabAtkins_> glazou: But they're already well interoperable.
08:21:34 <TabAtkins_> Topic: Agenda
08:21:43 <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0304.html
08:21:55 <TabAtkins_> stearns: First issue is box generation.
08:22:02 <TabAtkins_> stearns: I posted how I think this issue should be handled in the spec.
08:22:10 <TabAtkins_> stearns: I don't think box generation is required for CSS regions.
08:22:19 <TabAtkins_> stearns: The issue is how to handle more content than will fit in a fixed region chain.
08:22:34 <TabAtkins_> stearns: We've added auto-height regions and the regions processing model to address this.
08:22:45 <TabAtkins_> stearns: So handling more content in a region is the same as in any other element.
08:22:49 <TabAtkins_> stearns: So I'd liketo close this issue.
08:22:50 <kazutaka> kazutaka has joined #css
08:22:51 <lmclister> lmclister has joined #css
08:22:56 <TabAtkins_> howcome: Examples?
08:23:24 <dino> dino has joined #css
08:23:25 <TabAtkins_> stearns: The very first example in the spec has an example - the last region is auto height and will just take the rest of the flow.
08:23:31 <TabAtkins_> howcome: What about pagination?
08:23:41 <TabAtkins_> stearns: No effect on printing - it'll break across pages just like a normal element.
08:23:47 <kawabata> kawabata has joined #css
08:24:11 <TabAtkins_> stearns: I got one response on the list from Anton saying it was reasonable.
08:24:40 <TabAtkins_> howcome: What dimensions does it expand?
08:24:48 <TabAtkins_> stearns: Same as an auto-height div.
08:25:13 <TabAtkins_> stearns: The email goes into what you can do witht he last region - you can make it auto height, scrollable, overflow:visible; everything you can do with a normal element.
08:26:04 <sakih> sakih has joined #css
08:26:06 <TabAtkins_> TabAtkins_: I'm satisfied that this concludes the issue - the last region in a chain is no longer restricted, and you can do everything you can do with a normal element.
08:26:08 <yamaday> yamaday has joined #css
08:26:38 <TabAtkins_> stearns: The issue as stated is that region chains can't handle a varaible amount of content.  At the time the issue was raised, this was true.  It's no longer.
08:26:57 <TabAtkins_> stearns: We could close this issue and let you raise further issues.
08:27:17 <TabAtkins_> fantasai: Can you have a region  in the middle of the chain that's auto-height with a max-height, where it overflows to the next region in the chain?
08:27:25 <TabAtkins_> stearns: Yes, that's what the processing model now addresses.
08:27:30 <lstorset> lstorset has joined #css
08:27:59 <TabAtkins_> RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary amounts of content in a region chain.
08:28:59 <TabAtkins_> Rossen: can you swap css3-ui with something in the afternoon? I'm waiting for Tantek and Sylvain.
08:29:07 <yamaday> join #css
08:30:55 <vhardy_> vhardy_ has joined #css
08:31:52 <TabAtkins_> Topic: HTML & CSS
08:32:01 <TabAtkins_> plh: HTML plans to move to CR by the end of the year.
08:32:15 <TabAtkins_> plh: So if there are any concersn from the CSSWG, I'd like to get it now.
08:32:23 <TabAtkins_> plh: Are there any issues from the CSSWG?
08:32:28 <TabAtkins_> glazou: I have three issues.
08:32:33 <TabAtkins_> glazou: The first is organization.
08:32:46 <TabAtkins_> glazou: The liaison between html and css - there has been none.
08:32:58 <TabAtkins_> glazou: The HTML spec concerns bits of CSS related to scoped stylesheets and selectors which were never discussed with us.
08:33:11 <TabAtkins_> glazou: I call that a big issue, since the htmlwg charter contains a liaison with us.
08:33:23 <TabAtkins_> glazou: Don't care what side the problem lies on, but it needs to be solved.
08:33:25 <fantasai> s/liaison/mandatory liaison/
08:33:28 <TabAtkins_> glazou: Second problem is technical.
08:33:34 <TabAtkins_> glazou: The html spec contains scoped stylesheets.
08:33:53 <TabAtkins_> glazou: There's a grammar for scoped stylesheets in html, but we don't ahve a formal definition of how they'll work in CSS.
08:34:12 <TabAtkins_> glazou: There's no material the html spec can reference normatively.
08:34:20 <TabAtkins_> glazou: Third point is about CSS pseudoclasses.
08:34:54 <TabAtkins_> glazou: There are pseudoclasses inthe HTML spec - some are related to pseudos in css3-ui, but we never had a joint group or submission saying "we plan to include things that are in your charter in our spec, how can we do that, is that correct, etc."
08:35:14 <TabAtkins_> glazou: So it seems to me the process between the two WGs are completely broken.
08:35:25 <TabAtkins_> glazou: We dont' have these issues with the SVGWG - we work together great.
08:35:36 <TabAtkins_> glazou: So we have two things in the HTML spec that should be defined on our side.
08:36:03 <dbaron> TabAtkins: On selectors, we've either defined everything or HTML is just defining the host language part of it
08:36:15 <dbaron> TabAtkins: ... in cases where things are to be defined by the host language
08:36:21 <vhardy__> vhardy__ has joined #css
08:36:34 <TabAtkins_> plh: I like to understand if other people in the CSSWG share your opinions.
08:36:43 <mjs> mjs has joined #css
08:36:47 <TabAtkins_> plh: And some of the CSSWG is in the HTMLWG, so if there's no liaison, I wonder what's oging on.
08:37:32 <TabAtkins_> dbaron: We've been through the form control stuff before, but I agree with Tab that there's no problem there.
08:37:33 <mjs> q+
08:37:54 <TabAtkins_> dbaron: I don't think the <style scoped> stuff is defined well anywhere yet, or if it reflects quite what our idea of how it will work is.
08:38:30 <stearns> TabAtkins_: Me will define
08:38:36 <TabAtkins_> plh: Is <style scoped> handled properly in HTML?
08:38:56 <TabAtkins_> fantasai: First thing is how selectors are scoped.
08:39:04 <TabAtkins_> fantasai: Second is a mechanism to change how they're scoped.
08:39:08 <franremy> (just a note: maybe we also need to speak about shadow dom and its interaction with CSS, those specs also contain quite a bite of CSS)
08:39:09 <TabAtkins_> fantasai: Third is howt he cascade is scoped.
08:39:28 <TabAtkins_> fantasai: The fourth is how globally scoped things like @font-face are handled.
08:39:35 <Norbert> Norbert has joined #css
08:39:47 <yamaday> yamaday has joined #css
08:40:04 <TabAtkins_> fantasai: So there's four aspects of this. We have a definition for the first, and Tab and I are planning to work on a the third.
08:40:09 <TabAtkins_> fantasai: Dunno about the second and fourth.
08:40:13 <Liam|XMLCore> Liam|XMLCore has joined #css
08:40:16 <sakkuru_> sakkuru_ has joined #css
08:40:18 <TabAtkins_> TabAtkins_: The fourth is defined in hTML now - Boris got it fixed.
08:40:39 <TabAtkins_> fantasai: It doesn't matter if the HTMLWG editor is in the room or not, if they aren't bringing things up to us for review, etc.
08:40:53 <TabAtkins_> dbaron: I think we know about this - we don't need a formal email asking us to review it.
08:41:47 <fantasai> dbaron: The interesting question is, is there anything else we're not aware of.
08:41:52 <glazou> Zakim, ack mjs
08:41:52 <Zakim> I see no one on the speaker queue
08:43:03 <dbaron> dbaron: I don't think we need a formal email to inform us of something that we've discussed multiple times that we haven't received a formal email about.
08:43:17 <plh> plh has joined #css
08:43:19 <glazou> glazou: I think we do formal link between groups
08:43:22 <plh> q?
08:43:24 <TabAtkins_> TabAtkins_ has joined #css
08:43:30 <glazou> mjs: this is first time I hear about these issues
08:43:37 <glazou> glazou: no
08:43:46 <fantasai> glazou: I sent them as LC comments during the vote
08:44:05 <fantasai> glazou: Never got a reply
08:44:26 <plh> q+ PaulCotton
08:44:28 <fantasai> plinss: We sent comments last year as a WG, and the bug was closed WONTFIX by hixie
08:44:39 <fantasai> mjs: We have a clear process for escalating issues
08:44:58 <fantasai> mjs: We love technical input, but don't go out of our way to solicit it
08:45:33 <fantasai> mjs invites CSSWG members to participate in HTMLWG meetings at TPAC
08:46:11 <fantasai> mjs: Recently had change of editors, trying to be more open to input
08:46:25 <glazou> Zakim, ack PaulCotton
08:46:25 <Zakim> I see no one on the speaker queue
08:46:40 <fantasai> PaulCotton: Want to be more factual here. What are the bug numbers raised on these issues?
08:46:57 <fantasai> PaulCotton: What are the comments that were made for LC?
08:47:15 <glazou> Zakim, q+
08:47:15 <Zakim> I see glazou on the speaker queue
08:47:40 <fantasai> PaulCotton: If there weren't issues raised as tracker issues, we don't pay attention to them.
08:48:26 <fantasai> glazou: We discussed on HCG these issues
08:48:38 <dbaron> plinss: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13693
08:48:42 <fantasai> TabAtkins: Raised as email comments; you're not allowed to ignore those just because bug wasn't filed
08:49:09 <fantasai> glazou: All the comments, through various channels were dismissed.
08:49:41 <yamaday> yamaday has left #css
08:49:55 <dbaron> fantasai: I think there are three issues, 2 technical.  I think selectors issue already addressed by selectors4.
08:50:07 <dbaron> mjs: for record, bug doesn't mention scoped style sheets at all
08:50:24 <yamaday> yamaday has joined #css
08:50:25 <dbaron> glazou: Then HTML is referencing a non-normative document (FPWD)
08:50:32 <dbaron> plh: Where do you think selectors4 will be in 2014?
08:50:37 <dbaron> fantasai: Probably last call or CR.
08:50:41 <dbaron> glazou: maybe, maybe not
08:50:57 <dbaron> fantasai: So that problem is solved as long as HTML correctly referencing selectors4.
08:51:06 <dbaron> fantasai: Second issue is about scoped style, 4 sub-issues.
08:51:12 <dbaron> ted: Already at-risk for HTML5.
08:51:23 <dbaron> plh: I would ... the HTML WG to drop the feature and put in HTML.next.
08:51:34 <dbaron> plh: Sounds too risky to keep in HTML 5.0.
08:51:43 <dbaron> mjs: I'd like a record of the four issues.
08:51:49 <dbaron> TabAtkins, fantasai: in minutes
08:51:49 <plh> s/.../advocate/
08:51:56 <dbaron> TabAtkins, fantasai: We should have a draft in the next month.
08:52:11 <dbaron> fantasai: This is a complicated feature that ought to have a stable definition, not one writen 2 months before CR.
08:52:13 <dbaron> dirk: ???
08:52:22 <dbaron> fantasai: Third issue is the process issue.
08:52:43 <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.
08:52:50 <krit> s/???/Since we don't have one implementation, it may should not be in HTML5.0/
08:53:03 <dbaron> fantasai: Whether HTML WG does this by assigning a task to common members or some other process.  Fact is it hasn't happened.
08:53:06 <dbaron> glazou: or an email
08:53:29 <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.
08:53:41 <dbaron> PaulCotton: As a co-chair it's pretty frustrating.  I try to solicit input from HTML WG and get nothing.
08:53:48 <dbaron> PaulCotton: Not even from members of other WG.
08:53:48 <dbaron> q+
08:53:57 <dbaron> PaulCotton: So the ??? hasn't worked in the past.
08:54:02 <glazou> Zakim, ack glazou
08:54:02 <Zakim> I see dbaron on the speaker queue
08:54:03 <dbaron> PaulCotton: I think we probably need somebody on point here.
08:54:12 <dbaron> PaulCotton: I think we need somebody to draw attention to these kinds of things.
08:54:16 <dbaron> PaulCotton: We have new editors now.
08:54:28 <glazou> Zakim, q+
08:54:28 <Zakim> I see dbaron, glazou on the speaker queue
08:54:35 <dbaron> PaulCotton: I think with new editors: bugs, interop problems, ... bring that to your attention.
08:54:46 <glazou> Zakim, ack dbaron
08:54:46 <Zakim> I see glazou on the speaker queue
08:54:50 <dbaron> PaulCotton: I think the other route, bringing your (CSS) documents to attention of HTML WG isn't going to work.
08:54:59 <glazou> Zakim, q+ fantasai
08:54:59 <Zakim> I see glazou, fantasai on the speaker queue
08:55:10 <glazou> Zakim, q+ GlennAdams
08:55:10 <Zakim> I see glazou, fantasai, GlennAdams on the speaker queue
08:55:16 <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.
08:55:18 <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
08:55:24 <TabAtkins_> dbaron: I think there is a lot of value in giving notice to WGs about things that are related.
08:55:32 <TabAtkins_> dbaron: I don't see that the response needs to be from the WG as a whole.
08:55:49 <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.
08:55:49 <glazou> Zakim, ack me
08:55:49 <Zakim> I see fantasai, GlennAdams on the speaker queue
08:56:06 <TabAtkins_> glazou: Paul, you say you'd like someone in your WG to coordinate and give us feedback.
08:56:32 <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.
08:56:43 <TabAtkins_> hober: In CSS/SVG, we have the FXTF to help discuss issues.
08:56:46 <TabAtkins_> glazou: Even before that.
08:56:55 <TabAtkins_> glazou: It's not hard.  It's just a matter of person-to-person email.  It's doable.
08:56:59 <glazou> Zakim, ack fantasai
08:56:59 <Zakim> I see GlennAdams on the speaker queue
08:57:17 <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.
08:57:26 <TabAtkins_> fantasai: I think we've done that, but please point out if we need to improve.
08:57:42 <mjs> q+
08:57:47 <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.
08:58:08 <TabAtkins_> fantasai: The members of the CSSWG that aren't in the HTMLWG haven't been informed about thing sin HTML that affect CSS.
08:58:17 <glazou> Zakim, ack GlennAdams
08:58:17 <Zakim> I see mjs on the speaker queue
08:58:19 <TabAtkins_> fantasai: In particular, HTML defines things that are fundamentally not in their charter.
08:58:26 <TabAtkins_> fantasai: Which may be a bit over the line.
08:58:46 <glenn> glenn has joined #css
08:58:55 <glazou> Zakim, q+ PaulCotton
08:58:55 <Zakim> I see mjs, PaulCotton on the speaker queue
08:59:02 <TabAtkins_> glenn: In that regard, Hixie has been communicating with me about things that affect the CSSOM.
08:59:08 <glazou> Zakim, ack mjs
08:59:08 <Zakim> I see PaulCotton on the speaker queue
08:59:20 <TabAtkins_> mjs: Can someone give me an example of a time that the CSSWG has informed the HTMLWG about a relevant spec change.
08:59:36 <fantasai> TabAtkins_: element function in images spec, wanted to integrate with HTML in a particular way
08:59:48 <fantasai> TabAtkins_: I sent an email into HTMLWG and hixie fixed it for me
08:59:52 <fantasai> TabAtkins_: Done similar things with WebApps
09:00:05 <glazou> Zakim, ack PaulCotton
09:00:05 <Zakim> I see no one on the speaker queue
09:00:29 <fantasai> PaulCotton: Hixie is no longer an editor in the HTMLWG
09:00:31 <hober> I believe TabAtkins was referring to https://www.w3.org/Bugs/Public/show_bug.cgi?id=14028
09:00:45 <SteveZ> SteveZ has joined #css
09:00:51 <fantasai> PaulCotton: If you want to communicate wrt HTML5 spec, it's no longer hixie.
09:01:18 <fantasai> PaulCotton: When wanting changes with CR, need to communicate with current editors, not hixie
09:01:22 <glazou> Zakim, q+
09:01:22 <Zakim> I see glazou on the speaker queue
09:01:29 <fantasai> q+
09:01:42 <fantasai> PaulCotton: Question was what happens to changes hixie makes
09:01:50 <fantasai> PaulCotton: Our editors are triaging all of those changes
09:01:58 <fantasai> PaulCotton: For changes that go into 5.1, we're previewing in WG
09:02:07 <fantasai> PaulCotton: But editors in WG are about to produce CR drafts
09:02:17 <fantasai> PaulCotton: Those CR drafts will be only changes that are interoperability-based
09:02:27 <fantasai> PaulCotton: It's possible that change from WHATWG would make it into 5.1
09:02:37 <fantasai> PaulCotton: Also possible that if it's an interop problem, it would get into 5.0
09:02:56 <fantasai> PaulCotton: But not guaranteed
09:03:02 <glazou> Zakim, ack me
09:03:02 <Zakim> I see fantasai on the speaker queue
09:03:32 <fantasai> glazou: Would like us to use HTCG a bit more for communication. You are three co-chairs, but rarely attend the calls
09:03:52 <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.
09:04:06 <fantasai> glazou: When I said in HTCG that there were problems wrt scoped styles, there was no reaction from you.
09:04:10 <fantasai> glazou: We have a tool in our hands.
09:04:19 <fantasai> mjs: I find the coordination calls useless
09:04:23 <fantasai> glazou: Then let's do that by email
09:04:41 <fantasai> [HTCG doesn't have regular calls any more, just as needed]
09:04:44 <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
09:05:12 <fantasai> glazou: We've had this communication channel for years; it hasn't been used.
09:05:18 <glazou> Zakim, ack fantasai
09:05:18 <Zakim> I see no one on the speaker queue
09:05:27 <TabAtkins_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16169
09:05:44 <TabAtkins_> fantasai: Maciej wanted examples of us contacting the HTMLWG about changes affecting them.
09:05:52 <dbaron> Present (in back row): Rik Cabanier, ???, ???, Rebecca Hauck, ???, Israel Noto Garcia, Jet Villegas, ???, ???
09:05:55 <TabAtkins_> fantasai: First, we don't include things within the scope of the HTML charter within our specs.
09:06:05 <florianr> florianr has joined #css
09:06:28 <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.
09:06:58 <stearns> dbaron: some ???s: Israel Noto Garcia, Laurence Mclister, Rik Cabanier
09:07:07 <fantasai> mjs: How would you like us to inform you of changes we need in CSS? Filing a bug?
09:07:13 <fantasai> TabAtkins: Send an email to www-style.
09:07:45 <fantasai> mjs asks for example
09:07:54 <fantasai> TabAtkins: The bugs I filed against HTML are examples
09:08:04 <dbaron> mjs (above): Can you point to an email you've sent that's an example of what you'd consider sufficient notice to you?
09:08:26 <TabAtkins_> fantasai: Hixie has sent us emails asking for specific changes in CSS specs, and that's exactly how it should be handled.
09:08:26 <dbaron> fantasai: Hixie sent us some emails asking for changis in CSS specs; those were exactly how it should be handled.
09:08:42 <plh> q?
09:08:42 <dbaron> fantasai: What wasn't handled was saying that we drafted a new CSS feature and put it in HTML5 spec.
09:08:43 <TabAtkins_> fantasai: What wasn't handled was something informing us of some of the CSS features in HTML being drafted at all.  ^_^
09:09:02 <TabAtkins_> mjs: So what do you need to continue technically to resolve any issues in HTML?
09:09:19 <plh> q+
09:09:42 <TabAtkins_> mjs: As far as I know, all we've gotten so far in the HTMLWG about style scoped is that it's undefined, from Glazou.
09:09:51 <jet> jet has joined #CSS
09:09:55 <TabAtkins_> mjs: But today we have four things being about it.
09:10:06 <TabAtkins_> TabAtkins_: They're four ways of saying a specific thing is undefined.
09:10:34 <TabAtkins_> glazou: Scoped stylesheets will be a major way to copypaste stylesheets.  There are multiple deep technical issues to solve about these.  It won't happen today.
09:10:49 <TabAtkins_> glazou: My take is that it's so undefined right now, and there's so much on our radar, it's at risk, but you should drop it for now.
09:11:05 <TabAtkins_> glenn: Are there two interop impls?
09:11:20 <TabAtkins_> TabAtkins_: No - we've specifically held back our impl because it's not interop with how we know we want it to act.
09:11:30 <hober> So, has someone filed a "Drop <style scoped>" bug?
09:11:35 <TabAtkins_> glazou: It's so undefined, and will take long enough to do so, that it should be dropped.
09:11:56 <TabAtkins_> mjs: If best solution turns out that it shoudl be dropped, that's fine.
09:12:00 <TabAtkins_> mjs: But we need a bug and to be informed about this.
09:12:42 <TabAtkins_> mjs: I've heard several rapid-fire problems listed today, but we need those details to be brought to us.
09:13:09 <fantasai> TabAtkins_: The original problem we're bringing up is that nobody told us about it, or asked us to define it. Just now picking it up because we have to
09:13:35 <fantasai> TabAtkins_: But even within HTMLWG, ppl know that it's not well-enough defined to be implemented right now. bzbarsky has given feedback; Chrome is holding back implementation because it doesn't match what we want to do
09:13:54 <fantasai> TabAtkins_: The problem is well-known within HTMLWG
09:14:02 <plh> q+ PaulCotton
09:14:19 <fantasai> glazou: One concrete example I said is specificity of selectors, don't know technical solution we choose, need discussion to happen, but will drastically impact solution. Not a 10-minutes discussion
09:14:35 <fantasai> glazou: Need to find compromise that satisfies everyone.
09:14:41 <tomoyuki> tomoyuki has joined #css
09:14:47 <fantasai> glazou: And it's on our side, not on yours. It's about how the cascade works. Not in the HTML spec.
09:14:54 <fantasai> glazou: Am I completely mistaken or what?
09:15:43 <TabAtkins_> plh: It seems to me that we have information on the style scoped about whether to keep it or not.
09:15:55 <franremy> q: can't we replace the scoped attribute with a :scope-root pseudo-class so that it doesn't have to be defined in HTML at all?
09:16:09 <TabAtkins_> mjs: I don't think we have.  You guys have told us multiple rapid-fire problems, but they haven't been listed.
09:16:21 <plh> q?
09:16:21 <dbaron> q+
09:16:23 <plh> ack plh
09:16:29 <TabAtkins_> TabAtkins_: they're all variants of "it's undefined".  The specifics dont' matter. You've known it was undefined since we told you a year ago.
09:16:38 <TabAtkins_> mjs: Okay, so what should we do specifically?
09:16:41 <TabAtkins_> glazou: Drop it.
09:16:47 <plh> q?
09:16:48 <TabAtkins_> mjs: Give us that feedback specifically.  Send it in.
09:17:08 <TabAtkins_> mjs: Please submit a comment to the HTMLWG saying that and giving rationale.
09:17:13 <TabAtkins_> glazou: I've done that multiple times.
09:17:27 <TabAtkins_> mjs: I looked up your comments, and you didn't actually say that.
09:17:41 <TabAtkins_> glazou: PLH, do we really discuss inter-WG things via bugs only?
09:17:50 <TabAtkins_> glazou: I don't understand why you need more input from us.
09:19:27 <TabAtkins_> PaulCotton: I asked for exact comments.  You pointed to a bug.  It was closed, you didn't reopen.
09:19:31 <evanli> evanli has joined #css
09:20:02 <TabAtkins_> mjs: The HTMLWG has a process.  If you engage in it, we'll respond.  But berating us won't solve a problem.  If the problem is that it's underdefined and won't be solved in time, file a bug.
09:20:11 <TabAtkins_> mjs: If you're unwilling to engage in our process, then I won't help you.
09:20:29 <plh> --> http://lists.w3.org/Archives/Public/public-html/2012May/0080.html email from Tab regarding scoped
09:20:37 <dbaron> ack PaulCotton
09:20:52 <TabAtkins_> PaulCotton: Idon't quite agree with Philippe about ???...
09:21:01 <TabAtkins_> PaulCotton: This spec will be in CR for 18 months at least.
09:21:15 <TabAtkins_> PaulCotton: I think that marking it as at-risk with this evidence, is probably the right status.
09:21:19 <divya> s/Philippe/macej
09:21:32 <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.
09:21:52 <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.
09:22:04 <TabAtkins_> glenn: Agree.  At-risk is easier than dropping and restoring.
09:22:18 <TabAtkins_> mjs: It's at-risk right now.  We can enhance our at-risk list with annotations for reasoning.
09:22:42 <TabAtkins_> mjs: Getting dependencies right, getting implementors to implement, define it.
09:23:20 <liam> liam has joined #css
09:24:42 <krit> Zakim, q+
09:24:42 <Zakim> I see dbaron, krit on the speaker queue
09:25:10 <TabAtkins_> plh: Other issue is Selectors 4 having some of the HTML selectors.
09:25:20 <plh> --> http://dev.w3.org/html5/spec/single-page.html#pseudo-classes
09:25:38 <TabAtkins_> TabAtkins_: The ones in HTML right now are all just the host-language stuff.  The real new things are in WebVTT.
09:25:49 <TabAtkins_> mjs: WebVTT is no longer a HTMLWG deliverable.  It's in a CG.
09:26:11 <TabAtkins_> glazou: This is a quite heated discussion, I agree.  But we'd love to help the WG witht he HTML spec.  We'd love to be pinged when it's on our scope.
09:26:13 <mjs> mjs has joined #css
09:26:35 <Bert> q+ to mention another (some day) coord. issue: <DETAILS>
09:26:43 <TabAtkins_> hober: Right now we're trying to remove/drop things, not add.
09:26:53 <TabAtkins_> plh: But in HTML.next, if ever there is something new added, tell the CSSWG.
09:27:26 <TabAtkins_> PaulCotton: The way we're pulling from WHATWG to HTML5.1, the triage team should probably check for CSS-specific things and send an email to the CSSWG.
09:27:56 <TabAtkins_> mjs: In the past when stuff got put into the spec, I'll be honest and say it was largely editor recalcitrance.
09:28:06 <Rossen> Rossen has joined #css
09:28:50 <TabAtkins_> Bert: About a year ago I sent a personal note that I think there's a better way to define the <details> element that makes it easier to style in pure CSS.
09:29:07 <TabAtkins_> plh: Feel free to bring that up in our meeting Thu/Fri.
09:29:26 <dbaron> break-duration: calc(15 * 60s)
09:30:20 <Bert> q-
09:30:32 <TabAtkins_> zakim, ack krit
09:30:32 <Zakim> I see no one on the speaker queue
09:31:34 <tomoyuki> tomoyuki has joined #css
09:35:39 <yaso> yaso has joined #css
09:35:50 <rubylin> rubylin has joined #css
09:36:57 <tomoyuki> tomoyuki has joined #css
09:39:21 <kotakagi> kotakagi has joined #css
09:40:40 <vhardy__> vhardy__ has joined #css
09:47:09 <yamaday> yamaday has joined #css
09:49:05 <yamaday> yamaday has joined #css
09:52:41 <tomoyuki> tomoyuki has joined #css
09:53:01 <yamaday> aaaaaaaaaaa
09:55:34 <John_Jansen> John_Jansen has joined #css
09:58:33 <rhauck> rhauck has joined #css
09:59:41 <JohnJansen> JohnJansen has joined #css
10:00:21 <kotakagi> kotakagi has joined #css
10:00:28 <yamaday> yamaday has joined #css
10:00:54 <drublic> drublic has joined #css
10:03:55 <lmclister> lmclister has joined #css
10:04:42 <rhauck> rhauck has joined #css
10:06:51 <yamaday> yamaday has joined #css
10:09:21 <tomoyuki> tomoyuki has joined #css
10:10:50 <mgylling> mgylling has joined #css
10:12:40 <cabanier> cabanier has joined #css
10:13:20 <TabAtkins_> TabAtkins_ has joined #css
10:13:32 <mjs> mjs has joined #css
10:13:35 <dbaron> </br>
10:14:06 <dbaron> Topic: Regions issues
10:14:15 <dbaron> Alan: 3 issues left
10:14:28 <divya> divya has joined #css
10:14:40 <TabAtkins_> stearns: The draft currently says that Regions create their own stacking contexts.  There's an issue on the draft that perhaps we shouldn't do that, and allow them to be non-stacking.
10:15:07 <TabAtkins_> stearns: My contention is that regions should behave more like the things that *do* create stacking contexts, like fixpos/flaots/etc, because we are taking content out of the flow and putting it somewhere else.
10:15:18 <Rossen> Rossen has joined #css
10:15:21 <TabAtkins_> stearns: Same justification for those applies to Regions.  Little case for interleaving content.
10:15:41 <TabAtkins_> dbaron: Floats actually create a pseudo-stacking context.
10:15:52 <TabAtkins_> antonp: I don't think authors like stacking contexts.
10:16:10 <TabAtkins_> hober: I think most authors don't know what a stacking context is, and when things interleave in weird ways, that's funky behavior.
10:16:19 <TabAtkins_> hober: Will probably result in performance issue, which we can avoid...
10:16:24 <TabAtkins_> hober: I don't think authors would interleave on purpose.
10:16:45 <TabAtkins_> antonp: The reason the funny painting model exists is because people had overflow they weren't expecting; floats and next paragraphs and etc.
10:16:55 <TabAtkins_> antonp: That's why text is painted after all background/borders/etc.
10:16:59 <Norbert_> Norbert_ has joined #css
10:17:02 <TabAtkins_> antonp: Makes overlaps less painful.
10:17:18 <TabAtkins_> antonp: So it was historically because there was a lot of overflow, and impls thought it was better to see content.
10:17:31 <TabAtkins_> dbaron: I'm not sure it was that logical of a process.
10:17:56 <TabAtkins_> dbaron: There's a decent chunk that was Hixie and I interpreting a vague chunk of the spec, and coming up with the one precise definition that satisfied it, then wrote tests and got impls, and that was that.
10:18:05 <TabAtkins_> dbaron: Never really learned how much of that was intentional.
10:18:36 <TabAtkins_> dbaron: The spec never quite said that the backgrounds of the next paragraph drew under the text of the next paragraph, but you could infer it from a rule about floats, which was similar.
10:18:48 <TabAtkins_> dbaron: The thing I'm slightly worried about is...
10:18:56 <TabAtkins_> dbaron: You're talking a region being a stacking context?
10:18:59 <TabAtkins_> dbaron: Each region?
10:19:15 <TabAtkins_> stearns: Each region is a context for the fragment of the flow in it.
10:19:41 <TabAtkins_> dbaron: My problem is when people put regions close to each other to give the illusion of continuous flow
10:19:51 <TabAtkins_> TabAtkins_: Like using them to make a "non-rectangular grid cell".
10:20:00 <TabAtkins_> dbaron: yeah.  But I think there might be weird issues now.
10:20:16 <TabAtkins_> stearns: That's only a problem if they break outside of the bounds of the region.
10:20:29 <TabAtkins_> dbaron: Not necessarily rare, with text slightly overflowing, etc.
10:20:36 <TabAtkins_> dbaron: Don't have a strong opinion, but I'ma little worriedabout that case.
10:20:44 <TabAtkins_> stearns: I'm not really sure what to do about that case.
10:20:52 <rotsuya> rotsuya has joined #css
10:21:03 <stearns> s/to do/to say/
10:21:11 <kensaku> kensaku has joined #css
10:21:11 <TabAtkins_> Rossen: No real opinion...
10:21:32 <TabAtkins_> Rossen: From the pov of having valid use-cases for where it's really interesting to have interleaving, we struggled to find such a use-case.
10:21:47 <TabAtkins_> Rossen: The one David is bringing up is somewhat valid for the content being laid out between the regions themselves.
10:21:52 <sakkuru> sakkuru has joined #css
10:22:00 <toms> toms has joined #css
10:22:07 <TabAtkins_> Rossen: It is more interesting to see how the rest of the content outside the regions interacts with the content inside.
10:22:15 <TabAtkins_> Rossen: This is why we'd prefer regions being their own stacking context.
10:22:26 <TabAtkins_> Rossen: So you don't have weird interleaving between parts of the regions.
10:22:26 <hsivonen> hsivonen has joined #css
10:22:45 <TabAtkins_> antonp: I buy that point.
10:23:14 <TabAtkins_> antonp: I'm kinda thinking, you got stuff flowing down the left, you got regions on the right, and you're directing flows through each, and if you've got a long word on the left it'll interleave with what's on the right.
10:23:29 <TabAtkins_> antonp: What about a pseudo-stacking context, so abspos doesn't have to deal with it?
10:24:11 <TabAtkins_> TabAtkins_: I think that limiting abspos is actually an important part of it.
10:24:23 <yamaday> yamaday has joined #css
10:24:43 <TabAtkins_> szilles: This seems a bit like the problems of composition in SVG - they introduced groups to denote what things are part of "the same thing" versus a different thing.
10:24:57 <TabAtkins_> szilles: Conceivably one could introduce a similar property that groups things like that.
10:25:23 <TabAtkins_> TabAtkins_: Like explicitly turning on stacking contexts without side effects?
10:25:45 <TabAtkins_> szilles: No, other way around.  Declaring that some stacking contexts are part of a group, so within that group they can interact, but they're still shielded from the rest of the group.
10:26:03 <TabAtkins_> Rossen: To add to this, it becomes more apparent once you bring content that's not quite in the same document into regions.
10:26:18 <TabAtkins_> Rossen: Then you have content from separate documents that can interleave.
10:26:30 <TabAtkins_> TabAtkins_: You're talking about IE's addition that lets them flow iframes into a region flow?
10:26:40 <Bert> q+ to compare regions with columns
10:26:41 <TabAtkins_> Rossen: Yeah.  You don't want an iframe to be interleaved with anything else.
10:26:57 <TabAtkins_> antonp: At the very least that says you want pseudo-stacking contexts.  It doesnt' necessarily talk about abspos.
10:27:23 <TabAtkins_> antonp: abspos is a weird beast.  But when people use it, they get frustrated that you can't choose where things are positioned from.
10:27:37 <TabAtkins_> antonp: By locking it into the region box, it seems you're taking away a little of the freedom they otherwise have.
10:28:34 <TabAtkins_> TabAtkins_: There's a workaround - flow the abspos into *another* region chain, and flow-from it somewhere outside higher in the document.
10:28:41 <TabAtkins_> Bert: That loses the auto position, though.
10:28:56 <tomoyuki> tomoyuki has joined #css
10:28:57 <TabAtkins_> TabAtkins_: If you're usign the auto position, you probably don't need to worry about stacking context.
10:29:19 <TabAtkins_> Bert: Most of the time when I use regions, I started using columns, then found a weird case, and had to replace the columns with regions.
10:29:30 <TabAtkins_> Bert: That means that I'd like them to act like columns.
10:30:15 <TabAtkins_> glazou: [something about columns across pages, and how regions would work the same way maybe?]
10:30:30 <TabAtkins_> Bert: Point is that I'd like columns to act the same way as regions.
10:30:52 <TabAtkins_> stearns: So that's an argument for Steve's suggestion - the ability to group contexts together.
10:31:10 <TabAtkins_> dbaron: So you say that having flow-from on an element makes it a stackign context automatically?
10:31:15 <TabAtkins_> stearns: yes, that's part of the spec right now.
10:31:24 <yaso> yaso has joined #css
10:31:42 <TabAtkins_> stearns: I have been arguing both sides of the issue with my teamf or months now, and I think I've come down on the side of stacking contexts.
10:32:06 <TabAtkins_> stearns: Possibly with a future mechanism to aggregate stacking contexts.
10:32:29 <TabAtkins_> TabAtkins_: I'm cool with that.  I just don't want automatic grouping, from a performance standpoint.
10:32:45 <TabAtkins_> stearns: Hyatt's doing some work with identical regions, which might be relevant there.
10:32:55 <TabAtkins_> stearns: So, are there any objections to keeping what the spec currently says?
10:33:24 <TabAtkins_> stearns: (i was arguing for the opposite position in my team, and I lost the argument)
10:34:26 <TabAtkins_> Bert: It doesn't sound quite right - it's like an implicit relpos, which limits what you can do with abspos.
10:35:00 <TabAtkins_> TabAtkins_: I think that there are enough implicit positioning containments already that we can argue this is a general limitation of *abspos*, not of any individual other spec, and should be fixed in abspos properly, by letting you override what you're positioning relative to.
10:35:16 <TabAtkins_> antonp: Bear in mind that we're not just talking about positioning, but also painting.
10:35:28 <TabAtkins_> antonp: If in the future we're going to let you throw your positioning root around, you're also changing positioning.
10:35:46 <TabAtkins_> s/changing positioning/changing painting/
10:35:53 <TabAtkins_> TabAtkins_: yeah, you're more or less moving it in the box tree.
10:36:29 <TabAtkins_> Bert: Another comparison is with shapes - if you can make two regions and flow between them, or put a shape on a single paragraph that duplicates the same size, why do those act differently?
10:37:15 <TabAtkins_> antonp: To be fair, you'll have different behavior anyway - the fragmentation is probably going to be different anyway.
10:37:24 <TabAtkins_> Rossen: Currently in shapes there's nothing taklinga bout this.
10:37:49 <TabAtkins_> Rossen: In the multishapes section, we're allowing multishapes.
10:37:59 <TabAtkins_> Rossen: Like if you extract a shape from an image, and it creates two circles.
10:38:09 <TabAtkins_> Rossen: The spec currently says its allowed, but doesn't define how it works.
10:38:44 <TabAtkins_> Rossen: Making a comparison based on that right now is a bit premature imo.
10:39:07 <TabAtkins_> Bert: maybe, but the examples I worked through often didn't matter - I could use multicol or regions, shapes or regions, they worked roughly equally well either way.
10:39:16 <TabAtkins_> Bert: So I thought that if they were so similar, they should perhaps all be the same.
10:39:27 <TabAtkins_> Bert: With their own possibilities, but the common elements should be the same.
10:39:45 <TabAtkins_> stearns: If we have stacking contexts, the only part that might be different is that content that overlaps at the boundaries might get painted over.
10:39:59 <TabAtkins_> stearns: That seems like a tiny edge-case for me.  You generally avoid overlap.
10:40:02 <cox_> cox_ has joined #css
10:40:11 <TabAtkins_> Bert: I was thinking about abspos, actually.
10:40:23 <TabAtkins_> Bert: But I'm not sure how important it really is.  I generally use abspos only as a last resort.
10:40:34 <TabAtkins_> stearns: It's certainly a limitation, and that's why I argued against it with my team.
10:40:42 <TabAtkins_> stearns: But finding use-cases where you want interleaved content...
10:40:44 <kotakagi> kotakagi has joined #css
10:40:49 <plh> plh has joined #css
10:40:56 <kotakagi2> kotakagi2 has joined #css
10:41:03 <liam> liam has joined #css
10:41:06 <TabAtkins_> stearns: From another direction, in all the use-cases we looked at, when you *have* interleaving, you always *want* a stacking context to prevent that from interleaving accidentally.
10:42:22 <TabAtkins_> TabAtkins_: So most interleaving is accidental and would benefit from stacking contexts, and the cases where it might be good are a corner-case, which might be best addressed in the future by a specialized property to group stacking contexts together.
10:42:29 <TabAtkins_> antonp: So are columns changing any?
10:42:31 <TabAtkins_> stearns: No.
10:42:47 <TabAtkins_> szilles: You'd need later to define that the stacking-context-grouping property auto-groups columns by default.
10:43:21 <TabAtkins_> arronei: Does it become a stacking context as soon as flow-from is set, even if it has no content?
10:43:31 <TabAtkins_> stearns: Yes, but then there's no content to be stacking-contexted.
10:43:32 <r12a> r12a has joined #css
10:43:47 <TabAtkins_> antonp: There was a comment from Hyatt about how content that flows through a region physically belong to the region.
10:43:50 <fantasai> r12a: http://wiki.csswg.org/topics/custom-ident-case-sensitivity
10:44:00 <TabAtkins_> antonp: Is this true, or does the content just flow through the space of the region?
10:44:29 <TabAtkins_> stearns: I think that's relevant.  If you're defining Regions to have stacking contexts, then it's the principle box of the Region that contains them, and the fragments of the flow are children of that in the box tree.
10:44:43 <TabAtkins_> antonp: Hyatt has said that would significantly complicate his implementation.
10:44:53 <TabAtkins_> stearns: He's gone back and forth on the issue.  Not sure where he is on the issue right now.
10:45:19 <TabAtkins_> Rossen: I'm having a little trouble understanding what "physically belongs to" means.
10:45:36 <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.
10:45:48 <TabAtkins_> Rossen: As you interact with the region, you change how much content is in each region.
10:45:56 <TabAtkins_> Rossen: But that doesn't mean actually changing the content in the document.
10:46:05 <TabAtkins_> Rossen: That complicates region styling.
10:46:14 <TabAtkins_> Rossen: Region styling has proven to be complicated for that reason.
10:47:09 <vhardy__> vhardy__ has joined #css
10:48:15 <TabAtkins_> TabAtkins_: Wrong level of discussion.  Are the box-tree stuff from the flow children of the region's box?  Or are they independent and just happen to be rendered with a geometric restriction that makes them look like the same?
10:48:23 <TabAtkins_> Rossen: The former (though it's complicated).
10:48:47 <TabAtkins_> antonp: Makes sense - otherwise you get weird effects with things like a float "belonging" to another box entirely, which changes the rendering order.
10:49:38 <TabAtkins_> Bert: Is this similar to the relationship between lineboxes and inline content?
10:49:42 <TabAtkins_> TabAtkins_: Yes, very similar.
10:50:20 <TabAtkins_> stearns: Especially given the connection with styling ::first-line.  Same exact problem as region styling.
10:51:16 <TabAtkins_> stearns: So back to the issue at hand - stacking contexts.  Yay/nay?
10:51:49 <TabAtkins_> dbaron: I dont' have strong opinions.  I don't think we ahve a strong performance reason to prefer full stacking context versus pseudo.  But I'd have to ask roc about it.
10:52:19 <TabAtkins_> Rossen: I don't think performance is a strong reason to make a decision either way.
10:52:24 <TabAtkins_> TabAtkins_: yeah, not strong, but an input.
10:52:37 <TabAtkins_> Rossen: Right.  I'm hearing, though, that some impls prefer it for performance reasons, and some don't care.
10:53:05 <TabAtkins_> RESOLVED: bug 15824 - keep the current spec text, where regions all create stackign contexts for the stuff flowed into them.
10:53:13 <stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858
10:53:23 <antonp> howcome: [something along the lines of I'm not sure whether pseudo-stacking contexts would be good enough, rather than full stacking contenxts]
10:53:26 <TabAtkins_> stearns: Should creation of regions from elements be disallowed?
10:53:50 <TabAtkins_> stearns: This came up about a year ago.
10:53:55 <TabAtkins_> stearns: I think there's a good reason to have this.
10:54:03 <TabAtkins_> stearns: It can inherit part of the structure of your document.
10:54:09 <TabAtkins_> stearns: Particularly for scripting/events.
10:54:10 <cabanier> cabanier has joined #css
10:55:07 <TabAtkins_> stearns: I think we should have the ability to flow it into css-created boxes, but we shouldn't disallow it.
10:56:06 <virginie> virginie has joined #css
10:56:17 <TabAtkins_> TabAtkins_: This is completely the issue I was taklign about yesterday, with changing over to dbaron's proposal.
10:56:48 <lstorset> lstorset has joined #css
10:56:56 <lstorset> lstorset has joined #css
10:57:12 <TabAtkins_> stearns: Actually, you were doing an either-or.  Either do dbaron's thing (no explicit region flow at all) or do Regions thing (explicit flow, with elements and such).  So I'd like to resolve that, *if* we do that latter, we can use elements.
10:57:17 <TabAtkins_> TabAtkins_: I'm fine with that.
10:57:20 <kotakagi> kotakagi has joined #css
10:57:46 <TabAtkins_> TabAtkins_: I'm not happy about being forced to use dummy elements, but it's better in my book than the alternatives, given the lack of dedicated pseudo-element creation right now.
10:58:29 <TabAtkins_> stearns: There's an example by implication in note 3 about how you don't necessarily have to use dummy elements.
10:59:12 <dbaron> howcome: ...
10:59:22 <divya> TabAtkins: we dont need to handle eventing on pseudo-elements
10:59:42 <divya> TabAtkins: if we end up going with current regions proposal there are a lot of things that wont work well and wont work accessibly if we just stick to pseudo elements
10:59:45 <stearns> http://wiki.csswg.org/spec/css3-regions/regions-use-cases#converting-hard-breaks-to-named-flows
10:59:55 <divya> TabAtkins: if we go with dbaron's proposal we will still have …
11:00:06 <divya> howcome: if we need the DOM thing, then put up a proposal for that.
11:00:14 <divya> glazou: you raised a problem then why dont you do it?
11:00:20 <divya> howcome: I dont have dom issue.
11:00:28 <divya> glazou: this is lower in priority.
11:00:40 <divya> glazou: i am just saying people like regions given …
11:00:56 <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.
11:01:07 <divya> TabAtkins: i use dummy html as wrappers all the time, it is going to be necessary sometimes
11:01:24 <divya> howcome: you are creating a separate structure next to content structure
11:01:40 <divya> stearns: that visual structure in a lot of interesting pieces has to have a structure, you have to have nesting in child-parent rels
11:01:42 <dbaron> (Tab also said something unminuted after the "howcome: ...")
11:01:57 <divya> stearns: one of the args against … is that you are reinventing html in css
11:02:20 <divya> glazou: when you do TOCs and extract them, you do want elements.
11:02:36 <divya> stearns: it is quite similar to what is being done in SHADOW DOM
11:02:58 <Bert> (HTML could add a <toc> element.)
11:03:03 <divya> stearns: you have an insertion point that is an empty element in your shadow dom tree. that seems to be something people want as well. we are providing a similar facility.
11:03:20 <divya> TabAtkins: the point of shadow dom is recognizing that you need dummy elements and taking them from the main flow.
11:03:54 <divya> stearns: in MS you have two separate html documents you have content and vi…
11:04:20 <divya> howcome: i dont think you can make the argument that they are semantic
11:04:32 <divya> howcome: we need representation of visual structure, we should not abuse html documents for that.
11:04:49 <divya> stevezilles: i am sorry visual structure is semantic
11:04:58 <divya> TabAtkins: philosophically opposed but not practically opposed
11:05:07 <Bert> q+ to say using an external (XML) document for the visual structure is a different case again, and OK
11:05:09 <divya> howcome: building on what you said, if we agree on going david's way we should do that.
11:05:28 <divya> TabAtkins: within option b lets not screw around and allow that, as it is required for regions proposal to work well.
11:05:44 <divya> howcome: it is not well defined if it requires html
11:06:05 <divya> [lots of arguments]
11:06:45 <divya> glazou: authors already use elements for layouts.
11:06:49 <divya> glazou: they will continue to do it
11:07:05 <divya> TabAtkins: my arg is what stearns suggests is improv over what we have right now.
11:07:20 <divya> TabAtkins: you would have to explicitly break contents between the elements right now.
11:07:37 <divya> TabAtkins: you have same divs sitting around, but you get better semantics with the content and more reliable styling.
11:07:55 <divya> howcome: as soon as you change the font size.
11:08:08 <divya> dbaron: assuming people will do things in the same proportion to they do things right now.
11:08:13 <fantasai> dbaron: The strictly better than right now is assuming that people will do things in the same proportion to te rate they do them right now
11:08:24 <fantasai> dbaron: But this will change the rate at which people do such things.
11:09:00 <fantasai> ;P
11:09:18 <divya> TabAtkins: if we are selecting columns you are using pseudo elements
11:09:28 <Jirka> Jirka has joined #css
11:10:01 <divya> TabAtkins: there is no reason to cripple the alternative right now.
11:10:07 <divya> TabAtkins: if we dont need it then stop caring about it.
11:10:24 <divya> glazou: all specs rely on implementation in the long run, if we dont have 2 impl. then it would go away.
11:11:11 <divya> steve zilles: people being forced to divide content to make it look like what it looks like.
11:11:26 <divya> steve zilles: you have restructured it in a form that defeats accessible access
11:11:43 <divya> steve zilles: you want to show content for different devices and you cant do it.
11:11:55 <glazou> Zakim, q+
11:11:55 <Zakim> I see Bert, glazou on the speaker queue
11:12:23 <divya> steve zilles: html as a suitable lang to express viz structure, it is possible to explore restricting the use of regions to page templates and in that context require they be empty boxes
11:12:36 <TabAtkins_> howcome: I think the page template proposal is much more sensible in that regard.
11:12:57 <TabAtkins_> szilles: In that case regions would end up with addressable things - we'd get CSSOM access to them.
11:13:12 <TabAtkins_> stearns: The OM stuff is in a separate spec entirely - the pseudo spec Daniel and I are doing.
11:13:37 <rubylin> rubylin has joined #css
11:13:49 <TabAtkins_> szilles: The main reason for this is exactly what Tab said - from a practical viewpoint, elements work today, and they're eventable/scriptable/etc. This needs to be there for a lot of use-cases.
11:14:09 <TabAtkins_> szilles: If you're paginating a complex structure, you don't know what the use-cases are today, and we won't know what they are until we see them in the wild.
11:14:23 <TabAtkins_> szilles: You can come up with a few simple rules, but they dont' generalize right now.
11:14:36 <Bert> zakim, ack me
11:14:36 <Zakim> Bert, you wanted to compare regions with columns and to say using an external (XML) document for the visual structure is a different case again, and OK
11:14:37 <TabAtkins_> Bert: Two remakrs.
11:14:39 <Zakim> I see glazou on the speaker queue
11:14:44 <TabAtkins_> Bert: I've been watiing for regions for 15+ years.
11:15:01 <TabAtkins_> Bert: If we're waiting for events to be defined on them, cool, let's do that.  If it takes a year, okay.
11:16:01 <TabAtkins_> Bert: going back to an example from alan was using an external document to define the regions. This seems fine to me as well, as long as those extra element are clearly marked as being in a document which is defined as being for layout, not meaning.
11:16:35 <TabAtkins_> stearns: Certainly something MS has been working on - content in one doc and visual structure in the other - and we've been doing experiments with Shadow DOM, with similar effects.
11:16:36 <glazou> Zakim, ack me
11:16:36 <Zakim> I see no one on the speaker queue
11:16:44 <TabAtkins_> stearns: Either way, they're separated from the meaningful HTML.
11:16:55 <TabAtkins_> glazou: I was speaking at the Paris Web Conf last week.
11:17:05 <TabAtkins_> glazou: I demoed Regions and other things, and people came to the end of my talk.
11:17:29 <dbaron> q+
11:18:08 <TabAtkins_> glazou: they said pseudos were bad because screen-readers dont' read pseudos.
11:18:22 <TabAtkins_> TabAtkins_: I think they misunderstand. The real content will still be in the DOM, in a single element.
11:18:48 <dbaron> q-
11:18:50 <TabAtkins_> stearns: By the time you get to the reader, you're not looking quite at the DOM.
11:19:18 <TabAtkins_> TabAtkins_: Not quite - they vary.  You usually get an accessibility tree, which is an expanded version of the DOM.
11:19:31 <TabAtkins_> howcome: If pseudos dont' work, then why don't multicol work?  They're pseudos too.
11:19:48 <TabAtkins_> dbaron: There's a long-standing problem with people trying to put *content* into the pseudos, rather than in the document.
11:20:04 <shepazu> shepazu has joined #css
11:20:16 <dbaron> dbaron: ... ...
11:20:25 <dbaron> TabAtkins: If that's a problem then we also need to throw away flexbox and grid for the same reason.
11:20:46 <dbaron> TabAtkins: If people have learned that putting content in pseduos in bad, they'll interpret what you say as the same bad thing.
11:20:53 <dbaron> TabAtkins: I think their concern is actually mistaken.
11:20:57 <antonp> +!
11:21:03 <antonp> +1
11:21:05 <dbaron> glazou: Let's take a flow that ...
11:21:20 <dbaron> glazou: The voice reador should say "moving from one column to ..."
11:21:22 <dbaron> ?: why?
11:21:42 <dbaron> TabAtkins: Regions encourages you to have a semantically whole pice of your content even if it's split visually.
11:21:58 <dbaron> TabAtkins: Accessibility could be better in general when display order is different from source order.
11:22:06 <dbaron> glazou: I was just reporting what I heard
11:22:21 <TabAtkins_> stearns: Unless anyone has something to continue in this discussion, I'd like to close it.  Leave the issue in the spec and continue on.
11:22:26 <TabAtkins_> stearns: The next thing is quick.
11:22:31 <TabAtkins_> stearns: I think it was resolved yesterday.
11:22:48 <TabAtkins_> stearns: How the regions specification defines the first region box as the ICB of the named flow.
11:23:08 <TabAtkins_> stearns: I wasn't sure if that was exactly necessary, but in the discussion yesterday about paged media and the talk about first page and ICB and such...
11:23:45 <TabAtkins_> stearns: I think regions just needs to follow what is going on in pages.
11:24:15 <TabAtkins_> TabAtkins_: I think arronei thought up a name for the concept you need: "fragmentation containing block".  For the concept syou need to pull from the ICB, without the *full* assortment of baggage from it.
11:25:07 <fantasai> fragmentaining block!
11:26:11 <TabAtkins_> TabAtkins_: So we need to define exactly what parts of the current ICB concept need to be pulled out into FCB, because non-initial pages/regions/etc need them.  Then write that down and reference it in Page and Regions.
11:27:14 <TabAtkins_> RESOLVED: What Tab said immediately above about ICB/FCB
11:28:16 <dbaron> Topic: Multicol
11:28:18 <TabAtkins_> Topic: multicol sizing
11:28:51 <dbaron> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
11:28:53 <TabAtkins_> fantasai: The proposal is to replace the "available width" and "shrink-to-fit" variables with just "used width".
11:29:11 <TabAtkins_> fantasai: And remove lines 3-10 of the pseudo-algo and just swap out refs for "used width".
11:29:22 <TabAtkins_> fantasai: Where used width is defined by referenced formulas.
11:29:44 <TabAtkins_> howcome: We presume when used width is handled, so we're shuffling where things are done.
11:30:22 <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.
11:30:31 <TabAtkins_> howcome: [something about min and max width]
11:30:46 <TabAtkins_> fantasai: That's contained in "used width".  It's the result of all the computations about what the width is going to be.
11:31:05 <TabAtkins_> howcome: It seems you've been wanting to have a discussion about min-width in this spec, but maybe I'm wrong.
11:31:15 <kawabata> kawabata has joined #css
11:31:16 <TabAtkins_> SimonSapin: When is the available width unknown?
11:31:21 <TabAtkins_> SimonSapin: The spec has one example - in floats.
11:31:29 <TabAtkins_> SimonSapin: but that's no longer unknown, and it's defined in Sizing.
11:31:45 <TabAtkins_> howcome: So no other changes, just these removals/swaps?  No additional complexities?
11:32:04 <TabAtkins_> Bert: I'm not completely clear on what the change is.
11:32:18 <TabAtkins_> fantasai: The available width is always known.
11:32:37 <TabAtkins_> dbaron: You're removing the stuff about shrink-to-fit into Sizing, so for the purposeof this spec, available width is always known.
11:32:47 <dbaron> fantasai, ...: yes
11:32:53 <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.
11:33:19 <TabAtkins_> SimonSapin: In 2.1, what we call available width is based on containing block, but in here it's not the same.
11:33:23 <TabAtkins_> howcome: Right, that's confusing.
11:33:40 <TabAtkins_> Rossen: Another is the "used width", which in 2.1 terms is the final width, can still change here afterwards.
11:33:54 <TabAtkins_> Rossen: If you came in with width:auto and have a column-count, it can still change here.
11:34:19 <TabAtkins_> Rossen: So you're either oging to have a complete used-width spec somewhere else, and thus yank out these two usages.
11:34:29 <TabAtkins_> Rossen: or redefine shrink-to-fit elsewhere and don't call it used width here.
11:34:40 <TabAtkins_> fantasai: The sizing spec defines the used width (in conjunction with 2.1).
11:34:54 <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.
11:35:06 <TabAtkins_> fantasai: So we can assume that we've already figured out the width.
11:35:34 <TabAtkins_> Bert: but you need that information to figure out the width.
11:35:43 <TabAtkins_> TabAtkins: Right, you do use that in Sizing to figure out the width.
11:35:57 <TabAtkins_> Bert: So all that happens *before* you figure out the intrinsic size.
11:36:15 <TabAtkins_> fantasai: It's more complicated.  [summarizes the shrink-to-fit algo in Sizing]
11:36:54 <TabAtkins_> fantasai: So this formula in multicol is technically wrong - it overflows when unnecessary in some cases.
11:37:33 <TabAtkins_> howcome: It's not *wrong*, but it might not be what you want.
11:38:38 <fantasai> http://dev.w3.org/csswg/css3-sizing/
11:38:40 <TabAtkins_> TabAtkins: Lines 5-8 aren't great. Sizing defines a slightly better definition that doesn't overflow as often.
11:39:09 <TabAtkins_> fantasai: Because this definition is a bit complicated, I don't think this CR (multicol) is the right place to deal with this.
11:39:46 <florianr> florianr has joined #css
11:39:53 <TabAtkins_> glazou: We brought this up weeks ago, and deferred it to the f2f to resolve on it.
11:40:00 <SimonSapin> q+
11:40:02 <TabAtkins_> howcome: I agree we should kill lines 9-10.
11:40:35 <oyvind> oyvind has joined #css
11:40:38 <TabAtkins_> howcome: I don't think we need to remove lines 3-4, seems like useful information.
11:40:49 <TabAtkins_> howcome: 5-8 gives *a* definition, even if it's not ideal.
11:41:02 <TabAtkins_> TabAtkins: We should kill it if we know we have a better definition, which we do in Sizing.
11:41:38 <TabAtkins_> dbaron: The definition in 19-23 is more complicated - you dont' want to get a different result from 5-8 as from 19-23, once you get a definite width.
11:42:08 <fantasai> The point is, that this pseudo-algorithm should restrict itself to determining the number and width of the columns, because the rules for sizing a multi-col are not clear, not interoperable, and not agreed-upon
11:42:33 <TabAtkins_> Bert: But that's in a float situation. I asked for column counta nd width, shouldn't i get it?
11:42:57 <TabAtkins_> TabAtkins: Floats dont' overflow their containing block unless absolutely necessary.  Our better definition tweaks things if necessary to maintain that invariant.
11:43:09 <TabAtkins_> SimonSapin: Importantly, what does "unknown width" actually mean?
11:43:50 <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".
11:44:09 <TabAtkins_> dbaron: I think Simon's proposal is takign the first.
11:44:14 <dbaron> I think
11:44:31 <TabAtkins_> glazou: It seems that some work has to be done on this in any way, because some definitions are missing or unclear.
11:45:05 <TabAtkins_> fantasai: Yes.  So we should not be leaving these in the spec.  We should pull them out and let Sizing define it.
11:46:00 <dbaron> dbaron: I think we should take the proposal, and raise further issues as they come up.
11:46:25 <TabAtkins_> glazou: Straw poll, 6 for, 1 against, many abstain/undecided
11:46:40 <TabAtkins_> glazou: Those who are undecided, can you trust the group?
11:46:56 <fantasai> The proposal is, remove lines 3-10 in the pseudo-algorithm, use the term "used-width' rather than "available-width", and define in css3-multicol that "used-width" is undefined; work on it in css3-sizing
11:47:06 <TabAtkins_> Rossen: There seems to be some conflicting terminology.  It seems to be complicated.
11:47:26 <TabAtkins_> Rossen: I'm interested in resolving this in favor of Sizing.  I just want to minimize damage on this spec.
11:48:42 <TabAtkins_> glazou: Okay, so discuss before tomorrow evening, and we will resolve.  Otherwise, deferred.
11:49:08 <dbaron> lunch break until 2pm
11:50:08 <kensaku> kensaku has joined #css
11:55:46 <tomoyuki> tomoyuki has joined #css
12:00:13 <krijnh> krijnh has joined #css
12:08:40 <boblet> boblet has joined #css
12:13:22 <stearns> stearns has joined #css
12:32:22 <rotsuya> rotsuya has joined #css
12:33:33 <franremy> franremy has joined #css
12:34:45 <SimonSapin> SimonSapin has joined #css
12:36:19 <rotsuya_> rotsuya_ has joined #css
12:36:24 <tomoyuki> tomoyuki has joined #css
12:36:42 <SimonSapin> SimonSapin has joined #css
12:38:39 <mjs> mjs has joined #css
12:40:39 <rotsuya> rotsuya has joined #css
12:41:16 <kotakagi> kotakagi has joined #css
12:42:41 <shepazu> shepazu has joined #css
12:47:27 <r12a> r12a has joined #css
12:50:53 <arronei> arronei has joined #css
12:51:28 <kensaku> kensaku has joined #css
12:55:01 <arronei> arronei has joined #css
12:58:50 <franremy> franremy has joined #css
13:01:02 <sakkuru> sakkuru has joined #css
13:03:13 <glenn> glenn has joined #css
13:04:21 <sakkuru> sakkuru has joined #css
13:04:27 <cabanier> cabanier has joined #css
13:05:38 <yaso> yaso has joined #css
13:05:41 <krit> krit has joined #css
13:06:56 <Jirka> Jirka has joined #css
13:07:23 <antonp> antonp has joined #css
13:07:28 <mjs> mjs has joined #css
13:07:42 <dbaron> dbaron has joined #css
13:07:42 <glazou> glazou has joined #css
13:09:20 <mgylling> mgylling has joined #css
13:11:56 <TabAtkins_> TabAtkins_ has joined #css
13:11:58 <franremy> franremy has joined #css
13:13:14 <dino> dino has joined #css
13:13:30 <cabanier> cabanier has joined #css
13:13:42 <florianr> florianr has joined #css
13:17:05 <divya> divya has joined #css
13:17:11 <divya1> divya1 has joined #css
13:17:54 <r12a> r12a has joined #css
13:18:28 <slightlyoff> slightlyoff has joined #css
13:18:40 <cabanier> cabanier has joined #css
13:18:41 <TabAtkins_> Topic: CSS Animations
13:19:01 <cox> cox has joined #css
13:19:04 <yamaday> yamaday has joined #css
13:19:11 <lstorset> lstorset has joined #css
13:19:19 <antonp> antonp has joined #css
13:19:29 <Rossen> Rossen has joined #css
13:19:29 <chsiao> chsiao has joined #css
13:19:30 <liam> liam has joined #css
13:19:57 <JohnJansen> rumor has it that a photo was just taken...
13:20:20 <TabAtkins_> Rumor has it that we did it quick before you found out...
13:20:30 <JohnJansen> as long as sylvain was in it, that's cool.
13:20:44 <TabAtkins_> Topic: CSS Masking
13:20:46 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
13:21:20 <kawabata> kawabata has joined #css
13:21:24 <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.
13:21:30 <TabAtkins_> krit: Have a few issues left.
13:21:35 <TabAtkins_> krit: First is mask-clip.
13:21:50 <TabAtkins_> krit: CSs Masking in webkit is pretty similar to background and its properties.
13:21:58 <Norbert> Norbert has joined #css
13:22:10 <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.
13:22:29 <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.
13:22:40 <TabAtkins_> krit: But right now mask-clip only has the same property as background-clip.
13:23:05 <TabAtkins_> krit: I'd like another keyword that takes into account the boxes of children.
13:23:16 <shepazu> shepazu has joined #css
13:23:20 <TabAtkins_> TabAtkins_: So, not things like shadows?  Just the union of geometry, like getboundingClientRect?
13:23:23 <TabAtkins_> krit: Yes.
13:23:47 <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.
13:24:04 <TabAtkins_> krit: Another related issue - set the clip area to the same as the filtered area.
13:24:17 <Reinaldo_> Reinaldo_ has joined #css
13:24:40 <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.
13:25:11 <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.
13:25:51 <TabAtkins_> krit: We could use the "union box" for that too - difference being that stuff outside the 0%-100% range are actually still useful.
13:26:16 <trackbot> trackbot has joined #css
13:27:14 <TabAtkins_> dbaron: That's a little weird, if the blur is part of the bounding box.
13:27:57 <TabAtkins_> TabAtkins_: It's not - it's just whatever bounding client rect would return.
13:28:45 <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?
13:29:08 <TabAtkins_> TabAtkins_: It's allowed, but I think it's meaningless right now.  We could maybe fix that.
13:30:03 <TabAtkins_> krit: And for PNG it would just sit at the 0,0 of the coord space?
13:30:04 <yamaday> yamaday has joined #css
13:30:04 <TabAtkins_> TabAtkins_: Yes.
13:30:29 <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.
13:30:48 <TabAtkins_> TabAtkins_: Okay, so we might want a clip-margin then, to allow the author to manually expand the clipping box further.
13:31:10 <trackbot> trackbot has joined #css
13:31:12 <TabAtkins_> krit: Ok, if you're willing to help me figure that out, we can leave it unresolved for now.
13:31:50 <tomoyuki> tomoyuki has joined #css
13:31:57 <TabAtkins_> TabAtkins_: Okay, so two additions to the spec being reviewed right now:
13:32:50 <TabAtkins_> TabAtkins_: 1) Add a new value to mask-clip/origin which uses the "bounding box" - same as returned by getBoundingClientRect.
13:33:16 <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.
13:34:06 <TabAtkins_> plinss: So the initial suggestion was just to add a "none" keyword?
13:34:24 <TabAtkins_> RESOLVED: Add the two new values to mask-clip/origin as described above.
13:34:42 <jfmoy> jfmoy has joined #css
13:34:57 <jfmoy> jfmoy has left #css
13:35:07 <trackbot> trackbot has joined #css
13:35:15 <TabAtkins_> TabAtkins_: Has anyone asked for the "bounding rect" clip?
13:35:23 <stearns> stearns has joined #css
13:35:46 <kotakagi> kotakagi has joined #css
13:35:46 <TabAtkins_> krit: Firefox does the "none" value right now.
13:36:00 <TabAtkins_> TabAtkins_: Okay, so maybe just do the "none" value now, and reserve the explicit "bounding rect" clip for later.
13:36:28 <TabAtkins_> RESOLVED: Amend previous resolution - only agree to add the "none" value.
13:36:38 <TabAtkins_> Bert: Do we need to coordinate with SVG on this?
13:36:53 <TabAtkins_> krit: SVG already decided on it - this is SVG coming to CSS to sanity-check/bless it.
13:36:56 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#ClipProperty
13:37:17 <TabAtkins_> krit: The 'clip' property only applies to abspos elements, using the rect() function.
13:37:43 <TabAtkins_> krit: But clip-path() works on everything, with more shape functions and an SVG <clipPath> element reference.
13:38:03 <TabAtkins_> s/clip-path()/'clip-path'/
13:38:32 <TabAtkins_> TabAtkins_: So do we want to unify the two properties?
13:38:38 <yaso> yaso has joined #css
13:39:54 <TabAtkins_> krit: I think I don't - people might be confused about using both rect() and another shape (doing one on :hover, for instance) and not knowing why one doesn't work (since rect() would, for legacy reasons, only work on abspos elements).
13:40:14 <TabAtkins_> TabAtkins_: Okay, so you're suggesting deprecating 'clip' and using only 'clip-path'.
13:42:28 <Zakim> Zakim has left #css
13:42:36 <TabAtkins_> plinss: Sorta sad - clip was the first one that we ever did with the intention of being extended with more functions like this.
13:43:50 <glazou> s/quites/quits
13:44:42 <Zakim> Zakim has joined #css
13:45:19 <TabAtkins_> RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.
13:46:33 <TabAtkins_> TabAtkins_: Related to this, can we add an inset-rectangle()?
13:46:56 <TabAtkins_> dbaron: We have a standing resolution from 2001 to add an inset-rect()
13:47:00 <dbaron> Redwood City in 2001
13:47:07 <yamaday> yamaday has joined #css
13:47:08 <dbaron> (which was only the second WG meeting I attended in person)
13:47:44 <TabAtkins_> everyone: sounds good, make Rossen do it.
13:48:09 <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec.
13:48:50 <trackbot> trackbot has joined #css
13:49:04 <TabAtkins_> ACTION rossen to add inset-rectangle(top, right, bottom, left) to the Shapes spec.  (or just inset()).
13:49:04 <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].
13:49:19 <TabAtkins_> RESOLVED: Add inset() or inset-rectangle() to the Shapes module.
13:49:34 <TabAtkins_> krit: Last issue is the 'mask' shorthand.
13:49:46 <TabAtkins_> krit: 'maks' property in SVG takes a ref to a <mask> element.
13:49:57 <TabAtkins_> krit: Webkit takes just CSS images.
13:50:15 <TabAtkins_> krit: roc complained that these are not fully compatible with each other
13:50:45 <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).
13:51:19 <yamaday> yamaday has joined #css
13:51:29 <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
13:51:44 <krit> TabAtkins: CSS would like to integrate into SVG further
13:51:54 <krit> TabAtkins: fill and stroke would take CSS IMages
13:52:03 <krit> TabAtkins: this needs two different code pathes
13:52:17 <fantasai> TabAtkins^: Use SVG paint servers as CSS images
13:52:19 <krit> TabAtkins: Is the SVG file referencing an resource, paint sserver or element
13:52:41 <krit> TabAtkins: but depndent on the context, the file needs to be treated differently
13:52:47 <mjs> mjs has joined #css
13:52:51 <krit> TabAtkins: this might be a problem in more impementation
13:53:16 <krit> TabAtkins: that's why he want to know on parse time which code pah we need
13:53:46 <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 ?
13:53:48 <krit> TabAtkins: roc has a proposal to differ the file interpretation on #
13:53:54 <fantasai> TabAtkins: If it's a frag id, assume it's a paint server
13:54:16 <fantasai> TabAtkins: If it's a media fragment or SVG functional notation, it's a [picture]
13:54:34 <fantasai> ChrisL: What if you have a normal fragment ID that points to an SVGView element?
13:54:41 <fantasai> s/picture/SVG view/
13:54:45 <yamaday> yamaday has joined #css
13:54:57 <fantasai> TabAtkins: ... use :target pseudo-class to get similar facts
13:55:05 <fantasai> TabAtkins: Probably safe to shut that down
13:55:27 <fantasai> TabAtkins: Let's discuss this soon, decide on something that's good for SVG, and incorporate here.
13:55:37 <fantasai> TabAtkins: If you're interested in this, contribute to mailing list thread on www-style
13:56:24 <ChrisL> ChrisL has joined #css
13:56:55 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
13:56:58 <TabAtkins_> Relevant thread: http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
13:57:22 <fantasai> SteveZ: Appears to me you wnat to distinguish paint servers, things that SVG can fill
13:57:31 <dbaron> http://lists.w3.org/Archives/Public/www-svg/2012Oct/thread.html#msg19
13:57:34 <fantasai> SteveZ: my experience is that heuristics is a fragile way to distinguish
13:57:44 <fantasai> SteveZ: Why not add something to referencing mechanism?
13:57:46 <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
13:57:57 <fantasai> TabAtkins: SVG and CSS are already ambiguous in how they handle this
13:58:09 <fantasai> TabAtkins: Luckily way SVG uses CSS URLs is usually referring to a paint server
13:58:11 <fantasai> TabAtkins: So works already
13:58:29 <fantasai> krit: SVGStack
13:58:43 <fantasai> TabAtkins: mechanism for spriting SVG, using :target to hide everything else
13:58:53 <fantasai> TabAtkins: These would break, because need to load those as an image, not as a paint server
13:59:09 <fantasai> TabAtkins: But afaict the uses of these in the wild are in <object> tags, etc.
13:59:27 <fantasai> krit: we've seen a lot of blog posts and bug reports complaining that we don't implement this
13:59:45 <ed> TabAtkins: yes, that's true, but the use outside of CSS doesn't use the url()-notation, so it's different
13:59:55 <ed> use of svg stacks that is
14:00:25 <fantasai> fantasai: We have several functions that allow referencing images
14:00:45 <fantasai> fantasai: Distinguish based on that
14:00:58 <fantasai> TabAtkins: roc suggests element() interprets as paint server, image() as view
14:01:11 <fantasai> fantasai: make url() do the legacy thing
14:01:16 <fantasai> TabAtkins: both are legacy things
14:01:49 <fantasai> plinss: Interpreting things differently based on fragment ID is an architectural faux-pas
14:02:01 <fantasai> plinss: Interpretation of frag ID should be registered with media type
14:02:23 <fantasai> plinss: Let's not do something that breaks the Web architecture
14:02:35 <fantasai> TabAtkins: Two legacy behaviors are bg-image: url(svg); treats as an image
14:02:46 <fantasai> TabAtkins: fill: url(svg); treats as a paint server
14:03:15 <fantasai> fantasai: Then per-property, define handling of url() per property
14:03:55 <fantasai> TabAtkins: doesn't work for masking -- could load svg as a mask path, or as an image
14:04:14 <fantasai> fantasai: So pick a default, and then can use other function names to do something different
14:04:17 <fantasai> ChrisL: ...
14:04:32 <fantasai> krit: Mozilla also has to consider CORS, which is one reason need to know ahead of time
14:05:04 <fantasai> krit: So let's leave this issue open for now
14:05:11 <fantasai> krit: Can we publish a FPWD with changes we resolved today?
14:05:17 <fantasai> plinss: any objections?
14:05:30 <ChrisL> ChrisL: why not add a keyword with several values, he initial value is auto which means do the magic thing but you can add specific keywords for paint server or image if auto does the wrong thing for you
14:05:33 <fantasai> RESOLVED: FPWD Masking
14:05:53 <fantasai> plinss: Have similar issue wrt shortname
14:06:16 <fantasai> ...
14:06:20 <fantasai> TabAtkins: It's a Level 1 spec
14:06:52 <fantasai> TabAtkins: So could just call it css-mask
14:07:04 <fantasai> RESOLVED: call it css-mask
14:07:05 <TabAtkins_> dbaron: (to ChrisL) we already have the image()/element() functions to distinguish them, so I don't think we need further keywords to distinguish
14:07:20 <kensaku> kensaku has joined #css
14:07:50 <cabanier> slides for blending discussion: http://cabanier.github.com/blending/#/
14:07:55 <fantasai> <br duration=22m>
14:08:22 <cabanier> cabanier has joined #css
14:08:31 <rotsuya> rotsuya has joined #css
14:17:56 <sakkuru> sakkuru has joined #css
14:20:00 <kotakagi> kotakagi has joined #css
14:23:05 <Jirka> Jirka has left #css
14:25:52 <stearns> stearns has joined #css
14:31:30 <tomoyuki> tomoyuki has joined #css
14:34:18 <TabAtkins_> TabAtkins_ has joined #css
14:34:25 <cabanier> cabanier has joined #css
14:36:08 <divya> divya has joined #css
14:37:28 <glazou> glazou has joined #css
14:37:30 <cabanier> http://cabanier.github.com/blending/#/
14:37:31 <TabAtkins_> Topic: Compositing
14:38:11 <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.
14:38:22 <TabAtkins_> cabanier: Two reasons - non-isolated are much more expensive to do.
14:38:42 <TabAtkins_> cabanier: Two, some OS frameworks (such as Cairo) can't do them natively, so they'd have to be done by hand.
14:38:59 <TabAtkins_> cabanier: So I fear that they would be non-implementable as written today.
14:42:56 <TabAtkins_> cabanier: [goes through his slides]
14:44:16 <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.
14:44:24 <TabAtkins_> cabanier: (in SVG, the relevant group is the <g> element)
14:44:48 <TabAtkins_> cabanier: Authors generally *prefer* non-isolated groups, but the implementability just seems to be too painful right now.
14:45:21 <TabAtkins_> TabAtkins_: So we might still want to have a proeprty that merges groups?
14:45:37 <tomoyuki> tomoyuki has joined #css
14:46:10 <TabAtkins_> cabanier: Already exists.  I'm just asking to change the default.
14:46:24 <TabAtkins_> cabanier: (Also, that property probably won't be implemented yet, and may be removed from this level.)
14:47:23 <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.
14:47:41 <TabAtkins_> cabanier: This weirdness already exists sometimes - z-index can be disrupted by opacity creating a new stack.
14:48:28 <TabAtkins_> TabAtkins_: Relevant Moz implementor would be roc, right?
14:48:49 <TabAtkins_> krit: Cairo was cited as the problem.  Direct3d will have the same problem.
14:49:20 <TabAtkins_> lstorset: Will this affect existing SVG impls?
14:49:31 <TabAtkins_> cabanier: It's a new property, so no.
14:49:47 <rotsuya> rotsuya has joined #css
14:50:40 <TabAtkins_> RESOLVED: Turn the Compositing default to be isolated groups.
14:50:44 <chsiao> chsiao has joined #css
14:50:54 <TabAtkins_> dino: What about publishing the spec?
14:50:56 <TabAtkins_> cabanier: It's already a WD.
14:51:14 <TabAtkins_> cabanier: And I'll request a new WD when I make edits.
14:51:19 <TabAtkins_> Topic: Animations
14:52:55 <TabAtkins_> sylvaing: What do we do for TTA?  Something every week?
14:53:20 <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.
14:53:26 <yamaday> yamaday has joined #css
14:53:37 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
14:53:55 <TabAtkins_> sylvaing: This is about dynamic changes to animation properties or keyframes.
14:54:15 <TabAtkins_> sylvaing: Spec since the beginning requires animation property or keyframes to be snapshotted at the start of the animation.
14:54:29 <TabAtkins_> sylvaing: David and Simon agree that it should be more open to dynamic changes while it's running, such as changing the duration.
14:54:34 <TabAtkins_> sylvaing: We haven't defined in detail how that works.
14:55:12 <TabAtkins_> dbaron: I believe FF's model is that, at the first moment in which the animation-name appears in the animation list, we determine the start-time for the animation.
14:55:18 <TabAtkins_> dbaron: This is the start time at the end of the delay (I think).
14:55:32 <TabAtkins_> dbaron: As long as that animation name stays in th elist of animations, that's the start time we use for the animation.
14:55:39 <TabAtkins_> dbaron: And we continue using that start time for all other things.
14:55:50 <TabAtkins_> dbaron: I think basically anything else can change.
14:56:09 <TabAtkins_> dbaron: So I *think* if you change the delay it has no effect, because we compute the "start" time as the end of the delay.
14:56:12 <TabAtkins_> dbaron: But I'd have to confirm.
14:56:25 <lstorset> lstorset has joined #css
14:56:52 <TabAtkins_> dbaron: Effectively, you just recompute all the parametersof the animation at every moment based on the current values.
14:57:03 <ChrisL> all the parameters are recomputed at each tick in the animation
14:57:36 <TabAtkins_> dbaron: Exception is pausing.  When running->paused, record the time you paused.  Switch from paused->running, adjust the start time forward by the amount of time it was paused.
14:58:31 <TabAtkins_> plinss: if you change things while paused, it can put you in a different position?
14:58:52 <TabAtkins_> dbaron: Yes.  Change the animation-duration while it's paused, and it'll live-move you to the new position.
14:59:35 <TabAtkins_> dino: I don't like starting it at the end of the delay.
14:59:53 <TabAtkins_> dbaron: I agree - I probably should have made it record from the start of the delay instead, so it can take delay changes into account.
15:00:05 <TabAtkins_> dino: We snapshot right now, but the underlying engine supports modification.
15:00:32 <TabAtkins_> dino: We have all the infrastructure so we can expose it to JS.
15:00:58 <TabAtkins_> sylvaing: I'm okay with making the animation properties dynamic.
15:01:05 <mishida> mishida has joined #css
15:01:06 <TabAtkins_> sylvaing: We need some prose in the spec to b emore explicit.
15:01:08 <Norbert> Norbert has joined #css
15:01:55 <TabAtkins_> sylvaing: For example, "animation-name: b, c, d; animation-duration: 2s, 3s, 4s;", then I change to "animation-name: a, b, c, d;", does it restart b, c, d, or does it consider them as having never left the animation list?
15:02:15 <hiroki> hiroki has joined #css
15:02:20 <TabAtkins_> dbaron: b,c,d never left the lsit.
15:02:24 <TabAtkins_> sylvaing: Okay, we need that written down.
15:03:00 <TabAtkins_> dbaron: I wonder what brian birtle thinks about this, given his work.
15:03:14 <TabAtkins_> TabAtkins_: Based on me working with him, I think this is in line with what he wants.
15:04:04 <TabAtkins_> dino: Further wrinkles.  What happens if your animation is almost done, you shrink its duration so it's already over?  Do you get an end event?
15:04:16 <TabAtkins_> TabAtkins_: I think *not* delivering one would result in bad accidental bugs.
15:04:19 <knobuta2> knobuta2 has joined #css
15:04:46 <TabAtkins_> dino: Okay, further answer. Animations with many iterations.  Just befor ethe first iteration ends, you shrink the duration so that the entire animatino is over.  Do you get tons of iterations events, one after the other?
15:05:26 <TabAtkins_> TabAtkins: I can be argued either way on whether to deliver iteration events that didn't "actually" pass.  I think it might be acceptable to have those inconsistent.
15:05:38 <TabAtkins_> dino: Okay.  So there are multiple things like this that need to be resolved and specified.
15:05:58 <TabAtkins_> sylvaing: Right - right now everything is simple, because they can't change.
15:06:24 <TabAtkins_> dino: We'll have to check every state transition - an animation that is done but filling (still technically running), but then has its duration changed so that it should still be running?
15:06:49 <TabAtkins_> dino: Need to work out the full state machine for all of this.
15:07:11 <TabAtkins_> plinss: (re: iteration events) maybe only deliver the last iteration, updating you to the current state.
15:08:35 <TabAtkins_> ChrisL: Scrubbing was one of the things that SMIL got wrong - time resolution was permanent, so if you scrubbed and then ran it, it would jump back to the time it had gotten itself to.
15:08:49 <TabAtkins_> dbaron: [draws a table of states on the whiteboard]
15:09:02 <TabAtkins_> dbaron: If we define what fires for every transition between these cells, is that sufficient?
15:09:04 <TabAtkins_> dino: Yes.
15:09:16 <TabAtkins_> dino: (But there may be another column or two on that graph.)
15:10:05 <dbaron> columns: before / 1st iter / 2nd iter / 3rd iter / after
15:10:09 <dbaron> rows: running / paused
15:10:10 <dbaron> or maybe
15:10:19 <dbaron> rows: running / paused, happens immediately / paused, happens when unpaused
15:10:21 <TabAtkins_> sylvaing: Okay, so I think there's agreement to make these properties dynamic.
15:10:36 <dbaron> And I think there's agreement that the recorded start is the start before the delay
15:10:46 <TabAtkins_> RESOLUTION: Change the animation properties to be dynamically changable, details TBD.
15:11:09 <TabAtkins_> ACTION sylvain to define what happens when animation properties are changed dynamically.
15:11:39 <oyvind> and @keyframes?
15:11:48 <TabAtkins_> oyvind, getting there.
15:11:56 <oyvind> alright
15:12:04 <TabAtkins_> sylvaing: So, keyframes.
15:12:12 <TabAtkins_> sylvaing: Changing those on the fly while animation is running.
15:12:37 <TabAtkins_> sylvaing: The concept makes sense when the animation iterates - when the next interval takes the changes into account.
15:12:49 <TabAtkins_> sylvaing: If you have an animation that runs once, I dunno.
15:13:14 <TabAtkins_> dino: It sounds testable, sure, but internally it's actually kinda difficult - animation may be running on another thread, and there's a disconnect in processing times.
15:13:45 <JohnJansen> JohnJansen has joined #css
15:13:55 <TabAtkins_> TabAtkins_: Conceptually, I don't see anything wrong with changing them mid-animation.
15:14:51 <TabAtkins_> glazou: I have a use-case.  A long-running webapp animation may have a large duration. If you change it, you don't want to wait for an entire iteration to go by.
15:15:09 <divya1> divya1 has joined #css
15:15:22 <TabAtkins_> sylvaing: Are there any animation functions in @keyframes?
15:15:27 <TabAtkins_> TabAtkins_: Only the timing function.
15:16:18 <TabAtkins_> glazou: I think that dynamic changes of animations will actually be a reasonably common case (editting is hard right now, but CSSOM will improve)
15:18:12 <kensaku> kensaku has joined #css
15:18:42 <TabAtkins_> sylvaing: So what about changes of keyframes during an iteration event, intending for the next iteration to use new values?
15:18:59 <kensaku> kensaku has joined #css
15:19:08 <TabAtkins_> TabAtkins_: There may by a delay if you need to deliver the changes to a separate animation thread, but otherwise it should work fine.
15:19:28 <TabAtkins_> TabAtkins_: I think we're doing work on our end that should make it automatically do a smooth transition over to the new values when it discovers that it's overshot and needs to change tracks.
15:19:32 <TabAtkins_> dino: But then we need to specify that.
15:19:58 <TabAtkins_> TabAtkins_: We'll have non-interop a bit anyway, because of timing issues based on whether you do animatino on a separate thread or not.  I think we can leave it alone and spec after things have shaken out.
15:20:14 <kensaku_> kensaku_ has joined #css
15:20:27 <TabAtkins_> RESOLVED: @keyframes can be dynamically changed
15:20:37 <glazou> yay
15:20:40 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15846
15:21:16 <TabAtkins_> sylvaing: Next.  Transition events report what pseudo-element of the element the transition is running against.
15:21:22 <TabAtkins_> sylvaing: We don't have it for animation events at the moment.
15:21:24 <stearns> stearns has joined #css
15:21:26 <TabAtkins_> dbaron: We should just copy it.
15:21:40 <TabAtkins_> RESOLVED: Copy over the pseudo-element info from transition events to animation events.
15:21:41 <Rossen> Rossen has joined #css
15:22:06 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html
15:22:22 <TabAtkins_> sylvaing: What happens when you have duplicate animation names in the animation-name property.
15:22:25 <TabAtkins_> sylvaing: Seems that last one wins.
15:23:11 <yaso> yaso has joined #css
15:23:52 <kensaku> kensaku has joined #css
15:23:55 <TabAtkins_> dbaron: I think we resolved that and I edited it already.
15:24:28 <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.
15:24:42 <TabAtkins_> dbaron: This matches what backgrounds/etc do.
15:24:54 <TabAtkins_> dbaron: I may have already editted this into the draft.
15:25:32 <divya> divya has joined #css
15:25:44 <smfr> smfr has joined #css
15:26:13 <TabAtkins_> RESOLVED: animation-name's length is authoritative.  Other animations properties are adjusted to its length.
15:26:30 <TabAtkins_> ACTION Sylvain to make sure that animation-name's length is definitive, and edit it to be so otherwise.
15:27:17 <TabAtkins_> RESOLVED: When you encounter duplicate animations names, last one wins.
15:27:34 <oyvind> that last resolution seems unclear
15:27:41 <kensaku> kensaku has joined #css
15:27:45 <dbaron> dbaron has joined #css
15:27:48 <glazou> oyvind: explain ?
15:28:19 <oyvind> current draft says that the last wins *at any particular point in time, for a particular property*
15:28:29 <dbaron> http://dev.w3.org/csswg/css3-animations/#list-matching already has the first of those two resolutions edited in, actually
15:28:39 <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.
15:28:43 <dbaron> oyvind, oh, it's about what happens if the same animation-name is specified twice in the list
15:28:56 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14599
15:28:57 <dbaron> oyvind, which duration, delay, timing-function, etc., does it use
15:29:04 <sylvaing> http://jsfiddle.net/leaverou/jwHva/2/
15:29:14 <dbaron> oyvind, the answer is that it's the last occurrence of that animation-name in the list
15:29:59 <TabAtkins_> sylvaing: In this example, if you remove border-style:solid, the animation stops working.
15:30:25 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html
15:31:36 <TabAtkins_> dbaron: I think I wrote a response for why this is crazy.
15:32:45 <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.
15:33:03 <oyvind> dbaron, ok, I misunderstood somewhat
15:33:03 <TabAtkins_> leaverou: Authors find this super-confusing in my experience.
15:33:08 <TabAtkins_> dbaron: There's an even more subtle issue here.
15:33:21 <TabAtkins_> dbaron: Related to the processing model.
15:33:31 <florianr> florianr has joined #css
15:34:00 <TabAtkins_> dbaron: When animating from A to B, there's an idea that it overrides some of the properties, and only those.
15:34:17 <TabAtkins_> dbaron: So this animation actually overrides 13 properties. border-image, border-top-style, border-top-color, etc.
15:34:37 <TabAtkins_> dbaron: For each keyframe, you get a computed value from it, and then you animate the computed values between.
15:34:48 <TabAtkins_> dbaron: However, in some cases, for border-width, the computed value depends on border-style.
15:35:11 <TabAtkins_> dbaron: Which value are you using? The base value, or the value that the keyframe is overriding?
15:35:14 <kotakagi> kotakagi has joined #css
15:35:29 <TabAtkins_> dbaron: And this gets more confusing.
15:35:41 <TabAtkins_> dbaron: Say you have a 50% keyframe here with only a "border-width: 10px;" property.
15:35:47 <TabAtkins_> dbaron: What border-style is this resolved against?
15:36:14 <knobuta2> knobuta2 has joined #css
15:36:31 <TabAtkins_> dbaron: Gecko currently resolves it against the base value.
15:36:42 <TabAtkins_> dbaron: (It also does this for the other keyframes.)
15:37:12 <TabAtkins_> dbaron: The spec's processing model just doesn't really care about the fact that computed values can depend on other computed values.
15:37:49 <dbaron> dbaron has joined #css
15:38:01 <TabAtkins_> dbaron: I think it should, but I doubt any browser really does it.
15:38:28 <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.
15:40:05 <Norbert> Norbert has joined #css
15:41:40 <TabAtkins_> ChrisL: In SMIL anything can be animated.  It just switch halfway through.
15:42:38 <dbaron> dbaron: halfway through the timing function (which makes step-start and step-end magically work)
15:42:42 <TabAtkins_> TabAtkins_: Worst case, can we separate this out, so that non-animatable properties with constant value are still paid attention to and "animate".
15:42:56 <TabAtkins_> ChrisL: That sounds like doing 3/4 of the work and just stopping.
15:43:34 <TabAtkins_> glazou: We could also just say non-animatable properties freeze at their first keyframe value.
15:44:28 <dbaron> dbaron: The thing about font-size and length in ems -- need to test with both in-the-same-@keyframes and in-different-@keyframes
15:44:30 <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.
15:44:44 <dbaron> ... and in different @keyframes on different elements.
15:45:14 <TabAtkins_> TabAtkins_: So 3 cases of increasing complexity.
15:46:33 <TabAtkins_> glazou: So what about my "freeze at frame 0" idea?
15:46:45 <TabAtkins_> dbaron: I think that has a higher chance of web compat problems.
15:46:53 <TabAtkins_> dbaron: The problem with all of these is potential web compat.
15:48:22 <TabAtkins_> glazou: Can we seriously not do better than just making this work?
15:48:23 <ChrisL> I'm arguing for fixing it now by defining animation of enumerated values
15:49:17 <TabAtkins_> ChrisL: Are you saying that people are relying on the behavior in that fiddle?
15:49:19 <TabAtkins_> dbaron: I don't know.
15:49:29 <TabAtkins_> dbaron: Webdevs often try things, find they don't work, and then don't remove them.
15:49:42 <TabAtkins_> ChrisL: So if we fix it, something might suddenly start working and break a page.
15:50:21 <TabAtkins_> dbaron: I suspect we could get away with making this change in animations.
15:50:33 <TabAtkins_> dbaron: I suspect not in transitions, because it defaults to "all".
15:50:46 <TabAtkins_> dbaron: I suspect that if we fix it, we're adding a minimum of 4 months to the spec.
15:50:57 <TabAtkins_> ChrisL: Yes, but that avoids 3+ years of us explaining why it's stupid.
15:51:20 <TabAtkins_> dino: I don't think many authors have hit this particular case.  Or they do and they screw around until it works.
15:51:47 <sylvaing> cool border transitions: http://thecodeplayer.com/walkthrough/simple-yet-amazing-css3-border-transition-effects
15:52:48 <TabAtkins_> leaverou: I think this change's impact will be smaller than gradient angles flipping.  ^_^
15:53:07 <TabAtkins_> dino: I'd like to get some compat data on this first.
15:53:15 <TabAtkins_> TabAtkins_: Can we put a time limit on this?
15:53:24 <mollydotcom> mollydotcom has joined #css
15:54:16 <TabAtkins_> dbaron: Do you know why Gecko doesn't allow you to style the color of the radio button dot?
15:54:51 <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.
15:56:00 <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).
15:56:34 <dbaron> (doesn't apply to transitions)
15:56:38 <dbaron> s/transition function/timing function/
15:58:09 <TabAtkins_> dino: I don't object to putting this in the spec, but would then like time to investigate compat.
15:58:21 <plh> plh has joined #css
15:59:51 <dbaron> depending on whether timing function output is greater or less than 0.5
15:59:51 <TabAtkins_> leaverou: If you have cubic-bezier with out-of-range params, you can have it hit 50% multiple times.  What happens there?
15:59:58 <dbaron> so it might swap more than once
16:00:18 <dbaron> (though we don't think so)
16:00:18 <TabAtkins_> dbaron: It takes the first/last value depending on whether progress is currently above/below 50%, so it'll flip multiple times.
16:00:43 <leaverou> example of timing function that reaches 50% multiple times: http://cubic-bezier.com/#0,1.8,1,-0.79
16:01:32 <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.
16:01:39 <dbaron> cubic-bezier(0.25, 3, 0.75, -2)
16:01:59 <dbaron> (you can cross 50% more than once)
16:02:36 <Bert> q+ to ask if we can now remove the Animatable line from table.propdef.
16:02:50 <dbaron> Bert, no, we can't
16:03:11 <dbaron> q+ to go back to the processing model issue
16:03:47 <glazou> http://www.w3.org/2012/10/TPAC/meetup-Lyon.html#logistics
16:04:09 <dino> leaverou, is that your site? cubic-bezier.com?
16:04:42 <TabAtkins_> ack bert
16:04:42 <Zakim> Bert, you wanted to ask if we can now remove the Animatable line from table.propdef.
16:05:39 <TabAtkins_> dbaron: No, really it's about how to interpolate the property.
16:06:25 <dbaron> we could maybe rename Animatable: to Interpolation:
16:06:32 <dbaron> ack dbaron
16:06:32 <Zakim> dbaron, you wanted to go back to the processing model issue
16:06:38 <plinss> ack dbaron
16:06:47 <TabAtkins_> dbaron: Do we at least have an issue filed on the processing model stuff we're discussing?
16:07:02 <TabAtkins_> dbaron: How you compute the base values for the properties that we were discussing a moment ago?
16:07:52 <TabAtkins_> ACTION tab to test the processing model of animations where computed values of animated properties depend on each other.
16:10:21 <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
16:10:22 <fantasai> ScribeNick: fantasai
16:11:31 <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
16:11:33 <fantasai> smfr: We think that the only real substantive issue in the transforms spec is this bug
16:11:44 <fantasai> smfr: which talks about the containing block terminology used in 3D transforms rendering part of the spec
16:11:49 <smfr> http://jsfiddle.net/fNxAQ/3/
16:11:56 <fantasai> smfr: and to illustrate that, jsfiddle that Ted just linked to, hopefully someone can project
16:12:17 <fantasai> smfr: The issue here is related to 3D rendering contexts and
16:12:24 <fantasai> smfr: how 3D transforms propagate across containing blocks,
16:12:29 <SimonSapin> SimonSapin has joined #css
16:12:32 <fantasai> smfr: Is that jsfiddle on the screen?
16:12:34 <fantasai> [yes]
16:12:41 <SimonSapin> SimonSapin has joined #css
16:13:39 <fantasai> [fiddling with example]
16:14:32 <fantasai> smfr: 2 containers here,
16:14:34 <SimonSapin> Sorry to early, going to the city hall to prepare talks
16:14:37 <fantasai> smfr: border box with perspective
16:14:46 <fantasai> smfr: Top intemrediate div  with no style
16:14:49 <fantasai> smfr: ... with rotate-y
16:14:59 <fantasai> smfr: issue here is whether perspective on grandparent affects rendering of that transform
16:15:07 <fantasai> smfr: i.e. whether the intermediate box flattens it
16:15:17 <fantasai> smfr: i.e. whether the intermediate and the box are members of the same 3D context
16:15:36 <fantasai> smfr: I believe in FF, intermediate box causes flattening to occur, b/c it's the containing block of the blue box
16:15:41 <fantasai> smfr: in Webkit it doesn't
16:15:48 <fantasai> smfr: FF more close to wording in current spec
16:15:55 <fantasai> smfr: Transforms looks at containing block hierarchy
16:16:03 <fantasai> smfr: in bottom example, container, then inside an image, and image has a block sibling
16:16:09 <fantasai> smfr: image gets an anonymous block container
16:16:17 <fantasai> smfr: in this case the containing block for the image is anonymous
16:16:30 <fantasai> smfr: question here is whether that anon box prevents transform
16:16:50 <fantasai> smfr [... gecko]
16:17:32 <krit> http://jsfiddle.net/fNxAQ/6/
16:17:35 <fantasai> dbaron: Gecko doesn't actually create an anonymous box here
16:17:46 <fantasai> [fantasai explains what gecko does, why it doesn' tmake that box]
16:18:02 <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
16:18:14 <fantasai> smfr: Webkit's implementation is falling out of some other things going on
16:18:38 <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
16:18:46 <fantasai> smfr: So it's not conforming to the spec, and not always predictable
16:18:59 <fantasai> dbaron: You say you're looking for ancestors starting ...
16:19:22 <fantasai> dbaron: starting from thing that has a 3D transform?
16:19:37 <fantasai> smfr: Any of those things between that and the transform will cause flattening to occur
16:19:51 <fantasai> smfr: so webkit won't flatten otherwise
16:19:52 <krit> Zakim, q+
16:19:52 <Zakim> I see krit on the speaker queue
16:20:03 <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
16:20:06 <fantasai> smfr: wording in spec is very tight, maybe need something in between
16:20:22 <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
16:20:29 <fantasai> smfr: [quotes]
16:21:03 <fantasai> smfr: [...]
16:21:20 <fantasai> smfr: Aryeh's suggestion.. A is closer to what authors expect, and B doesn't have anon containing block problem
16:21:48 <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c0
16:21:48 <koji> koji has joined #css
16:22:05 <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
16:22:24 <fantasai> smfr: Jsut got browser shots from IE10
16:22:29 <fantasai> smfr: Which is similar to FF behavior
16:22:37 <fantasai> smfr: Opera shot didn't show any support for 3D transforms
16:23:17 <fantasai> smfr: Question here is whether we try to cook up some wording similar to Aryeh's suggestion
16:23:20 <fantasai> smfr: or whta
16:23:25 <fantasai> smfr: input from other implementers
16:23:58 <fantasai> [...]
16:24:04 <fantasai> sylvaing: Our rendering in this case is not really related
16:24:30 <sylvaing> s/is not/may not be
16:24:31 <fantasai> krit: Do we want to follow Webkit, or different approach?
16:24:58 <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?
16:25:08 <mishida> mishida has joined #css
16:25:11 <fantasai> dbaron: Authoring perspective, want it never to flatten, but problem is it's too expensive.
16:25:20 <fantasai> smfr: Want it to flatten in certain cases
16:25:26 <fantasai> dbaron: You'd want the default to be the other way around
16:25:48 <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
16:25:57 <fantasai> smfr: Webpages are typically flatt, and having them not-flat would be strange
16:26:02 <fantasai> smfr: That's why default style is to be flat
16:26:10 <dbaron> those two lines from me were questions
16:26:18 <fantasai> smfr: Time authors use preserve3d is when they build up 3d hierarchies of objects they want to sit in the same perspective
16:26:41 <fantasai> smfr: It's fairly unusual for someone to put perspective on document and expect theo whole thing to be 3d
16:26:51 <fantasai> smfr: Generally have islands of 3D
16:27:09 <fantasai> smfr: So we expect authors to sprinkle around preserve3d between things with perspective and objects they want to show in 3d
16:27:18 <fantasai> smfr: not too bad, usually only 1-3 levels of elements in between
16:27:36 <fantasai> dbaron: Substantive implementation differences. If we pick a different rule, would it be more burdensome?
16:27:54 <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
16:28:11 <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
16:28:27 <fantasai> dbaron: Other reason bz pointed out is that containing block is not an element, it's a rectangle
16:28:36 <fantasai> smfr: didn't anton fix some things wrt that?
16:28:40 <fantasai> antonp: yep, but nothing published yet
16:28:48 <fantasai> antonp: but could work around that, if that's what you want
16:29:05 <fantasai> smfr: If no one has any more input, then action is on me to write up wording for spec ~ Aryeh's comment #4
16:29:31 <dbaron> sounds good to me
16:29:49 <fantasai> krit: Can we resolve on some kind of wording ?
16:29:54 <fantasai> plinss: Do we have wording?
16:30:02 <fantasai> dbaron: Simon was proposing to take an action to propose wording
16:30:18 <fantasai> ACTION smfr: propose wording for 3d perpsective containing block thing
16:30:46 <lmclister> lmclister has joined #css
16:30:56 <fantasai> RESOLVED: Accept Aryeh's proposal, exact wording TBD
16:30:59 <divya> divya has joined #css
16:31:00 <krit> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
16:31:11 <fantasai> krit: Some other items on issues list
16:31:21 <fantasai> krit: Did some wording on it, but needs review from implementers
16:31:31 <fantasai> krit: Not necessarily an issue, but should be reviewed
16:31:45 <mjs> mjs has joined #css
16:32:29 <fantasai> ACTION sylvain: look into bug 15605
16:33:35 <fantasai> dbaron: I truest Aryeh on this
16:33:40 <dbaron> s/truest/trust/
16:33:41 <fantasai> dean: We're happy with this
16:34:29 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17017
16:34:40 <fantasai> krit: Next issue is concern of dbaron's
16:34:59 <fantasai> krit: we have some interpolation code, how you can interpolate between 3d matrices
16:35:10 <fantasai> krit: But don't say how to interpolate between 2d and 2d matrices
16:35:20 <fantasai> krit: So, I looked a bit at source code from FF and Webkit
16:35:31 <fantasai> krit: FF has ... like 2d interpolation, modified to work on 2d
16:35:37 <fantasai> krit: Webkit operates on 3d all the time
16:35:51 <fantasai> krit: We have 4x4 matrix
16:36:08 <fantasai> krit: we transform everything to 3d first, then take 2d values from the resulting matrix
16:36:20 <fantasai> dbaron: I had testcases; possible it's been fixed but;
16:36:29 <ChrisL> do you assume the three unused values are 0 0 1?
16:36:38 <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
16:36:48 <fantasai> dbaron: If you transition between matrices where sign of determinant is different
16:36:49 <ChrisL> because they miight not be if you had scaling in there,
16:37:11 <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
16:37:28 <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
16:37:59 <fantasai> dbaron: Chrome seems to get these right now, but it didn't used to
16:38:11 <smfr> chrome and safari do different things with the bottom row
16:38:17 <fantasai> dbaron: That said, bottom row is looking ike it's doing something 3d to me
16:38:27 <fantasai> dbaron: so I think Chromium is interpolating the bottom in 3d
16:38:42 <fantasai> dbaron: Firefox is interpolating in 2d
16:38:49 <smfr> in safari, middle row 2nd from right is weird
16:39:26 <rotsuya_> rotsuya_ has joined #css
16:40:07 <fantasai> [random discussion of these cases and what's happening in various browsers/versions]
16:40:28 <fantasai> ChrisL: Promoting to 3d and then interpolating doesn't necessarily give you the wrong answer, just depends how you do it
16:40:43 <nsakai> nsakai has joined #css
16:40:54 <fantasai> krit: Do we want to define an algorithm for this?
16:41:02 <fantasai> krit: It seems to be hard in webkit atm
16:41:13 <fantasai> dbaron: Seems we should say what happens, how you interpolate between these things
16:41:49 <fantasai> krit: Are implementations willing to change?
16:41:58 <fantasai> dean: FF must have extra code to handle this
16:42:06 <fantasai> dbaron: We have separate paths for 2d vs 3d
16:42:13 <fantasai> dean: What's 3d vs 2d?
16:43:32 <fantasai> dbaron: The test for 2d is based on the components of the matrix
16:44:17 <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
16:45:08 <fantasai> [...]
16:45:22 <Rossen> Rossen has joined #css
16:45:25 <fantasai> dean: It coudl be that the 3d interpolation is ok for enough cases
16:45:34 <fantasai> dean: and we're just seing some bugs in webkit's implementation
16:45:46 <fantasai> dean: would sitll like to know why chose to customize algorithm for 2d
16:46:02 <fantasai> dbaron: he's in New Zealand...
16:46:08 <fantasai> dean: I don't trust anyone from New Zealand
16:46:14 <fantasai> dean: I accept the resolution
16:46:35 <fantasai> krit: Even if we have interpolation in 3d space, still need to specify how get 2d components for e.g. getComputedStyle
16:47:45 <SimonSapin> SimonSapin has joined #css
16:47:46 <fantasai> krit: It's the main thing left
16:47:58 <fantasai> krit: I'd like to have just one algorithm in the spec, not multiple algorithms. 3d is already complex enough
16:48:12 <fantasai> plinss: Anyone take an action to do research and get back?
16:48:18 <fantasai> krit: What do you expect as the result?
16:48:54 <fantasai> dbaron: Are we interoperable on 3d interpolation, in general?
16:49:03 <smfr> sounds like we need some test cases!
16:49:03 <fantasai> krit: Webkit is mostly following the algorithm in the spec
16:49:31 <fantasai> dean: Made an effort to match the algorithm from you, although we may have bugs
16:50:11 <fantasai> [more discussion of browser versions]
16:50:17 <fantasai> krit: They look different. That might be a bug
16:50:32 <fantasai> dbaron: Looking at our code, looks like we're still doing quaternian thing for both 2d and 3d, just do a different decomposition
16:50:40 <fantasai> dean: Is the decomposition for speed or aesthetics?
16:50:44 <fantasai> dbaron: Think it's for aesthetics
16:50:50 <fantasai> dbaron: we use a decomposition that never generates a perspective
16:51:09 <fantasai> dbaron: sometimes the 3d comp will generate a negative 1 perspective instead of 1
16:51:20 <fantasai> dbaron: that's what leads to weird zoom-in-zoom-out behavior
16:51:21 <glazou> glazou has left #css
16:51:36 <fantasai> ChrisL: That's not perspective, that's scale, right?
16:51:47 <glazou> glazou has joined #css
16:52:07 <fantasai> dbaron: Or maybe it's [this other] component that's affected
16:52:13 <fantasai> ChrisL: Looks like it's the scale factor
16:52:30 <fantasai> dean: I think if you get anything other than 1 in 4,4, you're done
16:52:50 <SimonSapin> SimonSapin has joined #css
16:52:58 <rotsuya__> rotsuya__ has joined #css
16:53:03 <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
16:53:17 <fantasai> krit: Webkit always assumes 3d, even if given 2d
16:53:29 <fantasai> krit: You could use algorithm from 3d transforms and do some weird stuff like setting 1 for perspective
16:53:35 <fantasai> krit: at the moment it's undefined
16:53:57 <fantasai> Options are
16:54:10 <fantasai> 1. Define 2d decompositing algorithm
16:54:16 <fantasai> 2. Leave it undefined
16:54:27 <fantasai> 3. Use 3d decomposing algorithm everywhere
16:55:17 <fantasai> krit: Could also defer this issue to next level
16:55:23 <fantasai> dean: Dunno. It is an interop issue.
16:55:42 <fantasai> dean: If you query getComputedStyle halfway through a transition, would get different values on different browsers
16:56:08 <fantasai> dbaron: Other thing is that algorithm could be tweaked so that the 3d algorithm will always work
16:58:26 <fantasai> dbaron: I'd like to at least email Matt Woodrow and Tim and ask them why we're doing what we're doing
16:58:47 <fantasai> ACTION dbaron: investigate motivations for gecko approach to 2d matrix interpolation
16:59:19 <fantasai> Meeting closed.
17:00:39 <dbaron> dbaron has joined #css
17:01:17 <TabAtkins_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1871
17:01:22 <TabAtkins_> dbaron ^^^
17:06:35 <nsakai> nsakai has joined #css
17:27:41 <Rossen> Rossen has joined #css
17:32:10 <glenn> glenn has joined #css
17:33:21 <antonp> antonp has joined #css
17:40:50 <smfr> smfr has joined #css
17:48:12 <darktears_> darktears_ has joined #css
17:52:15 <stearns> stearns has joined #css
17:55:33 <stearns> stearns has joined #css
17:56:44 <Norbert> Norbert has joined #css
18:00:26 <trackbot> trackbot has joined #css
18:09:57 <antonp> antonp has joined #css
18:10:54 <Kid> Kid has joined #css
18:11:56 <antonp1> antonp1 has joined #css
18:20:06 <drublic> drublic has joined #css
19:27:26 <SimonSapin> SimonSapin has joined #css
19:38:28 <SamB_Mac_> SamB_Mac_ has joined #css
20:12:34 <Norbert> Norbert has joined #css
20:26:57 <Ms2ger> Ms2ger has joined #css
20:41:32 <antonp> antonp has joined #css
20:43:44 <tantek> tantek has joined #css
20:44:42 <glenn> glenn has joined #css
20:52:33 <r12a> r12a has joined #css
21:08:21 <krit> krit has joined #css
21:11:50 <cabanier> cabanier has joined #css
21:19:10 <antonp1> antonp1 has joined #css
21:30:22 <drublic> drublic has joined #css
21:33:40 <rotsuya> rotsuya has joined #css
21:34:44 <antonp> antonp has joined #css
21:37:49 <tomoyuki> tomoyuki has joined #css
21:47:15 <rotsuya> rotsuya has joined #css
21:50:17 <antonp1> antonp1 has joined #css
21:52:16 <dino> dino has joined #css
21:59:15 <liam> liam has joined #css
22:14:00 <hiroki> hiroki has joined #css
22:31:39 <glenn> glenn has joined #css
22:32:19 <kensaku> kensaku has joined #css
23:08:15 <cabanier> cabanier has joined #css
23:37:50 <cabanier> cabanier has joined #css
23:46:28 <SimonSapin> SimonSapin has joined #css