IRC log of css on 2019-02-20

Timestamps are in UTC.

16:46:32 [RRSAgent]
RRSAgent has joined #css
16:46:32 [RRSAgent]
logging to https://www.w3.org/2019/02/20-css-irc
16:46:34 [trackbot]
RRSAgent, make logs public
16:46:34 [Zakim]
Zakim has joined #css
16:46:36 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:46:36 [trackbot]
Date: 20 February 2019
16:50:53 [TabAtkins]
Regrets for today, dentist appointment
16:52:10 [chris]
chris has joined #css
16:52:57 [TUSF]
TUSF has joined #css
16:55:59 [bdc]
bdc has joined #css
16:57:54 [lajava]
lajava has joined #css
16:59:03 [dael]
dael has joined #css
16:59:24 [gregwhitworth]
present+
16:59:27 [antenna]
antenna has joined #css
16:59:29 [dael]
present+
16:59:33 [dael]
ScribeNick: dael
16:59:39 [rego]
present+
16:59:45 [bdc]
present+
16:59:58 [florian]
present+
17:00:03 [antonp]
Present+ antonp
17:00:31 [astearns]
present+
17:00:31 [lajava]
present+
17:00:43 [dbaron]
Present+
17:00:54 [antenna]
present+
17:01:02 [rachelandrew]
rachelandrew has joined #css
17:01:12 [oriol]
present+
17:01:13 [dael]
astearns: We'll give people a couple more minutes to call in
17:01:57 [nigel]
nigel has joined #css
17:02:37 [bradk]
bradk has joined #css
17:02:46 [dauwhe]
present+
17:02:46 [dael]
astearns: I think we have enough people to start. Does anyone have extra thigns to add besides a new WD of Pseudo 4
17:02:56 [dael]
fantasai: Couple of grid issues if we have time
17:03:00 [rachelandrew]
present+
17:03:03 [dael]
astearns: Things that were just agenda+ last night?
17:03:05 [dael]
fantasai: Yeah
17:03:15 [melanierichards]
present+
17:03:18 [nigel]
Present+ Nigel_Megitt
17:03:18 [dael]
Topic: Publish new WD of Pseudo L4
17:03:29 [florian]
+1
17:03:32 [plinss]
present+
17:03:33 [dael]
astearns: fantasai I assume this is just reg WD?
17:03:46 [chris]
present+
17:04:16 [dael]
fantasai: Yes. Folded in large number of changes incl cascade changes. 2 issues open for F2F discussion are marked int he draft. Shoudl publish new to get it up to date. Major issues left are around first-line and first-letter
17:04:22 [dael]
astearns: Objections?
17:04:31 [dael]
RESOLVED: Publish new WD of Pseudo L4
17:04:40 [dael]
Topic: When to/not to include preserved trailing spaces
17:04:42 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3440
17:04:44 [myles]
myles has joined #css
17:05:56 [dael]
fantasai: This was discussion with koji and xidorn with how trailing spaces handled for intrinisic sizing and alignment. xidorn suggested we consider then when counting for max content. For min content b/c trailing spaces don't create overflow or cause wrapping we shouldn't count them. So longest word, not longest work+space controls content
17:06:39 [dael]
fantasai: Other suggestion was to define spaces hang according to allow-end rules. allow-end if it fits in the line it's not hanging. When you do right alignment it won't go outside. If it doesn't fit we allow it to fit on the line and in that case it's hanging
17:07:01 [dael]
myles: Changing things about expansion opp. is something the web depends on. Do we have compat?
17:07:06 [dael]
florian: We don'thave compat
17:07:13 [dael]
myles: Meaning browsers do different things?
17:07:26 [dael]
florian: Yes. safari does force-end and others do allow-end for alignment
17:07:49 [dael]
myles: I don't think we have any philosophical desire so as long as no web compat problem we're willing to change
17:08:03 [dael]
florian: fantasai your last comment in the issue can you clarify? I'm not sure where that's coming from
17:08:46 [dael]
fantasai: xidorn confirmed my first comment and not second. I think I was trying to figure out...That question is about handling spaces after a forced break diff then soft break or if they're the same
17:08:53 [nigel]
q+ to note https://github.com/w3c/csswg-drafts/issues/1997
17:08:59 [dael]
fantasai: I think just treating the same is the plan unless someone thinks different
17:09:05 [dael]
florian: I would think treat the same
17:09:22 [dael]
fantasai: Obviously they're kind of different when doing [missed] content b/c there is no soft break
17:09:37 [fantasai]
s/[missed]/max-content/
17:10:12 [dael]
florian: For rest of the question I think in terms of taking into account for max content and not min content I initially thought we would ignore in both. If you think in terms of punctuation this proposal makes more sense. Including in max-content is right idea. For alignment I could go either way
17:10:39 [ericwilligers]
ericwilligers has joined #css
17:11:01 [dael]
fantasai: That's what I was thinking. spaces then text then spaces. If we say hang in general and you wrap halfway throught he text you'd see the beginning spaces but not the end. If you right align we end up hanging them
17:11:14 [dael]
fantasai: Gonna depend on how they happen to fit. I think proposed behavior is fine
17:11:20 [dael]
florian: Makes sense. Good argument
17:11:32 [dael]
astearns: nigel had a point but he's having difficulty being heard
17:12:23 [dael]
fantasai: If asking about issue #1997 that's about if inline elements interrupt whitespace trimming. whitespace is trimmed when collapsible, but this is when it's not collapsable so it's not really related
17:12:34 [dael]
astearns: nigel can you indicate on IRC if that makes sense?
17:13:05 [nigel]
okay, I was just referencing that other issue because it seemed relevant
17:13:26 [dael]
florian: I am in supprot of proposal. Tests need to be updated but I will do so
17:13:38 [dael]
astearns: trailing spaces should be counted for max-content but not min-content
17:13:39 [nigel]
and space allocation at the ends of lines is a big deal for e.g. captions.
17:13:41 [dael]
astearns: Objections?
17:13:50 [dael]
RESOLVED: trailing spaces should be counted for max-content but not min-content
17:13:58 [dbaron]
this is all just *preserved* trailing spaces, right?
17:13:59 [dael]
astearns: What is next thing to resolve?
17:14:11 [florian]
dbaron, yes
17:14:15 [dael]
fantasai: when spaces hang they hand using allow-end behavior rather than force-end
17:14:23 [ericwilligers]
present+
17:14:29 [dael]
astearns: dbaron has a question on previous and that is correct as far as I understand
17:14:39 [dael]
fantasai: Yes.
17:15:00 [nigel]
q-
17:15:16 [dael]
astearns: Next is when preserved trailing spaces hang they do it using allow-end rather than force-end
17:15:25 [dael]
RESOLVED: when preserved trailing spaces hang they do it using allow-end rather than force-end
17:15:31 [dael]
fantasai: Think that's all on this issue
17:15:40 [dael]
Topic: Empty grid tracks should contribute to scrollable overflow
17:15:47 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3638
17:16:17 [dael]
astearns: Had some discussion, sounded to me like we were breaking toward including explicit tracks in scrollable area of grid container
17:16:23 [dael]
fantasai: I agree with that
17:16:36 [AmeliaBR]
AmeliaBR has joined #css
17:16:43 [dael]
astearns: Mats had a couple responses at end of thread that sounded like he's not objecting but not happy
17:17:35 [dael]
fantasai: Wondering if that's b/c impl track info about tracks temp but don't store. Then managing overflow requires tracking additional information somehow. But I think authors really do expect those tracks to be in scrollable overflow so we should do that
17:17:39 [dael]
astearns: Other opinions?
17:17:47 [AmeliaBR]
present+
17:17:56 [AmeliaBR]
RRSAgent, pointer?
17:17:56 [RRSAgent]
See https://www.w3.org/2019/02/20-css-irc#T17-17-56
17:18:35 [dael]
lajava: I also have doubts about impl this in Chrome. I commented some of my issues with this approach. Because the example about grid tracks contributing to intrinisic size I don't think is the ame as contributing to overflow area as Mats pointed out in last comment
17:18:58 [dael]
florian: You mean technically they're different so no technical reason to handle the same?
17:19:50 [dael]
lajava: Conceptual PoV. I don't think it's technically difficult but the argument for doing it is tracks contribute to intrinsic size. BUt in this case grid container has a specific size so shoudln't consider tracks as content by themselves. Why the overflow area is bigger then specific size if there is no content?
17:20:59 [dael]
florian: I think logic is the author explicitly asked for that size. Even if not putting anything in it putting a size indicates theye xpect tht large. The intrinsic size is one way to see that the size they ask is what they get. If they don't observe it as that size it breaks that assumption. yeah there's no content but grid is often to use whitespace as an active part of the design
17:21:44 [dael]
astearns: If you have a grid container that has explicit grid tracks, is auto sized, and not scrolling you'll see trailing white space before next bit of content. If you then constrain height and make it scrollable that whitespace disappears. That seems surprising to me
17:22:53 [dael]
lajava: I'm not sure. I think if there are items in the second row even that first is empty I think we use the bottom position of first item to define scrollable area. In a why the whitespaces in the first row are not lost. Youmean the trailing ones? Yeah, I see
17:23:01 [dael]
lajava: As Mats said there are other ways to achieve that
17:24:19 [dael]
fantasai: But there's the question of what do authors expect. They expect the rows to be considered as space that'st here. That they're not scrollable is confusing to them and not what expected. If creating a grid and want random empty spots, if they happen to be in one row that row shoudln't collapse away. If theys aid there is a 100px column it should be there. It might be there from impl but end result of the page is you can't tell it's there.
17:25:03 [dael]
florian: Thought of something else. Invisible things causing scrollbars to appear tends to be a thing authors hate. Given this isn't part of box model this is harder to find. I think with FF grid dev tools you could figure out what's going on but not other browsers
17:26:01 [dael]
fantasai: I think if you give explicit track sizes you should be able to figure out it's causing the scroll. We also have padding and it should be considered in scrollable and we get a lot of bugs on why it's not. Initial behavior for overflow is you trigger only as necessary to show content. There are a lot of general expecttations that there will be scrollbars
17:26:45 [dael]
fantasai: Authors are unhappy when don't include padding in scrollable overflow. We're limited by web compat there, but we're not here. I don't think authors will be they put 10 tracks of 100px and why is my scrollable overflow not 500px because only half are full.
17:26:49 [dael]
florian: I'm back to agreeing
17:27:10 [dael]
astearns: Your point is fair that this is a new thing that causes space to be added. This isn't in pre-grid dev tools, but that's a dev tool issue
17:27:27 [dael]
plinss: General principle: If you change the overflow behavior it should not effect it's size
17:27:46 [dael]
astearns: And size before changed overflow is what we're trying to arrive at where emptytracks contribute to scrollable
17:27:57 [dael]
iank_: What is use case authors want to have additional tracks?
17:28:16 [dael]
astearns: Preserving layout intent. It had the whitespace before scrollable so should contibue once it is
17:28:27 [dael]
florian: And what fantasai said about breathing space between content and edge
17:28:33 [dael]
iank_: So what padding was previous
17:28:42 [dael]
AmeliaBR: Or saving space for content that will be added
17:28:58 [dael]
astearns: Good point. Not changing the size as you add things to explicit grid is pretty useful
17:29:06 [dael]
iank_: Really good point AmeliaBR
17:29:19 [rego]
the padding is also lost as oriol explained https://github.com/w3c/csswg-drafts/issues/3638#issuecomment-464400716
17:29:23 [dael]
astearns: I thinkw e are converging on including explicit grid track sizing to the scrollable area of a grid container
17:29:30 [rego]
it'll be nice to be consistent on that case in the future too
17:29:38 [dael]
astearns: Anyone on the call that has an argument against or would object to resolving?
17:29:53 [dael]
lajava: I think rego has a point with padding not being consistant. I think oriol mentioned that in issue
17:30:38 [dael]
oriol: Prob with padding is there is no interop. In FF it does not add space but in Chromium the space is always added in block axis and sometimes in inline. So there is no interop. I think this is a similar case and would prefer consistent model.
17:31:07 [dael]
fantasai: We'd like consistent but we're constrained on compat. There are issues on overflow spec and hte goal is to include the padding.
17:31:23 [dael]
astearns: If oriol says there is no interop there may be more possibility to get behavior we want
17:31:49 [fantasai]
See issues in https://drafts.csswg.org/css-overflow-3/#scrollable
17:31:51 [dael]
fantasai: The amount to which chrome includes padding we're trying to do that. yOu can see those issues on overflow spec. but in inline axis it's pretty random. Sep discussion
17:32:03 [dael]
daniel: I'm testing chrome 24 and it seems to behave same as FF
17:32:11 [dael]
lajava: Yes because we just fixed the bug
17:32:37 [iank_]
s/chrome 24/chrome 74/ (I assume)
17:32:38 [dael]
lajava: b/c there is nothing in the spec that suggests we should use grid tracks to contribute to overflow area. If we want this to be new we should propose new text
17:32:47 [dael]
fantasai: Yes, this is not a clarification
17:33:17 [dael]
astearns: That is a slight concern. There is a bug Chrome canary responded to. I'm not sure if that's interop or if person that wrote the chrome bug wanted space to collapse.
17:33:25 [dael]
fantasai: Don't know, but guessing spec compliance.
17:33:29 [dael]
astearns: My guess as well
17:33:39 [dael]
florian: If I'm looking at right thing, chrome bug is from Mats
17:34:04 [dael]
lajava: Yeah, original bug was to FF but Mats argued they followed spec and he filed bug against Chrome. WE decided to follow spec
17:34:10 [zcorpan]
zcorpan has joined #css
17:34:12 [dael]
astearns: Thanks for the quick response on that
17:34:22 [dael]
lajava: Means we need to agree with Mats this is behavior we will impl
17:34:54 [dael]
astearns: Certainly. If we resolve we need to get Mats to agree to change behavior to spec. Unfortunate he's not on call, but I don't see in his issue comments reasons to not resolve the way we intend
17:35:28 [dael]
florian: Clarification point or extra argument. Given that Chrome in some cases includes padding if we have empty tracks and padding it seems it will be confusing to including padding and not empty tracks
17:35:39 [dael]
astearns: Interop on incl padding?
17:36:13 [fantasai]
https://drafts.csswg.org/css-align-3/#overflow-scroll-position
17:36:15 [dael]
florian: No but we're trying to including it at least as much as we can. And when alignment is not the default we always do. So when we have some cases where include the padding not including empty track seems weird. Or am I confused?
17:36:39 [dael]
fantasai: I think we should try and include padding in grid if we can. If we can include empty tracks we should because it's used for many more cases then padding
17:36:52 [dael]
florian: Yes, but given padding is outside not including the inside is confusing
17:37:11 [dael]
fantasai: Tackle in sep issue but I think you're right we should adjust grid and flexbox to do thing authors want to do
17:37:34 [dael]
astearns: Objections to including space in empty explicit grid tracks in the scrollable overflow area?
17:37:35 [florian]
+1
17:37:43 [dael]
RESOLVED: Include space in empty explicit grid tracks in the scrollable overflow area
17:38:02 [dael]
astearns: Hopefully impl can follow. We'll get feedback as we go.
17:38:12 [dael]
astearns: Do we have issues for including padding in scrollable areas?
17:38:14 [dael]
florian: We do
17:38:24 [dael]
fantasai: Might want a separate one on grid
17:38:29 [dael]
astearns: Is that overflow spec or grid?
17:38:35 [dael]
fantasai: mmm...I think grid. I'll file
17:38:38 [AmeliaBR]
Lots of open issues: https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+scrollable+padding
17:38:44 [dael]
Topic: Specify better handling of text shadows for ::selection
17:38:52 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3605
17:39:22 [bradk]
bradk has joined #css
17:39:30 [dael]
astearns: I see daniel commented. Did you get to read spec daniel?
17:39:36 [dael]
daniel: I haven't
17:39:40 [bradk]
present+
17:40:18 [dael]
fantasai: When we highlight text the problem is if you have a shadow behind. In general I would expect highlight to obscure shadow. In tess I've seen highlighting lets you see text badly styled.
17:40:28 [dael]
daniel: Sounds like you don't expect pic I posted?
17:41:10 [dael]
fantasai: The color of text and background of highligh are defined by selection. If we keep color of text from selection but take shadow from author we might not get enough contrast between text and shadow behind.
17:41:39 [dael]
fantasai: Whereas if we obscure the text shadow then you can ensure there is enough contrast b/c you have chosen both text and background color
17:42:17 [dael]
AmeliaBR: A little confused about drawing over text shadow. It's not like text decoration where it's contibuous from parent. text shadow is inheriting. It's not about drawing over, it's were' drawing within selection and that's part of character style
17:42:36 [dael]
chris: Sounds like 2 models for this. One if it's above or below and another is painting over.
17:42:54 [dael]
fantasai: That's fair. Maybe way to deal is UA default sheet should have text-shadow:none and that turns it off in selection
17:43:17 [chris]
s/painting over/painting without shadow/
17:43:25 [dael]
daniel: I like effect in picture. That would be example of if someone wanted to do word processing that's what I'd expect as a user. Any way we can let a webdev get that?
17:43:42 [dael]
fantasai: If we go with AmeliaBR model author could set text-shadow unset?
17:44:13 [dael]
AmeliaBR: But what if you want it preserved in selection. Maybe in the default selection styles could include turning off text shadow. But if user sets selection styles we shoudln't unset an inherited style
17:44:23 [chris]
+1 to what Amelia said. Set a good default but give authors control
17:44:27 [dael]
fantasai: I think in cases users won't think through it. If selection color was navy blue and white
17:44:42 [dael]
AmeliaBR: If author has set custom selection and not considered contrast that's author error
17:44:59 [dael]
fantasai: Theyd idn't think about the text shadow that's incompat. I think text shadow should be an explicit opt in
17:45:21 [dael]
AmeliaBR: As an author I would not want browser to mess thigns up so I have to explicitly say text-shadow:inherit on my selection
17:45:34 [dael]
fantasai: I don't think text-shadow:inherit would work b/c inherit from parent selection
17:45:59 [dael]
chris: Better to let author do what they want. Fine to have a default, but argument for not having contrast is same for setting foreground and background color.
17:46:24 [astearns]
also chris: you can't legislate against bad design
17:46:57 [dael]
fantasai: I think it's a question is where styles come from and do authors except them to combine. You as author should set background and foreground readable and text shadow in conjunction with that. Seems unlikely you'll style a psace and have headers with white text on black shadow and somewhere else in stylesheet you have hot pink as selection color with black text
17:47:41 [dael]
fantasai: Then in that section you have black text on a black shadow with a hot pink background. It's hard to read. You were thinking about making sure you had enough contrast, but where you set text shadow it takes effect
17:48:27 [dael]
AmeliaBR: I want to point out one of the things I use text-shadow for is to create contrast. If I've intentionally added something to create contrast and you wipe it for selection that could be counterintuitive. Unless I have easy way to say inherit that i's confusing
17:49:03 [dael]
fantasai: But that is cause of creating context, but when have selection you have different background and text color and shadow will no longer give you contrast. It should be exactly wrong color
17:50:00 [dael]
daniel: Seems to alternate between 2 audiences. One is web dev and stylesheet and other is person on computer who has own stylesheet. I think there's 2 answers. If this is for the website it's the website author's problem. I can see your argument makes sense for a human who has their own stylesheet
17:50:44 [dael]
fantasai: I'm worried about author picks good colors in all cases but when you use selection color with the shadow that was for the heading you end up with a combo of the same color becaue selection wasn't thinking about heading having shadow
17:51:03 [dael]
daniel: I think that's their responcibility to think through. They can do selection pseudo with good properties.
17:51:42 [dael]
daniel: solution: if you take the selection, paint the background and then blend shadow when you paint so that it preserves contrast. NOt exactly what author wants but we're correcting. Could be crazy solution
17:51:57 [dael]
fantasai: If author wants text shadow to show through selection you can set that
17:52:14 [dael]
daniel: I think that's the wrong audience. What does use expect and I think they would expect shadow to stay
17:52:20 [dael]
fantasai: I didn't expect it to stay
17:52:31 [dael]
daniel: Native OS gets you that result
17:54:02 [dael]
gregwhitworth: We are doing a lot of user studies in similar scenario. WE had to come to same conclusion that ultimately that's what selection pseudo is for and author needs to think through. WE have to give capability for authors to override so they can still do stupid things. I don't know what to standardize but would instead leave it to UAs. This comes down to user preference and in our studies people wanted it all ways and authors too.
17:54:17 [dael]
gregwhitworth: Don't know how to strandardize and take that all in in a meaningful way
17:54:39 [chris]
authoring advice is a good way forward
17:54:44 [dael]
astearns: Maybe we change from what should happen in the spec to an authoring note telling authors they should consider this but not put normative requirements on UA
17:55:19 [dael]
florian: seems like a lot of work for authors. Every time you have selection you should turn off text shadow before you think about it so you get right contrast. Defualt is you have to cancel the shadow and please think about it
17:55:26 [dael]
astearns: Not sure default is you should cancel the shadow
17:55:53 [dael]
florian: If you set selection you set foreground and background color. If shadow comesfrom whereever it could be whatever color and you don't know contrast is good
17:56:10 [dael]
florian: So by default you need to suppress it
17:56:36 [dael]
fantasai: No one is going to think to reset shadow when setting selection. you're not using shadows everywhere. I think we should be biased toward good contrast
17:56:53 [dael]
daniel: Could adjust visibility of color. webkit does this for regular foreground text. That's one way
17:57:04 [dael]
fantasai: Let's talk about this later, we're not going to resolve today
17:57:21 [dael]
astearns: Not much time in the call and not hearing consensus. Let's close for now and come back.
17:57:40 [dael]
topic: end
17:57:42 [dael]
astearns: In IRC rego pointed out a possible agenda item
17:57:44 [astearns]
https://github.com/w3c/csswg-drafts/issues/3416
17:57:44 [gregwhitworth]
fantasai: maybe we can discuss this at the F2F as a breakout session?
17:57:57 [fantasai]
gregwhitworth, added it to the F2F agenda
17:58:03 [dydz]
dydz has joined #css
17:58:18 [dael]
astearns: Prob need to cover at F2F so please take a look. Also a couple of grid items fantasai mentioned but please look so we can get to them at F2F.
17:58:19 [gregwhitworth]
fantasai: thanks
17:58:24 [dael]
astearns: Anything else?
17:58:43 [dael]
astearns: That's it then. For everyone travelling next week, safe travels. See you then.
18:05:23 [Tav]
Tav has joined #css
18:28:36 [atrigent]
atrigent has joined #css
18:54:27 [bgirard]
bgirard has joined #css
19:21:10 [Karen]
Karen has joined #css
19:54:13 [astearns]
trackbot, end meeting
19:54:13 [trackbot]
Zakim, list attendees
19:54:13 [Zakim]
As of this point the attendees have been gregwhitworth, dael, rego, bdc, florian, antonp, astearns, lajava, dbaron, antenna, oriol, dauwhe, rachelandrew, melanierichards,
19:54:16 [Zakim]
... Nigel_Megitt, plinss, chris, ericwilligers, AmeliaBR, bradk
19:54:21 [trackbot]
RRSAgent, please draft minutes
19:54:21 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/02/20-css-minutes.html trackbot
19:54:22 [trackbot]
RRSAgent, bye
19:54:22 [RRSAgent]
I see no action items