07:16:32 RRSAgent has joined #css 07:16:32 logging to http://www.w3.org/2017/08/04-css-irc 07:16:34 RRSAgent, make logs public 07:16:37 Zakim, this will be Style_CSS FP 07:16:37 ok, trackbot 07:16:37 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:16:37 Date: 04 August 2017 07:16:39 present+ 07:16:42 scribenick:tantek 07:16:57 present+ 07:17:01 TabAtkins: (shows tabatkins.github.iospecs/css-shadow-parts/ 07:17:12 https://tabatkins.github.io/specs/css-shadow-parts/ 07:17:13 present+ bdc 07:17:24 TabAtkins: (shows https://tabatkins.github.io/specs/css-shadow-parts/ ) 07:17:26 present+ 07:17:33 deep combinator was too powerful 07:17:35 present+ myles 07:17:38 works for transfering single values 07:17:41 terrible for outside of that 07:17:49 in particular one element, e.g. heading part of your warning message 07:17:55 you have to expose a lot of custom properties 07:17:59 theoretically all 300+ CSS props 07:18:06 then xfer each one by one 07:18:14 worse if you try to style pseudo 07:18:16 s 07:18:20 huge combinatorial problem 07:18:27 variables fall down quickly if you want to allow ... 07:18:35 this proposal (link) that Shane and I wrote up 07:18:46 glazou has joined #css 07:18:49 for letting authors expose an entire element from their shadow dom to other parts of the page 07:18:55 this would go into the dom spec 07:18:59 we'd add some piece 07:19:08 s 07:19:16 s/(link)/https://tabatkins.github.io/specs/css-shadow-parts/ 07:19:24 (shows feature in spec) 07:19:43 important part in CSS, two new pseudo-elements that appear on any shadow host 07:19:48 ::part() and ::theme() 07:19:54 (summarizes proposal from link) 07:20:26 do allow some pseudo-classes on them 07:20:39 but can't depend on anything to do with the DOM tree, e.g. no ::part():first-child 07:20:53 one aspect of vars that is availabe to preserve is that they do allow you to target things further down in the tree 07:21:07 useful in practice for authors right now 07:21:44 ::part() is one level, :theme() is what this component chooses to expose plus what all its subcomponents choose to expose 07:21:48 s/:theme/::theme 07:22:15 TabAtkins: In general ::part is better to do, helps with encapsulation. But ::theme helps you do what variables do. 07:22:29 (shows example of a custom button) 07:23:01 TabAtkins: there are some suggestions for more features, e.g. elements may want to censor 07:23:16 Florian has joined #css 07:23:19 e.g. give theme ability to exclude certain elements from being exposed 07:23:26 ready for FPWD 07:23:42 fantasai: ED? 07:23:50 TabAtkins: comments? 07:24:06 TabAtkins: I'd like to pursue this in the public repo, right now it is just in my personal github 07:24:14 TabAtkins: at the very least as an ED 07:24:25 TabAtkins: also ready for FPWD if group is ready for it 07:24:41 glazou: part is always exposed? 07:24:50 glazou: but you need to expose it outside the shadow DOM? 07:24:55 TabAtkins: yes that is exactly the point 07:25:08 glazou: I understand the point, I'm puzzled that we need to add an attribute for that 07:25:16 glazou: part serves same purpose as class 07:25:24 TabAtkins: but we don't want to expose arbitrary class(es) 07:25:43 astearns: we don't want to expose arbitrary class(es), why don't we say component say these classes that are allowed to style 07:26:01 TabAtkins: and then the selectors styling in the component could look like the selectors outside 07:26:16 glazou: I have another suggestion, give a list of attribute selectors, name and value 07:26:23 plinss: but then you're ... 07:26:27 glazou: unless ... 07:26:46 plinss: what's in the ... is not just the ... not just in the shadow tree, but something that is deliberately exposed 07:26:47 s/TabAtkins: and then/astearns: and then/ 07:27:02 plinss: and then propagate these things up to the route 07:27:04 s/route/root 07:27:17 plinss: this is basically what I wanted but just wanted pseudos... 07:27:24 plinss: can we do structure? 07:27:25 TabAtkins: no 07:27:33 plinss: it flattens the entire shadow tree? 07:27:45 TabAtkins: yes, because exposing the entire structure exposes too many details 07:27:54 plinss: ... so I'm find with that 07:27:55 q? 07:28:06 fantasai: I don't understand the use case for theme 07:28:24 TabAtkins: vars right now can be used to target an arbitrary depth down the shadow tree 07:28:32 TabAtkins: same thing that theme does 07:28:34 q+ 07:28:37 TabAtkins: part gives you only one level 07:28:43 q? 07:28:56 TabAtkins: not currently a way to block theme like vars 07:28:59 fantasai: why? 07:29:13 TabAtkins: e.g. to theme custom buttons regardless of where they are 07:29:19 TabAtkins: just by setting vars 07:29:29 fremy has joined #css 07:29:32 fantasai: second question is ... 07:29:37 q+ 07:29:45 fantasai: just wondering if ryosuke has read your draft 07:29:49 TabAtkins: he has but doesn't like theme 07:30:12 fremy: why can we just not create a namespace of classes that we expose? 07:30:23 instead of a new attribute 07:30:29 classes that start with ... 07:30:44 ack fremy 07:30:50 TabAtkins: possible, but class has traditionally be treated as a user (author) space thing, and we don't introspect on the internals of class name 07:30:57 dino has joined #css 07:31:00 fremy: it seems like a bad idea to have to use part and class 07:31:11 TabAtkins: class for internal styling, use part for how external world can see you 07:31:15 q? 07:31:23 ack dbaron 07:31:30 dbaron: I'd be in favor of this moving to ED space 07:31:41 the structure thing that plinss brought up could use some more examination 07:31:53 I can imagine different things that all expose the same piece instead 07:32:02 and you'd want to expose that instead of having to mirror the names 07:32:10 TabAtkins: yes that is possible, trying to hit the minimal case right now 07:32:14 q? 07:32:19 can carefully expose more structure 07:32:25 plinss: stack of custom elements? 07:32:34 TabAtkins: each pseudo can expose its parts 07:32:58 no particular reason author needs to know your buttons are x-button vs button 07:33:14 dbaron: one other point, I find the part and theme names confusing 07:33:19 TabAtkins: which part? (lol) 07:33:33 dbaron: the fact that they are very similar, but have very different names that don't tie them together 07:33:43 TabAtkins: like because "theme" doesn't indicate it is like "part"? 07:33:50 dauwhe: I certainly support ED on this 07:33:54 ack dauwhe 07:33:54 we have this problem in the ebook world 07:33:58 maybe ::parts() 07:33:58 publishers creating styles 07:34:05 need users to override parts of it but not all 07:34:13 we run into lots of problems with the cascade 07:34:23 trying to allow user to control P but not H 07:34:39 q+ to ask why '#the-button label' (with a space or a ">") isn't enough. 07:34:43 TabAtkins: ... inside shadow vs outside shadow 07:34:49 (explains how to solve it) 07:34:49 +1 to ED 07:35:09 Rossen: so I heard a few in favor of moving to ED to begin with 07:35:11 Bert: I have a q 07:35:17 not sure I understand how you expose part 07:35:17 we need a QA person ;) 07:35:23 do you need pseudo at all? 07:35:33 TabAtkins: the button already has children, the may or may not be exposed 07:35:45 you can take the actual dom children and pull them into the shadow dom 07:35:58 and two, letting you use the descendant combinator implies you can use child combinator 07:36:02 Bert: no at same level 07:36:09 TabAtkins: I would find that a little bit ... 07:36:25 big one is that child and descendant combinators already match the actual children 07:36:29 Bert: namespace issue ok 07:36:50 TabAtkins: pseudo gives you a clear context abou what you're matching 07:36:57 Because of how the cascade works for rules originating inside the shadow vs outside the shadow, you can prevent the outer page from manipulating particular properties on an element by just setting them from inside the shadow dom. 07:37:06 plinss: one thing I like about pseudo approach, in the ExtWeb approach, you can use ... to explain pseudo ... 07:37:17 plinss: I can explain that that was a ... element all along 07:37:26 TabAtkins: our inputs are implemented with shadow dom 07:37:44 TabAtkins: any objection to ED space? 07:37:48 Rossen: does anyone? 07:37:57 Rossen: doesn't seem like it. go ahead and move it. resolved 07:38:12 RESOLVED: move CSS Shadow Parts to WG ED space 07:38:19 Rossen: ... ? 07:38:29 TabAtkins: ... will go into ... and ... will go into ... 07:38:46 Rossen: let's go back to ... 07:38:50 The part attr will go into the DOM spec; the pseudo-elements will go into the SCoping spec. 07:38:57 Rossen: review of TTML 07:39:05 Rossen: we have Nigel joining us on the call 07:39:06 nigel_ has joined #css 07:39:20 Topic: Review of TTML 07:39:22 ScribeNick: fantasai 07:40:35 Rossen: Asked a few weeks ago to review TTML current WD 07:40:48 https://lists.w3.org/Archives/Public/www-style/2017Jul/0007.html 07:40:57 Rossen: Some back and forth over email 07:41:08 Rossen: Provided feedback, first time by dbaron, 2nd time by Florian 07:41:33 Florian: Feedback I wrote wasn't sent to TTML, sent to us to decide if it was my position our position 07:41:39 Florian: We haven't resolved on that officially 07:41:55 Rossen: Would ou want to summarize? 07:42:02 Florian: Roughly very similar to what dbaron saidhalf a year earlier 07:42:11 Florian: Didn't review anything other than style and layout, but for this part 07:42:20 Florian: You ahve a system that is very similar to CSS, but isn't CSS 07:42:30 Florian: Some attributes take the same syntax, but have different semantics 07:42:44 Florian: Some take a superset, some take a subset, some overlap in both ways 07:42:57 Florian: We could do a mapping, but different semantics is a problem 07:43:19 Florian: E.g. 'line-height' defines the height of the line box in CSS, in your case it defines the spacing between baselines which is similar but not quite the same 07:43:31 q+ to ask which cases have different semantics for line height 07:43:33 Florian: Other times you and us solved the same problem in parallel and came up with a different solution 07:43:44 Florian: e.g. your alignment properties are different from ours 07:43:47 q- 07:43:56 See also dbaron's review https://lists.w3.org/Archives/Public/www-style/2016Nov/0106.html 07:43:57 Florian: You can't really map to CSS, you can try but because of these differences, will come out wrong 07:44:09 Florian: Implementing TTML will be completely different from implementing CSS 07:44:10 q+ 07:44:16 Florian: Browsers have a CSS engine 07:44:28 Florian: If not compatible with CSS, unlikely to work out 07:44:37 Florian: There's a rough mapping in an informative part, but it's not really going to work 07:44:54 Florian: I understand the history of starting from XSL:FO, but that's dead for client-side on the Web 07:45:09 Florian: Out of context, it might be a good technology, but in the context of the Web it's hard to fit 07:45:24 ack nigel_ 07:45:24 nigel_, you wanted to ask which cases have different semantics for line height 07:45:27 nigel_: Fair summary 07:45:34 nigel_: Interested in specifics of line height issue 07:45:48 -> https://www.w3.org/wiki/TTML/CSSRequirements 07:45:53 nigel_: One thing, you mentioned an informal document that brings out correspondences to CSS 07:45:57 nigel_: here's a link 07:46:01 nigel_: we did quite a bit of this analysis 07:46:20 nigel_: we used dbaron's and your feedback (which we found) 07:46:26 nigel_: absolutely right that the syntax is different 07:46:42 nigel_: for us, compatibility with previous versions is important; breaking would be a problem for us 07:46:50 nigel_: a lot of the target devices are not browsers 07:47:02 nigel_: but there is a growing recognition that being able to render with CSS would be a good idea 07:47:19 nigel_: So there has to be a syntactic mapping, but wrt semantic mapping... 07:47:43 nigel_: We discussed with TAG recently, and hey had useful view that we should describe the mapping into CSS for this to be useful implemented 07:47:55 nigel_: Question of whether this mapping should be normative, unsure how much real world difference it makes 07:48:03 nigel_: Other recommendation from TAG was that if there were styling requirements 07:48:13 nigel_: then it would be really helpful if there were CSS equivalents 07:48:41 q+ 07:48:41 nigel_: If things that we need in subtitle / caption word aren't in CSS, we ask CSSWG to add them 07:48:48 nigel_: this makes it easier to implment with a CSS backing 07:48:48 q? 07:49:05 nigel_: If we can get to any detail, even offline, want to know e.g. differences in line height semantics 07:49:25 myles_: I guess, we've looked into this a bit and our findings align with Florian's findings 07:49:32 nigel_: Our conclusions are in line with Florian's conclusions 07:49:42 s/nigel_/myles/ 07:50:07 q? 07:50:11 myles_: We would be hesitant to implement if not aligned with CSS 07:50:15 ack myles_ 07:50:35 (Myles represents Apple, works on WebKit) 07:50:44 Florian: Wasn't on TAG, don't know what they said 07:50:59 Florian: But rather than have you define things and us define things in parallel 07:51:15 Florian: better to define in terms of CSS, and if something's missing, then we add it 07:51:36 Florian: Wrt subtle differences, determining how subtle secondary, if they are normatively defined independently 07:51:54 Florian: then there will be differences, and even small differences are problems in deployment 07:52:19 Florian: Differences between different and broken are subjective 07:52:29 Florian: If the syntax layer needs to be different, this is a minor annoyance but fine 07:52:41 Florian: But in terms of semantics, don't redefine separately what's already defined in CSS 07:52:47 Florian: file bugs against us to add things 07:52:54 Florian: Could go through long list of details on every property 07:52:59 Florian: I took line-height as an example 07:53:14 Florian: but given you have normative prose, there are bound to be differences 07:53:15 q+ to mention the spec timing issues 07:53:22 q? 07:53:22 ack Florian 07:53:29 ack 07:53:49 nigel: I understan where you're coming from 07:54:00 nigel: From TTML WG PoV, it's not always so obvious how to add things to CSS 07:54:01 ack nigel 07:54:01 nigel, you wanted to mention the spec timing issues 07:54:23 nigel: but also there is pressure to get a new version of TTML out, and if we had to wait for CSS, wouldn't be able to satisfy our community 07:54:44 q+ 07:54:46 nigel: TTML2 could be seen as a req document, and align with CSS later 07:55:28 nigel: I've not heard any dissent from view that these reqs need to be met 07:55:42 nigel: So assuming there is a ?, we do need to support them in subtitles and captions world 07:55:55 nigel: As soon as we have access to CSS definitions we can add them back in 07:56:04 s/?/requirement 07:56:14 nigel: There is time, actually 07:56:24 nigel: We're in WD at the moment, the review endes in September 07:56:29 nigel: we wouldn't be in CR until after TPAC 07:56:40 nigel: If there is an opportunity to get some featues specified in CSS, could contribute to that in some way 07:56:46 nigel: then there is time to fill some of these gaps 07:56:53 nigel: most important ones that would be useful 07:57:02 nigel: filling line gap 07:57:08 nigel: text-resentation for ideographic scripts 07:57:10 nigel: ruby 07:57:15 nigel: font ??? 07:57:18 nigel: these would be useful 07:57:32 https://www.w3.org/wiki/TTML/CSSRequirements#disparity 07:57:39 https://www.w3.org/wiki/TTML/CSSRequirements 07:57:42 astearns: Not time to define new things in CSS, but time to review list of places where you're unsure if there's concordance 07:57:51 astearns: I saw some things, e.g. where we do have the feature 07:58:09 astearns: Would be nice to have syntax map, and semantics if possible 07:58:22 astearns: Would be good to have someone from group review list to check for actual gap 07:58:29 Florian: We have a bit of precedence with this, with EPUB 07:58:35 Florian: Where they couldn't quite wait for us 07:58:41 Florian: This is overall not a story that ends veyr well 07:58:52 Florian: Similarly to your situation,not all EPUB readers are browsers, but kinda 07:58:53 s/syntax map, and semantics/semantics map, and syntax/ 07:59:12 Florian: When you ask to support things that are not CSS but kinda it's problematic 07:59:43 q? 07:59:48 ack Florian 08:00:01 Florian: Originally they asked us for stuff, and if we didn't deliver fast enough they tried to define their own thing 08:00:18 Florian: But realized that doesn't work, so now are planning to just bug us to prioritize and fix things 08:00:24 Florian: Wrt differences we were discussiong 08:00:35 Florian: I wonder if it's worth doing, if we don't go all the way in 08:00:42 Florian: If we can bring it to the point that browsers can implement 08:00:45 Florian: Then it's worth 08:00:56 q+ to talk about browser display 08:01:02 Florian: But if it's not possible to implement in browsers, then making it less different is maybe not so useful 08:01:18 nigel: wrt displaying in browsers, they do 08:01:25 ack nigel 08:01:25 nigel, you wanted to talk about browser display 08:01:27 nigel: TTML has a profile IMSC 08:01:34 nigel: one of the implementations is a JS implementation with CSS 08:01:48 nigel: clearly there's a desire to present subtitles in CSS 08:01:52 s/CSS/browser 08:02:01 nigel: I imagine same would be true for TTML2 08:02:20 nigel: Experience of editor of IMSC had with creating imsc.js was that he ad to work around limitations of CSS quite a bit 08:02:30 nigel: e.g. putting each character in its own span to tweak its position 08:02:47 nigel: Some easier things to fix, like box-decoration-break 08:03:00 nigel: possibly just understaning layout options in CSS better would help 08:03:09 nigel: As you guessed, ppl will want to map to browsers better 08:03:23 nigel: browsers natively doing is maybe ??? 08:03:46 q? 08:03:53 nigel: Making decision based on whether browsers want to natively present TTML is maybe a step too far 08:04:05 nigel: just about whether to present TTML at all, e.g. using JS libraries 08:04:40 jet: It seems like we're a bit torn in that browser venders see it as obvious to render TTML using our existing layout engines 08:04:47 jet: but the consumers of TTML might want custom layout in the future 08:04:59 jet: e.g. never render markup in front of a face, where browsers wouldn't even know where to start 08:05:12 jet: Need to innovate in ways beyond just render text in a fixed location 08:05:24 q? 08:05:24 jet: Want to align on things like text rendering 08:05:39 jet: but polyfill things that we wouldn't know where to start dealing with 08:05:48 nigel: avoiding faces is done by author positioning 08:05:57 nigel: but sounds really cool 08:06:37 nigel: Hvae a question to you, 08:06:50 nigel: TAG said it would really be good if CSS would support requirements 08:06:54 nigel: Is that something you concur with? 08:07:20 Rossen: So long as the feature requirements that are specific to CSS come to us fit to overall model of what we're doing 08:08:00 Rossen: as long as they are coming as requests we will definitely review and consider 08:08:10 Rossen: for those that don't, not much we can do 08:08:18 Florian: For those already in the spec, you have a solution 08:08:43 Florian: But for us what would be most useful is not to tell us to support the solutionof the TTML group, but to take a step back and tell us the use case 08:08:59 Florian: Maybe the way you solved it is a perfect fit for CSS, maybe it's not but another approach would work 08:09:08 Florian: Question is does the thing you care about fit into CSS? 08:09:28 Florian: If so then maybe it will influence what we do in CSS, either importing wholesale or adjusting the capabilities otherwise 08:09:38 Florian: Having only the solution without understanding the use case would not help very much. 08:10:07 nigel: One more thing to add... sounds like there are some actions 08:10:19 nigel: Whatever those actions are, we've set aside time at TPAC 08:10:27 nigel: best day for us would be Friday 08:10:34 nigel: set aside time to invite to join us 08:10:46 nigel: to hopefully come to some resolutions 08:10:52 nigel: will send a formal invitation 08:11:07 nigel: could also do THursday if preferred 08:11:26 Rossen: We have some requests pending for TPAC, I believe thursday is mostly gonna be fore CSS Houdini meetings, so that's likely to fil lthe day 08:11:32 Rossen: Haven't settled on thursday or friday, so dpeends on that 08:11:42 Rossen: Already have some a11y and few more groups that want to meet with us 08:11:45 Rossen: But def send an email 08:12:28 nigel to lurk for a bit 08:12:35 Topic: CSS Break 08:12:52 ScribeNick: TabAtkins 08:13:38 fantasai: We had a request from Nigel to add a value for the box-decoratio-break property. CAn you explain? 08:13:57 github-bot: https://github.com/w3c/csswg-drafts/issues/1633 08:13:57 fantasai, Sorry, I don't understand that command. Try 'help'. 08:14:04 github: https://github.com/w3c/csswg-drafts/issues/1633 08:14:05 nigel: IMagine you're displaying subtitles, and for a11y you want to put a high-contrast background behind the text. Not on the whole

