good morning heycam|away !

or afternoon or whtaever

Zakim, start meeting

present+ Rossen Atanassov, Microsoft

present+

present+

present+

present+ Rossen Atanassov

present+

present+

present+

present+

I don't seem be able to join on video? I enter the code (***-dama-***) but then am told no-one else is here...

present+

faceless2, doing that same thing worked for me FWIW

present+

present+

ScribeNick: TabAtkins

Topic: Should ::first-letter include space separator?

github:https://github.com/w3c/csswg-drafts/issues/5154

present+

present+

astearns: We got the examples tantek was asking for

astearns: For Norwegian and the other language [French, I think], it makes sense to add those space separators, since they're in the markup

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?

florian: I think dauwhe said they were inserting spaces to adjust visual separation for English content, so they would want the space included.

tantek: I tried to do a little more research as well.

tantek: Didn't have time to upload

[shows Elements of Typographic STyle]

tantek: ON p64, there's some first-letter effects with leading punct, including with guillarmes

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.

tantek: So I'm concerned we might be doing the wrong thing.

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

q+

tantek: Ok [shows an example in English too]. Maybe we should consider these issues together.

It's issue 2040

astearns: I'll drop it in the minutes.

ack fantasai

fantasai: So this is about whether we include the space *when* there is a quotation mark, not about the quotation mark itself.

fantasai: If we want French and English to be the same, we need to include it.

there is also w3c/csswg-drafts #4988 for changing size of components of initial-letter

fantasai: As astearns said, 2040 is about the formatting question if you want the punct and letter different.

q?

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.

q+ to comment on U+0020

fantasai: So if we're really concerned, we cna exclude u+0020 and only include the other spaces.

fantasai: And note that the punct by itself wont' be picked up as a ::first-letter anyway; you need a letter.

AmeliaBR: I'm not sure about ignoring u+0020, lots of people will type this with a stadnard space

ack AmeliaBR

AmeliaBR: But probably the more exotic spaces can be ignored.

present+

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.

rrsagent, here

Anyone who's fussy about typography will use the correct space, I think :)

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.

ack florian

if I paste this here does it work? w3c/csswg-drafts #2040

florian: Good guides about typography will say to use various spaces, but most people dont' know how to type those.

I think we should allow the regular space, even though I'm fussy about typography

florian: At least in French, it's pretty common to say ordinary spaces, probably same in Norwegian. So I'd include standard space.

q?

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.

tantek: And end up with big punctuation as well as big letters.

tantek: That might come as a surprise to authors who are used to not doing that automatically.

tantek: And I'm not sure it's the right default.

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.

tantek: That would look closer tothe typography examples.

q+

tantek: I'm concerned we have yet another place where we do the wrong thing typographically by default.

tantek: The web has a tradition of this, liek the way large text messes up the line rhythm.

so now we need a term for "the characters before the first actual letter"?

tantek: So I'm concerned if we add one more papercut.

chris_, we need a pseudo-element, yes :)

q+

tantek: 5154 shows what browsers are currently doing

tantek: There's an example with th eleading quote... [missed]

ack fantasai

fantasai: I think tantek is getting caught up in the not-perfect

in the examples provided for this issue, the punctuation *does* take the same styling as the letter: w3c/csswg-drafts #5154#issuecomment-659129316

::first-letter-before

fantasai: I think you're forgetting that English and French punct have the same problem and have to be treated the same way

ack florian

fantasai: We need to include the space to keep these on-par, and having them be inconsistent is bad

florian: Having ::firs-tletter select the letter and not the preceding punct seems bad, it's already complicated, sounds scary.

s/bad/bad and doesn't solve those problems anyway/

florian: As to compat, Safari does it already. So there's some amount of content out there probably already depending on it.

florian: So in this example we actually do want the included thing to be large.

florian: In other cases we wont' want the punct large, but those apply equally to the exisdting punct-letter without space.

TabAtkins: Florian touched on it at the end, one of the big concerns Tantek brought up

TabAtkins: is wanting to address differently-sized punctuation wrt first-letter

TabAtkins: But that's already the case. If there's no space, we already have that problem, already have to solve it.

TabAtkins: It's not relevant to this issue.

ack TabAtkins

Rossen_: So I think there were several reasons for ahving this, including some existing shipping impls

Rossen_: So it's probably not a compat risk, or at least not a big one.

q+

ack tantek

tantek: I don't actuallys ee the Safari example as proof of no compat problem

tantek: Safari applies all th epunct as well.

tantek: It wouldn't surprise me if there's special-casing going on here, looks like impl by accident.

tantek: Looking at an example with a massive preceding dash.

tantek: It woudlnt' surprise me if people are already not giving that styling to Safari to avoid that problem.

astearns: Also in CHrome

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?

tantek: Ok. So that's a bug, and I dont' thinkw e should be designing based on a bug.

q

florian: We're not saying it's a bug, we're saying it's desirable.

tantek: I'm talking justa bout the hyphen.

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.

florian: If there is a real compat problem we'll find tou and revisit

faceless2: The big hyphen was actually a desired effect

s/tou/out/

tantek: I'm convinced by the examples, we shoudl do this, but we should make it dependent on solving 2040

tantek: That would be my compromise proposal

tantek: I think this group can solve that.

fantasai: We need to do one thing at a time. These are two separate features that happen to work together.

fantasai: So let's just get opening quotes working the same between langs.

present+

tantek: They're both ::first-letter

[back and forth]

q?

+1 to resolving on this now

TabAtkins: Today, a single quote and no space, will be combined together.

TabAtkins: and the quote won't be sized "correctly" in that case either.

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?

tantek: I strongly prefer that we make this resolution dependent on 2040, but I won't object.

