16:08:03 RRSAgent has joined #css 16:08:03 logging to http://www.w3.org/2015/01/21-css-irc 16:08:09 Zakim, this will be STyle 16:08:09 ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 52 minutes 16:08:16 RRSAgent, make logs public 16:08:51 glazou has changed the topic to: logs: http://krijnhoetmer.nl/irc-logs/css - 2015-01-21 telcon http://lists.w3.org/Archives/Public/www-style/2015Jan/0369.html(JS only logs: https://log.csswg.org/irc.w3.org/css/today ) 16:09:05 glazou has changed the topic to: logs: http://krijnhoetmer.nl/irc-logs/css - 2015-01-21 telcon http://lists.w3.org/Archives/Public/www-style/2015Jan/0369.html (JS only logs: https://log.csswg.org/irc.w3.org/css/today ) 16:11:51 Florian has joined #css 16:22:44 kwkbtr has joined #css 16:27:42 hmmm I pushed a editorial fix on mediaqueries-3 minutes ago and now I can’t reach dev.w3.org/csswg any more 16:28:28 doesn't load from here either 16:28:45 hmmm 16:29:02 hg commit & hg push kill the server ; lovely :-p 16:32:05 or a coincidence 16:32:15 or a hint to start using git 16:32:16 :) 16:32:36 I'll be a bit late to the call today (most likely), but I'll join. Probably 20 minutes late or so 16:37:31 yes, saw that already 16:38:28 Florian_away: I heard someone say about a year ago « mercurial is the live proof the syntax of XSLT was not that bad » :-D 16:42:23 Mercurial has syntax? 16:43:16 that person was speaking of the command line’s syntax, Ms2ger 16:47:41 Rossen_ has joined #css 16:50:33 bcampbell has joined #css 16:54:24 dael has joined #css 16:55:33 Style_CSS FP()12:00PM has now started 16:55:40 +dael 16:57:33 AH_Miller has joined #CSS 16:57:36 +??P9 16:57:41 Zakim, ??P9 is me 16:57:41 +glazou; got it 16:57:53 +plinss 16:58:40 +??P17 16:58:42 Zakim, ??P17 is me 16:58:42 +SimonSapin; got it 16:59:05 +dauwhe 16:59:44 zcorpan has joined #css 16:59:59 +[IPcaller] 17:00:22 IPcaller is me 17:00:30 Zakim, [IPcaller] has bcampbell 17:00:30 +bcampbell; got it 17:00:48 +Lea 17:01:04 andreyr has joined #css 17:01:06 +MikeMiller 17:01:23 bradk has joined #css 17:01:30 SteveZ has joined #css 17:01:30 Zakim, mute Lea 17:01:30 Lea should now be muted 17:01:49 +??P19 17:01:57 leaverou: I muted you through zakim, unmute yourself if you want to speak 17:01:58 Zakim, ??P19 is me 17:02:00 +kwkbtr; got it 17:02:02 +BradK 17:02:13 +[Bloomberg] 17:02:36 as you wish leaverou 17:02:41 Zakim, unmute Lea 17:02:41 Lea should no longer be muted 17:02:42 +Stearns 17:02:45 +fantasai 17:02:46 +hober 17:02:48 andreyr has joined #css 17:02:51 +SteveZ 17:03:09 smfr has joined #css 17:03:33 tantek has joined #css 17:03:40 +[Microsoft] 17:03:48 +smfr 17:03:57 zakim, microsoft has me 17:03:57 +Rossen_; got it 17:04:09 leaverou: please send some food and wine 17:04:15 +dbaron 17:04:23 Olympus? 17:04:58 +??P44 17:05:08 ChrisL has joined #css 17:05:08 + +1.281.305.aaaa 17:05:09 glazou: Let's start 17:05:13 ScribeNick: dael 17:05:14 zakim, aaaa is me 17:05:14 +TabAtkins; got it 17:05:27 glazou: Anything to add to the agenda or discuss before we start to official one 17:05:33 antenna has joined #css 17:05:36 glazou: There's one from koji but I'm not sure we'll have time 17:05:46 Topic: Flexbox Accessability 17:05:50 https://wiki.csswg.org/spec/css3-flexbox/accessibility 17:05:51 bcampbell: Let me paste the wiki 17:05:53 +[IPcaller.a] 17:05:56 +ChrisL 17:06:18 alex_antennahouse has joined #css 17:06:18 +??P55 17:06:27 bcampbell: After posting some arguements and replies, it was my ex that I put in with a trivial flex box that was a diagram, I agree it was trivial and we need to address the holy grail of layout 17:06:36 glazou: I'd like to prepare a CSS3-UI draft for publication before the f2f 17:06:38 i should be ipcaller that just joined 17:06:44 zakim, ??p55 is me 17:06:44 +tantek; got it 17:06:55 zakim, mute me 17:06:55 tantek should now be muted 17:07:00 tantek: ok, will put that between items 2 and 3 17:07:05 +??P62 17:07:11 thank you glazou 17:07:19 bcampbell: I did some research on that and realized it says the seq of the cont in this layout has no meaning and therefore rearranging visually has no consiquence. We have an arguement against that from Matt King in IMB who is a spokes person for the blind and he's said that he wants it to work for the blind 17:07:28 + +1.631.398.aabb 17:08:09 bcampbell: After seeing that there's reflief and a meaningful sequesnce, I talked to Richard and a dev on a high profile IBM app to understand why we have this issues and what exactly they want. Flexbox has the opp to be powerful for designers that need to move things visually and not get dev to change the code. 17:08:21 +koji 17:08:35 +[IPcaller.aa] 17:08:54 bcampbell: There's several examples that I can site where data comes into the client and you're able to arrange the data using Flexbox. Those dev are crying out about losing the Moz "bug" because they're not going to update or use Tab and nex to go through. 17:09:00 -Lea 17:09:08 s/Tab and nex/tabindex/ 17:09:31 bcampbell: So we have a complex, rich application, like an e-mail app, so that's the other side of the power. TO go back, the arguement to force browsers to update tabbing order is what I'm hearing from disabled community. 17:10:16 bcampbell: From Richard and I what we need is a paramater to tell if the sequence is meaningful or not. If it's not meaningful, we can stay witht he old way. When it is meaningful, we need to be able to tell the browser that it is and switch the tab order. 17:10:28 bcampbell: The prop has changed more to allow Flexbox to have the power of doing it either way. 17:10:53 tgraham has joined #css 17:11:07 bcampbell: I have two questions to ask. The first one is if we have anyone that knows today how the backlog is for complaints about the way Mozilla reorders for Flexbox. The bug has been around for a long time and I'd love to know if it's a huge point of contention 17:11:35 +Lea 17:11:43 bcampbell: I'd also like to understand better, and everyone has been good at explaining and helping, but I'm wondering in this holy grail layout, starting tab order in the middle of the content and page, what situation does a user need to do that? 17:12:07 bcampbell: I'm from a standpoint of just peole using a webpage, not people with a disability. In general I'm going to assume this isn't a huge deal. 17:12:07 Is this discussion supposed to be primarily about tab-order, or also (which I thought was more important) about reading order? 17:12:11 q+ 17:12:11 bcampbell: I'll open it there. 17:12:28 glazou: tantek? 17:12:28 ack tan 17:12:32 glazou: dbaron go ahead. 17:12:57 -fantasai 17:12:58 tantek: Sorry, I'm hoping this is one of the areas where directional nav can help such as when there's a scenario when the author... 17:13:04 Tab was very faint when he was trying to talk. 17:13:21 +fantasai 17:13:34 tantek: uses Flexbox to move things and the tab order is non-obvious and not fixable by the browsers, but the author can say I know where things belong 17:13:43 bcampbell: I'm unfamiliar witht he spec lang that you mean. 17:13:59 tantek: Directional-nav prop in CSS3 UI. Let me get a ling. 17:14:00 http://dev.w3.org/csswg/css-ui-3/#nav-dir 17:14:01 http://dev.w3.org/csswg/css-ui/#nav-dir 17:14:03 -BradK 17:14:06 s/ling/link 17:14:19 tantek: Take a look at that and see if it could help from authing side 17:14:28 bcampbell: Interesting. 17:14:31 zakim, mute me 17:14:31 tantek should now be muted 17:14:32 +BradK 17:14:42 I think creating an 'order' property was a mistake, it should have been 'visual-order' if only affects the visual order. 17:14:48 directional navigation is separate from tabbing, yes? 17:15:04 astearns, yes 17:15:15 dbaron: One thing about this discussion was that there was...a lot of the discussion seemed to be about tabbing order, but we've been talking about what is the logical order in which to read the content or do anything other than how yo put it on the screen along the x and y axis 17:16:11 bcampbell: I think what you're referring to is visual order may be diff than logical. The answer I got on that was mainly from Matt King. He was adimant that all screens should follow the pattern, left ot right, top to bottom. That is not necc the visual flow on a screen, but it's the flow screen reader users understand. That's where it starts to get subjective 17:16:29 -Lea 17:16:32 bcampbell: You can manipulte that, but I think that arguement when you get to those who want it, they want it the way its always been. 17:16:46 s/manipulate that/manipulate that via visual hierarchy/ 17:17:00 dbaron: At some point what you said is you want a switch that says if you want things in the order as reorded by order or in the original order? I think order is that switch. 17:17:19 dbaron: The idea of order is the dom should be in the logical order. If you want the visual different you use order to manipulate that. 17:17:21 q+ 17:17:23 Not having tabbing order follow that order that reduces its usefulness. For example, if you pin posts in a forum with order: -1; wouldn't you expect tabbing to respect that? I can't think of any case where you would want tabbing to follow the source order 17:17:47 leaverou, the argument we're making is that you shouldn't be using 'order' for semantic reordering 17:17:58 bcampbell: But if you use order to manipulate the visual orde,r this is the basis of what we're talking about, then you have a tabbing order that jumps everywhere. If the visual is meaningful to the viewer, you need the seq of the tabs to flow in a meaningful direction. 17:18:07 leaverou, which is very clearly stated in the spec, but hasn't been reflected in e.g. your favorite tutorial 17:18:11 dbaron: If it's meaningful, tey shouldn't be using order, tey should do the dom in that order. 17:18:25 +Lea 17:18:31 ChrisL next 17:18:39 bcampbell: In principal I agree, but that isn't how it's being used and it's sort of unreasonable in a larger, agile team enviroment. 17:19:11 you shouldn't be using 'order' for semantic reordering 17:19:15 s/principal/principle/ 17:19:27 q+ 17:19:47 bcampbell: The other part is dev is finding that the speed of CSS to move things is faster. Inside of IBM on high profile apps is that they're using flexbox in any way they can. That has tons of implications and breaks things for those with a disability. Without a siwtch to say we want to change the order and say that we want this to flow in a meaningful way, they need that to get the benifits. 17:20:06 bcampbell: If the idea is to not have those benefits for Flexbox, how do you get people not to mess things up for those with disbailities. 17:20:09 bcampbell: can you provide a URL to one of these high profile app examples that we can look at ? 17:20:50 bcampbell: Can I understand the arguements against adding a switch other than dev should be doing good coding? I think we're stretching CSS and if it's moving in this way with Flex ans Psuedo Elements I think we'll have to change the stance of updating the DOM backwards. 17:20:52 Zakim, ack ChrisL 17:20:52 I see astearns on the speaker queue 17:21:28 ChrisL: fantasai made the point in IRC, you shouldn't use order to mod the semantic order, it's designed for visual. There are things used for alt reading orders. It's all very well to say the content and DOM should be in natural reading order. 17:21:33 bradk I agree and you should say that on the record 17:22:11 ChrisL: Say you have a map and the reading order depends. If you want heights you can tab through that, or shops and tab through that. There isn't only one right order. Reording the DOM all the time also isn't a good answer. 17:22:46 bcampbell: I think what I pinpoint is when you say stuff like should, I get that. I agree that you should do it the right way. I'd like to look at the directional-nav properties 17:23:11 q+ to ask for examples the group can see where 'order' is being apparently misused 17:23:43 bcampbell: What I'm seeing from all sides is that this flexbox tool could be a great poss for what designers do. To go back to all these teams and say no, I guess that is an option, but I'm hearing loud voices that say flexbox is awesome for these things, but a11y says flexbox is killing us. 17:24:26 bcampbell: The simple solution for everyone is to allow people to use flexbox. I'm sort of beating a dead horse. The arguement to add a paramitere, if that's on the table, the arguement is that you shouldn't be adding things in that order. 17:24:33 ??: I have an arguement about adding a switch 17:24:40 s/??/astearns 17:25:19 astearns: Having a flexbox specific switch is a little too narrow. We considered a switch that changes the way pointer properties go in display order rather than dom. We should consider a switch that alows us to change all the order. 17:25:45 s/change all the order/change tab for all the ways we can manipulate display/ 17:25:47 fantasai: no matter what we evangelize, authors *will* use it that way, just like they're using :before and :after for semantic content too. proper accessibility > semantical purity IMO. Also, what *is* non-semantic reordering? Is there any example of that? (sorry if it has been mentioned, I keep dropping) 17:26:03 TabAtkins: Caring about order is a narrow view that doesn't address the problem. There's lots in flexbox that causes problems. We need to address visual order rather than DOM order directly. Maybe that's a CSS prop or maybe it's something for a11y. 17:26:04 q? 17:26:09 ack me 17:26:26 leaverou, consider main vs navigation sidebars. Putting sidebar on left or right is a visual decision that shouldn't affect navigation/speech order 17:26:35 bcampbell: That was part of the problem. If you're changing the visual order it needs to be accessed by the a11y tree. That sounds like a hge undertaking that can take a long time. 17:27:25 TabAtkins: Not nec. That's the answer, there's no way around it. Ign order, you can force direction in upwards or rightwards direction, that reverses your normal flow. The assumption that dom table order will match visual order isn't really valid with advanced layout. 17:28:39 fantasai: I'd worht noting with MQ...If you want to insist that you want it to go in this way in this size for this divice, but if I change device I want a differenet way, that should be a screen reader feature that handles all the different properties. Any way you can get things out of order, if you want that visual order you should have a feature that does that 17:28:47 glazou: bcampbell will you be in Sydney. 17:28:55 bcampbell: Not unless I can make a good arguement for it. 17:29:05 glazou: It seems to me this is an excellent topic for a F2F 17:29:14 zakim, unmute me 17:29:14 tantek should no longer be muted 17:29:15 s/with MQ/with MQ, the visual order can change depending on the device or as I change the width of the browser window/ 17:29:28 bcampbell: I agree. I can work on it, but I doubt it. That's a good question. NYC if we don't have a resolution before. 17:29:53 s/insist that you want it to go in this way/insist that you want it to go strictly left to right top to bottom/ 17:29:55 -fantasai 17:29:59 yes, floats have provided reordering since forever 17:30:14 tantek: We've been able to rearange content in CSS for a long time. This isn't Flexbox in particular, it sounds like you're finding new examples. Links would help us see if it's a new problem or the same old one. Presentation vs DOM problem has been around since CSS1 17:30:19 +fantasai 17:30:30 bcampbell: The question is if Flexbox doesn't give you more flexability, why have it? 17:31:05 tantek: It gives you more flexability. The problem case we've had floats doing this since forever, positioning, tons of ways before flexbox. If we want this semantic order we shouldn't monkey-patch, we should solve. 17:31:10 zakim, who is noisy? 17:31:10 bcampbell: I completely agree. 17:31:21 plinss, listening for 10 seconds I heard sound from the following: [IPcaller] (31%), tantek (50%) 17:31:28 all the other ways we've been able to reorder display have been hacks - using features not meant for layout. Flexbox is the first feature meant for layout, so keeping tab order consistent with the intended layout is a bit more important than before 17:31:30 tantek: I think that's why people are asking for it at a F2F 17:31:33 s/change device I want a differnet way/change device or screen width I want to change the reading order to match that different order/ 17:31:40 glazou: I'm sorry we don't have a conclusion, but I suggest we move on 17:31:50 s/that should be/then that should be/ 17:31:52 bcampbell: This move more forward another step. I'll see about the F2F. Thank you. 17:32:00 Is there any reason why nav-index can't solve this? 17:32:02 glazou: If you can't make Sydeny, lets do it in NYC. 17:32:10 Topic: CSS Grid Layout Issues 17:32:16 Nav-index: visual-order 17:32:17 glazou: Rossen_ you requested a week on this 17:32:18 bradk nav-index was a poor design, and only addresses the tabbing problem 17:32:24 or only *tries* to 17:32:27 Rossen_: I'm okay with it 17:32:33 bradk: using nav-index along with order is a maintenance nightmare 17:32:33 s/that handles all the different properties/that reads the page in strictly visual left to right top to bottom order, and handles all the different ways of repositioning items (including flexbox, grid positioning, floats, abspos, etc.) 17:32:34 er, *tried*. sigh. 17:32:51 glazou: So, who raised the issue? Was it you fantasai ? 17:32:58 Expand nav-index to affect screen readers too then 17:32:59 fantasai: Let me try and remember it. 17:33:08 bradk, astearns: if anything I'd prefer to brainstorm a 'nav-next' property similar syntax as 'nav-up' etc. 17:33:45 we did re-review it one more time internally and are OK with the proposed change 17:33:52 fantasai: The issue was we wanted to updae the spec so space-around and space-between creates space between the grid tracks. That gives us some real functionality and is consistant with how items are thought abou 17:33:54 bradk - now that's crazy nav-index spooky side-effect from a distance stuff! :/ 17:34:03 s/real/useful/ 17:34:16 glazou: So Rossen_ says he agrees. 17:34:22 glazou: objections? 17:34:27 no obj 17:35:18 RESOLVED: align-content and justify-content on grid containers operate on the grid tracks (allows distributing extra space between grid tracks) 17:35:30 glazou: Okay for everyone? 17:35:35 [silence] 17:35:49 Topic: CSS3 UI 17:35:59 I am joining now 17:36:02 give me 1 minute 17:36:08 tantek: Thanks to Florian_away help we've made good progress with resolutions. I would like to pub a draft before the F2F. 17:36:45 Publish early, publish often 17:36:46 tantek: I'd like to both continnue to resolve the issues and anything we can't resolve in time I'll incorporate inline to the spec. I wanted to see if that plan is ammenable to the group and, if so, I'll follow that plan and have something for next Wed 17:37:01 ChrisL: Sounds good. Can I have it by Tuesday for the pub queue. 17:37:10 + +1.479.764.aacc 17:37:17 Zakim, I am aacc 17:37:17 +Florian_away; got it 17:37:23 tantek: I can dot hat, but I wanted to let the group review. If people are okay with what's there and the continued progress, that's fine with me too. 17:37:43 ChrisL: If you have it for Tuesday, I can put it in the queue and if we don't resolve on Wednesday I can pullit out. 17:37:45 tantek: Okay. 17:37:51 glazou: Anyone obj to the publication? 17:37:54 fantasai: I'm in favor 17:38:20 TabAtkins: I think it's reasonable for Florian to be a co-editor with everything he's put into the draft 17:38:29 tantek: I'll make sure Florian is acknowledged 17:38:48 tantek: Florian has put a lot in, but there's been a lot before. I'll give Florian proper acknowledgement. 17:39:18 glazou: To add to what TabAtkins said, I think he should be a co-editor, but we won't spend the rest of the call on it. He's doing major work. Lets go back to the main subject 17:39:25 RESOLVED: New WD of CSS3 UI 17:39:26 I agree it makes sense for Florian to become co-editor. And +1 to publish 17:39:35 Topic: Color & Background Serialization 17:39:44 http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html 17:39:49 glazou: That was from Sebastian Zartner. 17:40:33 I think it makes much more sense at the end, because it’s *underneath* the background image, so it follows the order of the rest of the bg layers 17:40:38 TabAtkins: I can do this. Apperently, currently the grammar for BG puts the bg-color at the end of the last layer. The serialization matches the grammar. Apperently Firebug users prefer it at the front. Are we okay with switching the serialization around? Is that a compat thing? 17:40:55 dbaron: You're putting the color at the beginning of the last ident instead of the end of the last 17:41:01 is there any reason to put it in the beginning besides people asking for it? Did they provide any rationale? 17:41:02 TabAtkins: Yeah. That's what he's asking for. 17:41:23 TabAtkins: I'm reading dbaron comment on it. It sounds like it's to make the code simplier 17:41:47 TabAtkins: I don't care either way. It's a tiny change. fantasai should be the one worrying about accept or reject. 17:42:01 smfr: Any feelings on the compat risk of this? 17:42:05 TabAtkins: No feelings. 17:42:14 dbaron: Are browsers interop now? 17:42:18 TabAtkins: I'm testing Chrome. 17:42:42 Zakim, who is in the call? 17:42:42 I don't understand your question, Florian. 17:43:16 TabAtkins: It's only asking to rearrange the serialization of the last layer. It's not a meaning change. 17:43:38 glazou: The main q isn't how the browsers are serializing. Are there frameworks that parse it and expect the color at the end? 17:43:49 TabAtkins: No idea. Chrome puts the color at the beginning. 17:43:53 smfr: Same with webkit 17:43:59 dbaron: Which implies it's fine the change. 17:44:01 can you share the tc 17:44:23 fantasai: The reason for end is that it's painted at the bottom of the bg layers and the bottom layer is the last with multiple layers. That's the org rational. 17:44:46 TabAtkins: I'm either insane or Chrome has a completely broken serialization of the BG shorthand. It looks like w'ere 100% broken. 17:44:51 TabAtkins: can you share your test case pls? 17:45:13 TabAtkins: This is what I get...I don't know how we completely broke that, but it's crazy times. 17:45:25 dbaron: We didn't get the this. 17:45:50 TabAtkins: So ours is an error. 17:45:59 TabAtkins: It does look like color is first. 17:46:10 -BradK 17:46:15 ??: So there's not that strong dependanies on how this is presented. 17:46:22 glazou: So are there obj to the change? 17:46:30 [silence] 17:46:49 RESOLVED: accept the proposed change for the serialization order 17:46:50 http://lists.w3.org/Archives/Public/www-style/2014Dec/0166.html 17:46:58 Topic: Floats & Initial Letters 17:47:02 -TabAtkins 17:47:37 fantasai: When dauwhe and I worked on initial letters, we discussed a lot of things already, but not how to deal with if there's a float on the first or second line of a paragraph with a two line drop cap 17:47:50 fantasai: We went witht he float clears the initial letter as if the initial letter was a float. 17:48:00 initial letter I18n examples from richard ishida https://www.flickr.com/photos/ishida/sets/72157650248400402/ 17:48:13 fantasai: Other options were float is betweent he initial letter and the rest of the text. Or it fits between initial letter and the rest of the text. 17:48:28 -ChrisL 17:48:39 fantasai: I think there's a reasonable arguement for at least two options. If the float is on the first line and not the second, it's awk no matter what. 17:48:54 fantasai: If you want an image at the beginning you can put it before the para with the initial letter. 17:49:05 aren't such floats usually FOR the initial letter 17:49:08 fantasai: Generally an image is an item on it's own. 17:49:14 fantasai: I wanted to see if there's other feedback 17:49:19 +ChrisL 17:49:55 SteveZ: I sent you another interp on the ML which is to say we should treat the initial letter as defining what the first line or current line is which means the float in the second line would move to the front and up because it's aprt of the initial letter seq 17:50:33 SteveZ: The arguement is the initial letter has moved the line it's shortening so it's part of the same seq. It would give you a fairly reasonable handling of most cases, even with shorter lines 17:50:47 SteveZ: http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html 17:50:53 SimonSapin: I was with you until the last thing. 17:51:06 SteveZ: That would be okay because it would float beneath the initial letter. 17:51:08 s/SimonSapin/???/ 17:51:14 s/SimonSapin/Florian/ 17:51:23 Florian: I thought it would get to float below. 17:51:30 SteveZ: not perfect, but I think better. 17:52:10 fantasai: I think it's an interesting interp. YOu can get yourself into interesting floats because the float might be on the second line, it fits on the second line, so it should shift left and it fits, but then when you move it up it doesn't fit anymore. 17:52:33 SteveZ: You migth need logic like that in Regions, so you make your decisions and if the layout changes, you ignore that. 17:52:39 fantasai: I'd like dbaron opinion. 17:52:49 s/anymore/anymore because the first line is now also shortened/ 17:52:57 floats are hard enough already 17:53:02 Rossen_: Sounds like a lot for doubtful benefits. The layout logic is quite complicated for something that's complex enough. 17:53:10 SteveZ: It's no worse than two floats on one line. 17:53:18 Rossen_: If ther initial letter is a float, yeah. 17:53:20 fantasai: no 17:53:27 we should be moving away from treating the initial letter like a float 17:53:29 SteveZ: The alignmenet is different, but it's basically a float 17:53:54 dbaron meaning ::first-letter ? 17:54:07 tantek, yes 17:54:12 fantasai: Floats depend...you never move a float p. YOu can decide if it fits, as you layout the text you see if it fits on the line and if it does, great, and you shift the position. If it doesn't fit you push to the end of the line and coniue layout. 17:54:55 s/float p/float up/ 17:55:09 fantasai: If you move it up, you can't do that. Here's my line #2, it fits, great, but we have an initial letter so ou have to push it up and then you have to relayout and the float may no longer fit. So if you're not moving up you can layout, but in this case you have a cyclic dependancy. 17:55:25 s/drop-cap/drop-cap-affected/ 17:55:26 yeah 17:55:29 SteveZ: It's no worse than you have to take the length of the lines being shortened byt he drop cap 17:55:37 s/byt he/by the 17:55:55 s/push it up/push it up, shorten the first line/ 17:55:56 tantek: I think we should capture this as an outstanding issue. I think it would also benefit from F2F visual discussion 17:56:02 Florian: Use cases would be good 17:56:04 tantek, we already published 17:56:20 dauwhe: I haven't seen an example where there's this possible interaction so I want to do a search for that. 17:56:24 I want to note that if you want to put a float in the top left corner, you can already do that 17:56:34 Florian: I think the proposal is sane, but there might be better. 17:56:37 Just put the float before the paragraph 17:56:44 dauwhe: I also think initial letter is different than a float. 17:57:00 tantek: I also see Rossen_ concerns about adding complexity without real world examples. 17:57:25 dbaron: What we need to solve is lets not have cases where the spec says there should be a result that's unachieable, but elsewise I agree. 17:57:36 tantek: I think with an addition that we find that out from impl experience. 17:57:41 dbaron: We already know that it is. 17:57:41 s/I think the proposal is sane, but there might be better./I think Steve's proposal is sane, but it's harder, and to see if it is worth solving, I'd like to see use cases. Otherwise, Fantasai's solution is simpler, and also sane./ 17:58:09 My proposal is documented in: http://lists.w3.org/Archives/Public/www-style/2014Dec/0277.html 17:58:51 fantasai: To summerize. I think your idea is interesting, but it intro a compexity in float that deosn't already exist. It also can create a loop. I think this is a bit of an edge case. Lastly I agree with Rossen_ that this doesn't seem like a really important thing to solve. That complexity doesn't seem to be worth dealing with for such an edge case that is rare in practice. 17:59:00 I think the simple solution is saying that a float that's not in the first line and intersects (i.e., on the same side as) a drop cap clears below the drop cap 17:59:04 fantasai: That's why I think you have an interesting idea, but not a good idea for us to go with. 17:59:15 tantek: I don't know which is better because there's a lack of examples 17:59:18 dbaron, that's exactly the proposal dauwhe and I have 17:59:28 SteveZ: I thought we were waiting to the F2F to solve 17:59:35 dauwhe: I can make diagrams. Cool. 17:59:36 diagrams++ 17:59:45 fantasai: Anyone want to presue SteveZ case? 17:59:55 let's wait until the ftf to decide, including steve's proposal 17:59:58 Florian: Without exmples, no, but if he has examples maybe 18:00:05 tantek: I can't answer w/o examples 18:00:14 s/presue/pursue/ 18:00:17 SteveZ: I also have to understand putting the float before the dropcap a bit better. 18:00:18

