IRC log of css on 2020-07-31
Timestamps are in UTC.
- 00:26:56 [innovati]
- innovati has joined #css
- 01:07:55 [innovati]
- innovati has joined #css
- 02:30:12 [geheimnis`]
- geheimnis` has joined #css
- 04:43:57 [Rossen_]
- Rossen_ has joined #css
- 04:44:15 [Rossen_]
- Rossen_ has changed the topic to: day 4 agenda: https://wiki.csswg.org/planning/virtual-summer-2020#friday
- 05:08:37 [hober]
- hober has joined #css
- 05:36:53 [fantasai]
- good morning heycam|away !
- 05:37:06 [fantasai]
- or afternoon or whtaever
- 07:16:59 [innovati]
- innovati has joined #css
- 07:50:17 [rego]
- rego has joined #css
- 11:52:09 [plh]
- plh has joined #css
- 13:12:34 [castastrophe]
- castastrophe has joined #css
- 13:21:46 [castastrophe]
- castastrophe has joined #css
- 13:51:29 [Rossen_]
- Rossen_ has joined #css
- 13:51:50 [Zakim]
- Zakim has joined #css
- 13:52:02 [Rossen_]
- Zakim, start meeting
- 13:52:02 [Zakim]
- RRSAgent, make logs Public
- 13:52:03 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 13:57:34 [AmeliaBR]
- AmeliaBR has joined #css
- 13:58:38 [Rossen_]
- present+ Rossen Atanassov, Microsoft
- 14:00:32 [faceless2]
- faceless2 has joined #css
- 14:01:45 [alisonmaher]
- alisonmaher has joined #css
- 14:01:52 [alisonmaher]
- present+
- 14:02:13 [cbiesinger]
- present+
- 14:02:18 [castastrophe]
- present+
- 14:02:27 [jfkthame]
- jfkthame has joined #css
- 14:02:34 [Rossen_]
- present+ Rossen Atanassov
- 14:02:35 [jfkthame]
- present+
- 14:02:48 [astearns]
- present+
- 14:02:51 [AmeliaBR]
- present+
- 14:04:17 [dholbert]
- dholbert has joined #css
- 14:04:30 [dholbert]
- present+
- 14:04:32 [faceless2]
- I don't seem be able to join on video? I enter the code (***-dama-***) but then am told no-one else is here...
- 14:04:34 [oriol]
- oriol has joined #css
- 14:04:43 [oriol]
- present+
- 14:04:51 [dholbert]
- faceless2, doing that same thing worked for me FWIW
- 14:05:16 [TabAtkins]
- present+
- 14:06:17 [faceless2]
- present+
- 14:09:01 [TabAtkins]
- ScribeNick: TabAtkins
- 14:09:33 [TabAtkins]
- Topic: Should ::first-letter include space separator?
- 14:09:37 [Rossen_]
- github:https://github.com/w3c/csswg-drafts/issues/5154
- 14:09:57 [drousso]
- drousso has joined #css
- 14:10:09 [drousso]
- present+
- 14:10:13 [tantek]
- tantek has joined #css
- 14:10:22 [tantek]
- present+
- 14:11:00 [TabAtkins]
- astearns: We got the examples tantek was asking for
- 14:11:18 [TabAtkins]
- astearns: For Norwegian and the other language [French, I think], it makes sense to add those space separators, since they're in the markup
- 14:11:46 [TabAtkins]
- astearns: A little afraid of turning it on for other langs, becuase if you have an open-quote and capital letter, and all you want is the quote itself, maybe people are adding spaces to create the separation currently?
- 14:12:10 [TabAtkins]
- florian: I think dauwhe said they were inserting spaces to adjust visual separation for English content, so they would want the space included.
- 14:12:21 [TabAtkins]
- tantek: I tried to do a little more research as well.
- 14:12:24 [TabAtkins]
- tantek: Didn't have time to upload
- 14:12:33 [TabAtkins]
- [shows Elements of Typographic STyle]
- 14:12:49 [TabAtkins]
- tantek: ON p64, there's some first-letter effects with leading punct, including with guillarmes
- 14:13:25 [TabAtkins]
- tantek: So the point I'm making here is that it's not the entire thing is the first letter, it's that the punctuation is skipped over, only the letter is embiggened, then the punct is situated next to it.
- 14:13:36 [TabAtkins]
- tantek: So I'm concerned we might be doing the wrong thing.
- 14:13:56 [TabAtkins]
- astearns: There's a separate issue addressing that layout, and the current suggestion to get that addressed requires the punct to be part of the ::first-letter
- 14:14:08 [AmeliaBR]
- q+
- 14:14:09 [TabAtkins]
- tantek: Ok [shows an example in English too]. Maybe we should consider these issues together.
- 14:14:19 [fantasai]
- It's issue 2040
- 14:14:22 [TabAtkins]
- astearns: I'll drop it in the minutes.
- 14:14:56 [Rossen_]
- ack fantasai
- 14:15:16 [TabAtkins]
- fantasai: So this is about whether we include the space *when* there is a quotation mark, not about the quotation mark itself.
- 14:15:24 [TabAtkins]
- fantasai: If we want French and English to be the same, we need to include it.
- 14:15:37 [astearns]
- there is also https://github.com/w3c/csswg-drafts/issues/4988 for changing size of components of initial-letter
- 14:15:39 [TabAtkins]
- fantasai: As astearns said, 2040 is about the formatting question if you want the punct and letter different.
- 14:15:54 [tantek]
- q?
- 14:16:01 [TabAtkins]
- fantasai: Richard said we didn't need to include U+0020 space, becuase the spaces used here are typically other spaces, not the standard word separator.
- 14:16:06 [florian]
- q+ to comment on U+0020
- 14:16:17 [TabAtkins]
- fantasai: So if we're really concerned, we cna exclude u+0020 and only include the other spaces.
- 14:16:32 [TabAtkins]
- fantasai: And note that the punct by itself wont' be picked up as a ::first-letter anyway; you need a letter.
- 14:16:45 [TabAtkins]
- AmeliaBR: I'm not sure about ignoring u+0020, lots of people will type this with a stadnard space
- 14:16:48 [Rossen_]
- ack AmeliaBR
- 14:16:53 [TabAtkins]
- AmeliaBR: But probably the more exotic spaces can be ignored.
- 14:17:03 [chris_]
- chris_ has joined #css
- 14:17:16 [chris_]
- present+
- 14:17:29 [TabAtkins]
- AmeliaBR: The one common thing from tantek's examples, and some in the issue, where the initial punct is different than the letter, they all have the letter as big. So to do that, we at least need the characters up to the letter to be included.
- 14:17:39 [chris_]
- rrsagent, here
- 14:17:39 [RRSAgent]
- See https://www.w3.org/2020/07/31-css-irc#T14-17-39
- 14:17:42 [fantasai]
- Anyone who's fussy about typography will use the correct space, I think :)
- 14:18:00 [TabAtkins]
- AmeliaBR: If we dont' come up with a special solution for people who want the punct to be offset or smaller, there's always the option of people including spans to mark off certain characters.
- 14:18:09 [Rossen_]
- ack florian
- 14:18:09 [Zakim]
- florian, you wanted to comment on U+0020
- 14:18:12 [tantek]
- if I paste this here does it work? https://github.com/w3c/csswg-drafts/issues/2040
- 14:18:20 [TabAtkins]
- florian: Good guides about typography will say to use various spaces, but most people dont' know how to type those.
- 14:18:29 [astearns]
- I think we should allow the regular space, even though I'm fussy about typography
- 14:18:37 [TabAtkins]
- florian: At least in French, it's pretty common to say ordinary spaces, probably same in Norwegian. So I'd include standard space.
- 14:18:47 [Rossen_]
- q?
- 14:19:19 [TabAtkins]
- tantek: My concern is that if we just flip this on, we'll cause pages that have not been tested with this to suddenly have first-letters that didn't before.
- 14:19:31 [TabAtkins]
- tantek: And end up with big punctuation as well as big letters.
- 14:19:42 [TabAtkins]
- tantek: That might come as a surprise to authors who are used to not doing that automatically.
- 14:19:47 [TabAtkins]
- tantek: And I'm not sure it's the right default.
- 14:20:08 [TabAtkins]
- tantek: So if it is punct-space-letter, maybe the letter itself should be the only thing included as the ::first-letter, and the pucnt gets normal inline styling.
- 14:20:10 [fremy]
- fremy has joined #css
- 14:20:16 [TabAtkins]
- tantek: That would look closer tothe typography examples.
- 14:20:19 [florian]
- q+
- 14:20:28 [TabAtkins]
- tantek: I'm concerned we have yet another place where we do the wrong thing typographically by default.
- 14:20:44 [TabAtkins]
- tantek: The web has a tradition of this, liek the way large text messes up the line rhythm.
- 14:20:48 [chris_]
- so now we need a term for "the characters before the first actual letter"?
- 14:20:53 [TabAtkins]
- tantek: So I'm concerned if we add one more papercut.
- 14:21:10 [fantasai]
- chris_, we need a pseudo-element, yes :)
- 14:21:13 [TabAtkins]
- q+
- 14:21:24 [TabAtkins]
- tantek: 5154 shows what browsers are currently doing
- 14:21:48 [TabAtkins]
- tantek: There's an example with th eleading quote... [missed]
- 14:22:06 [Rossen_]
- ack fantasai
- 14:22:10 [TabAtkins]
- fantasai: I think tantek is getting caught up in the not-perfect
- 14:22:14 [astearns]
- in the examples provided for this issue, the punctuation *does* take the same styling as the letter: https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-659129316
- 14:22:16 [chris_]
- ::first-letter-before
- 14:22:21 [TabAtkins]
- fantasai: I think you're forgetting that English and French punct have the same problem and have to be treated the same way
- 14:22:35 [Rossen_]
- ack florian
- 14:22:36 [TabAtkins]
- fantasai: We need to include the space to keep these on-par, and having them be inconsistent is bad
- 14:23:02 [TabAtkins]
- florian: Having ::firs-tletter select the letter and not the preceding punct seems bad, it's already complicated, sounds scary.
- 14:23:03 [fantasai]
- s/bad/bad and doesn't solve those problems anyway/
- 14:23:20 [TabAtkins]
- florian: As to compat, Safari does it already. So there's some amount of content out there probably already depending on it.
- 14:23:20 [florian]
- http://www.typografi.org/dropcaps/assets/sitatstrek-anf%C3%B8rselstegn_714.jpg
- 14:23:30 [TabAtkins]
- florian: So in this example we actually do want the included thing to be large.
- 14:23:47 [TabAtkins]
- florian: In other cases we wont' want the punct large, but those apply equally to the exisdting punct-letter without space.
- 14:24:05 [fantasai]
- TabAtkins: Florian touched on it at the end, one of the big concerns Tantek brought up
- 14:24:12 [fantasai]
- TabAtkins: is wanting to address differently-sized punctuation wrt first-letter
- 14:24:26 [fantasai]
- TabAtkins: But that's already the case. If there's no space, we already have that problem, already have to solve it.
- 14:24:32 [fantasai]
- TabAtkins: It's not relevant to this issue.
- 14:24:35 [Rossen_]
- ack TabAtkins
- 14:25:15 [TabAtkins]
- Rossen_: So I think there were several reasons for ahving this, including some existing shipping impls
- 14:25:23 [TabAtkins]
- Rossen_: So it's probably not a compat risk, or at least not a big one.
- 14:25:24 [tantek]
- q+
- 14:25:48 [Rossen_]
- ack tantek
- 14:25:54 [TabAtkins]
- tantek: I don't actuallys ee the Safari example as proof of no compat problem
- 14:26:02 [TabAtkins]
- tantek: Safari applies all th epunct as well.
- 14:26:19 [TabAtkins]
- tantek: It wouldn't surprise me if there's special-casing going on here, looks like impl by accident.
- 14:26:27 [TabAtkins]
- tantek: Looking at an example with a massive preceding dash.
- 14:26:39 [TabAtkins]
- tantek: It woudlnt' surprise me if people are already not giving that styling to Safari to avoid that problem.
- 14:26:51 [TabAtkins]
- astearns: Also in CHrome
- 14:27:01 [AmeliaBR]
- Slight tangent, but while testing I discovered that browsers treat quotes in the markup different from quotes inserted via `::before { content: open-quote }`. Is that expected, or just part of all the bugs?
- 14:27:02 [TabAtkins]
- tantek: Ok. So that's a bug, and I dont' thinkw e should be designing based on a bug.
- 14:27:11 [Rossen_]
- q
- 14:27:14 [TabAtkins]
- florian: We're not saying it's a bug, we're saying it's desirable.
- 14:27:26 [TabAtkins]
- tantek: I'm talking justa bout the hyphen.
- 14:27:51 [TabAtkins]
- tantek: Because of that I think authors might be picking different techniques. So maybe we dont' have a compat problem at all then, because nobody's using it.
- 14:28:06 [TabAtkins]
- florian: If there is a real compat problem we'll find tou and revisit
- 14:28:17 [TabAtkins]
- faceless2: The big hyphen was actually a desired effect
- 14:28:25 [faceless2]
- http://www.typografi.org/dropcaps/assets/sitatstrek-anførselstegn_714.jpg
- 14:28:26 [florian]
- s/tou/out/
- 14:28:47 [TabAtkins]
- tantek: I'm convinced by the examples, we shoudl do this, but we should make it dependent on solving 2040
- 14:28:53 [TabAtkins]
- tantek: That would be my compromise proposal
- 14:28:59 [TabAtkins]
- tantek: I think this group can solve that.
- 14:29:24 [TabAtkins]
- fantasai: We need to do one thing at a time. These are two separate features that happen to work together.
- 14:29:39 [TabAtkins]
- fantasai: So let's just get opening quotes working the same between langs.
- 14:29:59 [leaverou]
- present+
- 14:30:15 [TabAtkins]
- tantek: They're both ::first-letter
- 14:30:28 [TabAtkins]
- [back and forth]
- 14:30:43 [Rossen_]
- q?
- 14:30:52 [astearns]
- +1 to resolving on this now
- 14:31:01 [fantasai]
- TabAtkins: Today, a single quote and no space, will be combined together.
- 14:31:13 [fantasai]
- TabAtkins: and the quote won't be sized "correctly" in that case either.
- 14:32:18 [TabAtkins]
- Rossen_: Okay, so it sounds like people are all okay with the proposal as it exists. Tantek, you had an objection based on no examples; we now have those. Do you still object?
- 14:32:44 [TabAtkins]
- tantek: I strongly prefer that we make this resolution dependent on 2040, but I won't object.
- 14:33:10 [TabAtkins]
- Rossen_: So any objections?
- 14:33:28 [TabAtkins]
- RESOLVED: Spaces separating punct from first letter dont' stop ::first-letter
- 14:34:18 [TabAtkins]
- Topic: Define em-top and em-bottom baselines
- 14:35:03 [fantasai]
- github: https://github.com/w3c/csswg-drafts/issues/5312
- 14:35:41 [TabAtkins]
- fantasai: The canvas API has a handful of metrics that it allows getters for
- 14:35:55 [TabAtkins]
- fantasai: They decided to defer to CSS Inline for their definitions
- 14:35:55 [fantasai]
- https://drafts.csswg.org/css-inline-3/#baseline-types
- 14:36:08 [TabAtkins]
- fantasai: We ahve a section in css-inline which defines a bunch of metrics, their opentype equivs
- 14:36:21 [TabAtkins]
- fantasai: They're taking a dependency on ascent and descent metrics for the purpose of font bounding box
- 14:36:33 [TabAtkins]
- fantasai: There's another metric in this canvas spec that we dont' have a definition for in the CSS spec
- 14:36:37 [fantasai]
- https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent
- 14:36:38 [TabAtkins]
- fantasai: So I propose we include that
- 14:36:47 [fantasai]
- fontBoundingBoxAscent/Descent
- 14:36:56 [TabAtkins]
- fantasai: Those map to our ascent/descent
- 14:37:09 [fantasai]
- emHeightAscent/Descent
- 14:37:09 [TabAtkins]
- fantasai: Then there's the em height ascent/desent
- 14:37:26 [fantasai]
- "highest top of the em squares in the inline box"
- 14:37:33 [TabAtkins]
- fantasai: Which don't have a definition in HTML; the deifnition is "to the highest top of the em squares in the inline box", and I'm not sure what that really means
- 14:37:45 [TabAtkins]
- fantasai: So the proposal is we define that metric, so the canvas api spec can hook into it
- 14:37:53 [TabAtkins]
- fantasai: Even if we don't end up using the metric in our own spec
- 14:38:00 [TabAtkins]
- fantasai: I talked to jfkthame about what he thinks the metric should be
- 14:38:03 [AmeliaBR]
- +1 for keeping all definitions in one place
- 14:38:24 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/5312#issue-654391546
- 14:38:29 [TabAtkins]
- fantasai: Idea is [in the issue]
- 14:38:29 [fantasai]
- Proposed definition from me and @jfkthame is:
- 14:38:29 [fantasai]
- if the ideographic-top + ideographic-bottom or ideographic-central baselines are defined by the font, emHeightAscent is 0.5em above the ideographic-central and emHeightDescent is 0.5em below. (This will normally make ideographic-top = emHeightAscent and ideographic-bottom = emHeightDescent, but if ideographic-top and ideographic-bottom are not 1em apart it will normalize the distance to 1em)
- 14:38:35 [fantasai]
- if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em
- 14:39:04 [TabAtkins]
- florian: So dont' use the actual size, but use the proportions?
- 14:39:18 [TabAtkins]
- faceless2: Lots of fonts dont' have these metrics add up to 1, so normalizing is important
- 14:39:19 [Rossen_]
- q?
- 14:39:29 [TabAtkins]
- AmeliaBR: So looks like midpoint of ascent/descent, then .5em both ways.
- 14:39:43 [TabAtkins]
- AmeliaBR: So it might be larger or smaller than ascent/descent if they weren't 1em apart originally?
- 14:40:00 [TabAtkins]
- fantasai: Yes. And bias toward the ideographic lines if they exist, they're more likely to be 1em apart
- 14:40:24 [TabAtkins]
- fantasai: They're also more likely to be in the center of where the ink falls, because they're centrally painted
- 14:40:46 [TabAtkins]
- fantasai: It works out well for CJK, and it works out fine for other writing system so long as these metrics are halfway reasonably defined.
- 14:41:06 [TabAtkins]
- Rossen_: Koji, any opinion on this?
- 14:41:29 [TabAtkins]
- koji: I generally support defining this.
- 14:41:37 [TabAtkins]
- koji: Been discussing with our canvas team aobut it
- 14:41:45 [TabAtkins]
- koji: Tehy're not really well-defined
- 14:42:00 [TabAtkins]
- koji: How to do it, I think we need more investigation/discussion.
- 14:42:22 [TabAtkins]
- koji: I'm asking in the issue some questions, and not sure what the correct way to define it is yet.
- 14:42:35 [TabAtkins]
- koji: So no concrete proposal yet, but think we need more investigation to make this move.
- 14:43:00 [TabAtkins]
- Rossen_: If the current approach is something we can resolve for now, and then refine as we go if we identify it's not the precise math we need...
- 14:43:13 [TabAtkins]
- Rossen_: I think there's alignment behind exposing these metrics and roughly defining them as suggested
- 14:43:23 [TabAtkins]
- Rossen_: Possibly with tweaks as we adjust
- 14:43:30 [TabAtkins]
- Rossen_: Are you against that?
- 14:43:47 [dlibby]
- dlibby has joined #css
- 14:44:01 [TabAtkins]
- koji: Not all my questions are answered yet. Like, font top metric is visual, but we probably need to support vertical flow.
- 14:44:10 [Rossen_]
- q?
- 14:44:19 [TabAtkins]
- Rossen_: I think elika just answered that in the issue about 30s ago.
- 14:44:47 [TabAtkins]
- AmeliaBR: What is the actual use-case for these metrics? ARe we expecting people to use them to draw boxes around their text?
- 14:44:56 [TabAtkins]
- AmeliaBR: Knowing that might inform what a useful definition is.
- 14:45:02 [TabAtkins]
- fantasai: I think they'll be used to position the text.
- 14:45:27 [TabAtkins]
- Rossen_: There are more and more solutions taking a dependency on canvas today for word-like or excel-liek apps
- 14:45:42 [TabAtkins]
- Rossen_: So more and more need doing higher-fidelity typography thru canvas
- 14:46:26 [TabAtkins]
- iank_: The exact use-cases are basically "everything youc an imagine someone wanting to do when laying out text". It's pretty broad.
- 14:46:51 [TabAtkins]
- AmeliaBR: Right, the question is what this adds to the existing terms, and is this proposed dfn solving what's needed?
- 14:47:05 [TabAtkins]
- AmeliaBR: I don't know, bc I don't know what the people who added this metric were thinking about.
- 14:47:10 [Rossen_]
- q?
- 14:47:37 [TabAtkins]
- fantasai: Well the current ascent/descent metrics aren't interoperable, so one thing this adds is a consistent answer for something ascent/descent-like.
- 14:47:52 [TabAtkins]
- fantasai: The font metrics used for these differ depending on browser/OS currently.
- 14:48:09 [jfkthame]
- q+
- 14:48:12 [TabAtkins]
- fantasai: So at least in cases where we have ideographic metrics, we can get a consistent cross-platform answer here.
- 14:48:27 [TabAtkins]
- koji: This wouldn't be interoperable, right? It relies on ascent/descent.
- 14:48:36 [TabAtkins]
- fantasai: Yeah, it's just closer to interop.
- 14:48:52 [TabAtkins]
- koji: Is Gecko okay to change to match this?
- 14:49:06 [Rossen_]
- ack jfkthame
- 14:49:06 [TabAtkins]
- jfkthame: I think we'd be fine with this, it's fairly close to what Gecko already does.
- 14:49:56 [TabAtkins]
- jfkthame: I think omst of the use-cases are better served by canvas's ascent/descent metrics, but those don't necessarily add up to 1em, and there's a legacy expectation that canvas text baseline has a top/bottom values which are specified to be the top and bottom of the em square.
- 14:50:11 [TabAtkins]
- jfkthame: I think there's a legit expectation for those to be 1em apart.
- 14:50:27 [TabAtkins]
- jfkthame: But it's not clear where the text falls in the em square if ascent+descent doesn't equal 1em.
- 14:50:44 [TabAtkins]
- jfkthame: So that's where this normalization comes in, giving a sensible definition to where the em square is
- 14:50:54 [TabAtkins]
- Rossen_: Do we know what current word formatters do in this case?
- 14:51:47 [TabAtkins]
- koji: There's one definition in opentype saying the ideographic em box with almost the same algo proposed here
- 14:51:57 [TabAtkins]
- koji: Except opentype says it only exists for cjk fonts, and it's udnefined otherwise
- 14:52:28 [TabAtkins]
- Rossen_: Is it a problem to define it for non-cjk?
- 14:52:39 [TabAtkins]
- koji: We tried to do some work there. When we used platform ascent/descent, it was quite bad
- 14:53:03 [TabAtkins]
- koji: We then used [s-type?] ascent/descent, we use that for underline position.
- 14:53:10 [TabAtkins]
- koji: we probably need more heuristic investigations
- 14:53:16 [fantasai]
- s/s-type?/sTypo/
- 14:53:22 [TabAtkins]
- koji: In canvas we dont' ahve font cascading, right?
- 14:53:50 [TabAtkins]
- koji: So if we define this in CSS, this is okay for the primary font, but going to the fallback algo would be bad. I'm concerned about that.
- 14:54:01 [TabAtkins]
- AmeliaBR: Canvas does do font fallback like CSS does.
- 14:54:33 [TabAtkins]
- Rossen_: So looking for progress.
- 14:55:07 [castastrophe]
- I have to drop for a meeting, back online around noon
- 14:55:18 [TabAtkins]
- fantasai: I'm happy to put a note in saying that these metrics are for canvas, and not meant for CSS.
- 14:55:38 [smfr]
- smfr has joined #css
- 14:55:40 [TabAtkins]
- fantasai: I think we should add the terms and dfns, and note we dont' plan to use them in CSS.
- 14:55:49 [TabAtkins]
- fantasai: And then if there are changes to the algo needed, we can address that in further issues.
- 14:56:37 [chris_]
- Rossen, for the CSS OM Color item, Lea and I would like to present our work before the discussion opens up. About 10 minutes should do it. [10:56] == Rossen is away: Away
- 14:56:41 [TabAtkins]
- RESOLVED: Accept the addition of the terms with the current proposed definitions.
- 14:57:07 [TabAtkins]
- <br dur=15m>, right?
- 14:58:53 [TabAtkins]
- Topic: end
- 15:02:02 [dlibby]
- dlibby has joined #css
- 15:10:51 [TabAtkins]
- Topic: initial-letter alignment with overflow:sunk
- 15:10:55 [Rossen_]
- github:https://github.com/w3c/csswg-drafts/issues/5329
- 15:11:14 [fantasai]
- s/overflow:sunk/over-sunk letter/
- 15:11:16 [smfr]
- s/with overflow:sunk/when over-sunk/
- 15:11:44 [TabAtkins]
- faceless2: When you have an initial-letter smaller than the space given, how do you align it within that gap?
- 15:11:54 [TabAtkins]
- faceless2: Existing spec aligns it to the bottom, elika proposes we change it to the top
- 15:12:04 [TabAtkins]
- fantasai: It fixes a use-case I had for indic scripts, and the OP's case which is Latin
- 15:12:32 [TabAtkins]
- fantasai: The proposal is to do this when the size is less than the sink value.
- 15:12:52 [TabAtkins]
- fantasai: If size is > sink, we want to align to the bottom metric, because we want the top of the letter to be above th eparagraph
- 15:13:04 [TabAtkins]
- fantasai: But when size < sink, we align to the top metric so we're pulling up
- 15:13:21 [TabAtkins]
- florian: And the initial dfn just only considered one case and we forgot the secon dhalf?
- 15:13:24 [TabAtkins]
- fantasai: pretty mcuh
- 15:13:29 [TabAtkins]
- Rossen_: Any other opinions?
- 15:14:06 [TabAtkins]
- RESOLVED: When 'over-sunk', an initial-letter is aligned with the top metrics instead.
- 15:14:21 [TabAtkins]
- Topic: end
- 15:14:54 [fantasai]
- ScribeNick: fantasai
- 15:14:56 [fantasai]
- Topic: Houdini
- 15:15:16 [fantasai]
- s/Houdini/Houdini Layout/
- 15:15:53 [Rossen_]
- Topic: String based inline layout API
- 15:16:08 [Rossen_]
- github:https://github.com/w3c/css-houdini-drafts/issues/990
- 15:16:38 [fantasai]
- Rossen_: More and more desire to be able to perform typographic text layout from Canvas
- 15:16:58 [Rossen_]
- https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md
- 15:17:01 [fantasai]
- Rossen_: There were some proposals put forward to essentially expose API in the platform that will allow developers to do that
- 15:17:04 [fantasai]
- Rossen_: e.g. ^
- 15:17:26 [fantasai]
- Rossen_: When I looked at it, and when we discussed it, my initial reaction was, hey, we have Houdini, and Houdini Custom Layout API was intended to handle exactly this
- 15:17:53 [fantasai]
- Rossen_: Overall idea, instead of performing layout that is based on a particular subsection of DOM that has text, inline markup, etc.
- 15:18:11 [fantasai]
- Rossen_: Instead expose an API that simply, for custom layout or maybe different API, takes as input a string
- 15:18:17 [fantasai]
- Rossen_: and does layout into the given space
- 15:18:24 [fantasai]
- Rossen_: If Houdini is not able to handle this, we are failing this on some higher level
- 15:18:46 [fantasai]
- Rossen_: So talked about it with iank_ and he expanded in the issue why this makes perfect sense and is good fit for the API
- 15:18:55 [fantasai]
- Rossen_: Since then see that some additional comments by Travis and ?
- 15:19:00 [fantasai]
- Rossen_: from Edge Team
- 15:19:15 [AmeliaBR]
- q+
- 15:19:16 [fantasai]
- Rossen_: and I wanted to essentially turn this into a question and ask, does it seem like a reasonable API?
- 15:19:37 [fremy]
- q+
- 15:19:43 [fantasai]
- Rossen_: Is this a good API to add, given intended functionality?
- 15:19:59 [fantasai]
- Rossen_: Will it serve the purpose motivating the other proposal?
- 15:20:32 [fantasai]
- AmeliaBR: Ian had a question in the issue about, once you've laid out, how do you query back the position of content?
- 15:20:43 [fantasai]
- AmeliaBR: If you're going down that road, might look at APIs from SVG
- 15:20:56 [fantasai]
- AmeliaBR: Can't promise they'll be all you want, but if can harmonize it's better
- 15:21:10 [fantasai]
- AmeliaBR: More specifically on the proposal, like the idea of being able to run layout separately from full CSS layout context
- 15:21:18 [fantasai]
- AmeliaBR: And re-using Houdini Layout APIs sounds good
- 15:21:27 [fantasai]
- AmeliaBR: I'm concerned about being based on simple text strings
- 15:21:37 [fantasai]
- AmeliaBR: As soon as you go beyond the simplest things, need annotations
- 15:21:56 [fantasai]
- AmeliaBR: Need info on languages, need markup for bidi, going to need nest it with italic phrase inside regular text phrase, etc.
- 15:21:58 [iank_]
- q+
- 15:22:07 [fantasai]
- AmeliaBR: So it might be better to keep thinking of styling a DOM fragment
- 15:22:17 [fantasai]
- AmeliaBR: but DOM fragment doesn't necessarily need to be attached to the document
- 15:22:26 [fantasai]
- AmeliaBR: Because you will need some hierarchy of content
- 15:22:40 [fantasai]
- Rossen_: what you're asking for already exists, just extending to handle string only
- 15:22:40 [Rossen_]
- ack AmeliaBR
- 15:23:04 [Rossen_]
- ack fremy
- 15:23:11 [fantasai]
- fremy: One issue of doing with strings is, if you have ? such as text selection
- 15:23:17 [fantasai]
- fremy: Doesn't work if you don't have something in the DOM to select
- 15:23:22 [fantasai]
- fremy: Don't know the use case for the text
- 15:23:32 [fantasai]
- fremy: But selection is something users expect, and problematic if we can't handle selection
- 15:23:41 [fantasai]
- fremy: But at the same time, think about what Amelia said
- 15:23:47 [fantasai]
- fremy: if you have something in the DOM to represent the string
- 15:23:54 [fantasai]
- fremy: [something about spans]
- 15:24:00 [fantasai]
- fremy: If in the DOM, you can copy and paste, etc.
- 15:24:11 [fantasai]
- fremy: A lot of times you don't want to have everything possible in CSS
- 15:24:17 [fantasai]
- fremy: Sounds useful in many cases
- 15:24:31 [sushanth]
- sushanth has joined #css
- 15:24:33 [Rossen_]
- ack iank_
- 15:24:49 [fantasai]
- iank_: The linked formatted text explainer is much more well thought out
- 15:24:52 [fantasai]
- iank_: and seems pretty good
- 15:25:01 [fantasai]
- iank_: Amelia brought up point wrt doing on document fragments
- 15:25:09 [fantasai]
- iank_: Issue there is, this API wanted to work inside of workers
- 15:25:13 [fantasai]
- iank_: because have the Canvas API
- 15:25:23 [fantasai]
- iank_: I don't think needs that much of hierarchy
- 15:25:34 [fantasai]
- iank_: styling particular runs is roughly equivalent to structured hierarchy
- 15:25:35 [sushanth]
- q+
- 15:25:43 [fantasai]
- iank_: One thing to think about there is bidi reordering, though
- 15:25:55 [fantasai]
- iank_: To harmonize APIs
- 15:26:04 [fantasai]
- iank_: call out some core ? or mixins that can be shared between the APIs
- 15:26:09 [fantasai]
- iank_: Once you have a line of text, what info can you query?
- 15:26:22 [Rossen_]
- q
- 15:26:25 [fantasai]
- iank_: no reason they should be different
- 15:27:16 [fantasai]
- ??: Motivation was apps, like photoshop / excel
- 15:27:30 [fantasai]
- sushanth: API was trying to give them ability to do multiline text
- 15:27:31 [astearns]
- s/??/sushanth/
- 15:27:42 [fantasai]
- sushanth: Houdini, they have control over canvas context they'd want text to be rendered?
- 15:27:47 [fantasai]
- sushanth: Paint Worklet, Houdini controls context
- 15:27:57 [fantasai]
- sushanth: but these cases rendering other things, just want a few lines of text
- 15:28:12 [fantasai]
- sushanth: In terms of measuring API, we went towards existing Canvas Text Metrics API
- 15:28:17 [fantasai]
- sushanth: exposes same set of things
- 15:28:31 [fantasai]
- sushanth: Not the same as SVG, but has precedence on having some APIs
- 15:28:35 [fantasai]
- sushanth: Chromium has advances as well
- 15:28:43 [jfkthame]
- q+
- 15:28:55 [fantasai]
- sushanth: I think last question, selection / background / borders missing from this API
- 15:29:02 [fantasai]
- sushanth: with metrics can implement this
- 15:29:06 [fantasai]
- sushanth: in JS
- 15:29:12 [Rossen_]
- q?
- 15:29:13 [fantasai]
- sushanth: Just wanted basic multiline text
- 15:29:46 [fantasai]
- jfkthame: I wanted to comment that what I've seen of the text metrics API for canvas there, particularly advances from Chromium, that really does not address the needs of international text well
- 15:30:00 [fantasai]
- jfkthame: Does not handle that one character can map to arbitrary number of glyphs and vice versa
- 15:30:36 [fantasai]
- jfkthame: the mapping between glyphs and characters can be quite complex, and it doesn't handle that
- 15:30:54 [Rossen__]
- Rossen__ has joined #css
- 15:30:57 [Rossen__]
- q?
- 15:31:21 [fantasai]
- AmeliaBR: Hadn't clicked through to explainer previously, and only saw the examples in the issue. Explainer looks like a much more complex model, allows annotations
- 15:31:33 [fantasai]
- AmeliaBR: if that's extended to handle i18n issues, that's a good start [wrt bidi and lang?]
- 15:31:41 [fantasai]
- AmeliaBR: Might be useful to export a DOM fragment to this format
- 15:31:49 [fantasai]
- AmeliaBR: so if you have CSS-styled markup in Canvas Shadow DOM or in your SVG
- 15:32:01 [fantasai]
- AmeliaBR: and want to run through this API to get layout, would be a great feature
- 15:32:11 [Rossen__]
- q
- 15:32:21 [sushanth]
- q+
- 15:32:53 [fantasai]
- Rossen__: SVG has had this capability request for the longest time
- 15:33:04 [fantasai]
- Rossen__: some such as inkscape that support, no renderers
- 15:33:09 [fantasai]
- Rossen__: Want it in Canvas
- 15:33:20 [fantasai]
- Rossen__: If for every one of these [sound breaks]
- 15:34:35 [fantasai]
- AmeliaBR: He was talking about how SVG has long wanted formatted multiline text, haven't been able to get implemented in browsers, so will be very jealous if Canvas gets it before we do
- 15:34:41 [astearns]
- ack sushanth
- 15:34:53 [fantasai]
- sushanth: Point about advances in text metrics, it's incomplete
- 15:34:58 [fantasai]
- sushanth: flag to get it to wokr
- 15:35:04 [fantasai]
- sushanth: Does handle multiple glyphs per characters
- 15:35:15 [fantasai]
- sushanth: We augmented with hierarchy to allow advances within ?
- 15:35:48 [Guest60]
- Guest60 has joined #css
- 15:35:49 [fantasai]
- sushanth: It addresses multiple chars into single glyph is that it gives you the same advance value
- 15:35:54 [Guest60]
- present+
- 15:35:59 [fantasai]
- sushanth: They'll all have the same advance value
- 15:36:06 [jensimmons]
- present+
- 15:36:09 [fantasai]
- sushanth: advance = position from the start
- 15:36:11 [Rossen___]
- Rossen___ has joined #css
- 15:36:24 [Rossen___]
- q?
- 15:36:24 [fantasai]
- jfkthame: That won't be any different than a zero-width character right?
- 15:36:26 [AmeliaBR]
- This is similar to how the SVG API works: multiple characters will match to the same glyph box
- 15:36:28 [fantasai]
- sushanth: true
- 15:36:35 [fantasai]
- sushanth: Some other issues also?
- 15:36:50 [fantasai]
- Rossen__: Main point I wanted to make before network drop...
- 15:37:01 [fantasai]
- Rossen__: If we're not looking for ways to harmonize Houdini APIs with rest of platform
- 15:37:15 [fantasai]
- Rossen__: failing main use case of exposing ? to other things like Canvas and SVG
- 15:37:31 [AmeliaBR]
- s/?/text layout/
- 15:37:31 [fantasai]
- Rossen__: As we all know, text seems very benign and easy, when you thinking only about a few ascii glyphs
- 15:37:39 [fantasai]
- Rossen__: breaks based on simple logic
- 15:37:42 [fantasai]
- Rossen__: Things get increasingly complex
- 15:37:51 [fantasai]
- Rossen__: to the point where you're mostly ending up re-implementing layout for CSS
- 15:37:57 [fantasai]
- Rossen__: which now intended to be exposed as Houdini APIs
- 15:38:01 [iank_]
- q+
- 15:38:15 [Rossen___]
- ack fantasai
- 15:38:16 [Zakim]
- fantasai, you wanted to ask us to get Myles's opinion before signing off on anything like this
- 15:38:29 [fremy]
- q+
- 15:38:41 [fantasai]
- fantasai: Just wanted to say, I echo concerns about getting i18n right.
- 15:38:49 [iank_]
- q-
- 15:38:49 [iank_]
- q+
- 15:38:54 [fantasai]
- fantasai: Also want to say, I would be very uncomfortable resolving to add a new major text API without Myles signing off
- 15:39:05 [fantasai]
- fremy: Was thinking about use case, the idea is to run this in workers
- 15:39:10 [fantasai]
- fremy: because can't ? directly
- 15:39:21 [fantasai]
- fremy: So that's why don't want to take something from the DOM and draw it
- 15:39:23 [AmeliaBR]
- s/?/access the DOM/
- 15:39:27 [fantasai]
- fremy: ...
- 15:39:34 [fantasai]
- fremy: HTML content and canvas can automatically update
- 15:39:37 [fantasai]
- fremy: what gets drawn on it
- 15:39:40 [fantasai]
- fremy: that could get the other things to work
- 15:39:43 [fantasai]
- fremy: for ppl using the API
- 15:39:54 [fantasai]
- fremy: Draw on the canvas, put this in the DOM, and gets updated
- 15:40:01 [fantasai]
- fremy: enables selection, a11y, etc. everything to wokr
- 15:40:07 [astearns]
- s/.../describes an export from this API to a DOM fragment/
- 15:40:07 [fantasai]
- fremy: That's an idea, another way of looking at it
- 15:40:32 [fantasai]
- iank_: Based on the canvas text explainer here, definitely possible to harmonize SVG and layout API with htis
- 15:40:43 [Rossen___]
- ack iank_
- 15:40:47 [Rossen___]
- ack fremy
- 15:40:56 [fantasai]
- iank_: might me helpful to get on videochat and talk about details in detail at some point
- 15:41:17 [fantasai]
- Rossen___: As stated in the beginning, wanted to get opinion on whether good approach in general
- 15:41:33 [fantasai]
- Rossen___: For the proposed solution put together by ian on that issue, wanted to get feedback from sushanth and others
- 15:41:38 [fantasai]
- Rossen___: whether approach worth pursuing
- 15:41:48 [fantasai]
- Rossen___: Closing remarks are let's get together and work on this
- 15:41:50 [sushanth]
- thank you Ian, happy to follow up. :D
- 15:42:05 [florian]
- q+
- 15:42:15 [Rossen___]
- ack fantasai
- 15:42:44 [fantasai]
- fantasai: bidi, lang-tagging or markup for change in formatting, selection, a11y, character to glyph mapping ...
- 15:43:14 [fantasai]
- fantasai: justification? would it be possible?
- 15:43:26 [Rossen___]
- q
- 15:43:29 [fantasai]
- sushanth: ? has some some text justification, has just left/right/center
- 15:43:38 [AmeliaBR]
- s/?/canvas/
- 15:43:54 [fantasai]
- fantasai: just wanted to make sure these points don't get lost
- 15:44:06 [fantasai]
- florian: Want to echo a bit of the warning Myles gave us last time on this topic
- 15:44:27 [fantasai]
- florian: needs to be foolproof, so that if user of API doesn't think about them, they still work
- 15:44:28 [hober]
- present+
- 15:44:43 [fantasai]
- florian: otherwise we make large parts of internet inaccessible or unusable to a lot of the world population
- 15:44:50 [fantasai]
- florian: ...
- 15:45:07 [fantasai]
- florian: getting the right balance is hard, but we have to do it
- 15:45:17 [fantasai]
- iank_: This API is a substantial leap forward from current Canvas APIs
- 15:46:07 [fantasai]
- [Note to scribe: insert link to Myle's comments here]
- 15:46:10 [fantasai]
- Topic: ????
- 15:46:24 [fantasai]
- s/????/Print Behavior and Test Requirements/
- 15:46:25 [Rossen___]
- github: https://github.com/w3c/css-houdini-drafts/issues/978
- 15:46:37 [fantasai]
- github: https://github.com/w3c/css-houdini-drafts/issues/978
- 15:46:49 [fantasai]
- TabAtkins: gsnedders brought up really good point that historically we don't run JS for print
- 15:46:57 [fantasai]
- TabAtkins: but how should that interact with layout API and paint API?
- 15:46:59 [AmeliaBR]
- q+
- 15:47:01 [fantasai]
- TabAtkins: print style can change sizes of things
- 15:47:06 [fantasai]
- TabAtkins: have to run custom paint and custom layout
- 15:47:10 [astearns]
- ack florian
- 15:47:10 [fantasai]
- TabAtkins: are we doing something with that?
- 15:47:11 [florian]
- q-
- 15:47:13 [fantasai]
- TabAtkins: if we're not, do we plan to?
- 15:47:24 [fantasai]
- TabAtkins: we should document this either way, to make sure it's clear how printing and houdini APIs work together
- 15:47:41 [fantasai]
- Rossen___: When are we evaluating print?
- 15:47:44 [fantasai]
- TabAtkins: when you print a web page
- 15:47:53 [fantasai]
- TabAtkins: switch over to print styles and fragment for printing
- 15:47:55 [sushanth]
- +q
- 15:47:56 [fantasai]
- TabAtkins: but aren't running JS
- 15:48:07 [fantasai]
- iank_: These particular things, we should be running any layout API JS
- 15:48:15 [Rossen___]
- ack AmeliaBR
- 15:48:17 [fantasai]
- AmeliaBR: Definitely as part of a style recalc
- 15:48:38 [fantasai]
- AmeliaBR: Dunno if works correctly, but that should be the expectation
- 15:48:48 [fantasai]
- sushanth: for printing, I work on canvas so I know how it works for Chavas
- 15:49:05 [fantasai]
- sushanth: There's a "about to print" event, and you do stuff, and that gets replayed
- 15:49:07 [plinss]
- present+
- 15:49:09 [Rossen___]
- ack sushanth
- 15:49:13 [fantasai]
- sushanth: when you print, those recordings are played back
- 15:49:27 [AmeliaBR]
- s/"about to print"/onBeforePrint/
- 15:49:42 [emilio]
- q+
- 15:49:45 [fantasai]
- Rossen___: So takeaway is yes, should be running all of the JS hooks and execute scripts that will do custom paint / layout etc. in all of these cases
- 15:50:01 [fantasai]
- emilio: One question, for print approach, what happens when user changes stuff?
- 15:50:05 [fantasai]
- emilio: does print run multiple times?
- 15:50:08 [fantasai]
- emilio: in Gecko that's not the case
- 15:50:20 [fantasai]
- emilio: You issue print command, right?
- 15:50:31 [fantasai]
- emilio: there's a print preview that let's you adjust page size / margins / etc.
- 15:50:37 [fantasai]
- emilio: we don't dispatch JS events every time that happens
- 15:50:44 [fantasai]
- emilio: in Gecko, we do a complete separate document just for printing
- 15:50:53 [fantasai]
- emilio: we fire beforeprint event before doing this
- 15:51:05 [fantasai]
- emilio: when you change layout, we don't do it over again
- 15:51:10 [fantasai]
- AmeliaBR: It would be after regular JS event
- 15:51:18 [Rossen___]
- q?
- 15:51:28 [Rossen___]
- ack emilio
- 15:51:30 [fantasai]
- AmeliaBR: Houdini isn't part of event loop, it's triggered by style recalc directly
- 15:51:37 [gsnedders]
- q+
- 15:51:59 [fantasai]
- gsnedders: Want to point of last bit of my issue, which was about how we plan on testing the layout API
- 15:52:11 [fantasai]
- gsnedders: whether we expect there to be different testing for paged media vs scrolling media
- 15:52:31 [fantasai]
- iank_: There's currently work that is at least planned but maybe not in progress to support better printing in WPT?
- 15:52:41 [fantasai]
- gsnedders: We have paged reftests, but only currently implemented in Gecko
- 15:52:49 [fantasai]
- iank_: so on Chromium project to add support reftests of that form
- 15:52:57 [Rossen___]
- ack gsnedders
- 15:53:11 [fantasai]
- iank_: Testing strategy should be no different from other printing tests
- 15:53:28 [fantasai]
- gsnedders: ...
- 15:53:40 [fantasai]
- gsnedders: JS tests for worklets specifically, do we want them to differ from paged media?
- 15:53:52 [fantasai]
- iank_: Changing behavior between paged vs non-paged?
- 15:53:58 [fantasai]
- iank_: Definitely will be a difference
- 15:54:00 [fantasai]
- iank_: sizes change
- 15:54:06 [fantasai]
- iank_: definitley change in layout maybe paint
- 15:54:12 [fantasai]
- iank_: One that's missing is fragmentation support
- 15:54:19 [fantasai]
- iank_: that's one thing that will definitely be triggered by paged media context
- 15:54:32 [fantasai]
- emilio: We ported a lot of the Gecko paged reftests to be in WPT
- 15:54:47 [fantasai]
- iank_: We're undergoing adding more and more capabilities to our new fragmentation engine
- 15:54:54 [fantasai]
- iank_: adding a lot of those tests as ? tests
- 15:55:02 [fantasai]
- iank_: first half of next year will be focusing solely on printing, effectively
- 15:55:06 [fantasai]
- iank_: will add a lot more reftests
- 15:55:11 [AmeliaBR]
- s/?/ref/
- 15:55:23 [fantasai]
- iank_: will work on supporting print reftests in chromium at the same time
- 15:55:33 [fantasai]
- gsnedders: I think that answers my questions
- 15:55:56 [fantasai]
- Rossen___: smfr pointed out that we should probably specify when Houdini JS is specified in all of these cases for printing
- 15:56:27 [fantasai]
- AmeliaBR: Are worklets allowed to do anything asyc?
- 15:56:31 [fantasai]
- TabAtkins: nope. Very intentionally
- 15:56:36 [TabAtkins]
- ScribeNick: TabAtkins
- 15:56:47 [TabAtkins]
- fantasai: Layout API hasnt' been published since 2018, and I'm guessing edits ahve happened since then
- 15:56:57 [fantasai]
- fantasai: Just want to point out that Layout API haven't been published since 2018
- 15:56:58 [TabAtkins]
- Rossen___: Yes Ian and I botha ttempted to publish this and both failed
- 15:57:17 [TabAtkins]
- fantasai: If you have mechanics issues, can youg et a staff contact to help?
- 15:57:18 [TabAtkins]
- Rossen___: Yes.
- 15:57:19 [fantasai]
- fantasai: If you're getting stuck, ask the staff contacts for help
- 15:57:26 [fantasai]
- scribeNick: TabAtkins
- 15:58:14 [fantasai]
- TabAtkins: let's record a resolution
- 15:58:28 [fantasai]
- TabAtkins: Any houdini JS that needs to rerun for style / layout recalc needs to run
- 15:58:42 [fantasai]
- RESOLVED: Any Houdini JS that needs to run for style / layout calc needs to run for print
- 15:58:45 [fantasai]
- Topic: Break
- 15:58:58 [fantasai]
- <br end="??:25">
- 16:21:03 [myles]
- myles has joined #css
- 16:27:35 [GameMaker]
- present+
- 16:27:42 [leaverou]
- CSS Color 4 sample code: https://drafts.csswg.org/css-color-4/conversions.js and https://drafts.csswg.org/css-color-4/utilities.js
- 16:28:07 [fantasai]
- Topic: Color Conversion and Contrast Ratio
- 16:28:18 [astearns]
- github: https://github.com/w3c/css-houdini-drafts/issues/989
- 16:28:21 [leaverou]
- CSS Color 4 sample code: https://drafts.csswg.org/css-color-4/conversions.js and https://drafts.csswg.org/css-color-4/utilities.js
- 16:29:22 [tantek]
- tantek has joined #css
- 16:29:45 [emilio]
- present+
- 16:30:21 [fantasai]
- Rossen___: This issue motivated by TAG review about addition of lch and lab color spaces
- 16:30:40 [fantasai]
- Rossen___: One concern being discussed being discussed with TAG was that we were getting more variety of color across platform
- 16:30:52 [fantasai]
- Rossen___: but capabilities of simple things like contrasting two colors is very difficult
- 16:31:11 [fantasai]
- Rossen___: One of the ideas was, hey, if we have a strongly defined type of color that we can use across platform
- 16:31:26 [fantasai]
- Rossen___: then we could look at exposing variety of functions either on or around object
- 16:31:35 [fantasai]
- Rossen___: and achieve objectives like a11y and other things
- 16:31:45 [fantasai]
- Rossen___: Seemed like TypedOM is good place to start
- 16:31:52 [fantasai]
- Rossen___: Color is a type we need to define strongly
- 16:31:59 [fantasai]
- Rossen___: Luckily Lea and Chris jumped in, had been thinking about it
- 16:32:09 [fantasai]
- ?: ??
- 16:32:30 [fantasai]
- chris_: in color 4 there was an appendix written in JS by which I mean Pascal
- 16:32:43 [fantasai]
- chris_: It's simple, does work, set of simple functions
- 16:32:54 [fantasai]
- chris_: Also have utilities.js
- 16:32:58 [fantasai]
- chris_: includes a contrast function
- 16:33:06 [fantasai]
- chris_: Here's an sRGB_to_LCH
- 16:33:16 [fantasai]
- chris_: it does it all in the right order
- 16:33:19 [fantasai]
- chris_: It was useful for examples
- 16:33:22 [fantasai]
- chris_: and useful for color 5
- 16:33:28 [fantasai]
- chris_: but this is not a proposal for a color model
- 16:33:31 [fantasai]
- chris_: not object oriented
- 16:33:37 [fantasai]
- chris_: it's just something that wroks
- 16:33:46 [fantasai]
- chris_: Here's color.js
- 16:33:56 [fantasai]
- chris_: Until this morning was a private repo, now public
- 16:34:01 [leaverou]
- https://colorjs.io/
- 16:34:06 [fantasai]
- chris_: also not a proposal, but it's object oriented
- 16:34:19 [fantasai]
- chris_: This is a JS API, you can use it in the browser or on the server
- 16:34:32 [fantasai]
- chris_: These examples are all live, you can edit directly in the web page if you want
- 16:34:51 [fantasai]
- chris_: variety of color models, includes all in color 4 (except device-cmyk()) as well as a few more
- 16:34:59 [fantasai]
- leaverou demos
- 16:35:09 [fantasai]
- chris_: Notice these are in different color spaces
- 16:35:22 [fantasai]
- chris_: Internally it goes into CIEXYZ, and then ??, and then gets you a contrast
- 16:35:33 [fantasai]
- chris_: You just say you want contrast between two colors, and it just works out for you
- 16:35:38 [fantasai]
- chris_: You can change lightness or chroma or whatever
- 16:35:42 [fantasai]
- chris_: similar to things we do in Color 5
- 16:35:52 [fantasai]
- chris_: Convert between color spaces
- 16:35:56 [fantasai]
- chris_: interpolate between colors
- 16:36:11 [fantasai]
- chris_: either discreet steps, or gradients, or that sort of thing
- 16:36:25 [fantasai]
- chris_ reviews documentation
- 16:36:37 [fantasai]
- chris_: Color object. Can give a CSS string or use initializer with coordinates
- 16:36:46 [fantasai]
- leaverou: color space ID plus coordinates plus optional alpha
- 16:36:57 [fantasai]
- leaverou: or another color
- 16:37:02 [fantasai]
- s/color/Color/
- 16:37:17 [fantasai]
- chris_: This is similar to color-5, adjusting named coordinates
- 16:37:36 [fantasai]
- chris_: We've actually supported more than Color 4 supports
- 16:37:50 [fantasai]
- chris_: might be interesting to see if any would be useful as future additions
- 16:38:01 [fantasai]
- chris_ notes there's bugs, especially in the documentation, since this is pre-release
- 16:38:12 [fantasai]
- chris_: You can change color coordinates. Don't even have to change coordinates of the color space you're in
- 16:38:17 [fantasai]
- chris_: That's fairly useful
- 16:38:22 [fantasai]
- chris_: We also do gamut-mapping
- 16:38:28 [fantasai]
- chris_: because easy to get colors that are out of gamut
- 16:38:35 [fantasai]
- chris_: we've worked on that quite a bit, have an algo that works rather well
- 16:38:46 [fantasai]
- chris_: Do a binary search to find closest color via chroma reduction
- 16:38:49 [fantasai]
- chris_: and do speculative ???
- 16:38:59 [fantasai]
- chris_: 1st one we reduce chroma until it's inside the range
- 16:39:08 [fantasai]
- chris_: 2nd one, at each stage, we see if we clipped here, would we be close?
- 16:39:11 [fantasai]
- chris_: and that works much better
- 16:39:12 [astearns]
- s/???/clipping/
- 16:39:17 [fantasai]
- chris_: thinking to spec that in color-4 spec
- 16:39:24 [fantasai]
- chris_: Interpolation
- 16:39:33 [fantasai]
- chris_: range function allows that and getting intermediate stops
- 16:39:34 [Rossen___]
- q
- 16:39:46 [Rossen___]
- q+
- 16:39:51 [fantasai]
- leaverou: range function actually returns a function
- 16:40:05 [fantasai]
- leaverou: we can specify which space to do interpolation in
- 16:40:13 [fantasai]
- leaverou: you can see here examples of what each interpolation space produces
- 16:40:28 [fantasai]
- leaverou: we also implemented longer/shorter/increasing/decreasing args for the hue we were discussing
- 16:40:33 [fantasai]
- leaverou: although didn't implement dbaron's ? yet
- 16:40:48 [fantasai]
- chris_: Lets us implement and check and see if it works. Very helpful in writing spec
- 16:41:02 [fantasai]
- chris_: Also discussing keeping ? constant
- 16:41:10 [fantasai]
- leaverou: but we do keep Nan for chroma
- 16:41:28 [fantasai]
- s/keeping ?/using Nan for keeping coord/
- 16:41:35 [fantasai]
- chris_: It's on GH and there's a link, and also a bunch of tests
- 16:41:40 [fantasai]
- chris_: any questions at this stage?
- 16:41:44 [astearns]
- ack Rossen___
- 16:41:57 [fantasai]
- Rossen___: First of all, this is awesome, thanks for sharing
- 16:42:04 [fantasai]
- Rossen___: Looking forward to playing with the project
- 16:42:10 [fantasai]
- Rossen___: that's exactly what I was hoping to see
- 16:42:15 [fantasai]
- Rossen___: and you made this fantastic
- 16:42:28 [fantasai]
- Rossen___: Wrt functions like color-mix() etc.
- 16:42:30 [fremy]
- big +1 this is super great!
- 16:42:43 [fantasai]
- Rossen___: let's say we start going towards adopting such a type in TypedOM, where does that leave us?
- 16:42:51 [AmeliaBR]
- q+
- 16:43:07 [fantasai]
- chris_: You'll have 2 ways to do it: declarative in color-5, and imperative way like this
- 16:43:14 [fantasai]
- chris_: imperative can have more functionality
- 16:43:25 [fantasai]
- chris_: I don't think it's a problem that we have both declarative and imperative
- 16:43:27 [fantasai]
- leaverou: ?
- 16:43:32 [fantasai]
- leaverou: haven't done adjusters yet
- 16:43:40 [fantasai]
- leaverou: accepts a color space as well, but not adjusters
- 16:43:53 [fantasai]
- chris_: As general goal, would like to implement all of color-5 so we can test, and do example, see how that works
- 16:44:05 [fantasai]
- chris_: Another thing ppl might have noticed, there's a few more color spaces here not in color 4
- 16:44:10 [fantasai]
- chris_: support high dynamic range coors
- 16:44:16 [fantasai]
- chris_: there's a secret spec called css-color-hdr
- 16:44:22 [fantasai]
- chris_: there was an issue around high dynamic range
- 16:44:30 [fantasai]
- chris_: I said we won't do it, because too unstable
- 16:44:41 [fantasai]
- chris_: but I did spec an extension to color-4
- 16:44:48 [fantasai]
- chris_: and wanted to see that it works and coded it up
- 16:44:56 [fantasai]
- chris_: I presented to ??? and got good feedback, currently incorporating that
- 16:45:00 [fantasai]
- chris_: will present to the WG later
- 16:45:04 [astearns]
- s/???/ICC/
- 16:45:08 [fantasai]
- chris_: in the meantime, i'm incubating it in code to see whether it's feasible
- 16:45:19 [astearns]
- ack AmeliaBR
- 16:45:24 [florian]
- https://drafts.csswg.org/css-color-hdr/
- 16:45:33 [leaverou]
- https://drafts.csswg.org/css-color-hdr/
- 16:45:40 [fantasai]
- AmeliaBR: Great library, very useful. Some similar things, but this is a nice APi with good features
- 16:45:47 [fantasai]
- AmeliaBR: Wrt what we should adopt into the actual Web platform
- 16:45:59 [fantasai]
- AmeliaBR: I do like the idea of having general color utilities object
- 16:46:11 [fantasai]
- AmeliaBR: That you can call without having to getComputeStyle
- 16:46:17 [fantasai]
- AmeliaBR: coordnate with TypedOM also good
- 16:46:28 [fantasai]
- AmeliaBR: so you can construct CSS color type or get it from a style rule or a computed style
- 16:46:31 [fantasai]
- AmeliaBR: that would be great design
- 16:46:42 [fantasai]
- AmeliaBR: Probably don't want quite as many features as we have in this library
- 16:46:53 [fantasai]
- AmeliaBR: Might want to integrate a bit more e.g. generated gradients
- 16:47:12 [fantasai]
- AmeliaBR: and easing function would be its own object, to use more generally than just color
- 16:47:18 [fantasai]
- AmeliaBR: Interpolator for data vis
- 16:47:27 [fantasai]
- AmeliaBR: would be a great feature, use native interpolation that CSS already knows how to do
- 16:47:40 [fantasai]
- AmeliaBR: with additional smarts like interpolating in different color spaces
- 16:47:43 [fantasai]
- AmeliaBR: also useful to have
- 16:48:12 [fantasai]
- astearns: Anything else besides showing new cool code?
- 16:48:17 [fantasai]
- Rossen___: How do you see this moving forward?
- 16:48:26 [fantasai]
- chris_: Requirements, one of them for web platform API
- 16:48:37 [fantasai]
- chris_: what features do we want, what would be nice, what would be layered on top
- 16:48:42 [fantasai]
- chris_: Rossen asked about contrast, that's important
- 16:48:51 [fantasai]
- chris_: Converting between color spaces without having to understand how it does
- 16:49:00 [fantasai]
- chris_: not knowing about white points, not having to figure that out, that's important
- 16:49:10 [fantasai]
- leaverou: There should also be way to access color before / after gamut mapping because ???
- 16:49:25 [fantasai]
- AmeliaBR: Especially important for finding contrast ratio
- 16:49:41 [fantasai]
- AmeliaBR: if colors are theoretically good contrast, but not on user's screen, need to reflect that
- 16:50:04 [fantasai]
- florian: So is the plan to subset your project into TypedOM? and then build your project on top of that result?
- 16:50:08 [fantasai]
- chris_: would be reasonable
- 16:50:14 [fantasai]
- astearns: If you can't build on top of the subset, then we chose the wrong subset
- 16:50:19 [fantasai]
- Rossen___: That was part of my hope
- 16:50:39 [fantasai]
- Rossen___: exactly why I was provoking this type of discussion and exposure in typed OM space
- 16:50:48 [fantasai]
- Rossen___: Anything else left on color that you didn't cover?
- 16:50:49 [AmeliaBR]
- s/ ???/ that affects the results/
- 16:50:51 [fantasai]
- leaverou: ICC profiles
- 16:51:08 [fantasai]
- leaverou: in theory, TypedOM should cover that as well
- 16:51:16 [fantasai]
- leaverou: but wouldn't that make it asynchronous?
- 16:51:42 [bkardell_]
- bkardell_ has joined #css
- 16:51:52 [fantasai]
- TabAtkins: We already have a few things that need external resources, don't have a great way to handle that
- 16:52:00 [fantasai]
- TabAtkins: but nothing else needs to be infected, just wait for them via Promise
- 16:52:25 [fantasai]
- chris_: Mentioned that we have a lot of stuff. Because we wanted to test things against each other
- 16:52:36 [fantasai]
- chris_: e.g. deltaE, implemented 5 different variants
- 16:52:45 [fantasai]
- chris_: wanted to compare visual result, perf
- 16:52:51 [fantasai]
- faceless2: ...
- 16:53:05 [fantasai]
- florian: Feels like what we need is the various objects and methods to let you get from one to the other, and create mixes
- 16:53:13 [bkardell_]
- present+
- 16:53:17 [fantasai]
- florian: don't necessarily need all the operations to get from one color to another color
- 16:53:46 [fantasai]
- florian: maybe need ? and ?, but methods to get between them, but TypedOM doesn't need
- 16:53:56 [fantasai]
- chris_: Do need an intermediate way to go between colors
- 16:54:03 [fantasai]
- chris_: you use colors together, not in isolation
- 16:54:18 [Rossen___]
- q?
- 16:54:23 [fantasai]
- AmeliaBR: Base case would be converting single color into other color spaces
- 16:54:36 [fantasai]
- AmeliaBR: so you can convert two colors into the same color space in order to compare or calculate
- 16:54:49 [fantasai]
- AmeliaBR: Devs can implement the formulas that use whatever paramterization of colors that they need
- 16:54:52 [fantasai]
- chris_: yep
- 16:54:56 [fantasai]
- Rossen___: I agree
- 16:55:08 [fantasai]
- Rossen___: that was initial motivation here, exposing the type that will allow you to at least hoist the color space and its values
- 16:55:17 [fantasai]
- Rossen___: having this type, you can start adding libraries around it that do a bunch of math
- 16:55:33 [fantasai]
- Rossen___: as we go forward, can identify which math goes into native platform and which stays as library
- 16:55:38 [fantasai]
- Rossen___: but not having basic type is a blocker
- 16:55:51 [fantasai]
- Rossen___: My hope and ask for you, is to start defining what this type should look like
- 16:55:58 [fantasai]
- Rossen___: what is minimum set of parameters and stuff
- 16:56:16 [fantasai]
- Rossen___: I see Tab and fremy still editing TypedOM, so work with them to move it forward
- 16:56:50 [astearns]
- ack fantasai
- 16:56:57 [fantasai]
- fantasai: I want to note that Typed OM has also not been published since 2018.
- 16:57:57 [TabAtkins]
- Topic: Concern about attributeStyleMap updating the style attribute
- 16:58:01 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/997
- 16:58:21 [fantasai]
- TabAtkins: I'm not sure if this is an actual concern to worry about
- 16:58:24 [fantasai]
- TabAtkins: wanted impl advice
- 16:58:32 [fantasai]
- TabAtkins: when doing high-frequency updates, like during TypedOM
- 16:58:41 [fantasai]
- TabAtkins: use single transform object, setting over and over again
- 16:58:49 [fantasai]
- TabAtkins: but are seeing the style attr get updated in real time as well
- 16:58:58 [fantasai]
- TabAtkins: so reserialization happening constantly as well
- 16:59:03 [fantasai]
- TabAtkins: we saw as a perf concern
- 16:59:08 [fantasai]
- TabAtkins: So is this actually causing trouble?
- 16:59:19 [fantasai]
- TabAtkins: person seems to believe causing perf issues, I'm not sure myself
- 16:59:35 [fantasai]
- TabAtkins: but if we are eagerly reserializing to style attr, not great. Negates a major advantage of TypedOM
- 16:59:38 [fantasai]
- TabAtkins: Apparently we don't ???
- 16:59:48 [fantasai]
- TabAtkins: but if you look in inspector, do see it being constantly updated
- 16:59:53 [fantasai]
- TabAtkins: But either way..
- 17:00:04 [jensimmons]
- present-
- 17:00:05 [fantasai]
- emilio: Mutation observer thing, it should fire mutation observer callbacks exceptin some cases
- 17:00:19 [fantasai]
- emilio: afaict, internally we don't serialize until asked for
- 17:00:29 [fantasai]
- emilio: if that's devtools, then we reserialize all the time
- 17:00:46 [fantasai]
- TabAtkins: if that's true across browsers, then I can close as no change, browsers are smart enough to handle appropriately don't worry about it
- 17:00:51 [fantasai]
- fremy: meaning?
- 17:01:01 [fantasai]
- TabAtkins: browsers aren't eagerly serializing
- 17:01:20 [fantasai]
- iank_: file a bug against Chrome? we should investigate this
- 17:01:28 [fantasai]
- TabAtkins: apparently Chrome doesn't fire mutation events
- 17:01:34 [fantasai]
- TabAtkins: that's a bug in chrome
- 17:01:45 [fantasai]
- fremy: Because we still want to update the style attr, every single time
- 17:01:51 [fantasai]
- fremy: can we put something in the spec that says when?
- 17:02:00 [fantasai]
- AmeliaBR: it's on demand
- 17:02:09 [fantasai]
- TabAtkins: when someone asks for it, or is observing the style attr
- 17:02:13 [fantasai]
- fremy: so flag it?
- 17:02:22 [fantasai]
- fremy: ok
- 17:02:40 [Rossen___]
- q?
- 17:02:41 [fantasai]
- TabAtkins: sounds like the resolution should be, browsers should be smart enough to lazily serialize style attr when necessary
- 17:02:44 [Zakim]
- fantasai, you wanted to suggest a note in the spec
- 17:02:50 [fantasai]
- TabAtkins: I can put a note in the spec
- 17:03:22 [fantasai]
- AmeliaBR: One thing to consider, should this be a general thing for DOM attributes reflected?
- 17:03:34 [fantasai]
- AmeliaBR: working with CSSOM or other things to be consistent?
- 17:03:42 [fantasai]
- TabAtkins: yeah.....
- 17:03:44 [smfr]
- q+
- 17:03:56 [fantasai]
- TabAtkins: existing string OM, not doing any restringifying, but sure there are some reflected attrs
- 17:04:08 [fantasai]
- TabAtkins: in HTML... I'll check if HTML has wording on that
- 17:04:18 [fantasai]
- ACTION: TabAtkins investigate restringification of reflected attrs across OMs
- 17:04:37 [fantasai]
- fremy: Not always the user that gets the style attr
- 17:04:50 [fantasai]
- fremy: e.g. ??
- 17:05:12 [fantasai]
- fremy: Should never happen. Shouldn't change the DOM when recomputing CSS
- 17:05:25 [TabAtkins]
- s/??/if you have a selector that depends on the style attribute's contents/
- 17:05:30 [fantasai]
- TabAtkins: DOM has it internally tracked, doesn't need to update everything to keep consistent except on demand
- 17:05:42 [fantasai]
- emilio: style attr keep not a string, but a CSS declaration and an attached string
- 17:05:49 [fantasai]
- emilio: when request string, we serialize it
- 17:05:59 [fantasai]
- emilio: Someon requests DOM attr, will get the correct value
- 17:06:08 [TabAtkins]
- ack smfr
- 17:06:46 [fantasai]
- smfr: Normally we don't specify internal details
- 17:06:56 [fantasai]
- smfr: Would just be a QoI issue about when serialization happens
- 17:07:06 [fantasai]
- smfr: Spec shouldn't say anything, should just specify web-exposed behavior
- 17:07:15 [fantasai]
- TabAtkins: agree
- 17:07:40 [fantasai]
- TabAtkins: I will close no change, review HTML to see if they have any particular wording
- 17:07:56 [fantasai]
- AmeliaBR: only other thing is to make sure wording is clear wrt event hooks
- 17:08:07 [fantasai]
- AmeliaBR: should trigger mutation observers even if not serialized until asked for
- 17:08:31 [fantasai]
- ACTION TabAtkins write a test for mutation observer for style attr changes via TYpedOM
- 17:08:53 [fantasai]
- ACTION: TabAtkins write a test for mutation observer for style attr changes via TYpedOM
- 17:09:25 [TabAtkins]
- Topic: Simplifying away calc() wrappers around single numeric values when reifying
- 17:09:28 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/968
- 17:09:59 [fantasai]
- TabAtkins: If serializing ? or used value of calc(), gets simplified down
- 17:10:15 [fantasai]
- TabAtkins: at that point, you remove the calc() wrapper if simplifies down to a single component
- 17:10:21 [fantasai]
- TabAtkins: This behavior doesn't happen in TypedOM
- 17:10:24 [AmeliaBR]
- s/?/computed/
- 17:10:28 [fantasai]
- TabAtkins: it retains the calc() wrapper
- 17:10:32 [fantasai]
- TabAtkins: not sure if we should try to adopt or not
- 17:10:43 [fantasai]
- TabAtkins: if particular impl concern, I don't have a strong opinion...
- 17:11:06 [fantasai]
- AmeliaBR: from authoring side, if you wanted to go in and manipulate the value in the wrapper and still have clamping effects of calc()
- 17:11:25 [fantasai]
- AmeliaBR: e.g. calc(-5px) in property that's positive values only
- 17:11:33 [fantasai]
- AmeliaBR: ...?
- 17:11:43 [fantasai]
- TabAtkins: if you set a calc() it'll get that behavior, if you set a simple numeric value it won't
- 17:11:58 [fantasai]
- TabAtkins: if you want to do math, can do it without having already wrapped in calc regardless
- 17:12:06 [fantasai]
- TabAtkins: in particular, emilio brought this up in a CSS isue
- 17:12:10 [fantasai]
- s/isue/issue/
- 17:12:45 [AmeliaBR]
- s/...?/Where the clamping value would be different with a plain -5px. Not sure how clamping would be different in TypedOM./
- 17:12:47 [fantasai]
- emilio: I think getComputedValue is px value because can simplify away, so I think everyone should do the same
- 17:12:55 [fantasai]
- emilio: would be annoying in implemntation to maintain that information
- 17:13:08 [fantasai]
- emilio: about whethe was wrapped in calc or not
- 17:13:24 [fantasai]
- TabAtkins: ok, propose to resolve that TypedOM reifies value as simplified form
- 17:13:54 [fantasai]
- RESOLVED: TypedOM reifies values as simplified form (mirroring getComputedStyle etc.)
- 17:14:26 [TabAtkins]
- <br dur=10min>
- 17:14:30 [TabAtkins]
- Topic: end
- 17:16:46 [castastrophe]
- castastrophe has joined #css
- 17:24:49 [faceless2]
- @astearns we've implemented it, I haven't noticed any issues but wouldn't be likely to unless there's a WPT test for it.
- 17:25:19 [TabAtkins]
- Topic: using ObservableArray for the list-ish values in TypedOM
- 17:25:30 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/948
- 17:26:29 [fremy]
- ScribeNick: fremy
- 17:26:57 [fremy]
- TabAtkins: I tried to get better support for array-like classes in WebIDL
- 17:27:13 [fremy]
- TabAtkins: because we have three things that expose lists, and could benefit from this
- 17:27:37 [fremy]
- TabAtkins: but given I made no progress, I ended up using the legacy "getter/indexer" of WebIDL
- 17:27:46 [fremy]
- TabAtkins: but sadly that means that it's not an array
- 17:27:57 [fremy]
- TabAtkins: and you cannot use forEach etc on them
- 17:28:06 [fremy]
- TabAtkins: you have to convert them to an array first
- 17:28:15 [TabAtkins]
- https://heycam.github.io/webidl/#idl-observable-array
- 17:28:16 [fremy]
- TabAtkins: but domenic fixed this for me
- 17:28:27 [fremy]
- TabAtkins: and we have the observable array type
- 17:28:40 [fremy]
- TabAtkins: for the javascript user, it looks like an array
- 17:28:58 [fremy]
- TabAtkins: but it still triggers callbacks that allow us to type check things
- 17:29:06 [fremy]
- TabAtkins: so I'd like to switch to that
- 17:29:17 [fremy]
- TabAtkins: unfortunately that would result in a breaking change
- 17:29:51 [fremy]
- TabAtkins: indeed, the value itself cannot be an array
- 17:30:01 [fremy]
- TabAtkins: because it has to subclass the CSSValue type
- 17:30:15 [fremy]
- TabAtkins: so we need to store the list in a "values" member
- 17:30:23 [AmeliaBR]
- q+
- 17:30:40 [fremy]
- TabAtkins: for the math-value types, it's easier because it's already a FrozenArray
- 17:30:50 [fremy]
- TabAtkins: so I can just switch it
- 17:30:57 [fremy]
- TabAtkins: any objection to do this change?
- 17:31:22 [fremy]
- AmeliaBR: so, if I understand, you now need to do "x.values[0]" instead of "x[0]"?
- 17:31:39 [fremy]
- TabAtkins: if I don't accomodate that by making a special behavor, yes
- 17:31:50 [fremy]
- AmeliaBR: could we then make a putforward?
- 17:31:55 [fremy]
- TabAtkins: yes, we definitely can
- 17:31:57 [fremy]
- q+
- 17:32:17 [fremy]
- TabAtkins: and we could do that by just updating the code to do that and lookup in the array
- 17:32:23 [fremy]
- AmeliaBR: browser support?
- 17:32:34 [fremy]
- TabAtkins: yes, typedom is shipped in chrome
- 17:32:41 [fremy]
- TabAtkins: because paint api
- 17:32:51 [fremy]
- AmeliaBR: I would not like to break demos
- 17:33:07 [fremy]
- TabAtkins: yes, let's make the accomodation, it's not worth breaking the demos
- 17:33:15 [fremy]
- AmeliaBR: (restates)
- 17:33:17 [fremy]
- TabAtkins: (yes)
- 17:33:26 [AmeliaBR]
- ack AmeliaBR
- 17:33:26 [Rossen___]
- ack AmeliaBR
- 17:33:34 [Rossen___]
- ack fremy
- 17:33:39 [fantasai]
- fremy: I'm entirely in favor
- 17:33:48 [fantasai]
- fremy: Always thought it was really weird that ? and ?? you couldn't index it
- 17:33:53 [fantasai]
- fremy: so much cleaner for the PAI
- 17:33:59 [fantasai]
- fremy: not only improvement that you get an array
- 17:34:04 [fantasai]
- fremy: definitely in favor
- 17:34:11 [fantasai]
- fremy: and ??? sounds like a no-brainer
- 17:34:13 [fremy]
- TabAtkins: ok
- 17:34:16 [bkardell_]
- s/PAI/API ?
- 17:34:23 [fremy]
- s/??/forwarding
- 17:34:30 [fremy]
- TabAtkins: any concern from implementers?
- 17:34:33 [fremy]
- TabAtkins: looks like no?
- 17:34:38 [astearns]
- s/???/forwarding
- 17:34:45 [fremy]
- TabAtkins: any objection to adopt the change in the issue, with forwarding kept in?
- 17:35:12 [fremy]
- RESOLVED: put the list in a "value" property, and add a forwarding for compat
- 17:35:17 [TabAtkins]
- Topic: ban data: url worklets
- 17:35:25 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/985
- 17:35:31 [fremy]
- TabAtkins: next topic comes from Ana Tudor
- 17:35:53 [AmeliaBR]
- s/Ana Tudor/Anne VK/
- 17:35:56 [fremy]
- s/Ana Tudor/AnneVK/
- 17:35:58 [TabAtkins]
- vK
- 17:36:17 [fremy]
- TabAtkins: you initialize a worklet by passing a url
- 17:36:27 [fremy]
- TabAtkins: you can do that using a data url to avoid using the network
- 17:36:37 [fremy]
- TabAtkins: annevk says that this can be an issue
- 17:36:52 [fremy]
- TabAtkins: for security reasons
- 17:37:09 [fremy]
- TabAtkins: blob urls would still work
- 17:37:21 [fremy]
- TabAtkins: but data urls apparently have some issue
- 17:37:33 [fremy]
- TabAtkins: any comment?
- 17:37:48 [fremy]
- AmeliaBR: can we add a note showing how to use a blob url?
- 17:37:51 [fremy]
- TabAtkins: why not?
- 17:37:57 [fremy]
- TabAtkins: any suggestion?
- 17:38:14 [fremy]
- RESOLVED: ban data url from spanning a worker
- 17:38:30 [fremy]
- s/spanning/spawning/
- 17:38:39 [TabAtkins]
- Topic: make P&V API descriptors optional
- 17:38:43 [TabAtkins]
- github: https://github.com/w3c/css-houdini-drafts/issues/994
- 17:39:06 [fremy]
- AmeliaBR: with the at-property rule shipping, people started taking a look
- 17:39:28 [fremy]
- AmeliaBR: there were complaints that all the fields have to be explicit
- 17:39:38 [fremy]
- AmeliaBR: and this is not very css-y
- 17:39:50 [fremy]
- AmeliaBR: in general, css does handle defaults better
- 17:40:09 [fremy]
- AmeliaBR: and by making all these things be required, you remove some behaviors
- 17:40:21 [fremy]
- AmeliaBR: reasons why people use this
- 17:40:26 [fremy]
- AmeliaBR: - transition values
- 17:40:34 [fremy]
- AmeliaBR: - prevent inheritance
- 17:40:38 [fremy]
- AmeliaBR: - provide default value
- 17:40:46 [fremy]
- AmeliaBR: you don't always want all three
- 17:41:01 [fremy]
- AmeliaBR: and now you have to set all of them, which is not always useful
- 17:41:16 [fremy]
- AmeliaBR: worse, you cannot say "this is a color or it is invalid"
- 17:41:33 [fremy]
- TabAtkins: that default value thing is a different issue
- 17:41:43 [fremy]
- TabAtkins: I agree we should fix this
- 17:41:57 [fremy]
- TabAtkins: the other two cases
- 17:42:11 [fremy]
- TabAtkins: the inheritance one is that in JS, true has a default value is not logical
- 17:42:34 [fremy]
- TabAtkins: and we don't want to default to inheritance, because this is more costly
- 17:42:50 [fremy]
- TabAtkins: but having the default be the revert of the normal choice is confusing
- 17:43:03 [fremy]
- TabAtkins: so, we think forcing people to think about this is good
- 17:43:33 [fremy]
- TabAtkins: I think that issue is well settled, we really want to keep this in
- 17:43:48 [fremy]
- TabAtkins: for the syntax, we could use the unrestricted syntax "*" as a default
- 17:43:56 [fremy]
- TabAtkins: but I don't think that this is what you want
- 17:44:05 [fremy]
- TabAtkins: because it cannot do anything useful for you with this syntax
- 17:44:30 [fremy]
- TabAtkins: if we make this required, authors get an error, and they learn about this
- 17:44:45 [fremy]
- TabAtkins: and they realize they could have a better behavior
- 17:44:51 [AmeliaBR]
- q?
- 17:45:04 [fremy]
- TabAtkins: and "*" is not that common so I don't think it will be common enough to warrant the default
- 17:45:26 [fremy]
- TabAtkins: and there are other places in css where we force people to specify a value even if we have an obvious default
- 17:45:31 [fremy]
- TabAtkins: like for example fonts
- 17:45:40 [fremy]
- TabAtkins: we force you to say "serif" as fallback
- 17:45:46 [fremy]
- TabAtkins: even though it could be implied
- 17:45:57 [fremy]
- TabAtkins: but we thought forcing people to think about the fallback is useful
- 17:46:14 [fremy]
- AmeliaBR: you said that throwing an error makes more sense
- 17:46:26 [fremy]
- AmeliaBR: but in the non-declarative syntax, this works differently
- 17:46:37 [fremy]
- emilio: there are browsers where you can see CSS errors
- 17:46:43 [fremy]
- emilio: ;-)
- 17:46:55 [fremy]
- TabAtkins: I think this information is surfacable
- 17:47:15 [fremy]
- TabAtkins: if some browsers have a less-than-useful way of surfacing this, we can fix
- 17:47:45 [fremy]
- TabAtkins: but I still think "hey this doesn't work" is better than making it work less well
- 17:47:59 [fremy]
- TabAtkins: AmeliaBR do you feel about this strongly?
- 17:48:16 [fremy]
- AmeliaBR: not a huge deal I guess, won't object
- 17:48:31 [fremy]
- AmeliaBR: however, I think that the solution to the other issue is very important
- 17:49:01 [fremy]
- TabAtkins: yes, that's another issue, and there is another thread about that, and I think we are in agreement with what you wanted?
- 17:49:07 [fremy]
- AmeliaBR: can you send a pointer?
- 17:49:15 [fremy]
- TabAtkins: yes, issue ???
- 17:49:26 [astearns]
- https://github.com/w3c/csswg-drafts/issues/5370
- 17:49:41 [fremy]
- TabAtkins: so, it sounds like we should be able to resolve to close this issue no change for now
- 17:49:47 [fremy]
- TabAtkins: any final objection?
- 17:49:58 [fremy]
- RESOLVED: keep all fields in @property required
- 17:50:18 [TabAtkins]
- Topic: end
- 17:51:21 [fremy]
- Topic: drafts
- 17:51:31 [fremy]
- Rossen___: we have lots of specs that are outdated and needs republishing
- 17:51:38 [fremy]
- Rossen___: and most are just working drafts
- 17:51:50 [fremy]
- Rossen___: so republishing should be easy
- 17:51:57 [fremy]
- Rossen___: for example worklets
- 17:52:10 [fremy]
- Rossen___: no republication since 2016
- 17:52:31 [fremy]
- Rossen___: we only have one editor, iank_
- 17:52:41 [fremy]
- Rossen___: and that is probably not a focus of his to update specs
- 17:52:46 [fremy]
- Rossen___: so, can we get another editor?
- 17:52:59 [fremy]
- Rossen___: also, what other things do we need to do in worklets?
- 17:53:06 [fremy]
- Rossen___: because if not, can we get this to CR?
- 17:53:25 [fremy]
- Rossen___: (or, we merge it with html)
- 17:53:36 [fremy]
- florian: I think we should update the working draft
- 17:53:55 [fremy]
- florian: irrespective of whether we want to merge
- 17:54:02 [fremy]
- florian: it only takes a few minutes to do
- 17:54:11 [fremy]
- Rossen___: there are a few issues in this spec
- 17:54:15 [fremy]
- Rossen___: but not much
- 17:54:38 [fremy]
- Rossen___: TabAtkins, anybody else could help contribute to this spec?
- 17:54:43 [fremy]
- TabAtkins: I'm not sure
- 17:54:53 [fremy]
- TabAtkins: ??? worked in web audio
- 17:55:05 [fremy]
- TabAtkins: which use some aspects of worklets
- 17:55:17 [fremy]
- TabAtkins: but not sure if there's desire to become editor
- 17:55:34 [fremy]
- chris_: there are also folks at mozilla implementing it
- 17:55:36 [fremy]
- Rossen___: who?
- 17:55:41 [chris_]
- paul adenot, mozilla
- 17:55:42 [fremy]
- chris_: I'll type it in when I find
- 17:56:02 [fremy]
- AmeliaBR: handing it over to the spec that explains the window context makes sense
- 17:56:11 [chris_]
- s/???/Raymond Toy
- 17:56:14 [fremy]
- AmeliaBR: but I think updating the publication before sounds useful
- 17:56:40 [fremy]
- RESOLVED: Update the worklet spec working draft
- 17:57:09 [fremy]
- Rossen___: we also need to republish layout paint typedom
- 17:57:22 [fremy]
- Rossen___: properties and values are ok though
- 17:57:38 [fremy]
- fantasai: can we talk about grid in the last few minutes?
- 17:57:49 [fremy]
- Rossen___: yes, we dont need resolutions for the others
- 17:57:53 [fremy]
- Topic: grid
- 17:57:56 [fantasai]
- https://drafts.csswg.org/css-grid-1/#changes
- 17:58:05 [fremy]
- Rossen___: we need to publish a new CR
- 17:58:16 [fremy]
- fantasai: yes, we have DoC, tests for changes, etc...
- 17:58:18 [fantasai]
- https://drafts.csswg.org/css-grid-1/issues-cr-2017
- 17:58:27 [fremy]
- fantasai: and there is a lot of them, so we should really update
- 17:58:36 [fremy]
- fantasai: there are a few issues left over for the next revision
- 17:58:48 [fremy]
- fantasai: oriol said it would be ok to republish
- 17:58:51 [fremy]
- fantasai: and I support
- 17:58:55 [fremy]
- oriol: (confirms)
- 17:59:06 [fremy]
- Rossen___: any objection to republish CR of Grid L1 with these changes?
- 17:59:28 [fremy]
- RESOLVED: update the CSS Grid L1 CR
- 17:59:46 [fremy]
- Topic: end of the meeting ^_^
- 18:02:06 [Karen_]
- Karen_ has joined #css
- 18:03:00 [dholbert]
- dholbert has joined #css
- 18:03:23 [florian]
- +1
- 18:06:46 [Rossen___]
- Zakim, end meeting
- 18:06:46 [Zakim]
- As of this point the attendees have been Rossen, Atanassov, Microsoft, alisonmaher, cbiesinger, castastrophe, jfkthame, astearns, AmeliaBR, dholbert, oriol, TabAtkins, faceless,
- 18:06:49 [Zakim]
- ... drousso, tantek, chris_, leaverou, Guest, jensimmons, hober, plinss, GameMaker, emilio, bkardell_
- 18:06:49 [Zakim]
- RRSAgent, please draft minutes
- 18:06:49 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/07/31-css-minutes.html Zakim
- 18:06:52 [Zakim]
- I am happy to have been of service, Rossen___; please remember to excuse RRSAgent. Goodbye
- 18:06:56 [Zakim]
- Zakim has left #css
- 18:53:53 [jfkthame]
- jfkthame has joined #css
- 18:56:12 [TabAtkins]
- jensimmons: Do you still have a link to the cascade layers slides you presented back in Jan?
- 18:56:58 [TabAtkins]
- I couldn't find them in the minutes.
- 19:00:20 [jensimmons]
- I do. Just a sec.
- 19:00:56 [jensimmons]
- https://talks.jensimmons.com/QOEOYT/three-topics-for-jan-2020-csswg-meeting#srFUYHC
- 19:14:37 [Domenic]
- Merging worklets with HTML would probably be good for reducing maintenance burden. Currently whenever we change how globals work (which is a surprisingly-active area) we have to update three specs: HTML, service workers, and worklets. Reducing that to 2 would be a big simplification.
- 19:18:25 [fantasai]
- jensimmons: Can you send a copy to www-archive@w3.org?
- 19:19:11 [fantasai]
- gregwhitworth: Need a PDF attachment of your slides to www-archive, not just a link. The whole point is to get it archived. :)
- 20:44:50 [JonathanNeal]
- Is there something I can do as a non-member to make IPR commitments so that my PRs do not get failure checks? Ref: https://github.com/w3c/csswg-drafts/pull/5377
- 21:05:41 [fantasai]
- JonathanNeal: I'm sure there is, but I'm not sure what.
- 21:05:50 [fantasai]
- JonathanNeal: Chris Lilly or xfq would know
- 21:06:57 [fantasai]
- TabAtkins: If you approve https://github.com/w3c/csswg-drafts/pull/5377 I will merge it
- 21:47:38 [innovati]
- innovati has joined #css
- 22:25:50 [innovati]
- innovati has joined #css
- 22:40:46 [fantasai]
- JonathanNeal: merged
- 22:41:50 [JonathanNeal]
- fantasai-stic! 🎉
- 22:46:31 [innovati]
- innovati has joined #css
- 22:52:37 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/07/31-css-minutes.html fantasai
- 23:01:12 [fantasai]
- TabAtkins: Filed the CR update request! https://github.com/w3c/transitions/issues/258
- 23:02:57 [TabAtkins]
- fantasai: nice!
- 23:04:00 [fantasai]
- Also pushed a pile of track-sizing tests to WPT because we had like no tests on min-content sizing so adding one for the minor fix wasn't really...
- 23:04:14 [astearns]
- yay tests!
- 23:04:18 [fantasai]
- That brought up the interesting case of 'auto min-content'
- 23:08:47 [fantasai]
- when min-width < min-content, the auto column gets smaller than the min-content column...
- 23:08:52 [fantasai]
- kinda weird
- 23:09:24 [fantasai]
- not sure that's expected
- 23:10:04 [fantasai]
- http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20grid-template-columns%3A%20auto%20min-content%3B%20float%3A%20left%22%3E%0A%3Cspan%20style%3D%22grid-column%3A%201%2F-1%3B%20min-width%3A%2010px%22%3Etestingmincontent%3C%2Fspan%3E%0A%3Cspan%20style%3D%22border-bottom%3A%20solid%20orange%22%3E%3C%2Fspan%3E%3Cspan%20style%3D%22border-botto
- 23:10:10 [fantasai]
- m%3A%20solid%20teal%22%3E%3C%2Fspan%3E
- 23:10:13 [fantasai]
- ...
- 23:10:15 [fantasai]
- anyway