, just behind the lines. 08:14:27 nigel: You don't want the bg to be tightly wrapped to the text edges - you want it to extend slightly out for readability 08:14:32 nigel: But you cant predict the linebreaks. 08:14:38 nigel: That's okay righ tnow with b-d-b: clone 08:14:50 nigel: But then what if you have a span in the middle of the text with a different color bg. 08:15:09 nigel: And the break falls in the middle of that other span. 08:15:27 nigel: You want the span's bg to be what extends; you want to use padding to display that. 08:15:50 nigel: So the most relevant bg color to "extend" is from the innermost element at the break, not the element that sets b-d-b. 08:15:58 nigel: fantasai asked a good question. 08:16:10 nigel: Should it be "most nested" or "most nested thing that *counts", paraphrasing. 08:16:16 fantasai: I think we have this problem generally with fragmentation. 08:16:30 fantasai: At the break, you want to ahve a little bit of extra padding with the bg beneath it. 08:16:54 fantasai: It's possible that maybe we can solve this by just saying "add this amount of padding at the break". 08:17:06 fantasai: Whether that solves this is, do you need borders too? Or just backgrounds. 08:17:17 fantasai: Like a border around the inline that only closes if it's the innermost nested border? 08:17:21 fantasai: Seems weird, I guess not. 08:17:44 nigel: I think for border-radius you want [...]? 08:18:18 fantasai: If both have b-r; normally we'd just slice and get the green and black backgrounds overlapping eachother on a clean break. 08:18:34 fantasai: If only the green gets a border-radius, you'll see the black background peeking out from under the green. 08:18:38 fantasai: That's a problem. 08:18:49 Rossen: I think this is in conjuction with the line-padding property in TTML, right? 08:18:50 nigel: Yeah. 08:18:52 a general 'break-padding' property sounds like it could be useful... 08:19:26 Rossen: box decoration and fragmentation, you're talking about linebreaking, nto general box breaking 08:19:29 TabAtkins: It can be about boxes too. 08:19:30 I think it would be helpful to have a diagram in https://www.w3.org/TR/ttml2/#style-attribute-inlineAreaBreak that showed a rendering using each value for cases where there's a difference 08:19:35 Rossen: Sure, but that's not his requirement. 08:19:48 Rossen: Also something we don't have in CSS is line-padding that extends in every break. 08:19:53 dbaron, yeah, that's what I was thinking. But it doesn't solve the border-radius case he was describing 08:20:37 nigel: Line padding was introduced to IMSC when border-radius wasn't available in TTML; at that point the only styling you could do was bg-color and get a square box. 08:21:03 nigel: Now with b-r it's gotten more complicated, and probably need to extend it a little further than just the line-padding semantic, to include the other bg effects (or things that otherwise affect the background) 08:21:13 nigel: Your point about targeting line areas specifcially is well made. 08:21:32 nigel: If there was a way to say "for each line in this

