IRC log of css on 2019-02-27

Timestamps are in UTC.

00:00:29 [emilio]
florian: which is what has happened in the TV world
00:01:32 [astearns]
topic: dark mode
00:01:35 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/3299
00:02:32 [fremy]
fremy has joined #css
00:02:35 [heycam]
ScribeNick: heycam
00:02:53 [heycam]
futhark: Chrome is soon shipping dark mode for the UI of the browser itself
00:02:59 [heycam]
... respecting the dark mode setting of the OS
00:03:07 [heycam]
... but we also want to render the pages dark
00:03:12 [heycam]
... so the MQs 5 hsa prefers-color-scheme
00:03:18 [heycam]
... letting the authors follow the setting the user has
00:03:31 [heycam]
... but in order to render the content dark for all pages from day 1
00:03:43 [heycam]
... we're looking at a UA intervention that automatically darkens the web pages
00:03:49 [heycam]
... but giving the author the possibility to opt out of that
00:04:01 [heycam]
... and we have looked at a <meta> element that Apple has already implemented
00:04:15 [heycam]
... what it does is that you can specify which color schemes the page can respond to using MQs
00:04:29 [futhark]
futhark has joined #css
00:04:35 [heycam]
... and apply a UA style sheet which renders form controls dark, having a lighter foreground color, using a black canvas backgrdop
00:04:41 [heycam]
... this is basically what safari does
00:04:57 [heycam]
... the proposal here is that we do this with a <meta> element
00:05:08 [heycam]
emilio: also the CSS property?
00:05:14 [heycam]
futhark: the CSS property I haven't mentioned yet
00:05:34 [heycam]
... 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 [heycam]
... we get this request for various Google products
00:05:44 [heycam]
... where they want to handle some UI parts themselves in dark
00:05:50 [heycam]
... but automatically darken some content
00:05:57 [fremy]
q+
00:06:15 [heycam]
smfr: we have to distinguish between auto darkening, which is clobbering what the author's done
00:06:23 [heycam]
... and this thing, which allows the author to tell us they've thought aobut dark mode
00:06:33 [heycam]
... for us this is jus chanign form controls, selection, ...
00:06:37 [florian]
q+
00:06:40 [heycam]
... an auto darkifying thing is maybe orthogonal to this
00:06:59 [heycam]
futhark: what we've been thinking about is that the <meta> 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 [heycam]
... because it knows how to render dark pages
00:07:26 [heycam]
futhark: when the author has a <meta> saying it knows how to render this page in a dark color scheme, please opt out of auto darkening
00:07:41 [heycam]
... one of the reasons we've been thinking about <meta> is that we don't want any flash of white background
00:07:45 [heycam]
... so having it available early
00:07:57 [xfq]
ack db
00:07:59 [AmeliaBR]
q+
00:08:02 [emilio]
q+
00:08:06 [heycam]
dbaron: I agree with a bunch of what Simon said
00:08:22 [heycam]
... 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 [heycam]
... 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 [heycam]
... as a result we've done work to prevent dark native themes to get through to web content
00:09:01 [heycam]
... some recent Gtk changes broke this
00:09:23 [heycam]
... so I think there are a few separate problems here
00:09:40 [heycam]
... one is the fact that because of these dark theme options in macOS, Windows 10, etc., more users have dark themes
00:09:48 [heycam]
... and in a lot of web contne tthat doesn't work, even if they want it to work
00:09:57 [heycam]
... but we can't just go apply it to web content unless we know it will work with that
00:10:06 [heycam]
futhark: that's why we want to rely on the meta element to have the page tell us it's ok
00:10:20 [heycam]
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 [heycam]
... I think UAs could use it for different things
00:10:41 [heycam]
... 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 [heycam]
... or the UA could say "for pages that haven't done this, do auto darkening"
00:11:05 [heycam]
... and a meta that says "I suppor tdark theme" serves both of those purposes but not completely
00:11:18 [heycam]
... 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 [heycam]
... so they still might want the auto darkening in that case
00:11:40 [heycam]
... 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 [heycam]
... and I'd rather not create this problem
00:11:54 [heycam]
futhark: the only keyword?
00:12:02 [heycam]
dbaron: you can say supported schemes "dark", and skip light
00:12:32 [heycam]
... 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 [heycam]
... for users who want that
00:12:52 [heycam]
futhark: there's also the "only" keyword that Safari implements
00:12:57 [heycam]
... don't you have to say "dark only"?
00:12:59 [heycam]
smfr: [nods]
00:13:38 [heycam]
futhark: if you have a light theme and say "dark only" in the meta tag, you get the authored dark page
00:13:43 [heycam]
dholbert: and widgets are dark?
00:13:46 [heycam]
smfr: primarily widgets
00:13:57 [xfq]
ack fr
00:14:08 [heycam]
fremy: I am very curious about how you're going to enforce dark themes on pages that aren't prepared
00:14:12 [heycam]
... I'm skeptical people will like that
00:14:18 [heycam]
... you'll end up with images that look wrong etc.
00:14:25 [heycam]
... for a11y purposes it's a fair tradeoff
00:14:49 [heycam]
... 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 [gregwhitworth]
q?
00:15:09 [heycam]
futhark: auto darkening is not something we'd like to spec
00:15:19 [fantasai]
+1 to fremy
00:15:22 [heycam]
fremy: otoh, replying to david, I don't see why you'd want dark only
00:15:29 [heycam]
... in VS Code, a web app, it has dark menus
00:15:35 [heycam]
... it makes sense for them to say "dark only"
00:15:39 [heycam]
... they want to control all their app UI
00:15:50 [heycam]
... 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 [heycam]
... maybe for a powerpoint thing, if the author has thought about it, why prevent it?
00:16:27 [heycam]
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 [heycam]
... 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 [heycam]
... which on some platforms is not realistic
00:17:20 [heycam]
fremy: you can always have a normal styled fallback for form controls
00:17:28 [xfq]
ack fl
00:17:33 [heycam]
florian: that's the difference between I prefer dark and I support dark only
00:17:49 [fantasai]
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 [heycam]
... 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 [heycam]
... we shouldn't have that
00:18:02 [heycam]
... why create that category?
00:18:10 [heycam]
... there are some that would look better with dark controls
00:18:14 [heycam]
fremy: VS Code only has dark controls
00:18:19 [fantasai]
high constrast explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md
00:18:24 [heycam]
... why do they custom style everything? because they can't get dark controls
00:18:32 [heycam]
... I think what you're saying exists today
00:18:38 [heycam]
... but the web page custom styles every single thing
00:18:52 [heycam]
florian: if the OS doesn't support dark controls?
00:19:01 [heycam]
fremy: you fall back, just like when you put borders on form controls
00:19:13 [bdc]
q+
00:19:17 [heycam]
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 [heycam]
fremy: today the light controls have this fallback today
00:19:35 [gregwhitworth]
q?
00:19:43 [heycam]
... if you have a button border-radius:3px, you get the fallback rendering
00:19:49 [heycam]
... and you can do this same fallback for the dark one
00:20:00 [fantasai]
high contrast explainer archived:
00:20:02 [fantasai]
https://lists.w3.org/Archives/Public/www-archive/2019Feb/0001.html
00:20:10 [heycam]
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 [heycam]
... there's a tradeoff betwene that and having sites where the controls are more recognizable as such to users
00:20:28 [heycam]
... and the users recognize the thing over there is an input field
00:20:32 [heycam]
... that's a tradeoff
00:20:40 [heycam]
... there's an advantage to contrls that look native
00:20:46 [heycam]
... esp for less experienced users
00:20:58 [heycam]
... if we offer more ability to change what the controls look like, we will pull some designers away from replacing everything
00:21:07 [heycam]
... but we will also push some users into things that are less recognizable for them
00:21:14 [heycam]
... there's no one answer is more correct 100%
00:21:52 [heycam]
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 [heycam]
... 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 [heycam]
... I know I will not get full agreement on that
00:22:18 [heycam]
gregwhitworth: for end user experience reasons
00:22:31 [heycam]
florian: but it could become wrong when you update the style sheet and forget to update the meta
00:22:33 [heycam]
gregwhitworth: bad author
00:23:03 [heycam]
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 [xfq]
ack Am
00:23:24 [heycam]
futhark: the property wins
00:23:51 [heycam]
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 [heycam]
... but as long as the style property overrides the meta tag, that's ok
00:24:03 [heycam]
... but then I'm not sure why the meta tag is necessary
00:24:15 [heycam]
... if the style sheet sdon't load, I'm assuming the browser can apply whichever one
00:24:23 [heycam]
futhark: if you parse the meta tag, you can apply the black canvas pretty early
00:24:26 [heycam]
fremy: it's about flashing
00:24:44 [heycam]
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 [heycam]
smfr: every wikipedia page will flash
00:25:02 [heycam]
AmeliaBR: ok that's the point of the meta tag, for the default backdrop before style sheets load
00:25:06 [heycam]
fantasai: use bgcolor on body? :)
00:25:32 [heycam]
... I totally agree this is not something that belongs in the HTML layer if possible
00:25:38 [heycam]
... if you want to put it there, we have bgcolor
00:25:49 [heycam]
... the best thing there is you can solve that for any background color
00:25:59 [heycam]
AmeliaBR: not necessarily because what if the style sheet has a MQ switch based on user preference
00:26:04 [heycam]
fantasai: then it will override, but that's better
00:26:12 [heycam]
AmeliaBR: you can indicate which themes you support
00:26:23 [heycam]
fremy: bgcolor can only supply black, not "which theme the author supports"
00:26:40 [heycam]
fantasai: you're only doing this for white or black -- is this a big problem?
00:26:53 [heycam]
TabAtkins: if I'm looking at dark screens in bed, I don't want a big flash of white
00:27:17 [heycam]
AmeliaBR: why would wikipedia put a meta tag saying "dark only"?
00:27:30 [heycam]
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 [heycam]
[wikipedia just as an example here]
00:28:18 [heycam]
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 [heycam]
... when you're overriding author styles it's an a11y feature
00:28:33 [heycam]
... but that's separate from trying to match user preferences
00:29:09 [heycam]
... 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 [heycam]
... 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 [fantasai]
+1
00:29:38 [heycam]
... we kind of have multiple themes now in browsers
00:29:46 [heycam]
... the "legacy" widget themes, if you much around with styles
00:29:58 [heycam]
... then we have the modern native look buttons in light or dark theme
00:30:11 [heycam]
... I don't know how is the way the prop is currently specced going to interact with that?
00:30:23 [heycam]
... when you revert to the legacy styles
00:30:26 [heycam]
futhark: I don't have an answer for that
00:30:41 [heycam]
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 [heycam]
smfr: still has these fallbcak interactions
00:31:47 [heycam]
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 [heycam]
... will @supports just look at syntax, don't say you support dark mode unless you have one to use
00:32:14 [heycam]
... but that would break an author request of dark or light
00:32:28 [heycam]
... so the keywords need to be recognized even if they don't have matching themes
00:32:37 [heycam]
... can sites detect "do you have a native dark theme"?
00:32:41 [heycam]
emilio: that's a fair request
00:32:50 [heycam]
... an author to see if the browser suppotrs a native dark theme or not
00:33:04 [astearns]
ack emilio
00:33:06 [heycam]
... it feels to me that the auto darkening has a lot of potential to backfire
00:33:38 [xfq]
ack bdc
00:33:46 [heycam]
bdc: I think there are 2 different issues
00:33:48 [fantasai]
+1 to emilio
00:33:54 [heycam]
... one is that it makes a lot of sense for a page to fit into its environment
00:34:31 [heycam]
... 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 [heycam]
... it's a design shortcut
00:34:38 [heycam]
... it's a differnet purpose IMO
00:34:45 [heycam]
... VS Code is not designing that because they don't have access to a dark mode
00:34:52 [heycam]
... they just design it that way
00:34:58 [heycam]
... to me it's a different use case
00:35:12 [heycam]
... 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 [florian]
+1
00:35:21 [heycam]
fremy: the #1 request we got for controls in Edge is sites wanted dark scrollbars
00:35:32 [heycam]
... we don't want to customize the scrollbar, we just want a dark one
00:35:39 [heycam]
... when they do customize it, we get perf issues, etc.
00:35:50 [fantasai]
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 [tantek]
+1 same we get requests for dark scrollbars primarily
00:36:00 [fantasai]
Sometimes. not always
00:36:01 [heycam]
... 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 [heycam]
... for better UX for users
00:36:22 [heycam]
... also, let's say you have a blog engine, you want to support dark theme
00:36:27 [heycam]
... so you say the page supports light and dark
00:36:36 [heycam]
... an embedded component from another origin, it only supportslight
00:37:02 [heycam]
... 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 [heycam]
... this is the point of the property
00:37:29 [heycam]
... incorporating components from different sites, you might not want to give up your overall site dark theme
00:37:44 [heycam]
... the "dark only" value might not be useful ...
00:37:51 [heycam]
... I have seen sites that just want a dark scrollbar
00:38:09 [heycam]
... and you need "light only" anyway
00:38:53 [heycam]
AmeliaBR: anothe rexample, you're concerned it's not respecting user prefs
00:39:07 [heycam]
... 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 [heycam]
... so I'm going to have different prefs for different sites
00:39:22 [heycam]
... maybe browsers will one day allow me to set prefs on a per site basis
00:39:29 [heycam]
... but lots of sites have a way for the user to opt in to a theme
00:39:40 [heycam]
... so maybe when they're doing "light only" or "dark only", they're reflecting the user's preference in the site
00:40:05 [heycam]
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 [heycam]
... doing the opposite is being hostile to the env
00:40:16 [heycam]
... whatever you choose, I'm going to have dark, because I like it
00:40:30 [heycam]
fremy: but you could have a theme inside the app
00:40:40 [heycam]
AmeliaBR: we can encourage authors to make their sites theme flexible
00:40:43 [heycam]
... just like responsive sites
00:40:53 [heycam]
... but I don't think a dark only is any more hostile than saying background-color:black, etc.
00:41:11 [heycam]
... it's just one way for the author to opt in to a color scheme without setting everything themselves
00:41:17 [heycam]
... and making it a bit more native and familiar
00:41:24 [heycam]
bdc: I see that, but it really depends on how many things in the UI that change
00:41:41 [heycam]
... e.g. at some point I think Edge had a title bar that matched the site header color
00:41:53 [heycam]
... here you're forcing UI changes because use as an author prefer black
00:41:58 [heycam]
... it might be pushy
00:42:23 [heycam]
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 [heycam]
... we would do small things to match the page
00:42:42 [heycam]
... that was the behavior we did
00:42:49 [heycam]
bdc: this kind of thing can have an impact on the UI as a whole
00:42:57 [heycam]
... who knows what the OS will do in the future
00:42:59 [myles__]
myles__ has joined #css
00:43:01 [heycam]
... so it could affect more things
00:43:09 [heycam]
AmeliaBR: good point but it sounds like it's outside the scope of CSS
00:43:25 [heycam]
... anything the browser/OS is doing to extract styles from the page and applying outside the page ...
00:43:33 [heycam]
bdc: these properties and meta tags would do that no?
00:43:36 [heycam]
florian: just within the page
00:43:52 [heycam]
AmeliaBR: the only thing outside we can style with CSS is styling the dark/light bg of the canvas
00:44:00 [heycam]
bdc: the chrome of the browser could/should change based on that
00:44:16 [heycam]
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 [heycam]
... if you have the meta tag, it would flip to dark controls too, if not, it wouldn't
00:44:29 [AmeliaBR]
s/outside we can/outside what we can already/
00:44:34 [heycam]
... is there an issue with that?
00:44:36 [heycam]
bdc: not with that
00:44:52 [heycam]
... 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 [heycam]
dholbert: alerts could be dark
00:45:07 [heycam]
gregwhitworth: they're not controlled by you now anyway
00:45:23 [heycam]
AmeliaBR: that's an issue on the browser team to decide whether to respond author or OS choices ...
00:45:40 [astearns]
q?
00:46:08 [heycam]
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 [heycam]
... there's the shell, which is only controlled by the user
00:46:22 [heycam]
... usually it doesn't propagate anywhere beside the shell
00:46:41 [heycam]
... 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 [heycam]
... regardless of it it's dark or whatever
00:46:51 [heycam]
... then there's the content of these apps
00:47:01 [heycam]
... even besides browsers. many other apps that have content that could benefit from theming
00:47:12 [heycam]
... and there, it's the choice of the app on whether to propagate that information to the content
00:47:24 [heycam]
... a quick survey of 1st party apps that ship with Windows or macOS, even there is some inconsistency
00:47:35 [heycam]
... e.g. in Windows the shell is always dark, doesn't mean 1st party apps will always be dark
00:47:46 [heycam]
... at the same time, in Edge, there's a user choice to change the UI to be dark mode only
00:47:58 [heycam]
... changing the UI of the browser alone doesn't fit with anything else if the shell is light
00:48:10 [heycam]
... 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 [heycam]
... Mail doesn't usually force content to be dark by default
00:48:25 [heycam]
... looking at macOS Mail, it seems this is only done for text only messages
00:49:18 [heycam]
... 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 [heycam]
... 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 [heycam]
... most platforms today have these 3 tiers of color scheme propagation that, whether or not in this group agree, is irrelevant
00:51:34 [heycam]
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 [heycam]
... the standardization of a meta tag typically doens't happen in CSS
00:52:04 [heycam]
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 [heycam]
... 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 [heycam]
... if we're ok with flashing, then meta tag or property or alternative style sheet would work
00:53:13 [heycam]
smfr: we're not ok with flashing
00:53:23 [heycam]
... asked one of our engineers about the meta tag proposal
00:53:41 [heycam]
... 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 [heycam]
... I think that's the primary reason
00:54:03 [heycam]
florian: I'm personally not enthusastic about the meta tag, but I understand why you need it
00:54:11 [heycam]
... and as long as you have the property, that's fine
00:54:44 [tantek]
q?
00:54:58 [heycam]
bdc: the only change you're contemplating is form controls, canvas
00:55:22 [heycam]
futhark: foreground color, background color
00:55:30 [heycam]
s/canvas/root viewport color/
00:55:30 [tantek]
I'm curious if a <style> element would solve the flash or not
00:55:38 [heycam]
florian: would this change the bg color of the selection?
00:55:39 [heycam]
smfr: yes
00:55:54 [heycam]
florian: that's meant to be affected by a normal property on a selector
00:56:01 [heycam]
smfr: currently the selection color uses a system provided color
00:56:07 [heycam]
... but this will be overridden
00:56:10 [heycam]
... there's also spelling dots
00:56:20 [heycam]
... and the scrollbar color, even though we have a property for that now
00:56:28 [heycam]
... links too
00:56:58 [heycam]
jensimmons: does it also include the colors in the UA sheet?
00:57:07 [heycam]
hober: in practice we didn't have to, since it used named colors
00:57:32 [heycam]
smfr: in KHTML there was a system color called "text"
00:57:40 [heycam]
... that value persisted to the present day
00:57:45 [heycam]
... now we're using that in the UA sheet
00:57:50 [heycam]
... that becomes white when you use dark mode
00:57:59 [heycam]
emilio: we should talk about, because all UAs probably use system colors for this
00:58:09 [heycam]
... doesn't make sense to deprecate things that everyone is using them...
00:58:31 [heycam]
dbaron: on system colors, I had a bunch of proposals
00:58:37 [heycam]
... the current set is very Windows specific
00:58:45 [heycam]
... you generally think there is a fg and bg pair
00:58:55 [heycam]
... ButtonText / ButtonFace, HighlightText / Highlight
00:59:07 [heycam]
... in that set, from the Windows API, seeing how the Windows UI used those, there were some non obvious pairs
00:59:15 [heycam]
... there was a set of 4 colors, call them ABCD
00:59:34 [heycam]
... it was confusing
00:59:46 [heycam]
... in 2001..2003, I had a proposal for fixing this by adding another name for the other combinations
01:00:01 [heycam]
... rather than assuming this control always uses the fg color from this control and the bg color from that control
01:00:08 [heycam]
... and Gecko implements a bunch of these behinds prefixes
01:00:19 [heycam]
... additional system colors so we can do sane things on non-Windows
01:00:22 [heycam]
... Dialog and Field
01:00:28 [astearns]
ack dbaron
01:00:52 [heycam]
... I would support working un-deprecating system colors given how much they're used, I had some proposals to fix them
01:01:32 [heycam]
dbaron: I think it's possible that it might make sense to have 2 different flags rather than 1
01:01:43 [heycam]
... it might be that the aspect of what to do with native controls is different from what to do with default colors
01:02:02 [heycam]
... so you may wish to say that my page supports either light or dark native controls, but I still want to leave the default colors light by default
01:02:12 [heycam]
... not fully thought through
01:02:26 [Rossen]
q?
01:02:28 [heycam]
florian: I think that makes sense. think of an existing dark today site, but was written dark with the assumption the UA sheet is light
01:02:33 [heycam]
... and might rely on some thing sfrom there
01:02:38 [heycam]
... even if they want to opt into dark controls
01:02:42 [heycam]
emilio: but if you have no meta tag
01:02:51 [heycam]
florian: you add the meta tag to use the dark controls
01:02:54 [heycam]
emilio: hopefully you then check the page!
01:03:32 [fantasai]
bgcolor=dark
01:03:33 [fantasai]
:p
01:03:42 [heycam]
... presumably if you request dark theme, look at your page, notice that it has light text that looks broken ...
01:03:49 [heycam]
florian: so don't ask for it and hack controls the old way?
01:04:05 [dbaron]
https://dbaron.org/css/test/sec1802 has some examples of how the system colors work -- part of the mess is that there are both single-border and double-border styles for raised buttons, which is why there are so many colors for the edges of buttons
01:04:10 [heycam]
emilio: on one hand, I agree more configurability is nice. otoh, exploding the amount of combinations of themes and bits that you can tweak is also going to be a mess
01:04:17 [heycam]
florian: the #1 statement before was dark form controls
01:04:20 [heycam]
... not a dark UA style sheet
01:04:31 [heycam]
... why are we coupling the two?
01:05:04 [heycam]
AmeliaBR: is the disclosure on details a form control or just a style sheet thing? so many things
01:05:16 [heycam]
florian: fremy earlier stated if you try auto darkening you will get problem
01:05:23 [heycam]
... to me a dark UA sheet is a primitive form of that
01:05:31 [heycam]
fremy: but if it's opt in they can fix it
01:05:38 [heycam]
... if they don't want to fix it that's up to them
01:05:48 [heycam]
Rossen: not having the foreground color matching form controls would be strange
01:06:01 [heycam]
... let alone backgrounds
01:06:28 [heycam]
AmeliaBR: I suspect in most cases the author is going ot override most of the things tha twould be applied on non form controls, like on sites now
01:06:36 [heycam]
... but it seems nice to have the option to have a quick one liner
01:06:46 [heycam]
... just write this web site in a light or dark whatever the user wants
01:06:56 [heycam]
... or write this section in a generic dark style because it's a chunk of text and we won't fuss on it too much
01:07:19 [heycam]
florian: if the meta tag switches the UA sheet, does the property too? how do you switch the UA from light to dark on a subtree level?
01:07:38 [heycam]
... if oyu have a meta dark, and this subtree light only, how do you apply things from the UA sheet in that subtree?
01:07:43 [heycam]
Rossen: that's what we do for high contrast
01:07:49 [heycam]
florian: you have selectors that depend on the value of a prop?
01:07:51 [heycam]
fremy: the colors chnage
01:07:55 [heycam]
florian: change the UA sheet?
01:08:00 [heycam]
fremy: we don't have a UA sheet for dark theme
01:08:08 [heycam]
... we switch a couple of colors
01:08:30 [heycam]
AmeliaBR: but this would allow to opt in not just form controls, but also dark and the page will be light text on dark background, which is essentially the dark UA sheet
01:08:36 [heycam]
... right now we just have appearance
01:08:41 [heycam]
... whether browser styles apply to that element
01:08:48 [heycam]
... but it's only for isolated replaced elements, not paras
01:09:02 [heycam]
florian: if the only differnece between light and dark UA sheets, and all differences are system colors, that's doable
01:09:12 [heycam]
... if there is any difference, then you can't do that in a subtree
01:09:30 [dbaron]
The other fun question is whether the system color keywords are computed values.
01:09:43 [heycam]
astearns: I'm not hearing any objections
01:09:57 [heycam]
... some research into what the meta tag would actually do
01:10:12 [heycam]
... we need more details written down
01:10:35 [heycam]
tantek: other question this raises is that there is a hole in the CSS rendering model about initial / transitional paints
01:10:39 [heycam]
... and we're not addressing it
01:10:50 [heycam]
... and the jump to a specific solution like meta tag is a way of ducking that problem
01:10:55 [heycam]
... I believe this group owns this problem
01:11:02 [heycam]
... not saying we're addressing it today, but we should admit it's a problem
01:11:09 [futhark]
futhark has joined #css
01:11:34 [heycam]
smfr: there are consumers of HTML/CSS like mail clients without the same navigational behavior as browsers
01:11:46 [heycam]
... when browsers paint during page load is in some cases a differentiator between browsers
01:11:52 [heycam]
... we try to paint not too late or early
01:11:56 [heycam]
... not sure specifying that is productively
01:12:09 [heycam]
astearns: not specifying first paint, but specifying some control over what happens in that first paint to avoid flashes
01:12:13 [heycam]
... seems like a good thing to work on
01:12:20 [heycam]
fremy: first paint can happen before CSS
01:12:26 [heycam]
tantek: I sense a hole
01:12:46 [heycam]
... I won't diagree with smfr that browsers are motivated at doing a good job at, just that it's a hole that authors have asked for control of it, but we haven't provided for
01:12:57 [heycam]
... we can do a better job too, but those two are not in conflict
01:13:09 [heycam]
astearns: can you raise an issue on that?
01:13:32 [heycam]
... for the meta tag, seems like we should do some more work and come back with a more concrete proposal
01:16:08 [fremy]
scribenick: fremy
01:16:14 [futhark_]
futhark_ has joined #css
01:16:28 [fremy]
Topic: word-break: break-word
01:16:29 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/2390
01:16:33 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/2390
01:17:02 [fremy]
emilio: Blink cannot seem to be able to unship
01:17:09 [dbaron]
https://bugzilla.mozilla.org/show_bug.cgi?id=1296042
01:17:12 [fremy]
emilio: We considered the alternatives
01:17:26 [fremy]
emilio: but the usage in Blink is very high so even if they also implemented the alternatives
01:17:32 [fremy]
emilio: they would not unship
01:17:46 [fremy]
emilio: I'm tired of getting new compat issues about this
01:17:59 [fremy]
emilio: so, can we maybe as a group add this to a spec?
01:18:06 [fremy]
emilio: maybe even mark it as deprecated
01:18:14 [fremy]
emilio: it's sad but realistic
01:18:29 [fremy]
florian: I am annoyed that this means we will have to care about this forever
01:18:47 [fremy]
florian: but I guess if this is required, I guess we will have to live with it
01:19:01 [fremy]
florian: because both the name is bad, but also it's not on the right property
01:19:07 [fremy]
florian: but well...
01:19:20 [fremy]
florian: ...
01:19:29 [fremy]
florian: is anybody sad enough that they are willing to object?
01:19:39 [fremy]
(so far no noise is heard)
01:19:51 [fremy]
emilio: we could put it in a webcompat spec?
01:19:58 [fremy]
florian: no, if we do it, let's do it properly
01:20:04 [fremy]
florian: as in, the text spec
01:20:18 [fremy]
astearns: so, all seem resigned to accept this at this point, is that right?
01:20:20 [fantasai]
s/(so far no noise is heard)/<giggles>/
01:21:08 [fremy]
astearns: proposed resolution is thus to add it (back) to the spec
01:21:30 [fremy]
fantasai: we have to decide if we put it in the same table as the other values
01:21:40 [fremy]
fantasai: or in a prose section further down below
01:21:44 [fremy]
astearns: I like the latter
01:21:55 [fremy]
astearns: level 3 or level 4?
01:22:04 [fremy]
fantasai: level 3 because it is not CR yet
01:22:28 [fremy]
dholbert: are we confident we can get this specced properly soon though?
01:22:40 [fremy]
fantasai: yes, we already have this exact behavior, just on another property
01:22:52 [fremy]
AmeliaBR: so we will have two values doing the same thing?
01:22:54 [fremy]
fantasai: yes
01:23:01 [fremy]
AmeliaBR: how will they interact
01:23:10 [fremy]
emilio: either or both would trigger this behavior
01:23:14 [fremy]
AmeliaBR: ok, seems reasonable
01:23:33 [fremy]
emilio: either must work on their own for compat
01:24:13 [fremy]
astearns: so, any object to add this to text level 3? with the explanation that people should use the other property?
01:24:34 [fremy]
RESOLVED: add word-break:break-word to text level 3, with a note
01:24:38 [fremy]
Topic: end
01:24:43 [fantasai]
s/add/We are resigned to add/
01:24:47 [fremy]
Rossen: quick question about next f2f meeting
01:25:00 [fremy]
Rossen: hosted in Toronto by Mozilla
01:25:13 [fremy]
Rossen: are the dates frozen?
01:25:16 [fremy]
florian: I think so
01:25:25 [fremy]
Rossen: then we need to clarify the wiki
01:25:28 [florian]
s/think/hope/
01:25:38 [fremy]
dbaron: I'm doing it
01:26:05 [fremy]
astearns: we might want to think about our first meeting next year
01:26:11 [fremy]
astearns: because tpac is really early
01:26:36 [fantasai]
Topic: Meeting Planning
01:26:39 [fremy]
astearns: (this doesn't need to be minuted)
01:29:57 [dbaron]
https://en.wikipedia.org/wiki/A_Coru%C3%B1a#Climate
01:31:32 [fantasai]
Current proposal is at Igalia in January 2020
01:31:50 [fantasai]
not conflicting with Mozilla All-hands, but either close to it (one trip for travelers) or far away from it
01:32:36 [fantasai]
hober: It's been an embarassingly long time since we've hosted a CSS meeting, so throwing out there that we'd be happy to host next Spring
01:34:19 [rego]
Mozilla all hands is: 2020 January 27-February 1 - Berlin, Germany
01:35:43 [rego]
yep, rain is almost for granted, but in the coast is not going to be cold compared to the usual winter in north hemisphere
01:35:48 [rego]
so I guess the week before would work?
01:37:42 [rego]
pictures of Igalia office in the event we arrange every year: https://www.flickr.com/photos/webhackfest/
01:40:26 [futhark]
futhark has joined #css
01:40:28 [astearns]
trackbot, end meeting
01:40:28 [trackbot]
Zakim, list attendees
01:40:28 [Zakim]
As of this point the attendees have been krit
01:40:36 [trackbot]
RRSAgent, please draft minutes
01:40:36 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/02/27-css-minutes.html trackbot
01:40:37 [trackbot]
RRSAgent, bye
01:40:37 [RRSAgent]
I see 2 open action items saved in https://www.w3.org/2019/02/26-css-actions.rdf :
01:40:37 [RRSAgent]
ACTION: AmeliaBR to Open an issue to define getComputedStyle [1]
01:40:37 [RRSAgent]
recorded in https://www.w3.org/2019/02/26-css-irc#T18-36-19
01:40:37 [RRSAgent]
ACTION: gregwhitworth open issues against outline on all the aforementioned issues [2]
01:40:37 [RRSAgent]
recorded in https://www.w3.org/2019/02/26-css-irc#T23-01-20
16:53:41 [RRSAgent]
RRSAgent has joined #css
16:53:41 [RRSAgent]
logging to https://www.w3.org/2019/02/27-css-irc
16:53:43 [trackbot]
RRSAgent, make logs public
16:53:43 [Zakim]
Zakim has joined #css
16:53:45 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:53:45 [trackbot]
Date: 27 February 2019
16:54:08 [dauwhe]
dauwhe has joined #css
16:54:10 [myles]
myles has joined #css
16:56:58 [antenna]
antenna has joined #css
16:58:15 [futhark]
futhark has joined #css
16:58:56 [mstensho]
mstensho has joined #css
16:59:39 [rachelandrew]
rachelandrew has joined #css
17:01:17 [TabAtkins]
SVG Breakout will be in SFO-SPE-4 Forest Hill.
17:01:54 [TabAtkins]
Link for the main-room hangout is, again, https://g.co/hangout/google.com/csswg
17:03:39 [jensimmons_]
jensimmons_ has joined #css
17:04:18 [jihye]
jihye has joined #css
17:05:19 [skk]
skk has joined #css
17:05:58 [bgirard]
bgirard has joined #css
17:10:55 [tantek]
tantek has joined #css
17:13:13 [dauwhe]
present+
17:13:18 [tantek]
present+
17:13:41 [fremy]
fremy has joined #css
17:13:45 [fremy]
ScribeNick: fremy
17:14:03 [bdc]
bdc has joined #css
17:14:03 [fremy]
Topic: Grid (padding and overscroll area)
17:14:17 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/3665
17:14:33 [fremy]
fantasai: this is a follow-up of last issue
17:14:47 [fremy]
fantasai: where we resolved to take explicit tracks into account in the scroll area
17:15:13 [fremy]
fantasai: but we had a tangent discussion about considering the padding
17:15:28 [fremy]
fantasai: we have compat because in the case of block
17:15:29 [jihye]
present+
17:15:44 [skk]
skk has joined #css
17:15:50 [AmeliaBR]
AmeliaBR has joined #css
17:15:54 [chris]
chris has joined #css
17:16:03 [fremy]
fantasai: (missed the details of the compat case_
17:16:14 [fremy]
fantasai: but we don't have such a compat issue for grid, so we can do this thing right
17:16:24 [fremy]
astearns: and we would be doing this for flexbox as well?
17:16:27 [fremy]
fantasai: yes
17:16:42 [fremy]
fantasai: we already had people asking for this to be fixed for blocks
17:17:00 [fremy]
fantasai: and the closest we could do was to do this correctly when alignement properties have a non-default value
17:17:10 [tantek]
+1
17:17:13 [chris]
present+
17:17:19 [fremy]
dholbert: doesn't chrome already do that in the block direction?
17:17:29 [fremy]
fantasai: yes, but we want to change the spec to require both axises
17:17:41 [TabAtkins]
Trying to find a room with a not-broken gvc unit
17:17:42 [heycam]
present+
17:17:54 [fremy]
dbaron: what are you proposing to include exactly?
17:17:55 [smfr]
smfr has joined #css
17:18:21 [fremy]
fantasai: boxes that are in flow, and their border box, plus the entire grid, and the padding around all this should be included in the scrollable area
17:18:26 [fremy]
dbaron: and what is the change?
17:18:33 [bdc]
present+
17:18:38 [fremy]
fantasai: include the paddings
17:18:46 [fremy]
florian: when the alignment is the default
17:18:50 [jensimmons_]
present+
17:18:54 [fremy]
dbaron: but how about the margins?
17:19:01 [fremy]
dbaron: I thought it wasn't interoperable
17:19:16 [fremy]
dbaron: I would like the spec text to be very clear about what margins are included
17:19:37 [fremy]
dbaron: for example, descendant margins, collapsing margins, and their interactions
17:19:46 [fremy]
florian: but this is orthogonal to padding though
17:20:01 [fremy]
dbaron: yes, you're right, I just didn't know what was the change proposal about
17:20:11 [fremy]
dbaron: I would be fine with any behavior, but would like the spec to be clear
17:20:18 [tantek]
tests and examples for proposal?
17:20:18 [fremy]
?: do we have tests?
17:20:22 [tantek]
s/?/tantek
17:20:28 [fremy]
fantasai: no, but I can make one
17:21:00 [fantasai]
testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20padding%3A%2010px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22width%3A%20100px%3B%20height%3A%20100px%3B%20background%3A%20blue%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
17:21:12 [fremy]
florian: (restate what has been written above to rego)
17:21:22 [fantasai]
In Firefox, there's only padding in the top/left
17:21:27 [fantasai]
In Chrome, you also have padding at the bottom
17:21:28 [fremy]
Rossen: sounds great, let's do it
17:21:32 [fantasai]
Authors expect padding on all sides.
17:21:37 [dbaron]
Present+
17:21:51 [tantek]
I see padding on all sides of the blue square in FF67 nightly
17:22:12 [fremy]
Rossen: back when IE implemented this, we did it "right" be default
17:22:22 [fremy]
Rossen: then got compat issues
17:22:37 [fremy]
Rossen: but ideally we think this should be the default, so I support this change
17:22:54 [fremy]
astearns: where are we gonna write that?
17:23:19 [fremy]
fantasai: in the same place as where the rules are today, but we can add a note to explain why block must be an exception
17:23:33 [antenna_]
antenna_ has joined #css
17:23:36 [fremy]
jensimmons_: I think for authors it's great that the new layout work properly, and then there is legacy
17:24:01 [fremy]
jensimmons_: it's great to clean cut from the past, if you rely on new things, you don't have to be aware of old legacy issues
17:24:20 [fremy]
astearns: what about dbaron's concern that everything should be well defined
17:24:36 [fremy]
fantasai: we should add all these details in the overflow spec
17:24:37 [tantek]
fantasai, I see the same result in Safari and FF67. Blue square with padding all around it between it and black border
17:25:08 [fremy]
fantasai: but the general behavior should be in the alignment spec, that only deals to inflow content
17:25:10 [rego]
tantek: this is another example https://jsbin.com/yizuzanado/1/edit?html,output
17:25:24 [fremy]
fantasai: but well, I agree, there will be changes in a couple of specs to achieve this result
17:25:45 [fremy]
astearns: grid and flexbox are probably gonna be relased before overflow though
17:25:59 [fremy]
astearns: so pulling it in would help get this to REC sooner
17:26:21 [fremy]
florian: we can add a note in those specs, but in the end overflow is required for all modes, so it doesn't matter all that much
17:26:35 [fremy]
astearns: any objection to this proposal?
17:26:41 [tantek]
rego, that example is inconsistent across FF67 (no scrollable padding bottom & right), and Safari (no scrollable padding right)
17:26:56 [fantasai]
proposed resolution: include padding in scrollable overflow area, edits to grid/flexbox/alignment/overflow
17:26:56 [fremy]
RESOLVED: change the specs so that the default scroll area includes paddings by default for grid and flexbox
17:27:22 [fremy]
tantek: is there commitment to make the change in chrome?
17:27:34 [fremy]
rego: yes, we will make the change
17:27:39 [fremy]
tantek: cool
17:28:54 [fremy]
Rossen: just wanted to note that I had prior discussion on this topic, and one of the rules that some webkit engineers cared about was...
17:29:02 [rego]
at least we'll send the patch to Chromium and WebKit, if Apple doesn't agree with this I don't know
17:29:08 [fremy]
Rossen: ... to minimize the amount of empty space you are scrolling to
17:29:18 [lajava]
lajava has joined #css
17:29:41 [fremy]
Rossen: but for grid and flexbox, they are used as structure for other things, and it's important to preserve space because the space is part of the structure
17:29:58 [fremy]
Rossen: so I don't think dropping padding there is an option that isn't weird
17:30:16 [fremy]
Rossen: but we might want to give a chance to webkit folks to take a look
17:31:12 [fremy]
astearns: as for all resolutions, things can be reversed if needed but as far as I know, we have a webkit contributor here planning to make the change
17:31:26 [fremy]
Topic: Grid (base sizes and growth length)
17:31:28 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/3646
17:31:58 [fremy]
oriol: there are two issues in there
17:32:08 [fremy]
oriol: one is that when sizing a grid under max-content constraint
17:32:19 [fremy]
oriol: when computing the space for item with intrinsic size
17:32:27 [fremy]
oriol: we only consider the base size of tracks
17:32:31 [myles]
myles has joined #css
17:32:40 [fremy]
oriol: which can be smaller than the size of the track in the end
17:33:19 [fremy]
oriol: so, maybe we should consider instead of the contribution of the item minus the track size
17:33:29 [fremy]
oriol: consider the contribution of the item minus the growth limit
17:33:39 [fremy]
oriol: (explains the example in the issue)
17:34:23 [fremy]
oriol: when the growth limit of a track increases, we could increase to base size up to that growth limit
17:34:34 [fremy]
oriol: this means that when you are using fit-content
17:34:50 [fremy]
oriol: you need to do first min-content then max-content
17:35:02 [fremy]
oriol: this is a lot of work
17:35:08 [fremy]
oriol: but chromium isn't doing this all the time
17:35:37 [fremy]
oriol: they perform a single layout track, and sets a base size of the tracks which is the min-content, and the growth-limit is the max-content
17:35:55 [fremy]
oriol: which is ok if there are no spanning items, but if there are spanning items the result is wrong
17:36:39 [fremy]
oriol: however, with my proposal, we wouldn't need to keep track of different base sizes for these two cases, and therefore we can always do only one single layout for fit-content
17:36:59 [fremy]
oriol: (one single *extra* layout pass)
17:37:38 [fremy]
astearns: thanks oriol
17:37:57 [fremy]
astearns: some people in the room are reviewing this in a bit more details
17:38:14 [fremy]
astearns: anyone has a response?
17:38:34 [fremy]
astearns: or should we continue this in the issue?
17:39:04 [fremy]
rego: one question, are we sure that what the change is what authors would expect?
17:39:26 [fremy]
rego: if it is, I think the change oriol proposed should get done, but maybe it isn't what authors expect, I'm not sure
17:39:39 [fremy]
astearns: jensimmons_ ? do you have an opinion?
17:39:49 [fremy]
jensimmons_: not yet
17:40:09 [innovati]
innovati has joined #css
17:40:24 [fremy]
Rossen: the issue is fairly new
17:40:42 [fremy]
Rossen: maybe we need to take more time
17:40:44 [tantek]
TBH I can't visualize this. Any chance of projecting an example for things like this? E.g. before/after change?
17:41:00 [bkardell_]
tantek, yes please
17:41:07 [fremy]
Rossen: maybe we can use whiteboards at lunch
17:41:11 [florian]
I am a little confused. Does that relate to https://github.com/w3c/csswg-drafts/issues/2356 ?
17:41:15 [fremy]
fantasai: I'm in favor of that
17:41:35 [fremy]
fantasai: but I would also desire to publish a new grid update
17:41:53 [fremy]
fantasai: so I'm classifying changes between big changes and minor fixes
17:42:23 [fremy]
fantasai: and I would want to first get to the changes that are just fixes
17:42:42 [fremy]
fantasai: and continue to work on bigger changes on a more relaxed timeline
17:43:12 [fremy]
rachelandrew: is that just a perf issue?
17:43:36 [fremy]
rego: well, I mean, not entirely
17:43:59 [fremy]
rego: but it would enable firefox to match both the spec and chrome, because in Chrome we don't follow the spec because it's both faster and easier not to follow it
17:44:07 [fantasai]
s/but I would also desire/Wrt the labels, I want/
17:44:15 [fremy]
rego: with the proposed change, we could both update to this new text
17:44:47 [tantek]
(wants what Jen Simmons said minuted, but can't remember exactly to type it himself)
17:46:07 [jensimmons_]
I said: Let’s figure this out. It should make sense for Authors. And we want to squash any interop problems…. yes.
17:46:14 [astearns]
topic: [css-sizing] Rethinking how to prevent overflow in a container with an explicit aspect ratio
17:46:18 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/3268
17:46:57 [fremy]
fantasai: so jensimmons_ filed this issue about how we are going to handle non-replaced element aspect ratio
17:47:07 [fremy]
fantasai: it's possible that the content might overflow the element
17:47:28 [fremy]
fantasai: so do we want to make sure the aspect ratio is a rigid ratio, or just a minimum ratio
17:47:38 [fremy]
fantasai: there are multiple ways to do this
17:48:10 [fremy]
fantasai: one would be to take advantage of min-height: auto then use min-content or aspect ratio, but otherwise use only the aspect ratio
17:48:24 [dbaron]
Was having min/max-aspect-ratio one of the options?
17:48:35 [futhark]
futhark has joined #css
17:48:35 [fremy]
jensimmons_: we talked about it before, if you have paragraph with a couple of words an an aspect ratio
17:48:47 [fremy]
jensimmons_: if the ratio allows for breathing room at the bottom, it's fine
17:49:04 [fremy]
jensimmons_: but if it's smaller because the paragraph has lots of words, then it's overflowing
17:49:27 [fremy]
jensimmons_: so we thought maybe the default behavior would to take min-content into account
17:49:48 [fantasai]
Florian's proposal to use min-height: https://github.com/w3c/csswg-drafts/issues/3268#issuecomment-437731901
17:49:50 [fremy]
fantasai: so, could we resolve and add this into the spec
17:50:06 [fremy]
florian: min-content and max-content are the same in that direction
17:50:21 [fremy]
florian: but if they wouldn't be in the future, which one would we want to use?
17:50:37 [fremy]
florian: right now, we don't have mechanism to tweak it but it might come later
17:50:55 [fremy]
dbaron: min-aspect-ratio/max-aspect-ratio
17:51:12 [xfq]
xfq has joined #css
17:51:13 [fremy]
dbaron: but width/height are defined in the other direction
17:51:19 [fremy]
dbaron: (of priority?)
17:51:37 [fremy]
fantasai: yes, but you can apply the ratio in both directions, because we do it in the direction that is auto
17:52:04 [fremy]
dbaron: but if you worry about sizing of height, I guess by then the width has been set
17:52:32 [fantasai]
jensimmons_: I don't know what min-aspect-ratio or max-aspect-ratio would mean, and I don't think we need a three-part aspect ratio system
17:52:57 [fremy]
dbaron: the idea I was thinking is that you might want an aspect ratio, but that could be taller or wider, you could use min-aspect-ratio
17:53:10 [fremy]
dbaron: well, ok, maybe I got this backwards
17:53:24 [fremy]
dbaron: so it's fair to say that min and max might be confusing in this case
17:53:31 [fremy]
dbaron: but it's more expressive
17:53:46 [fremy]
jensimmons_: I don't think there is a use case for max-aspect ratio
17:53:56 [fantasai]
jensimmons_: I think the desired behavior is that you set an aspect ratio, and if there's more content it grows bigger... or it overflows
17:53:58 [fremy]
jensimmons_: you want the aspect ratio to either be strict
17:54:08 [fantasai]
jensimmons_: It's not a minimum aspect ratio, it's the desired aspect ratio unless it gets overflowed
17:54:12 [fremy]
jensimmons_: or allow for the box to grow
17:54:17 [rachelandrew]
q+
17:54:18 [fantasai]
jensimmons_: I don't know what the use case is for a maximum aspect ratio
17:54:23 [fantasai]
jensimmons_: or a range of aspect ratios
17:54:36 [fantasai]
jensimmons_: From authoring / film industry... doesn't make sense
17:54:53 [fantasai]
jensimmons_: You want a particular target, or you let it slide because it's not a good idea (overflow)
17:54:59 [xfq]
xfq has joined #css
17:55:00 [fantasai]
jensimmons_: I'd rather do the 1st proposal not the 2nd, to summarize
17:55:05 [Rossen]
q?
17:55:06 [florian]
q+
17:55:09 [xfq]
ack ra
17:55:17 [fremy]
rachelandrew: maybe there are a couple of use cases that this doesn't solve
17:55:28 [fremy]
rachelandrew: can we make a proposal statement, and try to get this out?
17:55:29 [fantasai]
rachelandrew: Trying to think of a use case this doesn't solve. Would like something written up with an example, say to authors, "this is wha we're thinking of doing, behaves like this. Can you think of any use case it doesn't solve?"
17:55:42 [fremy]
ScribeNick: fantasai
17:55:46 [fantasai]
rachelandrew: Pple are doing this all over the web, so have an idea of what they need
17:55:53 [fantasai]
rachelandrew: We could get htis out there and see if it'll solve the problems
17:56:08 [xfq]
ack fl
17:56:08 [jensimmons_]
q?
17:56:09 [fantasai]
florian: agree with jensimmons_
17:56:18 [fantasai]
florian: The thing you brought up, dbaron, is whta the proposal is trying to solve
17:56:31 [fantasai]
florian: Want to grow by default if too much content
17:56:37 [fantasai]
florian: min/max-aspect ratio is too confusing
17:56:47 [fantasai]
florian: and the first one gets most of what you want, and you can enforce strictly if you need
17:56:56 [fantasai]
jensimmons_: 2 use cases most common
17:57:05 [fantasai]
jensimmons_: 1 - video or empty decorative box
17:57:14 [fantasai]
jensimmons_: not a video element video, but iframe or object or something
17:57:24 [fantasai]
jensimmons_: other use case is teaser cards or something like that
17:57:28 [fantasai]
jensimmons_: Maybe you want them all squares
17:57:39 [fantasai]
jensimmons_: but you don't want them to consrain height, because want to allow overflow
17:57:45 [bkardell_]
q+
17:57:46 [fantasai]
jensimmons_: Is anyone imagining a different class of use case
17:57:47 [fantasai]
q+
17:58:10 [xfq]
ack bk
17:58:17 [fantasai]
bkardell_: I'm hesitant to even bring this up, because not sure it fits in conversation, but not that long ago I worked on a project that was CMS-oriented
17:58:24 [fantasai]
bkardell_: It was very open to what authors could provide
17:58:33 [fantasai]
bkardell_: There were maybe 2-3 different kinds of images with their own aspect ratios
17:58:38 [fantasai]
bkardell_: there was some negotiation
17:58:46 [fantasai]
bkardell_: wanting to deal with the actual spect ratio was the issue we had there
17:58:54 [fantasai]
bkardell_: but seems the opposite of what jen's talking about
17:58:57 [fantasai]
bkardell_: might not be relevant...
17:59:06 [fantasai]
astearns: We're talking here to add an aspect ratio tonon-replaced elements
17:59:20 [fantasai]
astearns: so behavior needs to be specified for when content can't match aspect ratio that was specified
17:59:23 [fantasai]
astearns: images always can
17:59:34 [futhark]
futhark has joined #css
17:59:35 [fantasai]
jensimmons_: Images come in when you use object-fit: cover or contain
17:59:41 [fantasai]
jensimmons_: and want ot give a particular aspect ratio
17:59:50 [fantasai]
jensimmons_: but that's about interaction of explicit and implicit aspect ratios
18:00:04 [xfq]
ack fan
18:00:07 [fremy]
fantasai: one of the benfits of the min-height auto solution
18:00:18 [fremy]
fantasai: is that we can easily turn off the grow behavior
18:00:35 [fremy]
fantasai: for example when we have scrolling in place
18:00:40 [dholbert]
q+
18:00:43 [fremy]
fantasai: which I think is what we want by default
18:00:54 [fantasai]
fantasai: this is what min-height: auto is for
18:00:57 [astearns]
ack dholbert
18:01:06 [fantasai]
dholbert: One thing to think about is the thing with aspect ratio is not itself scrollable
18:01:11 [fantasai]
dholbert: but it has a scrollable child
18:01:21 [fantasai]
dholbert: min-height: auto means be as tall as the thing inside the scrollable thing
18:01:22 [florian]
q+
18:01:35 [fantasai]
dholbert: because the scrollble content is one level belo
18:01:39 [fantasai]
dholbert: fixable by setting min-height: 0
18:01:45 [fantasai]
dholbert: but might be worth thinking about
18:01:46 [fantasai]
q+
18:02:01 [fremy]
fantasai: actually, that spec has a simple solution
18:02:12 [fremy]
fantasai: the question is whether this is web-compatible
18:02:33 [fremy]
fantasai: so we need to implement this and see in a canary build if that works
18:02:44 [fremy]
cbiesinger: it's in the backlog, but only for width
18:02:46 [innovati]
innovati has joined #css
18:02:57 [fremy]
fantasai: well, you said you could only do this for width, but eventually we would want to try both
18:03:02 [xfq]
ack florian, fantasai
18:03:05 [fremy]
fantasai: but width is a good start
18:03:06 [fantasai]
florian: Maybe this is one place where in the block axis we have a difference between min-content/max-content... maybe not
18:03:14 [xfq]
q?
18:03:21 [xfq]
ack florian
18:03:22 [xfq]
ack fantasai
18:03:30 [fantasai]
florian: max-content you expand all the ontent. min-content you don't...
18:03:33 [fantasai]
Rossen: That's super weird
18:03:42 [florian]
q-
18:03:46 [fantasai]
q-
18:04:09 [fantasai]
Rossen: I think it is super weird. It is also a beahvior that is desired.
18:04:24 [fantasai]
Rossen: If we going to introduce something like this, let's not re-introduce max-width or something
18:04:29 [fantasai]
Rossen: let's add another propert
18:04:35 [fantasai]
florian: I did not mean the max-width prperty
18:04:38 [fantasai]
florian: I meant themax-content keyword
18:04:52 [fantasai]
florian: min-height: auto grows you beyond the auto height
18:05:08 [fantasai]
florian: If you specified min-height: max-content you would grow and min-height: min-content you would not
18:05:26 [fantasai]
jensimmons_: We started there, but decided to use auto instead
18:05:29 [fantasai]
jensimmons_: You'd get the same result
18:05:45 [fantasai]
florian: Thing I hadn't considered is what dholbert brought up, when it's the children of the thing with an aspect ratio that are scrollable
18:05:53 [fantasai]
florian: Do you want control over that?
18:05:59 [fantasai]
florian: ...
18:06:15 [fantasai]
jensimmons_: My expectation is that if you assign an aspect ratio to a box and inside there's crollable contentn, then your desire is to keep that content at that spect ratio
18:06:20 [fantasai]
jensimmons_: and then the content scrolls
18:06:25 [fantasai]
jensimmons_: that would be awesome
18:06:40 [fantasai]
jensimmons_: The fact that children is scrolling, want the container to grow?
18:07:16 [fremy]
+1 to what fantasai said
18:07:36 [fremy]
fantasai: I think this is one of the big mistake we made, and I really want this fixed
18:07:50 [fremy]
fantasai: I am afraid of the webcompat
18:08:01 [fremy]
fantasai: so I can't make this change just by myself
18:08:09 [Rossen]
q?
18:08:14 [fremy]
fantasai: but authors shouldn't have to set weird height:0 etc hacks to work around this
18:08:26 [fremy]
astearns: but this is orthogonal to this issue, right?
18:08:32 [fremy]
fantasai: yes
18:09:01 [tantek]
+1 on fantasai's proposal from an authoring perspective. I hope we can do it and maintain compat!
18:09:37 [fantasai]
proposal is to use min-height: auto to solve the problem of having the box grow past its aspect-ratio in order to accommodate content that would otherwise overflow
18:09:57 [fantasai]
jensimmons_: [gives an example]
18:10:32 [fantasai]
jensimmons_: If have 400px wide box with 1:1 aspect ratio and content is 700px heigh
18:10:44 [fantasai]
jensimmons_: min-height: auto computes to 700px, therefore wins over the height calculated by aspect ratio
18:10:56 [fantasai]
jensimmons_: author can set min-height: 0 to get that content ignored in the sizing
18:11:23 [fremy]
dholbert: for both axes?
18:11:35 [fremy]
fantasai: I think so, but not if both are auto
18:11:49 [fremy]
dholbert: (example was about a very long word you can't break)
18:11:51 [xfq]
q+ AmeliaBR
18:12:06 [fantasai]
AmeliaBR: object-fit?
18:12:09 [xfq]
ack AmeliaBR
18:12:15 [fantasai]
fantasai: this is about non-replaced elements, doesn't apply
18:12:30 [Rossen]
present+
18:12:33 [bkardell_]
present+
18:12:41 [xfq]
present+
18:12:43 [fantasai]
astearns: objectiosn to proposed resolution?
18:12:47 [AmeliaBR]
present+
18:12:56 [fantasai]
RESOLVED: use min-height: auto to solve problem of content overflowing aspect-ratio
18:13:01 [chris]
present+
18:13:29 [fantasai]
https://github.com/w3c/csswg-drafts/issues/1865
18:13:30 [leaverou]
present+
18:13:42 [mstensho]
present+
18:13:49 [fantasai]
Topic: end
18:14:14 [fantasai]
astearns: We did start discussing grid sizing algorithm issue from Oriol, decided we needed some break-time whiteboarding discussion to figure it out
18:14:34 [presenter]
presenter has joined #css
18:14:42 [fantasai]
ScribeNick: fantasai
18:14:48 [fantasai]
Topic: Values
18:15:22 [fantasai]
Topic: String Concatenation
18:15:35 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/542
18:15:38 [fantasai]
leaverou: There's a bunch of string value accepting proeprties in CSS, and can't use variables in there
18:15:41 [fantasai]
leaverou: paths
18:15:46 [fantasai]
leaverou: Lots of places where concatenation would be useful
18:15:46 [dydz]
dydz has joined #css
18:15:49 [fantasai]
leaverou: and don't have a way to do it
18:16:02 [fantasai]
leaverou: Didn't recall any objections to the propsoal, just questions about what it's called
18:16:03 [myles__]
myles__ has joined #css
18:16:09 [fantasai]
leaverou: I don't care, we just need a way to do it
18:16:12 [AmeliaBR]
q+
18:16:33 [fantasai]
chris: ppl using preprocessors take string concatenation for granted, it's simple there
18:16:43 [fantasai]
chris: they're astounded when they find it's not available in raw CSS
18:16:54 [fantasai]
leaverou: Primarily useful in URLs, but also useful in other places like paths
18:17:10 [fantasai]
TabAtkins: I agree with the need for a function here, prefer concat() but fine with anything else
18:17:23 [chris]
q?
18:17:26 [fantasai]
leaverou: We've also had suggestions for a function that converts things to strings,
18:17:29 [xfq]
ack AmeliaBR
18:17:31 [fantasai]
leaverou: text() is generic enough to do both
18:17:49 [fantasai]
string() sgtm
18:18:03 [fantasai]
AmeliaBR: Problem with that is that for string coercion you often also want number formatting
18:18:09 [fantasai]
AmeliaBR: so that might need to be a separate function
18:18:23 [fantasai]
AmeliaBR: butwould need to be partof the system if you are going to make useful path dat from numeric variables
18:18:32 [fantasai]
AmeliaBR: need to concatenate not just letters but numbers from variables
18:18:35 [fantasai]
AmeliaBR: calc expressions
18:18:36 [dbaron]
q+ to ask what the inputs to this function can be, and where it can be used
18:18:41 [fantasai]
AmeliaBR: etc.
18:19:00 [fantasai]
TabAtkins: What are the use cases for coercion? Debugging ovviousl, anything else?
18:19:15 [fantasai]
leaverou: ...
18:19:15 [fantasai]
AmBig in dataviz
18:20:15 [leaverou]
s/.../generated content to display a variable value in the UI/
18:20:25 [fantasai_]
fantasai_ has joined #css
18:20:31 [leaverou]
q+
18:20:38 [fantasai_]
AmeliaBR: e.g. bar graphs, want to use value in drawing but also labelling
18:20:42 [fantasai_]
AmeliaBR: don't want to duplicate content
18:20:53 [fantasai_]
TabAtkins: I really don't want to get into string formatting
18:21:19 [fantasai_]
TabAtkins: otherwise do see the value in do see value in displaying 50% on bar chart while 50% also used to size the bar chart
18:21:30 [fantasai_]
AmeliaBR: So if we want to leave the generic number formatting issue for later, that's fine
18:21:46 [fantasai_]
AmeliaBR: So long as we still have idea that basic concat function can take non-string values and simply print them out
18:21:46 [fantasai_]
AmeliaBR: so you can use them for path data
18:21:58 [fantasai_]
AmeliaBR: In path data you generally want to preserve maximum precision anyway
18:22:12 [fantasai_]
leaverou: example ... interpolation
18:22:22 [fantasai_]
leaverou: Don't want to define how concat() interpolates with each other
18:22:26 [xfq]
ack db
18:22:26 [Zakim]
dbaron, you wanted to ask what the inputs to this function can be, and where it can be used
18:22:47 [fantasai]
dbaron: Reading the proposal wasn't clear to me what the inputs of this function is and what the output is in terms of types
18:22:55 [fantasai]
dbaron: What CSS value types can be used in here?
18:23:03 [fantasai]
TabAtkins: output tpe is tring
18:23:12 [fantasai]
TabAtkins: input type is any thing, standard serialization of the token
18:23:27 [fantasai]
dbaron: There will be a spec defining standard serialization of a token?
18:23:32 [leaverou]
s/example ... interpolation/yes, that simplifies interpolation as well, if types of arguments were not coerced we'd need to define interpolation between two concat() calls
18:23:34 [fantasai]
TabAtkins: Need that for variables anyway
18:23:49 [fantasai]
TabAtkins: If it doesn't exist yet, some othe rspec is implicitly relying on it and it needs to be defined
18:23:55 [fantasai]
astearns: Wrt used, it's anywhere with a string?
18:24:03 [fantasai]
fremy: Exception for url?
18:24:10 [fantasai]
TabAtkins: No, works in url()
18:24:12 [xfq]
ack lea
18:24:16 [fantasai]
TabAtkins: url() can take a string
18:24:37 [TabAtkins]
s/take a string/take only a literal string, there's another issue for generic <string> input/
18:24:37 [fantasai]
astearns: I'm hearing lots of nods on having this thing. Any implementer interest?
18:24:41 [fremy]
(to clarify what tab said, url() can take a string but not a <string>)
18:25:15 [fantasai]
astearns: From silence sounds like, yes this would be a good thing, no it's not a priority
18:25:44 [fantasai]
emilio: Expectation is that you can do like sth(var(--whatev))?
18:25:50 [fantasai]
emilio: Then how can you define it to be any token?
18:26:04 [fantasai]
TabAtkins: var() is processed at a higher level than any value
18:26:15 [fantasai]
fremy: If you want a string, you do text("string")
18:26:22 [TabAtkins]
(It's specific as taking a <string> in the syntax, but in Syntax we handle url() in special ways that prevent it from taking string-producing functions.)
18:26:22 [fantasai]
emilio: If it takes any token
18:26:27 [fantasai]
fremy: If it's not a string, then you convert
18:26:32 [fantasai]
TabAtkins: I think Emilio got it
18:26:58 [fantasai]
astearns: OK, naming. What do we call the thing?
18:27:12 [fantasai]
AmeliaBR: Lea suggested text(), but there's already a text() function in paged content
18:28:07 [fantasai]
fantasai: How about string? was in Lea's original proposal
18:28:10 [fantasai]
leaverou: sounds fine
18:28:15 [fantasai]
chris: sounds fine
18:28:18 [bkardell_]
lol
18:28:29 [fantasai]
AmeliaBR: Sorry, confused things. It's the string() function that exists, text() does not
18:28:33 [fantasai]
AmeliaBR: and already implemented
18:28:39 [chris]
I care more that it exists, than what precisely it is called
18:28:40 [xfq]
https://drafts.csswg.org/css-gcpm-3/#using-named-strings
18:28:41 [tantek]
I for one an all for the cat() function, I bet it would poll well on Twitter 😺
18:28:49 [bkardell_]
lol
18:28:55 [fantasai]
astearns: Any objections to text()?
18:29:06 [chris]
Lets go with text
18:29:07 [fantasai]
dydz: Prefer concat(), but ...
18:29:16 [Rossen]
combine()
18:29:17 [fantasai]
AmeliaBR: Want names that are understandable by non-programmers in CSS
18:29:28 [fantasai]
AmeliaBR: Also, we tend not to truncate identifiers in CSS
18:29:45 [chris]
concat is not immediately obvious to non programmers either. both cat and concat are abbreviations
18:29:45 [fantasai]
TabAtkins: We are not using cat(), tantek!
18:30:00 [tantek]
😿
18:30:04 [fantasai]
bkardell_: I don't have a better suggestion, but text() is not very clear to me
18:30:11 [TabAtkins]
text(50%)
18:30:13 [Rossen]
+1 to bkardell_
18:30:21 [fantasai]
bkardell_: There are so many ways that I coudl interpret "text"
18:30:21 [tantek]
+1 to bkardell_
18:30:24 [fantasai]
flatten() :P
18:30:32 [fantasai]
chris: I think it's pretty clear
18:30:51 [fantasai]
myles__: We should think about whether concatenation or coercion is more common use case
18:30:52 [TabAtkins]
url(text("http://example.com", var(--foo)))
18:30:58 [florian]
echo() ?
18:31:02 [tantek]
printf()
18:31:04 [florian]
printf()
18:31:05 [fantasai]
AmeliaBR: text() is clear for coercion, maybe less clear for concatenation
18:31:07 [TabAtkins]
No unixisms!
18:31:13 [TabAtkins]
y'all weirdos!
18:31:18 [chris]
and text(var(--foo)) with one param is clearer than concat(var(--foo))
18:31:19 [Rossen]
stringify()
18:31:25 [Rossen]
toString()
18:31:33 [TabAtkins]
to-string()
18:31:38 [chris]
DOTtoString
18:31:39 [dbaron]
hopefully everybody has forgotten XPath by now?
18:31:50 [tantek]
Time for a Twiter survey!
18:31:57 [fantasai]
iank_: Spreadsheets use concatenate and concat
18:32:02 [fantasai]
TabAtkins: It's terrible and hard to spell
18:32:20 [fantasai]
TabAtkins: These are all great names, except for all the ones that are bad.
18:32:30 [chris]
https://developer.mozilla.org/en-US/docs/Web/XPath/Functions/concat
18:32:33 [fantasai]
TabAtkins: Let's table this and put together a non-binding Twitter poll
18:32:48 [fantasai]
florian: Make sure you include an international audience
18:32:58 [fantasai]
bkardell_: That works best if we all promote it so let us know
18:33:23 [fantasai]
leaverou: Twitter doesn't have enough space for examples, and based on what examples you use can get different reactions
18:33:45 [fantasai]
TabAtkins: I'll put together coercion example and concat example, and you can review them
18:33:50 [chris]
https://stackoverflow.com/questions/9493732/difference-between-text-and-string
18:34:01 [fantasai]
astearns: Sounds like we'll do this and decide the name later, would be interested in implementer interest
18:34:04 [fantasai]
astearns: Any objections?
18:34:21 [fantasai]
RESOLVED: work on astring-coercion-and-concatenation function
18:34:56 [fantasai]
Topic: URL Stuff
18:35:22 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/541
18:35:41 [fantasai]
leaverou: Right now ppl cannot ? in url()
18:35:47 [fantasai]
leaverou: reason being 1, we didn't have string concatenation
18:35:57 [fantasai]
leaverou: but even if we did, you cannot put any function inside url() because of its weird parsing rules
18:35:58 [TabAtkins]
s/?/use var()/
18:36:06 [fantasai]
leaverou: It has a lot of weird parsing, because of unquoted URLs
18:36:16 [AmeliaBR]
Examples for Twitter poll: `content: NAME(var(--percentage)); background: url(NAME("/assets/img", var(--icon-name), ".svg"))`
18:36:19 [fantasai]
leaverou: We were thinking we should have another url function that only accepts <string>
18:36:29 [leaverou]
Right url(var(--foo)) doesn't work
18:36:31 [fantasai]
TabAtkins: Right now if you write url(var()) it'll be invalid
18:36:37 [fantasai]
TabAtkins: Interpreted as a URL
18:37:12 [bkardell_]
+1
18:37:20 [TabAtkins]
fetch("http://example.com")
18:37:23 [fantasai]
chris: We need a function that does stuff, I propose calling it fetch()
18:37:31 [fantasai]
emilio: It doesn't fetch anything though, only if it's loaded
18:37:36 [florian]
uri()
18:37:45 [heycam]
q+
18:37:49 [fantasai]
AmeliaBR: It's also a very JSy name and not very familiar to designers
18:37:55 [fantasai]
AmeliaBR: I would go with href()
18:38:27 [chris]
href() is nice actually
18:38:31 [fantasai]
astearns: fetch() should have all of fetch()'s semantics which it won't so let's stay away from that
18:38:32 [xfq]
ack heycam
18:38:35 [fantasai]
chris: iri()!
18:38:37 [florian]
+1 to href()
18:38:38 [fantasai]
TabAtkins: leave
18:39:11 [fantasai]
heycam: It might be nice to have a url function that uses relative URL rules rather than string concatenation
18:39:28 [Rossen]
uniform-resource-locator( )
18:39:41 [chris]
web-address()
18:39:42 [fantasai]
leaverou: I think it would be useful to have a base argument, but not a name like resolve-url(), shoudl be named something...
18:39:57 [fantasai]
leaverou: change the base URL
18:40:02 [AmeliaBR]
Would it work as a modifier? `url("base.png", relative("assets/images/")`?
18:40:04 [fantasai]
heycam: Similar but slightly different use csae
18:40:07 [leaverou]
s/but not a name like resolve-url(), shoudl be named something.../but it shouldn't be named after that feature, since there are many use cases where the default resolution is fine/
18:40:11 [fantasai]
heycam: But if that did overlap, might indicate a name
18:40:23 [fantasai]
myles__: Would such an addition make us not want to do this stringify concat thing also?
18:40:28 [nigel]
nigel has joined #css
18:40:38 [fantasai]
chris: no, you need that generally. Just makes designing this easier
18:40:56 [nigel_]
nigel_ has joined #css
18:41:05 [fantasai]
leaverou: also consider SVG data URLs with parameters in the SVG
18:41:08 [Rossen]
pointer()
18:41:14 [AmeliaBR]
q?
18:41:16 [fantasai]
fremy: I like address()
18:41:37 [leaverou]
s/also consider SVG data URLs with parameters in the SVG/URL resolution is not the only reason you want concat in URLs, e.g. think of SVG data URLs with parameters in the SVG/
18:41:39 [fantasai]
heycam: I don't like that it's synonymous with url()
18:41:40 [chris]
not-broken-url()
18:41:49 [chris]
url++()
18:41:55 [fantasai]
astearns: We actually want something that is basically better-URL, exact same semantics except working for all strings
18:42:06 [fantasai]
heycam: Are you expecting ppl to use it for non-string-interpolation cases?
18:42:10 [fantasai]
[yeah]
18:42:11 [dbaron]
either address() or location() is kinda synonymous with url()
18:42:12 [leaverou]
url(var(--foo)) is not string interpolation :)
18:42:22 [Rossen]
chris, and then we can make it really good by url#()
18:42:33 [fantasai]
AmeliaBR: We also talked a few days ago about url() modifiers, I'm assuming we'll create modifiers on the better function?
18:42:43 [chris]
amela, yes I expect so
18:42:58 [chris]
we are very constrained in how we can evolve url()
18:43:01 [fantasai]
AmeliaBR: Any existing support for url modifiers?
18:43:02 [fantasai]
No
18:43:10 [fantasai]
AmeliaBR: So if we do modifiers, we can do it in the new function
18:43:20 [fantasai]
AmeliaBR: No progressive enhancement reason to add new features to a legacy function
18:43:22 [astearns]
q?
18:43:25 [fantasai]
TabAtkins: No reason not to either
18:43:32 [Rossen]
the-url()
18:43:34 [fantasai]
chris: Incentive to move to the new one
18:43:39 [chris]
u()
18:43:46 [tantek]
you could give it inexplicable new capabilities and call it uri()
18:43:52 [jensimmons_]
u2()
18:43:53 [fantasai]
florian: If we want ppl to use it, then it needs to be a short name like url()
18:44:28 [fantasai]
florian: For familiar names we could re-use HTML attribute names like href() or src()
18:44:30 [Rossen]
get()
18:44:45 [chris]
u2(href, echo-params, looping-params, reverb-level)
18:44:56 [fantasai]
dbaron: hypertext-reference?
18:45:10 [tantek]
another survey!
18:45:49 [chris]
src is nice and short
18:45:52 [fantasai]
astearns: From my reading of IRC, ppl like href() and src(), didn't see any other contenders that aren't silly
18:45:55 [bkardell_]
fetch potentially wasn't silly imo
18:46:05 [fantasai]
dbaron: address() and location() seem OK too
18:46:11 [leaverou]
I'd vote for href() over src() because src: src(...) looks a bit weird (or maybe it doesn't?)
18:46:14 [Rossen]
clear-winner()
18:46:27 [bkardell_]
agree with lea actually
18:46:31 [fantasai]
TabAtkins: I suggest polling later
18:46:37 [bkardell_]
href() > src()
18:46:50 [leaverou]
fantasai: descriptor
18:47:06 [fantasai]
RESOLVED: Add a new url function that accepts only <string>, name tbd
18:47:19 [chris]
right, we have a src descriptor, which takes a url() currently
18:47:22 [tantek]
urls
18:47:31 [fantasai]
Topic: Something
18:47:37 [fantasai]
leaverou: I'd vote for something small
18:47:38 [astearns]
topic: trig
18:47:47 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/2331
18:47:48 [fantasai]
leaverou: We should keep it cos()/sin() maybe tan() and only accept angle
18:47:51 [chris]
atan2 though, surely
18:47:56 [fantasai]
leaverou: That would solve all the usecase I listed
18:48:09 [fantasai]
AmeliaBR: So initial proposal is to add simple trig functions in calc()
18:48:29 [fantasai]
AmeliaBR: Once you start doing graphical layouts involving arcs and stuff, you need trig functions to convert from width/height distances to angular distances
18:48:33 [leaverou]
s/That would solve all the usecase I listed/That would solve all the use cases listed in the issue/
18:48:44 [fantasai]
AmeliaBR: Currently to do this you either have to do it either in a preprocessor, or if in dynamic variables have to do it in JS
18:48:49 [fantasai]
AmeliaBR: which is a pain
18:48:57 [fantasai]
AmeliaBR: JS only take radians, SVG only takes degrees, etc.
18:49:08 [fantasai]
AmeliaBR: Let's just do it in CSS which has everything
18:49:14 [fantasai]
AmeliaBR: I'd also like to get the arc functions
18:49:21 [dbaron]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math might be an interesting source...
18:49:27 [fantasai]
AmeliaBR: CSS lengths, calculate angles, woudl be great
18:49:44 [fantasai]
AmeliaBR: You can't get a diagonal across the veiwport e.g. without this
18:50:15 [fantasai]
TabAtkins: There's a demo of the Taylor expansion of sin() using stacked variable :)
18:50:21 [tantek]
+1 dbaron get your trig funcs from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math
18:50:24 [fantasai]
leaverou: There's lots of examples of usage
18:50:39 [fantasai]
AmeliaBR: I asked anatudor about it the other day
18:50:51 [leaverou]
s/There's lots of examples of usage/We can look at preprocessors for usage stats, they've been supporting trig functions for years/
18:51:00 [fantasai]
AmeliaBR: <quotes anatudor>
18:51:05 [fantasai]
TabAtkins: Very useful for transforms
18:51:17 [fantasai]
myles__: People are doing this already to day, and implementation burden is close to trivial
18:51:34 [fantasai]
myles__: If doing arc, maybe also want atan, but probably just those
18:51:39 [fantasai]
chris: atan2 deals with that
18:51:50 [fantasai]
TabAtkins: ...
18:52:05 [fantasai]
dbaron: Only add functions that are on the JS math object? Not all of them, but a subset.
18:52:36 [fantasai]
fantasai_: atan2?
18:52:43 [fantasai]
AmeliaBR: [explains the theory of atan]
18:53:08 [TabAtkins]
s/.../someone asked for hypot(), rather than having to do calc(sqrt(var(--x) * var(--x) + var(--y) * var(--y))/
18:53:28 [fantasai]
dbaron: If you have x and y coords on a graph, you typically want the tangent of y over x
18:53:46 [fantasai]
dbaron: if you have x=1 y=1 you're in Q1, i fyou're x=-1 x=-1 your'e in Q3
18:54:20 [fantasai]
dbaron: atan(x/y) gives you Q1 always. atan2() let's you get 270deg
18:54:32 [dbaron]
s/x\/y/y\/x/
18:55:11 [fantasai]
myles__: so we gonna resolve on a list of functions?
18:55:23 [fantasai]
TabAtkins: resolve on a small list, and then maybe do more research to see if anything else needed
18:55:29 [fantasai]
TabAtkins: but can resolve on basic trigs right now
18:55:38 [myles__]
Sin() cos() tan() acos() asin() atan() atan2()
18:56:00 [fantasai]
emilio: angles calc...
18:56:12 [fantasai]
emilio: Don't want sin(calc(10px + 20%))
18:56:16 [AmeliaBR]
and probably hypot(), sqrt(), and pow()
18:56:18 [fantasai]
emilio: what is the type of these functions?
18:56:26 [fantasai]
TabAtkins: I think the output is always numbers
18:56:39 [fantasai]
TabAtkins: radians are numbers
18:56:41 [fantasai]
fantasai_: not in CSS
18:56:59 [fantasai]
TabAtkins: Right. Inverse ones do need to return <angle>
18:57:01 [cbiesinger]
q+
18:57:11 [fantasai]
TabAtkins: others return <number>
18:57:18 [dbaron]
sin() cos() tan() take an <angle> or a <number> (radians) and return a number
18:57:41 [dbaron]
asin() acos() atan() atan2() take a <number> (or 2, for atan2) and return an angle
18:57:58 [fantasai_]
chris: Surely you can do atan2(20px, 4em) lengths in general
18:58:03 [fantasai_]
?: Yes, of course
18:58:09 [fantasai_]
leaverou: ...
18:58:16 [xfq]
ack cbiesinger
18:58:26 [fantasai_]
cbiesinger: You suggested that radians can be an input, but without a pi constant how do you type that in a CSS style sheet?
18:58:29 [dholbert]
s/.../in theory we can divide lengths and get numbers in CSS, but no browser supports that yet/
18:58:34 [fantasai_]
TabAtkins: Use the turn unit. 0.5turn = pi
18:58:42 [fantasai_]
AmeliaBR: We don't radians much in CSS because we have better units
18:58:50 [leaverou]
s/leaverou: .../leaverou: (to Chris) yes, CSS in theory supports dividing lengths and it gives you a number. In practice, no UA supports this yet/
18:58:55 [fantasai_]
AmeliaBR: But if you're calcuating it somewhere else, we can bring it in
18:59:02 [dbaron]
so atan2(<number>, <number>) or atan2(<length>, <length>) ?
18:59:07 [fantasai_]
TabAtkins: This is why I want to accept numbers (meaning radians) in addition to <angle>
18:59:33 [fantasai_]
myles__: So atan2() will accept lenghts and numbers?
18:59:34 [fantasai_]
TabAtkins: Yes
18:59:41 [fantasai_]
myles__: atan2(10px, 5) ?
18:59:44 [fantasai_]
TabAtkins: No, type has to match
19:00:15 [fantasai_]
dbaron: [repeats what's above]
19:00:23 [fantasai_]
dbaron: sin() cos() tan() take an <angle> or a <number> (radians) and return a number
19:00:28 [leaverou]
atan2(calc(45deg * 1px), 1em)?
19:00:30 [fantasai_]
dbaron: asin() acos() atan() atan2() take a <number> (or 2, for atan2) and return an
19:00:33 [fantasai_]
angle
19:01:02 [fantasai_]
AmeliaBR: ...
19:01:08 [fantasai_]
TabAtkins: Unit division calc() should be implemented.
19:01:22 [dbaron]
s/.../We need people to implement unit division in calc() so that people can use that as an argument to asin() and acos()/
19:01:23 [fantasai_]
astearns: OK, I think we can resolve to add these things
19:01:39 [fantasai_]
astearns: Objections to dbaron's proposal?
19:01:48 [fantasai_]
TabAtkins: I think the 10 from dbaron and emilio are good
19:01:55 [emilio]
s/emilio/AmeliaBR
19:01:58 [fantasai_]
TabAtkins: hypot() sqrt() and ?
19:02:24 [florian]
s/?/powe/
19:02:27 [florian]
s/?/pow/
19:02:27 [xfq]
sin() cos() tan() acos() asin() atan() atan2() hypot() sqrt() pow()
19:02:29 [fantasai_]
TabAtkins: They would not adjust the unit, just multiply the magnitude
19:02:54 [fantasai_]
fremy: Can you use these directly, or has to be inside calc()
19:02:57 [fantasai_]
TabAtkins: Both
19:03:13 [fantasai_]
[discussion of edits]
19:03:30 [fantasai_]
fantasai: pow() is exponents, right? we don't want to use the ^ notation?
19:04:45 [fantasai_]
TabAtkins: JS uses **, others use ^, but everyone's function is called pow()
19:05:00 [fantasai_]
AmeliaBR: If you multiply two lengths together you still get a single-dimension length?
19:05:42 [fantasai_]
TabAtkins: Multiplying two lengths would give you squared unit, but pow() and sqrt() wouldn't
19:06:12 [fantasai_]
AmeliaBR points out inconsitency of this
19:06:18 [tantek]
+1 pow() http://php.net/manual/en/function.pow.php
19:06:20 [fantasai_]
TabAtkins: So maybe pow() and sqrt() should only take numbers
19:06:34 [fantasai_]
...
19:06:56 [fantasai_]
myles__: If you pow(3.5, 4.7) what's the dimension in CSS?
19:07:05 [tantek]
do we need a unit(number, unit-name) function?
19:07:06 [fantasai_]
TabAtkins: Maybe go back to pow() and sqrt() only accept numbers.
19:07:33 [fantasai_]
AmeliaBR: and hypot() makes it easier to deal with the most common case
19:07:39 [fantasai_]
TabAtkins: Good argument to keep hypot()
19:07:56 [fantasai_]
AmeliaBR: So I could draft this up?
19:08:00 [fantasai_]
fantasai: Would be edits to css-values-4
19:08:16 [fantasai_]
AmeliaBR: Matter of 1-2 days of writing things up now that we've hashed this out
19:09:02 [fantasai_]
Topic: end
19:09:42 [fantasai_]
RESOLVED: Add sin() cos() tan() acos() asin() atan() atan2() hypot() sqrt() pow()
19:13:00 [bdc]
bdc has joined #css
19:13:46 [futhark]
futhark has joined #css
19:15:53 [myles__]
myles__ has joined #css
19:21:41 [mstensho]
mstensho has joined #css
19:22:44 [TabAtkins]
https://twitter.com/tabatkins/status/1100838423248551936?s=20
19:22:51 [TabAtkins]
please RT, peope
19:25:54 [xfq]
xfq has joined #css
19:37:59 [myles__]
myles__ has joined #css
19:42:35 [dydz]
dydz has joined #css
19:50:51 [mstensho]
mstensho has joined #css
19:59:48 [futhark]
futhark has joined #css
20:00:08 [myles__]
myles__ has joined #css
20:26:29 [futhark]
futhark has joined #css
20:29:41 [xfq]
xfq has joined #css
20:37:44 [myles__]
myles__ has joined #css
20:41:56 [astearns]
Plans are to take a group photo at 1pm
20:45:11 [jensimmons_]
jensimmons_ has joined #css
21:05:01 [dydz]
dydz has joined #css
21:11:57 [Zakim]
Zakim has left #css
21:15:30 [jensimmons_]
jensimmons_ has joined #css
21:15:32 [dydz]
dydz has joined #css
21:17:05 [presenter]
presenter has joined #css
21:17:19 [dbaron]
florian,
21:17:19 [dbaron]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22column-count%3A3%3B%20column-rule%3A%20medium%20solid%20black%3B%20height%3A%20200px%3B%20width%3A%20600px%3B%20column-fill%3Aauto%20%22%3E%3Cdiv%20style%3D%22background%3A%20aqua%3B%20height%3A%20150px%22%3E%3Cdiv%20style%3D%22width%3A%2030px%3B%20height%3A%20
21:17:20 [dbaron]
250px%3B%20background%3Ayellow%22%3E%3C%2Fdiv%3E%3Cdiv%20style%3D%22column-span%3Aall%22%3Ecolumn-span%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E
21:17:56 [bdc]
bdc has joined #css
21:18:37 [rachelandrew]
rachelandrew has joined #css
21:19:27 [dbaron]
the difference between
21:19:27 [dbaron]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22column-count%3A3%3B%20column-rule%3A%20medium%20solid%20black%3B%20height%3A%20200px%3B%20width%3A%20600px%3B%20column-fill%3Aauto%20%22%3E%3Cdiv%20style%3D%22background%3A%20aqua%3B%20height%3A%20150px%22%3E%3Cdiv%20style%3D%22width%3A%2030px%3B%20height%3A%20
21:19:28 [dbaron]
250px%3B%20background%3Ayellow%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3EA%3Cdiv%20style%3D%22column-span%3Aall%22%3Ecolumn-span%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fdiv%3E and
21:19:28 [dbaron]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22column-count%3A3%3B%20column-rule%3A%20medium%20solid%20black%3B%20height%3A%20200px%3B%20width%3A%20600px%3B%20column-fill%3Aauto%20%22%3E%3Cdiv%20style%3D%22background%3A%20aqua%3B%20height%3A%20150px%22%3E%3Cdiv%20style%3D%22width%3A%2030px%3B%20height%3A%20
21:19:29 [dbaron]
250px%3B%20background%3Ayellow%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3EA%3Cdiv%20style%3D%22column-span%3Aall%22%3Ecolumn-span%3C%2Fdiv%3EB%3C%2Fdiv%3E%3C%2Fdiv%3E is interesting (in Chrome)
21:19:42 [argyle]
argyle has joined #css
21:20:08 [myles__]
myles__ has joined #css
21:20:23 [fantasai]
Scribenick: fantasai
21:20:29 [fantasai]
Topic: aspect-ratio and width/height attributes
21:20:33 [fantasai_]
fantasai_ has joined #css
21:20:35 [argyle]
elika not you
21:20:36 [fantasai]
ScribeNick: argyle
21:20:42 [argyle]
there we go
21:21:21 [argyle]
florian: my understandin as that we all agreed this would be a goo didea if possible, and we should check if possible
21:21:25 [argyle]
tab disagrees, i want to hear that
21:21:41 [argyle]
for context: "it" is using the width and height of attribtues to trigger the intrinsic aspect ratio
21:21:53 [futhark]
futhark has joined #css
21:22:01 [argyle]
elika: specifically, where we map the width and height to width and height props, we could also use them to calc the ratio back to css
21:22:09 [cbiesinger]
s/elika/fantasai/
21:22:29 [argyle]
that would solve the problem around the aspect ratio information would be lost due to waiting for the image to load, waiting to discover auto sizing
21:22:53 [AmeliaBR]
s/that/...that/
21:23:03 [argyle]
so the proposal was to introduce attributes to solve the same problem
21:23:21 [argyle]
rosson: was is the data we need to gather then
21:23:24 [fantasai]
s/was to introduce/was to do that instead of introducing new/
21:23:27 [argyle]
florian: so we dont break the web
21:23:31 [AmeliaBR]
s/so the/...so the/
21:23:33 [argyle]
rossen: for the width and height
21:23:43 [argyle]
florian: do we not agree?
21:24:01 [Rossen]
s/rossen/Rossen/
21:24:06 [argyle]
tab: having width and height be presentation attributes, and no affecting those new and exciting ways
21:24:34 [Rossen]
s/tab/TabAtkins/
21:25:17 [argyle]
tab: the other reason i liked it, some of the other things, like picture, you wanted to give an intrinsic size to them, and tab feels semantically better to be specific about being intrinsic than doing css things that also set intrinsic sizes.
21:25:27 [argyle]
florian: there's no intrinsic tools to do this
21:25:46 [AmeliaBR]
+1 to Tab's argument about `<picture><source intrinsicsize="...">` making more sense than width & height
21:25:58 [argyle]
miles: what about canvas
21:26:18 [Zakim]
Zakim has joined #css
21:26:27 [argyle]
miles: we should consider the interaction with canvas where w and h have other meanings other than mapping to css
21:26:30 [cbiesinger]
s/miles/myles/
21:26:37 [Rossen]
q?
21:26:43 [Rossen]
ack dbaron
21:26:45 [xfq]
xfq has joined #css
21:26:49 [argyle]
rosson: david, you're on the queue
21:26:49 [fantasai]
s/miles/myles/
21:27:08 [fantasai]
TabAtkins: It sets the backing store on width/height, which is compatible
21:27:24 [argyle]
david: ... if this is a, major thing sites can do to improve loading, if a cms can just do this, that's great, and it means that lots of sites can get it cheaply
21:27:41 [argyle]
david: i think, if it's it's won attr() it can do that, i dont think we ..
21:27:59 [fantasai]
s/won attr()/own attribute/
21:28:30 [fantasai]
s/i dont think we/I don't think it's as safe to do if we're re-using width and height/
21:28:33 [argyle]
florian: if the cms wanted to check if there was previously a width and ehight, they could still inject the w/h and multiply by whats needed, but they also need to check minheight and maxheight, and then it gets messy
21:28:55 [argyle]
alan: we're theorizing about things Ojan has experience in, at the most this conversation should inform what he continues to do as he tries to find a solution
21:28:57 [Rossen]
q?
21:29:09 [argyle]
alan: but i'm not sure i see the utility of theorizing when we have an experimentor
21:29:27 [argyle]
florian: utility is we dont need to experiment if we have other demos, not worth checking if we dont want to do it anyway
21:29:29 [xfq]
ack jen
21:29:30 [argyle]
rosson: go ahead jenn
21:29:40 [cbiesinger]
s/rosson/rossen/
21:29:47 [argyle]
jenn: i think the original intention behind what elika was saying, here's an idea, might be much simpler than adding attributes, we'd like this considered
21:29:56 [TabAtkins]
`<style>img { width: 100%; }</style> <img intrinsicsize="350x450">` works by default. Changing it to <img width=350 height=450> doesn't work; you have to manually set `height: auto` in CSS too.
21:30:07 [argyle]
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 [astearns]
s/jenn/jensimmons_ /
21:30:16 [skk]
s/alan/astearns/
21:30:21 [argyle]
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 [argyle]
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 [argyle]
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 [argyle]
rosson: where does this leave us
21:31:38 [astearns]
s/rosson/Rossen /
21:31:44 [argyle]
jenn: sounds like someone's going to find something out
21:31:51 [argyle]
(thanks for the correction y'all!)
21:31:54 [argyle]
(thanks for the corrections y'all!)
21:32:24 [argyle]
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 [argyle]
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 [argyle]
amelia: not sure if there's utility if no one's has implemented it yet
21:33:13 [jensimmons_]
+1 to what AmeliaBR just said
21:33:30 [jensimmons_]
maybe that could even be included in a project called CSS Remedy
21:33:52 [argyle]
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 [argyle]
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 [argyle]
no updating cms, no html file updates, it would let them hook into it via current functionality
21:34:37 [AmeliaBR]
s/attr()/attributes/
21:35:11 [argyle]
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 [fantasai]
s/100's/100,000s/
21:35:25 [argyle]
jenn: quick way to boost all sites
21:35:29 [astearns]
s/on things/on images in the cms/
21:35:50 [argyle]
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 [argyle]
jenn: other proposals will use it for be used for simple and complicated things, and some it'll be too much
21:36:13 [astearns]
s/height 100%/width 100% height auto/
21:36:44 [argyle]
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 [argyle]
tab: happy to do more discussion, but not confident enough to decide now, or for us
21:37:07 [argyle]
chris: maybe we could break out and talk about it?
21:37:15 [astearns]
s/chris/chrishtr /
21:37:21 [argyle]
chris: i dont think i fully understand, and I'd like time for that
21:37:45 [argyle]
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 [argyle]
rossen: i also didnt hear we shouldnt think about the intrinsic aspect ratio, because it'll just work
21:38:12 [argyle]
rossen: tab has committed to work on this fully
21:38:19 [argyle]
tab: chrome people will be working on this
21:38:39 [argyle]
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 [argyle]
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 [argyle]
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 [argyle]
elika: it's already in the draft
21:39:47 [fantasai]
s/elika/fantasai/g
21:39:49 [argyle]
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 [fantasai]
s/jenn/jensimmons/g
21:40:10 [AmeliaBR]
q+
21:40:15 [argyle]
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 [argyle]
jenn: might be right inbetween, and i think we should do what rossen mentioned
21:40:42 [argyle]
rossen: great point, thank you. before we move on
21:40:50 [Rossen]
ack AmeliaBR
21:41:49 [argyle]
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 [astearns]
TabAtkins: definitely should be in wicg - we'll get it there
21:42:48 [argyle]
rossen: topic, css inline, first and last baseline
21:42:51 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/861
21:43:11 [argyle]
dauwhe: no opinions
21:43:30 [argyle]
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 [argyle]
fantasai: do we have the board, do you want the [..] baselines, fantasai explains the problem
21:44:08 [argyle]
fantasai: once you match the baselines, you shift
21:44:19 [argyle]
fantasai: once one of those has multiple lines in it, what do we do
21:44:46 [argyle]
fantasai: do we put it in it's own properly, align baseline preference, and it cascades independently, .. continues explaining
21:45:19 [argyle]
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 [argyle]
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 [astearns]
[fantasai outlines things on the easel]
21:46:16 [argyle]
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 [argyle]
AmeliaBR: new property may not be used
21:46:59 [argyle]
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 [argyle]
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 [argyle]
AmeliaBR: i suppose the value of a new property is that vertical align is already supported with current functionality
21:47:58 [argyle]
AmeliaBR: you may end up with duplication anyway
21:48:07 [argyle]
fantasai: does anyone want to think about it more, or push it off to the next
21:48:31 [argyle]
dbaron: i can imagine there's reasons you want them separate, unknown how important they are. consider multiple languages..
21:48:45 [argyle]
fantasai: alright, we can resolve the issue
21:48:58 [argyle]
dbaron: i'm not convinced anyone will want to do this, but it does seem like a good thing to do
21:49:07 [argyle]
AmeliaBR: resolve to make a new long form property
21:49:20 [argyle]
astearns: we figure the name out later
21:49:24 [argyle]
fantasai: no matter how silly, make suggestions
21:49:37 [fantasai]
s/suggestions/suggestions in IRC, we'll evaluate later/
21:49:41 [dbaron]
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 [argyle]
Rossen: ok, any other opinions that can top David Barons?
21:49:49 [argyle]
Rossen: anyone object to david? or oppose?
21:49:56 [argyle]
Rossen: no objections. resolved.
21:50:19 [argyle]
astearns: so, david, could you put your actual suggestion into resolve line
21:50:35 [argyle]
dbaron: the question was a boolean, do we want a separate prop or not
21:50:48 [argyle]
RESOLVED: we'll add a separate property for this
21:50:51 [argyle]
astearns: great
21:50:55 [argyle]
fantasai: thank you
21:51:09 [argyle]
Rossen: next one is an awesome one
21:52:26 [emilio]
ScribeNick: emilio
21:52:50 [florian]
github: none
21:53:43 [Rossen]
github: https://github.com/w3c/csswg-drafts/issues/861
21:53:53 [emilio]
topic: Houdini <3 text
21:54:06 [emilio]
github: https://github.com/w3c/css-houdini-drafts/issues/854
21:56:15 [emilio]
myles_: So, houdini has a lot of stuff, and I think everything is things that browsers do already, which is cool
21:56:30 [emilio]
myles_: there's one of these things that is not in houdini so far, which is text
21:56:54 [emilio]
myles_: so there's a chance that authors are going to want text layout
21:57:30 [emilio]
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 [emilio]
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 [emilio]
myles_: there's a bunch of things like that listed in the issue
21:58:30 [emilio]
myles_: so I wanted to discuss how should we approach such an API to avoid causing pain
21:59:20 [emilio]
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 [emilio]
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 [emilio]
myles_: I think that'd be bad
22:00:06 [fantasai]
+1 to that being bad
22:00:47 [emilio]
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 [emilio]
AmeliaBR: (summarizing her comment in the issue)
22:01:31 [emilio]
AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355)
22:01:43 [florian]
q+
22:01:56 [fantasai]
AmeliaBR: There's a lot of steps, like [...], that we need to break this down into.
22:02:00 [dauwhe]
q+
22:02:09 [fantasai]
q+
22:02:13 [emilio]
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 [emilio]
AmeliaBR: other things like bidi unicode stuff we don't want to ever expose
22:02:30 [iank_]
q+
22:02:36 [florian]
q-
22:02:38 [florian]
q+
22:03:21 [emilio]
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 [emilio]
AmeliaBR: that's something that people may want but that is easy to get wrong / break
22:04:26 [emilio]
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 [emilio]
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 [Rossen]
q?
22:05:19 [emilio]
fantasai: so you can't just break that up
22:05:20 [Rossen]
ack fantasai
22:05:32 [Rossen]
ack ia
22:05:46 [emilio]
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 [emilio]
iank_: we may want to get smarter about where to break and such, but not atm
22:06:57 [emilio]
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 [emilio]
iank_: you can re-request that if the resulting height is too big for your layout
22:07:42 [emilio]
iank_: some layouts require the available width to change on a per-line-box basis
22:07:59 [emilio]
iank_: we want to prototype that
22:08:10 [Rossen]
q?
22:08:13 [emilio]
myles_: so, I also agree that we mostly agree
22:08:28 [dholbert]
s/models/myles_/
22:09:07 [emilio]
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 [emilio]
iank_: in our engine we do at most two layout passes to avoid shapes
22:09:32 [fantasai]
iank_^: We care about shapes a lot
22:09:40 [emilio]
iank_: which sort of fits in this model
22:09:52 [fantasai]
s/for shapes/for shapes in Houdini/
22:09:57 [emilio]
myles_: I think doing two layouts is unfortunate, describing geometry would be nicer
22:10:53 [emilio]
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 [emilio]
iank_: I think describing all the geometry upfront would be limiting
22:11:26 [emilio]
iank_: one of the examples we want to work is an arbitrary line grid
22:11:39 [fantasai]
q+ to talk about justification
22:11:47 [emilio]
iank_: the avail width of the next line really depends on the line height of the previous line box
22:11:51 [iank_]
q-
22:12:01 [xfq]
ack da
22:12:31 [Rossen]
q+
22:12:45 [emilio]
dauwhe: My industry is very interested in using houdini to improve justification / hyphenation, since the browsers have different requirements
22:12:46 [Rossen]
ack florian
22:12:59 [fremy]
fremy has joined #css
22:13:02 [fremy]
q?
22:13:04 [fremy]
q+
22:13:10 [emilio]
florian: I share the concern that this is important and hard to let people do a lot of random stuff
22:13:28 [emilio]
florian: but they shared examples for i18n where a lot of effects needs a lot of low-level access
22:13:52 [emilio]
florian: but Japanese people may want to increment distance between some glyphs or such
22:14:00 [emilio]
florian: or implement stuff that isn't in browsers yet
22:14:01 [fremy]
q- because basically florian just said what I wanted to say
22:14:05 [fremy]
q-
22:14:22 [emilio]
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 [fantasai]
+1 to ensuring legibility
22:14:54 [emilio]
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 [Rossen]
ack fantasai
22:14:56 [Zakim]
fantasai, you wanted to talk about justification
22:15:09 [skk]
q+
22:15:45 [emilio]
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 [emilio]
... and alignment
22:16:10 [emilio]
fantasai: that way I can see where it fits much more easily, and position it more easily
22:16:56 [emilio]
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 [florian]
s/but Japanese/for example, Japanese/
22:17:26 [Rossen]
q?
22:17:29 [emilio]
myles_: dauwhe, when you said for example you wanted to improve justifications, is ^ what you were referring to?
22:17:33 [emilio]
dauwhe: I think we want more
22:17:37 [fantasai]
s/Justification control/Justification/
22:17:49 [fantasai]
s/justification properties/justificaiton and alignment properties/
22:17:57 [florian]
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 [emilio]
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 [dauwhe]
q?
22:19:25 [dauwhe]
q+
22:19:42 [emilio]
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 [koji]
q+
22:21:10 [fantasai]
TabAtkins: We have existence proof that every single custom layout has done bidi wrong.
22:21:18 [emilio]
Rossen: it seems to me that we're talking about levels of customisability
22:21:38 [AmeliaBR]
q+ to follow up on Rossen's comments
22:21:46 [emilio]
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 [florian]
q+
22:22:12 [emilio]
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 [fantasai]
q+
22:22:28 [emilio]
Rossen: so that we're still not insisting on that rigid one box
22:23:02 [emilio]
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 [emilio]
Rossen: let's not try to take the custom part of layout outside of css
22:23:28 [Rossen]
q?
22:23:47 [Rossen]
ack dbaron
22:23:55 [emilio]
dbaron: I just wanted to bring up another use case that hasn't come up today
22:24:14 [emilio]
dbaron: I think having a low level API is very important for minority languages
22:24:15 [astearns]
[general nodding]
22:24:40 [emilio]
dbaron: Gecko has shipped graphite support
22:24:46 [dbaron]
https://en.wikipedia.org/wiki/Graphite_(SIL)
22:24:50 [Rossen]
q?
22:26:01 [emilio]
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 [emilio]
dbaron: another approach for this would be a low-level JS API using houdini
22:26:20 [dholbert]
(I believe "glat" is one of these graphite font tables that dbaron is referencing)
22:26:23 [dauwhe]
"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 [dauwhe]
hy a set of variant characters to represent these variant sounds."
22:26:33 [emilio]
dbaron: I think that's a potential real usecase
22:26:53 [xfq]
ack skk
22:27:11 [emilio]
skk: From Japanise digital books perspective, more precise Ruby would be amazing
22:27:47 [emilio]
skk: We'd like more control over ruby text positioning
22:28:19 [Rossen]
ack dauwhe
22:28:36 [emilio]
dauwhe: Responding to the phylosophical point, being able to explain and expose all the platform features?
22:28:48 [emilio]
Rossen: it is, what I'm saying is, let's not prevent that
22:29:12 [myles__]
q+ to respond to Rossen
22:29:53 [emilio]
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 [emilio]
Rossen: we've never said "and we don't want to let you do this because it's hard"
22:30:10 [dauwhe]
s/phylosophical/philosophical/
22:30:12 [emilio]
Rossen: why?
22:30:13 [Rossen]
q?
22:30:40 [emilio]
myles__: if your layout is wrong, the text still exists. For layout no layout is wrong, for text it is
22:30:47 [Rossen]
q?
22:30:56 [emilio]
Rossen: if it's unreadable it's unreadable because of me
22:31:12 [emilio]
fantasai: it may be because somebody typed something you didn't expect
22:31:35 [emilio]
fantasai: and you didn't care of thinking of those users
22:31:43 [dauwhe]
q?
22:31:44 [emilio]
fantasai: and those users are our users
22:31:48 [myles__]
s/layout is wrong/layout is not what the author intended/
22:31:57 [emilio]
Rossen: that's my problem, those users are going to complain to me
22:32:33 [Rossen]
Zakim, close queue
22:32:33 [Zakim]
ok, Rossen, the speaker queue is closed
22:32:40 [Rossen]
ack koji
22:33:18 [emilio]
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 [emilio]
koji: but I'm not very confident that JS running through glyphs is performant enough, so box-level layout seems simpler
22:33:55 [emilio]
koji: so re. Rossen's point, we're not against, but we want to start from the simple thing
22:34:23 [xfq]
ack AmeliaBR
22:34:23 [Zakim]
AmeliaBR, you wanted to follow up on Rossen's comments
22:34:55 [emilio]
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 [Rossen]
q?
22:35:35 [emilio]
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 [emilio]
AmeliaBR: I think we should prioritize our work to start with the safest things to change and isolate
22:36:37 [Rossen]
q?
22:36:46 [xfq]
ack florian
22:36:50 [Rossen]
ack fantasai
22:37:22 [heycam]
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 [heycam]
make it harder for them to accidentally not support those things
22:37:30 [emilio]
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 [emilio]
florian: very few people have the bussiness justification to deal with all languages
22:37:59 [emilio]
florian: minority languages is where this is interesting and dangerous
22:38:51 [emilio]
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 [emilio]
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 [emilio]
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]
tantek has joined #css
22:40:39 [emilio]
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 [Rossen]
astearns, assuming this was the interface they have to implement?
22:41:14 [emilio]
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 [emilio]
fantasai: I think koji and AmeliaBR and florian said everything I wanted to say
22:41:49 [xfq]
ack my
22:41:49 [Zakim]
myles__, you wanted to respond to Rossen
22:42:33 [emilio]
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 [emilio]
myles__: there's tons of places in WK where there are assumptions because of english only speakers
22:43:25 [emilio]
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 [emilio]
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 [dauwhe]
q?
22:43:59 [fremy]
q+
22:44:05 [emilio]
myles__: an approach where we take every thing the browser does and making it scriptable is not the highest priorities
22:44:34 [emilio]
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 [emilio]
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 [florian]
+111!1!1
22:45:17 [fantasai]
myles++
22:45:39 [emilio]
myles__: minority languages is a very interesting case, apart from Graphite we also have a similar thing with AAT
22:45:58 [emilio]
myles__: I wish we could find a way to solve that problem in a way where safety is preserved
22:45:59 [florian]
q?
22:47:07 [emilio]
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 [emilio]
Rossen: I wasn't suggesting to start exposing the far end, like glyphs
22:47:47 [emilio]
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 [emilio]
Rossen: is there something that you think it wasn't discussed?
22:48:32 [emilio]
to myles__
22:48:46 [AmeliaBR]
q+
22:48:49 [emilio]
myles__: I think the next thing is gathering use cases, so we're done
22:48:58 [emilio]
Rossen: queue time
22:49:00 [jensimmons_]
q+
22:49:04 [dauwhe]
q+
22:49:06 [Rossen]
Zakim, open queue
22:49:06 [Zakim]
ok, Rossen, the speaker queue is open
22:49:13 [dauwhe]
q+
22:49:15 [jensimmons_]
q+
22:49:22 [emilio]
iank_: to try to wrap up, is there anything inside of the current version of the spec that particularly scares you?
22:49:54 [emilio]
myles__: my biggest concern is about encouraging authors to do layouts in loops
22:50:22 [Rossen]
q?
22:50:26 [emilio]
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 [AmeliaBR]
q+
22:50:49 [emilio]
iank_: I think we agree, but we don't want to limit people which is why we chose this approach
22:51:23 [emilio]
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 [xfq]
ack dauwhe
22:51:37 [emilio]
Rossen: we have a proposal and we have a lot of discussions, let's not say yay or nay
22:51:51 [jensimmons_]
q-
22:52:10 [emilio]
dauwhe: I wanted to make a point re. the responsibility about us making software for our usecase vs. browsers
22:52:21 [Rossen]
q?
22:52:35 [emilio]
dauwhe: we publish english and spanish, I don't think there should be obligation for us to handle vertical or rtl
22:52:43 [xfq]
ack AmeliaBR
22:53:01 [Rossen]
Zakim, close queue
22:53:01 [Zakim]
ok, Rossen, the speaker queue is closed
22:53:06 [emilio]
AmeliaBR: I'm glad myles__ brough this discussion
22:53:26 [emilio]
AmeliaBR: one thing that myles__ and fantasai said is that text was different because it made stuff unreadable
22:53:42 [emilio]
AmeliaBR: I don't think that's true, there are lots of ways you can break content in another ways
22:54:43 [emilio]
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 [florian]
q+
22:54:50 [emilio]
fantasai: I think it's actually worse
22:54:58 [florian]
q?
22:55:22 [astearns]
I disagree with AmeliaBR's comment, and agree with fantasai. Bad text layout has uniquely bad ways of making content inaccessible
22:55:23 [emilio]
Rossen: this is not the end of the discussion, but some of the starting points
22:55:44 [emilio]
Rossen: we need go back and work more on this, we should keep participating passionately
22:55:52 [emilio]
Rossen: next steps is engaging in the specs
22:56:01 [emilio]
Rossen: so go help iank_ ;)
22:56:16 [emilio]
iank_: I'd love that
22:56:27 [emilio]
topic: end
22:56:54 [emilio]
topic: text-wrap: multi-line
22:57:37 [emilio]
github-: https://github.com/w3c/csswg-drafts/issues/672
22:57:40 [emilio]
github: https://github.com/w3c/csswg-drafts/issues/672
22:58:38 [emilio]
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 [emilio]
myles__: line-breaking on the web is greedy, and doing something slower but higher quality is a longstanding request
22:59:31 [emilio]
myles__: I proposed a value for this, which got to the spec and then got removed because of lack of consensus
22:59:34 [florian]
q+
22:59:37 [dauwhe]
q+
22:59:41 [xfq]
zakim, open the queue
22:59:41 [Zakim]
ok, xfq, the speaker queue is open
22:59:45 [dauwhe]
q+
22:59:52 [emilio]
myles__: I'd like to see which opinions for this
22:59:56 [eae]
q+
22:59:59 [emilio]
myles__: it's a very high-level switch
23:00:15 [emilio]
florian: I want to know which one is the author value
23:00:40 [emilio]
florian: I want one of the values to be stable when you type
23:00:49 [astearns]
default is 'wrap' which is stable
23:00:55 [heycam]
q+
23:00:55 [emilio]
myles__: right now the default is stable in every browser
23:00:59 [emilio]
florian: not for print
23:01:08 [emilio]
myles__: you don't type in print preview
23:01:19 [emilio]
myles__: I don't think you need another value, we already have it
23:01:59 [emilio]
florian: I think there should be a stable value
23:02:14 [emilio]
myles__: I think reflecting reality and saying that auto should be stable is fine
23:02:34 [emilio]
fantasai: I think the initial value should allow the UA to do whatever
23:02:42 [xfq]
ack dauwhe
23:02:43 [Rossen]
q?
23:03:06 [emilio]
dauwhe: If the property is added to iBooks I'll add it everywhere
23:03:32 [emilio]
dauwhe: I think you want to change it in existing books too
23:03:32 [fantasai]
fantasai: I think iBooks should just add it to its default UA
23:03:49 [xfq]
ack eae
23:03:50 [emilio]
dauwhe: having the text break better is just going to be a win
23:04:17 [emilio]
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 [emilio]
myles__: in the issue I listed a dozen different criteria
23:04:58 [emilio]
myles__: so describe it explicitly is probably not realistic, do you think agreeing on the goals is fine?
23:05:00 [dauwhe]
q?
23:05:09 [emilio]
eae: yeah, I think that's ok
23:05:11 [dauwhe]
q+
23:05:31 [emilio]
fantasai: dauwhe: myles__: I think it's important to _not_ get compat
23:06:01 [AmeliaBR]
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 [fantasai]
s/fantasai: dauwhe: myles__:/fantasai, dauwhe, myles:/
23:06:26 [emilio]
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 [emilio]
astearns: the current algorithm is not that interoperable
23:06:53 [emilio]
myles__: also, this is an opt-in
23:07:04 [Rossen]
ack heycam
23:07:15 [emilio]
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 [emilio]
myles__: it's the same answer for text-rendering: optimizespeed vs. optimizelegibility
23:07:41 [emilio]
fremy: it's mostly useless
23:07:45 [emilio]
myles__: AmeliaBR: it's not
23:08:07 [emilio]
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 [emilio]
astearns: I think that's a reason for the auto value
23:08:25 [emilio]
astearns: so that the ua can change it
23:08:36 [emilio]
heycam: I'm skeptic about changing line-breaking
23:08:43 [emilio]
(by default)
23:08:58 [xfq]
ack dauwhe
23:09:02 [emilio]
myles__: I'd like to keep the discussion less about the existence of auto
23:09:48 [emilio]
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 [emilio]
dauwhe: text layout is so sensitive that there's never going to be interop
23:10:22 [emilio]
myles__: I want to resolve to put this value back in
23:10:26 [emilio]
Rossen: objections?
23:11:23 [fantasai]
ScribeNick: florian
23:11:41 [fantasai]
florian: I want to make sure we have the three values, including stable.
23:11:49 [dbaron]
ScribeNick: fantasai
23:11:59 [emilio]
ScribeNick: emilio
23:12:15 [emilio]
fantasai: I think we should rename it, but no objection
23:12:27 [emilio]
fantasai: I'm a bit concerned that we are going to add another switch that does nothing
23:12:35 [emilio]
fantasai: but if people feel strongly I won't object
23:13:05 [emilio]
fremy: not an objection either but we need a better definition on what it does
23:13:26 [emilio]
RESOLVED: Add the value back in
23:13:33 [emilio]
fantasai: are we adding stable?
23:14:08 [AmeliaBR]
scribeNick:
23:14:32 [AmeliaBR]
scribeNick: AmeliaBR
23:14:45 [emilio]
myles_: there are three values: auto, balance and this new thing
23:14:57 [emilio]
fantasai: I object to the multi-line name
23:14:57 [AmeliaBR]
scribeNick: emilio
23:15:00 [emilio]
myles_: proposals?
23:15:05 [emilio]
fantasai: pretty sounds good to me
23:15:20 [emilio]
fantasai: it's what we used to discuss it here
23:15:58 [emilio]
RESOLVED: add the stable value
23:16:01 [emilio]
topic: end
23:25:49 [futhark]
futhark has joined #css
23:27:35 [bdc]
bdc has joined #css
23:28:03 [rachelandrew_]
rachelandrew_ has joined #css
23:42:57 [xfq]
xfq has joined #css
23:47:01 [presenter]
presenter has joined #css
23:47:27 [iank_]
scribeNick: iank_
23:47:57 [iank_]
<general discussion about what to talk about>
23:48:07 [iank_]
<.... etc.. ..>
23:49:52 [iank_]
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 [dbaron]
Topic: -webkit-line-clamp
23:49:57 [xfq]
Topic: -webkit-line-clamp compatibility issues
23:50:03 [xfq]
github: https://github.com/w3c/csswg-drafts/issues/2847
23:50:12 [dbaron]
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 [iank_]
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 [iank_]
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 [iank_]
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 [iank_]
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 [iank_]
TabAtkins: The existing WLC impls are bad and horrible.
23:53:10 [iank_]
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 [fantasai]
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 [iank_]
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 [fantasai]
Main concern is really interaction with -webkit-box
23:54:14 [iank_]
TabAtkins: iank_ did some looking.
23:54:20 [florian]
q+
23:55:40 [iank_]
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_]
iank_: This allowed us to kill percentage WLC
23:55:58 [iank_]
heycam: yaya
23:57:01 [iank_]
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 [astearns]
https://www.chromestatus.com/metrics/feature/timeline/popularity/2139
23:57:41 [iank_]
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 [iank_]
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 [Rossen]
q?
23:58:45 [iank_]
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 [iank_]
heycam: I think that's a sensible thing to do.
23:59:23 [xfq]
ack florian
23:59:24 [Rossen]
ack florian
23:59:27 [iank_]
florian: Most differences are intentional
23:59:58 [iank_]
florian: We probably need to do at the syntax level, where you specifiy that you need -webkit-box, etc, to apply the prefixed version.