Rossen_: So any objections?

RESOLVED: Spaces separating punct from first letter dont' stop ::first-letter

Topic: Define em-top and em-bottom baselines

github: w3c/csswg-drafts #5312

fantasai: The canvas API has a handful of metrics that it allows getters for

fantasai: They decided to defer to CSS Inline for their definitions

fantasai: We ahve a section in css-inline which defines a bunch of metrics, their opentype equivs

fantasai: They're taking a dependency on ascent and descent metrics for the purpose of font bounding box

fantasai: There's another metric in this canvas spec that we dont' have a definition for in the CSS spec

fantasai: So I propose we include that

fontBoundingBoxAscent/Descent

fantasai: Those map to our ascent/descent

emHeightAscent/Descent

fantasai: Then there's the em height ascent/desent

"highest top of the em squares in the inline box"

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

fantasai: So the proposal is we define that metric, so the canvas api spec can hook into it

fantasai: Even if we don't end up using the metric in our own spec

fantasai: I talked to jfkthame about what he thinks the metric should be

+1 for keeping all definitions in one place

fantasai: Idea is [in the issue]

Proposed definition from me and @jfkthame is:

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)

if none of the ideographic baselines are defined, use the ascent and descent normalized proportionally so they add up to 1em

florian: So dont' use the actual size, but use the proportions?

faceless2: Lots of fonts dont' have these metrics add up to 1, so normalizing is important

q?

AmeliaBR: So looks like midpoint of ascent/descent, then .5em both ways.

AmeliaBR: So it might be larger or smaller than ascent/descent if they weren't 1em apart originally?

fantasai: Yes. And bias toward the ideographic lines if they exist, they're more likely to be 1em apart

fantasai: They're also more likely to be in the center of where the ink falls, because they're centrally painted

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.

Rossen_: Koji, any opinion on this?

koji: I generally support defining this.

koji: Been discussing with our canvas team aobut it

koji: Tehy're not really well-defined

koji: How to do it, I think we need more investigation/discussion.

koji: I'm asking in the issue some questions, and not sure what the correct way to define it is yet.

koji: So no concrete proposal yet, but think we need more investigation to make this move.

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...

Rossen_: I think there's alignment behind exposing these metrics and roughly defining them as suggested

Rossen_: Possibly with tweaks as we adjust

Rossen_: Are you against that?

koji: Not all my questions are answered yet. Like, font top metric is visual, but we probably need to support vertical flow.

q?

Rossen_: I think elika just answered that in the issue about 30s ago.

AmeliaBR: What is the actual use-case for these metrics? ARe we expecting people to use them to draw boxes around their text?

AmeliaBR: Knowing that might inform what a useful definition is.

fantasai: I think they'll be used to position the text.

Rossen_: There are more and more solutions taking a dependency on canvas today for word-like or excel-liek apps

Rossen_: So more and more need doing higher-fidelity typography thru canvas

iank_: The exact use-cases are basically "everything youc an imagine someone wanting to do when laying out text". It's pretty broad.

AmeliaBR: Right, the question is what this adds to the existing terms, and is this proposed dfn solving what's needed?

AmeliaBR: I don't know, bc I don't know what the people who added this metric were thinking about.

q?

fantasai: Well the current ascent/descent metrics aren't interoperable, so one thing this adds is a consistent answer for something ascent/descent-like.

fantasai: The font metrics used for these differ depending on browser/OS currently.

q+

fantasai: So at least in cases where we have ideographic metrics, we can get a consistent cross-platform answer here.

koji: This wouldn't be interoperable, right? It relies on ascent/descent.

fantasai: Yeah, it's just closer to interop.

koji: Is Gecko okay to change to match this?

ack jfkthame

jfkthame: I think we'd be fine with this, it's fairly close to what Gecko already does.

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.

jfkthame: I think there's a legit expectation for those to be 1em apart.

jfkthame: But it's not clear where the text falls in the em square if ascent+descent doesn't equal 1em.

jfkthame: So that's where this normalization comes in, giving a sensible definition to where the em square is

Rossen_: Do we know what current word formatters do in this case?

koji: There's one definition in opentype saying the ideographic em box with almost the same algo proposed here

koji: Except opentype says it only exists for cjk fonts, and it's udnefined otherwise

Rossen_: Is it a problem to define it for non-cjk?

koji: We tried to do some work there. When we used platform ascent/descent, it was quite bad

koji: We then used [s-type?] ascent/descent, we use that for underline position.

koji: we probably need more heuristic investigations

s/s-type?/sTypo/

koji: In canvas we dont' ahve font cascading, right?

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.

AmeliaBR: Canvas does do font fallback like CSS does.

Rossen_: So looking for progress.

I have to drop for a meeting, back online around noon

fantasai: I'm happy to put a note in saying that these metrics are for canvas, and not meant for CSS.

fantasai: I think we should add the terms and dfns, and note we dont' plan to use them in CSS.

fantasai: And then if there are changes to the algo needed, we can address that in further issues.

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

RESOLVED: Accept the addition of the terms with the current proposed definitions.

<br dur=15m>, right?

Topic: end

Topic: initial-letter alignment with overflow:sunk

github:https://github.com/w3c/csswg-drafts/issues/5329

s/overflow:sunk/over-sunk letter/

s/with overflow:sunk/when over-sunk/

faceless2: When you have an initial-letter smaller than the space given, how do you align it within that gap?

faceless2: Existing spec aligns it to the bottom, elika proposes we change it to the top

fantasai: It fixes a use-case I had for indic scripts, and the OP's case which is Latin

fantasai: The proposal is to do this when the size is less than the sink value.

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

fantasai: But when size < sink, we align to the top metric so we're pulling up

