00:00:26 SteveZ has joined #css 00:01:32 shans_ has joined #css 00:01:50 glazou has joined #css 00:01:54 https://attendee.gotowebinar.com/register/5412617925660825345 00:02:29 plinss has changed the topic to: http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345 00:02:30 plinss has changed the topic to: http://wiki.csswg.org/planning/seoul-2014#agenda - https://attendee.gotowebinar.com/register/5412617925660825345 00:04:23 andrey has joined #css 00:04:34 murakami has joined #css 00:06:49 jh_hong has joined #css 00:15:02 dbaron has joined #css 00:15:43 glaz: Let's start 00:15:56 glaz: WE have krit calling in and the first is CSS masking 00:16:11 clilley has joined #css 00:16:14 http://dev.w3.org/fxtf/css-masking-1/#masking 00:16:22 krit: CSS Masking had some changes since last WD one was that we now have posistion masking support 00:16:35 http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite 00:16:41 krit: To make this possible it was an issue how to combine diff mask layers and I introduced mask composite prop 00:16:54 abinader has joined #css 00:17:00 krit: Which is using composite operators to make it easier to use instead of using whole composite mode 00:17:14 krit: The mask-source-type which needed to be renamed to mask-type 00:17:30 krit: Therefore it all needs to be renamed since webkit and Blink are shipping 00:17:37 krit: I've called it mask-operation 00:17:56 krit: mask-type is mask-operation and mask-box-type is mask-box-operation 00:18:09 krit: No change requests in 2 weeks, so is it possible to pub a new LC? 00:18:14 krit: It might be last LC 00:18:17 glaz: Thoughts? 00:18:49 fantasai: Thre was one issue that was raised with layers about grouping the operations and combining the images and the reason we defered we didn't know how to do syntax to do properties. 00:19:15 Rossen_ has joined #css 00:19:28 fantasai: [missed] 00:19:54 krit: Grouping isn't important at the moment but is interesting. We can think about that at backgrounds and borders, but for now I think we're fine with not having grouping 00:20:02 krit: We can introduce it in backgrounds and borders. 00:20:20 TabAtkins: I'm fine with that. Whatever solution is in B&B will be fine 00:20:32 fantasai: If we do an expression language that will be different from ones that map. 00:20:37 TabAtkins: And in the future we can have both. 00:20:52 krit: Any other requests or can we go to LC? 00:20:57 glaz: Comments? 00:21:05 adenilson has joined #css 00:21:10 glaz: TabAtkins is fine, I'm fine, clilley, Rossen_ 00:21:19 RESOLVED: LC for CSS Masking 00:21:29 clilley: Can you get the doc ready today so I can req pub on thursday? 00:21:34 krit: Next week? 00:21:36 clilley: This week 00:21:39 krit: Sure. 00:21:49 krit: Do you think you can get it on Thursday? 00:21:59 clilley: Yeah. As long as it's ready we can pub on Thursday. 00:22:03 krit: Yeah 00:22:09 fantasai: What was the mask type change? 00:22:21 fantasai: is it in the ED yet? 00:22:29 krit: For some reason it wasn't input. I looked online and all that's missing is the change from mask-source-type 00:22:30 plh has joined #css 00:22:36 krit: And the mask-mode 00:22:41 krit: And mask-box-layout 00:22:58 krit: I'm not sure if I put it on the wrong branch, but it needs to be changed first 00:23:07 fantasai: Is there a clearer name than mask-mode? 00:23:18 TabAtkins: That's what we used in SVG and I can't come up with better. 00:23:20 fantasai: Okay. 00:23:28 fantasai: Where is it in SVG? 00:23:31 TabAtkins: Mask element 00:23:38 clilley: So you can't rename it 00:23:44 fantasai: I'm happy if it matches something 00:23:55 fantasai: It's otherwise very vague but... 00:24:01 krit: So you're fine with mask-mode? 00:24:07 fantasai: If it matches SVG yes 00:24:17 krit: There isn't in mask-mode, it was interduced in SVG 00:24:29 TabAtkins: There's an attribute. There's a same named thing so there's consisstancy 00:24:38 krit: We use mode quite often. That's true. 00:25:01 krit: Any better suggestions or is it fine? 00:25:10 fantasai: Were is mode? I was looking at masking module 00:25:17 http://dev.w3.org/fxtf/filters/ 00:25:27 krit: It is in the spec linked above. There's a lot of use of mode. 00:25:39 krit: Composate operator 00:25:49 fantasai: If it means the same thing, but it doesn't? 00:25:58 fantasai: It's used for blending, not mask interpretation. 00:26:02 krit: True. 00:26:14 fantasai: And Masking will need blend modes at some point? 00:26:16 krit: No. 00:26:24 clilley: He's arguing we use mode for that sort of thing 00:26:32 fantasai: Are we going to add blending modes to masking? 00:26:44 krit: For background it's called background-blend-mode so it's explicit 00:26:53 astearns: If we do we can call them blenders. 00:26:58 TabAtkins: Which is clear at that point. 00:27:05 s/blenders/blendmodes/ 00:27:05 fantasai: The blend mode is clear. 00:27:25 fantasai: Okay. I'm not happy it matches something else, but I don't have a better idea. 00:27:34 fantasai: If it concept matched that would be awesome 00:27:41 clilley: Do we have a better name or can we move on? 00:27:44 fantasai: We can move on 00:27:57 krit: The next one? 00:28:03 glaz: That's all for masking? Okay. 00:28:08 Topic: Geometry Interfaces 00:28:12 http://dev.w3.org/fxtf/geometry/ 00:28:36 krit: We worked on the geometry interface with is the dom-point dom-matrix etc that we had in different pub before. 00:28:41 s/awesome/matching a different concept is less awesome/ 00:28:59 krit: They had been in CSSOM view and this is combination of the interface that we actually use in OM and SVG 00:29:08 krit: There have been some slight changes to DomMatrix. 00:29:22 http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-isidentity 00:29:34 krit: There had been long discussions on the ML and I added ident to the dom matrix interface that checks if the matrix is an identity transformer 00:29:37 krit: There are some issue 00:29:51 http://dev.w3.org/fxtf/geometry/#issue-5712ca41 00:29:57 krit: One is for the DOMMatrix constructor. One issue I'd like to resolve is issue 2 (link) 00:30:09 krit: This is where DOM Matrix takes a string that can be a translater. 00:30:26 krit: your document lacks a normative reference to WebIDL please 00:30:34 krit: The translation y ou can use in CSS can be passed into the string because you can pass the start and generate the DOM Matrix 00:30:48 krit: SCG uses the transform attr and it has less restrictions. It doesn't req units 00:31:12 s/SCG/SVG/ 00:31:27 krit: In SVG we have the transform attr and it has less rest. It doesn't req unit and it has white spaces between function name and the breaks. 00:31:39 krit: I would suggest that we allow transform attr syntax here. 00:31:47 krit: It allows CSS syntax and SVG syntax 00:32:10 s/breaks/braces/ 00:32:17 krit: The SVG syntax wll be along for a long time and use of SVG syntax would allow CSS syntax to work. The SVG group wanted approval from CSS 00:32:31 TabAtkins: I'm fine with unitless, but I don't like the let's have it be an ident plus paran 00:32:42 plh has joined #css 00:32:42 TabAtkins: It's a strange artifact and doesn't nee to be maintained 00:32:50 krit: I haven't seen it but it's in theory allowed 00:33:04 TabAtkins: I don't think we need to spread that aspect further, but unitless if fine 00:33:21 krit: We would need a third syntax. It creats a string from trnasform and passes to Matrix 00:33:30 TabAtkins: And if you're not weirf it'll work 00:33:41 krit: I don't think that it's a good idea to have a thurd syntax 00:34:06 TabAtkins: It's only 3rd because it accepts the unitless SG thing when CSS ingeneral doesn't do that. That's the only seperation and I don't think that's sig. difference 00:34:16 krit: User agents have to impl three diff for very little gain 00:34:24 krit: It gets you closer to CSS without whitespaces 00:34:31 krit: I'm not sure if that ain is good enough 00:34:42 TabAtkins: Whenever you do the unitless is that intp as px? 00:34:45 krit: yes. 00:35:12 TabAtkins: So it's accepting the wierd or req to use pix, I'm fine with sticking to CSS, but don't see a reason. If we have to do one or another, I want CSS. 00:35:18 clilley: Unitless doesn't mean px always 00:35:25 TabAtkins: But it has to be understandable. 00:35:38 clilley: If I do 0.3 by 0.3 it can be huge. 00:35:49 krit: If clilley Is talking about user units, it's always 1 px 00:35:51 clilley: No it's not 00:35:53 krit: It is 00:36:09 krit: It means 1px sn't always 1pixel when it's transform 00:36:17 krit: It depends on what you mean. 00:37:01 clilley: So 1px can be 3000 divice pixals. Most people if they say the want a 1px font they don't expect huge. Forcing people to write px isn't useful. For a lot of content people that aren't used to scalable, they set to fixed and use px, but that's the only way 00:37:11 krit: I agree on the behviour. Do we want CSS, SVG, or a mix 00:37:20 clilley: Does mix mean the superset? 00:37:26 krit: SVG is the superset 00:37:38 TabAtkins: CSS syntax that accepts numbers that are interp as px units 00:37:55 krit: How would you do with having CSS syntax w/o units 00:38:05 TabAtkins: Have them set numbers that are interp as pixal units. 00:38:16 krit: Um. 00:38:32 s/the only/not the only/ 00:38:45 krit: I hope we can get rid of whitespace in SVG. I didn't see the behviour in use so maybe it's fine, but in this case I'd change SCG transform syntax. 00:38:57 krit: I'm fine with keeping this issue open unit SVG transform is resolved 00:39:11 krit: I'd like to pub a FPWD with these issues and we can compare. 00:39:17 TabAtkins: absolutely publish, yeah. 00:39:23 glaz: Other op? 00:39:43 RESOLVED: Publish FPWD 00:39:51 clilley: plh, canw e pub FPWD? 00:39:54 plh: Yes. 00:40:25 plinss: I q. In shenshen we got a bunch of feedback that isn't in here. Is that rejected, not considered? 00:40:29 s/feedback/feedback from Alex Russell/ 00:40:33 koji has joined #css 00:40:34 s/shenshen/Shenzhen/ 00:40:35 krit: So waht about Alex Russell? 00:40:47 krit: I tried to ping him and he didn't respond? 00:40:53 clilley: What was the subs. of your ping? 00:41:31 krit: I summerized the promises we have in CSS WG with the interface and he was suggesting growth instead of new itnerface. I asked him to comment on the ML and summerize his opinion and that from others. He didn't respond or comment on the ML 00:41:36 plinss: I'll follow up with him. 00:41:48 krit: I talked with Mozilla and he feels we should have the new interface. 00:41:57 plinss: Okay 00:42:09 glaz: So are we done with this topic? 00:42:16 krit: Yeah. 00:42:25 Topic: Test Results Script 00:43:02 clilley: I was winching with our web and communications team where they wanted us to take outthe paragraph markers. We got to leave them, but I compained about taking out this script that gave a nice summary of the test suite 00:43:37 clilley: Without it the pages aren't as useful and the reaction was surprising positive. I went a few rounds of what we would need to keep this and one was accessability and I proved this doens't interfear with that 00:43:48 clilley: The next was does this make the doc non archiaval. I said no. 00:43:59 clilley: And can you jsut inline the results, no because we want it to be in real time. 00:44:13 clilley: The one sticking point is that the script isn't hosted at w3c.org 00:44:43 clilley: I said I'd talk about this. Since then someone popped up witha bunch of hand waving where it would let the data live where it does and the script can be on w3c.org 00:44:54 plinss: It's fine by me, it makes it harder if I update the script, but that's okay. 00:45:08 clilley: Will you update in a way that breakst he API? 00:45:20 plinss: I wrote it a long time ago and the API has only had one update since. 00:45:41 plinss: I intent to get back in in the next few weeks and let me do that and then you can have a fairly stable script 00:45:47 clilley: Thank you. I think it's very good. 00:46:05 plinss: It doesn't link to the style sheet. Do you want that piece too and have it live on the w3c server? 00:46:08 plinss: That's doable 00:46:31 plh: Do you think about how you do a new ap you need to do the script. Is that painful and do we want to try a new location? 00:47:00 clilley: All the thing for a pub need to be underneath. I think it's worth pushing on a well known location where it's installed and point there. It also solves the version problem. 00:47:05 clilley: That's worth pushing for. 00:47:09 SteveZ: I unuted you 00:47:11 unmuted 00:47:14 plh: You can still share it across spec. 00:47:25 plh: As long as you won't ever break it, that would be nice. 00:47:45 clilley: If it's instearting a style sheet link through the script, that needs to come in before the final offical sheet. 00:48:42 clilley: So for next step we need to refactor and stabilize? 00:48:49 plinss: Yeah, let me have another pass to stabilite 00:48:56 plh: Then we need to deal with bikeshead 00:49:04 plinss: Yes, bikeshed is making those links. 00:49:17 plinss: So we'll want to use our on version of the script on the drafts? 00:49:30 clilley: It seems more efficent if the script is together. If not, let's shift. 00:49:37 TabAtkins: It's the browser making the requests. 00:49:43 clilley: Then we'll use the same version for all. 00:49:56 clilley: Any origan problems if some is on dev and some is on www 00:49:59 TabAtkins: Shouldn't 00:50:09 clilley: Okay. The ball is in plinss court. 00:50:23 plinss: I recall an issue with TR where it doesn't exist? 00:50:31 clilley: I believe they're serving HPS. 00:50:37 plh: We don't use it for TR commands. 00:50:53 plinss: If people are doing the FTP for it it would be shipping wrong 00:50:58 plh: I don't believe people are. 00:51:04 plinss: But we can do it on dev 00:51:23 plh: It's possible people could access it but since the link is related the script will be through HTTPS as well 00:51:29 plinss: I was think of issues a while ago. 00:51:34 plh: Testing will be needed 00:51:40 plinss: Okay. We're fine. 00:51:53 plh: I tried to access through HTTPS and got redirected 00:51:59 plinss: And dev isn't doing HTTPS 00:52:12 plinss: I think bikeshead has a sceme for that. I think we're okay. 00:52:19 plinss: Okay. 00:52:37 s/has a sceme/uses scheme relative urls/ 00:52:41 Topic: Selectors 4 00:53:09 fantasai: There's been a lot of text changes so I need to review and we'll want another WD with that 00:53:33 fantasai: I think what we needf rom the WG is opinions on what's this level vs the next. Right now the draft has a cut of what we think goes in this level 00:53:57 glaz: So nothing to do really 00:54:02 fantasai: I don't think so 00:54:08 http://dev.w3.org/csswg/selectors4/ 00:54:13 glaz: If you have anything to discuss on 4 now is the time. 00:54:24 glaz: We need time to review the added text 00:54:31 TabAtkins: And I have more to rewrite 00:54:52 glaz: If we close this now it means we've used the morning's agenda. CSS3 text is on this afternoon for SteveZ and Bert 00:54:59 glaz: We don't have Bert on the call 00:55:19 TabAtkins: I had a 5 or 10 minute topic from last night. 00:55:44 TabAtkins: At least year's blink con one of the bloomburg guys that does blackberry asked me to prop a value for text overflowt hat does a fade over the edge 00:55:57 TabAtkins: So when the thing overflows you don't kill characters for an elip. 00:56:07 TabAtkins: The name they're using is -blackberry-fade. 00:56:18 TabAtkins: I think text-overflow-fade is good 00:56:24 hober: Is the fade config? 00:56:25 TabAtkins: Yeah. 00:56:36 s/text-overflow-fade/text-overflow: fade/ 00:56:47 plinss: My concern is that is there a new paradim next year. Can we do a generic way to handle overflow markers where someone could use a fade. 00:56:50 lmclister has joined #css 00:57:00 hober: Link how I do a fade from 0k black to transparent black 00:57:16 plinss: My point is can we get creative and come up with ::voverflow or something 00:57:25 clilley: Where the overflow defines and area that you can style. 00:57:32 plinss: And the default is elipsis 00:57:40 glaz: Can we just add a value for that effect? 00:57:58 TabAtkins: If we had a way to config, given that we don't have a way to composite jsut the content there's no way... 00:58:00 hober: masking? 00:58:10 fantasai: That get's BG. You just want ttext to fade. 00:58:15 fantasai: The easiest is a keyword 00:58:28 plinss: But when we want a diff effect, do we need another kyword 00:58:37 TabAtkins: Well if it's similar we jsut tack on. 00:58:46 TabAtkins: The obvious is eventually do a pseudo when it's needed 00:59:11 krit mentioned adding an image 00:59:13 Rossen_: One common req we get becides layout is that people wnat to use it for bubble or whatever have you so we need to be able to attach other behavious 00:59:18 fantasai: Yeah. 00:59:24 TabAtkins: and that's true for block overflow 00:59:47 Rossen_: And if we don't know which period is where the marker is more than just a layout. Evenually we put the power in the designer's hands. 00:59:50 TabAtkins: I agree. 00:59:56 hober: I think that's a better long term way 01:00:16 TabAtkins: None of that solves that there is no was in CSS without new abilities to do a lets fade the content over some fraction 01:00:21 Rossen_: Well what we talked about 01:00:33 TabAtkins: We have conceptiual framework, but nothing that can be extended 01:00:51 krit: Is it poss that instead of one keyword we have the image and that uses mask That give more freedom 01:01:03 TabAtkins: Are there use cases for fading with an arbitratry image? 01:01:20 krit: I can image it. there are different ways to indicate and that's platform dependant 01:01:29 TabAtkins: You mean adding an image, yes. 01:01:38 clilley: If you use the image and use lumanence. 01:01:49 TabAtkins: You can't fade the content via the masking of another elemnt 01:01:55 plinss: It seems we should fix that 01:02:13 krit: You can fade and mask just the test. if you use text overflow and just use the image it's not an issue 01:02:20 TabAtkins: Maps instead of displays? 01:02:28 Rossen_: And you large is your image, krit? 01:02:34 krit: You have to define that 01:02:55 Rossen_: In the case of text overflow what you would do when you layout the last word you would have to work your way backwards to fine the elipsis 01:03:18 Rossen_: Actual size is det. at layout and if you're just doing one generic image, how do you align 01:03:23 krit: You can define it with gradent. 01:03:47 s/You can define it with gradient./How would you define the offset for gradients?/ 01:03:59 TabAtkins: I'm still not clear krit I think you're suggesting we can spec an image instead of a string and have an option for use this image as a mask instead of as an image. Is that correct? 01:04:20 yes 01:04:24 krit: Yes 01:05:01 TabAtkins: That seems weird to me because it feels like jamming a special behaviour in and if we're introducing something more than keyword it should be more general so that you can use an element as the mask of another element 01:05:20 fantasai: Do we want a pseudo for something like ::content and all you can apply is masking/filters. As a general thing. 01:05:39 TabAtkins: no, we don't want that b/c...well, it won't solve the overflow b/c you can't tell what side the overflow is on. 01:05:48 plinss: Yeah, that's orthaganal to the question 01:05:57 fantasai: Can overflow take 2 values? 01:05:58 TabAtkins: Yes 01:06:12 fantasai: If we add image we can do that. If we let the image be a mask that solves it 01:06:29 TabAtkins: But saying you can do that for text overflow, that seems oddly specfic way of generalization. 01:06:48 TabAtkins: That's an odd place to stop. Either design something that works clearly or design the general facility 01:06:55 fantasai: I'm in favor of the keyword regardless. 01:07:09 fantasai: I would suggest we add fade to text-overflow 01:07:35 fantasai: We'll need a more general solution that has event handling and full styling, but even if we had that it would be awkward for this simple, straigthforward case 01:07:47 hober: You think a single keyword would be enough for most people's design? 01:07:58 TabAtkins: For most people, but allowing to passa length wouldn't be a problem 01:08:12 hober: People who have gone to the effort already are they people that was a level of control 01:08:24 glaz: The fade length is likely different on a small screen. 01:08:29 TabAtkins: I've seen some long fades. 01:08:38 fantasai: So you want to use percentage length 01:08:43 TabAtkins: percentages and lengths 01:08:56 glaz: Adding length doesn't really fit. fade should be functional 01:09:03 TabAtkins: As a keyword and a function it should take a length 01:09:08 hober: Words for me 01:09:11 glaz: Me too 01:09:16 s/Words/Works/ 01:09:20 TabAtkins: We can discuss the greater generalization later 01:09:32 glaz: I've seen a text overflow with flat text and rounding 01:09:37 plinss: It's a transform, right? 01:09:43 glaz: It's a transform. 01:09:57 plinss: People will want to do transforms. If we give them one we want a lot. 01:10:10 hober: And if we get feedback it's good. 01:10:30 plinss: I don't mind the keyword, I want to explain that the keyword creates these things and you can override that by adding these lines of CSS 01:10:44 hober: And you can describe the pseudo as something you can work toward and get at laters 01:10:54 plinss: Let's explain in terms of our primitives 01:11:16 fantasai: I think adding the keyword makes sense and we should work o nthe general solution. And having these use cases will help us get there coreectly. 01:11:28 TabAtkins: I think it's the inside pseudo hixie tried forever ago 01:11:33 fantasai: I don't think so. 01:12:01 fantasai: We could spend the morning trying to figure out this problem. People want control over overflow, they want elipsis in the direction of the block 01:12:10 fantasai: WE always find that solving it takes time and we have time 01:12:20 Rossen_: WE can look into use content-outflow 01:12:33 Rossen_: ::after 01:12:40 s/content-outflow/::after { content: ... }/ 01:12:46 fantasai: I don't think we want to do that 01:12:54 plinss: How does that interact witht he overflow 01:13:02 fantasai: It's part of the text alignmenet. 01:13:11 hober: It's the last part of the content 01:13:13 s/alignment/content/ 01:13:21 plinss: So that you have content after can cause the elipsis 01:13:22 fantasai^: that gets elided 01:13:49 fantasai: If you haev a long bit of ::after content a lot will get elipsised, but if it's short... 01:13:50 *ellipsized 01:14:11 dbaron: What needs solvign for block overflow? 01:14:28 fantasai: 1 is to have the block overflow inline and 2 is to have it after last line 01:14:29 ellipsizationnized 01:14:34 dbaron: I've seen the latter as fades. 01:14:46 TabAtkins: When in JS it'll be centered on the last line. 01:15:02 TabAtkins: The other req would be to be able to recieve click events. 01:15:08 fantasai: We need a way of defining events 01:15:16 dbaron: In some cases you only want click in some places. 01:15:43 fantasai: I propose we take a break, get the awesome green board, and start doing examples. 01:15:56 glaz: I don't think the greenboard will get in the elevator. 01:16:27 [break = 15min] 01:32:01 jh_hong has joined #css 01:34:13 dauwhe_ has joined #css 01:39:23 myakura has joined #css 01:42:39 tantek has joined #css 01:43:29
01:43:29

