00:00:29 florian: which is what has happened in the TV world 00:01:32 topic: dark mode 00:01:35 github: https://github.com/w3c/csswg-drafts/issues/3299 00:02:32 fremy has joined #css 00:02:35 ScribeNick: heycam 00:02:53 futhark: Chrome is soon shipping dark mode for the UI of the browser itself 00:02:59 ... respecting the dark mode setting of the OS 00:03:07 ... but we also want to render the pages dark 00:03:12 ... so the MQs 5 hsa prefers-color-scheme 00:03:18 ... letting the authors follow the setting the user has 00:03:31 ... but in order to render the content dark for all pages from day 1 00:03:43 ... we're looking at a UA intervention that automatically darkens the web pages 00:03:49 ... but giving the author the possibility to opt out of that 00:04:01 ... and we have looked at a element that Apple has already implemented 00:04:15 ... what it does is that you can specify which color schemes the page can respond to using MQs 00:04:29 futhark has joined #css 00:04:35 ... and apply a UA style sheet which renders form controls dark, having a lighter foreground color, using a black canvas backgrdop 00:04:41 ... this is basically what safari does 00:04:57 ... the proposal here is that we do this with a element 00:05:08 emilio: also the CSS property? 00:05:14 futhark: the CSS property I haven't mentioned yet 00:05:34 ... there's the posisbility for the page saying that parts of the page are styled itself, but also the possibility to do automatic darkening of other parts of the page 00:05:38 ... we get this request for various Google products 00:05:44 ... where they want to handle some UI parts themselves in dark 00:05:50 ... but automatically darken some content 00:05:57 q+ 00:06:15 smfr: we have to distinguish between auto darkening, which is clobbering what the author's done 00:06:23 ... and this thing, which allows the author to tell us they've thought aobut dark mode 00:06:33 ... for us this is jus chanign form controls, selection, ... 00:06:37 q+ 00:06:40 ... an auto darkifying thing is maybe orthogonal to this 00:06:59 futhark: what we've been thinking about is that the element at the same time it says it wants the dark UA style, it would also opt out of the auto darkening 00:07:05 ... because it knows how to render dark pages 00:07:26 futhark: when the author has a saying it knows how to render this page in a dark color scheme, please opt out of auto darkening 00:07:41 ... one of the reasons we've been thinking about is that we don't want any flash of white background 00:07:45 ... so having it available early 00:07:57 ack db 00:07:59 q+ 00:08:02 q+ 00:08:06 dbaron: I agree with a bunch of what Simon said 00:08:22 ... there's a long standing problem we've had which is that when we use native form controls and certain things like that, if the user has a dark theme, those don't work with some pages 00:08:43 ... e.g. text input is a common one. if the text input has a dark background with a light text color, and the author overrides only one of bg/fg, it's broken 00:08:54 ... as a result we've done work to prevent dark native themes to get through to web content 00:09:01 ... some recent Gtk changes broke this 00:09:23 ... so I think there are a few separate problems here 00:09:40 ... one is the fact that because of these dark theme options in macOS, Windows 10, etc., more users have dark themes 00:09:48 ... and in a lot of web contne tthat doesn't work, even if they want it to work 00:09:57 ... but we can't just go apply it to web content unless we know it will work with that 00:10:06 futhark: that's why we want to rely on the meta element to have the page tell us it's ok 00:10:20 dbaron: I think a meta that says "I the page author have thought about this and I know that my page will work with a dark theme" is a good thing 00:10:25 ... I think UAs could use it for different things 00:10:41 ... one could use it to say "the user has a dark theme, so I will let dark theme data theme, and use the user's preferred form controls for this page" 00:10:52 ... or the UA could say "for pages that haven't done this, do auto darkening" 00:11:05 ... and a meta that says "I suppor tdark theme" serves both of those purposes but not completely 00:11:18 ... if the user wants the entire thing to be dark, working with dark form controls doesn't imply that their whole UI is dark 00:11:24 ... so they still might want the auto darkening in that case 00:11:40 ... another thing in here I don't like. it also allows authors to say that their page doesn't work with light pages 00:11:46 ... and I'd rather not create this problem 00:11:54 futhark: the only keyword? 00:12:02 dbaron: you can say supported schemes "dark", and skip light 00:12:32 ... in the spirit of trying to do more of what the user wants, where right now users want to see things in dark mode, I'm hesitant to give authors an option to say this page doesn't work in light mode 00:12:35 ... for users who want that 00:12:52 futhark: there's also the "only" keyword that Safari implements 00:12:57 ... don't you have to say "dark only"? 00:12:59 smfr: [nods] 00:13:38 futhark: if you have a light theme and say "dark only" in the meta tag, you get the authored dark page 00:13:43 dholbert: and widgets are dark? 00:13:46 smfr: primarily widgets 00:13:57 ack fr 00:14:08 fremy: I am very curious about how you're going to enforce dark themes on pages that aren't prepared 00:14:12 ... I'm skeptical people will like that 00:14:18 ... you'll end up with images that look wrong etc. 00:14:25 ... for a11y purposes it's a fair tradeoff 00:14:49 ... but I am very unsure that people going to bing.com that doesn't support dark theme now the links aren't visible 00:14:52 q? 00:15:09 futhark: auto darkening is not something we'd like to spec 00:15:19 +1 to fremy 00:15:22 fremy: otoh, replying to david, I don't see why you'd want dark only 00:15:29 ... in VS Code, a web app, it has dark menus 00:15:35 ... it makes sense for them to say "dark only" 00:15:39 ... they want to control all their app UI 00:15:50 ... if you're talking about wikipedia, they should probably not say "dark only", but I don't think they will do that 00:16:09 ... maybe for a powerpoint thing, if the author has thought about it, why prevent it? 00:16:27 dbaron: one of my worries about this stuff is that not all browsers will be able to do all of these things 00:16:42 ... if we want web pages to be able to say "dark only", the browsers need a native set of light and dark controls 00:16:46 ... which on some platforms is not realistic 00:17:20 fremy: you can always have a normal styled fallback for form controls 00:17:28 ack fl 00:17:33 florian: that's the difference between I prefer dark and I support dark only 00:17:49 slides from the earlier high-contrast discussion: https://lists.w3.org/Archives/Public/www-archive/2019Feb/att-0000/CSSWG_F2F_High_Contrast.pdf 00:17:54 ... if you don't have dark controls, and your OS doesn't have them -- that's different from saying "if you show light controls I will be broken" 00:17:56 ... we shouldn't have that 00:18:02 ... why create that category? 00:18:10 ... there are some that would look better with dark controls 00:18:14 fremy: VS Code only has dark controls 00:18:19 high constrast explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md 00:18:24 ... why do they custom style everything? because they can't get dark controls 00:18:32 ... I think what you're saying exists today 00:18:38 ... but the web page custom styles every single thing 00:18:52 florian: if the OS doesn't support dark controls? 00:19:01 fremy: you fall back, just like when you put borders on form controls 00:19:13 q+ 00:19:17 florian: so VS Code will still need to hand code their dark controls, since they can't handle that some OSes will fall back 00:19:30 fremy: today the light controls have this fallback today 00:19:35 q? 00:19:43 ... if you have a button border-radius:3px, you get the fallback rendering 00:19:49 ... and you can do this same fallback for the dark one 00:20:00 high contrast explainer archived: 00:20:02 https://lists.w3.org/Archives/Public/www-archive/2019Feb/0001.html 00:20:10 dbaron: I think there is a tradeoff here. some sites that want to own things so much they will replace the native controls 00:20:20 ... there's a tradeoff betwene that and having sites where the controls are more recognizable as such to users 00:20:28 ... and the users recognize the thing over there is an input field 00:20:32 ... that's a tradeoff 00:20:40 ... there's an advantage to contrls that look native 00:20:46 ... esp for less experienced users 00:20:58 ... if we offer more ability to change what the controls look like, we will pull some designers away from replacing everything 00:21:07 ... but we will also push some users into things that are less recognizable for them 00:21:14 ... there's no one answer is more correct 100% 00:21:52 florian: afaict, the property here, whether it has a bunch of properties or auto vs i-support-dark, does the same thing at the meta tag? just at a subtree granularity 00:22:06 ... whether or not you suppor tdark theme depends on the style sheet, so it belongs in the style sheet rather than meta tag 00:22:13 ... I know I will not get full agreement on that 00:22:18 gregwhitworth: for end user experience reasons 00:22:31 florian: but it could become wrong when you update the style sheet and forget to update the meta 00:22:33 gregwhitworth: bad author 00:23:03 florian: if you have a page that claims to support dark mode, the author sheet does support dark mode, but user sheet doesn't -- how to tell the page? 00:23:16 ack Am 00:23:24 futhark: the property wins 00:23:51 AmeliaBR: I'm a bit uncomfortable doing style theming in the meta tag because you might have all sorts of flexible themings based on user prefs based on your own thing 00:23:57 ... but as long as the style property overrides the meta tag, that's ok 00:24:03 ... but then I'm not sure why the meta tag is necessary 00:24:15 ... if the style sheet sdon't load, I'm assuming the browser can apply whichever one 00:24:23 futhark: if you parse the meta tag, you can apply the black canvas pretty early 00:24:26 fremy: it's about flashing 00:24:44 AmeliaBR: is there any reason to do the flashing? if the style sheets haven't loaded can't you have a default bg that is according to the default theme? 00:24:49 smfr: every wikipedia page will flash 00:25:02 AmeliaBR: ok that's the point of the meta tag, for the default backdrop before style sheets load 00:25:06 fantasai: use bgcolor on body? :) 00:25:32 ... I totally agree this is not something that belongs in the HTML layer if possible 00:25:38 ... if you want to put it there, we have bgcolor 00:25:49 ... the best thing there is you can solve that for any background color 00:25:59 AmeliaBR: not necessarily because what if the style sheet has a MQ switch based on user preference 00:26:04 fantasai: then it will override, but that's better 00:26:12 AmeliaBR: you can indicate which themes you support 00:26:23 fremy: bgcolor can only supply black, not "which theme the author supports" 00:26:40 fantasai: you're only doing this for white or black -- is this a big problem? 00:26:53 TabAtkins: if I'm looking at dark screens in bed, I don't want a big flash of white 00:27:17 AmeliaBR: why would wikipedia put a meta tag saying "dark only"? 00:27:30 florian: they won't hae the tag, so you know it's a light site, but you can still show dark until it shows up 00:27:47 [wikipedia just as an example here] 00:28:18 AmeliaBR: my other point, repeating some of fremy, if there's any discussion about auto applying styles without author opt in, that should be discussed in the context of accessibile color schemes, high contrast mode, think of it that way 00:28:27 ... when you're overriding author styles it's an a11y feature 00:28:33 ... but that's separate from trying to match user preferences 00:29:09 ... for matching user prefs, I like the idea of making it easier for authors to say this site supports a dark theme, draw default styles for select boxes, if you have one, or saying my styles work well whether you use light or dark whichever the user prefers 00:29:31 ... there are sites that are dark that require custom styling for form controls now, so I like the easy way to opt in to native dark mode styles 00:29:33 +1 00:29:38 ... we kind of have multiple themes now in browsers 00:29:46 ... the "legacy" widget themes, if you much around with styles 00:29:58 ... then we have the modern native look buttons in light or dark theme 00:30:11 ... I don't know how is the way the prop is currently specced going to interact with that? 00:30:23 ... when you revert to the legacy styles 00:30:26 futhark: I don't have an answer for that 00:30:41 AmeliaBR: if you use this prop are you saying "use the native UI look no matter what other styles I put on the element?" 00:31:09 smfr: still has these fallbcak interactions 00:31:47 AmeliaBR: so if I wanted styles that say use native dark mode, but if you don't support these new props, and if I want a custom styled dark inputs, you'll need @supports or something? 00:32:08 ... will @supports just look at syntax, don't say you support dark mode unless you have one to use 00:32:14 ... but that would break an author request of dark or light 00:32:28 ... so the keywords need to be recognized even if they don't have matching themes 00:32:37 ... can sites detect "do you have a native dark theme"? 00:32:41 emilio: that's a fair request 00:32:50 ... an author to see if the browser suppotrs a native dark theme or not 00:33:04 ack emilio 00:33:06 ... it feels to me that the auto darkening has a lot of potential to backfire 00:33:38 ack bdc 00:33:46 bdc: I think there are 2 different issues 00:33:48 +1 to emilio 00:33:54 ... one is that it makes a lot of sense for a page to fit into its environment 00:34:31 ... the other use case, which I disagree with, is fremy's example of "I'd prefer a dark theme for my app so I will just use theme by requesting dark controls" 00:34:34 ... it's a design shortcut 00:34:38 ... it's a differnet purpose IMO 00:34:45 ... VS Code is not designing that because they don't have access to a dark mode 00:34:52 ... they just design it that way 00:34:58 ... to me it's a different use case 00:35:12 ... to want to re-use a set of controls that are nicer to the designer's eye is different from fitting to the environment 00:35:14 +1 00:35:21 fremy: the #1 request we got for controls in Edge is sites wanted dark scrollbars 00:35:32 ... we don't want to customize the scrollbar, we just want a dark one 00:35:39 ... when they do customize it, we get perf issues, etc. 00:35:50 I would like to point out that Adobe Creative Suite uses dark mode for its UI, but the expectation is that content being edited is black-on-white, so it's not that you always want to match content to the OS "theme". 00:35:57 +1 same we get requests for dark scrollbars primarily 00:36:00 Sometimes. not always 00:36:01 ... that's the point of this prop, this area of the page is dark, it's a choice we made, but we want to play nice with native controls 00:36:05 ... for better UX for users 00:36:22 ... also, let's say you have a blog engine, you want to support dark theme 00:36:27 ... so you say the page supports light and dark 00:36:36 ... an embedded component from another origin, it only supportslight 00:37:02 ... you need to have a way to say this part of my webpage does not support dark theme, even though my site overall does 00:37:06 ... this is the point of the property 00:37:29 ... incorporating components from different sites, you might not want to give up your overall site dark theme 00:37:44 ... the "dark only" value might not be useful ... 00:37:51 ... I have seen sites that just want a dark scrollbar 00:38:09 ... and you need "light only" anyway 00:38:53 AmeliaBR: anothe rexample, you're concerned it's not respecting user prefs 00:39:07 ... for somethings I like a dark theme, but if I'm reading a lot, I can't read a lot of white text on black bg 00:39:13 ... so I'm going to have different prefs for different sites 00:39:22 ... maybe browsers will one day allow me to set prefs on a per site basis 00:39:29 ... but lots of sites have a way for the user to opt in to a theme 00:39:40 ... so maybe when they're doing "light only" or "dark only", they're reflecting the user's preference in the site 00:40:05 bdc: the way I would summarize is that letting the browser know that you are dark theme compatible is nice, a good citizen in this environment 00:40:10 ... doing the opposite is being hostile to the env 00:40:16 ... whatever you choose, I'm going to have dark, because I like it 00:40:30 fremy: but you could have a theme inside the app 00:40:40 AmeliaBR: we can encourage authors to make their sites theme flexible 00:40:43 ... just like responsive sites 00:40:53 ... but I don't think a dark only is any more hostile than saying background-color:black, etc. 00:41:11 ... it's just one way for the author to opt in to a color scheme without setting everything themselves 00:41:17 ... and making it a bit more native and familiar 00:41:24 bdc: I see that, but it really depends on how many things in the UI that change 00:41:41 ... e.g. at some point I think Edge had a title bar that matched the site header color 00:41:53 ... here you're forcing UI changes because use as an author prefer black 00:41:58 ... it might be pushy 00:42:23 Rossen: we used to have a mode that when you pin a site to the taskbar or start menu and you want to use it exclusivle in an app mode 00:42:33 ... we would do small things to match the page 00:42:42 ... that was the behavior we did 00:42:49 bdc: this kind of thing can have an impact on the UI as a whole 00:42:57 ... who knows what the OS will do in the future 00:42:59 myles__ has joined #css 00:43:01 ... so it could affect more things 00:43:09 AmeliaBR: good point but it sounds like it's outside the scope of CSS 00:43:25 ... anything the browser/OS is doing to extract styles from the page and applying outside the page ... 00:43:33 bdc: these properties and meta tags would do that no? 00:43:36 florian: just within the page 00:43:52 AmeliaBR: the only thing outside we can style with CSS is styling the dark/light bg of the canvas 00:44:00 bdc: the chrome of the browser could/should change based on that 00:44:16 gregwhitworth: the way I would see this working in Edge, user turns on dark mode, Edge would flip into dark mode, devtools would too 00:44:27 ... if you have the meta tag, it would flip to dark controls too, if not, it wouldn't 00:44:29 s/outside we can/outside what we can already/ 00:44:34 ... is there an issue with that? 00:44:36 bdc: not with that 00:44:52 ... but in the future making the assumption that if the site opts in that other UI is now dark, then I do 00:44:59 dholbert: alerts could be dark 00:45:07 gregwhitworth: they're not controlled by you now anyway 00:45:23 AmeliaBR: that's an issue on the browser team to decide whether to respond author or OS choices ... 00:45:40 q? 00:46:08 Rossen: the one thing to keep in mind is that at least in Windows, probably on macOS, we have three levels of where color schemes can apply 00:46:15 ... there's the shell, which is only controlled by the user 00:46:22 ... usually it doesn't propagate anywhere beside the shell 00:46:41 ... then there are apps. apps are going to depending on the UI framework they use, they may be either forced or opt in to a particular color theme 00:46:47 ... regardless of it it's dark or whatever 00:46:51 ... then there's the content of these apps 00:47:01 ... even besides browsers. many other apps that have content that could benefit from theming 00:47:12 ... and there, it's the choice of the app on whether to propagate that information to the content 00:47:24 ... a quick survey of 1st party apps that ship with Windows or macOS, even there is some inconsistency 00:47:35 ... e.g. in Windows the shell is always dark, doesn't mean 1st party apps will always be dark 00:47:46 ... at the same time, in Edge, there's a user choice to change the UI to be dark mode only 00:47:58 ... changing the UI of the browser alone doesn't fit with anything else if the shell is light 00:48:10 ... for these cases, to say that because I'm switching my app to be dark, I want everyhing else inside to be dark 00:48:16 ... Mail doesn't usually force content to be dark by default 00:48:25 ... looking at macOS Mail, it seems this is only done for text only messages 00:49:18 ... propagating this down to the site and alowing the site to say "yes I'm fine if you are going to change your UI, regardless where the change came from, I'm going to match it a bit better" 00:49:55 ... so I think the overall approach of this proposal doesn't seem crazy, it's just that how do we get to the point where the actual handshake between content and the app layer becomes as transparent/easy as possible 00:50:23 ... most platforms today have these 3 tiers of color scheme propagation that, whether or not in this group agree, is irrelevant 00:51:34 futhark: one of the things I wanted to figure out is if a meta tag is the right way to do this 00:51:47 ... the standardization of a meta tag typically doens't happen in CSS 00:52:04 Rossen: what are you optimizing for here? style sheet download, so that before you navigate you want the right theme applied without flashing? 00:52:19 ... if you're going from page to page on wikipedia, and let's say wikipedia had a dark mode, you don't each navigation flash to white 00:53:04 ... if we're ok with flashing, then meta tag or property or alternative style sheet would work 00:53:13 smfr: we're not ok with flashing 00:53:23 ... asked one of our engineers about the meta tag proposal 00:53:41 ... there are clients other than browsers, like mail client, it's useful for them to be able to parse the first part of the message without a css parser 00:53:46 ... I think that's the primary reason 00:54:03 florian: I'm personally not enthusastic about the meta tag, but I understand why you need it 00:54:11 ... and as long as you have the property, that's fine 00:54:44 q? 00:54:58 bdc: the only change you're contemplating is form controls, canvas 00:55:22 futhark: foreground color, background color 00:55:30 s/canvas/root viewport color/ 00:55:30 I'm curious if a ` works by default. Changing it to doesn't work; you have to manually set `height: auto` in CSS too. 21:30:07 jenn: i do think there's a way to do it that hooks into cms's and existing things, instead of making it more complicated 21:30:16 s/jenn/jensimmons_ / 21:30:16 s/alan/astearns/ 21:30:21 jenn: if only width is coming out of a cms, and there's no height, there's no mapping to intrinsic, we can map with that limited data 21:30:42 jenn: maybe there's something more complex needed, and we do both, i think there's an elegance here tapping into what we already have. perhaps that's what ojan is intending 21:31:18 jenn: hey, we're going to solve some of this in css, and to have that really heard, .. that's what i'd like to see happen 21:31:25 rosson: where does this leave us 21:31:38 s/rosson/Rossen / 21:31:44 jenn: sounds like someone's going to find something out 21:31:51 (thanks for the correction y'all!) 21:31:54 (thanks for the corrections y'all!) 21:32:24 amelia: i think it's great, we're leveraging something that already works, but i think i agree with the arguments there's too many cases where things can get messy for repurposing 21:32:55 amelia: if browsers implemented the attr function that values to lengths, ... any image, grab these values, put them together, here's the ratio 21:33:11 amelia: not sure if there's utility if no one's has implemented it yet 21:33:13 +1 to what AmeliaBR just said 21:33:30 maybe that could even be included in a project called CSS Remedy 21:33:52 tab: i feel like there's just more discussion, but in the way of being explicit with cases and approaches, and i dont know if i want to spend time trying to nail it down 21:34:10 elika: there are advantages of usign existing attr(), like for images out there, we get the faster layout/loading for free. info is already there 21:34:36 no updating cms, no html file updates, it would let them hook into it via current functionality 21:34:37 s/attr()/attributes/ 21:35:11 jenn: there's 100's of sites that put height and width on things. then in their code, height 100% in their code. decade of work built that way, and likely arent maintained 21:35:22 s/100's/100,000s/ 21:35:25 jenn: quick way to boost all sites 21:35:29 s/on things/on images in the cms/ 21:35:50 jenn: don't get deep into picture element, ..., hey this is a performance thing, but it back in and it'll be faster 21:36:07 jenn: other proposals will use it for be used for simple and complicated things, and some it'll be too much 21:36:13 s/height 100%/width 100% height auto/ 21:36:44 elika: historically, we've asked users to put weight and height on them, back into the 90s, and hooking into that advice, it hooks into content and knowledge better. it wont just work on new things for people keeping up with latest things 21:36:58 tab: happy to do more discussion, but not confident enough to decide now, or for us 21:37:07 chris: maybe we could break out and talk about it? 21:37:15 s/chris/chrishtr / 21:37:21 chris: i dont think i fully understand, and I'd like time for that 21:37:45 rossen: ok so, i didnt hear that say the HTML width and height attributes is the worst idea i've ever heard, we shouldnt do it 21:38:03 rossen: i also didnt hear we shouldnt think about the intrinsic aspect ratio, because it'll just work 21:38:12 rossen: tab has committed to work on this fully 21:38:19 tab: chrome people will be working on this 21:38:39 rossen: kidding aside, we'll close this issue for now. thanks for introducing it to the working group, and making it an actual proposal 21:39:06 rossen: i think there was another bit in this, which was css property, which will then have to map using either the height or width attributes, as a ratio, or whatever else is there, if anything is added as an additional attribute 21:39:20 rossen: i think the property can be discussed at a later point, or is this something you want to discuss later today 21:39:24 elika: it's already in the draft 21:39:47 s/elika/fantasai/g 21:39:49 jenn: so this discussion about not doing other things in HTML, the stuff we've already talked about, there will be more to talk about aspect ratio with min-height and min-width 21:39:58 s/jenn/jensimmons/g 21:40:10 q+ 21:40:15 jenn: there is a question of: do we put in what's there already in the draft, support for ??, whether it's happening int he UA style sheet, we do have the ability to grab information about height and width 21:40:35 jenn: might be right inbetween, and i think we should do what rossen mentioned 21:40:42 rossen: great point, thank you. before we move on 21:40:50 ack AmeliaBR 21:41:49 amelia: i have a question: it's not being proposed by a web group. before we get a css spec, we need to get that moving up into the HTML wg, so it's outside our scope, so long as it's going through process and getting standardized. chrome pushed it without standarization, we need to make sure that happens 21:42:31 TabAtkins: definitely should be in wicg - we'll get it there 21:42:48 rossen: topic, css inline, first and last baseline 21:42:51 github: https://github.com/w3c/csswg-drafts/issues/861 21:43:11 dauwhe: no opinions 21:43:30 elika: this issue keeps coming up because i dont have any points in favor or against either options, and i'd like to hear why we should pick one over the other 21:43:57 fantasai: do we have the board, do you want the [..] baselines, fantasai explains the problem 21:44:08 fantasai: once you match the baselines, you shift 21:44:19 fantasai: once one of those has multiple lines in it, what do we do 21:44:46 fantasai: do we put it in it's own properly, align baseline preference, and it cascades independently, .. continues explaining 21:45:19 AmeliaBR: reminder: long hands exist for legacy compat. so svg had align, baseline shift, css had vertical align.. they descirbe the same functionality but behave slightly differently 21:45:47 AmeliaBR: ..., adding new features to the long hand, when it's just for compat, seems questionable. also, not sure how first/last would work in SVG. i dont see benefit there 21:46:00 [fantasai outlines things on the easel] 21:46:16 fantasai: we cant add values to the short. so it there's a reason to choose one over the other, it'll help us resolve 21:46:27 AmeliaBR: new property may not be used 21:46:59 fantasai: related issue: from the MATH ML folks, they want to take the baseline not from the first or last item, but from a specific item 21:47:22 fantasai: so that ties in a little bit with this, we dont have a proposal, but we have an idea we should do it. so that might tie into we end up with another that helps us solve this as well 21:47:37 AmeliaBR: i suppose the value of a new property is that vertical align is already supported with current functionality 21:47:58 AmeliaBR: you may end up with duplication anyway 21:48:07 fantasai: does anyone want to think about it more, or push it off to the next 21:48:31 dbaron: i can imagine there's reasons you want them separate, unknown how important they are. consider multiple languages.. 21:48:45 fantasai: alright, we can resolve the issue 21:48:58 dbaron: i'm not convinced anyone will want to do this, but it does seem like a good thing to do 21:49:07 AmeliaBR: resolve to make a new long form property 21:49:20 astearns: we figure the name out later 21:49:24 fantasai: no matter how silly, make suggestions 21:49:37 s/suggestions/suggestions in IRC, we'll evaluate later/ 21:49:41 dbaron (earlier): you might want to set alignment-baseline as a function of the language without messing with the first/last choice set for other reasons 21:49:41 Rossen: ok, any other opinions that can top David Barons? 21:49:49 Rossen: anyone object to david? or oppose? 21:49:56 Rossen: no objections. resolved. 21:50:19 astearns: so, david, could you put your actual suggestion into resolve line 21:50:35 dbaron: the question was a boolean, do we want a separate prop or not 21:50:48 RESOLVED: we'll add a separate property for this 21:50:51 astearns: great 21:50:55 fantasai: thank you 21:51:09 Rossen: next one is an awesome one 21:52:26 ScribeNick: emilio 21:52:50 github: none 21:53:43 github: https://github.com/w3c/csswg-drafts/issues/861 21:53:53 topic: Houdini <3 text 21:54:06 github: https://github.com/w3c/css-houdini-drafts/issues/854 21:56:15 myles_: So, houdini has a lot of stuff, and I think everything is things that browsers do already, which is cool 21:56:30 myles_: there's one of these things that is not in houdini so far, which is text 21:56:54 myles_: so there's a chance that authors are going to want text layout 21:57:30 myles_: there's a lot of ways this could go, text is complicated, and different to other parts of houdini, in the sense that (a) it's pretty easy to get wrong and (b) if it is, users will be misled and confused 21:57:58 myles_: it's easy to get it wrong when things like how BiDi works should work by default, we don't want authors to have to remember how to do these 21:58:14 myles_: there's a bunch of things like that listed in the issue 21:58:30 myles_: so I wanted to discuss how should we approach such an API to avoid causing pain 21:59:20 myles_: a strawman proposal just to get the discussion started would be a region-like API, where your content flows from one box to the other, and regular CSS properties apply in that box 21:59:43 myles_: that'd be very high level. Another approach would be to expose glyph indices and fonts and let the author place all of them 21:59:56 myles_: I think that'd be bad 22:00:06 +1 to that being bad 22:00:47 myles_: So, there are these two extremes, these high-level things, and there's this low-level thing which we can agree it's a bad idea. There's a range in there that we should figure out 22:01:02 AmeliaBR: (summarizing her comment in the issue) 22:01:31 AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355) 22:01:43 q+ 22:01:56 AmeliaBR: There's a lot of steps, like [...], that we need to break this down into. 22:02:00 q+ 22:02:09 q+ 22:02:13 AmeliaBR: within all the individual steps which happen during text layout, we need to figure out which of them authors want to customize. One of them could be justification 22:02:28 AmeliaBR: other things like bidi unicode stuff we don't want to ever expose 22:02:30 q+ 22:02:36 q- 22:02:38 q+ 22:03:21 AmeliaBR: we could expose (though maybe trickier) glyph selection (sounds scary, but there's lot of fun stuff you could do with OT glyph selections instead of having to create a new font because you want to create a space-maximizing layout) 22:03:37 AmeliaBR: that's something that people may want but that is easy to get wrong / break 22:04:26 AmeliaBR: also, the steps are very dependent on one another, so we need to come up with a nice model of the data that goes through the pipeline if we want authors to insert their custom stuff 22:05:05 fantasai: this is not just a sequential pipeline, some of the steps interact with each other. An excellent line-breaking engine will account for glyph selections and such 22:05:07 q? 22:05:19 fantasai: so you can't just break that up 22:05:20 ack fantasai 22:05:32 ack ia 22:05:46 iank_: I think we agree in spirit models, we don't want to get into the bussiness of bidi resolution or glyph selection or such 22:06:04 iank_: we may want to get smarter about where to break and such, but not atm 22:06:57 iank_: the current model in the spec is a box where you run layout giving the avail width and you get back an inline box / line box fragment 22:07:25 iank_: you can re-request that if the resulting height is too big for your layout 22:07:42 iank_: some layouts require the available width to change on a per-line-box basis 22:07:59 iank_: we want to prototype that 22:08:10 q? 22:08:13 myles_: so, I also agree that we mostly agree 22:08:28 s/models/myles_/ 22:09:07 myles_: the idea of giving avail width works well if the area has vertical end, but if you're not a perfectly vertical container it doesn't, it's not clear how much we care for shapes 22:09:25 iank_: in our engine we do at most two layout passes to avoid shapes 22:09:32 iank_^: We care about shapes a lot 22:09:40 iank_: which sort of fits in this model 22:09:52 s/for shapes/for shapes in Houdini/ 22:09:57 myles_: I think doing two layouts is unfortunate, describing geometry would be nicer 22:10:53 iank_: that'd be difficult, a lot of the use cases that devs want to place a line depending on how the previous line has been laid out 22:11:15 iank_: I think describing all the geometry upfront would be limiting 22:11:26 iank_: one of the examples we want to work is an arbitrary line grid 22:11:39 q+ to talk about justification 22:11:47 iank_: the avail width of the next line really depends on the line height of the previous line box 22:11:51 q- 22:12:01 ack da 22:12:31 q+ 22:12:45 dauwhe: My industry is very interested in using houdini to improve justification / hyphenation, since the browsers have different requirements 22:12:46 ack florian 22:12:59 fremy has joined #css 22:13:02 q? 22:13:04 q+ 22:13:10 florian: I share the concern that this is important and hard to let people do a lot of random stuff 22:13:28 florian: but they shared examples for i18n where a lot of effects needs a lot of low-level access 22:13:52 florian: but Japanese people may want to increment distance between some glyphs or such 22:14:00 florian: or implement stuff that isn't in browsers yet 22:14:01 q- because basically florian just said what I wanted to say 22:14:05 q- 22:14:22 florian: the approach of get line boxes doesn't get far enough, but I'm not sure how to get far enough but not being dangerous 22:14:51 +1 to ensuring legibility 22:14:54 myles_: you're right, but we have competing desires, letting authors implement nice effects, and making pages legible, the latter has been historically more of a priority 22:14:56 ack fantasai 22:14:56 fantasai, you wanted to talk about justification 22:15:09 q+ 22:15:45 fantasai: side comment, about justification and the model that is in houdini, which I agree is the right one to get started. For justification would it make sense to return the fragment without filling the available width, but also let the user set it to be wider and that'd trigger justification 22:15:50 ... and alignment 22:16:10 fantasai: that way I can see where it fits much more easily, and position it more easily 22:16:56 fantasai: and justification properties would work the same way it works when you place it in a bigger size. Justification control would still be in control of the user-agent 22:17:00 s/but Japanese/for example, Japanese/ 22:17:26 q? 22:17:29 myles_: dauwhe, when you said for example you wanted to improve justifications, is ^ what you were referring to? 22:17:33 dauwhe: I think we want more 22:17:37 s/Justification control/Justification/ 22:17:49 s/justification properties/justificaiton and alignment properties/ 22:17:57 s/but they shared examples for i18n/but Dave shared examples about hyphenation and justification, and there are many more of the same kind of when you consider i18n/ 22:18:44 Rossen: thanks for bringing the issue, and I'm glad it's getting more and more traction. The one common theme that I see so far is that we are trying to get the "custom" part of layout out of custom layout. Everything that's been discussed so far how to force people to do the thing what we're already doing and tweak it a bit here and there 22:19:14 q? 22:19:25 q+ 22:19:42 Rossen: the nice thing of custom layout is that we're not giving restrictions for where people to position boxes in the block layout case, but when it comes around text we through our hands in the air and say it's too hard, and I don't agree with that 22:19:54 q+ 22:21:10 TabAtkins: We have existence proof that every single custom layout has done bidi wrong. 22:21:18 Rossen: it seems to me that we're talking about levels of customisability 22:21:38 q+ to follow up on Rossen's comments 22:21:46 Rossen: one where you expose bidi and shaping at every breaking opportunity, the other where you give it a box and we'll do the layout inside 22:22:04 q+ 22:22:12 Rossen: I'd be interested to go and explore the options in the middle which would allow most custom layouts that people want 22:22:25 q+ 22:22:28 Rossen: so that we're still not insisting on that rigid one box 22:23:02 Rossen: we're also assuming that we're doing inline layout the way browsers do it now, but maybe my lines are spiral, or I want to go on top of floats 22:23:21 Rossen: let's not try to take the custom part of layout outside of css 22:23:28 q? 22:23:47 ack dbaron 22:23:55 dbaron: I just wanted to bring up another use case that hasn't come up today 22:24:14 dbaron: I think having a low level API is very important for minority languages 22:24:15 [general nodding] 22:24:40 dbaron: Gecko has shipped graphite support 22:24:46 https://en.wikipedia.org/wiki/Graphite_(SIL) 22:24:50 q? 22:26:01 dbaron: one of the things it does is let languages that have shaping requirements that aren't in browsers do it in fonts instead 22:26:12 dbaron: another approach for this would be a low-level JS API using houdini 22:26:20 (I believe "glat" is one of these graphite font tables that dbaron is referencing) 22:26:23 "For example, it may be the case that a minority language is tonal, while the national language is not, and the orthographic solution involves using the standard writing system with some extra diacritics to indicate tone. Or the minority language might have a set of sounds characterized by a certain linguistic feature, such as aspiration or breathiness, that are not present in the national language, and the desire is to add to the standard orthograp 22:26:23 hy a set of variant characters to represent these variant sounds." 22:26:33 dbaron: I think that's a potential real usecase 22:26:53 ack skk 22:27:11 skk: From Japanise digital books perspective, more precise Ruby would be amazing 22:27:47 skk: We'd like more control over ruby text positioning 22:28:19 ack dauwhe 22:28:36 dauwhe: Responding to the phylosophical point, being able to explain and expose all the platform features? 22:28:48 Rossen: it is, what I'm saying is, let's not prevent that 22:29:12 q+ to respond to Rossen 22:29:53 Rossen: so that we can avoid limiting the inner pinnings of how things work. Said that, we want to open the engine so that we don't need to implement all the stuff people want, that's the fun part of it. 22:30:09 Rossen: we've never said "and we don't want to let you do this because it's hard" 22:30:10 s/phylosophical/philosophical/ 22:30:12 Rossen: why? 22:30:13 q? 22:30:40 myles__: if your layout is wrong, the text still exists. For layout no layout is wrong, for text it is 22:30:47 q? 22:30:56 Rossen: if it's unreadable it's unreadable because of me 22:31:12 fantasai: it may be because somebody typed something you didn't expect 22:31:35 fantasai: and you didn't care of thinking of those users 22:31:43 q? 22:31:44 fantasai: and those users are our users 22:31:48 s/layout is wrong/layout is not what the author intended/ 22:31:57 Rossen: that's my problem, those users are going to complain to me 22:32:33 Zakim, close queue 22:32:33 ok, Rossen, the speaker queue is closed 22:32:40 ack koji 22:33:18 koji: From my POV I think "don't do bidi and don't you your own thing" is more "we want to start from simple things", and as we can confirm it performs properly and works we can extend further 22:33:41 koji: but I'm not very confident that JS running through glyphs is performant enough, so box-level layout seems simpler 22:33:55 koji: so re. Rossen's point, we're not against, but we want to start from the simple thing 22:34:23 ack AmeliaBR 22:34:23 AmeliaBR, you wanted to follow up on Rossen's comments 22:34:55 AmeliaBR: I agree with Rossen and dauwhe, the point of houdini is being able to tweak one of the little things the browser does without having to re-implement the browser, and we want to let authors do what they want 22:35:10 q? 22:35:35 AmeliaBR: you can do some sort of custom layout with SVG, but probably badly. we should let authors do what they want without forcing to reimplement what they don't want to tweak 22:36:08 AmeliaBR: I think we should prioritize our work to start with the safest things to change and isolate 22:36:37 q? 22:36:46 ack florian 22:36:50 ack fantasai 22:37:22 agree with AmeliaBR -- we should bias towards coming up with APIs that allow users to benefit automatically from the browser implemented bidi, complex text shaping, etc. features that the author doesn't want to reimplement 22:37:29 make it harder for them to accidentally not support those things 22:37:30 florian: so, I think when we say is "this is too hard", this is not saying that devs in this room are smarter than all of them. But very litte people have resources to implement all the complexities right 22:37:44 florian: very few people have the bussiness justification to deal with all languages 22:37:59 florian: minority languages is where this is interesting and dangerous 22:38:51 florian: the low level things that enable minority languages to work on the web, are also what enable companies to write western-only layouts that don't work on other minority languages that browsers support today 22:39:42 florian: in the process of creating an api that's good enough to support minority languages we'd have created the chance of chinese languages where you only can write in chinese, or english pages that allow you to only work in languages 22:40:12 florian: so if you force people to rebuild text-layout itself, they will not do the right thing, and we'd have disabled some languages instead of enabling others 22:40:17 tantek has joined #css 22:40:39 florian: so I'm more on the side of caution, and making sure that everything we add to this API is a thing we can tweak 22:40:40 astearns, assuming this was the interface they have to implement? 22:41:14 florian: And yes, people will break stuff for their own customers, but we'll also break the fact that the web is multilingual 22:41:31 fantasai: I think koji and AmeliaBR and florian said everything I wanted to say 22:41:49 ack my 22:41:49 myles__, you wanted to respond to Rossen 22:42:33 myles__: most of my job is fixing bugs that the text experts in the piece of software they created cause they only spoke english 22:42:58 myles__: there's tons of places in WK where there are assumptions because of english only speakers 22:43:25 myles__: I agree we should investigate the middle parts in the spectrum, but I think we disagree with the criteria for success 22:43:43 myles__: I think text is different, where if you get it wrong it may work for you but not for your users 22:43:52 q? 22:43:59 q+ 22:44:05 myles__: an approach where we take every thing the browser does and making it scriptable is not the highest priorities 22:44:34 myles__: raising use cases is a good way to prioritize, the idea of tweaking specific parts of the browser is great and makes total sense 22:45:04 myles__: picking specific use cases and filing in holes is probably the right idea, creating a low level platform and tell people to write it yourself is probably not 22:45:06 +111!1!1 22:45:17 myles++ 22:45:39 myles__: minority languages is a very interesting case, apart from Graphite we also have a similar thing with AAT 22:45:58 myles__: I wish we could find a way to solve that problem in a way where safety is preserved 22:45:59 q? 22:47:07 Rossen: I see a lot of passion and interest, zero reasons for us to stop working on this. A lot of things said will hopefully be taken into account as we move forward. One thing that I wanted to make sure that the record reflects what I said. 22:47:23 Rossen: I wasn't suggesting to start exposing the far end, like glyphs 22:47:47 Rossen: but as we go forward we should start walking towards the end, I just want to ensure that we don't preclude us from going forward 22:48:28 Rossen: is there something that you think it wasn't discussed? 22:48:32 to myles__ 22:48:46 q+ 22:48:49 myles__: I think the next thing is gathering use cases, so we're done 22:48:58 Rossen: queue time 22:49:00 q+ 22:49:04 q+ 22:49:06 Zakim, open queue 22:49:06 ok, Rossen, the speaker queue is open 22:49:13 q+ 22:49:15 q+ 22:49:22 iank_: to try to wrap up, is there anything inside of the current version of the spec that particularly scares you? 22:49:54 myles__: my biggest concern is about encouraging authors to do layouts in loops 22:50:22 q? 22:50:26 myles__: where they try over and over, but I understand such and approach allows for dynamic use-cases, so I guess the question is to which side we fall 22:50:28 q+ 22:50:49 iank_: I think we agree, but we don't want to limit people which is why we chose this approach 22:51:23 myles__: We heard a lot of use-cases in this discussion that aren't covered by the API, so maybe it's too early to create APIs 22:51:34 ack dauwhe 22:51:37 Rossen: we have a proposal and we have a lot of discussions, let's not say yay or nay 22:51:51 q- 22:52:10 dauwhe: I wanted to make a point re. the responsibility about us making software for our usecase vs. browsers 22:52:21 q? 22:52:35 dauwhe: we publish english and spanish, I don't think there should be obligation for us to handle vertical or rtl 22:52:43 ack AmeliaBR 22:53:01 Zakim, close queue 22:53:01 ok, Rossen, the speaker queue is closed 22:53:06 AmeliaBR: I'm glad myles__ brough this discussion 22:53:26 AmeliaBR: one thing that myles__ and fantasai said is that text was different because it made stuff unreadable 22:53:42 AmeliaBR: I don't think that's true, there are lots of ways you can break content in another ways 22:54:43 AmeliaBR: I agree with Rossen that the developers of the websites are responsible for being user friendly and would be the ones to pay the price. I don't think that this proposed ways which could break websites are worse that other ways to break stuff with CSS 22:54:45 q+ 22:54:50 fantasai: I think it's actually worse 22:54:58 q? 22:55:22 I disagree with AmeliaBR's comment, and agree with fantasai. Bad text layout has uniquely bad ways of making content inaccessible 22:55:23 Rossen: this is not the end of the discussion, but some of the starting points 22:55:44 Rossen: we need go back and work more on this, we should keep participating passionately 22:55:52 Rossen: next steps is engaging in the specs 22:56:01 Rossen: so go help iank_ ;) 22:56:16 iank_: I'd love that 22:56:27 topic: end 22:56:54 topic: text-wrap: multi-line 22:57:37 github-: https://github.com/w3c/csswg-drafts/issues/672 22:57:40 github: https://github.com/w3c/csswg-drafts/issues/672 22:58:38 myles__: Similar to houdini, there are lots of different ways to do line-breaking, houdini solves some of them, other ways people want to do line breaking are some fancy book-like line-breaking 22:59:01 myles__: line-breaking on the web is greedy, and doing something slower but higher quality is a longstanding request 22:59:31 myles__: I proposed a value for this, which got to the spec and then got removed because of lack of consensus 22:59:34 q+ 22:59:37 q+ 22:59:41 zakim, open the queue 22:59:41 ok, xfq, the speaker queue is open 22:59:45 q+ 22:59:52 myles__: I'd like to see which opinions for this 22:59:56 q+ 22:59:59 myles__: it's a very high-level switch 23:00:15 florian: I want to know which one is the author value 23:00:40 florian: I want one of the values to be stable when you type 23:00:49 default is 'wrap' which is stable 23:00:55 q+ 23:00:55 myles__: right now the default is stable in every browser 23:00:59 florian: not for print 23:01:08 myles__: you don't type in print preview 23:01:19 myles__: I don't think you need another value, we already have it 23:01:59 florian: I think there should be a stable value 23:02:14 myles__: I think reflecting reality and saying that auto should be stable is fine 23:02:34 fantasai: I think the initial value should allow the UA to do whatever 23:02:42 ack dauwhe 23:02:43 q? 23:03:06 dauwhe: If the property is added to iBooks I'll add it everywhere 23:03:32 dauwhe: I think you want to change it in existing books too 23:03:32 fantasai: I think iBooks should just add it to its default UA 23:03:49 ack eae 23:03:50 dauwhe: having the text break better is just going to be a win 23:04:17 eae: I think this is a great idea, I'm a bit concerned that if we don't define what pretty does we'd get interop issue, so we should try to explain what pretty would do 23:04:30 myles__: in the issue I listed a dozen different criteria 23:04:58 myles__: so describe it explicitly is probably not realistic, do you think agreeing on the goals is fine? 23:05:00 q? 23:05:09 eae: yeah, I think that's ok 23:05:11 q+ 23:05:31 fantasai: dauwhe: myles__: I think it's important to _not_ get compat 23:06:01 There will always be perf trade-offs, so that it makes sense that a print book will get prettier `pretty` results than a browser on a low-CPU device. 23:06:02 s/fantasai: dauwhe: myles__:/fantasai, dauwhe, myles:/ 23:06:26 heycam: I was going to make eae's point, though maybe I'm a bit more worried about the compat impact, I don't we can change the default algorithm because of compat, why wouldn't that happen with `pretty`? 23:06:49 astearns: the current algorithm is not that interoperable 23:06:53 myles__: also, this is an opt-in 23:07:04 ack heycam 23:07:15 heycam: once we have this, why would we not expect authors to just use it all the time. Why would they not do that? 23:07:34 myles__: it's the same answer for text-rendering: optimizespeed vs. optimizelegibility 23:07:41 fremy: it's mostly useless 23:07:45 myles__: AmeliaBR: it's not 23:08:07 heycam: I don't think people will think about speed, and many people will just use it without thinking about it, having a perf impact 23:08:18 astearns: I think that's a reason for the auto value 23:08:25 astearns: so that the ua can change it 23:08:36 heycam: I'm skeptic about changing line-breaking 23:08:43 (by default) 23:08:58 ack dauwhe 23:09:02 myles__: I'd like to keep the discussion less about the existence of auto 23:09:48 dauwhe: I think there are a lot of tradeoffs. Browsers are optimized for speed right now, and taking any step to opt in to better systems is going to be great regardless of interop 23:10:04 dauwhe: text layout is so sensitive that there's never going to be interop 23:10:22 myles__: I want to resolve to put this value back in 23:10:26 Rossen: objections? 23:11:23 ScribeNick: florian 23:11:41 florian: I want to make sure we have the three values, including stable. 23:11:49 ScribeNick: fantasai 23:11:59 ScribeNick: emilio 23:12:15 fantasai: I think we should rename it, but no objection 23:12:27 fantasai: I'm a bit concerned that we are going to add another switch that does nothing 23:12:35 fantasai: but if people feel strongly I won't object 23:13:05 fremy: not an objection either but we need a better definition on what it does 23:13:26 RESOLVED: Add the value back in 23:13:33 fantasai: are we adding stable? 23:14:08 scribeNick: 23:14:32 scribeNick: AmeliaBR 23:14:45 myles_: there are three values: auto, balance and this new thing 23:14:57 fantasai: I object to the multi-line name 23:14:57 scribeNick: emilio 23:15:00 myles_: proposals? 23:15:05 fantasai: pretty sounds good to me 23:15:20 fantasai: it's what we used to discuss it here 23:15:58 RESOLVED: add the stable value 23:16:01 topic: end 23:25:49 futhark has joined #css 23:27:35 bdc has joined #css 23:28:03 rachelandrew_ has joined #css 23:42:57 xfq has joined #css 23:47:01 presenter has joined #css 23:47:27 scribeNick: iank_ 23:47:57 23:48:07 <.... etc.. ..> 23:49:52 heycam: Talked about webkit-line-clamp, wanted to give an update, last couple weeks looking at implmeenting, and looking at what the actual behaviour inside blink/webkit 23:49:56 Topic: -webkit-line-clamp 23:49:57 Topic: -webkit-line-clamp compatibility issues 23:50:03 github: https://github.com/w3c/csswg-drafts/issues/2847 23:50:12 heycam: Talked about webkit-line-clamp, wanted to give an update, last couple weeks looking at implmeenting, and looking at what the actual behaviour inside blink/webkit 23:50:28 heycam: At high level, in the spec we talk about it as a fragmentation, once you reach Nth line, subsequent lines fragment, and lines disappear. 23:51:07 heycam: In blink/WK the effect is only as incluencing its size. like a max-block-size constraint, element is reflowed, where is pos of last line? this affects intrinsic block-size 23:51:35 heycam: As in blink/WK you'll end up with an element w/ this size, however the remaining lines will appear as overflow. 23:52:13 these differences aren't insignificant, i've written patch for what blink/WK have done. Wanted to do this in a reasonable time. 23:52:39 TabAtkins: The existing WLC impls are bad and horrible. 23:53:10 heycam: Apart from the difference with fragmenting or not, elements on subsequent lines will actually show, however this probably isn't a webcompat constraint. 23:53:44 The differences are largely intentional https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5 23:53:51 heycam: WLC only work on -webkit-box, orientation: vertical. Some risk that if we don't respect that it may appear on elements that wasn't expected to have that treated. 23:53:56 Main concern is really interaction with -webkit-box 23:54:14 TabAtkins: iank_ did some looking. 23:54:20 q+ 23:55:40 iank_: I did some analysis by adding a bunch of usecounters in our webkit-box implementation to answer questions like how many w/ single block-flow child, vs. multiple. 23:55:56 iank_: This allowed us to kill percentage WLC 23:55:58 heycam: yaya 23:57:01 heycam: One other difference between spec and impl, any indepented formatting context child gets skipped over, that means a BFC, overflow: scroll, display: flex etc, I think that makes sense, is nice simple model, however it is a difference. 23:57:40 https://www.chromestatus.com/metrics/feature/timeline/popularity/2139 23:57:41 heycam: Where this difference has more of an effect, as it only works on a "box-item" that establibishs a independent formatting context. 23:58:09 heycam: If repsected that rule, we'd never be able to apply that line-clamp. Needs to be an exception around this. 23:58:10 q? 23:58:45 fantasai: A couple of options, and excpetion for WLC stuff, e.g. inherit the line clamp behaviour into the flex-item, or automatically apply. 23:58:52 heycam: I think that's a sensible thing to do. 23:59:23 ack florian 23:59:24 ack florian 23:59:27 florian: Most differences are intentional 23:59:58 florian: We probably need to do at the syntax level, where you specifiy that you need -webkit-box, etc, to apply the prefixed version.