florian: And the initial dfn just only considered one case and we forgot the secon dhalf?

fantasai: pretty mcuh

Rossen_: Any other opinions?

RESOLVED: When 'over-sunk', an initial-letter is aligned with the top metrics instead.

Topic: end

ScribeNick: fantasai

Topic: Houdini

s/Houdini/Houdini Layout/

Topic: String based inline layout API

github:https://github.com/w3c/css-houdini-drafts/issues/990

Rossen_: More and more desire to be able to perform typographic text layout from Canvas

Rossen_: There were some proposals put forward to essentially expose API in the platform that will allow developers to do that

Rossen_: e.g. ^

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

Rossen_: Overall idea, instead of performing layout that is based on a particular subsection of DOM that has text, inline markup, etc.

Rossen_: Instead expose an API that simply, for custom layout or maybe different API, takes as input a string

Rossen_: and does layout into the given space

Rossen_: If Houdini is not able to handle this, we are failing this on some higher level

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

Rossen_: Since then see that some additional comments by Travis and ?

Rossen_: from Edge Team

q+

Rossen_: and I wanted to essentially turn this into a question and ask, does it seem like a reasonable API?

q+

Rossen_: Is this a good API to add, given intended functionality?

Rossen_: Will it serve the purpose motivating the other proposal?

AmeliaBR: Ian had a question in the issue about, once you've laid out, how do you query back the position of content?

AmeliaBR: If you're going down that road, might look at APIs from SVG

AmeliaBR: Can't promise they'll be all you want, but if can harmonize it's better

AmeliaBR: More specifically on the proposal, like the idea of being able to run layout separately from full CSS layout context

AmeliaBR: And re-using Houdini Layout APIs sounds good

AmeliaBR: I'm concerned about being based on simple text strings

AmeliaBR: As soon as you go beyond the simplest things, need annotations

AmeliaBR: Need info on languages, need markup for bidi, going to need nest it with italic phrase inside regular text phrase, etc.

q+

AmeliaBR: So it might be better to keep thinking of styling a DOM fragment

AmeliaBR: but DOM fragment doesn't necessarily need to be attached to the document

AmeliaBR: Because you will need some hierarchy of content

Rossen_: what you're asking for already exists, just extending to handle string only

ack AmeliaBR

ack fremy

fremy: One issue of doing with strings is, if you have ? such as text selection

fremy: Doesn't work if you don't have something in the DOM to select

fremy: Don't know the use case for the text

fremy: But selection is something users expect, and problematic if we can't handle selection

fremy: But at the same time, think about what Amelia said

fremy: if you have something in the DOM to represent the string

fremy: [something about spans]

fremy: If in the DOM, you can copy and paste, etc.

fremy: A lot of times you don't want to have everything possible in CSS

fremy: Sounds useful in many cases

ack iank_

iank_: The linked formatted text explainer is much more well thought out

iank_: and seems pretty good

iank_: Amelia brought up point wrt doing on document fragments

iank_: Issue there is, this API wanted to work inside of workers

iank_: because have the Canvas API

iank_: I don't think needs that much of hierarchy

iank_: styling particular runs is roughly equivalent to structured hierarchy

q+

iank_: One thing to think about there is bidi reordering, though

iank_: To harmonize APIs

iank_: call out some core ? or mixins that can be shared between the APIs

iank_: Once you have a line of text, what info can you query?

q

iank_: no reason they should be different

??: Motivation was apps, like photoshop / excel

sushanth: API was trying to give them ability to do multiline text

s/??/sushanth/

sushanth: Houdini, they have control over canvas context they'd want text to be rendered?

sushanth: Paint Worklet, Houdini controls context

sushanth: but these cases rendering other things, just want a few lines of text

sushanth: In terms of measuring API, we went towards existing Canvas Text Metrics API

sushanth: exposes same set of things

sushanth: Not the same as SVG, but has precedence on having some APIs

sushanth: Chromium has advances as well

q+

sushanth: I think last question, selection / background / borders missing from this API

sushanth: with metrics can implement this

sushanth: in JS

q?

sushanth: Just wanted basic multiline text

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

jfkthame: Does not handle that one character can map to arbitrary number of glyphs and vice versa

jfkthame: the mapping between glyphs and characters can be quite complex, and it doesn't handle that

q?

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

AmeliaBR: if that's extended to handle i18n issues, that's a good start [wrt bidi and lang?]

AmeliaBR: Might be useful to export a DOM fragment to this format

AmeliaBR: so if you have CSS-styled markup in Canvas Shadow DOM or in your SVG

AmeliaBR: and want to run through this API to get layout, would be a great feature

q

q+

Rossen__: SVG has had this capability request for the longest time

Rossen__: some such as inkscape that support, no renderers

Rossen__: Want it in Canvas

Rossen__: If for every one of these [sound breaks]

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

ack sushanth

sushanth: Point about advances in text metrics, it's incomplete

sushanth: flag to get it to wokr

sushanth: Does handle multiple glyphs per characters

sushanth: We augmented with hierarchy to allow advances within ?

sushanth: It addresses multiple chars into single glyph is that it gives you the same advance value

present+

sushanth: They'll all have the same advance value

present+

sushanth: advance = position from the start

q?

jfkthame: That won't be any different than a zero-width character right?

This is similar to how the SVG API works: multiple characters will match to the same glyph box

sushanth: true

sushanth: Some other issues also?

Rossen__: Main point I wanted to make before network drop...

Rossen__: If we're not looking for ways to harmonize Houdini APIs with rest of platform

Rossen__: failing main use case of exposing ? to other things like Canvas and SVG

s/?/text layout/