, apply this styling" that would be really helpful, but that doesn't seem to exist yet. 08:21:48 fantasai: I think it would be relatively easy to describe as only things that work are background and things on the box, not background. 08:21:49 Here's nigel's example https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png 08:21:53 fantasai: Once inheritance applies it's hard. 08:22:07 fantasai: We have this problem with ::first-line; it's a mess, lots of bugs, spec isn't precise enough despite our efforts. 08:22:19 fantasai: But if it's just about "background here, put a b-r on it", it's not too hard. 08:22:33 fantasai: Not high prio to do in browsers, but wouldn't be too hard. 08:22:59 iank_: We don't have an architecture that can support that (styling lines individually). It's several years away. 08:23:23 bdc has joined #css 08:23:29 Rossen: The existing model of line boxes in most impls, certainly in Edge, is not easily extdendable to support this. Not impossible, but it would be quite hard. 08:23:45 Rossen: Tho this is a valid use-case and feature. 08:23:49 fantasai: What's line-padding? 08:24:34 Rossen: Imagine you have a span - I posted on of Nigel's examples - that adds bg to the current inline. And the span breaks. You can put padding on the span - you'll get padding at the start and end of the span. If it fits on one line, great; the bg will extend a little past the text. 08:25:01 Rossen: But if the text breaks in the middle, you have some padding on start of first fragment and end of last fragment, but all other broken edges have no padding. 08:25:10 Rossen: line-padding feature adds padding to every break-edge. 08:25:16 Rossen: Basically to the linebox itself. 08:25:27 Rossen: if the linebox has background, it extends. 08:25:36 fantasai: The linebox is wider than that actually, but I get what you're saying. 08:25:51 fantasai: Taht makes sense, and I see how adding border-radius would be tricky. 08:26:20 nigel: Doing just the inline-padding isn't the only place we want to do something with line areas. 08:26:36 nigel: Another feature, fill-line-gap, says "draw background areas between lines". 08:26:49 nigel: Hard now, because character heights are UA-dependent. 08:27:06 nigel: So can't specify a padding-top/bottom that correctly fills in the space between lines. 08:27:31 fantasai: Question I have - you ahve a line of text with some line-spacing, say 1.5. You're seeing there's a bg below the text, and a .5em gap between the lines. 08:28:02 fantasai: When asking to fill the linegap, you're filling that .5em space, what happens at the top and the bottom? Do you add .25em at each? So each line gets .25em of bg above and below? Or just between the lines? 08:28:10 nigel: At the moment we don't say. 08:28:22 fantasai: Ok, thiat's a really important question to answer in CSS. 08:28:31 fantasai: Second question, if two lines have different lengths, what happens? 08:28:36 line-box-margin: collapse 08:28:48 nigel: Probably we take whatever answer is most convenient. 08:29:00 nigel: But as far as I know you can't set a padding value, because you can't calculate it... 08:29:19 fantasai: We should specify that... 08:29:54 TabAtkins: Why's it hard? Just the diff between font-size and line-height, right? 08:30:22 fantasai: Not quite - the bg area isnt' the size of the line box. The area around an inline - in 2.1 there were two ways to calculate the area, based on font metrics, and impls might do different things. 08:30:40 Rossen: This is going a bit off topic, can we bring it back to b-d-b? 08:30:42 dustinm has joined #css 08:30:42 s/line box/line height box of the inline that's used for layout/ 08:31:39 -> https://github.com/w3c/csswg-drafts/issues/814 [css-inline] Define the content area of inline boxes #814 08:31:42 q? 08:32:03 TabAtkins: So it sounds like b-d-b: inner-clone badly solves border-radius issues, and limiting it to just background is better solved with a break-padding property? 08:32:26 break-padding also causes problems with border-radius 08:32:51 fantasai: So I think those are the main two request from Nigel, this and figuring out the fill-the-gaps issue. 08:33:05 fantasai: Which I think is best done by making impls interoperable, then just using padding on the element. 08:33:33 fantasai: If we have a consistent box height, then having a line-height of 1.5 and a padding on inline of .25em above and below *should* fix the gap; if it doesn't, we should fix that. 08:34:07 fantasai: And for the other issue of cloning spaces - it seems the solution you're proposing doesn't actually solve the problem. 08:34:39 fantasai: It's not just "clone most nested"; if there is b-r involved, you want to spam that innermost b-r all the way up, so the lower backgrounds dont' show up underneath the topmost's b-r. 08:35:23 Rossen: So yeah, the feature request is something we'll work on, probably as part of Break. We'll go from there! 08:36:17 Topic: letter spacing 08:37:05 Topic: tter-spacing should not apply to the end edge of a line/span? 08:37:10 kochi: Text 3 letter-spacing specifies that the letter-spacing after the last character of an element should be eliminated. 08:37:19 github-topic: https://github.com/w3c/csswg-drafts/issues/1518 08:37:23 koji: Concern that, while this is better, it may not be web compatible. 08:37:29 github topic: https://github.com/w3c/csswg-drafts/issues/1518 08:37:40 koji: Our team prefers it be opt-in, so existing pages still work but authors can choose the better model. 08:37:45 s/kochi/koji/ 08:37:55 all right :) 08:38:00 koji: It looks like Sebastian and François agrees 08:38:13 fantasai: I know it's different, I wanna know if it actually causes a problem. 08:38:25 fantasai: Adding extra stuff is extra cognitive laod on the author; it would be better ot just do the right thing. 08:38:39 koji: We have a bug requesting this feature for years. 08:38:57 koji: He wants to stop using negative margin to cancel the space. 08:39:13 koji: If we change things, his pages' compensation will instead ram the characters together. 08:39:26 fantasai: Right, question is how many people will have that problem, and how many will be *fixed* by the change. 08:39:33 q+ 08:39:52 fantasai: If you have a large amoutn of letter-spacing to cancel, so large negative margin, and there's text after, that's a problem. 08:40:15 fantasai: But if it's a small letter-spacing, it'll have less than ideal spacing but still *okay*, but lots of other pages will have improved letter spacing. 08:40:44 koji: I think it's a little self-contradicting - people want this feature to care about it, and people who care can apply negative margin today. 08:41:11 myles_: I don't think that's necessarily true 08:41:18 TabAtkins: I've never realized I needed to deal with this case 08:41:38 myles_: There's a diff between caring about letter-spacing, caring and noticing there's a problem, and caring, noticing, and trying to fix it with this hack. 08:42:06 myles_: What's stated in the spec is generally the correct result. I'd like to implement it, but I share fantasai's hesitation that we don't know how much will break. 08:42:08 ack fremy 08:42:13 fantasai: I'm not hesitant, I think we should try it. 08:42:18 q? 08:42:38 fremy: letter-spacing is used eveyrwhere on the web, so even if a tiny fraction care enough to use the hack, it'll still be a lot of web pages. 08:43:07 fremy: And browsers are mostly interoperable today. I don't think it's a huge problem to keep current spec, add new glyph-spacing property that works properly, and tell authors to use latter. 08:43:13 myles_: glyph-spacing is bad name 08:43:28 fremy: Sure, anything works. 08:43:43 myles_: I think making two solutions, one broken and one working, isn't great. We should investigate fixing the one. 08:43:54 fantasai: Someone has to ship it then. 08:43:57 myles_: Or crawl for it. 08:44:05 myles_: Look for letter-sapcing and negative-margin on the same element. 08:44:31 Florian: Hard to tell automatically if it's bad. 08:44:51 fantasai: Have to investigate the *inherited* letter-spacing value, and if negative margin on the element. 08:44:58 fantasai: That's the pages that are trying to work around it. 08:45:18 fantasai: But there's also millions of pages that aren't trying to fix it, and will look better when we change it. 08:45:25 q+ 08:45:29 fantasai: So it's a balance of how much bad it is. 08:45:31 q+ 08:45:41 fantasai: Slijghty worse appearance, or readability is affected. 08:46:01 fantasai: So you have to actually look at the page. 08:46:20 q? 08:46:36 bdc: Huge letterspacing is bad design by default, while negative letterspacing i soften used for proper kerning. 08:46:46 If it's mostly just slightly worse appearance, we're winning: there are many many more pages that aren't trying to compensate. 08:46:53 rego has joined #css 08:46:59 bdc: So there, we'd have the opposite issue - if we remove the space after last letter, we'd have bigger space between words than we currently have. 08:47:08 fantasai: If you apply letter-spacing to whole paragraph, no impact. 08:47:13 ack 08:47:14 q? 08:47:22 ack dbaron 08:47:29 dbaron: This isn't th efirst time it's brought up - maybe web compat, don't know, a little afraid of it. 08:47:38 dbaron: If it is web-compatible we should stick to the current design. 08:47:51 dbaron: If we wanna conclude it's not, we need more evidence than brought so far that it's not. 08:48:08 dbaron: Until we have evidence that it's not, we should stop trying to discuss it every six months. 08:48:09 agreed with dbaron 08:48:12 q? 08:48:16 ack fremy 08:48:17 +1 to dbaron 08:48:40 fremy: I've seen a lot of websites using letter-spacing for not letter-spacing itself; icon fonts and aligning, letter-spacing of 1px because "it looks better on my PC", ... 08:49:13 fremy: I'm concerned it'll be a lot of webpages, but I"m not sure how to figure it out. 08:49:37 I think dbaron made the point I was trying to make, but much more elegantly than I did 08:49:57 TabAtkins: Do a good collection of affected pages via a crawl, then we can just sample them to whatever accuracy you want. Basic stats. 08:50:10 or at least provide URLs to illustrative examples (didn't see any in the issue) 08:50:16 koji: I'm not clear on the next actions. 08:50:23 (illustrative real world examples, not artificial data URls etc.) 08:51:09 koji: I think someone has to do a collection and figure out whether it's problematic or not. 08:51:16 s/not./not?/ 08:51:38 myles_: Someone somewhere has to prove that an impl that follows the spec is not web-compatible. 08:52:22 TabAtkins: WG likes the current spec, and puts burden of proof on implementations to prove that it's not Web-compatible 08:53:36 TabAtkins: Need to evaluate pages where they have negative right margin that matches to the letter-spacing 08:53:46 TabAtkins: And then see if they are actually broken 08:53:57 koji: So who will do this? 08:54:08 myles_: Whoever wants to change the spec. 08:54:17 koji: Spec has been there for five years so far... 08:54:24 fantasai: Yeah, nobody has stepped forward to implement this. 08:54:29 fantasai: We want a spec and impls to match. 08:54:39 fantasai: So first option is somebody impls and ships and sees what trouble they have. 08:54:49 fantasai: Second is somebody does a crawl and checks the stats. 08:55:09 fantasai: Broken vs sligthy suboptimal; we dont' carea bout latter, because w'ell fix a bunch more pages. 08:55:23 fantasai: Third is we do what we did with control characters, where we all ship at same time. 08:55:45 Florian: Option 1 where things just ship, there are release channels for early info... 08:56:23 bdc: I don't see how the crawl is possible really - the margin might be a little different than th espacing, they might have negative spacing and positive margin... 08:56:36 fantasai: position margin is fine; it doesn't cause overlapping that hurts readability, just puts in a larger gap. 08:56:51 bdc: So I'm in favor of just keepign the spec as it is. 08:56:53 liam has joined #css 08:57:04 fantasai: So in favor of moving forward, do impls have a pref on which strategy to use? 08:57:19 koji: To me this is a nice feature, but not worth spending a week doing a crawl. 08:57:28 koji: So I'd much rather have another property that does opt-in. 08:57:33 fantasai: That won't give us useful information. 08:57:45 fantasai: Majority of people aren't paying attention to this, or aren't caring enough to do anything about it. 08:58:12 myles_: I think, going along with Elika, you can track the # of times you encouter a website that uses it, but that's only useful as a fraction, and you don't know the denominator. 08:58:31 myles_: I can say 1k websites use the property, but we don't know how many sites considered it and didn't use it because it was bad for them. 08:58:50 fantasai: [repeats three options] 08:59:38 fantasai: And I think the WG is generally agreeing that changing the spec isn't a valid fourth option. 08:59:52 Bert: Gradual change; reduce it by half this year, then quarter next year, eventually it's nothing. 09:00:32 Rossen: So I don't think we did very good with the third option. 09:00:43 Rossen: Anyone want to do option #1? 09:00:47 [crickets] 09:00:54 Rossen: Anyone wants to crawl? 09:01:15 [crickets] 09:01:22 Rossen: So we're at same position as before. 09:01:32 fantasai: Question on #1 - we had zero interest in impl and shipping it. 09:01:46 fantasai: But if someone was to give you a patch, you just had to ship it, then what? 09:01:57 myles_: I'm happy to investigate it. I'll impl and see if it doesn't work. 09:02:18 Rossen: Sounds good. 09:02:24 s/investigate it/investigate it, I want to make this work/ 09:02:24 I think Gecko would be happy to try taking a patch. 09:02:39 Probably don't have the resources to do it in the near future. 09:03:05 ACTION Myles to investigate changing letter-spacing impl to match spec regarding spacing at start/end of element. 09:03:06 Created ACTION-857 - Investigate changing letter-spacing impl to match spec regarding spacing at start/end of element. [on Myles Maxfield - due 2017-08-11]. 09:03:19
09:03:26 github-bot, end topic 09:03:38 ACTION: fantasai to write test cases 09:03:39 Created ACTION-858 - Write test cases [on Elika Etemad - due 2017-08-11]. 09:09:10 rachelandrew has joined #css 09:22:09 bdc has joined #css 09:23:51 Florian has joined #css 09:24:21 Topic: bidi mixed directions 09:24:51 Topic: letter-spacing and word-spacing applied to which side 09:25:03 github topic: https://github.com/w3c/csswg-drafts/issues/1517 09:25:16 koji: Problem from user perspective is that when letter-spacing is applied to a bidi-mixed string, Blink and Gecko has sometimes no l-s, sometimes double l-s, it's hard to predict. 09:25:23 koji: WK and Edge add even letter-spacing. 09:25:37 koji: It's not specced in CSS2, CSS3 defines quite different algorithm that solves this problem. 09:25:42 q+ 09:25:46 koji: But it requires some complex impl. 09:25:59 fantasai: CSS3 just says letter-spacing is applied after bidi reordering. 09:26:24 myles_: If we end up shipping what we resolved in the last topic, I tink that'll mean that the Blink behavior of switching which direction you add l-s to, you won't need anymore. 09:26:29 https://www.w3.org/TR/CSS21/text.html#spacing-props 09:26:39 myles_: bc then letter-spacing isn't on "left" or "right", it's on "inside". 09:27:08 fantasai: 2.1 defines it as "between characters" - double or nothing is just wrong. 09:27:08 CSS2.1 defines letter-spacing as "between" characters 09:27:52 CSS3 is more precise "between adjacent typographic characters, after bidi reordering". No ambiguity. 09:27:56 https://drafts.csswg.org/css-text-3/#letter-spacing-property 09:28:09 s/CSS3/fantasai: CSS3/ 09:28:19 myles_: So what's the proposal, making it legal to have double/nothing? 09:28:28 koji: Proposal is to match WK/Edge. 09:28:31 myles_: Oh, okay, great. 09:28:43 myles_: So that's what the spec already says, right? 09:28:54 koji: If spec says between chars, this might be an impl issue. 09:29:04 koji: Most impls apply it to the left or right of characters. 09:29:20 koji: Edge and WK apply it to the line-right direction, so always "to the right" regardless of direction. 09:29:44 fantasai: ANd if we apply the previous topic's resolution, the user can't tell whether it's line-left/right. 09:30:01 koji: Blink/Gecko apply it to end edge. 09:30:16 Florian: Can't you detect it with backgrounds? 09:30:41 fantasai: No, l-s doesn't occur at a boundary; the l-s at a boundary is determined by the element containing both of them. 09:30:44 s/end edge/end side of resolved bidi direction/ 09:31:00 dbaron: I think the current spec is solid, just a decent bit of work to implement. 09:31:15 astearns: So reading of issue is just that Blink/Gecko need to change behavior to match spec? 09:31:20 koji: Yes. 09:31:34 RESOLVED: No change, Blink/Gecko require bugfixes. 09:31:52 Topic: Applying letter-spacing after line breaking 09:32:10 github topic: https://github.com/w3c/csswg-drafts/issues/1509 09:32:14 koji: As fantasai just mentioned, diff between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder. 09:32:27 koji: But bidi-reorder applies after line-breaking, 09:32:40 CSS2.1 implied after bidi-reorder. L3 specifies explicitly 09:32:44 koji: Which can change the number of "between" spaces there is to add letter-spacing. 09:32:56 koji: So after we add letter-spacing, the line width can change, shorter or longer. 09:33:08 koji: So I think this is a worse issue than what it's trying to solve. 09:33:27 fantasai: You ahve to include the letter-spacing when figuring out sapcing and line-breaking. 09:33:42 fantasai: This is same as kerning. 09:33:48 koji: We don't redo kerning after bidi. 09:34:07 koji: Because changing line widths after break is really bad. 09:34:26 fantasai: Yeah, def don't want to change line-width afterwards, that's bad. 09:34:39 fantasai: So that measn you have to consider letter-spacing before breaking the line. 09:35:02 fantasai: But since bidi-reordering happens after breaking the line, you won't know where the letter-sapcing goes until after doing the reordering. 09:35:13 myles_: Do you have an example of this breaking? 09:35:24 koji: [looks it up] 09:35:35 antonp has joined #css 09:36:46 koji: Last bit of example 16 in Text. 09:37:07 koji: There's a 2em spaccing between the characters in the span, but reordering separates the letters. 09:37:29 myles_: I understand now. 09:38:07 fantasai: If you have that example, bidi-reordering puts two letters nexxt to each other that weren't next to each other logically, do you perform shaping and kerning between them? 09:38:23 myles_: Ours won't cross bidi boundaries. 09:38:59 koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering. 09:39:10 koji: I believe we're trying to match Gecko's behavior. 09:39:27 fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go? 09:39:43 fantasai: Per spec, you don't put the letter spacing between letters of the element and letters outside the element. 09:39:49 fantasai: So I see you point that it's hard to measure correctly. 09:40:10 koji: If we follow Edge/WK impl and resolve the previous l-s topic, there should be 2em space on the right of C. 09:41:07 TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter. 09:41:39 fantasai: Example: you ahve a para with 1em letter spacing. Inside you have a span with 0 l-s. Between the last letter of the span and first letter outside the span, there's 1em letter spacing, where does that attach? 09:42:05

f_o_obar_f_o_o

09:42:13 fantasai: Another span with borders and padding. You do linebreaking calcs. 09:42:38 fantasai: Then you cut the line and do bidi reordering, but it has b-d-b: clone. Now you have two pieces with padding around them, where befor eyou had only one. Now what? 09:42:50

f_o_o_bar_f_o_o

, rather 09:43:04 koji: I was reading b-d-b for the first time this morning, and thought of that exact problem. 09:45:55 dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders. 09:46:28 koji: But you don't know how linebreaking will happen yet. 09:47:09 TabAtkins: If there's only enough room for 4 letters, so the "c" and the aleph are next to each other, is that still two independent spans? 09:48:11 dbaron: We don't unclone them - they stay separate fragments. 09:48:27 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2F 09:48:27 p%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E 09:48:42 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292 09:48:46 dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out. 09:48:56 fantasai: I think it's okay to allow impls to do that. 09:49:05 projector has joined #css 09:49:34 Rossen has joined #css 09:49:53 TabAtkins: So the c and aleh would still be considered separate fragments, even though they are adjacent 09:50:04 shans has joined #css 09:50:05 TabAtkins: and the letter-spacing between them would be controlled by the parent 09:50:35 sylvaing has joined #css 09:50:58 fantasai: I like this solution 09:51:05 leaverou has joined #css 09:51:23 TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest 09:51:36 plinss has joined #css 09:51:38 TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that 09:52:32 koji: So we'll lose the letter sapcing between bidi runs. 09:52:46 TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing. 09:53:59 Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking. 09:55:40 Topic: line-break: break-all 09:56:10 github topic: https://github.com/w3c/csswg-drafts/issues/1561 09:56:20 Florian: line-break:break-all isn't a great name. Should we find a better name? 09:56:27 Florian: I think all names are bad, but I can't come up with a good one. 09:56:38 Florian: This value allows line-breaks everywhere. 09:56:57 Florian: word-break:break-all allows for breaks between letters, but not between punctuations, spaces, etc. 09:57:21 line-break is terminal wrapping, word-break is just hyphens-wherver-you-want 09:57:42 Florian: Trying to do better ignoring web constraints is hard, trying to do better *with* web compat is near impossible. 09:57:53 Florian: line-break:break-all is the newest one, with best chance of renaming. 09:58:00 Florian: Unforutnately it's got the best name, I think. 09:58:15 koji: I don't mean it's badly named, just that same keyword on similar property doing differently is confusing. 09:58:25 koji: Particularly if we have a shorthand for both hof these. 09:58:42 fantasai: shorthands can do custom syntax; we'll definitely redesign the whole thing if we do a shorthand 09:58:53 fantasai: Shorthand would be *great*, we can make it all make sense 09:58:57 zakim, shut up and go awya 09:58:57 I don't understand 'shut up and go awya', TabAtkins 09:59:12 koji: I understand it's possible, but if we're naming now, why choose "break-all"? 09:59:17 fantasai: We didn't have a better one. 09:59:28 koji: Line-break:terminal? 10:00:01 Rossen: anywhere? 10:00:07 Rossen: any? 10:00:09 Rossen: all? 10:00:24 TabAtkins: That would force a break between every character 10:00:27 [a few people like anywhere] 10:01:11 Rossen: anyone care? 10:01:16 TabAtkins: I think re-using the keyword is bad 10:01:22 [several other ppl care] 10:01:32 Rossen: So from the people paying attention, any objections to renaming break-all to anywhere? 10:01:36 dbaron: How widely implemented? 10:01:41 fantasai: Nowhere, it's new, we added it this year. 10:02:08 RESOLVED: Rename line-break:break-all to line-break:anywhere. 10:02:45 Florian: I have a PR for this change; other than me changing this keyword, can the editors approve it or tell me what's wrong? 10:02:48 fantasai: Yeah, at lunchb. 10:03:08 RESOLVED: After edits from this meeting, publish new WD of Text 3. 10:03:17 Topic: text-spacing fullwidth punctuation collapsing 10:03:35 github topic: https://github.com/w3c/csswg-drafts/issues/1668 10:03:46 Florian: In CJK, full-width punct takes a full-width box, but they visually fill half o fit 10:04:06 Florian: Japanese expects that when they're next to each other (like two close-parens), there will be a big space. 10:04:36 s/there will be a big space/there will not be a big space, they'll be collapsed visually/ 10:04:48 Florian: The font contains spaces, but it needs to be canceled out in some cases. 10:04:56 Florian: We have a rule in Text 4 that says when to do this. 10:05:08