22:52:47 <RRSAgent> RRSAgent has joined #css
22:52:47 <RRSAgent> logging to https://www.w3.org/2019/09/04-css-irc
22:52:49 <trackbot> RRSAgent, make logs public
22:52:49 <Zakim> Zakim has joined #css
22:52:51 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
22:52:51 <trackbot> Date: 04 September 2019
22:53:23 <liam> liam has joined #css
22:59:34 <AmeliaBR> AmeliaBR has joined #css
22:59:37 <plinss> present+
22:59:37 <tantek> tantek has joined #css
22:59:54 <tantek> Zakim, who is here?
22:59:54 <Zakim> Present: plinss
22:59:55 <Zakim> On IRC I see tantek, AmeliaBR, liam, Zakim, RRSAgent, birtles, drousso, dauwhe, Karen, plinss_, leaverou, sylvaing, shans, Rossen, projector, rbyers, krit, lukebjerring, bradwerth,
22:59:55 <Zakim> ... dholbert, AutomatedTester, cwilso, melanierichards, rhunt, gregwhitworth, nainar, innovati, geheimnis`, Tavmjong, github-bot, dauwhe-irc-cloud, cbrewster, florian, ed, hober,
22:59:58 <tantek> regrets+
22:59:59 <Zakim> ... DenSchub, jamesn, paul___irish, kereliuk, yoichio, NavidZ_, iank_, drott, majidvp, falken, foolip, ojan, dustinm, stryx`, CSSWG_LogBot, plinss, ZoeBijl, emilio, ausi, tobie
23:00:00 <fremy> fremy has joined #css
23:00:05 <florian> present+
23:00:11 <fremy> present+
23:00:19 <birtles> present+
23:00:39 <AmeliaBR> present+
23:01:00 <myles> myles has joined #css
23:01:05 <myles> Present+ Myles
23:01:37 <drousso> present+
23:01:43 <smfr> smfr has joined #css
23:02:07 <smfr> present+
23:02:14 <AmeliaBR> Scribenick: AmeliaBR
23:02:23 <AmeliaBR> rrsagent, pointer
23:02:23 <RRSAgent> See https://www.w3.org/2019/09/04-css-irc#T23-02-23
23:03:53 <AmeliaBR> Agenda: https://lists.w3.org/Archives/Public/www-style/2019Sep/0004.html
23:04:19 <AmeliaBR> astearns: Any agenda additions?
23:04:30 <dino> dino has joined #css
23:04:34 <AmeliaBR> …we may push multicol issues to next week / TPAC.
23:04:52 <AmeliaBR> Topic: Process updates from AB
23:04:55 <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_16
23:05:12 <AmeliaBR> fantasai: We will be presenting these slides ↑ at TPAC
23:05:29 <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
23:05:48 <AmeliaBR> … maintaining a spec that is in late stages up to date is difficult. Want to reduce overhead of frequent updates.
23:06:04 <AmeliaBR> …While maintaining wide review & making sure that is handled.
23:06:04 <fantasai> https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
23:06:37 <AmeliaBR> …Proposal is to update W3C Track Process. E.g., get royalty commitments earlier in the process (CR or WD).
23:07:16 <Rossen_> Rossen_ has joined #css
23:07:16 <AmeliaBR> …For CR, want to automate more routine Director approvals for updates — e.g., if there has been no disagreement/objections.
23:07:20 <Rossen_> present+
23:07:36 <AmeliaBR> …Ideally, you just fill out a form. If all checks are OK, the director isn't going to object anyway.
23:08:24 <AmeliaBR> …But frequent updates are a problem for patent review; don't want patent reviews more often than 6 months. So we want to split CR publication updates from reviews.
23:08:49 <myles> myles has joined #css
23:08:49 <AmeliaBR> …While do the approvals & reviews periodically, but not every time you push a minor update.
23:09:29 <AmeliaBR> …We'll also be formalizing the system that Tantek & (missed) started, annotating spec with notes about what has changed and why. So the review is more predictable.
23:09:56 <AmeliaBR> …So we can issue a call for review on those specific changes. And everything can be reviewed at the same time.
23:10:20 <gtalbot> gtalbot has joined #css
23:10:28 <AmeliaBR> … (This is specifically about changes to a REC spec) Changes can go through full review without re-reviewing entire spec.
23:11:10 <jensimmons> jensimmons has joined #css
23:11:11 <AmeliaBR> … For these easier updates to REC specs, you can only do this if chartered for "extensible specs".
23:11:16 <jensimmons> present+
23:11:27 <dino> present+
23:11:28 <AmeliaBR> …Some specs have a need to be predictable and fixed.
23:11:48 <TabAtkins> present+
23:11:54 <AmeliaBR> …(something about registries. I got behind, sorry)
23:11:58 <fantasai> https://lists.w3.org/Archives/Public/public-w3process/
23:12:08 <AmeliaBR> astearns: How do we give feedback?
23:12:08 <fantasai> https://github.com/w3c/w3process/issues
23:12:18 <AmeliaBR> fantasai: Here is the mailing list & process repo.
23:12:31 <AmeliaBR> astearns: Are issues on the repo recommended?
23:12:53 <AmeliaBR> fantasai: Yes. Minor questions about the slides can be sent direct to me. But issues on repo.
23:13:16 <AmeliaBR> astearns: If these changes go through, should CSS WG change to Living Standard specs for each module?
23:14:12 <AmeliaBR> fantasai: I'm mostly happy with how we work with versioned specs. Switching to updating recs would mean all new development would need to be isolated to note boxes until ready to commit.
23:14:30 <AmeliaBR> …And I wouldn't want to change until we see how this works. But other changes will help.
23:15:00 <AmeliaBR> TabAtkins: I mostly agree. But I'd like to get CSS Syntax as a permanent REC. So that all updates get immediately integrated.
23:15:10 <AmeliaBR> fantasai: And we're not making many changes to Syntax.
23:15:25 <florian> https://w3c.github.io/w3process/everblue/
23:15:25 <fantasai> s/making many changes/adding many features/
23:15:35 <AmeliaBR> florian: One comment about that repo link: Some of what fantasai described hasn't yet been merged into the main branch.
23:15:44 <fantasai> s/Some/Most/
23:16:02 <AmeliaBR> … E.g., the bit about only some CRs triggering reviews.
23:16:20 <fantasai> ^florian: But most of it is in this branch of the Process [link]
23:16:32 <fantasai> ^florian: except a few bits, e.g. ...
23:16:56 <AmeliaBR> astearns: I'd add, if you are an AC rep for / part of an org that cares about patent law, make sure your lawyers see this presentation. It doesn't have all info they need, but they should know what's coming.
23:17:04 <fantasai> https://lists.w3.org/Archives/Member/w3c-ac-members/2019JulSep/0024.html Patent Policy Survey
23:17:08 <oriol> oriol has joined #css
23:17:19 <AmeliaBR> fantasai: There's an open survey for AC reps on Patent Policy. One of many surveys likely going forward.
23:17:42 <AmeliaBR> … (brief summary of Patent Policy survey questions)
23:18:24 <fantasai> Open questions other than the patent policy application poll: https://docs.google.com/presentation/d/e/2PACX-1vSY6cySWt81srZWN_GWl4LMCFSJOw4dYeO-Tlx8Fj_50P5oc0IgzGXFGrZzT3t_cktR9pjDVfNfqmLh/pub?start=false&loop=false&delayms=3000#slide=id.g5ee5921594_0_0
23:18:26 <oriol> present+
23:18:30 <AmeliaBR> … Depending on results, we may be able to update things more smoothly.
23:18:44 <AmeliaBR> Topic: Proposal for Navigation Controls
23:19:03 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4187
23:20:16 <AmeliaBR> TabAtkins: Request for a way to tell if there is a back button or similar (e.g., PWA shells don't always have this), as a media query. Normal browser it would be true. PWA may be false, so you might want to add a back button in your page UI.
23:20:37 <florian> q+
23:20:39 <AmeliaBR> … For now, the request is only for back button, but the proposal is designed in an extensible way.
23:21:37 <AmeliaBR> dino: I don't understand the scope of "back button". Would a back-swipe gesture count? Generally support the idea, but we need to define it.
23:21:59 <AmeliaBR> … I can also see other use cases, like is there a share button?
23:22:17 <myles> Q+
23:22:44 <AmeliaBR> TabAtkins: Question on back swipe is interesting. Not all UI options are equal. Keyboard controls might not be well known. But depends on the platform.
23:23:03 <jensimmons> +1 to being generic... not too focused on How People Do Things in 2019.
23:23:14 <AmeliaBR> dino: That's just an example. My concern is that the query should focus on the functionality rather than the "button" nature.
23:23:27 <astearns> ack florian
23:23:32 <Rossen_> q+
23:23:34 <dino> oops. forgot about queuing :) sorry.
23:23:44 <dino> i just bullied my way in
23:24:10 <AmeliaBR> florian: Individual parts of the media query are useful. But how would it be collapsed to a boolean level, without breaking extensibility?
23:24:48 <astearns> ack myles
23:24:49 <AmeliaBR> TabAtkins: Current proposal is boolean means any navigation control, of which back button is the simplest. If we can't make that assumption, that the boolean mode is probably meaningless.
23:25:45 <AmeliaBR> myles: Some browsers are designed as standalone apps; other browsers integrate with a system, like an iOS webview. Whether there's a backbutton or not depends on the embedding app. Webview doesn't know, may be difficult to implement.
23:26:19 <AmeliaBR> TabAtkins: In that case, if the rendering agent doesn't know, they should probably be conservative & assume there isn't anything.
23:26:49 <AmeliaBR> florian: And maybe embedded web views could add an API for the environment to tell them if they're handling navigation.
23:26:57 <AmeliaBR> myles: that doesn't help with existing apps
23:27:01 <astearns> ack Rossen_
23:27:09 <AmeliaBR> florian: But it could help in combination with sensible defaults.
23:27:22 <AmeliaBR> TabAtkins: And the default wouldn't be any worse than today.
23:27:45 <AmeliaBR> Rossen_: Is there a reason we're only talking about back button right now & not navigation controls as a group?
23:28:15 <AmeliaBR> TabAtkins: No reason to avoid other features. It's just that back-button has the strongest use case & is the one that is most commonly available.
23:28:29 <AmeliaBR> … But I made sure syntax would work with other buttons, too.
23:28:31 <AmeliaBR> q+
23:28:52 <AmeliaBR> … If we find anything that is really important we can add them too.
23:29:12 <drousso> q+
23:29:21 <AmeliaBR> Rossen_: If we are only doing back-button for now, why not just use that in a boolean sense?
23:29:49 <AmeliaBR> … I didn't want "any"/"none" because that could be more complicated for adding things.
23:29:57 <fantasai> ScribeNick: fantasai
23:30:17 <fantasai> AmeliaBR: Would a URL bar be included inside this general concept of navigation controls?
23:30:26 <fantasai> TabAtkins: If people think that's a useful thing to expose, sure
23:30:39 <fantasai> TabAtkins: number of possibilities we could
23:30:55 <fantasai> AmeliaBR: URL bar allows copy/paste of current URL and also allows navigation
23:31:07 <fantasai> AmeliaBR: also can be used to share
23:31:24 <drousso> dino i am too
23:31:26 <fantasai> TabAtkins: Interesting question of whether that should be distinct from share button
23:31:37 <astearns> ack AmeliaBR
23:31:44 <fantasai> florian: Wrt URL bar, I could imagine a UI which has URL bar only but not back button
23:31:44 <AmeliaBR> ScribeNick: AmeliaBR
23:31:54 <fantasai> florian: so assumption of always having a back button might not be correct
23:32:01 <AmeliaBR> TabAtkins: Theoretically, but I don't think that will happen
23:32:09 <AmeliaBR> florian: without a time machine
23:32:20 <astearns> ack drousso
23:32:36 <tantek> tantek has joined #css
23:32:53 <AmeliaBR> drousso: One clarification: Are we talking about the *presence* of these buttons, or whether they are enabled? E.g., in a new tab, back button is disabled.
23:33:43 <AmeliaBR> TabAtkins: I could be convinced either way, I think it's best to say "is it present", regardless of whether currently disabled. Probably don't want to toggle this on and off a lot. Might be used via JS to download extra scripts.
23:34:14 <AmeliaBR> AmeliaBR: What is the request at this time?
23:34:40 <AmeliaBR> TabAtkins: To add to draft. Can discuss specifics later.
23:34:44 <tantek> present+
23:34:51 <AmeliaBR> astearns: Any objections to adding to a media queries draft?
23:35:03 <AmeliaBR> (silence)
23:35:32 <AmeliaBR> RESOLUTION: Add navigation controls media query to MQ 5
23:35:37 <tantek> tries to catch up
23:36:04 <fantasai> RESOLVED: Add navigation controls media query to MQ 5
23:36:07 <AmeliaBR> astearns: We should also get in touch with the original proposer (fallaciousreasoning) for giving credit.
23:36:30 <AmeliaBR> Topic: Expose User Preference Media Queries as HTTP Client Hint or HTTP Header
23:36:38 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4162
23:37:20 <AmeliaBR> TabAtkins: Idea is that some of the preference media queries trigger fairly substantial changes to a page. E.g., reduced motions might trigger more than just CSS fix-ups.
23:37:47 <AmeliaBR> …If you want to make changes on first display, need that before the page downloads.
23:38:00 <dino> q+
23:38:05 <AmeliaBR> …Idea is to pass this info to server as a client hint & server can respond with the good stuff
23:38:26 <AmeliaBR> …Some debate on the invalidation logic. The settings can change over the course of a session.
23:38:43 <astearns> ack dino
23:38:43 <AmeliaBR> …But overall, idea seems reasonable. But I'm not well versed on client hints.
23:39:19 <AmeliaBR> dino: My pref is that this shouldn't happen. Media queries are supposed to be dynamic & can cause page changes.
23:39:36 <tantek> +1 dino
23:39:41 <AmeliaBR> …Changing which JS you download doesn't seem to conform.
23:39:57 <AmeliaBR> …Could also make pixel tracking techniques even easier.
23:40:25 <drousso> q+
23:40:42 <AmeliaBR> TabAtkins: I disagree that changing downloads is a minor benefit. Could help make sure that initial payload is as small as possible, good for many use cases.
23:40:42 <dino> q+
23:40:45 <florian> q+
23:41:14 <astearns> ack drousso
23:41:19 <AmeliaBR> …Already, sites can *try* to do this by setting server cookies based on previous MQ results. That's more likely to mess things up than using HTTP headers.
23:41:36 <tantek> CSS is a tiny fraction of what G sends down compared to the heaps of JS. Not buying the "send less CSS" argument as a practical impact here
23:42:21 <AmeliaBR> drousso: Using the example of dark mode, downloading only a slimmed-down dark mode CSS. If that MQ changes, then the cache invalidation must need to handle the change in state, to know what to download.
23:42:53 <AmeliaBR> TabAtkins: I suspect this is similar to state handling in many JS based apps, but I'm not an expert.
23:42:57 <tantek> LMK if there's a noJS version of G properties that has well designed CSS for normal/dark mode and what % of the page download that would impact
23:43:01 <astearns> ack dino
23:43:28 <AmeliaBR> drousso: Would probably need to add query parameters to CSS so that it can be invalidated.
23:43:53 <tantek> +1 dino thanks for making the right argument. sending both normal/dark CSS rules are tiny compared to all the rest of the page load size
23:44:30 <AmeliaBR> dino: I think the savings for cutting out a bit of CSS is probably not worth the overhead. Cookie tracking might not be that bad an alternative.
23:44:42 <astearns> ack florian
23:44:52 <AmeliaBR> TabAtkins: Sounds reasonable. Can you add these comments to the issue so we can close it with reasons?
23:45:09 <tantek> I'd say, the additional fingerprinting from Client Hints for this are not worth the fractional anticipated performance gain by less CSS compared to the massive JS in practice.
23:45:23 <astearns> ack dbaron
23:45:28 <AmeliaBR> florian: Another concern is privacy. If we allow this on HTTP as well as HTTPS, preferences get leaked everywhere. Also, logged on all sorts of servers
23:46:44 <AmeliaBR> dbaron: I am also generally skeptical. But I think some arguments given here aren't correct & what to make sure those are clarified. Client hints spec integrates with vary headers, so that caching can handle it. And tracking is not as easy as suggested.
23:47:10 <AmeliaBR> …I'd also want more details on proposal anyway before accepting.
23:47:10 <dbaron> s/tracking is not as easy/designed so fingerprinting is active rather than passive/
23:47:26 <AmeliaBR> astearns: OK. So let's follow-up on issue.
23:47:37 <AmeliaBR> Topic: It should be detectable whether an element ellipsized the text
23:47:50 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4123
23:48:43 <AmeliaBR> TabAtkins: Issue comes down to some APIs not reporting subpixels, which can give weird results sometimes. That's worth addressing But I think we can close main issue.
23:49:11 <AmeliaBR> florian: Worth mentioning that the use case is JS code to *show* ellipsized text. If more browsers offered that as a built-in feature, wouldn't need to hack around it.
23:49:29 <AmeliaBR> Topic: Compute non-existent `list-style-type` <counter-style> to `decimal`?
23:49:39 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4210
23:50:33 <AmeliaBR> TabAtkins: fantasai discovered this when cleaning up lists spec. Issue is what should computed style be if you set the list-style-type to a custom ident that doesn't currently exist.
23:51:12 <AmeliaBR> …The used style is decimal. But computing that eagerly (as Firefox used to do) can be problematic, since @-rule could be added later.
23:51:49 <AmeliaBR> …I don't think any other browsers yet implement custom idents; they reject at parse time. I think best to follow current Firefox. Computed value is the custom ident.
23:52:15 <fantasai> s/cleaning up/doing archaeology for the/
23:52:24 <AmeliaBR> astearns: There are Firefox folks in thread pointing out that current behavior wasn't really intentional.
23:52:42 <AmeliaBR> TabAtkins: That's OK. It's still good behavior. Let's spec it properly.
23:52:53 <AmeliaBR> dbaron: If Emilio's OK with it, I'm OK with it.
23:53:07 <AmeliaBR> TabAtkins: He wrote the current Firefox behavior, so I hope so.
23:53:17 <AmeliaBR> astearns: And this will just be no-change to current spec.
23:53:29 <AmeliaBR> RESOLVED: No change re computed value of list-style-type
23:53:36 <AmeliaBR> Topic: Scheduling
23:54:04 <AmeliaBR> astearns: I was planning to have a call next week. dbaron notes many will be travelling.
23:54:19 <AmeliaBR> … We can try to have a call, but see if we will have quorum or not.
23:54:50 <AmeliaBR> Topic: Make `table-caption` and `table-cell` <display-outside> values
23:55:03 <AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3940
23:55:24 <fremy> @AmeliaBR, we moved that issue to TPAC
23:55:41 <fremy> @AmeliaBR you skipped one list issue :)
23:55:57 <fremy> oh, ok
23:56:14 <AmeliaBR> fantasai: Matts wanted to support allowing flex/grid inside table caption. Maybe also table-cell, but there are more layout issues there, so the focus is on caption right now.
23:56:49 <AmeliaBR> TabAtkins: Chrome would have issues with doing this for table cell, although that makes me sad. But I think caption is OK.
23:57:12 <AmeliaBR> iank_: I think it's OK to do this with table-caption. Will need to check.
23:57:35 <dbaron> dbaron: Do table captions affect the table size, or does the table size affect the table caption's size?
23:58:14 <AmeliaBR> fremy: They can in that if the caption is wider than the table, the table gets stretched to the wider size.
23:58:27 <AmeliaBR> florian: That doesn't seem like a very hard interaction to handle.
23:58:43 <AmeliaBR> dbaron: The harder interaction would be if the table layout affected the caption size.
23:58:54 <AmeliaBR> iank: (missed)
23:59:23 <AmeliaBR> iank_: Can we delay this, then?
23:59:46 <AmeliaBR> florian: So, no to table-cell since it's too hard. And no to table-caption as there isn't strong enough demand.
00:00:02 <fantasai> s/(missed)/Was there any demand from authors, or just requesting for completeness?/
00:00:04 <florian> s/no to table-caption/not yet to table-caption
00:00:20 <AmeliaBR> astearns: objections to wontfix?
00:00:27 <tantek> aww
00:00:37 <tantek> hoping its postpone rather than wontfix
00:00:40 <tantek> see you at TPAC!
00:00:40 <AmeliaBR> RESOLVED: Do not add table-cell/table-caption as display-outside values at this time
00:01:03 <AmeliaBR> Topic: Scheduling (part 2)
00:01:19 <tantek> posting regrets for next week's call now :)
00:01:37 <dbaron> Definite regrets from me -- can't do a 1am-2am call and then be ready for a 9am all-day TAG face-to-face meeting
00:01:38 <AmeliaBR> fantasai: It would be nice to know before next meeting if there will be a meeting or not. Especially for those calling in very late from Japan.
00:01:43 <iank_> regrets for next week.
00:01:56 <smfr> i can show up
00:01:59 <plinss> regrets for next week
00:01:59 <myles> I will not attend next week. Tokyo FTW
00:02:05 <florian> I don't wanna show up next week
00:02:14 <AmeliaBR> regrets for next week. I will be in a plane if all is as scheduled.
00:02:41 <fantasai> next week is inconvenient but possible for me, week after TPAC should be no problme
00:06:51 <AmeliaBR> trackbot, end telcon
00:06:51 <trackbot> Zakim, list attendees
00:06:51 <Zakim> As of this point the attendees have been plinss, florian, fremy, birtles, AmeliaBR, Myles, drousso, smfr, fantasai, Rossen_, jensimmons, dino, TabAtkins, oriol, tantek
00:06:59 <trackbot> RRSAgent, please draft minutes
00:06:59 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/04-css-minutes.html trackbot
00:07:00 <trackbot> RRSAgent, bye
00:07:00 <RRSAgent> I see no action items