Rossen__: As we all know, text seems very benign and easy, when you thinking only about a few ascii glyphs

Rossen__: breaks based on simple logic

Rossen__: Things get increasingly complex

Rossen__: to the point where you're mostly ending up re-implementing layout for CSS

Rossen__: which now intended to be exposed as Houdini APIs

q+

ack fantasai

q+

fantasai: Just wanted to say, I echo concerns about getting i18n right.

q-

q+

fantasai: Also want to say, I would be very uncomfortable resolving to add a new major text API without Myles signing off

fremy: Was thinking about use case, the idea is to run this in workers

fremy: because can't ? directly

fremy: So that's why don't want to take something from the DOM and draw it

s/?/access the DOM/

fremy: ...

fremy: HTML content and canvas can automatically update

fremy: what gets drawn on it

fremy: that could get the other things to work

fremy: for ppl using the API

fremy: Draw on the canvas, put this in the DOM, and gets updated

fremy: enables selection, a11y, etc. everything to wokr

s/.../describes an export from this API to a DOM fragment/

fremy: That's an idea, another way of looking at it

iank_: Based on the canvas text explainer here, definitely possible to harmonize SVG and layout API with htis

ack iank_

ack fremy

iank_: might me helpful to get on videochat and talk about details in detail at some point

Rossen___: As stated in the beginning, wanted to get opinion on whether good approach in general

Rossen___: For the proposed solution put together by ian on that issue, wanted to get feedback from sushanth and others

Rossen___: whether approach worth pursuing

Rossen___: Closing remarks are let's get together and work on this

thank you Ian, happy to follow up. :D

q+

ack fantasai

fantasai: bidi, lang-tagging or markup for change in formatting, selection, a11y, character to glyph mapping ...

fantasai: justification? would it be possible?

q

sushanth: ? has some some text justification, has just left/right/center

s/?/canvas/

fantasai: just wanted to make sure these points don't get lost

florian: Want to echo a bit of the warning Myles gave us last time on this topic

florian: needs to be foolproof, so that if user of API doesn't think about them, they still work

present+

florian: otherwise we make large parts of internet inaccessible or unusable to a lot of the world population

florian: ...

florian: getting the right balance is hard, but we have to do it

iank_: This API is a substantial leap forward from current Canvas APIs

