15:37:12 <RRSAgent> RRSAgent has joined #css
15:37:12 <RRSAgent> logging to http://www.w3.org/2015/09/16-css-irc
15:37:22 <astearns> RRSAgent, make logs public
15:42:25 <darktears> darktears has joined #css
15:51:00 <gregdavis> gregdavis has joined #css
15:52:52 <dael> dael has joined #css
15:56:06 <alex_antennahouse> alex_antennahouse has joined #css
15:58:05 <astearns> present+ astearns
15:58:11 <dael> present+ dael
15:58:17 <dael> ScribeNick: dael
15:58:20 <kwkbtr> kwkbtr has joined #css
15:59:01 <gregwhitworth> gregwhitworth has joined #css
15:59:07 <dauwhe> present+ dauwhe
15:59:08 <Florian_> present+ Florian
15:59:18 <gregwhitworth> present+ gregwhitworth
15:59:21 <bkardell_> bkardell_ has joined #css
15:59:26 <AH_Miller> AH_Miller has joined #CSS
16:01:02 <darktears> darktears has joined #css
16:01:02 <adenilson> adenilson has joined #css
16:01:32 <fantasai> present+ fantasai
16:01:34 <kwkbtr> present+ Toru Kawakubo
16:01:44 <skk`> present+ Hiroshi Sakakibara/skk
16:02:10 <Rossen_web> Rossen_web has joined #css
16:02:17 <Rossen_web> present+ Rossen_web
16:02:28 <fantasai> TabAtkins, css-display-3 doesn't seem to be linking up properly for WDs? It keeps generating links to the ED, even though afaict the WD is up-to-date
16:02:39 <adenilson> present+ adenilson
16:02:46 <gregdavis> present+ gregdavis
16:02:56 <Bert> Present+ Bert
16:03:29 <dael> present+ hober
16:03:35 <dael> present+ AH_Miller
16:03:45 <dauwhe> fantasai: do you want me to draft email for css-inline publication, or do you want to do it?
16:03:50 <bkardell_> present+ bkardell_
16:03:57 <fantasai> dauwhe: I already did it :)
16:04:12 <dael> astearns: Me might as well start
16:04:17 <plh> Present+ Plh
16:04:17 <dael> s/Me/We
16:04:22 <dael> astearns: Any extra agenda items?
16:04:24 <Florian> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
16:04:44 <dael> Florian: If we have time we might want to look into this e-mail. Tantek and I responded about allowing resize to apply to replaced elements.
16:04:54 <dael> astearns: We'll put that at the end.
16:05:00 <bradk> bradk has joined #css
16:05:11 <fantasai> https://wiki.csswg.org/planning/tpac-2015
16:05:21 <fantasai> If no items, we will do a dramatic reading of CSS Box Alignment
16:05:26 <fantasai> So add items
16:05:26 <fantasai> :p
16:05:27 <dael> astearns: We need agenda items for TPAC so please go to the wiki and add things you want to discuss. The sooner we items on the sooner we get a schedule so we don't have to spend F2F time scheduling
16:05:33 <astearns> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0168.html
16:05:56 <dael> astearns: Also, just reminding everybody about the Japanese industry meetup. Please add your name to the wiki saying you're going.
16:05:59 <bcampbell> bcampbell has joined #css
16:06:08 <plh> regrets+ DavidBaron
16:06:10 <dael> skk`: I'm trying to decide the venue. Then I will note that to the mailing list.
16:06:25 <Bert> q+ to ask if the start time is known already.
16:06:36 <dael> skk`: After that I will send a planned agenda. Please let me know if you have any questions or topics. I will send the agenda ist within the week.
16:06:42 <dael> astearns: [reads bert's q]
16:06:42 <koji> Present+ koji
16:07:02 <dael> Florian: I think it depends on the venue, but the prop. was 3-7 followd by dinner.
16:07:12 <tantek> tantek has joined #css
16:07:26 <Bert> q-
16:07:36 <dael> astearns: E-mail says 3-4pm start and that will depend on where we end up meeting. I'll add a section tot he TPAC page for industry meetup questions and skk` can reference that.
16:07:52 <dael> Rossen_web: Since we're talking TPAC logistics, is it a good time to talk Houdini?
16:08:08 <dael> astearns: I wanted to get through the rest of the agenda because I feel the Houdini convo could take a while.
16:08:11 <astearns> http://www.w3.org/2015/10/meetup-sapporo.html
16:08:23 <dael> astearns: Other reminder is there's a Mon. night meetup. If you're interested, please sign up.
16:08:25 <dael> Rossen_web: Which?
16:08:41 <dael> astearns: W3C dev meetup at Sapporo(sp?) convention center.
16:08:44 <adenilson_> adenilson_ has joined #css
16:08:54 <dael> astearns: You can sign up for just hte industry demos or also the social time afterwards.
16:09:07 <dael> astearns: That's all for reminders.
16:09:25 <dael> Topic: Prefixing Policy in Snapshot
16:09:37 <dael> Florian: There was something from MS which waas addressed. I think we're waiting on Apple.
16:10:14 <andrey-bbg> andrey-bbg has joined #css
16:10:39 <dael> hober: I'm gathering feedback. Overall it looks good and is an improvement. Two areas of concern, though this isn't final feedback, is difference between what we do and the new policy. When you ship a feature prefixed you should simulataniously ship unprefixed, that might change syntax. But that might be a big deal.
16:10:44 <dael> Rossen_web: Is this a must?
16:10:46 <dael> hober: Should
16:10:59 <dael> Florian: You must ship unprefixed, you should ship prefixed.
16:11:24 <dael> hober: Yeah. That's somethign we're still talking about.
16:11:39 <dael> hober: The second is the...let me pull up the draft...
16:11:44 <astearns> https://drafts.csswg.org/css-2015/#responsible
16:11:59 <tantek> present+ tantek
16:12:14 <dael> Florian: I misspoke. The wording is should for both prefix and unprefixed.
16:13:08 <dael> hober: The second bit is in market pressure and defacto standards [reads] The main concern is histically adding support for unprefixed and removing for prefixed are treated as sep. engineering decisions. One is based on stability and one is on compat.
16:13:15 <TabAtkins> present+ Tab Atkins
16:13:18 <smfr> smfr has joined #css
16:13:25 <smfr> present+ smfr
16:13:35 <tantek> huh? unstable = ship unprefixed?!?
16:13:35 <vollick> vollick has joined #css
16:13:47 <tantek> wow this is confusing
16:14:21 <dael> Florian: To put some feedback on that in case the wording isn't clear, the intent would be is when you ship something unstable you ship it unprefixed and pref ship it prefixed. The preference is that the authors would use unprefixed unless there's a bug. That changes the model. IN the majority of cases the prefix would only be used to work around bugs and when you remove the bugs it would remove the compat hit.
16:14:44 <dael> Rossen_web: I don't quite agree. The prefix version in a majority of cases is to wait for other impl to catch up and for specs to mature.
16:14:54 <tantek> q+
16:15:06 <tantek> Zakim?
16:15:11 <dael> Florian: Today yes. The way this is proposed for the future there is no reason to use prefixed when they're released simultaiously unless you're trying to be impl specific.
16:15:13 <Zakim> Zakim has joined #css
16:15:16 <tantek> q+
16:15:41 <dael> astearns: We're talking about an unstable prop that means it's impl in at least 3 UA and there's rough interop and the CSS has consensus it should exist. That's a different stable.
16:16:07 <dael> Florian: You may disagree with what's going on, but I wanted to clarify what's going on. If it's clear and you disagree that's a different discussion.
16:16:22 <dael> hober: Personally I'm fine. It's should which is like must unless you have a good reason.
16:16:33 <MaRakow> MaRakow has joined #CSS
16:16:39 <dael> smfr: The spec needs a word for unstable but follows the three interop
16:16:40 <MaRakow> present+ MaRakow
16:17:57 <dael> fantasai: It uses it for a spec that is unstable. So the spec is unstable but we have these thigns happening. We only have rough interop. THe spec is out of date or incomplete or there's a ton of open issues, but we have all these people shipping. There will be problems because the spec isn't finished. This is like the transforms and transitions case where stuff was still changing and people were still implementing and there were all these issues.
16:18:23 <dael> fantasai: We do need to be a bit more clear, but there's this stage where the spec is moving to stable and there are a bunch more impl, but the spec isn't finished yet and might change.
16:18:52 <dael> Florian: WE shouldn't use a word that means unstable and matches all those criteria above. So if you ship something that doesn't match  the criteria you should still take this approach.
16:20:15 <dael> tantek: a couple of points. I think the first problem is in our convo of what means unstable vs interop. If we're using unstable we should use what an author would consider unstable instead of a spec impl definition. If something works across most places they'll ignore that the WG thinks that it's unstable. I think that needs to get reaccessed.
16:21:04 <dael> tantek: I understand the intention that changing the meaning of when you ship prefix vs unprefix is a good intention, but transitioning to that model will be so confusing and I think authors will just say screw it and use both. If the goal is to try and get out of this problem situation I don't think that approach will work.
16:21:12 <dael> tantek: I don't have an alternative to suggest.
16:21:38 <dael> tantek: So first point, use of unstable needs to be author centric definition. Second is changing the meaning of prefix and unprefix is good intention but will fail.
16:22:32 <dael> Florian: second, I wouldn't be surprised people will be confused and use both, but I don't think it will cause problems. If people sue both the unprefixed is in the style sheet so vendors can remove the prefixed. So I think it will be misused, but I don't thinkt hat's causing problems.
16:22:52 <dael> tantek: Not causing problems isn't a high enough bar. If you say this path will improve the situation that's good.
16:23:03 <antenna> antenna has joined #css
16:23:04 <dael> Florian: I think that when this is misused it isn't going to be a problem.
16:23:12 <dael> tantek: So how about not preventing improvement.
16:23:19 <dael> Florian: How does this prevent improvement?
16:23:45 <fantasai> TabAtkins, "shorthand" is also mislinking to cascade-4 ED
16:23:52 <dael> tantek: I'm trying to encourage you to re-word your arguement in a stronger way. It sounds like you are close to demoing that the misuse won't prevent the improvement and in that case it's reasonable to move forward.
16:24:14 <Rossen_web> -goodenoug-cascade-4
16:24:26 <dael> Florian: I think it won't prevent the improvement where vendors can remove the prefixed version once the bugs are ironed out because there will be no risk to removing the prefix.
16:25:03 <dael> tantek: I think you need to put that into the spec. What if authors use both? And then put what you said. And that will demo why impl should use this new policy. I think that's a strong argument and it should be clear.
16:25:10 <dael> tantek: Does that make sense to everyone else?
16:25:22 <TabAtkins> fantasai: Hm, I think I do the "remove anchors from older versions of the spec" step before I do the "prefer TR-level anchors when generating TR-level specs".
16:25:25 <tantek> ack tantek
16:25:48 <dael> astearns: I think some of the argument is in the section, but it can be improved. So I'm hearing we need to clarify what we mean by unstable and clarify why this change in prefixing policy is a good thing. So we can get that and circle around.
16:26:08 <dael> action Florian to improve the note explaining why the prefixing policy change is good
16:26:08 <trackbot> Created ACTION-722 - Improve the note explaining why the prefixing policy change is good [on Florian Rivoal - due 2015-09-23].
16:26:24 <bradk> Are authors supposed to list the prefixed versions of properties last?
16:26:28 <dael> action fantasai fix up the termonology around 'unstable'
16:26:28 <trackbot> Created ACTION-723 - Fix up the termonology around 'unstable' [on Elika Etemad - due 2015-09-23].
16:26:43 <dael> tantek: I'd ask leaverou_away what she thinks unstable means when authoring.
16:26:55 <dael> astearns: hober you're still collecting feedback. Do you know when you'll be done?
16:26:57 <dael> hober: No offhand.
16:27:46 <dael> Rossen_web: We're still collecting too so I'm sure this won't be the last time we discuss it. Ideally the changes we're discussing will come about soon so we don't have to go back for another few weeks to circle back on this set of changes. It would be helpful to start stabilizing the subject.
16:28:03 <dael> Florian: Yes. This is a change in termonology and a note. This isn't changing the actual policy.
16:28:07 <dael> Rossen_web: They are still changes.
16:28:12 <dael> Florian: I'll get to it soon.
16:28:13 <bradk> "Unstable" = not ready for general use, features/syntax might change.
16:28:17 <dael> Topic: Writing Mode Issues
16:28:39 <dael> fantasai: Koji sent a couple in. Let me pull up the DoC.
16:28:43 <astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0100.html
16:28:49 <astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0101.html
16:28:49 <dael> astearns: The links I sent in the agenda were Koji's.
16:28:55 <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-47
16:29:36 <dael> fantasai: First issue don't need WG input, I think. Not that one. For some impl that need to support old writing modes values in SVG syntax but not CSS they could map over using UA style rule. I was going to add an example.
16:29:50 <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0061.html
16:29:52 <dael> fantasai: Main one that's open is this one. Orientation of an <iframe> whichi s 300x150
16:30:34 <dael> fantasai: Does that orientation rotate in vertical text or do we keep it as 300x150. I lean to keep it because the main use case if plug-ins where they can't adapt. If there's a reason it should go the other way let me know.
16:30:36 <koji> this one: https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0195.html
16:30:54 <dael> Rossen_web: I would argue the opp. You can argue keeping the <iframe> and images default sizing logical...
16:31:05 <dael> Rossen_web: Images are upright regardless. You're right.
16:31:27 <dael> fantasai: We think the kinds of things that would rely on this default are more likely to be image-like the logic was lets make it stay upright.
16:31:38 <dael> koji: FF Webkit Blink and Trident default to vertical.
16:32:03 <dael> Rossen_web: That's what we do. Everyone defaults to keeping the 'default' size of <iframe> physical. So the w is 300 and h is 150
16:32:03 <koji> s/vertical/physical/
16:32:12 <dael> Florian: Isn't there a security consideration?
16:32:23 <dael> Rossen_web: What would be different than an image witha  default size?
16:32:40 <dael> Florian: From and <iframe> not being supposed to know what's going on. Well, maybe not really. Just ignore me, I'm not sure.
16:33:29 <dael> fantasai: I think that's kind of it for things we need to ask the WG for help on. I'm going to go over the DoC and make sure everything is wrapped up and colorized. If there's anything you feel needs to be addressed in this draft that hasn't yet, please let us know. We're trying to go for CR soon.
16:33:35 <dael> astearns: Do you need a resolution?
16:33:36 <dael> fantasai: Yeah.
16:34:10 <dael> Rossen_web: It's good to have in the spec that default replaced size remains physical.
16:34:22 <dael> tantek: How about answering the security questionarre.
16:34:31 <Florian> https://drafts.csswg.org/css-ui/#security-privacy-considerations
16:34:49 <MaRakow> MaRakow has joined #CSS
16:35:08 <dael> tantek: I think you must include this section in the spec to go to CR if you're touching <iframe>. It doesn't take long and it's a good practice.
16:35:21 <dael> Florian: Even if you end up saying everything is safe at least you've thought about it.
16:35:38 <plh> --> https://w3ctag.github.io/security-questionnaire/ Self-Review Questionnaire: Security and Privacy
16:35:59 <dael> tantek: Yeah, but even if <iframe> is giving a default size it's poss. to leak information. If I can ifram youtube and get a default size and it's diff if you're logged in that's not info I should have. You see what I'm getting at?
16:36:47 <dael> Rossen_web: I don't. What you'll see from the iframe is if it defaults to 300x150 it will regardless of the writing mode. We're not changing anything about replaced default sizing. We're making it less detectable. Replaced sizing remains physical
16:36:53 <dael> Florian: That we go that way makes it safe.
16:37:10 <dael> tantek: And because it's something potentially cross origin it makes sense to put the survey answers in.
16:37:17 <dael> fantasai: Because they're all no I'm not sure how it helps.
16:37:31 <dael> tantek: It shows you've gone through and taken the time. There's a question about cross-origin.
16:37:39 <dael> fantasai: But writing mode doesn't do cross-origin.
16:38:02 <fantasai> +1 to astearns
16:38:09 <dael> astearns: I'm not that entused about boilerplate no to every question, but I like that we thought about these things being there. Should we say we looked at this in an appendix and it was all no.
16:38:23 <dael> tantek: And maybe adda  note about <iframes> being okay because it's the defualt size.
16:38:45 <dael> astearns: So resolve to put in an appendix and say that we considered it as one of the reasons we didn't change the default replaced size.
16:38:51 <dael> fantasai: Is there an official link?
16:39:14 <dael> tantek: The one from plh. I'm pinging the TAG every few weeks to publish a W3C note version on TR, but that hasn't happened yet.
16:39:38 <dael> plh: The TAG is meeting. I can nag them for you.
16:39:41 <dael> tantek: Please do.
16:39:55 <dael> tantek: Last time I asked plinss was apperently assigned to publish it.
16:40:08 <bkardell_> tantek: didn't you mention this in tag meeting irc yesterday?
16:40:09 <bradk> bradk has joined #css
16:40:18 <tantek> https://drafts.csswg.org/css-ui/#security-privacy-considerations
16:40:29 <dael> RESOLVED: Replaced sizing remains physical. add an appendix about the considereation of the security and privacy concerns.
16:40:42 <dael> astearns: Anything else?
16:41:00 <dael> fantasai: I think that's it for now. We should repub CR perhaps next week.
16:41:08 <Florian> Agenda+ using prefixes in examples
16:41:13 <dael> plh: In terms of publishing you'll need to ping me or Bert.
16:41:22 <dael> Topic: Definition of white space
16:41:39 <dael> fantasai: dbaron sent this issue about making sure the def. of white space is sync across specs.
16:42:04 <dael> fantasai: CSS 2 spec has two def depending on syntatic or white space that gets collapsed. One include the form feed character and one doesn't is the main diff.
16:42:43 <dael> fantasai: We should align our specs and HTML and go with the list that includes form feed. It seems to be an error in CSS spec that form feeds weren't included since every other spec has it.
16:43:04 <dael> fantasai: Certain broswers collapse other characters, but FF doesn't and they're not in any spec, so I think we should align on the historical.
16:43:23 <dael> TabAtkins: I strongly agree. This is to find the formatting in your source code, so it should just be the handful HTML defines.
16:43:36 <dael> astearns: Objections?
16:43:54 <bradk> NBSP in the HTML is almost always non-semantic
16:43:57 <dael> fantasai: This would effect CSS2.1 errata and CSS text
16:43:59 <TabAtkins> s/find the formatting/deal with the whitespace used in formatting /
16:44:04 <dael> tantek: Has there been testing on this?
16:44:31 <TabAtkins> bradk: It's usually used for alignment, yeah, not semantic purpose, but it's definitly not used in source code.
16:44:35 <dael> fantasai: dbaron had one in his message. FF follows the spec except the off inconsistancy on collapsable white space. Other browsers do this and more.
16:44:51 <dael> tantek: So other impl collapse the form feed. We have interop on that except FF?
16:44:56 <TabAtkins> Florian: Right, it's not really used, it's just that matching definitions across specs is useful.
16:45:04 <dael> fantasai: FF includes form feed character. The CSS spec doesn't include that.
16:45:07 <dael> tantek: Awesome.
16:45:07 <Florian> TabAtkins: sure
16:45:20 <dael> TabAtkins: It doesn't include it in the def. of white space in this one place.
16:45:21 <tantek> +1
16:45:23 <dael> tantek: Sounds good.
16:45:24 <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0237.html
16:45:54 <dael> RESOLVED: Add the form feed character and make sure all CSS specs align on the definition of white space
16:46:24 <dael> Topic: Implementability of align. etc...
16:46:38 <dael> TabAtkins: I'm generally okay witht he changes. I want to review and discuss with fantasai .
16:46:46 <dael> astearns: Feel free to respond on the list.
16:46:57 <dael> TabAtkins: Yep. It's in my 'need to deal with soon'
16:47:00 <astearns> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
16:47:05 <dael> Topic: Resizeing (from Florian)
16:47:31 <dael> Florian: Either that topic or the discussion from the member only list about using prefix expamples in spec
16:47:38 <dael> Topic: using prefix examples in spec
16:48:29 <dael> Florian: When doing a live example in a spec showing how a prop would work a sample rendering using some other way of displaying it is useful. I did it using normal unprefixed CSS which works for everything except safari where I used a refix for the behavior. Bert and I think fantasai didn't like the prefix use.
16:48:48 <dael> Florian: I can do it using a gif, but is it bad using the prefixed fallback for one browser.
16:48:58 <dael> smfr: Safari and iOS 9 will support that unprefixed.
16:49:44 <dael> fantasai: Part of the reason tantek was arguing to allow was it functions as an inline test int he spec. As an impl reading the spec you can see if your impl does this correctly and as an author you can see if your browser does this. But if you add the prefix that doesn't work.
16:49:53 <dael> Florian: I was using it on the ref side, nott he test side.
16:50:04 <dael> fantasai: In that case, I don't have a strong opinion.
16:50:24 <dael> Florian: I can switch to doing it was a GIF. I'm not sure they're standard, though they work everywhere.
16:50:30 <tantek> q+
16:50:34 <dael> fantasai: I think they're standard even if there isn't a spec.
16:50:45 <hyojin> hyojin has joined #css
16:50:45 <dael> Florian: If the criteria is has a standard, gifs are not.
16:50:54 <dael> tantek: This is prefix in the exicutable code, not the example?
16:50:56 <dael> Florian: Yeah.
16:50:58 <plh> q+
16:51:02 <dael> tantek: Then it absolutely should be allowed.
16:51:04 <dael> TabAtkins: I agree.
16:51:19 <dael> tantek: We've gotten acceptions for this multiple times, LIke CSS 3 UI
16:51:29 <dael> Florian: That was a slightly different battle.
16:51:33 <dael> tantek: No, we have unrefixed.
16:51:59 <dael> plh: I'm trying to understand the motivation.
16:52:37 <dael> plh: The goal isn't to say anyone can use CSS prefixes in their spec, the goal here is for the purpose of having a reference if we can find a way that works in all existing browsers it's okay to use a prefix.
16:53:23 <dael> Florian: I have a double example where on one side it shows what the property would do which doesn't work right now and on the other side show what it will do once implemented which I can do using existing properties except for one browser where I needed the prefix to make it work.
16:53:29 <dael> plh: Okay, thanks for the clarification.
16:54:10 <dael> Florian: I think in general this should be fine, but requires judgement where if the spec isn't stable but there are multiple interop impl, but it shouldn't be used when there isn't interop. In this specific case it seemed fine.
16:54:17 <tantek> q?
16:54:24 <dael> astearns: So we should allow this prefix in this ex seems consensus.
16:54:58 <plh> q+
16:55:04 <tantek> q-
16:55:27 <dael> Bert: This is about the W3C side. It's not about how we ought to show things to people. If we want to show how something blinks that's fine. This is about what we can show on the TR page. That's where we have documents that should stay there forever and there we want thigns that should be valid and stable forever. We want to keep the value of the TR page as high as possible. I'd say find some other means of showing blinking.
16:55:37 <plh> q?
16:55:44 <dael> astearns: I don't see the future compat issue. We're not only using the prefix, we're also using unprefix.
16:55:57 <Bert> s/side/site/
16:56:32 <dael> plh: I think we jumped that gun when we said you want to use prop that aren't in REC in a CSS spec and that's okay. So we jumped that gun in spec. At the time prefixes wasn't presented to me. Honestly, I'll have to sit down with Tim and make sure he's comfortable to say go ahead.
16:56:41 <dael> Florian: Should I restore the examples, we try and publish?
16:57:06 <dael> plh: You won't be able to until I sit down with Tim, but if you want to restore the spec go ahead.
16:57:15 <dael> Florian: Okay, so I'll resore the spec.
16:57:34 <dael> plh: I may have a chance later today to sit down with him. Some time in the next four hours.
16:57:46 <dael> astearns: So we have a clear desire from the WG to allow the example and we'll wait to hear from plh.
16:57:52 <dael> astearns: There's just two minutes left.
16:58:12 <dael> fantasai: Status of will-change and variables which were suposed to be pub as CR a while ago, who has that ball?
16:58:14 <dael> TabAtkins: Me.
16:58:23 <dael> fantasai: Can you pass it to somebody else at some point?
16:58:25 <dael> TabAtkins: Yes.
16:58:55 <dael> astearns: We'll talk about resize issue next week and Houdini at TPAC on maybe Thursday or Friday will continue on the ML.
16:59:01 <dael> astearns: That's it for the week.
16:59:39 <bradk> Beeboop^100
17:01:23 <bradk> 😀
17:02:00 <bradk> bradk has left #css
17:06:29 <rego> rego has joined #css
17:08:26 <estellevw> estellevw has joined #css
17:22:05 <rego> rego has joined #css
17:31:06 <rego> rego has joined #css
17:36:03 <adenilson_> adenilson_ has joined #css
17:44:06 <rego> rego has joined #css
17:58:37 <glazou> glazou has joined #css
17:58:59 <glazou> hey all ; sorry I could not chair that call, just came back from my duties
17:59:07 <rego> rego has joined #css
17:59:59 <glazou> astearns: everything went well?
18:00:46 <astearns> glazou: I think so - no one called for my head, at least
18:01:17 <astearns> do I need to do anything with RSSAgent, or does it drop off?
18:01:20 <glazou> wonderful ;-)
18:01:25 <glazou> nothing to do
18:08:08 <rego> rego has joined #css
18:18:08 <Florian> glazou: everything went lovely. We even had 2 discussions about prefixes where we reached reasonable conclusions. That's some quality chairing. :)
18:18:21 <Florian> plh: draft with examples updated, and in your inbox
18:18:31 <glazou> Florian: that’s even a miracle !!! ;-)
18:19:02 <glazou> discussing prefixes AND reasonable conclusions, colour me impressed :-D
18:19:46 <zcorpan> zcorpan has joined #css
18:19:50 <rego> rego has joined #css
18:19:56 <Florian> well "conclusions". These discussions are not closed, as we need feedback from people not present. But as far as the presents were concerned, things went well.
18:20:28 <Florian> on the other hand, I's now past 3am here. It's high time I got some sleep.
18:20:51 <glazou> yeah, and I should have dinner, it’s 8:20pm here
18:20:55 <glazou> bye everyone
18:29:53 <TabAtkins> Florian: "We had such a great discussion now that we have a new chair that isn't you!" ^_^
18:31:26 <Florian> Florian has joined #css
18:33:43 <estellevw> estellevw has joined #css
18:33:57 <smfr> smfr has left #css
18:38:51 <rego> rego has joined #css
18:53:51 <rego> rego has joined #css
19:08:52 <rego> rego has joined #css
19:13:48 <adenilson_> adenilson_ has joined #css
19:23:52 <rego> rego has joined #css
19:32:52 <Florian> Florian has joined #css
19:32:53 <rego> rego has joined #css
19:49:53 <rego> rego has joined #css
20:08:54 <rego> rego has joined #css
20:13:06 <lajava> lajava has joined #css
20:23:55 <rego> rego has joined #css
20:32:55 <rego> rego has joined #css
20:38:08 <myles> myles has joined #css
20:41:55 <rego> rego has joined #css
20:46:59 <lajava> lajava has joined #css
20:48:34 <myles> myles has joined #css
20:50:55 <rego> rego has joined #css
20:55:57 <myles> myles has joined #css
20:56:22 <myles> myles has left #css
21:30:17 <zcorpan> zcorpan has joined #css
22:00:34 <zcorpan> zcorpan has joined #css
22:09:34 <fantasai> TabAtkins: Do you know the answer to this? https://lists.w3.org/Archives/Public/www-style/2014Jan/0157.html
22:09:41 <fantasai> TabAtkins: It's a CSSOM shorthands question
22:12:03 <TabAtkins> Yes, it does have to return null.  This is why the DOM l2 APIs were the absolute worst.
22:12:34 <fantasai> TabAtkins: That's not really compatible with expanding shorthands into longhands, though
22:12:41 <TabAtkins> Correct.
22:12:50 <TabAtkins> See previous statement.
22:13:20 <fantasai> TabAtkins: Do we need to fix that somehow, then?
22:13:50 <TabAtkins> I doubt it. They're old-ass APIs, and terrible to use. Usage is very low.
22:14:16 <fantasai> Okay
22:14:26 <TabAtkins> getPropertyValue() works correctly, and is shorter than getPropertyCSSValue()
22:14:32 <fantasai> cool
22:14:38 <TabAtkins> (Who tf came up with that name, btw?)
22:14:44 <fantasai> Would you mind replying to that message then?
22:15:03 <fantasai> You can also point out that very few people would be querying the value of a paged media property
22:15:12 <fantasai> since paged media and scripting aren't especially common.
22:15:33 <fantasai> and scripting a break control property isn't really a use case for anything except an HTML editor
22:15:40 <fantasai> If not, I can reply
22:15:47 <fantasai> but I figure you know more about this issue than I do...
22:17:11 <TabAtkins> I'm replying.
22:17:15 <fantasai> Thanks~
22:31:12 <astearns> TabAtkins: not sure that Johannes would agree with you that "paged media and scripting don't collide very much" :)
22:31:28 <TabAtkins> Paged Media, scripting, *and* DOM L2 Style
22:36:16 <zcorpan> zcorpan has joined #css
22:42:38 <zcorpan_> zcorpan_ has joined #css
22:44:24 <zcorpan> zcorpan has joined #css
23:06:54 <rbyers> rbyers has joined #css
23:19:13 <Florian> Florian has joined #css
23:24:52 <jdaggett> jdaggett has joined #css
23:48:44 <estellevw> estellevw has joined #css
23:52:54 <zcorpan> zcorpan has joined #css
23:54:27 <zcorpan_> zcorpan_ has joined #css