Drop cap paragraph/p> 18:00:23 img { float: left; 18:00:34 Done. Puts it in top left corner of paragraph 18:00:36 glazou: We're at the top of the hour 18:00:37 (Also seems asymmetric to me: you might to move up when floating left, but probably not when flowtimnmg right...) 18:01:21 Florian: Quest question on CSS3 UI. There was one resolution that we made that was objected to. If we pub without changes that's fine, but I don't want to make edits and change them. 18:01:22 -[Bloomberg] 18:01:25 tantek: Issue 40? 18:01:38 Florian: No. If we publish, publish as is and don't roll in the edits. 18:01:53 I cannot hear you 18:02:00 tantek: I can capture the obj. I'd rather have the edits in and caputure the concesus and the objection 18:02:14 this is about Issue 47 resize (I think) 18:02:20 it is about issue 47 18:02:22 need URL to the objection 18:02:28 it's in the wiki 18:02:32 great. thanks. 18:02:34 glazou: I'm lost. What are you waiting for tantek 18:02:36 tantek: Nothing. 18:02:42 glazou: Okay. 18:02:50 -dbaron 18:02:51 -ChrisL 18:02:53 -hober 18:02:54 -Stearns 18:02:54 -glazou 18:02:56 -SteveZ 18:02:56 -dauwhe 18:02:57 glazou: That's it for today. Talk to you next week and thank you very much. 18:02:58 -Florian_away 18:02:58 -[IPcaller] 18:02:58 -tantek 18:02:58 -smfr 18:02:58 -??P62 18:02:59 -fantasai 18:02:59 -plinss 18:03:00 -??P44 18:03:00 -[IPcaller.a] 18:03:02 -kwkbtr 18:03:03 -SimonSapin 18:03:03 smfr has left #css 18:03:03 -koji 18:03:04 -[Microsoft] 18:03:04 -Lea 18:03:06 -[IPcaller.aa] 18:03:06 -dael 18:03:07 bye 18:03:08 -MikeMiller 18:03:11 Objection was from Tab and smfr. 18:03:13 - +1.631.398.aabb 18:03:13 Style_CSS FP()12:00PM has ended 18:03:13 Attendees were dael, glazou, plinss, SimonSapin, dauwhe, bcampbell, Lea, MikeMiller, kwkbtr, BradK, [Bloomberg], Stearns, fantasai, hober, SteveZ, smfr, Rossen_, dbaron, 18:03:13 ... +1.281.305.aaaa, TabAtkins, [IPcaller], ChrisL, tantek, +1.631.398.aabb, koji, +1.479.764.aacc, Florian_away 18:03:43 tgraham has left #css 18:05:50 kwkbtr has left #css 18:14:50 mib_xmxjd8 has joined #css 18:16:33 Florian has joined #css 18:36:31 svillar has joined #css 18:38:48 zcorpan has joined #css 18:42:48 dauwhe has joined #css 19:01:15 bradk has joined #css 19:16:12 bradk has joined #css 19:17:07 Florian has joined #css 19:19:54 dauwhe has joined #css 19:21:31 dauwhe_ has joined #css 19:28:15 dauwhe has joined #css 19:35:42 bradk has joined #css 19:43:35 bradk has joined #css 19:44:01 Zakim has left #css 19:50:50 Florian has joined #css 20:57:12 TabAtkins: Values & Units says "UAs should support reasonably useful ranges and precisions" about numeric data types, but what to do on overflow is apparently undefined 20:57:26 I think it’d be useful to specify something like "clamp, do not wrap" 20:57:49 "… if the supported range is finite" 20:59:02 SimonSapin: spoken like a true rust developer, always with safety in mind. I'm a C++ guy, and I'm fine with undefined behavior :P 21:01:48 Florian: integer overflow does not affect memory safety :) I’m rather thinking that `z-index: 3000000000` should not wrap to -1294967296 21:02:31 jokes aside, as long as the browser does not crash, I don't mind if wrapping happens instead of clamping. If the values used are so large the browser can't handle them, the intended layout will be messed up anyway. I don't know if clamp messes up less badly than wrap, but I am not convinced I am intersted in the performance trade off needed to make sure you can one fallback over the other 21:03:36 dauwhe has joined #css 21:07:26 Integer overflow does not affect memory safety, but strange values might crash the layout system. That must be avoided but I don't mind if the layout is messed up 21:13:04 nikos has joined #css 21:16:57 bradk has joined #css 21:21:54 If your layout code crashes with large input values, the correct fix is not to make sure input values are small :) 21:28:52 "Doctor, it hurts when I do this" 21:29:45 dauwhe has joined #css 21:40:52 gsnedders: clamping z-index also means that different values can end up at the same max clamped value, and so stack differently than if the max was higher 21:41:10 (it’s still better than wrapping) 21:41:13 SimonSapin: yeah, but it's probably a better experience in general 21:41:34 idk, I mean wrapping could end up with 98, 99, 100 instead of crazy_value, crazy_value + 1, etc. 21:41:40 which might work better 21:41:46 but only in the cases where they're thus stacked 21:42:03 data for crazy value usage, plz 21:42:15 except it’s apparently more often crazy_value^2 than crazy_value + 1 21:42:37 http://adspecs.aol.com/technical-guidelines/z-index-guidelines 21:42:50 (I’m only slightly exaggerating) 21:42:57 still seems like wrapping may actually give the better advice then, bleh. why's there no solution that always works best? :) 21:43:08 (well, there is, arbitrarily-sized ints, but…) 21:43:14 bignum all the things! 21:47:14 If I wanted to be evil I'd suggest scaling down from max_seen_in_AST to MAX_INT. 21:47:19 But I'm not that evil. 21:47:25 Mostly. 21:47:55 dynamic updates would be fun 21:48:30 SimonSapin: This is what makes it truly evil instead of "kinda evil". 21:48:48 bradk has joined #css 21:58:44 Florian: No, wrapping is terribad, and there's no excuse for it. Clamping is also bad, but when you can't avoid it, it at least comes close to the author's intent, and is thus more likely to be less broken. 22:24:21 dauwhe has joined #css 22:27:34 thinkxl_ has joined #css 23:13:28 lajava has joined #css 23:25:40 tantek has joined #css 23:55:57 jdaggett has joined #css