[Note to scribe: insert link to Myle's comments here]

Topic: ????

s/????/Print Behavior and Test Requirements/

github: w3c/css-houdini-drafts #978

github: w3c/css-houdini-drafts #978

TabAtkins: gsnedders brought up really good point that historically we don't run JS for print

TabAtkins: but how should that interact with layout API and paint API?

q+

TabAtkins: print style can change sizes of things

TabAtkins: have to run custom paint and custom layout

ack florian

TabAtkins: are we doing something with that?

q-

TabAtkins: if we're not, do we plan to?

TabAtkins: we should document this either way, to make sure it's clear how printing and houdini APIs work together

Rossen___: When are we evaluating print?

TabAtkins: when you print a web page

TabAtkins: switch over to print styles and fragment for printing

+q

TabAtkins: but aren't running JS

iank_: These particular things, we should be running any layout API JS

ack AmeliaBR

AmeliaBR: Definitely as part of a style recalc

AmeliaBR: Dunno if works correctly, but that should be the expectation

sushanth: for printing, I work on canvas so I know how it works for Chavas

sushanth: There's a "about to print" event, and you do stuff, and that gets replayed

present+

ack sushanth

sushanth: when you print, those recordings are played back

s/"about to print"/onBeforePrint/

q+

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

emilio: One question, for print approach, what happens when user changes stuff?

emilio: does print run multiple times?

emilio: in Gecko that's not the case

emilio: You issue print command, right?

emilio: there's a print preview that let's you adjust page size / margins / etc.

emilio: we don't dispatch JS events every time that happens

emilio: in Gecko, we do a complete separate document just for printing

emilio: we fire beforeprint event before doing this

emilio: when you change layout, we don't do it over again

AmeliaBR: It would be after regular JS event

q?

ack emilio

AmeliaBR: Houdini isn't part of event loop, it's triggered by style recalc directly

q+

gsnedders: Want to point of last bit of my issue, which was about how we plan on testing the layout API

gsnedders: whether we expect there to be different testing for paged media vs scrolling media

iank_: There's currently work that is at least planned but maybe not in progress to support better printing in WPT?

gsnedders: We have paged reftests, but only currently implemented in Gecko

iank_: so on Chromium project to add support reftests of that form

ack gsnedders

iank_: Testing strategy should be no different from other printing tests

gsnedders: ...

gsnedders: JS tests for worklets specifically, do we want them to differ from paged media?

iank_: Changing behavior between paged vs non-paged?

iank_: Definitely will be a difference

iank_: sizes change

iank_: definitley change in layout maybe paint

iank_: One that's missing is fragmentation support

iank_: that's one thing that will definitely be triggered by paged media context

emilio: We ported a lot of the Gecko paged reftests to be in WPT

iank_: We're undergoing adding more and more capabilities to our new fragmentation engine

iank_: adding a lot of those tests as ? tests

iank_: first half of next year will be focusing solely on printing, effectively

iank_: will add a lot more reftests

s/?/ref/

iank_: will work on supporting print reftests in chromium at the same time

gsnedders: I think that answers my questions

Rossen___: smfr pointed out that we should probably specify when Houdini JS is specified in all of these cases for printing

AmeliaBR: Are worklets allowed to do anything asyc?

TabAtkins: nope. Very intentionally

ScribeNick: TabAtkins

fantasai: Layout API hasnt' been published since 2018, and I'm guessing edits ahve happened since then

fantasai: Just want to point out that Layout API haven't been published since 2018

Rossen___: Yes Ian and I botha ttempted to publish this and both failed

fantasai: If you have mechanics issues, can youg et a staff contact to help?

Rossen___: Yes.

fantasai: If you're getting stuck, ask the staff contacts for help

scribeNick: TabAtkins

TabAtkins: let's record a resolution

TabAtkins: Any houdini JS that needs to rerun for style / layout recalc needs to run

RESOLVED: Any Houdini JS that needs to run for style / layout calc needs to run for print

Topic: Break

<br end="??:25">

present+

CSS Color 4 sample code: drafts.csswg.org/css-color-4/conversions.js and drafts.csswg.org/css-color-4/utilities.js

Topic: Color Conversion and Contrast Ratio

github: w3c/css-houdini-drafts #989

CSS Color 4 sample code: drafts.csswg.org/css-color-4/conversions.js and drafts.csswg.org/css-color-4/utilities.js

present+

Rossen___: This issue motivated by TAG review about addition of lch and lab color spaces

Rossen___: One concern being discussed being discussed with TAG was that we were getting more variety of color across platform

Rossen___: but capabilities of simple things like contrasting two colors is very difficult

Rossen___: One of the ideas was, hey, if we have a strongly defined type of color that we can use across platform

Rossen___: then we could look at exposing variety of functions either on or around object

Rossen___: and achieve objectives like a11y and other things

Rossen___: Seemed like TypedOM is good place to start

Rossen___: Color is a type we need to define strongly

Rossen___: Luckily Lea and Chris jumped in, had been thinking about it

?: ??

chris_: in color 4 there was an appendix written in JS by which I mean Pascal

chris_: It's simple, does work, set of simple functions

chris_: Also have utilities.js

chris_: includes a contrast function

chris_: Here's an sRGB_to_LCH

chris_: it does it all in the right order

chris_: It was useful for examples

chris_: and useful for color 5

chris_: but this is not a proposal for a color model

chris_: not object oriented

chris_: it's just something that wroks

chris_: Here's color.js

chris_: Until this morning was a private repo, now public

chris_: also not a proposal, but it's object oriented

chris_: This is a JS API, you can use it in the browser or on the server

chris_: These examples are all live, you can edit directly in the web page if you want

chris_: variety of color models, includes all in color 4 (except device-cmyk()) as well as a few more

leaverou demos

chris_: Notice these are in different color spaces

chris_: Internally it goes into CIEXYZ, and then ??, and then gets you a contrast

chris_: You just say you want contrast between two colors, and it just works out for you

chris_: You can change lightness or chroma or whatever

chris_: similar to things we do in Color 5

chris_: Convert between color spaces

chris_: interpolate between colors

chris_: either discreet steps, or gradients, or that sort of thing

chris_ reviews documentation

chris_: Color object. Can give a CSS string or use initializer with coordinates

leaverou: color space ID plus coordinates plus optional alpha

leaverou: or another color

s/color/Color/

chris_: This is similar to color-5, adjusting named coordinates

chris_: We've actually supported more than Color 4 supports

chris_: might be interesting to see if any would be useful as future additions

chris_ notes there's bugs, especially in the documentation, since this is pre-release

chris_: You can change color coordinates. Don't even have to change coordinates of the color space you're in

chris_: That's fairly useful

chris_: We also do gamut-mapping

chris_: because easy to get colors that are out of gamut

chris_: we've worked on that quite a bit, have an algo that works rather well

chris_: Do a binary search to find closest color via chroma reduction

chris_: and do speculative ???

chris_: 1st one we reduce chroma until it's inside the range

chris_: 2nd one, at each stage, we see if we clipped here, would we be close?

chris_: and that works much better

s/???/clipping/

chris_: thinking to spec that in color-4 spec

chris_: Interpolation

chris_: range function allows that and getting intermediate stops

q

q+

leaverou: range function actually returns a function

leaverou: we can specify which space to do interpolation in

leaverou: you can see here examples of what each interpolation space produces

leaverou: we also implemented longer/shorter/increasing/decreasing args for the hue we were discussing

leaverou: although didn't implement dbaron's ? yet

chris_: Lets us implement and check and see if it works. Very helpful in writing spec

chris_: Also discussing keeping ? constant

leaverou: but we do keep Nan for chroma

s/keeping ?/using Nan for keeping coord/

chris_: It's on GH and there's a link, and also a bunch of tests

chris_: any questions at this stage?

ack Rossen___

Rossen___: First of all, this is awesome, thanks for sharing

Rossen___: Looking forward to playing with the project

Rossen___: that's exactly what I was hoping to see

Rossen___: and you made this fantastic

Rossen___: Wrt functions like color-mix() etc.

big +1 this is super great!

Rossen___: let's say we start going towards adopting such a type in TypedOM, where does that leave us?

q+

chris_: You'll have 2 ways to do it: declarative in color-5, and imperative way like this

chris_: imperative can have more functionality

chris_: I don't think it's a problem that we have both declarative and imperative

leaverou: ?

leaverou: haven't done adjusters yet

leaverou: accepts a color space as well, but not adjusters

chris_: As general goal, would like to implement all of color-5 so we can test, and do example, see how that works

chris_: Another thing ppl might have noticed, there's a few more color spaces here not in color 4

chris_: support high dynamic range coors

chris_: there's a secret spec called css-color-hdr

chris_: there was an issue around high dynamic range

chris_: I said we won't do it, because too unstable

chris_: but I did spec an extension to color-4

chris_: and wanted to see that it works and coded it up

chris_: I presented to ??? and got good feedback, currently incorporating that

chris_: will present to the WG later

s/???/ICC/

chris_: in the meantime, i'm incubating it in code to see whether it's feasible

ack AmeliaBR

AmeliaBR: Great library, very useful. Some similar things, but this is a nice APi with good features

AmeliaBR: Wrt what we should adopt into the actual Web platform

AmeliaBR: I do like the idea of having general color utilities object

AmeliaBR: That you can call without having to getComputeStyle

AmeliaBR: coordnate with TypedOM also good

AmeliaBR: so you can construct CSS color type or get it from a style rule or a computed style

AmeliaBR: that would be great design

AmeliaBR: Probably don't want quite as many features as we have in this library

AmeliaBR: Might want to integrate a bit more e.g. generated gradients

AmeliaBR: and easing function would be its own object, to use more generally than just color

AmeliaBR: Interpolator for data vis

AmeliaBR: would be a great feature, use native interpolation that CSS already knows how to do

AmeliaBR: with additional smarts like interpolating in different color spaces

AmeliaBR: also useful to have

astearns: Anything else besides showing new cool code?

Rossen___: How do you see this moving forward?

chris_: Requirements, one of them for web platform API

chris_: what features do we want, what would be nice, what would be layered on top

chris_: Rossen asked about contrast, that's important

chris_: Converting between color spaces without having to understand how it does

chris_: not knowing about white points, not having to figure that out, that's important

leaverou: There should also be way to access color before / after gamut mapping because ???

AmeliaBR: Especially important for finding contrast ratio

AmeliaBR: if colors are theoretically good contrast, but not on user's screen, need to reflect that

florian: So is the plan to subset your project into TypedOM? and then build your project on top of that result?

chris_: would be reasonable

astearns: If you can't build on top of the subset, then we chose the wrong subset

Rossen___: That was part of my hope

Rossen___: exactly why I was provoking this type of discussion and exposure in typed OM space

Rossen___: Anything else left on color that you didn't cover?

s/ ???/ that affects the results/

leaverou: ICC profiles

leaverou: in theory, TypedOM should cover that as well

leaverou: but wouldn't that make it asynchronous?

TabAtkins: We already have a few things that need external resources, don't have a great way to handle that

TabAtkins: but nothing else needs to be infected, just wait for them via Promise

chris_: Mentioned that we have a lot of stuff. Because we wanted to test things against each other

chris_: e.g. deltaE, implemented 5 different variants

chris_: wanted to compare visual result, perf

faceless2: ...

florian: Feels like what we need is the various objects and methods to let you get from one to the other, and create mixes

present+

florian: don't necessarily need all the operations to get from one color to another color

florian: maybe need ? and ?, but methods to get between them, but TypedOM doesn't need

chris_: Do need an intermediate way to go between colors

chris_: you use colors together, not in isolation

q?

AmeliaBR: Base case would be converting single color into other color spaces

AmeliaBR: so you can convert two colors into the same color space in order to compare or calculate

AmeliaBR: Devs can implement the formulas that use whatever paramterization of colors that they need

chris_: yep

Rossen___: I agree

Rossen___: that was initial motivation here, exposing the type that will allow you to at least hoist the color space and its values

Rossen___: having this type, you can start adding libraries around it that do a bunch of math

Rossen___: as we go forward, can identify which math goes into native platform and which stays as library

Rossen___: but not having basic type is a blocker

Rossen___: My hope and ask for you, is to start defining what this type should look like

Rossen___: what is minimum set of parameters and stuff

Rossen___: I see Tab and fremy still editing TypedOM, so work with them to move it forward

ack fantasai

fantasai: I want to note that Typed OM has also not been published since 2018.

Topic: Concern about attributeStyleMap updating the style attribute

github: w3c/css-houdini-drafts #997

TabAtkins: I'm not sure if this is an actual concern to worry about

TabAtkins: wanted impl advice

TabAtkins: when doing high-frequency updates, like during TypedOM

TabAtkins: use single transform object, setting over and over again

TabAtkins: but are seeing the style attr get updated in real time as well

TabAtkins: so reserialization happening constantly as well

TabAtkins: we saw as a perf concern

TabAtkins: So is this actually causing trouble?

TabAtkins: person seems to believe causing perf issues, I'm not sure myself

TabAtkins: but if we are eagerly reserializing to style attr, not great. Negates a major advantage of TypedOM

TabAtkins: Apparently we don't ???

TabAtkins: but if you look in inspector, do see it being constantly updated

TabAtkins: But either way..

present-

emilio: Mutation observer thing, it should fire mutation observer callbacks exceptin some cases

emilio: afaict, internally we don't serialize until asked for

emilio: if that's devtools, then we reserialize all the time

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

fremy: meaning?

TabAtkins: browsers aren't eagerly serializing

iank_: file a bug against Chrome? we should investigate this

TabAtkins: apparently Chrome doesn't fire mutation events

TabAtkins: that's a bug in chrome

fremy: Because we still want to update the style attr, every single time

fremy: can we put something in the spec that says when?

AmeliaBR: it's on demand

TabAtkins: when someone asks for it, or is observing the style attr

fremy: so flag it?

fremy: ok

q?

TabAtkins: sounds like the resolution should be, browsers should be smart enough to lazily serialize style attr when necessary

TabAtkins: I can put a note in the spec

AmeliaBR: One thing to consider, should this be a general thing for DOM attributes reflected?

AmeliaBR: working with CSSOM or other things to be consistent?

TabAtkins: yeah.....

q+

TabAtkins: existing string OM, not doing any restringifying, but sure there are some reflected attrs

TabAtkins: in HTML... I'll check if HTML has wording on that

ACTION: TabAtkins investigate restringification of reflected attrs across OMs

fremy: Not always the user that gets the style attr

fremy: e.g. ??

fremy: Should never happen. Shouldn't change the DOM when recomputing CSS

s/??/if you have a selector that depends on the style attribute's contents/

TabAtkins: DOM has it internally tracked, doesn't need to update everything to keep consistent except on demand

emilio: style attr keep not a string, but a CSS declaration and an attached string

emilio: when request string, we serialize it

emilio: Someon requests DOM attr, will get the correct value

ack smfr

smfr: Normally we don't specify internal details

smfr: Would just be a QoI issue about when serialization happens

smfr: Spec shouldn't say anything, should just specify web-exposed behavior

TabAtkins: agree

TabAtkins: I will close no change, review HTML to see if they have any particular wording

AmeliaBR: only other thing is to make sure wording is clear wrt event hooks

AmeliaBR: should trigger mutation observers even if not serialized until asked for

ACTION TabAtkins write a test for mutation observer for style attr changes via TYpedOM

ACTION: TabAtkins write a test for mutation observer for style attr changes via TYpedOM

Topic: Simplifying away calc() wrappers around single numeric values when reifying

github: w3c/css-houdini-drafts #968

TabAtkins: If serializing ? or used value of calc(), gets simplified down

TabAtkins: at that point, you remove the calc() wrapper if simplifies down to a single component

TabAtkins: This behavior doesn't happen in TypedOM

s/?/computed/

TabAtkins: it retains the calc() wrapper

TabAtkins: not sure if we should try to adopt or not

TabAtkins: if particular impl concern, I don't have a strong opinion...

AmeliaBR: from authoring side, if you wanted to go in and manipulate the value in the wrapper and still have clamping effects of calc()

AmeliaBR: e.g. calc(-5px) in property that's positive values only

AmeliaBR: ...?

TabAtkins: if you set a calc() it'll get that behavior, if you set a simple numeric value it won't

TabAtkins: if you want to do math, can do it without having already wrapped in calc regardless

TabAtkins: in particular, emilio brought this up in a CSS isue

s/isue/issue/

s/...?/Where the clamping value would be different with a plain -5px. Not sure how clamping would be different in TypedOM./

emilio: I think getComputedValue is px value because can simplify away, so I think everyone should do the same

emilio: would be annoying in implemntation to maintain that information

emilio: about whethe was wrapped in calc or not

TabAtkins: ok, propose to resolve that TypedOM reifies value as simplified form

RESOLVED: TypedOM reifies values as simplified form (mirroring getComputedStyle etc.)

<br dur=10min>

Topic: end

@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.

Topic: using ObservableArray for the list-ish values in TypedOM

github: w3c/css-houdini-drafts #948

ScribeNick: fremy

TabAtkins: I tried to get better support for array-like classes in WebIDL

TabAtkins: because we have three things that expose lists, and could benefit from this

TabAtkins: but given I made no progress, I ended up using the legacy "getter/indexer" of WebIDL

TabAtkins: but sadly that means that it's not an array

TabAtkins: and you cannot use forEach etc on them

TabAtkins: you have to convert them to an array first

TabAtkins: but domenic fixed this for me

TabAtkins: and we have the observable array type

TabAtkins: for the javascript user, it looks like an array

TabAtkins: but it still triggers callbacks that allow us to type check things

TabAtkins: so I'd like to switch to that

TabAtkins: unfortunately that would result in a breaking change

TabAtkins: indeed, the value itself cannot be an array

TabAtkins: because it has to subclass the CSSValue type

TabAtkins: so we need to store the list in a "values" member

q+

TabAtkins: for the math-value types, it's easier because it's already a FrozenArray

TabAtkins: so I can just switch it

TabAtkins: any objection to do this change?

AmeliaBR: so, if I understand, you now need to do "x.values[0]" instead of "x[0]"?

TabAtkins: if I don't accomodate that by making a special behavor, yes

AmeliaBR: could we then make a putforward?

TabAtkins: yes, we definitely can

q+

TabAtkins: and we could do that by just updating the code to do that and lookup in the array

AmeliaBR: browser support?

TabAtkins: yes, typedom is shipped in chrome

TabAtkins: because paint api

AmeliaBR: I would not like to break demos

TabAtkins: yes, let's make the accomodation, it's not worth breaking the demos

AmeliaBR: (restates)

TabAtkins: (yes)

ack AmeliaBR

ack AmeliaBR

ack fremy

fremy: I'm entirely in favor

fremy: Always thought it was really weird that ? and ?? you couldn't index it

fremy: so much cleaner for the PAI

fremy: not only improvement that you get an array

fremy: definitely in favor

fremy: and ??? sounds like a no-brainer

TabAtkins: ok

s/PAI/API ?

s/??/forwarding

TabAtkins: any concern from implementers?

TabAtkins: looks like no?

s/???/forwarding

TabAtkins: any objection to adopt the change in the issue, with forwarding kept in?

RESOLVED: put the list in a "value" property, and add a forwarding for compat

Topic: ban data: url worklets

github: w3c/css-houdini-drafts #985

TabAtkins: next topic comes from Ana Tudor

s/Ana Tudor/Anne VK/

s/Ana Tudor/AnneVK/

vK

TabAtkins: you initialize a worklet by passing a url

TabAtkins: you can do that using a data url to avoid using the network

TabAtkins: annevk says that this can be an issue

TabAtkins: for security reasons

TabAtkins: blob urls would still work

TabAtkins: but data urls apparently have some issue

TabAtkins: any comment?

AmeliaBR: can we add a note showing how to use a blob url?

TabAtkins: why not?

TabAtkins: any suggestion?

RESOLVED: ban data url from spanning a worker

s/spanning/spawning/

Topic: make P&V API descriptors optional

github: w3c/css-houdini-drafts #994

AmeliaBR: with the at-property rule shipping, people started taking a look

AmeliaBR: there were complaints that all the fields have to be explicit

AmeliaBR: and this is not very css-y

AmeliaBR: in general, css does handle defaults better

AmeliaBR: and by making all these things be required, you remove some behaviors

AmeliaBR: reasons why people use this

AmeliaBR: - transition values

AmeliaBR: - prevent inheritance

AmeliaBR: - provide default value

AmeliaBR: you don't always want all three

AmeliaBR: and now you have to set all of them, which is not always useful

AmeliaBR: worse, you cannot say "this is a color or it is invalid"

TabAtkins: that default value thing is a different issue

TabAtkins: I agree we should fix this

TabAtkins: the other two cases

TabAtkins: the inheritance one is that in JS, true has a default value is not logical

TabAtkins: and we don't want to default to inheritance, because this is more costly

TabAtkins: but having the default be the revert of the normal choice is confusing

TabAtkins: so, we think forcing people to think about this is good

TabAtkins: I think that issue is well settled, we really want to keep this in

TabAtkins: for the syntax, we could use the unrestricted syntax "*" as a default

TabAtkins: but I don't think that this is what you want

TabAtkins: because it cannot do anything useful for you with this syntax

TabAtkins: if we make this required, authors get an error, and they learn about this

TabAtkins: and they realize they could have a better behavior

q?

TabAtkins: and "*" is not that common so I don't think it will be common enough to warrant the default

TabAtkins: and there are other places in css where we force people to specify a value even if we have an obvious default

TabAtkins: like for example fonts

TabAtkins: we force you to say "serif" as fallback

TabAtkins: even though it could be implied

TabAtkins: but we thought forcing people to think about the fallback is useful

AmeliaBR: you said that throwing an error makes more sense

AmeliaBR: but in the non-declarative syntax, this works differently

emilio: there are browsers where you can see CSS errors

emilio: ;-)