Consider a shape that is clipped by a clipping path applied to an ancestor:

01:43:29 
<g clip-path="circle()">
01:43:29      <path id="shape" d="M0,0 L10,10, L 20,0 z"/>
01:43:29  </g>
01:43:29
01:43:29

The shape is referenced by a 'use' element:

01:43:29 
<use xlink:href="#shape"/>
01:43:30
01:43:30

The geometry of the shape is not influenced by the circular clipping path.

01:43:30
01:43:35 oops 01:43:39 https://www.irccloud.com/pastebin/s2nE2bXp 01:43:55 gets to 01:43:59 https://www.irccloud.com/pastebin/CeY6YX28 01:45:22 Hm, shouldn't be doing that. I'll investigate. 01:46:30 TabAtkins: It seems not to do it if a follows after 01:49:58 The new Markdown code is still a little bit buggy, sorry. 01:52:32 https://www.irccloud.com/pastebin/cj4sRSA8 01:52:46 TabAtkins: that is another error I get from the validator 01:54:09 krit: I can't reproduce your first error. 01:54:39 That validator issue is easy to diagnose. I think I fixed that yesterday. 01:54:47 Have you updated Bikeshed recently? 01:54:57 TabAtkins: happens in example 3 http://dev.w3.org/fxtf/css-masking-1/#clipping-paths 01:55:01 TabAtkins: yes 01:57:30 krit: Huh. I grabbed your source code from Masking and just ran it through bikeshed, and it does the right thing. 01:57:43 Got some context around as well, just in case. 01:57:57 TabAtkins: di you run make, or bikeshed? 01:58:33 I looked up Overview.src.html from my browser, found the example, copied out a chunk of it into a test document. 01:58:38 Then ran Bikeshed. 02:01:16 TabAtkins: hm, looks like i didn't run latest build 02:01:25 TabAtkins: issue 1 resolved :) 02:01:39 hahaha I KNEW IT 02:01:56 The other one looks like an unquoted title, which definitely happened before I fixed the problem. 02:02:34 I presume you have title="nonzero value" in your source? 02:03:03 TabAtkins:

The following drawing illustrates the nonzero rule:

02:03:38 Oh! Use like a normal person. 02:03:43 I don't do a lot of the fixup on . 02:04:19 Support for is pretty much just to appease fantasai 02:04:26 TabAtkins: just freaks out the SVG preprocessor I still have to use 02:04:52 to appease fantas ? 02:05:13 TabAtkins: FATAL ERROR: No 'value' refs found for 'nonzero'. 02:05:30 TabAtkins: --> 02:06:18 Yeah, go look at your . Bikeshed doesn't know it's a valuedef. 02:07:00 TabAtkins: so nonzero ? 02:08:01 Private discussion on how to resolve logical box properties with physical ones between fantasai and rossen. 02:08:05 The rest of us are on break. 02:08:12 tx 02:08:15 And me and krit are doing stuff. 02:08:24 doing = good 02:08:31 ftf time awesome for that. 02:08:56 krit: Either nonzero, or put
and then just plain 02:09:24 krit: rtfm ^_^ 02:09:30 TabAtkins: fixed now. Thanks! 02:12:02 zcorpan has joined #css 02:19:53 Glenn Adams, Rossen Atanassov, Tab Atkins, David Baron, Adenilson Cavalcanti, Dave Cramer, Bruno de Oliveira Abinader, Elika Etemad, Daniel Glazman, Dongwoo Joshua Im, Koji Ishii, Dael Jackson, Philippe Le Hégaret, Chris Lilley, Peter Linss, Shinyu Murakami, Edward O'Connor, Simon Pieters, Andrey Rybka, Alan Stearns, Shane Stephens, Jet Villegas + 5 observers 02:20:29 Phone: krit, SteveZ, liam, Bert (dael - check at EoD) 02:21:06 myakura_ has joined #css 02:32:06 plinss: glazou: plh and i added two suggested topics at http://wiki.csswg.org/planning/seoul-2014#wednesday 02:33:57 fantasai: First is logical properties in general. There's 4 impl. Webkit Microsoft Mozilla and AH and there's no spec. 02:34:03 zcorpan: noted 02:34:09 fantasai: When I wrote it the WG said I wasn't allowed to (4 years ago) 02:34:47 fantasai: We're proposing the take that spec and resurect it seperatly and publish it as an ED with a FPWD shortly after 02:35:14 fantasai: Editors would be me and Rossen_ with murakami ghost editing. 02:35:38 harayama has joined #css 02:35:40 fantasai: Further commetns? 02:35:44 hober: It's a great idea. do it. 02:35:57 dbaron: I may have comments when it exists, but I'm happy to have it. 02:36:13 hober: If you check the UA stylesheet for right and left we clearly need it. 02:36:24 Rossen_: There's enough web content that it demands having this. 02:36:33 Rossen_: We don't want to go into technical now. 02:36:56 RESOLVED: ED of CSS Logical Properties 02:37:49 lmclister has joined #css 02:37:56 dauwhe_: Should we try and use logical prop when writing specs? 02:37:59 jhh has joined #css 02:38:09 fantasai: I think all future drafts of layout should have logical and physical spec'ed together. 02:38:32 Rossen_: There's 2 exceptions, B&B and exclussions. It was demanded that we name all the properties from the start 02:38:39 hober: So exclussions is only logical 02:38:44 TabAtkins: Well we didn't have a way to mix. 02:39:07 hober: So where webkit has phsycial and logical, the shorthand is physical, so are there exclusion shorthands that are logical? 02:39:27 Rossen_: No. You have wrap-start, wrap-end and it's in the logical way of whatever we decide logical is 02:39:40 fantasai: And shorthands prob want a keyword to spec that it's logical. 02:39:46 hober: !logical 02:39:51 Rossen_: We can have an option 02:40:04 TabAtkins: Do we want to defer discussion about order for four sides in a marging 02:40:20 fantasai: The one that starts block-start, line start, block end, line end 02:40:28 hober: start after end before should be the order 02:40:39 TabAtkins: Depends on if you're english-specific 02:40:53 dbaron: What fantasai said matches arabic and hebrew 02:41:04 fantasai: But that gets you what's on the beginging half of the block to be set first. 02:41:13 TabAtkins: It's opposite way of the circle for somebody. 02:41:20 adenilson has left #css 02:41:23 fantasai: We have start comes before end so the shorthand should match that 02:41:41 hober: I was hoping for if I have a margin for lengths that's physical. If I put !logical at the end I don't see something different 02:41:50 s/match that/match that semantic/ 02:42:11 TabAtkins: It won't happen. Either english is wrong and arabic is right or vice verse. 02:42:31 TabAtkins: And verical modes are completely a mess. We can bless one writing method with being identicial 02:42:40 TabAtkins: We have precedent with grid positioning. 02:42:47 TabAtkins: Grid only uses logical 02:42:59 hober: I'm not conviced, but we can discuss this later. 02:43:35 zcorpan: I agree with hober that it should be similar to the spirit of the phsyical 02:44:07 fantasai: But the spirit was lets go forwarda nd if we have four directions, lets go clockwise. If you're talking logical you don't go start to end, you do start,start corner 02:44:21 hober: In horizontal LR it would be odd if !logical made my margins float. 02:44:43 TabAtkins: I don't understand why that's valid because if people have a differently directioned language they can argue for a different result 02:45:04 plinss: One reason it is what it is if you leave things off and repeat you get logical (reasonable) results. 02:45:10 plinss: That rule is preserved. 02:45:15 hober: That's regardless of chioce 02:45:20 it's not pure repeating (for the 3 value case) 02:45:23 Rossen_: Currently most content is in physical. 02:45:32 Rossen_: If you have a keyword that breaks this half the time... 02:45:54 TabAtkins: So if someone is an idiot and converts to logical without thinking about it, you're left and right will swap. 02:46:04 zcorpan: I think people will use the keyword because i'ts cool 02:46:11 murakami has joined #css 02:46:27 hober: If you have existing content and want to make it flip to logical, it should be as easy as possible 02:46:34 Rossen_: I can see libraries changing. 02:46:36 s/rule is preserved/rule should be preserved/ 02:46:54 TabAtkins: And the first time a library switches people will see a bug. You're positing a library that forces you into logical 02:47:12 TabAtkins: They'd assume english and swap the values. You're assuming librabry authors are idiots. 02:47:44 TabAtkins: There's a different between one person that writes a plug for 100 webpages. Are you write a library and pushing without result? 02:47:54 clilley: THen people wouldn't use your library 02:48:03 TabAtkins: You want to make sure the omitting arguements makes sense. 02:48:21 hober: If you have two values it applies to the start and end. plinss argues we shouldn't do something pathalogical. 02:48:37 dbaron: The arguement is that the first two arguements 1 shoudl be block and 1 inline 02:48:51 fantasai: And we're arguing that of the two inlines that start should be first. 02:48:52 s/The arguement/peterl's argument/ 02:49:23 hober: I think the underlying is that the org clockwise was a mistake, but it's one we'll live with forever and I think consistany with that mistake is a good thing. 02:49:37 glaz: Are we done with logical properties? 02:49:40 adenilson has joined #css 02:49:48 fantasai: WE can move to background-position x/y 02:50:12 dbaron: To be clear, this is the day we have a 1-2 that needs to be 1-2 which means we need to break in the next 10 minutes. 02:50:19 fantasai: I'll present and we can ruminate over lunch. 02:50:50 fantasai: The problem is we have a background position prop which takes two values (for simplicity) 02:51:20 fantasai: That are all keywords. They are top, center, bottom, left, center right. One from each set of 3 02:52:03 fantasai: When you throw in logical values you can do this or do inline-start, center, inline-end, and than block-start, center, block-end and pick 2 from each section 02:52:25 fantasai: And than you have these properties that have been impl of background-position x/y and what do they map to? 02:52:32 fantasai: What do we assign to these long hands. 02:53:13 fantasai: The other case is pick any two keywords from the options and you can have top-start 02:53:38 fantasai: If you have english it's top left, arabic top-right, and japanese it's where the block starts. 02:53:56 fantasai: You've already constrained the first dimension, so you just have to pick the second. 02:54:22 case (1) is using only physical (top/center/bottom and left/center/right) 02:54:35 case (2) is using only logical (inline-start/center/inline-end and block-start/center/block-end) 02:54:41 fantasai: Let's say you have a sun and a fish background, you want the sun to be in the origan, not to be scrolled off so you'd want that in the start corner, but in the top for sure. 02:54:48 case (3) is mixing one value from case (1) with (start/center/end) (note no block- or inline-) 02:54:51 fantasai: So there's reasons to combine logical and physical. 02:55:10 fantasai: This world with a combination of logical/physical doesn't map to x and y axis. 02:55:23 Rossen_: What introduced background-position 02:55:27 fantasai: inline-block 02:55:34 TabAtkins: In the same way we'd have alias 02:55:42 fantasai: But we can't actually accept it as an alias 02:55:51 TabAtkins: You can alias after you figure out writing modes. 02:56:00 hober: If you set margin sstart and inspect margin top 02:56:15 dbaron: So then the long hands let you spec combinations that can't be represented. 02:56:38 hober: So the margin shorthand if you have something global to the property line, the short hand is all physical or logical, but if you use longhand you can mix. 02:57:01 dbaron: So in your 3rd case of start-center-end they're values of x and y because they're not spec values of inline-start. 02:57:10 TabAtkins: That's how I was thinking I would handling the shorthanding. 02:57:18 dbaron: I don't quite follow the implications 02:57:30 zcorpan: If you are mixing the phsyical one can get into shorthand fine? 02:57:47 zcorpan: So if you have top-start than it goes into position-y. 02:57:54 zcorpan: The problem is if you spec both as logical? 02:58:19 jh_hong has joined #css 02:58:21 fantasai: That's this whole mess and having these properties mapping there's an adidtional problem with all of the other cases with logical prop the initial values are identical 02:58:59 fantasai: If they all have 0 and there's no conflict. But here with background-position-x/y they'll be top left. That's fine in english, but in other languages it'll be inconsistant 02:59:05 dbaron: And you need to know which one to use. 02:59:13 fantasai: And you can't use a cascase because there isn't one. 02:59:19 TabAtkins: I say spec by fiat 02:59:53 dbaron: There's another way. If you haev something spec for one, if the winning is background-posistion-y you use that for x, but if the winning is background-inline that wins 03:00:02 dbaron: It could be 2 but one gets overridden 03:00:06 hober: But with none? 03:00:11 dbaron: We leave the current defual 03:00:33 TabAtkins: So if we do fiat physical, if you speck background-position-block and you spec in the direction, ir should work. 03:00:36 TabAtkins: I'm fine with that. 03:00:45 dbaron: I'm okay. It's more complex than I was hoping. 03:00:49 fantasai: Yeah. 03:00:57 fantasai: It would have been nice to avoid the longhands. 03:01:32 hober: It would be prob premature to res on res in this way since we haven't tried, but let's agree the initial spec should be this way and we'll alter if needed. 03:02:00 [whiteboard photo from dbaron] 03:02:18 [break = lunch] 03:07:43 whiteboard photo: http://lists.w3.org/Archives/Public/www-archive/2014May/att-0008/dsc06433-fantasai-whiteboard.jpg 03:32:16 myakura has joined #css 03:39:05 dauwhe has joined #css 03:53:35 andrey has joined #css 03:54:24 dael has joined #css 03:55:49 jh_hong has joined #css 03:56:31 adenilson has joined #css 03:59:21 glazou has joined #css 03:59:28 Bert: yt? 03:59:59 glaz: Let's start even if Bert isn't here. 04:00:09 glaz: First is CSS 3 Text 04:00:26 glaz: And we have 5 sub items. First is texxt-align short ending 04:00:46 fantasai: We discussed this at Paris F2F 04:01:43 fantasai: We currently have a text-slign property and we have text-align-last prop. 04:01:50 s/short ending/shorthanding/ 04:02:08 fantasai: They're currently independant and we think that we can make text-align-last a longhand for text-align 04:02:18 clilley: With making it take an optional 2nd value? 04:02:21 fantasai: That's one poss. 04:02:46 fantasai: The case were people use align-last is auto or justify, which means justify the last line b/c it's not be default 04:02:55 dauwhe: We call this forced justiciation in my work 04:03:29 fantasai: In Japanese people with set text-align: justify, text-justify: distribute and text-align-last: justify. 04:03:38 fantasai: We elimated that last step to make it easier 04:03:51 fantasai: We were going to tie in to have it happen only end justification is happening 04:04:06 clilley: So you mean that you can set text-align-last to justify and only the last line will justify? 04:04:08 fantasai: Yeah 04:04:31 fantasai: The prop on the table was to have text-align and text-align-all which would take the other values 04:04:44 fantasai: We also have where people would want hte first line aligned for poetry or something. 04:05:04 fantasai: Currently we have an issue in the spec where we need a name for that and we'll drop it if we can't find a name 04:05:11 TabAtkins: Can you apply text-align to first line? 04:05:13 shans_ has joined #css 04:05:17 fantasai: I don't know. I think you could. 04:05:22 TabAtkins: They don't cascade together. 04:05:29 fantasai: The cascading is a bit of a problem. 04:05:50 fantasai: I think it is do we want to switch text-align to a short hand and potenitally a text-align-first 04:06:07 dbaron: I think you had expalined a case where the first and last lines should work differently in cascade terms. 04:06:23 fantasai: When you set first diff from all you want to make sure you're restting all the alignment in the next declaration 04:06:37 fantasai: The q was do we want text align as a delcaration. 04:06:51 fantasai: Should/would that obliterate a privious text-align 04:06:57 s/first line/::first-line/ 04:07:07 dbaron: I think it's where -last applies to anything before a break. 04:07:25 dauwhe: That's something that's tripepd me on text-align-last that it applies after a forced line break 04:07:41 dbaron: I rememebr there's something not semetric and you convined me they should cascade sperate 04:07:55 glaz: can we use text align on the first and last line pseudo? 04:08:09 As I recall, "text-align-last" applies to paragraphs that have only one line 04:08:17 fantasai: I won't cascade correctly. If you override and want thigns to center, it won't work because the pseudo is more specific. 04:08:37 fantasai: That's a problem that shows up in various problems since the cascade rests things that are on the pseudo 04:08:45 TabAtkins: I wouldn't call that killer, but it's a down side 04:09:15 TabAtkins: Bolding the first line differently happens quite a bit. We use first-line for a lot of things that fall into a similar bucket and we're okay with making those not cascade. 04:09:42 dbaron: I think text-align-last wouldn't work with a last-line pseudo 04:09:54 dauwhe: I wish it was the last line. It would solve a lot of my problems. 04:10:06 dbaron: You want the opposite too 04:10:19 fantasai: You want a property for both things. No one has brought that up before. 04:11:03 dauwhe: I can work up examples, but we run into problems where we're trying to force a line break. In inDesign there's a lot of ways to do a line break and you can't do that in CSS because it'll force justify the last line even if it only has two characters 04:11:13 fantasai: Okay. 04:11:38 fantasai: I think I need to work on reloading the previous discussions into my brain. Unless there's something else to point out, I'll do that as we discuss other things 04:12:04 liam: We added a bunch of stuff for XFL-FO for this. We have a bunch more values there and I'd have to look at how they interact 04:12:08 s/XFL-FO/XSL-FO/ 04:12:15 glaz: Okay. 04:12:39 fantasai: most recent prop was text-align and a shorthand for -all and -last where they take the same values except -last takes auto 04:12:50 [xsl-fo text-align-last has relative | start | center | end | justify | inside | outside | left | right | inherit ] 04:12:57 http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last 04:13:06 fantasai: The other is that they have the values that are attached to each. S you can set to justify: justify but it reads better. 04:13:14 fantasai: So in most cases, the authors only need one keyword. 04:13:21 http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html 04:14:02 s/The other is that they have the values that are attached to each./The text-align shorthand takes one or two keywords, second one setting text-align-last. Alternately a justify-all keyword./ 04:14:45 fantasai: I guess we should go to the next issue while I find old minutes where we discussed 04:14:49 dbaron: I could be mis rememebring 04:15:15 fantasai: It was something about when you set text-align-last and you set the rest of it, if you want the rest of it to...um... 04:15:53 fantasai: If you only have one line it'll be text-align first takes priority, folowed by -last, followed by -therest 04:16:16 SteveZ: I dont understand how -first takes priority because it would be wrong for western. 04:16:20 fantasai: If it's not justify. 04:16:33 SteveZ: Is that why text align-last took priority 04:16:47 fantasai: I think -first take auto or start becasue there's no use case for antoher value 04:16:53 SteveZ: What's auto mean? 04:16:59 fantasai: do same as text-align-all 04:17:11 SteveZ: There's 4 componets? -all, -first, -last 04:17:18 fantasai: And the shorthand text-align 04:17:54 SteveZ: I still think -first doesn't work because -all will want to be, in wetern you want all but the last line just 04:17:58 fantasai: You leave first as auto 04:18:05 SteveZ: But if it's priory it's justify 04:18:07 s/wetern/Western/ 04:18:13 dbaron: Auto says nothing special for the first, keep going 04:18:21 SteveZ: But you have to decide if the first is just 04:18:34 fantasai: I see what you're saying. Start takes priority but auto doesn't 04:18:42 TabAtkins: It's same as start-self. 04:18:59 astearns: But in western you want to take the text-align value if there's only one line. 04:19:17 s/text-align/text-align-last/ 04:19:23 fantasai: dauwhe problem he brough about different behviour form last line vs after a forced break. It means another prop 04:19:37 fantasai: And if we add that is text-align-last actually the last line, or after breaks. 04:19:46 koji: Is there a use case? 04:20:05 dauwhe: The use-case is tied in details of hypenations and justification of text, but we get requests to alter a lot. 04:20:27 dauwhe: If that happens outside the paramenters, you do a soft return and than that line is justified. That's desireable for us 04:20:38 dauwhe: We don't want to force that just to the last line usually. 04:20:53 dbaron: So we need a mech for that. For saying a break should be treated as a non-forced 04:20:56 +1 04:20:56 dauwhe: Yeah. 04:21:02 fantasai: That makes more sense. 04:21:10 dauwhe: I know it's an oddball use case. 04:21:15 Rossen_ has joined #css 04:21:18 I agree that a softbreak should not be treated as a hard break 04:21:19 koji has joined #css 04:21:34 astearns: I think it comes up where people try and use a break and are confused that it's a paragraph break when they want a soft break 04:21:58 koji: So iss the break feel alrigt? 04:22:06 dauwhe: It feels liek a different break character 04:22:24 glenn: Is there a unicode that has that sematic? 04:22:35 fantasai: There's a soft break that we don't want to get into here. 04:22:48 dbaron: I'm of the opinion that if we can't rememebr why to seperate, we should combine 04:23:03 I found http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html 04:23:16 fantasai is quoting from Minutes 2013-11-12 Tues IV 04:23:19 fantasai: Minutes from last F2F, we were ambivilent, than we heard from digipub and they said it would be better to go short-hand long-hand 04:23:37 plinss: Unicode does have a line seperated vs paragraph seperater 04:23:45 fantasai: I think that's the bidi(?) one 04:23:50 fantasai: It's similar to soft 04:24:05 dbaron: If we agree we want that use case to be from a soft-break, we don't need to do that now 04:24:15 fantasai: So let's agree it'll be solved by a soft-break mechanism. 04:24:26 koji: There's two issues in text-align I understand 04:24:40 fantasai: I can defer text-align-first to the next level. We don't have a good shorthand. 04:24:50 s/good shorthand/good way to express it in the shorthand/ 04:24:54 fantasai: I think we need text-align-all and -last with text-align as the shorthand 04:25:10 fantasai: I think that's what we want to do. We should make that change and than go back to soft-breat 04:25:20 dbaron: So text-align is a shorthand and takes one or two values 04:25:27 fantasai: Or the shorthand justify-all 04:25:43 SteveZ: So how do I get wester to align all but the last line? 04:25:57 s/western/western layout/ 04:26:03 fantasai: Justify. 04:26:09 s/Justify/text-align: justify/ 04:26:11 fantasai: Any other comments? 04:26:34 RESOLVED: text-align as shorthand for text-align-last and text-align-all 04:26:50 SteveZ: My understanding of french poetry is the first line is left just and the rest if right. 04:26:55 fantasai: We're def. that to 4 04:27:26 SteveZ: What I'm curious is if I say text-align: right and than say text-align: na and text-align: start that will work 04:27:29 fantasai: Yes. 04:27:36 dbaron: But that's what's defer to level 4 04:27:57 fantasai: Part of the reason is that's fine in general if the browser supports, but if it doesn't you get all right align and that's not the fallback you want 04:28:18 fantasai: We want a way to express that in shorthand so that declaration that makes the other lines go right gets thrown out by newer browsers 04:28:24 s/newer/older 04:28:49 fantasai: That gives us a migration forward. no one has come up with a good way to express this in the shorthand. We've asked for keywords and no one has come u p with one. 04:28:59 fantasai: Unless there's a keyword, we're going to drop 04:29:09 dbaron: It could be a / to seperate the first and the all/last 04:29:14 fantasai: Maybe. 04:29:23 dbaron: I'm fine dropping it 04:29:41 s/Maybe./Maybe. ... would not be super-clear./ 04:29:47 RESOLVED: Defer text-align-first to level 4 04:30:19 s/text-align-first/text-align-first and text-align: start-end/ 04:30:29 We are in need of an understandable keyword for start-end 04:30:43 fantasai: And we have to go back to the soft break 04:31:08 fantasai: Current spec says that text-align-last takes affect after every force break. If we want to say except line seperater we can. 04:31:24 fantasai: line seperater is intended to be a soft break because it doesn't break to bidi pparagraph 04:31:41 dauwhe: I found a unicode where line seperater corripond to HTML 04:31:51 clilley: But understanding of break is often wrong 04:32:04 fantasai: We did compat and found that
is a paragraph seperator 04:32:18 dauwhe: Can we apply a prop to break itself? 04:32:30 plinss: Didn't we def break as replaced content? 04:32:36 zcorpan has joined #css 04:32:47 fantasai: my one concern is you have a bidi embedded...if you're doing a hard break it's a semantic break. 04:32:50 s//
/ 04:33:09 fantasai: If you have a multi-line quote and you might have an embedding and you don't want to break the embedding. 04:33:18 s/quote/quote in poetry/ 04:33:31 s/embedding/embedding on the line breaks/ 04:33:33 dauwhe: I'll send out what I've been testing for this unicode character 04:33:47 fantasai: I'm not sure line-seperator is a good option 04:33:56 fantasai: I'm not sure it's not either. 04:34:30 koji: Since most of these cases are for a single line, can we consider changing this to be last-line? The point I'm not sure is if we need the options. 04:34:35 yamamoto has joined #CSS 04:34:44 koji: I'm not sure if it wants to consider
as a line. 04:34:59 dauwhe: So you might be okay with text-align-last not applying before first line breaks 04:35:05 koji: From major use cases I'm fine 04:35:21 fantasai: In Japan if you're just the very last line, if you have more text youw ant to jsutify all those. 04:35:47 fantasai: You'll find use cases where you want to justify all but the last line, but not the lines that are after a forsced break which isn't hte last line 04:36:03 fantasai: So having it apply to all is right, though you might want something to restrict and not apply to the last line. 04:36:14 dauwhe: I feel need to mull this over 04:36:27 fantasai: WE can leave that there. We need another WD cycle anyway 04:36:40 plinss: grapheme cluster termonology 04:37:03 fantasai: So we've alises the term character to grapheme cluster so we can jsut say character 04:37:19 clilley: And this has a lot of problems where people think that character means different things 04:37:37 clilley: Logically you can say right is left, but it's still confusing 04:38:15 fantasai: Character has a lot of means and we picked one definition 04:38:34 fantasai: This gets word. i18n said people will be confused and you should use the right term 04:38:53 fantasai: Having heard from James Clark about Tai letter spacing vs line break, we have to conclude there's two things we're talking about 04:39:07 s/Tai/Thai/ 04:39:08 fantasai: one is the grapheme cluster in regards to space and one is to line breaking 04:39:14 clilley: And which is unicode? 04:39:17 fantasai: Neither 04:39:23 s/in regards to space/with regards to spacing/ 04:39:39 fantasai: unicode is trying to solve both problems, but targeting line breaking. 04:39:54 fantasai: In order to do correct line breaking, you'll have to extend to meaning of grapheme cluster 04:40:13 fantasai: Unicode allows for taloring for this case. They are aiming at the line breaking unit and the def they have is mostly there 04:40:26 zcorpan_ has joined #css 04:40:31 fantasai: Then we have spacing where in some cases it's larger than the grapheme cluster but in Thai it's smaller. 04:40:45 fantasai: And some of those you have to deconstruct to construct correctly 04:40:52 "lump" 04:40:53 fantasai: So now we don't want character or grapheme cluster. 04:41:19 "graster" 04:41:45 fantasai: So. Does anyone have suggestions? 04:41:46 "glazter" 04:41:46 "mario" 04:42:04 TabAtkins: At this point we're in the foo/bar territory 04:42:14 dauwhe: Does first letter make this more complicated? 04:42:22 fantasai: No I think it mostly uses line breaking. 04:42:25 koji 04:42:48 koji: We could go line-break point as grapheme cluster and define spaceing as something. 04:43:13 clilley: You could denife a new term so they have to look it up. 04:43:20 LCBO is where we get da booze eh? 04:43:35 (there is also the Beer Store) 04:43:52 clilley: Letter Spacing break oppertunity is LSBO 04:44:27 fantasai: So. Unless there are further suggestions we can move on. 04:44:39 SteveZ: One comment. It seems to me the grouping is more important than the breaking aspect 04:44:55 SteveZ: So I didn't like letter spacing break oppertunity and prefered talking of nature groups 04:45:10 fantasai: Break opportunity is a break between these "things" and we need a name for the "things" 04:45:26 fantasai: If you're reading this definition, I wanted a one sentence of what this property does 04:45:36 SteveZ: How about unitary characters 04:46:01 koji: You mentioned using HTML? 04:46:12 fantasai: It's different. I don't think they mean grapheme cluster 04:46:24 TabAtkins: It's codepoint or scalor value. On or the other. 04:46:45 zcorpan_: It's both in HTML. It's scalor if it can be, elsewise it' codepoint. 04:47:10 TabAtkins: scalori s a subset of codepoint that exlused the lone surregate. 04:47:12 s/scalori s/scalar value is/ 04:47:21 visually-perceived character and semantically-perceived character? 04:47:27 TabAtkins: It's nto relevenet since I'm not talking about code points. 04:47:30 (Unicode calls Grapheme clusters "user-perceived characters") 04:47:50 zcorpan_: HTML is complicated because it wants scalors and codepoints 04:48:17 dbaron: So how about creating CSS charaters 04:48:32 s/CSS charaters/the term "CSS character"/ 04:48:34 hober: CSS character would be confusing witht he ch 04:48:44 fantasai: I think it's a problem with parsing 04:48:56 TabAtkins: I changed all references from character to codepoint 04:49:17 clilley: The reason there was a link to character, is that he thought that he would use an existing definition 04:49:30 fantasai: He picked a different definition and didn't realize that. 04:49:57 fantasai: Anyways. i'm gonna put up a chart on the whiteboard and over the next break you can add suggestions 04:50:05 koji: No opposition to CSS characters? 04:50:19 fantasai: There isn't a dominant one, really. We need two terms. 04:50:33 http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#unicode-code-point was what i was thinking about. not called "character" though 04:50:52 actually it is "character" 04:50:54 fantasai: What's next? 04:50:54 palpatine character? yes emperor 04:51:02 plinss: Def text-justify: auto 04:51:41 murakami_ has joined #css 04:53:32 [spec text being projected] 04:53:44 [text-justify - at one point i'd proposed (and the wg accepted) a property to let the user ask for a named justification/line-breaking] algorithm 04:53:59 http://dev.w3.org/csswg/css-text-3/issues-lc-2013 04:54:08 fantasai: The issue was...(link above) 04:54:34 fantasai: I believe this is text-justify: auto being more international one. 04:54:43 http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-57 04:54:46 koji: 57 where there was feedback that we accepted 04:55:07 fantasai: The i18n group wanted us to be more explicite about UA doing the right thing in all cases 04:55:23 fantasai: Current state is that if you don't spec a language tag on your text is uses western justification 04:55:50 fantasai: This is aproblem for CJK texts because there's no spaces and that we dropped text-justify: interideographic in favor of auto 04:56:05 fantasai: But there's pages out there that use auto assuming it's work for CJK. 04:56:27 fantasai: We said where UA if possible sure use the approapriate spacing for the text, but we added a better example. 04:56:37 fantasai: [reads example 10 text] 04:56:58 fantasai: That will cause CJK pages that set text-align: justify to start justifying which I hope wouldn't break anything. 04:57:11 fantasai: We go futher saying if you know the content language you can be more sophisticated. 04:57:32 clilley: I like that it includes English as a more specific thing. Can you remind me of the letter definition 04:57:55 fantasai: So it's a grapheme cluster where it's not spaces, not punctuation, not whatever the n catagory way 04:58:20 fantasai: I want to go oevr this with impl to see if it's okay or if they want more explict text, or if they won't justify CJK without a languge tag... 04:58:55 clilley: This appears to only be for unrecognized language. So this allows them to do this for any language. So this is only about special languages where you don't have something for it 04:59:07 fantasai: We want UA to justify with CJK spacing by default 04:59:15 clilley: And that's testable and I like that. 04:59:26 fantasai: So I wanted to hear from impl what they think. 04:59:40 SteveZ: What happens for languages like arabic which don't put spaces? 05:00:08 fantasai: What happens is with arabic you put spaces and just at spaces. for Thai if there's a space you just at that space and if there isn't you would expand between clusters 05:00:21 fantasai: The requires a 2 level justufucation algorithm. 05:00:35 clilley: So that algorythm is wrong for Thai? 05:00:45 fantasai: Thai spaces between grapheme clusters. 05:00:51 fantasai: Word spereators are characters 05:00:57 SteveZ: So it's letter spacing 05:01:11 dbaron: This is when there's no language tag. So it would be useful to have more clear req. here. 05:01:31 dbaron: I think the current text assume the impl knows more about world lang thant hte spec author and that's not usually the case. 05:01:40 dbaron: It won't be wide knowledge. 05:02:09 dwim: I did text-justify in Blink and I can do English and Korean, but I don't know arabic and what they pref. More spec. cases are needed. 05:02:54 fantasai: If you impl primaryily expanding word seperators alsong with secondary expanding, you get there. But if we have an impl that has better knowledge I want them to be able to do that 05:03:20 clilley: So could choose needs to be changed. This is the minimal. So a test with a nonsense lang is needed. 05:03:30 dbaron: So it's also useful to say when there's a lang spec. 05:03:35 fantasai: It's here. 05:03:39 dbaron: That's not much. 05:03:59 dbaron: I think the spec is unclear enough it'll be ignored. So if not ignored you should spec. 05:04:28 clilley: You remove the part that says ex 10 and you make it non-mornative. People with good knowledge of second language, you let them do that with your second sentence 05:04:42 fantasai: We want the UA to use a universal comprimise, but it can be more specific. 05:05:02 clilley: So make it normative by saying this is the minimal required. Say from primarily onwards this is the baseline. 05:05:18 koji: But than what's minimal. Can you swap secondary and primary? 05:05:28 zcorpan_: You can also say if you have better, give me feedback? 05:05:35 glenn: I like it as is 05:05:46 zcorpan_: Is there a problem with spacing between characters in english 05:06:03 fantasai: Yes. I fyou haev a mix of CJK and other on the line, you want to spec between characters. 05:06:16 liam: There's a problem in german. Letter spacing is used for emphasis. 05:06:36 s/spec between characters/space between the CJK characters and not the English; you could space between the English as a tertiary measure/ 05:06:52 liam: A year ago I had an action item, I had sent a prop to let the author to name which alg they want for line breaking and that was for CSS 4 text. 05:07:15 dbaron, maybe adding "and should, at minimum, adequately handle both Western and non-Western scripts by default" ? 05:07:24 liam: I hadn't realized I had that action, I'll rewrite the propsal for advanced linebreaking and some of this could be refered to such a property 05:07:24 [insert example here] 05:07:33 clilley: It could be useful. 05:07:44 Rossen__ has joined #css 05:08:03 liam: Maybe you wen're on he call, but the goal was, when you do a better line-breaking a lot of the research has been print and it goes wrong for screen. 05:08:33 liam: If you use the line-breaking algoritm and you edit the text, you insert your pointer and type so the dynamic makes you pointer move up and down by a few lines. 05:08:38 liam: That's not accepable. 05:09:15 liam: I was going to let you say you plan to edit this and do that shortly before you start the editing. That would tell the user agent you accept the text as is and don't refind line breaking. For print you can optimize just a few lines. 05:09:35 liam: Than you get something that's slightly better. Being about to say an end is useful for several languages. 05:09:48 fantasai: Any further comments on this? 05:10:33 koji: A comprimise that's not suboptimal for CJK so IE will have some justification issues for quality. 05:10:40 [ proposal from last March - http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html ] 05:10:53 koji: You have something optimal for CJK and now we're removed it. If language isn't spec it's suboptimal for CJK. 05:11:13 fantasai: CJK is secondary anyway because if you have a line with a spac you just the spac. JL rec says that already. 05:11:24 fantasai: I think it compresses instead of expand. 05:11:34 koji: Compressing is okay. Expanding... Anyway. 05:11:47 koji: Since we're talking line breakign changes anyway. 05:12:01 fantasai: dbaron did you see the IRC text? 05:12:17 dbaron: It's so far from what an impl would write. This spec is sayin do a pile of research. 05:12:19 clilley: If you want. 05:12:28 fantasai: I had more spec and people said they don't want more spec. 05:12:35 clilley: I was pushing for more specific. 05:12:46 fantasai: I can't please both directions. 05:13:05 SteveZ: The main comment I wanted to make is whatever you write should be testable and some things I heard didn't sound testable 05:13:18 fantasai: Auto is to "do the right thing" and we don't say what that is 05:13:26 SteveZ: Which makes it hard to test and get interop 05:13:43 fantasai: I'll need 6 montsh research to spec the right thing plus a research budget. 05:14:06 fantasai: I can't give yout he alg. 05:14:12 dbaron: So how should impl? 05:14:20 s/impl/implementors do it/ 05:14:22 Rossen__: So why is it in the spec 05:14:36 fantasai: Because we need to say a baseline of how to justify. 05:14:54 fantasai: I don't have the answers and I've been doing this for 10 years. If you want an algorithm, I don't have it. 05:15:03 fantasai: I don't have actionable requests. 05:15:19 fantasai: I can answer spec questions, but if you want a step by step algorithm, I can't do that. 05:15:53 SteveZ: I thought I heard two things useful. 05:16:35 SteveZ: 1 was clilley point that we need a nonesense language to test and 2nd we need an algorithm that processes that nonsense lang which I thought was prioritize existing spaces or use letter spacing 05:16:39 SteveZ: That's testable 05:16:58 SteveZ: Outside the nonsense language you can't test because people may have heuristics that let them do a better job 05:17:00 https://www.rfc-editor.org/rfc/rfc6919.txt has "SHOULD CONSIDER" which seems to match this case 05:17:08 fantasai: There's simple cases where we can say you should get this result 05:17:18 fantasai: But we can't say here's the algorithm you must use. 05:18:08 fantasai: So we can say here's a praragraph of latin words with spaces and we can test if it's been handled correctly. And than do 5 CJK characters in a 6em box and than Thai and than etc. We can't test script mixing because people will want to have different priorities 05:18:22 fantasai: So we can test, but we can't spec more than a few outputs on a test case. 05:18:32 fantasai: I can say you should have these outputs, but nothing more spec. 05:18:54 "I can't define justification, but I know it when I see it" 05:19:11 dbaron: This sounds hard to jsutify spending time on because we'll write some code, someone will tell us it's wrong, we have to re-write and on and on and we may as well stick witht he western behaviour 05:19:21 clilley: That seems worse. Unless you're well known you get english. 05:19:33 TabAtkins: If you're not known you have to be a special case. 05:19:58 clilley: Well the prose is something where her'es a good way for spacing in general and if there's special cases you can do that better. 05:20:06 fantasai: What are you asking me to do dbaron ? 05:20:50 dbaron: I'm curious what other impl think they'll do. I'd rather have an alogrithm in the spec that's better than what we have and we can move toward and have something where if people say they think we can do better in their language, tell them they should get it in the spec. 05:21:08 clilley: Yeah. So people will come with different opinions and this can get concensus of how things can be. 05:21:14 plinss: This is sounding like counter-styles. 05:21:34 zcorpan_: An algorithm in the spec that we know is wrong and can get feedback and importove is more likely to get interop 05:21:45 zcorpan_: You can put in a bit note saying it's prob. wrong 05:21:50 clilley: It's prob sub-optimal 05:22:23 SteveZ: The Japaense layout req taskforce is the best to capture what you need and even they recognie that it's house styles. Don't assume there's a right way. 05:23:02 dauwhe: We devote our lives to carefully justifying text. But we do a lot of hand tweeking for results and it's so immensely complicated and we're frustrated we have so little control over it. 05:23:28 dbaron: I think broswers have different introp than formatters. We can more about interop 05:23:55 dbaron: I don't consider it worth investing in something like this if it's complicated and won't lead to browser interop. I'm curious what others think 05:24:13 Rossen__: I think your last sentence summerizes well We won't put in much without an interop result 05:24:36 hober: If we spec something that's simplier to being worse in common cases, sure we could converge, but we don't want to if it's worse. 05:24:51 fantasai: I don't htink we're prop you do worse. We're prop we do better in non-English 05:25:25 fantasai: I don't htink introp of languages isn't the goal. We want the text to jsutify and look good, but exactly what it looks like we shouldn't obsess over. That'll vary and that's okay. 05:25:37 dauwhe: I have no expections that every word will maintain across browsers 05:25:47 fantasai: That's true jsut from different font librabries 05:26:03 dauwhe: If font version changes it breaks justification. The smallest length can make large changes. 05:26:20 plinss: There is an expectation that if I only change the browser, I should get the same thing 05:26:23 dauwhe: That doens't happen today 05:26:27 plinss: People want that. 05:26:43 dauwhe: And this isn't text-align: justify, but othervalues of text-align 05:27:16 dbaron: If we start doing something that we think is better, someone will think it's worse and be furious and it's easier to point to a spec with some research than to say we thought this was better because we talked to the guy over here. 05:27:35 fantasai: We want interop on if a line of text has been jsutified or not. Where it happens is less important. 05:27:45 fantasai: Right now if you have CJK and you justify, it's not right. 05:27:52 fantasai: That's how deep the spec should get. 05:27:58 dbaron: Thent he spec should require that. 05:28:06 dbaron: If that's what you want to solve it should be must level 05:28:35 fantasai: As far as an alogirthm, I can do a non-normative appendix, but I don't want people that have a better idea or different performance be locked into a browser-required alogrithm. 05:28:42 dbaron: That's fair 05:28:42 s/not right/left-aligned/ 05:28:54 dauwhe: Plus that might take a 5 years for the algorithm 05:29:26 s/dbaron: That's fair/Rossen__: That's fair/ 05:29:35 plinss: Thinking back to counter styles, you mentioned that justification style is a hosue style so maybe at some point we want to name the prop to control all the properites of just and do it as an @ rule so people who want to be really specific can. 05:29:51 plinss: We can have our list of default parameters for these languages that are good starting points 05:29:59 dauwhe: That might be a good way of describing it. 05:30:07 fantasai: So not going to happen in the next year. 05:30:12 plinss: I'm sayin somewhere downt he road 05:30:25 fantasai: The algorithm will have different kinds of outputs. 05:30:31 s/year/6 years/ 05:30:53 koji: Are we resolving this as adding a non-normative appendix? 05:31:00 fantasai: We're saing require what should be justified 05:31:04 koji: So liek the minimum 05:31:05 frankly, one *could* spec text-justify: auto in infinite detail but as fantasai says, this would take a *lot* of research and probably wouldn't be completely relevant in the end 05:31:24 fantasai: These are justification oppotunities and if they exist you must do them. Would that work for you? 05:31:45 dbaron: I guess so. There's a bunch of things you said about where you know how to prioritize that should be in the spec. 05:31:51 "ideal" justification is not something easily defined, there's typically "better for this use" 05:31:57 dauwhe: And hopefully the simple statements can be tested. 05:32:40 to say that "this has already been done for print" is nonsense, a lot of print typography is manual tweeking up the wazoo 05:33:00 RESOLVED: Require which lines are justified even if justification method is not defined 05:33:19 plinss: next is arabic letters connecting between elements 05:33:34 jdaggett, but if fantasai is saying that the point of the text in the spec is to ensure that CJK text should be justified inter-ideograph when justify is specified, then the spec should at least require that 05:33:42 fantasai: So this was people taking a UL and formatting as inline elements and because there wasn't space all the arabic words jammed together. 05:34:09 fantasai: So if you format with no spaces the arabic elements run up together. We were discussing how to create boundries at the element boundry 05:34:30 fantasai: We could create a prop devoted to it, we could piggyback off of bidi isolation 05:34:31 dbaron: sure, if specific requirements are being stated those should be detailed, agreed 05:34:46 fantasai: Or if you have non-0 padding or margin, you consider that shaping isolated 05:35:02 fantasai: This is about shaping behviour for scripts like arabic? 05:35:13 glenn: What about arabic cuase the spaces to collapse 05:35:28 TabAtkins: It's not. Its the lack of space causes it to have text on text. 05:35:50 TabAtkins: Can you do a zero-width non-joiner? Is that sufficent? 05:35:54 fantasai: Yep. I think we can do that. 05:35:55 plus any print justification algorithm is inherently offline and can do infinite automatic adjustments without worrying too much about rendering speed. this isn't true for browsers 05:36:02 fantasai: Let me pull up the thread. 05:36:42 [people do worry about formatting speed. Luckily there are very good very fast algorithms, but there are NP-complete corner cases for all of them] 05:36:55 fantasai: I thinkt hat would work if author is aware. If we want this in UA stylesheet or take affect automatically it wouldn't work, but I'm not sure we need that 05:37:06 fantasai: I can reply to the thread and ask if that's felt to be suffiecent. 05:37:20 liam: but with browsers those algorithms need to execute in real-time on $25 devices 05:37:25 http://lists.w3.org/Archives/Public/www-style/2014Feb/0302 05:37:29 it ain't the same! 05:37:35 jdaggett, yes, understood. 05:37:37 fantasai: Okay. Next? 05:37:52 koji: Control characters 05:37:53 http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72 05:38:32 fantasai: We got a question from James Clark about why are we ignoring form feed, verical tab, and new-line characters? 05:38:37 TabAtkins: They're normalize out. 05:38:44 fantasai: You can stick them in the DOM 05:38:55 TabAtkins: Oh...neermind. 05:39:22 fantasai: Then ROc said mozilla has control character visiability prop, do we want that? 05:39:40 plinss: Some word processers let yo make spaces visible 05:40:00 fantasai: Then there was a reply saying that there was a section...[missed] 05:40:10 zcorpan_: But you can put it into the script afterwards 05:40:17 fantasai: But then it will work out in legacy 05:40:28 fantasai: So there's a legacy problem with pages that use control characters. 05:40:40 dbaron: But pages that are in UTF-8 can spec these control points 05:40:46 fantasai: Do we need to care in CSS? 05:40:50 clilley: no. 05:41:02 fantasai: So we say Zach Winburg's comment is our of spec. 05:41:16 fantasai: For the original comments, just say there's no reason too. They're formmating 05:41:18 s/our of spec/out of scope/ 05:41:45 glenn: Sometimes you want to see control codes. If you're doing arabic you want to see left or right marks and joiners, but not in the default 05:41:57 TabAtkins: mozilla has a display for invisble characters 05:42:03 zcorpan_: That was to catch errors 05:42:10 TabAtkins: Some times you want to display on purpose 05:42:33 glenn: Unicode has a block that has visual depiction symbols and some fonts support those for control groups 05:42:42 fantasai: Wasn't there a prop in GCPM? 05:42:50 glenn: You don't wnat to change the character content 05:42:58 clilley: Text transform doesn't 05:43:03 TabAtkins: That's a decent idea 05:43:06 text-transform: control-visible 05:43:08 fantasai: And you can pick waht you want. 05:43:22 TabAtkins: We can add a keyword to replace Mozilla's propritary 05:43:31 zcorpan_: And would that be compat with showing spaces or tabs? 05:43:38 TabAtkins: This is what it would do. 05:43:47 zcorpan_: I thought it was just control, not spaces. 05:43:59 fantasai: So any suggestions on responding to this comment other than no change? 05:44:10 fantasai: Apperently we conflict with unicode, but I don't think we care. 05:44:22 s/care/are 05:44:40 koji: I think the proposal also wants to treat things with whitespace. Is that reasonable to add? 05:45:00 koji: He's saying because HTML and Unicode do it's own thing we should. 05:45:12 koji: Form-feed character 05:45:29 fantasai: I don't have an opinion. We should do what browsers do which I'm guessing is not to display 05:45:34 koji: impl? 05:45:36 dbaron: I'm not sure. 05:45:47 s/dbaron/?/ 05:45:48 fantasai: We can write a test 05:45:55 fantasai: it's invisible 05:46:08 fantasai: So I think that's what we're doing. And the sepc says don't render 05:46:12 s/?/Rossen__/ 05:46:15 koji: We don't have formfeed as whitespace 05:46:21 fantasai: no, it's a control character. 05:46:26 fantasai: Any other comments? 05:46:48 fantasai: I think that's all the text stuff 05:46:55 [break = 15 min] 05:58:40 shans_ has joined #css 06:08:07 zcorpan has joined #css 06:10:05 Topic: split CSS3 Text 06:11:37 koji: The basic issue is some properties are ready but some properties need more work 06:12:01 koji: I'm proposing the split the fast moving ones so they can go to CR while the other ones can stay in a different spec. 06:12:26 astearns: I'm all for splitting to different levels. You had prop at some point different modules 06:13:16 fantasai: My concern is the things we're chunning on are the things that are the highest priority, where as the things that are stable the 2.1 stuff is fine. So text-justify, line-break and word-break are the thigns the i18n care aboutt he most and the split would make them go slower. 06:13:28 fantasai: I think in this case I'd be against pushing that stuff to the next level 06:13:53 fantasai: That might mean it'll be another 3 to 6 months to CR, but I don't think it'll be more than that 06:14:13 fantasai: We need to do the eidts we discussed today, do a ne WD and do a few cycles of LC to get comments. 06:14:22 fantasai: And that's kinda what we're stuck on right now 06:14:32 rrsagent, here 06:14:32 See http://www.w3.org/2014/05/21-css-irc#T06-14-32 06:14:47 koji: The size is quite large so half the properties we get almost 0 feedback so asking review of all the features every time doens't makes sense 06:15:24 fantasai: We can say what has changed since last LC and please focus on those things. i think if we split we'll have to do LC/CR for one and FPWD from the other and that takes longer. 06:15:31 plh: What about at risk? 06:15:44 fantasai: The thigns that are holding back we don't want to drop 06:15:51 glaz: You said FPWD was hard? 06:16:23 fantasai: It would take the focus away from the things that need work to the things that are stable and giong well. There's also a certain amount of editorial work and to keep the two drafts in sync. 06:16:34 fantasai: That won't make things go fasted except what's high priority 06:16:47 glaz: This is a level. We don't need everything in the other level. It's not versions. 06:16:58 glaz: You don't need to copy 3 into 4. 4 is an extension 06:17:06 The AB (some time ago) advised that we do not produce delta specs 06:17:07 TabAtkins: You really do. You don't want delta specs. 06:17:17 fantasai: There's individuals that interact 06:17:24 glaz: That's the purpose of levels! 06:17:39 dauwhe: Is there a natural split? I want one-stop-shopping for text. 06:17:41 Delta specs are not reader friendly 06:18:00 fantasai: I think this will jsut get text-indent and a few others to CR faster 06:18:26 koji: What happened to text-decoration is that the spec went to CR and impl starts. This will help us focus on the things left in the spec. I can see a lot of benefits 06:18:37 fantasai: If the high priority thigns were in the stable state I'd agree. 06:18:48 koji: But that helps me to move low priority to other specs. 06:19:03 hober: So you're saying that you should move the higher readiness to CR? 06:19:22 glaz: A few years ago we said if there are things that are slow and blocking we should remove them to antoher level 06:19:31 dbaron: But the ideal is we do that for things that are high priority. 06:20:01 fantasai: When we split text-decoration it's because it was long and there was a logical break. It turned out one part was faster, but I was expecting the same. 06:20:18 fantasai: There is a clear priority here. I want to concentrate on the high priority things. 06:20:34 koji: If half the CSS items are thigns we don't want, why keep them? 06:20:59 fantasai: It was in 2.1 plus a few minor extensions, plus hanging punctuation and I don't think hanging puctuation is worth it. 06:21:05 koji: There are 7 properties 06:21:16 glaz: Beurocratic isn't bad, it's editorial 06:21:22 fantasai: What are the 7 prop? 06:21:43 koji: [in irc] 06:21:46 https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0121.html 06:21:55 Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation Lower: word-break line-break text-align text-align-last text-justify word-spacing letter-spacing 06:22:08 Higher (zero-to-few feedback to the last LC): text-transform white-space tab-size hyphens overflow-wrap/word-wrap text-indent hanging-punctuation 06:22:18 plh: Are the impl of those sever prop? 06:22:51 fantasai: Yes. Of all. The first 2 are in CSS 2.1, the next 2 have impl, hanging-puntuation is AH and text-indent is in CSS 2.1 06:23:34 fantasai: The lower 4 are high for i18n and ebook communities. If it'll take us 6 months or less it'll cause more confusion instead of benefit. We won't know why we pub two levels in 6 months. 06:23:39 glaz: We did that for selectors 06:23:45 fantasai: No, they were many years apart 06:24:03 glaz: We split levels 3 and 4 and we released CR when we did 4. 06:24:12 fantasai: But 4 isn't going to CR in multiple years. 06:24:30 fantasai: These properties should go in 6 months. I think it should be 6 months. 06:24:54 fantasai: Selectors 3 went to PR. Here we have a WD that we're taking to CR and creating a new one to also take to CR. 06:25:13 fantasai: We also have impl of everything that we're planning to defer. 06:25:18 fantasai: They all have impl. 06:25:44 Rossen__: So how confident are you in the 6 months? 06:26:05 fantasai: It depends on how much time I put in, but koji is also available so as long as we're actively responding, we should be able to 06:26:15 fantasai: We're not getting "redign this" feedback 06:26:39 jcraig has joined #css 06:26:44 koji: I think that's optimistic. Last time i18n asked for a 3 month extension to LC. To make CR in 6 months we have to do the WD in one or two months. That's tough. 06:26:50 Rossen__: So we're talking about longer. 06:26:58 koji: That's why i want to reduce the focus 06:27:15 fantasai: I wasn't really working on this for the last 6 months, koji was the only one working. 06:27:20 koji: I expect a lot of work. 06:27:40 dauwhe: Can w3c help focus i18n on this? 06:27:47 fantasai: I think that LC was during the holidays. 06:28:08 glaz: That's not a valid excuse. There's always holidays. We've even discussed this during a F2F. 06:28:15 fantasai: They're overloaded I think. 06:28:42 s/there's always holidays/they're always later 06:28:54 clilley: Part of their job is to check every spec everyone produces 06:29:19 koji: I can't imagine how one person could make all the test cases for this spec. 06:29:28 koji: I don't have an impl team. 06:29:43 plh: If we don't know we can get to rec in 6 months, why aren't we splitting? 06:29:52 lmclister has joined #css 06:29:56 koji: We said CR. To PR I need help from impl. 06:30:14 hober: CR is an offical call for impl. What's stopping us from unofficially asking we'd like people to impl 06:30:18 fantasai: They're impl already. 06:30:28 hober: So then why haven't I heard of a call for impl? 06:30:39 dbaron: And if there was a CR we'd feel more confident. 06:31:13 clilley: CR gives a message of stability. There's no patitent difference. You can CR in 0 time. If you have full pass test suite you don't have to go to CR if you've met the exit criteria 06:31:23 clilley: You just need a test suite that passes 06:31:49 koji: What happened to text decoration is that once it got to CR it was picked up. I think CR gives a good message 06:31:57 fantasai: What on this list would you pick out? 06:32:08 dbaron: I think we would impl the stuff in the lower list. 06:32:19 fantasai: I don't see a benefit of taking the higher level stuff to CR. 06:32:48 fantasai: text-indent maybe, but no one is super excited. Maybe hinging punctuation for CJK, but that's one property. 06:32:59 s/hinging/hanging/ 06:33:26 fantasai: The things people are really waiting on are the thigns in the lower list. Those are the ones that a transition to CR would make a difference and the split will slow them getting to CR at least somewhat. It will add time. 06:34:05 fantasai: Making sure it's all coherent and ther's intro text. It's easy to cut things out, it's hard to pull things out and make it fit together. That takes time and it's not worth spending without a beneit and I don't think we would get a benefit. 06:34:19 clilley: Splitting won't help in any way. I think fantasai gave a good demistration of that. 06:34:24 glaz: Is there concensios. 06:34:28 RESOLVED: No change 06:34:36 s/demistration/demonstration/ 06:34:52 Topic: web-platform-tests and csswg-test github 06:35:09 plh: I don't know how familair people are with testing we have and the differences between the two 06:35:16 plh: How much detail should I go into? 06:36:01 plh: With webplatform tests contains test suits for abourd 60 spec from 6 WG. THe goal is actually to make the web work. It might sound crazy, but that's the goal and there's imput to make that work 06:36:37 plh: There's high activity on that at the moment. At the moment ?? from Mozilla is doing fantastic work to get it to work on Firefox. My hope is by end of year we'd get results from browsers 06:36:39 s/??/James Graham/ 06:36:39 s/??/jgraham/ 06:36:54 plh: So you put a test into the suite and overnight you get results. 06:37:22 plh: That would be very useful for WG to get the raw test results. That's the goal. The problem is it wan'ts to cover CSS as well 06:37:44 plh: By running the tests it's also web tests. and there's ongoing work to be able to write a webdriver test as well 06:38:19 plh: So theres' a huge advantage to haveing CSS. The CSS test repo is a mirror of mecurial. I'd assume this group is more familair than me. 06:38:33 plh: So there's discussion about how to get them to interact. There's 3 proposals. 06:38:49 plh: 1 is to make a simple solution. Make the CSS repo a sub of webplatformtest 06:38:53 s/sub/submodule/ 06:39:33 plh: So if you want to maek a publich test you make it on the CSS repo. On the pro it's easy, on the con it's confusing because people can't pull requests from the same place. Right now webplatform is using a review different system than CSS 06:39:35 s/publich test/pull request/ 06:39:51 s/review different system/different review system/ 06:40:06 plh: The third that can be argued the most is we have different requirements. webrepo placed the bar low to favor test submission. 06:40:32 plh: The seoncd solution is to have the repo as a subtree. The problem is you would have two systems and you could send pull requests to both. 06:40:49 plh: We're used to dealing with one place and we'd have to look at two with different test requirements 06:41:01 plh: Third solution is to say we're not going to try and integrate. 06:41:32 plh: People will send submitters to webplatform test and in order to satisfy the requirements it'll have to move to the reposity by the same or a different person 06:41:49 plh: So it would be submit your test to the webplatform and than the CSS will reask 06:42:23 plh: CSS platofrm does have tools that the webplatofrm doesn't have. The whole system we have on ED is all on the CSS test repo and you wouldn't get that on webplatform until written. 06:42:29 clilley: That was discussed this morning. 06:42:36 plh: I'm talking about a bigger rewrite 06:42:47 plinss: I was giong to clean up, but not fundimentally re-write 06:42:52 clilley: I misunderstood 06:43:20 plh: To finish, we don't have everyone in the room, but we can start by saying are the opinions, what to test contributors want to see? 06:43:43 plh: At the end of the day with webplatform test we can let people submit test and merge into CSS test repo that's fine. 06:43:55 plh: Do people have opinions, do they care at the moment? 06:44:32 zcorpan: My opinion is that people should be able to make a pull request to webplatform tests for when they want to add CSS tests and not have to put in the meta data that the CSS WG req for their tests 06:44:40 zcorpan: How the syncing works I have less opinons 06:44:52 plinss: Without some fundimental metadata we won't get use from the test. 06:45:22 plinss: The fundimental dicodomy is that the stated goal of the webplatform is to get better tests, but they don't care about getting specs to REC and we do 06:45:47 zcorpan: There is some meta data to annotate which tests to which section. You put it in a directory and it annotates it for a particular section. 06:46:12 plinss: I don't care about what form the meta data is in, but I'm saying we need to to exist. And if you're promising our minimum of meta data we can work witht hat 06:46:14 zcorpan: Right 06:46:41 plinss: Biggest problem is tracking issues. Where are the bugs going to be filed and where tracked and if we're copying back how will people know where to look 06:46:46 hober: We already have that problem. 06:47:04 plinss: But at least we haev a system. There's even less information about where we'll track information for the tests. 06:47:21 plh: We have a tracking per WG and er system that's automatically 06:47:48 plh: I can tell you the number of tests and pull requests we have to each spec. You mentioned that it didn't care about getting to REC and you're right. 06:48:14 plh: But WG can use it to get to rec and that's good enough. If we can get test results from three or four browsers that great. 06:48:44 astearns: I think the most important thing is one place to submit for any webplatform tests. So any one place that takes difference and reviews differences is a big thing 06:49:12 jcraig has joined #css 06:49:28 plh: If we do that there's a lot of work to be done. most of the CSS tests re manual so they'll have to be run manually which takes time. 06:50:22 plh: It may will be that we have an appraoch like with the presto where they have thier of github and we're trying to over time move thier tests to webplatform and than remove them from the original repository. We'll be sucessful when that's 0, but it'll take us a while. 06:51:00 astearns: So. I'm much more concerned with getting test solutions than having a single place to track issues and reviews. I jsut want the tests. 06:51:16 astearns: I'll accept multiple processes and the headaches to get bigger test suites. 06:51:35 astearns: I thought we decided as long as a review happened, it didn't matter where. It jsut mattered that it was tracked. 06:52:01 astearns: There could be a review in many places and we can deal with having the headache of having these mulitple ways as long as we get more tests in the test suite. 06:52:15 zcorpan: Multiple reviews thing is already an issue in webplatform without CSS 06:52:20 astearns: And it's an issue in CSS 06:52:29 plinss: I have a plan to sync our systems 06:52:38 astearns: And if you get to it great. If not that's fine. 06:52:56 plinss: I don't know how to sync those three and another repo. It sounds like a nightmare, but maybe it's possible. 06:53:51 plinss: fundimentally from one aspect I don't care and don't want to worry about this stuff. If we had an all in one we can use I'd be happy, but we don't. The other systems out there don't meet our needs. they don't help use get the specs to REC. 06:54:04 plinss: And they'ren ot offering to help us with the needs beyond what they're acknoledged. 06:54:28 astearns: But getting to REC means sufficent tests and I don't have any evendence that any tools help us get to rec 06:55:09 plinss: But what we have is multi test suites so we can run against things becides browers. We accpet from other sources and fold them into an area to generate the data to get us to REC. That's not from sheppard. 06:55:18 s/any tools/critic *or* shepherd/ 06:55:19 s/multi/multi-format/ 06:55:44 plinss: I'm all for trying to blend, but I don't want the throw out the baby with the bathwater and make it harder to get specs done. If we can bring thigns together and get them in one place, but still keep going, that's great. 06:56:03 plinss: I don't know what the right step is. If it's sub trees and pulling from different places or if it's submodules 06:56:14 Ms2ger has joined #css 06:56:40 astearns: If all tests were in same repsoitory and we have our system or our tess and the tess in W3C and their tests do what they want, maybe the competition will move fast 06:56:58 plh: And we tried to be highly modular and they're likely to try and impose every bit of the system 06:57:17 plinss: The other problem is there's a lot of histroical review data we would lose or have the track seperatly 06:57:24 s/tess/test 06:57:55 s/likely/not likely/ 06:58:13 plinss: I don't want to lose that information. Tests have to be good tests of they make our jobs harder. If the webplatform can live with use in a subdirectory we can do that and maintina our own repo for as long as we need to. But I don't know if that will fly 06:58:36 I don't think that improves the situation. 06:59:00 plh: I think we've done as much as we can on this topic 06:59:16 plinss: There are questions about if putting all CSS in a subdirectory is good enough 06:59:30 plh: I don't have an answer. I think there are some people who don't like this approach 06:59:31 My personal answer to that is "no" 07:00:03 Topic: annotate url() with "crossorigin" "integrty" etc. 07:00:33 zcorpan: So yesterday ?? talked about an ability to to give attr to a url in CSS 07:00:53 zcorpan: It doesn't have to be url. I mean the functionality 07:01:05 s/??/Anne van Kesteren/ 07:01:36 s/be url/be url() function/ 07:01:36 bye 07:01:44 zcorpan: In HTML you can do 07:02:08 zcorpan: In this case you can read the stylesheet data in CSSOM but without crossorigin you can't read it. 07:02:38 zcorpan: So today with @import you cannot annotate the url with the crossorigin. You can have a media here, but the media piece is missing. 07:02:45 zcorpan: Is that just about Stylesheets or other resources like images as well? 07:02:49 zcorpan: So import stylesheets can't be read in CSSOM 07:03:02 zcorpan: What it's asking for is some way to spec a crossorigin. 07:03:21 zcorpan: There's also a spec called sub resource integrity which takes and integrity attr 07:03:23 http://w3c.github.io/webappsec/specs/subresourceintegrity/ 07:03:43 zcorpan: And the user can compare the downloaded hash with the spec hash and they prob. want to use this is CSS as well. 07:03:47 zcorpan: So how? 07:04:20 zcorpan: You can't put anything ins url() but we can come up with some other fucntion like newurl("...", crossorigin...); 07:04:21 jh has joined #css 07:04:34 zcorpan: I don't have a concrete prop for how to do this, but I wanted to see what people thing. 07:05:06 glaz: To be sure I understand, current behaviour of linking, we can link to any stylesheet from anywhere. If this is going to be changed without crossorgin, you won't be able to reach across, right? 07:05:15 dbaron: No the issue you can't acces without crossorigin. 07:05:28 zcorpan: You should be able to opt-in to loading and accessing 07:05:32 glaz: This is a change 07:05:36 zcorpan: It's a new feature. 07:05:53 plinss: I haven't read up on crossorigin, but I'm assuming it's more than having the attr that makes it accessible 07:05:56 zcorpan: Yeag 07:06:09 TabAtkins: Relatively easy. There's already been a lot of work done. 07:06:17 plinss: It'll depend on the responce of the server. 07:06:29 zcorpan: Yeah. If you try and link and spec and if the server doesn't support... 07:06:36 something like link( ?) (where is [ ]+) e.g. link(http://a/b crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200") 07:06:39 plinss: So you're requiresting that the browser does thing 07:06:49 zcorpan: If the server doesn't support cores you'll get an error 07:06:56 s/reach across/reeach the OM 07:06:59 plinss: You don't get the style sheet? Not just you don't get access? 07:07:15 s/cores/CORS/ 07:07:16 zcorpan: Yes. If you opt into I want cores and it doesn't support you get a network error 07:07:33 adenilson has joined #css 07:07:36 plh: One question if when you function you'll need to have some questions about lazyload. 07:07:50 hober: If you look at my IRC syntax and you accept aribrary. 07:07:54 plh: That would work. 07:07:55 s/cores/CORS 07:08:38 zcorpan: I think your prop needs quotes for parsing, but is fine 07:08:43 s/your/your (hober's)/ 07:08:46 so link( ?) (where is [ ]+) e.g. link("http://a/b" crossorigin "anonymous" integrity "6d8f296997bfd407d3c82bd950585200") 07:08:46 dbaron: I think this is fine if we come up with a good name for it. 07:09:03 zcorpan: So we have link. Any other ideas? 07:09:07 dbaron: Or href. 07:09:16 fantasai: Are we using this for anything but @import? 07:09:18 ... because there's precedent, not because it's any good 07:09:22 zcorpan: Yeah. 07:09:31 fantasai: For images we can put in the image function. 07:09:45 hober: The generic case is just slightly worst than current syntax 07:10:00 TabAtkins: One poss is we play with parsing for " URLs can take arguements after. 07:10:04 hober: So no new function 07:10:13 TabAtkins: You would have to fo " or you're get an error 07:10:18 what about a core() function? 07:10:38 cors( | image, CORS arguments) ? 07:10:43 hober: I'm sympatetic to no new function, but I worry about I'm an author I hear of this awesome thing, but I don't look at if I " the URL 07:10:54 TabAtkins: So same scenario if we add a new prop though. 07:11:09 plinss: And if you're really niave you don't check if the serve supports CORS 07:11:28 dbaron: If you find a way to do TabAtkins prop you make URLs with quotes return as tokins 07:11:28 people love url()!!! 07:11:33 you can not get rid of it 07:11:34 TabAtkins: I think I can do this. 07:11:45 TabAtkins: It'll consume space until it find the quote 07:11:57 dbaron: It's the URL without " tokin that's crazy so this will work. 07:12:06 s/tokin/token 07:12:07 s/tokin/token/ 07:12:14 TabAtkins: Yeah. I want to get into the code to make sure but at this point I'm certain I can do this quick. 07:12:21 zcorpan: I like the URL with quotes idea. 07:12:29 fantasai: But you don't need multiple 07:12:47 TabAtkins: Everywhere a function can take a URL it can take a cross. 07:13:06 fantasai: I don't know about that. In SVG it uses a hyphin 07:13:25 s/cross/quoted string/ 07:13:50 hober: I love this idea of inhancing URL 07:13:59 what about image() ??? 07:14:03 action TabAtkins figure out if inhancing URL works 07:14:03 Created ACTION-632 - Figure out if inhancing url works [on Tab Atkins Jr. - due 2014-05-28]. 07:14:07 s/inhancing/enhancing/ 07:14:24 TabAtkins: We'd build the resource integrty stuff alongside. 07:14:32 zcorpan: I don't expect the entegrity right now. 07:14:32 done 07:14:43 krit: You're just talking about URL what about image. 07:14:52 hober: Image takes URL arguement so it's same thing 07:15:05 TabAtkins: Alternatly we could also allow these in image fucntion grammar. 07:15:13 fantasai: How often would we use this for images? 07:15:26 plinss: I think integrety would become popular for things like online banking 07:15:38 fantasai: I image it would in the HTML, but the CSS? 07:15:50 TabAtkins: We can always let you do it as URL and flatten it later if necessary 07:15:59 fantasai: Yes. I think it won't be used often for images. 07:16:24 fantasai: Also it's more closely tied tot he network request rather thant the image proessing. 07:16:40 so fits better in url() than flattened into image() 07:16:44 plinss: So TabAtkins you'll come back to us 07:17:01 hober: If it doesn't work we can add the function 07:17:11 Topic: grid/subgrid 07:17:39 Rossen__: Quick review 07:17:44 Rossen__: Grid is awesome. 07:17:51 [whiteboard drawing] 07:18:07 Rossen__: The thing we can do with grid is you have a division of space and you have lines where you can size and have adaptive layout 07:18:17 Rossen__: The one thing it doesn't give you is grouping. 07:18:30 Rossen__: If you have items on the grid you want to group and attach behviour, you can't. 07:18:57 http://fantasai.inkedblade.net/style/discuss/subgrid-markup/ 07:19:25 Rossen__: For ex a simple form with a button and an input field for text. If you want to treat it as a group where text spans two cells and the button is one, but I want hover where the whole group is hovered, in order to deal witht hat we into subgrid 07:19:39 Rossen__: It behavies liek a semi-transparent item in the level of grid and the purpose is grouping. 07:19:45 My position: If you can convince me that 80% of Web use cases for grid layout can be handled without compromising accessibility, I will retract my objection to removing subgrid. Otherwise not. 07:20:07 Rossen__: All the items in a subgrid are in the top-level grid, but have this invisible elemnt that let's us attach behaviour 07:20:40 Rossen__: For the past 1 or 2 years one exersize we went though was take the initial grid spec with is an app based grid with cells and try and merge that with typography based grid 07:20:51 Rossen__: We did that . Everyone in the grid taskforce contributed a lot 07:21:01 Rossen__: The spec is in fairly good shape to get to LC 07:21:09 fantasai: I think it needs another round or two for the algorithm 07:21:14 Rossen__: As concepts it's good 07:21:15 fantasai: but design-wise, it's good 07:21:28 Rossen__: The one wrinkle is that impl subgrid will be fairly complex. 07:22:18 Rossen__: The reason why is (and subgrids nest) so the entire layout of subgrids boils down to the dependnency of subgrids which can bring any element anywhere in a subtree with a different amount of spanning on some leverl as well as overflow 07:22:43 rossen: the current sampling makes me thing blink and firefox are close to impl grid 07:22:49 fantasai: mozilla is nowhere near 07:23:04 jet: It's been going around for a bit 07:23:29 rossen: But we want to push grid out as soon as we can. We want to rev our unprefixed version of grid for everything except subgrid. 07:23:39 (jet indicated someone named "max" was put on it too) 07:23:55 I think you mean "mats" 07:23:58 rossen: I think subgrid as a functionality is needed. I prop we move subgirid to level 2, allow level 1 to ship so all impl that are close can roll out at the same time 07:24:06 rossen: And than work on subgrid as soon as we can 07:24:43 rossen: In the meantime if we find out impl of subgrid is quicker, we might pull into level 1 before rec, but my initial prototyping suggests it will have a sig impl delay 07:25:22 fantasai: My position is if we can cover 80% of common use cases with existing without subgrid or comp accessability, I'm okay, but I'm not convised. I think we can cover 30% There's common cases that wil be worse with grid. 07:25:44 fantasai: Those case for which grid is designed and I haven't heard markup for an example that uses grid and isn't bad markup 07:26:04 rossen: I can tell you almost, nearly all HTML based windows store apps use grid. 07:26:32 rossen: They're assiable and request subgrid as a future, but almost all that content that will be on the web will be fine without subgrid 07:26:39 s/assiable/accessible/ 07:26:39 fantasai: App layouts seem to be simplier 07:26:45 rossen:I don't agree. 07:27:03 fantasai: I want a concrete example of something common with proper markup and I haven't seen that 07:27:14 dbaron: fantasai concern is about people having to remove thigns from markup 07:28:09 TabAtkins: So anythign doing a vaguely grid layout, accessibility wise it's fine, right now they're deeply nested, but for accessibility they're fine. There's a decent number of use cases for in page components that are better solved by subgrid, but I want to solve page layout right now. 07:28:21 fantasai: So write an ex an post to the ML 07:28:26 TabAtkins: Look at any website 07:28:43 fantasai: I did and said you'd have to remove these things and add emply elements. 07:29:06 fantasai: I went to a grid layout system, I posted the link about. There's people that made frameworks for gridlink layouts. 07:29:12 s/things/things (section markup and ids)/ 07:29:17 s/assiable/accessible/ 07:29:27 fantasai: I took that, figured out how to mark with grid and subgrid and figured out it's very different. 07:29:37 TabAtkins: This first is fine if you don't remove sections. 07:30:10 fantasai: If you want the pictures to line up, you need to remove the markup that collects around "here" [pointing] unless you guarentee it lines up. 07:30:35 fantasai: So something where you have something that looks like a grid, but doesn't rely on things being the same size. If its' same size, why not use flex. 07:30:59 TabAtkins: You don't need subgrid until you're trying to style with padding and border. You're taking each top level piece and display box works. 07:31:07 fantasai: Than we can put display box in grid 07:31:11 TabAtkins: That's silly. 07:31:18 s/display box/display-box: contents/ 07:31:34 s/in grid/in the grid spec/ 07:31:43 fantasai: I agree. I don't want to give a feature that authors will be excited about but to use it they have to strip out content to use it, they're continue to do that after we ship subgrid 07:32:04 fantasai: Markup won't sure for 2 years, it'll suck for 10 because people will keep stripping it out. 07:32:21 TabAtkins: Given the pattern worst case you need a diva round the pattern so that you can say auto: flow 07:32:39 hober: I thinkt he point stands is you have to take out the layout for a complicated model. 07:32:53 fantasai: auto:flow only works in one direction. 07:33:15 fantasai: I'm not convinced this isn't harmful. I'm pretty sure it's harmful. Unless you have examples that show me I'm wrong, but you have not done that 07:33:28 TabAtkins: Most sites have a simple grid that's hard to do now and can be addressed fine with grid 07:33:37 fantasai: And how many of the use cases is that? 07:33:45 TabAtkins: The plan is people will use grid forever 07:33:58 fantasai: I don't want them int he habit to do harmful thigns to use grid and keep using it 07:34:03 TabAtkins: This is a short period of time 07:34:12 fantasai: So we wait until subgrid is impl 07:34:37 fantasai: It's not tutorials, it's about habits. I fyou do it the old way it'll work in old version os IE. 07:35:02 hober: Prob shouldn't add verya ttractive desireable features to use practically in the real world but require reduced markup quality. 07:35:26 TabAtkins: I say not many or most case and the markup qualityt oday is so terrible we're improving anyway 07:35:36 TabAtkins: We'd rather a flatter structure. 07:35:50 plinss: Does display box conent solve most of the problems 07:35:52 TabAtkins: Some 07:36:01 plinss: Enough to aleviate your concerns? 07:36:10 fantasai: Yes, my concerns about active markup being bad 07:36:28 plinss: So is display box being ready before subgrid a way to make this work 07:36:41 TabAtkins: So I can't promise, but it's likely ready before subgrid 07:36:50 TabAtkins: We have something else calling for this feature. 07:36:57 plinss: Does this handle your concerns? 07:37:07 TabAtkins: I'm otherwise going to object to obections here. 07:37:53 fantasai: If that's impl and shipped before or with grid and we update the spec to have a nice tutorial to use these together, htan I think that will be acceptable 07:37:56 plinss: Okay. 07:38:00 TabAtkins: Sounds fine to me 07:38:11 rossen: Jet, you're okay witht hat? 07:38:23 fantasai: I'm waiting for display content before I remove my objection 07:38:35 TabAtkins: The agreement was it shipping 07:38:44 fantasai: Until that's happening, I'm not removing my obj 07:39:06 dbaron: Would you be okay with something in the spec that says impl impling grid are also expected to impl display: box 07:39:29 hober: That's a message to say that things should be in the order. All the example should have to use it in order to have the affect you want. 07:39:34 TabAtkins: The examples today don't need it 07:39:38 rossen___ has joined #css 07:39:48 s/display: box/display-box/ 07:39:50 plinss: So phrase it in a way to say display: box content is an impl requirement of grid 07:40:03 dbaron: They're correct that the examples should have it as well 07:40:13 Rossen_ has joined #css 07:40:19 clilley: rossen___ the app store has an accessibility review? Any problems? 07:40:55 rossen___: Grid is a default that's used for authoring apps. In order to submit it has to meet assicibility. Im' not sure how it's essessed 07:41:10 rossen___: With the current grid which we have without subgrid, all these application exist just fine 07:41:17 clilley: Some data would be useful 07:41:38 rossen___: They're all new content. Nonea re using the same pattern as the website, though I wouldn't expect much different 07:41:51 fantasai: Put if you have labesla nd forms elements, it's a jumble 07:42:16 s/labesla nd/labels and/ 07:42:22 dbaron: The other point is on the web we want the platform so people write accessibile as the default. If you have a revew state that means you havea different situation. 07:42:33 dbaron: I think we almost had a comprimise 07:42:38 rossen___ has left #css 07:42:58 plinss: Proposed res is to move subgrid to level two and add a requirement for display-box to be used with grid. 07:43:07 fantasai: I'd prefer a label for at risk 07:43:22 astearns: How far along is the display box impl? 07:43:27 plinss: Peple said it's easier 07:43:34 astearns: Is it impl yet? 07:43:45 plinss: So it's coming real soon. 07:43:53 fantasai: We should finish the draft. 07:44:00 jet^: Think it's almost landed 07:44:19 RESOLVED: move subgrid to at risk for level 1 and add a requirement for display-box to be used with grid and include examples 07:44:38 fantasai: I'll make the edits 07:44:42 Rossen_: I'll review them 07:44:47 TabAtkins: And I'll go over them. 07:45:00 Topic: sticky 07:45:01 Topic: position sticky 07:45:32 dbaron: It's a followup to an issue that hasn't been editing into spec. There was a thread started that it doesn't explain the two boxes you need to use sticky 07:45:46 fantasai: Can we turn the spec into a list of links into the www-style archives? 07:46:18 dbaron: My understanding of sticky is that you have soemthing like a hearder and you want to to scroll up witht he content and than stop for a period of time witht he content where it's the header and than sroll off when it's done being used 07:46:37 dbaron: So it's fundimentally like position: relative except the offset is changing dynamically. 07:46:48 dbaron: You can use any of top.right.bottom.left properties 07:47:01 . -> / 07:47:10 dbaron: You have the boxes you care about. the scrollable box, the element's containing block, and than you have the sticky element itself. 07:47:31 dbaron: For the sticky element we only care about the margin box and for the scrollable area we care about the padding box. 07:47:43 dbaron: What happens if you set none of the offesets nothing interesting happens. 07:48:24 dbaron: If you set the offset to top: 20px, it's relative to the outside box so it means you care about the edge that's 20px from the top of the scrollable area. So you prevent this margin box from going above... 07:48:56 dbaron: So top 20px says the top px of the sticky box won't go above the container as long as the scrolling box doesn't go above 07:49:04 hober: So it implicitly controls two edges 07:49:20 dbaron: It's two constraints. And the 2nd overirdes the first. 07:49:40 dbaron: The point of the 2nd is to have it scroll off. Even though this isn't in the spec, we agree that this is how it works. 07:49:53 dbaron: Where impl don't agree is if the boxes are the same size 07:50:06 Rossen_: Or some of the internal boxes are bigger. 07:50:35 dbaron: I want to discuss what if they're the same. The issue is that the second constraint constrains relative to something that's scrolling withint the scrollable area 07:50:42 hober: If they're the same you never hit the bottom 07:51:00 dbaron: The problem is the scrollable box is sorta like two boxes. the actualy box and the scrollable area. 07:51:21 dbaron: There are three options for the second constrant where the sticky element's containing block is it's scrollable container 07:51:33 dbaron: I prefer 1) Throw out hte second constraint 07:51:52 dbaron: 2) make the scrollable constraint the area inside the scrollable conatiner 07:52:20 dbaron: and that means most of the time the 2nd constraint doesn't happen either unless you're in an overflow case 07:52:24 dbaron: Geicko does #1 07:52:48 dbaron: 3rd is webkit which is use the box that isn't being scrolled. You have to write weird test cases to trigger this 07:52:49 yamamoto_ has joined #CSS 07:52:55 s/Geicko/Gecko/ 07:53:00 dbaron: Webkit will force the sticky element intot he box, even if it's below it. 07:53:31 dbaron: If the sticky element is scrolled up above, it'll force it down into the box. Which seems crazy 07:53:58 dbaron: I think in this case where the two boxes are the same, the purpose of the contianing block constrant has disappeared 07:54:21 [whiteboard] 07:54:45 dbaron: I've got a testcase link in which Gecko and Webkit disagree 07:54:45 https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943 07:55:06 *Geiko 07:55:26 dbaron: So the case... 07:56:11 dbaron: In webkit, I was right the first time. If the box is way below, webkit will constrain it to the bottom and than will scroll it up to the 20px margins until, I'm not sure when 07:56:15 Rossen_: Can I add one more view? 07:56:28 Rossen_: This is what I was going to add intot he spec and it's almost ready. 07:56:39 Rossen_: Last I talked about this with Cory is the follwoing. 07:56:51 Rossen_: We have an element to which you'llb e using position: sticky. 07:56:58 Rossen_: You default to 0px, not matter what 07:57:07 dbaron: They default to auto, not 0 07:57:26 hober: For what it's worth, the webkit testcase is paying attention to how I thought. 07:57:42 dbaron: [corrects] 07:57:48 hober: Oh. That's evil. 07:58:07 dbaron: The other thing to notice is they have a bottom of 180px that pushes them outside the containing block. 07:58:55 Rossen_: So the termonology we used is the sticky position which is the position at which the box will get stuck. Also the release position which is the condition at which the box gets put away. 07:59:12 hober: That you're using enormous values is what makes it apperent. 07:59:47 Rossen_: So sticky position is byt he scroller, release pos is trigger by containing block and an open question is if cont. block is the same as the scroll in which case we need to define reasonable behaviour. 07:59:58 dbaron: I was suggesting if they're the ame you throw away release 08:00:31 Rossen_: So it's stuff forever. that could be reasonable. If you have a bunch of these they'd stick on eachother. It would be sucky if they're the same size, but a reasonable comprimise. 08:00:50 Rossen_: The other problem is when sticky is about the trigger so we have to either define so it's brought back or it doens't trigger 08:01:08 dbaron: The other fun case is if you have both top and bottom or left and right and figuring out who wins 08:01:28 Rossen_: We can use the scroll direction as a preference so ify ou're scrolling down we take preference of the tob 08:01:56 hober: Having the behaviour depend on initial scroll direction is weird. As an author trying to debug, not realizing it's that you originally scrolled 08:02:07 dbaron: I think he ment by which way you can scroll to overflow. 08:02:15 hober: I'm presuming you've scrolled a bit 08:02:28 Rossen_: Initially. When the scroller is at origin than you have a direction 08:02:34 hober: That does seem reasonable 08:02:54 adenilson: I have all thre browsers and they're all doing something weird 08:02:58 dbaron: It's a weird testcase 08:03:04 dbaron: We should try and fix this 08:03:12 TabAtkins: We're no longer shipping sticky 08:03:24 TabAtkins: It's in stable, but not in less stable versions 08:03:58 dbaron: I think chrome has sticky in experemental web platform, but apple is shipping and we are. 08:04:10 TabAtkins: The more i think about it, webkit's behaviour makes sense 08:04:18 dbaron: It makes sesne to pull to the opposite edge 08:04:28 TabAtkins: It doesn't want to exit it's containing block 08:04:44 hober: Which is undesireable in the weird case where they're the same. 08:05:00 Rossen_: Having section don't necessary mean...they can be sep by headers 08:05:04 hober: But they the stack 08:05:17 TabAtkins: This is how I'd expect if the containing block is the viewport 08:05:34 Rossen_: Or if the release is defined by interacting with another sticky item 08:05:38 hober: No no 08:06:07 dbaron: Youc an compute this locally and this is all data you want to send to your compositor. What I don't like about webkit is it's totally different information in that one case 08:06:26 dbaron: In every other case it's in the scrolling except in that case where the release is a scrolling position 08:06:46 shans__ has joined #css 08:06:58 fantasai: Sticky is relative to the nearest ancestor 08:07:06 fantasai: It's sticky in both dimensions 08:07:15 hober: Yes. In the axis you set and offset 08:07:26 dbaron: top/bottom/left/right auto means not sticky 08:07:44 hober: It's relatively positiioned, but you haven't offset it from it's original static position. 08:07:45 fantasai: Okay. 08:08:14 dbaron: In firefox the green one is honoring the bottom 180 and the orange one is honoring the top 180 08:08:42 dbaron: Green starts like that beciase that's bottom 180. 08:08:56 dbaron: There's no release constraint, just sticky. 08:09:07 TabAtkins: Whereas in ours this means sticky so it stays 08:09:29 hober: So there's a release side where you're willing to release but if you haven't hit that you should stick 08:09:43 TabAtkins: Now that I can see it live, I can see it's a bug 08:09:50 TabAtkins: I'm not sure. 08:09:57 TabAtkins: If I like it or not. 08:10:17 TabAtkins: If you say the green is bottom 180, top 0 it wouldn't ever fall off. 08:10:40 dbaron: It's kinda an edge case and I jsut want the make the impl simplier and don't have to worry about a release that's outside the box. 08:10:49 TabAtkins: I'm assuming this is because it's easier, but I'm not sure 08:10:58 hober: I think Simon thought through a lot of edge cases. 08:11:07 TabAtkins: I'm not opposed to changing. 08:11:16 dbaron: I think we're done this topic 08:11:24 TabAtkins: Who is edit position? 08:11:31 Rossen_: It's going 08:11:35 TabAtkins: You have a plan? 08:11:37 Rossen_: Yeah. 08:11:50 Rossen_: I have most of this edit done, I have to clean it up. 08:12:03 TabAtkins: Can we define static pos in your draft 08:12:12 Rossen_: Fine with me. WE need it for flex and grid 08:12:18 plinss: We haven't pub a WD in 2 years 08:12:31 Rossen_: As soon as I have the edit I'll ask for a new WD 08:12:43 Topic: CSS conditions 08:12:59 dbaron: This was a humorous spec 08:13:13 plinss: FPWD on April 1, 2015 08:14:04 dbaron: Is there stuff worth saying about the workshop? 08:14:09 hober: I have questions about it. 08:14:13 hober: Is it in this building? 08:14:16 many: yes 08:14:23 hober: It starts at 9? 08:14:37 astearns: 9:30. It's all day, but the afternoon is in Korean. 08:15:04 dauwhe: We got the announcement in Korean. 08:15:20 dauwhe: It's independant talks. 08:15:27 plh: Is there a page for this thing? 08:15:34 clilley: It's only e-mail 08:16:12 hober: If the format is morning is in English and the purpose of WG to attend is to be able to interact, I assume there's oportunities for people to ask questions in the afternoon an have those translated back 08:16:22 dwim: Are you sure the afternoon is in Korean? 08:16:31 dwim: Korea guys may present in English 08:16:53 glaz: The meeting tomorrow is witht he TTA members. It's the gov't telecom agency 08:17:22 glaz: They are going to host the meeting on this floow starting at 9am about W3C and CSS ingeneral and than a focus on CSS in the morning. 08:17:56 glaz: The Korean members will give talks in Korean for the rest of the day. Al WG members are welcome to join. 08:18:01 glaz: And that's it. 08:18:33 glaz: Let me check the exact schedule. 08:18:40 plh: Is there a page for this? 08:18:43 glaz: No. 08:19:04 glaz: 9:30 for the first session, welcome at 9. 08:19:24 glaz: There's prob. an introduction by an offical before. 08:19:52 glaz: Registration is at 9, just say you're a CSS WG member 08:20:46 glaz: at 2pm is pure CSS drawing. 3pm is CSS post and pre process. 4pm is CSS 3 08:21:23 glaz: A few minutes ago I e-mailed TTA to thank them for hosting. I think the walking distance hotel was very convenient and they were incredibly helpful 08:21:37 [I would like to thank Daniel for the audio webinar facility] 08:21:39 glaz: I'd also like to thank dwim for all the help he gave us 08:21:46 Meeting agorned 08:22:02 THANK U DAEL !!! 08:22:14 bye folks! 08:22:26 bye :) 08:22:29 4:20am here 08:47:04 dauwhe has joined #css 08:53:47 heeyoun has joined #css 09:30:28 antonp has joined #css 09:37:32 abinader has joined #css 09:37:32 Garbee has joined #css 09:51:59 dauwhe has joined #css 10:00:14 antonp has joined #css 10:09:16 antonp has joined #css 10:24:36 antonp has joined #css 10:36:18 antonp has joined #css 10:48:08 antonp has joined #css 10:51:36 dauwhe has joined #css 11:00:38 dauwhe has left #css 11:02:06 dbaron has joined #css 11:19:57 zcorpan has joined #css 11:21:11 antonp has joined #css 11:28:34 antonp1 has joined #css 11:44:16 antonp has joined #css 11:47:33 zcorpan has joined #css 11:55:36 antonp has joined #css 12:02:04 antonp has joined #css 12:16:17 antonp has joined #css 12:38:39 Ms2ger has joined #css 12:44:06 jdaggett has joined #css 13:31:08 zcorpan has joined #css 14:03:27 koji_ has joined #css 14:03:31 fantasai; I:m ok to have the S&C added to HTML later, if that:s easier process wise. Would want an active version of it somewhere, so we can develop it, but don:t care if it:s in HTMl5 14:03:38 koji_ has left #css 14:32:08 dauwhe_ has joined #css 14:33:35 dauwhe_ has joined #css 14:46:52 dauwhe has joined #css 14:52:17 dauwhe__ has joined #css 14:54:38 dauwhe has joined #css 15:06:05 dauwhe_ has joined #css 15:13:26 dauwhe has joined #css 15:17:02 xiaoqian has joined #css 15:19:09 dauwhe__ has joined #css 15:20:39 dauwhe has joined #css 15:26:06 zcorpan has joined #css 15:27:04 dauwhe_ has joined #css 15:28:30 dauwhe__ has joined #css 15:31:56 rhauck has joined #css 15:35:07 dauwhe has joined #css 15:52:42 Ms2ger has joined #css 16:01:54 lmclister has joined #css 16:11:33 dauwhe has joined #css 16:53:43 rhauck has joined #css 17:07:05 jcraig has joined #css 17:16:46 dauwhe has joined #css 17:21:41 lmclister has joined #css 18:09:31 jcraig has joined #css 18:17:52 dauwhe has joined #css 18:50:20 zcorpan has joined #css 19:02:23 tantek has joined #css 19:18:31 dauwhe has joined #css 19:29:57 zcorpan has joined #css 19:30:22 jcraig has joined #css 19:30:27 zcorpan has joined #css 19:35:49 darktears has joined #css 19:42:40 tantek has joined #css 19:43:42 zcorpan has joined #css 19:44:52 jcraig has joined #css 19:46:44 zcorpan: Do you plan to use bikeshed on CSS OM View 19:46:45 ? 19:47:10 krit: yeah 19:47:39 zcorpan: cool, it would auto link DOMRect and so on 19:47:51 yes 20:01:10 jcraig has joined #css 20:10:23 darktears has joined #css 20:30:30 zcorpan has joined #css 21:14:49 jcraig has joined #css 21:19:56 dauwhe has joined #css 21:21:42 dauwhe_ has joined #css 22:03:26 dbaron has joined #css 22:03:55 rhauck has joined #css 22:08:33 jcraig has joined #css 23:18:24 dbaron has joined #css 23:27:27 jdaggett has joined #css 23:50:42 zcorpan has joined #css 23:58:03 zcorpan has joined #css 23:58:56 dwim has joined #css