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