TabAtkins: I think this information is surfacable

TabAtkins: if some browsers have a less-than-useful way of surfacing this, we can fix

TabAtkins: but I still think "hey this doesn't work" is better than making it work less well

TabAtkins: AmeliaBR do you feel about this strongly?

AmeliaBR: not a huge deal I guess, won't object

AmeliaBR: however, I think that the solution to the other issue is very important

TabAtkins: yes, that's another issue, and there is another thread about that, and I think we are in agreement with what you wanted?

AmeliaBR: can you send a pointer?

TabAtkins: yes, issue ???

TabAtkins: so, it sounds like we should be able to resolve to close this issue no change for now

TabAtkins: any final objection?

RESOLVED: keep all fields in @property required

Topic: end

Topic: drafts

Rossen___: we have lots of specs that are outdated and needs republishing

Rossen___: and most are just working drafts

Rossen___: so republishing should be easy

Rossen___: for example worklets

Rossen___: no republication since 2016

Rossen___: we only have one editor, iank_

Rossen___: and that is probably not a focus of his to update specs

Rossen___: so, can we get another editor?

Rossen___: also, what other things do we need to do in worklets?

Rossen___: because if not, can we get this to CR?

Rossen___: (or, we merge it with html)

florian: I think we should update the working draft

florian: irrespective of whether we want to merge

