00:09:30 <SimonSapin1> SimonSapin1 has joined #css
00:22:05 <yaso> yaso has joined #css
00:25:44 <cabanier> cabanier has joined #css
00:39:44 <cabanier> cabanier has joined #css
00:39:50 <shepazu> shepazu has joined #css
01:08:20 <isherman> isherman has joined #css
02:35:27 <glenn> glenn has joined #css
02:55:09 <kensaku> kensaku has joined #css
03:46:22 <Norbert> Norbert has joined #css
04:03:37 <paul___irish> paul___irish has joined #css
04:38:54 <rotsuya> rotsuya has joined #css
04:47:01 <Norbert> Norbert has joined #css
05:28:53 <tomoyuki> tomoyuki has joined #css
05:33:45 <vhardy__> vhardy__ has joined #css
05:33:46 <isherman> isherman has joined #css
05:33:55 <CSSWG_LogBot> CSSWG_LogBot has joined #css
05:34:01 <boblet> boblet has joined #css
05:34:15 <shans_away> shans_away has joined #css
05:35:15 <leaverou_away> leaverou_away has joined #css
05:35:30 <plinss> plinss has joined #css
05:36:00 <sylvaing> sylvaing has joined #css
05:46:48 <yamaday> yamaday has joined #css
05:57:10 <rotsuya> rotsuya has joined #css
06:02:06 <glenn> glenn has joined #css
06:21:00 <plh> plh has joined #css
06:21:51 <Norbert> Norbert has joined #css
06:29:02 <kensaku> kensaku has joined #css
06:32:15 <plh> plh has joined #css
06:50:03 <SimonSapin> SimonSapin has joined #css
07:02:11 <plh> plh has joined #css
07:16:10 <glenn> glenn has joined #css
07:30:23 <Zakim> Zakim has left #css
07:31:58 <Ms2ger> Ms2ger has joined #css
07:33:24 <nsakai> nsakai has joined #css
07:44:21 <nsakai> nsakai has joined #css
07:44:47 <kensaku> kensaku has joined #css
07:48:35 <stearns> stearns has joined #css
07:49:33 <stearns> stearns has joined #css
07:50:32 <dbaron> dbaron has joined #css
07:50:54 <stearns> stearns has joined #css
07:53:25 <nsakai> nsakai has joined #css
07:56:57 <SimonSapin> SimonSapin has joined #css
07:57:14 <glenn> glenn has joined #css
07:58:58 <tomoyuki> tomoyuki has joined #css
08:00:21 <SimonSapin> SimonSapin has joined #css
08:01:06 <tokamoto> tokamoto has joined #CSS
08:01:12 <kensaku> kensaku has joined #css
08:01:14 <plh> plh has joined #css
08:01:30 <nsakai> nsakai has joined #css
08:01:44 <kotakagi> kotakagi has joined #css
08:02:54 <kotakagi> kotakagi has joined #css
08:03:01 <dino> dino has joined #css
08:03:08 <sakkuru> sakkuru has joined #css
08:03:17 <Yune> Yune has joined #css
08:03:40 <SimonSapin> SimonSapin has joined #css
08:04:33 <Norbert> Norbert has joined #css
08:04:57 <nsakai> nsakai has joined #css
08:05:46 <rotsuya> rotsuya has joined #css
08:06:28 <glazou> glazou has joined #css
08:07:02 <mihara> mihara has joined #css
08:07:16 <cabanier> cabanier has joined #css
08:07:35 <drublic> drublic has joined #css
08:08:00 <lmclister> lmclister has joined #css
08:09:08 <TabAtkins_> TabAtkins_ has joined #css
08:09:11 <kazutaka> kazutaka has joined #css
08:09:12 <sakih> sakih has joined #css
08:09:49 <nsakai> nsakai has joined #css
08:09:57 <antonp> antonp has joined #css
08:09:58 <Bert> ScribeNick: Bert
08:11:31 <yamaday> yamaday has joined #css
08:12:40 <nsakai> nsakai has joined #css
08:13:41 <Rossen> Rossen has joined #css
08:13:57 <Zakim> Zakim has joined #css
08:14:05 <sakkuru> sakkuru has joined #css
08:14:08 <mishida> mishida has joined #css
08:15:14 <JohnJansen> JohnJansen has joined #css
08:15:39 <nsakai> nsakai has joined #css
08:16:11 <Bert> Topic: Before/after/head/foot/tail/start/end terminology
08:17:30 <arronei> arronei has joined #css
08:17:30 <rhauck> rhauck has joined #css
08:17:31 <Bert> fantasai: We have issue in writing mode spec about terminology.
08:17:36 <dbaron> http://dev.w3.org/csswg/css3-writing-modes/
08:17:42 <SteveZ> SteveZ has joined #css
08:17:50 <jet> jet has joined #CSS
08:17:53 <Rossen> Rossen has joined #css
08:18:05 <dbaron> http://dev.w3.org/csswg/css3-writing-modes/#abstract-box
08:18:22 <nsakai> nsakai has joined #css
08:18:35 <Bert> ... Two sets of terms, physical (top, left...) and flow-relative terms.
08:18:45 <Bert> ... Block axis and inline axis.
08:19:01 <Bert> ... Start/end is in inline axis
08:19:22 <knobuta2> knobuta2 has joined #css
08:19:42 <Bert> ... line relative (line-left, line-over...)
08:19:56 <dbaron> s/line-over/over/
08:20:40 <evanli> evanli has joined #css
08:21:07 <Bert> ... Old :before and :after are in document order.
08:21:25 <Bert> ... Flex can be in any axis.
08:21:45 <Bert> ... Speech have before/after. too.
08:21:55 <Shinji> Shinji has joined #css
08:21:55 <dbaron> fantasai: longstanding issue about confusion figuring out which of start/before end/after were which.  Sylvain also raised issue about confusion with :before and :after.
08:22:01 <Bert> howcome: We also need inside/outside for paged media.
08:22:24 <Bert> SteveZ: relative to spine of 2-page spread.
08:22:56 <Bert> fantasai: thead/tfoot similar to head/foot terms.
08:23:09 <Bert> ... But feedback on list was that it was confusing.
08:23:18 <nsakai> nsakai has joined #css
08:23:36 <Bert> ... E.g., Japanese uses "line head" for start of line.
08:23:46 <Bert> howcome: N E S W ?
08:24:22 <Bert> fantasai: IN bidi, E/W would swicth. even more confusing.
08:24:43 <Bert> Rossen: prefix with box-?
08:24:52 <Bert> fantasai: Avoid too long words.
08:25:26 <Bert> ... Some places where these terms could be used:
08:25:36 <lstorset> lstorset has joined #css
08:25:47 <Bert> ... grid start, margin start, start border radius...
08:26:38 <Bert> ... My latest idea: [lists many pairs]
08:26:56 <koji> koji has joined #css
08:27:04 <Bert> SteveZ: When I first asked if Head/foot fit Japanese, I was told yes. Now it turns out it doesn't
08:27:12 <Bert> fantasai: It is somewhat inconsistent.
08:27:34 <Bert> SteveZ: That is the audience we target. has to be logical for them.
08:27:38 <arronei> before/after, pervious/next, lead/tral, ahead/behind, head/foot, above/below, fore/aft, ante/post, prior/next, front/rear, pre/post, early/late
08:27:48 <massimo_> massimo_ has joined #css
08:27:59 <arronei> s/tral/trail
08:28:07 <nsakai> nsakai has joined #css
08:28:13 <Bert> fantasai: Grid is logical.
08:28:26 <Bert> bert: No, for me grid is physical.
08:28:49 <Bert> SteveZ: [something about DOM order]
08:29:12 <Bert> ... People learn the terms after a while.
08:29:18 <tantek> tantek has joined #css
08:29:31 <Bert> ... Unless the termss are significantly better, there is not much reason to change.
08:29:34 <lmclister1> lmclister1 has joined #css
08:29:53 <Bert> ... Head&foot seem not optimal for the intended audience.
08:30:05 <Bert> howcome: I keep mixing htem up.
08:30:15 <glazou> TabAtkins, glazou: no grid is logical
08:30:21 <Bert> ... Just arbitrary.
08:30:30 <Bert> SteveZ: It *is* arbtrary.
08:30:36 <Bert> howcome: Pre/post?
08:30:49 <Bert> SteveZ: : Still unclear it is blovk or line.
08:31:04 <Bert> TabAtkins_: I was convinced by before/after at first.
08:31:21 <Bert> glazou: It is not confusing for avg web designer
08:31:29 <Bert> howcome: I think it is.
08:31:36 <Bert> glazou: Pre/post means nothing.
08:31:59 <Bert> peter: :before coul be in line *or* block diretcion.
08:32:17 <Bert> glenn: I had to memorize, but then had no more pbs.
08:32:36 <Bert> howcome: 'block-start'/'block-end'
08:32:46 <Bert> sylvaing: Gets long for border radius
08:32:56 <nsakai> nsakai has joined #css
08:32:59 <Bert> howcome: don't need it there
08:33:19 <stearns> s/sylvaing/arron/
08:33:25 <rhauck> rhauck has joined #css
08:33:35 <Bert> SteveZ: I'm not convinced. All neutral words have the pb that they don't say block/line.
08:33:59 <Bert> ... It probably doesn't matter. As Glenn said. you memorize it.
08:34:18 <Bert> ... Add exra words is not wordth it.
08:35:12 <Bert> Bert: In the Box model I proposed using A, B, C, and D sides.
08:35:38 <Bert> fantasai: That doens't work well witht he grid.
08:36:27 <Bert> SteveZ: I'd just reverse to with before/after
08:36:36 <Bert> TabAtkins_: I'd prefer head/foot.
08:37:10 <Bert> SteveZ: All uses of before/after are in DOM order.
08:37:20 <Bert> glazou: We do this for 18n
08:37:44 <Ms2ger> s/18n/i18n/
08:37:48 <Bert> ... No consensus.
08:38:33 <Bert> ... So stick with before (for top) and after for (bottom), is that it?
08:38:48 <evanli> evanli has joined #css
08:38:50 <Bert> SteveZ: Go back to before/after.
08:39:05 <Bert> koji: Proposal last May.
08:39:14 <dbaron> http://lists.w3.org/Archives/Public/www-style/2012May/1149.html has a resolution to change to head/foot
08:39:16 <Bert> ... It was resolved and raised again.
08:39:53 <Bert> sylvaing: webkit uses before/after
08:40:00 <Bert> TabAtkins_: (with prefixes)
08:40:16 <Bert> ... There is next to no usage of it, in our surveys.
08:40:42 <Bert> peter: No real user feedback
08:40:52 <JohnJansen> s/sylvaing/arronei
08:41:50 <Bert> koji: Talked to r12a and he said like stevez, if terms improved over before/after then OK, but head/foot didn't seem to improve.
08:42:08 <nsakai> nsakai has joined #css
08:42:24 <Bert> TabAtkins_: If before/after are half acceptable, then why nor pre/post
08:42:35 <Bert> fantasai: Confuses with DOM order.
08:42:51 <fantasai> s/Confuses/before and after confuses/
08:42:51 <Bert> TabAtkins_: I think it is reasonable, in my attempts.
08:42:59 <Bert> glenn: If you use both XSL and CSS,
08:43:05 <Bert> ... new terms will be confusing.
08:43:24 <fantasai> [Tab and fantasai were talking about ease of wording spec prose]
08:43:40 <Bert> TabAtkins_: On the web almost no uses of the terms.
08:43:54 <Bert> SteveZ: Audience is not just web authors.
08:44:05 <Bert> peter: That argument isn't solving any pb.
08:44:28 <massimo> massimo has joined #css
08:44:31 <Bert> SteveZ: I propose we agree to drop head/foot and leave open what the terms are going to be.
08:44:53 <glazou> dbaron: XSL FO won't be in Mozilla...
08:45:04 <dbaron> (in response to glenn)
08:45:53 <Bert> glazou: Steve's seems acceptable for now.
08:46:14 <tantek> tantek has joined #css
08:46:30 <evanli> evanli has joined #css
08:47:10 <Bert> REASOLVED head/foot are not the terms (revert earlier decision), that doens't say anything about other terms.
08:47:30 <Bert> s/REASOLVED/RESOLVED/
08:47:54 <Bert> fantasai: Some properties use line-relative direction.
08:48:10 <Bert> ... Text decoration, ruby should also.
08:48:43 <Bert> ... Should I use over/under there?
08:48:53 <fantasai> ... currently useing above/below
08:49:04 <Bert> SteveZ: In vertical, those terms don't make much sense.
08:49:05 <nsakai> nsakai has joined #css
08:49:15 <JohnJansen> I think trackbot requires that the 'resolved' syntax be correct. so I'm re-resolving our non-resolution to be resolved...
08:49:44 <glenn> dbaron: never say never
08:49:47 <JohnJansen> RESOLVED: head/foot are not the terms (revert earlier decision), that doesn't say anything about other terms.
08:50:09 <Bert> Tab: over/under seems fine to me.
08:50:11 <rotsuya_> rotsuya_ has joined #css
08:50:32 <Bert> Peter: We alrady have over/under in text-deco, good to not add more terms.
08:51:18 <Bert> RESOLVED: Use over/under terms instead of above/below
08:51:52 <Bert> SteveZ: ascender/descender go "up" and "down"
08:51:58 <nsakai> nsakai has joined #css
08:52:04 <Bert> ... rotated fonts
08:52:26 <Bert> Peter: Text rotation, what is over/udnder?
08:52:31 <Bert> fantasai: Stays on same side
08:53:06 <nsakai> nsakai has joined #css
08:53:10 <Bert> Topic: CSS Transforms (continued from yesterday)
08:54:44 <krit> krit has joined #css
08:54:47 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17433
08:54:55 <Bert> Dirk: Issue about how do 3D transf in 2D context.
08:55:11 <cabanier> cabanier has joined #css
08:55:25 <Bert> ... Do we need to specify it or is it obviousl, mathematically?
08:55:58 <Bert> s/obviousl/obvious/
08:56:10 <Bert> ... Can we ask the implementers?
08:56:29 <Bert> dino: Loking at last comment in the bug.
08:57:26 <Bert> ... Youre asking if we need to define what flatten means?
08:57:37 <Bert> dirk: Yes, is it not obvious enough?
08:57:45 <Bert> dino: No, I think it is not.
08:57:58 <nsakai> nsakai has joined #css
08:58:12 <Bert> ... Rendering into 2D texture and that is composited.
08:58:23 <Bert> ... Perspective proeprty sets up te coord system.
08:58:39 <Bert> ... I think you should take an action to define it.
08:58:59 <Bert> dbaron: Roc or somebody would know, I'm not the best person.
08:59:14 <dbaron> s/somebody/mattwoodrow/
08:59:21 <Bert> dino: Probably we all do the same thing, but still worth defining.
08:59:46 <glazou> RRSAgent, this is Style
08:59:46 <RRSAgent> I'm logging. I don't understand 'this is Style', glazou.  Try /msg RRSAgent help
08:59:51 <Bert> Dirk: It seems an implementation detail, but I'd like some doc that describes how it works.
08:59:59 <dbaron> trackbot, this is style
08:59:59 <trackbot> Sorry, dbaron, I don't understand 'trackbot, this is style'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
09:00:16 <Bert> dino: I can also take an action to try and write it up.
09:00:48 <Bert> ACTION dino: propose wording how you flatteen  3d subtree into normal CSS 2s rendering.
09:00:48 <trackbot> Created ACTION-515 - Propose wording how you flatteen  3d subtree into normal CSS 2s rendering. [on Dean Jackson - due 2012-11-06].
09:00:50 <Rossen> Rossen has joined #css
09:01:03 <Bert> s/2s/2D/
09:01:54 <Bert> dirk: Other issues are editorial and we already have actions.
09:02:03 <Bert> ... Remaining is unmatrix stuff.
09:02:09 <Bert> dino: We can do it offline.
09:02:21 <Bert> ... We all want it to look correct and the same.
09:02:51 <Bert> dino: We just need to know why Mozilla did it differently.
09:03:10 <nsakai> nsakai has joined #css
09:03:22 <Bert> dirk: I'd like to ask for LC in about 4 weeks, depending on whether these last issues are solved.
09:04:11 <Bert> Dong-yong lee: we're looking in to stereo display.
09:04:19 <tokamoto> tokamoto has joined #css
09:04:41 <Bert> ... Has anybody in the group thought about that?
09:05:02 <Bert> dino: Would you make 2D objects appear in 3D, or only the existing 3D objects.
09:05:11 <Bert> Dong-yong: The latter.
09:05:34 <Bert> dino: Should be possible for most content, just slightly different transform for the two views.
09:06:00 <Bert> ... the 3D isn't a realistic 3D, strange perspective distances, etc.
09:06:10 <tokamoto> tokamoto has joined #css
09:06:18 <Bert> Dong-yong: We tried, and we can render many interesting 3D transforms quite nicely.
09:06:24 <Bert> ... E.g., on 3D TV.
09:06:46 <Bert> ... But we want some correct or nive way or some specification for doing it.
09:07:09 <stearns> s/nive/nice/
09:07:11 <Bert> ... We are not sure if it is a good idea how/whether to display in 3D.
09:07:19 <Bert> dino: Some extra properties in CSS?
09:07:25 <Bert> dong-yong: Maybe
09:07:56 <Bert> dirk: I'd like to read the propsalon the m-list. Don't want ot add complexity right now.
09:08:02 <Bert> ... Maybe next version.
09:08:03 <nsakai> nsakai has joined #css
09:08:19 <Bert> glazou: We need to publishe this version as soon as possible.
09:08:22 <glenn_> glenn_ has joined #css
09:08:26 <Bert> ... But interesting for next version.
09:08:43 <Bert> dino: Can Dong-Yong send a proposal/idea to m-list?
09:08:52 <florianr> florianr has joined #css
09:09:03 <Bert> Dong-yong: Yes, I can write it. We don't necessarily propose a solution.
09:09:16 <Bert> glazou: We need you input, with or without proposal.
09:09:35 <Bert> dino: Yes, the backgtound info is as important as the proposal.
09:10:00 <Bert> dong-yong: The extension should be minimal. And all 3D content should also display on a 2D display.
09:10:50 <glenn_> glenn_ has joined #css
09:11:01 <Bert> glazou: So a few edits base don today/yesterday, and then ask for LC?
09:11:24 <Bert> dino: Dirk said within 4 weeks we'll ask.
09:12:03 <Bert> [Discussion about agenda]
09:12:42 <glenn> glenn has joined #css
09:12:56 <nsakai> nsakai has joined #css
09:15:03 <liam> liam has joined #css
09:15:04 <Bert> Topic: Reversing transitions
09:15:24 <Bert> dbaron: Does IE implement something for that?
09:15:25 <stearns> s/reversing transitions/reversing interrupted transitions/
09:15:45 <Bert> ... E.g., on hover, and then the hover ends, do you moves back at same speed or in same duration?
09:16:18 <Bert> ... Therwe were 2 proposals.
09:16:33 <Bert> ... Dino's proposal and my impl in Gecko.
09:16:38 <Bert> ... I prefer mine.
09:17:33 <Bert> ... Is it a good idea to discuss it now? Or just figure out a way to move forward on the issue?
09:17:54 <Bert> Tab: I wanted to write up examples, but I never did.
09:18:06 <Bert> dbaron: Wait for tab's stuff?
09:18:23 <Bert> .. The issue was knowing what it looks like in practice.
09:18:33 <Bert> ... Other issue:
09:19:01 <Bert> ... We don't allow inherit and initial to be keywords in list in some properties.
09:19:05 <Bert> ... Also none
09:19:27 <Bert> ... Transition proeprty list should never allow those keywords in a list, only isolated.
09:20:00 <massimo> massimo has joined #css
09:20:07 <glenn> glenn has joined #css
09:20:28 <dbaron> RESOLUTION: none, inherit, and initial are not allowed at any position within the list for 'transition-property'; such a declaration is syntactically invalid
09:20:32 <florianr> On transition reversal, I believe that we had concluded in a previous f2f (paris or hamburg) that next level could introduce a new property to switch between the  various possible alternatives, and that it made the choice less critical one. Whatever we pick has to be reasonable, but doesn't have to solve all usecases
09:20:53 <dbaron> http://dev.w3.org/csswg/css3-transitions/#animatable-types
09:21:01 <Bert> dbaron: In section on animation of property types:
09:21:13 <Bert> ... colors in pre-multiplied space?
09:21:24 <Bert> tab: I think we watned to use pre-multipled in all cases.
09:21:37 <Bert> ... Need to be consistent with gradients, etc.
09:21:45 <Bert> dirk: And with SVG
09:22:17 <Bert> dbaron: But SVG 1.1 had opactity and color on separate proeprties.
09:22:34 <Bert> dino: Still has the same problem of interpolating in 4 channels.
09:22:45 <Bert> dbaron: Gradient says pre-multiplied.
09:22:45 <glazou> s/watned/wanted
09:22:54 <Bert> ... Some OS's don't give you that.
09:23:00 <rubylin> rubylin has joined #css
09:23:04 <Bert> ... I'd be happy with pre-multiplied.
09:23:17 <Bert> Rik: Prefer non-pre-multiplied.
09:23:35 <Bert> ... Better for SVG and Canvas.
09:23:54 <Bert> Tab: (How did Canvas end up different, I wonder...)
09:24:10 <glenn> glenn has joined #css
09:24:12 <Bert> ... Because CSS gradient has been pre-multuiplied for a while.
09:25:02 <Bert> Dino: benefit of pre-mul is you don't gray when anamating to transparent. And can solbe it by going to rgb(...)
09:25:13 <oyvind> I believe we encountered issues on the web when we did non-premultiplied transitions
09:25:21 <Bert> Tab: Can add some color stops.
09:25:25 <kazutaka> kazutaka has joined #css
09:25:35 <oyvind> hovering comments on youtube looked weird, for instance
09:25:41 <Bert> ... But SVG is adding  mesh gradients and you cannot do the same trick.
09:26:03 <Bert> dbaron: I feel more strongly about animations being pre-mul than about gradients.
09:26:27 <Bert> ... If an animation from/to transparent is ugly, thta is a pb.
09:26:48 <Bert> Rik: Transparent is black, that is the pb.
09:27:13 <Bert> sylvaing: That's why we ended up with pre-mul, isn't it?
09:27:46 <Bert> dbaron: If you anim from green 20% opaque to 100% opaque red.
09:28:25 <Bert> .. not the same issue as going through gray, but in non-mul space, the green will first get deeper before fading.
09:28:49 <leaverou> dbaron’s example http://dabblet.com/gist/3979232
09:29:00 <Bert> ... Our MSIL anim code is using pre-mul, I'm pretty sure.
09:29:32 <Bert> dino: One old proposal was to transition in hsl.
09:29:38 <dbaron> http://dbaron.org/css/test/2009/transitions/transitions-alpha
09:29:38 <Bert> dbaron: I have a test case:
09:30:15 <Bert> tab: webkit is non-pre-multiplied.
09:30:22 <Bert> dbaron: FF is pre-mul.
09:30:28 <divya> divya has joined #css
09:30:51 <Bert> ... So actually everybody is doing pre-mul after all.
09:30:53 <plh> plh has joined #css
09:30:58 <Bert> tab: [checking]
09:31:14 <Bert> lea: Did FF change?
09:31:27 <Bert> dbaron: No, we always did.
09:32:10 <Bert> dino: So we all do the same. Let's specify it.
09:32:28 <Bert> tab: Yes, chrome does pre-mul, too.
09:32:47 <Bert> [dbaron adding a test]
09:33:29 <Bert> RESOLVED: Animations of colors are in pre-multiplied space.
09:36:04 <shepazu> shepazu has joined #css
09:37:42 <glazou> glazou has joined #css
09:39:36 <florianr> florianr has joined #css
09:39:42 <tokamoto> tokamoto has joined #css
09:45:36 <tokamoto> tokamoto has joined #css
09:51:58 <tomoyuki> tomoyuki has joined #css
09:56:13 <tomoyuki> tomoyuki has joined #css
09:57:43 <tomoyuki> tomoyuki has joined #css
09:59:15 <yamaday> yamaday has joined #css
09:59:51 <tomoyuki> tomoyuki has joined #css
10:00:17 <Shinji> Shinji has joined #css
10:00:18 <mishida> mishida has joined #css
10:01:05 <tomoyuki> tomoyuki has joined #css
10:02:53 <glazou> glazou has joined #css
10:07:29 <tomoyuki> tomoyuki has joined #css
10:08:15 <mihara__> mihara__ has joined #css
10:09:09 <rotsuya_> rotsuya_ has joined #css
10:09:38 <fantasai> ScribeNick: fantasai
10:09:40 <lmclister> lmclister has joined #css
10:09:46 <fantasai> Topic: text-overflow
10:11:31 <jet> jet has joined #CSS
10:12:26 <fantasai> tantek: First sub-item is wrt selection behavior of ellipsed content
10:12:40 <fantasai> tantek: Second issue is what should we do about ellipsing block overflow content
10:13:05 <yune> yune has joined #css
10:13:08 <glazou> http://www.w3.org/Style/CSS/Tracker/issues/279
10:13:13 <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0219.html
10:13:23 <fantasai> fantasai: I think we have a resolution from previous F2F as being out-of-scope for this feature
10:13:37 <fantasai> tantek: captured on css4-ui wiki
10:13:44 <fantasai> tantek: so should be resolved wrt this meeting
10:13:51 <fantasai> tantek: first issue wrt selection behavior is unspecified in spec
10:14:02 <fantasai> tantek: issue is, should it be specified, and if so... how
10:14:27 <Rossen> Rossen has joined #css
10:14:50 <fantasai> tantek: One is wrt copy/paste, another is what hapens when you select
10:15:22 <fantasai> tantek: in Safari, you can see that the copy-pasted text is the complete text
10:15:44 <kensaku> kensaku has joined #css
10:15:49 <fantasai> tantek: I think this is what is expected by users, implemented by other browsers, should put it in the spec
10:16:37 <fantasai> arronei: There's a problem in this case is that the ellipsis doesn't look highlighted
10:17:17 <fantasai> [some discussion of DOM ranges]
10:17:40 <fantasai> Bert: Is this the first time we talk about selection in CSS?
10:17:54 <fantasai> tantek: I thought we had something in the Selectors spec
10:18:05 <fantasai> fantasai: Doesn't say what is selected, or selection behavior, just what the selection looks like
10:18:17 <fantasai> Bert: If you use text-transform: uppercase; in selection, you may get uppercase or not
10:18:28 <fantasai> Bert: Not opposed, but do we think we're strong enough to say what happens?
10:18:33 <fantasai> tantek: In this case I think we are
10:18:38 <fantasai> tantek: have strong interop
10:18:52 <fantasai> tantek: Another issue is list markers -- what gets copied?
10:19:15 <fantasai> sylvaing: We put this on the agenda because we have an issue wrt css3-ui definition
10:19:54 <krit> krit has joined #css
10:20:00 <krit1> krit1 has joined #css
10:20:26 <fantasai> RESOLVED: Selecting the ellipsis selects the ellipsed text.
10:20:35 <fantasai> plinss: I think the ellipsis should look selected, though
10:21:05 <fantasai> Rossen: We're now talking about selection which is happening with something not in the content
10:21:22 <fantasai> glazou: Could select a list item by clicking list marker
10:21:26 <fantasai> tantek: label selects an input
10:21:45 <fantasai> arronei: It's weird and misleading if you don't highlight the ellipsis
10:22:12 <fantasai> tantek: No implementation as far as I know will actually let you select the ellipsis itself
10:22:16 <fantasai> tantek: I can't click on it and highlight it
10:22:52 <fantasai> antonp: It's a problem with generated content in general
10:22:59 <fantasai> tantek: It's bad behavior, but also interoperable
10:23:28 <fantasai> tantek: There are some ppl that want to specify bad behavior that's interoperable
10:23:41 <fantasai> tantek: Some ppl take approach of leaving things vague, allowing for improvement
10:24:00 <fantasai> tantek: I'm of the opinion that we should be vague in L3, and put normative should in L4
10:24:20 <fantasai> Bert: Add some kind of note of what we intend
10:24:33 <fantasai> plinss: We don't require test passes on shoulds
10:24:42 <fantasai> plinss: So let's just put a should.
10:25:00 <kotakagi> kotakagi has joined #css
10:25:27 <fantasai> dbaron: What do you think UAs should do if part of the ellipsed text is selected?
10:25:28 <massimo> massimo has joined #css
10:25:34 <fantasai> dbaron: e.g. via DOM manipulation
10:25:47 <dbaron> ... or text selected prior to the resize that makes the ellipsis
10:25:55 <dbaron> ... or selection of text with the keyboard
10:26:01 <dbaron> (maybe)
10:26:15 <glazou> show ellipsis in a tooltip and allow seleciton in the tooltip
10:26:21 <fantasai> tantek: Looks like selection with keyboard goes one character at a time
10:26:35 <fantasai> TabAtkins_: For highighting the ellipsis, think should only do so once contain the entire ellipsed text
10:26:50 <fantasai> fantasai: And otherwise don't select any of it?
10:26:59 <fantasai> dbaron: Don't know I'd require that; could do better
10:27:21 <fantasai> dbaron: e.g. selecting part of ellipsis proportional to selected text
10:27:39 <fantasai> tantek: That makes me lean towards a note, since we don't know exactly the right behavior
10:27:53 <fantasai> plinss: I don't think we need to specify in excruciating detail, but give them some broad strokes
10:28:12 <fantasai> plinss: If everything is selected, must select the whole ellipssis
10:28:22 <fantasai> plinss: if partial selection, may indicate that some other way
10:28:59 <tokamoto> tokamoto has joined #css
10:29:12 <fantasai> s/must/should/
10:29:47 <fantasai> RESOLVED: If all of ellipsed text is selected, show selection of ellipsis
10:30:10 <tokamoto> tokamoto has joined #css
10:30:37 <fantasai> RESOLVED: put a note that behavior wrt partially-selected text is up to UA
10:30:48 <divya> divya has joined #css
10:31:16 <fantasai> Rossen: Have a minor issue wrt the example in the testcases
10:31:36 <fantasai> Rossen: You only have an ellipsis on the last line of text, and they are confused
10:31:57 <fantasai> Rossen: They think it's defining multiline ellipsis because the example only shows the ellipsis on the last line
10:32:07 <fantasai> Rossen: This example sets the expectations
10:32:41 <fantasai> fantasai: Change it to "CSS AWESOME IS"
10:33:33 <rubylin> rubylin has joined #css
10:33:35 <fantasai> ACTION tantek: fix text-overflow example in the spec to not ellipse the last line, but an earlier line
10:33:35 <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
10:33:44 <fantasai> o_O?
10:33:51 <glazou> ROFL
10:34:33 <fantasai> plinss asks for clarifications on what this property does
10:35:30 <fantasai> various explain
10:35:45 <fantasai> Rossen: Other issue is wrt scrolling, and expectation to keep the ellipsis, recalc on every scroll
10:35:53 <fantasai> Rossen: Currently I believe no implementation does tha
10:36:03 <fantasai> Rossen: No one has actually asked for this behavior
10:36:32 <fantasai> Rossen: Depending on the underlying implementation, whether or not we need to reformat line of text when you render it, that behavior ties display with layout, which is not a good idea
10:36:47 <fantasai> tantek: You're saying you don't want to scroll content into view?
10:37:01 <fantasai> Rossen: If you have a horizontal scroller, no implementation does what you're saying
10:37:04 <fantasai> tantek: Not true, FF does it.
10:38:40 <fantasai> JohnJansen: Tantek, are your tests online somewhere?
10:38:49 <fantasai> plinss: Secondary question: can you turn these into real tests in the test suite
10:39:03 <fantasai> Topic: Case-insensitivity of Identifiers
10:39:06 <tantek> the tests were emailed to the list a while ago
10:39:08 <tantek> I can resend
10:39:11 <JohnJansen> ACTION: Tantek send the test cases to the list
10:39:11 <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
10:39:22 <tantek> and yes, we have an outstanding need for css3-ui test cases.
10:39:32 <tantek> (unactioned)
10:39:33 <fantasai> ishida: We may need to punt on a decision from i18n
10:39:41 <jet> jet has joined #CSS
10:39:48 <stearns> tantek's testcase: https://bug690187.bugzilla.mozilla.org/attachment.cgi?id=583694
10:39:49 <fantasai> dbaron: Speaking of i18n, seems we can no longer assign actions to Tantek
10:40:01 <tantek> thanks stearns!
10:40:03 <r12a> r12a has joined #css
10:40:10 <JohnJansen> ACTION: tantek send the test cases to the list
10:40:10 <trackbot> Could not create new action (unparseable data in server response: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128)) - please contact sysreq with the details of what happened.
10:40:12 <tantek> :D
10:40:34 <fantasai> http://wiki.csswg.org/topics/custom-ident-case-sensitivity
10:41:49 <glazou> right, that's the issue, the python script on the server side has a problem with utf-8
10:42:05 <fantasai> fantasai summarizes the issue
10:42:10 <fantasai> (see above)
10:42:15 <hober> ACTION: dbaron to make tantek send the test cases to the list
10:42:16 <trackbot> Created ACTION-519 - Make tantek send the test cases to the list [on David Baron - due 2012-11-06].
10:42:49 <fantasai> ishida: For extending out to full Unicode, recommendation would be to use default case-folding
10:43:05 <fantasai> ishida: Would work for most people, except Turkish and Lithuanian
10:43:14 <fantasai> ishida: because of dotted is
10:43:31 <fantasai> ishida: Keeping case-insensitivity with default Unicode case-folding would create a problem for these users
10:43:37 <fantasai> ishida: Don't know what more we can say oday
10:43:50 <fantasai> ishida: We don't have a conclusion in i18n
10:44:14 <fantasai> TabAtkins_: I think case-insensitivity in CSS was a mistake, but given we have this problem already, I would say keep it to ASCII
10:44:21 <fantasai> TabAtkins_: HTML already does htis
10:44:29 <JohnJansen> ACTION: fantasai make tantek fix text-overflow example in the spec to not ellipse the last line, but an earlier time
10:44:29 <trackbot> Created ACTION-520 - Make tantek fix text-overflow example in the spec to not ellipse the last line, but an earlier time [on Elika Etemad - due 2012-11-06].
10:44:29 <leaverou> s/htis/this
10:44:53 <fantasai> ishida: Problem with that is writing French, would assume you have case-insensitivity, but one character in your word happens to have an accent, would not be
10:46:06 <fantasai> TabAtkins_: Could recommend to authors to just use lowercase all the time
10:46:11 <JohnJansen> JohnJansen has joined #css
10:46:22 <fantasai> fantasai: Or just recommend not relying on case-insensitivity, and always using consistent casing
10:46:41 <fantasai> TabAtkins asks for ishida's opinion
10:47:02 <fantasai> ishida: I personally feel that this seems a good way forward, but would have to discuss with i18n
10:47:13 <fantasai> TabAtkins asks for a resolution by end of TPAC
10:47:23 <fantasai> ishida: Not sure, but could have an answer by next Thursday, would that be ok?
10:47:44 <fantasai> norbert: What extent do you actually need case-insensitivity
10:47:59 <fantasai> TabAtkins: There's a significant fraction of people who use capital letters for CSS keywords
10:48:06 <fantasai> TabAtkins: We can't change that.
10:49:02 <rhauck> rhauck has joined #css
10:49:38 <fantasai> fantasai: So can we come to a conclusion on what we're doing here, pending i18n approval?
10:49:57 <fantasai> [explosion]
10:51:33 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html
10:51:51 <fantasai> [argument over what was resolved; see minutes above for actual resolution]
10:52:08 <fantasai> Bert is not happy with ASCII case-insensitivity
10:52:10 <jet> http://w3cmemes.tumblr.com/image/29509229758
10:52:15 <knobuta2> knobuta2 has joined #css
10:52:37 <fantasai> SteveZ: My understanding is we asked i18n to come back with a recommendation
10:53:03 <mgylling> mgylling has joined #css
10:53:05 <fantasai> TabAtkins: And we want to tentatively resolve on something
10:53:22 <fantasai> but there is no consensus, so we are waiting for i18n
10:54:36 <fantasai> Topic: Grid Layout
10:54:51 <fantasai> SteveZ: my issue is how to make progress on Peter's concerns. But not sure her eis the right place to do that
10:55:01 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0828.html
10:55:24 <fantasai> plinss: Takeaway from meeting with MSFT was tha where there were differences between proposals, capture as issues
10:55:27 <fantasai> plinss: and publish the spec
10:55:43 <fantasai> plinss: And then modify the spec to bring in significant aspects of my proposal
10:55:53 <fantasai> plinss: I was trying to go towards a general-purpose design grid
10:56:06 <fantasai> plinss: Don't need all those features in this level, but want to take in a direction that's compatible
10:56:16 <fantasai> plinss: I believe as the syntax stands now, it is incompatible
10:56:27 <paul___irish> paul___irish has joined #css
10:56:40 <fantasai> TabAtkins: From my understanding of discussion with fantasai, it's mostly just syntax changes that are needed
10:56:51 <fantasai> TabAtkins: basically changing -position/-span to -start/-end
10:57:03 <fantasai> TabAtkins: and then other aspects slot in
10:57:14 <fantasai> SteveZ: Want to see next steps happen
10:57:34 <fantasai> fantasai: I think it's mainly a syntax brainstorming problem
10:57:45 <fantasai> fantasai: There are various constraints we want to solve here
10:58:24 <dbaron> Peter: I don't require major architectural changes to the proposal; just want minor changes to allow future changes
10:59:05 <dbaron> Rossen: So do think at this point that everything will actually overlap?
10:59:18 <dbaron> Peter: I think room for moderate tweaks in syntax and terminology, to keep existing model with terminology and syntax that will be compatible with the more expanded model.
10:59:30 <dbaron> Peter: I don't see reason we should decide we can't do it and give up.
11:00:16 <dbaron> fantasai: I tried mocking up on a whiteboard; main area I got stuck on is that Peter wants a model where you say which lines you're between, whereas MS model allows for an auto-placement model, which requires ability to express with start or end positions plus a span.
11:00:24 <dbaron> fantasai: I had trouble figuring out a sane syntax that could represent both.
11:00:29 <dbaron> Peter: I had notions of a functional notation.
11:00:41 <dbaron> Peter: ... opposite side wants to be nth version of that line?
11:00:51 <dbaron> Peter: We should ... and brainstorm.
11:01:06 <dbaron> fantasai: Yep, brainstorming.
11:01:14 <dbaron> Peter: My proposal can be broken into discrete levels.
11:01:26 <dbaron> Peter: First order is agreeing to express grid model in terms of lines and fields instead of rows and columns.
11:01:40 <dbaron> Peter: So expose it that way and present it to authors in that mindset.
11:01:50 <dbaron> Peter: fields instead of cells, roles instead of names
11:02:06 <dbaron> Peter: I don't know if we decide to adopt those as principles or wait for real syntax.
11:02:22 <dbaron> fantasai: I think if we figure out the syntax it will be easier to write the prose; but I'm not the editor.
11:02:37 <dbaron> Peter: I think ??? is an important direction; based on lines and fields instead of rows and columns.
11:02:42 <dbaron> Peter: That distinction influences syntax.
11:02:47 <dbaron> Peter: Syntax now is rows, columns, and spans.
11:03:00 <dbaron> Bert: There's a danger using terms like fields, which have a meaning in some traditions.
11:03:09 <dbaron> Bert: Our fields aren't exactly what they're used for in those traditions.
11:03:27 <dbaron> Peter: I don't care about the exact words; don't want to be hung up on terms; but opposed to rows, columns, spans.
11:03:38 <dbaron> SteveZ: We need to set up a call to discuss this.
11:03:53 <dbaron> Tab: ... .  I contacted Phil about being a coeditor on this spec.
11:04:03 <dbaron> SteveZ: Can we have a 15 minute update following the next CSS call?
11:04:14 <dbaron> SteveZ: Status check of where we are on that.
11:04:19 <SimonSapin> SimonSapin has joined #css
11:04:44 <SimonSapin> SimonSapin has joined #css
11:04:45 <dbaron> SteveZ: Outside of the telecon time.
11:05:04 <dbaron> JohnJansen: Why not part of the agenda on the next call?
11:05:10 <dbaron> ?: Not having the brainstorming on the call.
11:05:21 <dbaron> Peter: Have a deadline for brainstorming to be done and report back to the group.
11:05:33 <dbaron> SteveZ: Want it less than a month.
11:05:46 <dbaron> Rossen: Reasonable to dedicate some time before the next conf call.
11:06:12 <dbaron> Rossen: Minimal overlap that needs to go in the level 1 spec.
11:06:37 <dbaron> Rossen: Two things we need to guarantee: (1) that there's no features of current grid that will contradict further devel. of overlap grid
11:06:59 <dbaron> Rossen: ... (2) minimal set of syntax rewrite we'll need to do for current grid to verify (1)
11:07:18 <dbaron> Rossen: If we come to the conclusion they're not overlappable, because of significant differences, then we each go our separate ways.
11:07:22 <dbaron> SteveZ: ... and agree to disagree
11:07:38 <dbaron> Rossen: So I guess we have an action to get together and talk about this.
11:07:52 <dbaron> Bert: My next 3 weeks are very busy.
11:07:57 <dbaron> Rossen: Who needs to be on call?
11:08:14 <dbaron> Rossen: Peter, Elika, Bert, Tab, Steve, Rossen, Phil
11:08:35 <dbaron> Rossen: Let's schedule offline.
11:08:49 <dbaron> ACTION Rossen to organise brainstorming call about grid
11:08:49 <trackbot> Created ACTION-521 - Organise brainstorming call about grid [on Rossen Atanassov - due 2012-11-06].
11:09:03 <dbaron> Topic: Alternate style sheets
11:09:19 <dbaron> Peter: This came out of discussion about alternate style sheets, people asking what ever happened to them.
11:09:29 <dbaron> Peter: I accept there are reasons they haven't caught on.
11:09:36 <dbaron> Peter: I wanted to ask if there was something we could do to fix this.
11:09:44 <dbaron> fantasai: I think Alternate SS mechanism in HTML is sufficiently powerful.
11:09:50 <dbaron> fantasai: Problem is implementations aren't.
11:10:05 <dbaron> fantasai: Mozilla has UI to switch, but doesn't remember.
11:10:09 <dbaron> dbaron: I think it does remember now.
11:10:29 <dbaron> Peter: If I go to homepage of site and switch site, it should persist.
11:10:43 <dbaron> Glenn: Intersects with OM, Anne spec'd some functionality.
11:10:58 <dbaron> dbaron: I thought that spec was sort of stable.
11:11:06 <fantasai> fantasai^: That was all worked out as an implementation plan for Mozilla, but never happened
11:11:15 <dbaron> Tantek: I think this is just one instance with the problem with prescriptive UI in specs.
11:11:20 <dbaron> Tantek: I think such things are doomed to fail.
11:11:26 <dbaron> Tantek: I think they're the form of a wishlist.
11:11:36 <dbaron> Håkon: But the spec didn't say what to do.
11:11:50 <dbaron> Tantek: The specs put in prescriptive UI, and that UI failed.
11:12:02 <dbaron> Tab: I find it unlikely we'll want to do anywhere near the same UI other browsers.
11:12:13 <dbaron> Tantek: I think prescriptive UI is going to fail.
11:12:20 <dbaron> Peter: I don't think the problem is that the UI is underspecified.
11:12:31 <dbaron> Peter: I'm questioning if there isn't something missing in the fundamental model to make this work.
11:12:32 <dbaron> q+
11:12:40 <dbaron> Peter: We don't know where to preserve the choices for a given site.
11:12:51 <dbaron> fantasai: There are detailed proposals for that in the Mozilla bugs.
11:12:59 <dbaron> Tantek: I think that's an area where implementations need to innovate.
11:13:22 <dbaron> Tantek: We have the same problem with text zooming.
11:13:32 <dbaron> fantasai: I don't there's anything this working group needs to work on for that.
11:13:41 <dbaron> fantasai: But there's one thing on this topic I'd like to get a resolution on.
11:14:07 <dbaron> fantasai: There's a proposal for syntax for alternate style sheets proposed in the cascade module for @import rules.  I'd like to drop that, at least until it's requested.
11:14:14 <dbaron> ?: or at least at risk
11:14:29 <dbaron> fantasai: If we want Cascade module to be up-to-date, we shouldn't take on functionality that nobody wants to work on.
11:14:38 <stearns> s/?/Peter/
11:15:55 <dbaron> RESOLVED: Drop alternate style sheet syntax from @import in css3-cascade.
11:16:21 <dbaron> break-duration: calc(60 * 60s)
11:17:06 <Shinji> Shinji has joined #css
11:20:32 <jet> jet has joined #CSS
11:22:47 <rubylin> rubylin has joined #css
11:33:35 <plh> plh has joined #css
11:46:47 <arronei> arronei has joined #css
11:47:22 <arroneiTPAC> arroneiTPAC has joined #css
11:47:34 <leehomlin> leehomlin has joined #css
12:04:22 <stearns> stearns has joined #css
12:05:13 <tantek> tantek has joined #css
12:08:05 <SimonSapin> SimonSapin has joined #css
12:11:41 <evanlee> evanlee has joined #css
12:12:55 <mollydotcom> mollydotcom has joined #css
12:16:11 <tomoyuki> tomoyuki has joined #css
12:17:11 <kensaku> kensaku has joined #css
12:17:52 <tokamoto> tokamoto has joined #css
12:24:26 <florianr> florianr has joined #css
12:29:26 <florian> florian has joined #css
12:34:18 <glazou> glazou has joined #css
12:34:25 <arronei> arronei has joined #css
12:38:18 <antonp> antonp has joined #css
12:38:39 <Rossen> Rossen has joined #css
12:41:57 <dino_> dino_ has joined #css
12:42:39 <dbaron> dbaron has joined #css
12:43:08 <cabanier> cabanier has joined #css
12:43:14 <cabanier1> cabanier1 has joined #css
12:44:29 <Norbert> Norbert has joined #css
12:46:51 <dbaron> Topic: Editorship of Cascade module
12:47:14 <dbaron> Tab: Elika and I would like to take editorship of cascade from Håkon
12:47:25 <dbaron> Håkon: What needs to be done?
12:47:36 <dbaron> Elika: 1) remove alternate style sheets syntax
12:47:40 <lstorset> lstorset has joined #css
12:47:45 <dbaron> Elika: 2) synchronize text with CSS 2.1 and make sure corrections all copied over
12:47:54 <dbaron> Elika: 3) editorial reorganization of spec to make sure it still makes sense
12:48:10 <dbaron> Elika: 4) Add cascading rules for scoped styles, the 'all' shorthand, and the 'default' keyword
12:48:17 <dbaron> Håkon: Are we doing scoped style?
12:48:19 <dbaron> Tab: Yes!
12:48:49 <dbaron> Elika: The proposal for scoped styles, as I mentioned in the meeting yesterday.  Boris Zbarsky has a proposal for the cascading part that we want to edit into the spec.
12:49:02 <dbaron> Håkon: I'm happy for you to edit; I still think we need to discuss that feature.
12:49:06 <krit> krit has joined #css
12:49:16 <mgylling> mgylling has joined #css
12:49:19 <dbaron> Tab: I'd like to start doing those edits and then bringing it to discuss in the group.
12:49:23 <dbaron> Bert: What is the 'all' shorthand?
12:49:26 <mgylling_> mgylling_ has joined #css
12:49:44 <dbaron> Tab: We'd like to make 'all' a real property that's a shorthand for all properties, that only accepts initial | inherit | default (once we add default).
12:49:51 <dbaron> Tab: Reason for this is that authors sometimes want to shut off inheritance.
12:50:02 <dbaron> Tab: Authors don't want outer page's styles to leak into a widget.
12:50:10 <dbaron> Tab: Right now authors code very defensively.
12:50:14 <dbaron> Tab: The all property makes it very easy.
12:50:24 <dbaron> Bert: Shouldn't they mark it as a scope in the HTML?
12:50:32 <dbaron> Tab: Yes, in many cases, you want to do this properly.
12:50:44 <dbaron> Tab: But the shadow dom would like to have a non-magical mechanism to reset inheritance.
12:50:44 <dbaron> q+
12:50:57 <dbaron> Tab: When you don't need the full weight of shadow DOM, it can still be useful to reset inheritance entirely.
12:51:02 <dbaron> Bert: Seems a bit frivolous.
12:51:11 <dbaron> Tab: It's a minor improvement that reduces a bit of magic in a few parts of the platforms.
12:51:27 <dbaron> Aaron: And it solves a problem that it's a pain to ...
12:51:35 <dbaron> ack dbaron
12:52:03 <fantasai> dbaron: What about things that are in the UA style sheet where the UA has an inherited property on the root, on the assumption that we want that to be the default but let authors override it
12:53:01 <fantasai> TabAtkins: Discussed with bzbarsky of having 'default' roll back one level of the cascade, resetting all author styles
12:53:21 <fantasai> dbaron: That assumes user prefs are expressed e.g. by changing the definition of 'medium' rather than ways that put a style rule in place on the root element
12:53:50 <fantasai> dbaron: font-size is ok, but other properties might not be
12:53:53 <shepazu> shepazu has joined #css
12:53:57 <glazou> glazou has left #css
12:54:08 <fantasai> dbaron: suppose we didn't have a 'medium' font size keyword, handled default by setting 'font-size: 20px' on the root
12:54:49 <nsakai> nsakai has joined #css
12:54:59 <dbaron> dbaron: so default does something magic with inheriting rules on ancestors that are ua and user rules?
12:55:08 <fantasai> TabAtkins: [...]
12:55:57 <fantasai> [basically, this is an issue that needs to be considered]
12:56:04 <florianr> florianr has joined #css
12:56:11 <fantasai> RESOLVED: Tab and fantasai to take over css3-cascade
12:57:07 <Yune> Yune has joined #css
12:57:36 <fantasai> Topic: HTML5 Challenges (presented by Bert)
12:57:44 <florianr> florianr has joined #css
12:57:56 <fantasai> ScribeNick: fantasai
12:58:05 <fantasai> Bert: Overall question is how much magic
12:58:15 <fantasai> Bert: we have some, for example: a link is a link, and we don't define that
12:58:23 <fantasai> Bert: CSS doesn't say when an element matches :link or :visited
12:58:27 <fantasai> Bert: So some magic we want to keep
12:58:33 <fantasai> Bert: But overall, think we should minimize magic
12:58:33 <florianr> florianr has joined #css
12:58:52 <fantasai> Bert: to be able to use as many features as possible in more environments
12:59:26 <fantasai> Bert: Here's a question -- do we need to say in CSS that you switch from CSS to SVG model? To math model?
12:59:33 <fantasai> Bert: How does this interact with the box model
12:59:39 <fantasai> Bert: Do we define what it means
12:59:45 <fantasai> Bert: SVG and Math might have different answers
12:59:54 <fantasai> Bert: Do we want some way in CSS saying that you switch rendering models?
13:00:03 <fantasai> Bert: And in the case of math, do we want to define exactly how that works?
13:00:07 <lmclister> lmclister has joined #css
13:00:16 <fantasai> TabAtkins: I would like to see 'display: svg' and 'display: math'
13:00:30 <fantasai> TabAtkins: with SVG switching into a kind of abspos model
13:00:46 <fantasai> TabAtkins: And math for now just being handwavy as math, but work on it more later
13:00:57 <fantasai> TabAtkins: Have had some discussions on integrating SVG and CSS models better, think it's a good idea
13:01:09 <fantasai> Bert: Do we expect to support other types of rendering models?
13:01:26 <fantasai> TabAtkins: I think others should use existing layout model, or if using something completely different, use this extension model
13:01:32 <fantasai> TabAtkins: Dont' want to overly-generalize right now
13:01:47 <fantasai> TabAtkins: If in future have a 3rd language with its own display, give it its own display value
13:02:04 <fantasai> plinss: Sounds reasonable. For consistency, do we go back and do <img> and <iframe> ?
13:02:16 <fantasai> Bert, Tab: no that's replaced content b/c external file
13:02:38 <fantasai> arronei: once you're inside SVG element, CSS doesn't care anymore
13:02:52 <fantasai> TabAtkins: But would be better if integrate better
13:02:52 <r12a> r12a has joined #css
13:03:03 <fantasai> TabAtkins: e.g. not have to use <foreignObject> in SVG to include HTML bits
13:03:21 <fantasai> TabAtkins: But wrt CSS box model, would still behave as they do now
13:03:28 <fantasai> arronei: Do we then need inline-svg and svg?
13:03:34 <fantasai> TabAtkins: No, we need display-inside/display-outside :)
13:03:55 <tokamoto> tokamoto has joined #css
13:04:11 <yamaday> yamaday has joined #css
13:04:18 <fantasai> [side discussion on whether to split display]
13:04:48 <fantasai> Bert: An alternative is not to have a keyword per model, but just have one keyword, 'foreign', and let it be determined by the namespace
13:05:00 <fantasai> hober: Single keyword doesn't tell you anything useful about what's inside
13:05:05 <fantasai> or how to process it
13:05:28 <fantasai> TabAtkins: I would like to go and define an SVG layout model at some point, add it at that point
13:05:38 <SimonSapin> SimonSapin has joined #css
13:05:42 <fantasai> TabAtkins: Maybe go ahead and say we'll define math value now?
13:05:56 <dbaron> dbaron has joined #css
13:06:13 <glazou> glazou has joined #css
13:06:30 <fantasai> fantasai: What if I set 'display: block' on an embedded <svg> element?
13:06:34 <vhardy__> For reference http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
13:06:41 <fantasai> fantasai: Right now that just makes the SVG a block-level replaced element
13:06:47 <fantasai> fantasai: just like external SVG
13:06:59 <fantasai> fantasai: but if we go with your proposal, this will cause the SVG to break
13:07:13 <TabAtkins_> TabAtkins_ has joined #css
13:07:17 <vhardy__> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
13:07:40 <kotakagi> kotakagi has joined #css
13:08:04 <Daisuke> Daisuke has joined #css
13:08:26 <fantasai> vhardy: Might want to talk more with HTML guys of mixing svg andhtml
13:09:09 <fantasai> Bert: Next issue is math, do we define that layout model. There are useful behaviors there, useful outside of math
13:09:15 <fantasai> Bert: Don't know how to get that done
13:09:24 <fantasai> TabAtkins suggests kidnapping David Carlisle
13:09:50 <fantasai> Bert: Have to work out details, but do people think math boxes in principle is a good idea?
13:09:53 <fantasai> plinss: I think it's reasonable
13:10:14 <fantasai> plinss: I remember we looked at how to render math with existing CSS
13:10:32 <fantasai> Bert: There's a MathML profile for that. Doesn't quite look right, but you can get quite far
13:10:52 <fantasai> ChrisL: If you redid that profile with Flexbox, would that help?
13:11:01 <fantasai> Bert: Maybe. Have to see what baselines are use
13:11:03 <fantasai> d
13:12:12 <fantasai> TabAtkins: Proposed resolution - Add 'display: svg' and 'display: math' or something similar at some point
13:12:39 <fantasai> TabAtkins: Can solve the stylesheet overriding problem by having display-inside: svg !important to UA stylesheet
13:13:15 <fantasai> ChrisL: display-inside/display-outside sets up a proper handoff mechanism
13:14:27 <TabAtkins_> RESOLVED: Add 'display: svg' and 'display: math' or something similar at some point
13:14:52 <fantasai> Bert: So, <details> element has an open attribute
13:14:58 <fantasai> Bert: So you can style differently the two different states
13:15:03 <fantasai> Bert: This is an example of a wider problem
13:15:15 <fantasai> Bert: Wider problem is, we should have a way to give every element two states
13:15:17 <TabAtkins_> I agree: http://www.xanthir.com/b4Kn0
13:15:27 <fantasai> Bert: Even a <section> or <div> should be able to be open/close
13:15:40 <fantasai> TabAtkins: I agree, and tried to write something up on this
13:15:47 <fantasai> fantasai: But you ran into a problem
13:15:54 <fantasai> TabAtkins: Yeah, ran into a fundamental problem.
13:15:58 <fantasai> TabAtkins: Circular dependencies
13:16:10 <fantasai> Bert: Did you look at the pseudo-class solution instead?
13:16:25 <fantasai> TabAtkins: This keys directly into :checked pseudo-class, except generalizes so you can have more than 2 states
13:16:51 <fantasai> TabAtkins: Also does what HTML label element does, transferring checkedness between elements. E.g. clicking on <summary> affects <details>
13:17:00 <fantasai> TabAtkins: But fundamental problem with this, whatever property turns on ability to be checked
13:17:10 <fantasai> TabAtkins: If whie it's there, you turn off that property, then it's a problem
13:17:25 <fantasai> Bert: Do you actually need the property? Couldn't it just be implicit?
13:17:33 <Norbert> Norbert has joined #css
13:17:54 <fantasai> TabAtkins: Could imply checked / unchecked states for all elements, just use pseudo-classes
13:18:07 <fantasai> TabAtkins: But doesn't let you do radio buttons
13:18:17 <fantasai> TabAtkins: which I've found to be super useful
13:18:39 <ChrisL> ChrisL has joined #css
13:18:56 <fantasai> TabAtkins: My suggestion is to go with this, but restrict the toggleable property to not be set in pseudo-classes that read the toggled state
13:19:29 <liam> liam has joined #css
13:19:33 <fantasai> Bert: You say you can have more than 2 states. I investigated that too, but it seemed too complicated for authors
13:19:42 <fantasai> TabAtkins: Not sure it's necessary, though can come up with cases where it would be useful
13:20:10 <fantasai> TabAtkins: But most cases I came up with were two states, but able to make second state sticky so that clicking it doesn't toggle the stae away from the second state
13:20:16 <fantasai> divya: Maybe solve this through shadow dom?
13:20:42 <fantasai> TabAtkins: You'd be using shadow dom to put radio buttons into the shadow dom
13:21:20 <fantasai> TabAtkins: I think shadow dom brings in additional complexity that a tailored CSS solution wouldn't
13:21:20 <ChrisL> if the labels are in the shadow dom then accessibility helpers have more trouble discovering them
13:21:43 <fantasai> TabAtkins: It still doesn't give you the label functionality, necessary even for simple case of <details>
13:21:49 <fantasai> Bert: So Tab thinks it's a good idea, anyone else?
13:22:18 <fantasai> fantasai: I think it's good problem to solve
13:22:43 <fantasai> divya asks for a prototype
13:23:17 <fantasai> TabAtkins asks for objections
13:23:28 <fantasai> hober: Object to what? Thinking about the problem?
13:23:37 <fantasai> Bert: Question is, do we put this in some working draft
13:23:48 <fantasai> sylvaing: Adding another module?
13:23:58 <fantasai> hober: I'm pretty sure this falls into the bottom half of our prioritization list
13:24:03 <Cyril> Cyril has joined #css
13:24:30 <fantasai> Bert: So, a new working draft, it would be ok at some point
13:24:36 <fantasai> arronei: I don't think we need more than 2 states initially
13:24:45 <fantasai> TabAtkins: Does anyone think this is a bad idea, should not pursue?
13:25:21 <fantasai> hober: In generic case of multiple states, adding the complexity of essentially of a state machine to all elements of all languages, so maybe we should have reason to do this?
13:25:25 <fantasai> TabAtkins: I do this so often
13:25:32 <fantasai> arronei: It's such a common pattern on the Web, it's done everywhere
13:26:07 <fantasai> fantasai: I think this is a very common use case, to have collapsible elements etc.
13:26:23 <fantasai> fantasai: Think it's good to have a declarative solution
13:26:30 <fantasai> fantasai^: Done with JS etc. all the time
13:26:38 <fantasai> fantasai: whether purely CSS or integrating somehow with DOM
13:27:06 <divya> https://github.com/louisremi/Activable
13:27:19 <lstorset> lstorset has joined #css
13:27:19 <divya> is one solution to do a declarative markup way to do UI components
13:27:20 <fantasai> fantasai: Might be useful for DOM to be able to reflect the states, or screen reader to react to the states
13:27:26 <ChrisL> http://www.w3.org/TR/scxml/
13:27:32 <divya> (which includes interactions such as what tab discussed)
13:27:34 <ChrisL> State Chart XML (SCXML): State Machine Notation for Control Abstraction
13:27:34 <ChrisL> W3C Working Draft 16 February 2012
13:27:37 <fantasai> plinss: Bottom line is, no objections to further investigation
13:28:15 <fantasai> Bert: <details> has another issue -- when I tried to model it, problem was that there's a part you want to show, and part you want to hide
13:28:24 <fantasai> Bert: want to hide most of it, except the summary
13:29:11 <TabAtkins_> Easy: details:not([open]) > :not(summary) { display: none; }
13:29:39 <fantasai> Bert: Hmm, let me go back and see if that solves it.
13:29:52 <TabAtkins_> Easy: details:not([open]) > :not(summary:first-of-type) { display: none; }
13:30:19 <fantasai> leaverou: It doesn't work for direct text content of the <details>
13:31:28 <fantasai> RESOLVED: Toggleable states is a cool idea and work on it at some undetermined but not high priority
13:32:04 <fantasai> Bert: Lst item is a replaced item whose height depends on width, but not as an aspect ratio
13:32:17 <fantasai> Bert: e.g. <iframe seamless>
13:32:47 <fantasai> TabAtkins: I don't think there's anythign to do here
13:33:03 <fantasai> Bert: Need to update object negotiation rules for it
13:33:22 <Daisuke> Daisuke has joined #css
13:33:27 <fantasai> TabAtkins: [..]
13:33:35 <fantasai> fantasai: I agree with Tab that I don't think we need to add any features to CSS for this
13:34:10 <fantasai> fantasai: But I also agree with Bert that the object negotiation algorithm to handle this
13:34:26 <fantasai> s/that the/that we need to update the/
13:35:00 <fantasai> ACTION TabAtkins and fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless>
13:35:00 <trackbot> Sorry, couldn't find TabAtkins. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
13:35:05 <krit> krit has joined #css
13:35:18 <ChrisL> trackbot, status
13:35:27 <fantasai> Bert: So the style sheet author doens't need to set anything?
13:35:38 <fantasai> fantasai: No, the object itself returns different information in this case
13:36:19 <trackbot> trackbot has joined #css
13:36:20 <shige> shige has joined #css
13:36:52 <fantasai> fantasai explains why this is the case
13:36:56 <fantasai> Bert: Ok, I guess it's good enough
13:38:13 <fantasai> [you always try to get the best intrisic size that you can get, and in the case of non-seamless iframes this is nothing, whereas seamless iframes can return a sizing functio]
13:38:14 <TabAtkins_> ACTION Tab and fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless>
13:38:14 <trackbot> Created ACTION-522 - And fantasai to update object negotiation algorithm in css4-images to handle <iframe seamless> [on Tab Atkins Jr. - due 2012-11-06].
13:39:21 <fantasai> Topic: Conditional Rules
13:39:27 <fantasai> TabAtkins: Only one remaining issue oncss3-conditional
13:39:41 <fantasai> TabAtkins: Decided to loosen parsing things, treating unknown constructs as false
13:39:46 <fantasai> TabAtkins: rather than making rule invalid
13:39:52 <fantasai> TabAtkins: The only real change is...
13:40:02 <fantasai> TabAtkins: This bit, supports_condition, now uses 'any' token from grammar
13:40:10 <fantasai> TabAtkins: As long as you match pretty much anything at all in there
13:40:53 <fantasai> TabAtkins: If you don't see one of the grammar constructs listed, it drops out as false
13:40:57 <fantasai> TabAtkins: Should be all we need.
13:41:04 <fantasai> TabAtkins: As far as I can tell, it's right
13:41:14 <fantasai> TabAtkins: It's just details to tweak to make it clearer
13:41:30 <fantasai> TabAtkins: So, because of this change, we should now  have all issues resolved, and should be able to resolve to go to LC
13:41:43 <fantasai> TabAtkins: Anyone object to publish LC?
13:42:09 <fantasai> fantasai: I'd like dbaron to have a chance to review this, but otherwise looks good
13:42:41 <fantasai> RESOLVED: Publish css3-conditional on Tuesday unless dbaron objects within next few days
13:43:02 <fantasai> Bert: You're limiting what you can do in the future, but why make things false when you don't understand them?
13:43:10 <fantasai> TabAtkins: This is to make ti easier to extend in the future
13:43:22 <fantasai> TabAtkins: We don't want the presence of new things to wipe out the entire @supports rule in older UAs
13:44:02 <fantasai> TabAtkins explains why this makes sense
13:44:28 <fantasai> plinss: but sometimes will get wrong answer
13:44:41 <fantasai> TabAtkins: Will sometimes fail, but gives better forward-compat overall
13:45:04 <fantasai> plinss: Any other items on agenda?
13:45:19 <fantasai> TabAtkins: display model?
13:45:24 <fantasai> fantasai: or paged-media
13:45:49 <fantasai> [discussion of what's left to discuss]
13:49:02 <massimo> massimo has joined #css
13:49:47 <fantasai> Topic: display models
13:50:16 <leaverou> http://dev.w3.org/csswg/css-display-3/
13:50:52 <fantasai> Tab reviews the draft with the WG
13:50:59 <fantasai> currently showing off display-inside/display-outside
13:51:49 <knobuta2> knobuta2 has joined #css
13:52:42 <trackbot> trackbot has joined #css
13:53:24 <fantasai> showing off display-box (noneness switch)
13:53:44 <fantasai> stearns: Do you expect authors to use independnt properties, or just shorthand
13:54:01 <fantasai> TabAtkins: mostly shorthand, but in some cases would want separation
13:54:07 <fantasai> TabAtkins: e.g. the SVG case discussed earlier
13:54:23 <fantasai> stearns: imo the first two properties are too much noise for benefit, but third property -- certainly something we should do
13:54:34 <fantasai> TabAtkins: The first two are mostly a matter of simplifying the spec's model of things
13:54:41 <fantasai> TabAtkins: Our complexity ends up leaking into the [...[
13:54:53 <fantasai> TabAtkins: e.g. keep having to add inline- versions of everything
13:55:02 <fantasai> TabAtkins: But also adds some additional functionality
13:55:09 <fantasai> TabAtkins: e.g. table-caption with flex layout inside
13:55:30 <fantasai> TabAtkins: or table cells, which can only be blocks right now
13:56:40 <fantasai> howcome: sympathsize with Tab's attempt to make this coherent, but also Alan's concern about whether we need to expose this to authors
13:57:08 <fantasai> fantasai: If splitting out display-none part, then the other part needs to go into some property
13:57:38 <fantasai> Bert: Why is splitting out display-none useful?
13:57:59 <fantasai> TabAtkins: So you don't clobber the previously-set display value -- need an on/off switch
13:59:28 <fantasai> fantasai: Going back, if we're going to split out 'display' type, and at any point going to split it further into -outside/-inside, should make that split now
13:59:40 <fantasai> fantasai: otherwise will need two levels of shorthanding if we ever split it into -outside/-inside
14:00:28 <fantasai> [Tab explains why splitting out is beneficial for layout models]
14:00:41 <fantasai> antonp: Good example is flex items
14:01:03 <fantasai> antonp: Didn't want to have anonymous box tree generation in order to have flex-item display type
14:02:46 <fantasai> plinss: What if I say table-header-group, and inside is block?
14:02:59 <fantasai> TabAtkins: Think there needs to be an edit that such things compute -inside to auto
14:03:23 <fantasai> antonp: I think key thing here is not this conceptual level, but what Bert was trying to tell me the other night
14:03:32 <fantasai> antonp: what does it really mean, for something to be an inline-block
14:03:42 <fantasai> antonp: If inline-level, participates in an inlin formatting context
14:03:51 <fantasai> antonp: but not the same as a string of text; can't split across lines
14:04:01 <fantasai> antonp: What's causing
14:04:28 <fantasai> antonp: that special behavior?
14:04:39 <fantasai> TabAtkins: The combination of inline-level and auto does special behavior
14:05:34 <fantasai> howcome: if we just have the display, then we name things that make sense and don't give names that don't make sense
14:05:49 <fantasai> TabAtkins: things that don't make sense to combine, you force inside to auto
14:05:56 <fantasai> howcome: it's a lot
14:05:58 <fantasai> TabAtkins: It's not a lot
14:06:24 <fantasai> TabAtkins: ...
14:06:32 <stearns> http://hyperboleandahalf.blogspot.fr/2010/04/alot-is-better-than-you-at-everything.html
14:06:42 <fantasai> howcome: Cascading things separately could be a problem
14:06:50 <fantasai> TabAtkins: Forcing is at computed value time
14:07:05 <fantasai> TabAtkins: There's 3 display-outside values: inline, block, and tabley things
14:07:37 <fantasai> ...
14:07:53 <fantasai> plinss: There are cases where you might want to toggle just the outside, e.g. just switch inline to block or vice versa, without affecting insides
14:08:03 <fantasai> Bert: I had 2 reasons for dropping it
14:08:16 <fantasai> Bert: Found out all combinations, that I was defining more, not less, with the split
14:09:16 <fantasai> Bert: Other thing was, even found myself only using the 'display' property
14:09:44 <fantasai> Bert: regardless of naming, kept thinking in terms of display types as a whole
14:10:40 <fantasai> Bert: Other issue wrt display...
14:10:58 <fantasai> Bert: For flex, let it be a display type, mainly didn' tthink anyone would use inline-flex
14:11:16 <fantasai> Bert: But grid, not convinced
14:11:26 <fantasai> Bert: Grid element should just have a grid property
14:11:48 <fantasai> Bert: it's a block, just like any other block
14:12:03 <fantasai> hober: it's a block on the outside, it's a grid on the inside...
14:12:19 <fantasai> plinss: when I went through grid proposal, felt the same way -- everything should be able to have a grid
14:12:33 <cabanier> cabanier has joined #css
14:12:38 <fantasai> plinss: The difference here is, that MSFT model has ability for contents to push around the lines and size arond the contents
14:12:43 <fantasai> plinss: Can't do that
14:12:46 <fantasai> otherwise
14:12:53 <tomoyuki> tomoyuki has joined #css
14:12:56 <fantasai> plinss: while I think grids should be able to go anywhere
14:13:12 <fantasai> plinss: think there also needs to be a way to have a grid that auto-size around things
14:13:15 <fantasai> plinss: they're different
14:13:31 <fantasai> antonp: Another problem.. multi-col properties apply to block containers
14:13:45 <fantasai> antonp: but once you turn it into multi-col by applying those properties, it's no longer a block container
14:13:50 <fantasai> antonp: weird editorial cycle
14:14:21 <fantasai> ...
14:14:33 <fantasai> ChrisL: In SVG, ppl pick a random value when they're switching display on/off.
14:14:47 <fantasai> ChrisL: It doesn't matter whether choose inline or block, for the SVG, nless you inheriting down into something else
14:14:51 <fantasai> ...
14:15:20 <fantasai> TabAtkins: when we were talking about flexbox, you wanted ability to say an item is a flex-item, so that can wrap around  it
14:15:32 <fantasai> TabAtkins: What model is used inside the flex item?
14:15:42 <fantasai> TabAtkins: table? flex? block?
14:15:58 <fantasai> TabAtkins explains cases where you want to mix models
14:16:12 <fantasai> TabAtkins: Only reason display works ok right now is b/c outside values are just block and inline
14:16:29 <fantasai> TabAtkins: Once we add another outside value, then the combinations will explode
14:16:49 <fantasai> TabAtkins: Right now it's sane only because we have only two columns
14:17:55 <fantasai> TabAtkins gives an example of <h1>, <table>, <p> put into a flexbox
14:19:42 <fantasai> <br>
14:19:51 <fantasai> return at 5pm
14:19:52 <fantasai> er
14:19:52 <fantasai> 4pm
14:20:13 <JohnJansen> JohnJansen has joined #css
14:29:55 <Norbert> Norbert has joined #css
14:35:30 <cabanier> cabanier has joined #css
14:43:11 <Rossen> Rossen has joined #css
14:45:33 <mihara> mihara has joined #css
14:48:56 <Shinji> Shinji has joined #css
14:50:21 <krit> krit has joined #css
14:51:26 <glazou> glazou has joined #css
14:51:35 <mgylling> mgylling has joined #css
14:51:45 <mgylling_> mgylling_ has joined #css
14:52:39 <yune> yune has joined #css
14:52:53 <yamaday> yamaday has joined #css
14:53:35 <dbaron> dbaron has joined #css
14:56:44 <nsakai> nsakai has joined #css
14:57:57 <lmclister> lmclister has joined #css
14:59:51 <lstorset> lstorset has joined #css
15:01:30 <shepazu> shepazu has joined #css
15:03:52 <rubylin> rubylin has joined #css
15:03:59 <r12a> r12a has joined #css
15:05:03 <SteveZ> SteveZ has joined #css
15:06:48 <kotakagi> kotakagi has joined #css
15:06:58 <lstorset> lstorset has joined #css
15:09:56 <tantek> tantek has joined #css
15:13:50 <Shinji> Shinji has joined #css
15:16:12 <sylvaing> scribenick:sylvaing
15:17:16 <Yune> Yune has joined #css
15:17:38 <sylvaing> howcome: I think the list of odd cases is not long enough to justify the split
15:18:08 <sylvaing> tantek: I think the list is long
15:18:28 <sylvaing> tabatkins: today we have inline versions of a number of displays
15:18:45 <sylvaing> tabatkins: we may want a flex-item display value in the future
15:19:18 <sylvaing> tabatkins: but then we'd add 4 versions of flex item
15:19:35 <sylvaing> tabatkins: every new display outside type multiplies the combinations
15:19:52 <sylvaing> howcome: but not all these combinations make sense
15:20:14 <rotsuya> rotsuya has joined #css
15:20:16 <sylvaing> tabatkins: all these combinations exist today
15:20:36 <sylvaing> tabatkins: and it will keep growing as we add new layout modes
15:21:06 <sylvaing> tantek: does it make sense for these properties to cascade these properties separately?
15:21:08 <shepazu> shepazu has joined #css
15:21:17 <sylvaing> plinss: yes
15:21:56 <kensaku> kensaku has joined #css
15:22:14 <sylvaing> tabatkins: also we have some display-outside values that only take blocks inside right now but we could argue that they should support more e.g. table-caption
15:22:41 <sylvaing> howcome: but you still have to describe the combinations that don't work
15:22:46 <sylvaing> tabatkins: there are not that many
15:22:56 <sylvaing> antonp: ruby?
15:23:03 <sylvaing> tabatkins: that works similarly to table
15:23:05 <sylvaing> antonp: yes
15:23:22 <mgylling> mgylling has joined #css
15:23:29 <mgylling> mgylling has left #css
15:23:51 <sylvaing> howcome: what's the issue with ruby?
15:24:09 <sylvaing> tabatkins: this is not in yet. everything except table-cell and table-caption force the inside to auto
15:24:31 <sylvaing> tabatkins: they only make sense in the context of tables; they're not fully independent i.e. they're not just display-outsides
15:25:13 <sylvaing> tabatkins: any new display mode we add would work the same; they would combine with everything
15:26:08 <sylvaing> antonp describes his proposal re: ruby
15:26:25 <koji> koji has joined #css
15:26:25 <antonp> http://lists.w3.org/Archives/Public/www-style/2012Oct/0554.html
15:26:29 <sylvaing> tabatkins: we'd have display-outside: ruby-* then inside would be auto
15:26:52 <sylvaing> howcome: so will we say new outside values force auto?
15:26:59 <sylvaing> tabatkins: we would do it as needed
15:27:56 <sylvaing> antonp: you could argue all the display values for table were overkill; were 7-8 values for table necessary? would we do this again?
15:28:48 <sakkuru> sakkuru has joined #css
15:28:52 <sylvaing> bert: we also have run-in, this should be inline inside
15:28:54 <sylvaing> tabatkins: yes
15:29:15 <sylvaing> antonp: we're not trying to get rid of awkward cases; we're trying to enable independent toggling for many of the cases that make sense
15:29:36 <sylvaing> antonp: the purpose of this is not to remove the inherent complexity we already have
15:29:48 <sylvaing> antonp: just adding power to express things in a more flexible and powerful way
15:30:00 <sylvaing> bert: why add complexity ?
15:30:16 <sylvaing> tabatkins: because we are currently avoiding situations that are painful in the current model
15:30:40 <sylvaing> tabatkins: e.g. any new feature that requires adding a ton of display keywords is a turn-off
15:31:04 <sylvaing> ChrisL: an inside and outside is not that complex, is it?
15:31:24 <sylvaing> plinss: the common use-case is that someone is going to use the shorthand then override one aspect of it somewhere else.
15:31:29 <leehomlin> leehomlin has joined #css
15:31:43 <sylvaing> plinss: so the common use-case is not authors specifying both inside and outside everywhere
15:32:17 <sylvaing> tabatkins: we make it easier to add new values but at a lower cost
15:33:11 <sylvaing> tantek: I have run into cases where I wanted to only change the outside because someone already defined the inside
15:33:44 <sylvaing> tantek: I wanted to lay it out along other things e.g. using MQ turn some inline thing into block level for responsive design
15:34:40 <sylvaing> tantek: I just want to style the outside, not the inside
15:35:02 <sylvaing> tantek: this is a use-case
15:35:41 <sylvaing> antonp, bert: it's not just a matter of flipping the switch; you may also want to adjust widths and other measures and that will interact with the inside
15:36:04 <sylvaing> antonp: but there may be a way to do this negotiation using some of the new keywords in the sizing spec
15:36:16 <sylvaing> antonp: so I'm not sure outside/inside are fully independent
15:36:45 <sylvaing> tantek: for many inline blocks it would work with minimal work.
15:37:20 <sylvaing> antonp: tables, on the other hand, would be more complicated.
15:37:32 <massimo> massimo has joined #css
15:37:40 <sylvaing> tantek: yes, and we'll have more questions once people use this with real content. but in terms of utility and use-cases I think we have it.
15:39:25 <sylvaing> tantek: the hack I'm using right now is float; it's my display-outside:block. it's workable but not elegant or intuitive.
15:39:32 <sylvaing> Bert: but that doesn't give you the right alignment
15:39:35 <sylvaing> tantek: exactly!
15:40:13 <sylvaing> Bert: I still think you may need to adjust margins, padding etc.
15:40:18 <sylvaing> antonp: yes, but we can handle that
15:40:42 <sylvaing> plinss: and the author can change that but that's better than having to handle all the side-effects of switching to floats
15:40:56 <sylvaing> plinss: or you may have to change the markup, which is worse
15:41:11 <sylvaing> tantek: i'd like to get this to a stage where we can get some implementation experience and iterate from there
15:41:19 <sylvaing> tantek: and yes, there will be things we do not expect
15:41:25 <sylvaing> tantek: but we should try to get there
15:41:43 <sylvaing> plinss: we'll also find new things that are really cool and would not be able to do in any other way
15:41:59 <sylvaing> howcome: I agree but I fear that some of the complexities that will appear will be implementation-specific hacks
15:42:09 <sylvaing> howcome: achieving interop will take time
15:42:54 <sylvaing> howcome: but I can see tantek's use-case
15:43:08 <sylvaing> plinss: do we proceed with this or not?
15:43:18 <sylvaing> Bert: I think we have more important things to do...
15:43:35 <sylvaing> plinss: we're not deciding priorities
15:43:50 <tantek> here's an actual use-case where I had to hack floats to get the display effects I wanted where I think it would have been easier with display-outside and display-inside
15:43:53 <sylvaing> tabatkins: is it OK to make it an ED?
15:44:04 <tantek> http://tantek.com/xoxo-2012-directory
15:44:28 <sylvaing> fantasai: display:none discards the element from the rendering tree; some of the values you have - contents - don't quite do that
15:44:42 <sylvaing> tabatkins: no it's not there, only its children
15:44:49 <sylvaing> fantasai: I'm not sure that is what authors actually want
15:46:19 <sylvaing> fantasai: is it the right place to have this control? maybe we need to rethink display-none; one meaning discard from the rendering tree, the other means that it's not in the rendering tree but it is preserved for things like counters
15:46:38 <sylvaing> fantasai: so you could hide a list item without renumbering your list
15:46:49 <sylvaing> tabatkins: I have issues in the spec for this
15:47:01 <sylvaing> plinss: objections to ED?
15:47:26 <sylvaing> RESOLVED: start css-display-3 as a new ED
15:48:20 <fantasai> ScribeNick: fantasai
15:48:45 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15242
15:48:45 <fantasai> sylvaing: I believe it was the last F2F or theone before, we discussed the way animations affect the cascade
15:48:56 <fantasai> sylvaing: an interesting issue came out of this bug is the interaction of animations with concurrent positions
15:49:14 <fantasai> sylvaing: animations trigger during a transition
15:49:26 <fantasai> sylvaing: do we treat the transition as if it runs in the background? pause it?
15:49:29 <fantasai> sylvaing: not defined at all
15:49:35 <fantasai> sylvaing: Not sure there's interop anyway
15:49:56 <jeff> jeff has joined #css
15:50:20 <fantasai> sylvaing: essentially, you hover over an element, it transitions, halfway through an animation starts -- what happens?
15:50:31 <fantasai> dbaron, ping
15:50:40 <dbaron> fantasai, pong
15:50:50 <fantasai> dbaron, see sylvain's issue?
15:51:24 <fantasai> dean: we've implemented that the transition is still running in the background
15:51:46 <fantasai> dean: if the transition is still running, it picks up from where it would have been in the transition
15:52:07 <fantasai> plinss: does the animation pick up from where the transition was?
15:52:51 <fantasai> fantasai: This all seems kindof wrong to me. I don't understand why transitions don't win.
15:53:12 <fantasai> plinss: Either way, still have same problem of one taking over from other one
15:53:50 <fantasai> fantasai: [...]
15:54:02 <fantasai> dean: Transitions aren't more important than animations b/c they operate on property changes
15:54:28 <fantasai> dean: would be kindof weird for animation that's running, then a transition triggers.. does a thing, and then jumps back to the animation frame
15:55:02 <fantasai> dean: My proposal is to follow what Webkit's done, which is transition is still running, events still fire
15:55:18 <fantasai> dean: and I'm not sure what the spec says, wrt what to do with 0 or 100% keyframes, if they're missing
15:55:53 <fantasai> plinss: if they're missing, would make sense to pick up from where the transition was, and if the 100% is missing pick up where the animation's at
15:57:19 <fantasai> plinss: If the transition's running, and during the transition an animation fires, runs to completion, and leaves the property in a different state than what the transition would have done, had it not been interrupted, and the transition still has time left, where does the property go?
15:57:29 <fantasai> plinss: does it go to where the property would have been if there was no animation?
15:57:42 <fantasai> dean: ...
15:57:55 <fantasai> dean: you should act as if animations could exist in a world where there are no transitions
15:58:11 <fantasai> dean: in that case, we would always override and never pause that zero-length instantaneous transition effect
15:58:22 <fantasai> dean: I'm not sure if we actually have any issues here, if people agree
15:58:32 <fantasai> dean: I think maybe the spec has enoughwording, provided we add this description of what happens
15:58:45 <fantasai> dean: for zero and 100% case
15:59:11 <fantasai> dean: interesting question of whether missing from keyword should result in starting from transition point, or from transition start point
15:59:21 <fantasai> dean: seems like it makes sense to start from transition point
15:59:35 <fantasai> plinss: Suppose I'm animating a box's height trhough a transition over 5s
15:59:47 <fantasai> plinss: halfway through an animation runs that wiggles it, and then leaves it where started
15:59:53 <fantasai> plinss: transition continues
16:00:05 <fantasai> plinss: would that jump from start point to where transition would have been?
16:00:13 <fantasai> plinss: or transition resumes from where animation left it?
16:00:27 <Wonsuk> Wonsuk has joined #css
16:00:31 <fantasai> plinss: The whole point of a transition is you don't want things do jump
16:00:40 <fantasai> plinss: do you really want to introduce these jumps
16:00:55 <fantasai> sylvaing: You have no discontinuity at the beginning
16:01:03 <fantasai> ChrisL: would it make a difference if you freeze the animation?
16:01:27 <fantasai> sylvaing: repeats when transition is stil running...
16:01:40 <fantasai> dean: Think the spec should say, calculate 0 or 100% and keep that forver
16:01:57 <fantasai> dean: That saves us having to do 2 computations to figure out the style
16:02:17 <fantasai> plinss: Agree it makes implementation crazy, but wrt author ...
16:02:35 <fantasai> arronei: Maybe put a warning to authors, that if you animate and transiton same property values, it will not be smooth
16:02:49 <fantasai> plinss: If doing the right thing was reasonably simple and cheap, do the right thing
16:03:06 <fantasai> plinss: but better to do something lame consistently on all browsers
16:03:13 <fantasai> plinss: than to have inconsistency across browsers
16:03:26 <fantasai> plinss: want the author to see right away exactly what ways things are messed up
16:03:36 <fantasai> dean: what if you have CSS and SMIL animation on the same thing?
16:03:43 <fantasai> dean: in webkit righ now it pingpongs
16:04:18 <fantasai> tantek: Is there an effort to unify CSS and SMIl animations?
16:04:23 <fantasai> ChrisL: yes, it's caled web Animations
16:04:26 <fantasai> krit: ...
16:04:41 <fantasai> krit: We came up with proposal that the attribute style, in svg, has the lowest priority of both style sheets
16:04:53 <fantasai> krit: Then when we animate CSS property, describes before transition and animation
16:04:58 <fantasai> krit: Therefore overrides SMIL animation
16:05:06 <fantasai> krit: Already implemented in webkit and Gecko this way
16:05:12 <fantasai> krit: can't tell about Opera
16:05:21 <fantasai> ...
16:05:41 <fantasai> dean: I think our resolution is that transitions continue to run and still is overridden by animations wanted
16:05:51 <fantasai> dean: Even if you're overriding the property
16:06:09 <ChrisL> s/.../leif: we have them now in Opera
16:06:10 <fantasai> sylvaing: If 2 completely different sets of properties, happen simultaneously
16:06:22 <fantasai> sylvaing: Talked about ...
16:06:30 <fantasai> sylvaing: We may want to have smooth transition back to ...
16:07:03 <fantasai> fantasai interrupts:
16:07:13 <fantasai> fantasai: San Diego we have a resolution that transitions happen last in the cascade
16:07:16 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0900.html
16:07:32 <lstorset> lstorset has joined #css
16:08:56 <fantasai> [..]
16:08:59 <massimo> massimo has joined #css
16:09:14 <fantasai> plinss: It's not the transition rule that's causing it to transition now, it's because some other rule got applied, which is not overridden by the animation rule
16:10:26 <fantasai> fantasai: This resolution says that if you transition and animate the same property at the same time, you don't see the animation, just the transition
16:11:05 <fantasai> fantasai: The properties that are in transition are last in the cascade
16:11:43 <fantasai> dean: you can't do that
16:11:46 <fantasai> fantasai: I believe Gecko does
16:12:20 <fantasai> sylvaing reads/interprets the minutes
16:12:38 <fantasai> dean: Suppose I'm moving this box over 1s
16:13:12 <fantasai> dean: At the same time I have an animation that moves the top value from here to here
16:13:46 <TabAtkins_> fantasai, dino: [discussion of example]
16:13:57 <shige_> shige_ has joined #css
16:15:14 <cabanier> jsfiddle example: http://jsfiddle.net/FALtu/
16:15:37 <Shinji> Shinji has joined #css
16:17:28 <odinho_> odinho_ has joined #css
16:21:10 <koji> koji has joined #css
16:21:48 <TabAtkins_> dino_: If the user wants to stop a transition, they put !important in their stylesheet.  But that won't stop an animations.
16:22:08 <TabAtkins_> dino_: To stop animation, they put "animation: none !important;" in their user stylesheet to kill it.
16:23:03 <TabAtkins_> fantasai: No, if you have a property that is set to some value in the user!important stylesheet, that property cant' animate.  The user!important rule overrides the animation rule.  Per the resolution that animatinos are below user!important, nota bove.
16:23:48 <TabAtkins_> sylvaing: It doesn't stop animations...
16:24:04 <TabAtkins_> fantasai: yes, the animation still *happens*, but that property doesn't change.
16:24:28 <TabAtkins_> plinss: Now how does that realte to transitions?
16:24:39 <TabAtkins_> plinss: If the user has a !importatn color, how can that possibly transition?
16:24:54 <TabAtkins_> Bert: They have two user!important rules.
16:25:39 <TabAtkins_> plinss: So the transition will still happen.  But that has no effect on an animation from the author.
16:25:53 <TabAtkins_> plinss: What does transitions in the cascade mean?  Transitions aren't cascading.
16:26:18 <TabAtkins_> fantasai: the "virtual declaration" that's in effect (dictating the value of the property at that moment from the transition)...
16:26:27 <TabAtkins_> fantasai: That declaration is the last thing in the cascade.  It wins over everything else.
16:26:39 <florianr> florianr has joined #css
16:27:52 <TabAtkins_> plinss: So now we're flipping the case - transitions override animations, not the other way around?
16:27:55 <TabAtkins_> fantasai: Yes.
16:28:20 <TabAtkins_> plinss: Now the case is - there's an animation running, and something else happens that causes a transition.
16:29:00 <TabAtkins_> plinss: My color is pulsing from an animation, but then I hover, which changes it to black.
16:29:28 <TabAtkins_> plinss: So the answer seems to be that I transition *from the current animated value* (because that's the current computed value) to black.
16:29:55 <cabanier> example of a transition during an animation: http://jsfiddle.net/FALtu/
16:29:57 <TabAtkins_> plinss: Then, if I stop hovering, I think that it should transition over to the current animated value, since the animation has continued to run this whole time.
16:31:43 <TabAtkins_> krit: Transitioning from the current animated value is very hard in SMIL.  It will be similarly hard to implement in CSS Transitions.
16:32:15 <TabAtkins_> [we all update David on the discussion]
16:33:39 <TabAtkins_> dbaron: My pref is that if we want the animation to win when it's running with a transition, we should do that with something other than the cascade.
16:33:45 <TabAtkins_> dbaron: Just say that the transition disappears.
16:34:12 <TabAtkins_> dbaron: If it's the other way around, I don't think we need anything special.
16:35:12 <TabAtkins_> dino_: I think animations should always trump transitions, with the exception of !important.
16:35:38 <TabAtkins_> dbaron: The thing is, it's very hard to make that happen.
16:35:46 <TabAtkins_> dbaron: It's hard to make a transition run when an animation is running too.
16:35:57 <TabAtkins_> dbaron: It's hard to make a transition start when an animation is running.
16:36:05 <TabAtkins_> plinss: [gives his pulsing color example]
16:36:42 <TabAtkins_> plinss: So should the transition even happen?  If it does, should it transition from the currently animated value, or the base value (ignoring animations).
16:37:00 <TabAtkins_> dino: The reason comes back to transitions being just property changes spread out a bit.
16:37:37 <TabAtkins_> dbaron: So do you think transitions should happen if the 'to' or 'from' is a user!important rule?
16:38:00 <TabAtkins_> dbaron: Like something that says "a:hover { color: pink; }"
16:38:21 <TabAtkins_> dbaron: If there's also a transition request for that property, does that transition happen?
16:39:07 <TabAtkins_> dbaron: In order to transition, the transition's "virtual rule" has to be higher in the cascade than the user!important rule.
16:40:15 <mjs> mjs has joined #css
16:40:35 <TabAtkins_> dbaron: So you have an author stylesheet with "a:link { color: green; transition: color .25s; }" and a user!important sheet with "a:hover { color: black !important; }"
16:40:39 <TabAtkins_> dbaron: What happens?
16:40:45 <TabAtkins_> dino_: It transitions to black.
16:40:56 <TabAtkins_> dbaron: Okay, so it either immediately changes or it transitions.
16:41:10 <TabAtkins_> dbaron: So with your answer, the transition overrides it.
16:42:37 <TabAtkins_> TabAtkins_: If you go the other way (no transition from green to black, but a transition from black back to green), then that implies that you can *never* transition between two user!important values, because they *always* beat the transition.  Hopefully you see that's not very good.
16:42:42 <kensaku> kensaku has joined #css
16:42:53 <TabAtkins_> plinss: So I see no reason for it to not transition to/from black.
16:43:10 <TabAtkins_> plinss: And if there's another user!important rule that sets the color to something different in non-hover, it should transition those two colors as well.
16:43:28 <TabAtkins_> plinss: (author added the transition, but we're still respecting the user's colors)
16:43:43 <TabAtkins_> plinss: If the user didn't want transitions at all, they can add "* { transition: none !important; }"
16:45:13 <Cyril> Cyril has joined #css
16:45:18 <TabAtkins_> fantasai: Clarification.  If I have at the author level, two color rules, one on hover one on non-hover.  That'll trigger a transition when I hover.
16:45:20 <plh> plh has joined #css
16:46:15 <TabAtkins_> fantasai: If I have an animation on the element as well, then the color rules of the animation, because they're at a higher cascade level, at every point in time override those previous two rules, and therefore no transition is triggered.
16:46:31 <TabAtkins_> dbaron: That's not actually how it works in Gecko, but I dont' like Gecko's implementation.
16:46:32 <plh> q+ to bring up a web perf issue
16:47:40 <fantasai> TabAtkins paraphrases fantasai
16:48:06 <TabAtkins_> plinss: So you have an animation running.  Magical animation rules overriding all other cascade levels (besides transition).
16:48:31 <TabAtkins_> plinss: Now if I hover over it, the hover rule's declaration loses the cascade, so no transition happens.
16:48:36 <jarek> jarek has joined #css
16:48:44 <TabAtkins_> plinss: Now say the animation isn't running.  I have a long transition - a 5s one on hover.
16:48:55 <TabAtkins_> plinss: while I'm hovering, the transition is doing it's magical style rule.
16:49:19 <TabAtkins_> plinss: Now I trigger some other rule that starts an animation over the property.  What happens? What wins?
16:50:31 <TabAtkins_> plinss: What I think elika's model is saying implies that the animation happens, it runs, everything goes normally.  But the transition-created rule is still running at a higher cascade level, and so it overrides the animation's *effects* as long as it runs.
16:50:40 <ChrisL> q?
16:50:48 <TabAtkins_> plinss: To the implementation, transitions win, and everything works more or less statelessly.
16:51:06 <SteveZ> SteveZ has joined #css
16:51:34 <tokamoto> tokamoto has joined #css
16:51:38 <TabAtkins_> plinss: To the author, it kinda looks like the first-set wins, just becasue whether the transition starts or not depends on whether the animation is running.
16:52:17 <Bert> q+ to ask if state change triggers transition or property value change. If the latter, does the end of an animation trigger a transition back to the normal value?
16:53:10 <TabAtkins_> [dbaron is drawing out the cascade levels]
16:53:27 <divya> :'(
16:53:32 <divya> that meme outmemed itself
16:54:26 <glenn> glenn has joined #css
16:55:27 <TabAtkins_> dbaron: UA < user < author < magic-animation < author!important < user!important < UA!important < magic-transition
16:55:31 <TabAtkins_> dbaron: This is what Gecko does.
16:55:42 <TabAtkins_> dino_: WebKit does something else.
16:55:47 <rotsuya> rotsuya has joined #css
16:56:10 <ChrisL> .@sylaing yes I know I was just explaining to @Bert
16:56:17 <sakkuru> sakkuru has joined #css
16:57:41 <TabAtkins_> dino: In WebKit, magic-transition is higher than UA!important, and magic-animation is higher than that.
16:58:06 <TabAtkins_> TabAtkins_: If you set a user!important property to something static, does that override the animation or not?
16:58:09 <TabAtkins_> dino_: It does.
16:58:24 <TabAtkins_> TabAtkins_: Then you have a contradiction.  Your behavior cannot be explained in terms of cascade.
16:58:55 <TabAtkins_> s/in terms/solely in terms/
16:59:15 <TabAtkins_> plinss: Can we action you to come back with examples of behaviors, and demonstrate why that makes sense from the user perspective?
16:59:24 <TabAtkins_> dbaron: I also definitely want to see what the behavior actually is.
17:00:14 <TabAtkins_> plinss: I think we all agree that transitions belong where they are (higher than all non-magic rules).
17:00:19 <TabAtkins_> plinss: We're disagreeing on what animations do.
17:00:56 <TabAtkins_> ACTION Dean to come back with an explanation of WebKit's animation model, and why it makes more sense for users.
17:00:56 <trackbot> Created ACTION-523 - Come back with an explanation of WebKit's animation model, and why it makes more sense for users. [on Dean Jackson - due 2012-11-06].
17:01:31 <TabAtkins_> plh: Speaking on behalf of WebPerf, I'm here to make your life more complex.
17:01:44 <TabAtkins_> plh: We're working on animation too - requestAnimationFrame.
17:01:48 <TabAtkins_> plh: [explains rAF]
17:02:40 <ChrisL> http://www.w3.org/TR/animation-timing/#requestAnimationFrame
17:03:15 <kensaku_> kensaku_ has joined #css
17:03:38 <TabAtkins_> dino_: I think rAF is signif. flawed becasue you can't use it for situations where you want a callback but not at the display rate.
17:03:55 <TabAtkins_> TabAtkins_: You use setTimeout for that.  rAF is just for things that want to key into the frame rate.
17:04:05 <TabAtkins_> plh: [more explanation of rAF behavior]
17:05:03 <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0040.html
17:05:07 <TabAtkins_> plh: FF runs rAF even on inactive tabs, despite it violating the spec.  The reason is that they run it on the CSS Animations loop, and don't want to run things twice.
17:05:17 <TabAtkins_> s/run things twice/run them on two separate animation loops/
17:05:38 <plh> http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0043.html
17:07:06 <TabAtkins_> TabAtkins_: Based on what we already agreed to write yesterday (regarding animation scrubbing and how the events get fired in various cases), once that's finished, this behavior will be easy to specify.
17:07:29 <TabAtkins_> TabAtkins_: Just say that CSS animations pause whent he tab is inactive, and then scrub forward once it come sactive again.
17:07:43 <TabAtkins_> dbaron: I think right now, for background tabs we do exponential backoff on the animation timer.
17:08:00 <plh> http://w3c-test.org/webperf/specs/RequestAnimationFrame/#processingmodel
17:09:47 <TabAtkins_> TabAtkins_: I think that the spec actually doesn't *quite* forbid FF's behavior.
17:10:25 <TabAtkins_> TabAtkins_: The first paragraph of that linked section says to queue rAF stuff whenever the tab isn't hidden.  it doesn't say *not* to queue rAF stuff when the tab is hidden.
17:10:41 <Bert> q?
17:10:44 <Bert> ack plh
17:10:44 <Zakim> plh, you wanted to bring up a web perf issue
17:11:44 <TabAtkins_> Bert: I had an idea of what triggers the transition? A state change or a property value?
17:12:21 <TabAtkins_> TabAtkins_: It's the computed property value
17:12:46 <TabAtkins_> Bert: So then if you have an animation that ends, and the property then reverts to its normal value, you should trigger a transition, yes?
17:13:08 <TabAtkins_> TabAtkins: Depends on our exact cascade model.  The one I favor would indeed do that.
17:13:22 <TabAtkins_> plinss: [explains a few other possibilities, given other models]
17:13:28 <Wonsuk> Wonsuk has left #css
17:13:29 <TabAtkins_> Bert: I was just wanting to see if this was thought of.
17:13:40 <TabAtkins_> TabAtkins: Yeah, it was definitely brought up during the discussion today at some points.
17:15:02 <Shinji> Shinji has joined #css
17:15:23 <TabAtkins_> dbaron: The basic idea in Gecko is that we have a style with animation, and a style without animation.  Transitions are triggered by the style without animation.
17:15:44 <TabAtkins_> dbaron: I took an impl shortcut that turns out to not be fully valid to that model.
17:16:46 <TabAtkins_> plinss: Okay, I just want to note for the minutes that we need to make sure that the behavior of transitions when an animations begins/ends is what we want, when we decide on the cascade model.
17:16:58 <TabAtkins_> ADJOURNED
17:24:35 <SteveZ> SteveZ has joined #css
17:37:42 <Ms2ger> Ms2ger has joined #css
17:37:51 <glenn> glenn has joined #css
17:50:24 <cabanier> cabanier has joined #css
17:51:20 <tokamoto> tokamoto has joined #css
19:23:02 <SimonSapin> SimonSapin has joined #css
19:36:38 <antonp> antonp has joined #css
20:11:03 <koji> koji has joined #css
20:17:39 <brett> brett has joined #css
20:18:15 <brett> trackbot, bye
20:18:15 <trackbot> trackbot has left #css
20:18:19 <trackbot-test> trackbot-test has joined #css
20:18:22 <brett> trackbot, status?
20:18:32 <Ms2ger> That didn't work out well :)
20:20:23 <SimonSapin> brett: about today’s UTF-8 fail? One .decode('utf8') somewhere should be enough, but where :]
20:20:55 <brett> SimonSapin, That one I know I've fixed, this is about trackbot trying to flood the channel with names of CSS WG participants.
20:21:31 <trackbot-test> trackbot-test has joined #css
20:21:33 <brett> trackbot, status?
20:24:43 <brett> Okay, think I got it this time.
20:24:46 <trackbot-test> trackbot-test has joined #css
20:24:49 <brett> trackbot, status?
20:29:40 <trackbot> trackbot has joined #css
20:30:26 <brett> trackbot, status?
20:30:56 <Zakim> Zakim has left #css
20:30:57 <brett> All right then.  If you all notice any other issues, please let us know at <sysreq@w3.org>.  Thanks for your patience with this.
20:31:26 <brett> brett has left #css
20:32:13 <Rossen> Rossen has joined #css
20:43:36 <SamB_MacG5> SamB_MacG5 has joined #css
20:50:04 <trackbot> trackbot has joined #css
20:59:50 <antonp1> antonp1 has joined #css
21:02:41 <shepazu> shepazu has joined #css
21:13:23 <antonp> antonp has joined #css
21:14:12 <antonp2> antonp2 has joined #css
21:22:27 <tantek> tantek has joined #css
21:34:00 <divya1> divya1 has joined #css
21:34:32 <divya1> divya1 has left #css
21:46:17 <liam> liam has joined #css
21:50:59 <kensaku> kensaku has joined #css
21:53:30 <glenn> glenn has joined #css
21:54:40 <tokamoto> tokamoto has joined #css
21:55:11 <tomoyuki> tomoyuki has joined #css
21:56:56 <lstorset> lstorset has joined #css
22:26:08 <drublic> drublic has joined #css
22:34:05 <r12a> r12a has joined #css
22:44:21 <tokamoto> tokamoto has joined #css
22:53:21 <krit> krit has joined #css
23:15:28 <tantek> tantek has joined #css
23:22:42 <sakkuru> sakkuru has joined #css
23:23:36 <krit> krit has joined #css
23:24:09 <JohnJansen> JohnJansen has joined #css