florian: it only takes a few minutes to do

Rossen___: there are a few issues in this spec

Rossen___: but not much

Rossen___: TabAtkins, anybody else could help contribute to this spec?

TabAtkins: I'm not sure

TabAtkins: ??? worked in web audio

TabAtkins: which use some aspects of worklets

TabAtkins: but not sure if there's desire to become editor

chris_: there are also folks at mozilla implementing it

Rossen___: who?

paul adenot, mozilla

chris_: I'll type it in when I find

AmeliaBR: handing it over to the spec that explains the window context makes sense

s/???/Raymond Toy

AmeliaBR: but I think updating the publication before sounds useful

RESOLVED: Update the worklet spec working draft

Rossen___: we also need to republish layout paint typedom

Rossen___: properties and values are ok though

fantasai: can we talk about grid in the last few minutes?

Rossen___: yes, we dont need resolutions for the others

Topic: grid

Rossen___: we need to publish a new CR

fantasai: yes, we have DoC, tests for changes, etc...

fantasai: and there is a lot of them, so we should really update

fantasai: there are a few issues left over for the next revision

fantasai: oriol said it would be ok to republish

fantasai: and I support

oriol: (confirms)

Rossen___: any objection to republish CR of Grid L1 with these changes?

RESOLVED: update the CSS Grid L1 CR

Topic: end of the meeting ^_^

+1

Zakim, end meeting

jensimmons: Do you still have a link to the cascade layers slides you presented back in Jan?

I couldn't find them in the minutes.

I do. Just a sec.

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.

jensimmons: Can you send a copy to www-archive⊙wo?

gregwhitworth: Need a PDF attachment of your slides to www-archive, not just a link. The whole point is to get it archived. :)

Is there something I can do as a non-member to make IPR commitments so that my PRs do not get failure checks? Ref: w3c/csswg-drafts #5377

JonathanNeal: I'm sure there is, but I'm not sure what.

JonathanNeal: Chris Lilly or xfq would know

TabAtkins: If you approve w3c/csswg-drafts #5377 I will merge it

JonathanNeal: merged

fantasai-stic! 🎉

TabAtkins: Filed the CR update request! w3c/transitions #258

fantasai: nice!

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...

yay tests!

That brought up the interesting case of 'auto min-content'

when min-width < min-content, the auto column gets smaller than the min-content column...

kinda weird

not sure that's expected

m%3A%20solid%20teal%22%3E%3C%2Fspan%3E

...

anyway