Meeting minutes
<fantasai> good morning heycam|away !
<fantasai> or afternoon or whtaever
<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...
<dholbert> faceless2, doing that same thing worked for me FWIW
Should ::first-letter include space separator?
<Rossen_> github:https://github.com/w3c/csswg-drafts/issues/5154
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
tantek: Ok [shows an example in English too]. Maybe we should consider these issues together.
<fantasai> It's issue 2040
astearns: I'll drop it in the minutes.
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.
<astearns> there is also https://github.com/w3c/csswg-drafts/issues/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.
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.
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
AmeliaBR: But probably the more exotic spaces can be ignored.
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.
<fantasai> 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.
<Zakim> florian, you wanted to comment on U+0020
<tantek> if I paste this here does it work? https://github.com/w3c/csswg-drafts/issues/2040
florian: Good guides about typography will say to use various spaces, but most people dont' know how to type those.
<astearns> 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.
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.
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.
<chris_> 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.
<fantasai> chris_, we need a pseudo-element, yes :)
tantek: 5154 shows what browsers are currently doing
tantek: There's an example with th eleading quote... [missed]
fantasai: I think tantek is getting caught up in the not-perfect
<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
<chris_> ::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
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 and doesn't solve those problems anyway, it's already complicated, sounds scary.
florian: As to compat, Safari does it already. So there's some amount of content out there probably already depending on it.
<florian> http://www.typografi.org/dropcaps/assets/sitatstrek-anf%C3%B8rselstegn_714.jpg
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.
<fantasai> TabAtkins: Florian touched on it at the end, one of the big concerns Tantek brought up
<fantasai> TabAtkins: is wanting to address differently-sized punctuation wrt first-letter
<fantasai> TabAtkins: But that's already the case. If there's no space, we already have that problem, already have to solve it.
<fantasai> TabAtkins: It's not relevant to this issue.
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.
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
<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?
tantek: Ok. So that's a bug, and I dont' thinkw e should be designing based on a bug.
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 out and revisit
faceless2: The big hyphen was actually a desired effect
<faceless2> http://www.typografi.org/dropcaps/assets/sitatstrek-anførselstegn_714.jpg
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.
tantek: They're both ::first-letter
[back and forth]
<astearns> +1 to resolving on this now
<fantasai> TabAtkins: Today, a single quote and no space, will be combined together.
<fantasai> 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?
Resolution: Spaces separating punct from first letter dont' stop ::first-letter
Define em-top and em-bottom baselines
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/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> https://drafts.csswg.org/css-inline-3/#baseline-types
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> https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent
fantasai: So I propose we include that
<fantasai> fontBoundingBoxAscent/Descent
fantasai: Those map to our ascent/descent
<fantasai> emHeightAscent/Descent
fantasai: Then there's the em height ascent/desent
<fantasai> "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
<AmeliaBR> +1 for keeping all definitions in one place
<fantasai> https://github.com/w3c/csswg-drafts/issues/5312#issue-654391546
fantasai: Idea is [in the issue]
<fantasai> Proposed definition from me and @jfkthame is:
<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)
<fantasai> 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
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.
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.
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.
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?
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 [sTypo] ascent/descent, we use that for underline position.
koji: we probably need more heuristic investigations
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.
<castastrophe> 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.
<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
Resolution: Accept the addition of the terms with the current proposed definitions.
<br dur=15m>, right?
end
initial-letter alignment with over-sunk letter
<Rossen_> github:https://github.com/w3c/csswg-drafts/issues/5329
<smfr> 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?
Resolution: When 'over-sunk', an initial-letter is aligned with the top metrics instead.
end
Houdini Layout
String based inline layout API
<Rossen_> 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_> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md
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
Rossen_: and I wanted to essentially turn this into a question and ask, does it seem like a reasonable API?
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.
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
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
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
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?
iank_: no reason they should be different
sushanth: Motivation was apps, like photoshop / excel
sushanth: API was trying to give them ability to do multiline text
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
sushanth: I think last question, selection / background / borders missing from this API
sushanth: with metrics can implement this
sushanth: in JS
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
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
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
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
sushanth: They'll all have the same advance value
sushanth: advance = position from the start
jfkthame: That won't be any different than a zero-width character right?
<AmeliaBR> 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 text layout to other things like Canvas and SVG
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
<Zakim> fantasai, you wanted to ask us to get Myles's opinion before signing off on anything like this
fantasai: Just wanted to say, I echo concerns about getting i18n right.
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 access the DOM directly
fremy: So that's why don't want to take something from the DOM and draw it
fremy: describes an export from this API to a DOM fragment
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
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
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
<sushanth> thank you Ian, happy to follow up. :D
fantasai: bidi, lang-tagging or markup for change in formatting, selection, a11y, character to glyph mapping ...
fantasai: justification? would it be possible?
sushanth: canvas has some some text justification, has just left/right/center
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
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]
Print Behavior and Test Requirements
<Rossen___> github: https://github.com/w3c/css-houdini-drafts/issues/978
github: https://github.com/w3c/css-houdini-drafts/issues/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?
TabAtkins: print style can change sizes of things
TabAtkins: have to run custom paint and custom layout
TabAtkins: are we doing something with that?
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
TabAtkins: but aren't running JS
iank_: These particular things, we should be running any layout API JS
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 onBeforePrint event, and you do stuff, and that gets replayed
sushanth: when you print, those recordings are played back
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
AmeliaBR: Houdini isn't part of event loop, it's triggered by style recalc directly
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
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 ref tests
iank_: first half of next year will be focusing solely on printing, effectively
iank_: will add a lot more reftests
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
fantasai: Layout API hasnt' been published since 2018, and I'm guessing edits ahve happened since then
<fantasai> 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> fantasai: If you're getting stuck, ask the staff contacts for help
<fantasai> TabAtkins: let's record a resolution
<fantasai> TabAtkins: Any houdini JS that needs to rerun for style / layout recalc needs to run
Resolution: Any Houdini JS that needs to run for style / layout calc needs to run for print
Break
<fantasai> <br end="??:25">
<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
Color Conversion and Contrast Ratio
<astearns> github: https://github.com/w3c/css-houdini-drafts/issues/989
<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
<fantasai> Rossen___: This issue motivated by TAG review about addition of lch and lab color spaces
<fantasai> Rossen___: One concern being discussed being discussed with TAG was that we were getting more variety of color across platform
<fantasai> Rossen___: but capabilities of simple things like contrasting two colors is very difficult
<fantasai> Rossen___: One of the ideas was, hey, if we have a strongly defined type of color that we can use across platform
<fantasai> Rossen___: then we could look at exposing variety of functions either on or around object
<fantasai> Rossen___: and achieve objectives like a11y and other things
<fantasai> Rossen___: Seemed like TypedOM is good place to start
<fantasai> Rossen___: Color is a type we need to define strongly
<fantasai> Rossen___: Luckily Lea and Chris jumped in, had been thinking about it
<fantasai> ?: ??
<fantasai> chris_: in color 4 there was an appendix written in JS by which I mean Pascal
<fantasai> chris_: It's simple, does work, set of simple functions
<fantasai> chris_: Also have utilities.js
<fantasai> chris_: includes a contrast function
<fantasai> chris_: Here's an sRGB_to_LCH
<fantasai> chris_: it does it all in the right order
<fantasai> chris_: It was useful for examples
<fantasai> chris_: and useful for color 5
<fantasai> chris_: but this is not a proposal for a color model
<fantasai> chris_: not object oriented
<fantasai> chris_: it's just something that wroks
<fantasai> chris_: Here's color.js
<fantasai> chris_: Until this morning was a private repo, now public
<leaverou> https://colorjs.io/
<fantasai> chris_: also not a proposal, but it's object oriented
<fantasai> chris_: This is a JS API, you can use it in the browser or on the server
<fantasai> chris_: These examples are all live, you can edit directly in the web page if you want
<fantasai> chris_: variety of color models, includes all in color 4 (except device-cmyk()) as well as a few more
<fantasai> leaverou demos
<fantasai> chris_: Notice these are in different color spaces
<fantasai> chris_: Internally it goes into CIEXYZ, and then ??, and then gets you a contrast
<fantasai> chris_: You just say you want contrast between two colors, and it just works out for you
<fantasai> chris_: You can change lightness or chroma or whatever
<fantasai> chris_: similar to things we do in Color 5
<fantasai> chris_: Convert between color spaces
<fantasai> chris_: interpolate between colors
<fantasai> chris_: either discreet steps, or gradients, or that sort of thing
<fantasai> chris_ reviews documentation
<fantasai> chris_: Color object. Can give a CSS string or use initializer with coordinates
<fantasai> leaverou: color space ID plus coordinates plus optional alpha
<fantasai> leaverou: or another Color
<fantasai> chris_: This is similar to color-5, adjusting named coordinates
<fantasai> chris_: We've actually supported more than Color 4 supports
<fantasai> chris_: might be interesting to see if any would be useful as future additions
<fantasai> chris_ notes there's bugs, especially in the documentation, since this is pre-release
<fantasai> chris_: You can change color coordinates. Don't even have to change coordinates of the color space you're in
<fantasai> chris_: That's fairly useful
<fantasai> chris_: We also do gamut-mapping
<fantasai> chris_: because easy to get colors that are out of gamut
<fantasai> chris_: we've worked on that quite a bit, have an algo that works rather well
<fantasai> chris_: Do a binary search to find closest color via chroma reduction
<fantasai> chris_: and do speculative clipping
<fantasai> chris_: 1st one we reduce chroma until it's inside the range
<fantasai> chris_: 2nd one, at each stage, we see if we clipped here, would we be close?
<fantasai> chris_: and that works much better
<fantasai> chris_: thinking to spec that in color-4 spec
<fantasai> chris_: Interpolation
<fantasai> chris_: range function allows that and getting intermediate stops
<fantasai> leaverou: range function actually returns a function
<fantasai> leaverou: we can specify which space to do interpolation in
<fantasai> leaverou: you can see here examples of what each interpolation space produces
<fantasai> leaverou: we also implemented longer/shorter/increasing/decreasing args for the hue we were discussing
<fantasai> leaverou: although didn't implement dbaron's ? yet
<fantasai> chris_: Lets us implement and check and see if it works. Very helpful in writing spec
<fantasai> chris_: Also discussing using Nan for keeping coord constant
<fantasai> leaverou: but we do keep Nan for chroma
<fantasai> chris_: It's on GH and there's a link, and also a bunch of tests
<fantasai> chris_: any questions at this stage?
<fantasai> Rossen___: First of all, this is awesome, thanks for sharing
<fantasai> Rossen___: Looking forward to playing with the project
<fantasai> Rossen___: that's exactly what I was hoping to see
<fantasai> Rossen___: and you made this fantastic
<fantasai> Rossen___: Wrt functions like color-mix() etc.
<fremy> big +1 this is super great!
<fantasai> Rossen___: let's say we start going towards adopting such a type in TypedOM, where does that leave us?
<fantasai> chris_: You'll have 2 ways to do it: declarative in color-5, and imperative way like this
<fantasai> chris_: imperative can have more functionality
<fantasai> chris_: I don't think it's a problem that we have both declarative and imperative
<fantasai> leaverou: ?
<fantasai> leaverou: haven't done adjusters yet
<fantasai> leaverou: accepts a color space as well, but not adjusters
<fantasai> chris_: As general goal, would like to implement all of color-5 so we can test, and do example, see how that works
<fantasai> chris_: Another thing ppl might have noticed, there's a few more color spaces here not in color 4
<fantasai> chris_: support high dynamic range coors
<fantasai> chris_: there's a secret spec called css-color-hdr
<fantasai> chris_: there was an issue around high dynamic range
<fantasai> chris_: I said we won't do it, because too unstable
<fantasai> chris_: but I did spec an extension to color-4
<fantasai> chris_: and wanted to see that it works and coded it up
<fantasai> chris_: I presented to ICC and got good feedback, currently incorporating that
<fantasai> chris_: will present to the WG later
<fantasai> chris_: in the meantime, i'm incubating it in code to see whether it's feasible
<florian> https://drafts.csswg.org/css-color-hdr/
<leaverou> https://drafts.csswg.org/css-color-hdr/
<fantasai> AmeliaBR: Great library, very useful. Some similar things, but this is a nice APi with good features
<fantasai> AmeliaBR: Wrt what we should adopt into the actual Web platform
<fantasai> AmeliaBR: I do like the idea of having general color utilities object
<fantasai> AmeliaBR: That you can call without having to getComputeStyle
<fantasai> AmeliaBR: coordnate with TypedOM also good
<fantasai> AmeliaBR: so you can construct CSS color type or get it from a style rule or a computed style
<fantasai> AmeliaBR: that would be great design
<fantasai> AmeliaBR: Probably don't want quite as many features as we have in this library
<fantasai> AmeliaBR: Might want to integrate a bit more e.g. generated gradients
<fantasai> AmeliaBR: and easing function would be its own object, to use more generally than just color
<fantasai> AmeliaBR: Interpolator for data vis
<fantasai> AmeliaBR: would be a great feature, use native interpolation that CSS already knows how to do
<fantasai> AmeliaBR: with additional smarts like interpolating in different color spaces
<fantasai> AmeliaBR: also useful to have
<fantasai> astearns: Anything else besides showing new cool code?
<fantasai> Rossen___: How do you see this moving forward?
<fantasai> chris_: Requirements, one of them for web platform API
<fantasai> chris_: what features do we want, what would be nice, what would be layered on top
<fantasai> chris_: Rossen asked about contrast, that's important
<fantasai> chris_: Converting between color spaces without having to understand how it does
<fantasai> chris_: not knowing about white points, not having to figure that out, that's important
<fantasai> leaverou: There should also be way to access color before / after gamut mapping because that affects the results
<fantasai> AmeliaBR: Especially important for finding contrast ratio
<fantasai> AmeliaBR: if colors are theoretically good contrast, but not on user's screen, need to reflect that
<fantasai> florian: So is the plan to subset your project into TypedOM? and then build your project on top of that result?
<fantasai> chris_: would be reasonable
<fantasai> astearns: If you can't build on top of the subset, then we chose the wrong subset
<fantasai> Rossen___: That was part of my hope
<fantasai> Rossen___: exactly why I was provoking this type of discussion and exposure in typed OM space
<fantasai> Rossen___: Anything else left on color that you didn't cover?
<fantasai> leaverou: ICC profiles
<fantasai> leaverou: in theory, TypedOM should cover that as well
<fantasai> leaverou: but wouldn't that make it asynchronous?
<fantasai> TabAtkins: We already have a few things that need external resources, don't have a great way to handle that
<fantasai> TabAtkins: but nothing else needs to be infected, just wait for them via Promise
<fantasai> chris_: Mentioned that we have a lot of stuff. Because we wanted to test things against each other
<fantasai> chris_: e.g. deltaE, implemented 5 different variants
<fantasai> chris_: wanted to compare visual result, perf
<fantasai> faceless2: ...
<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
<fantasai> florian: don't necessarily need all the operations to get from one color to another color
<fantasai> florian: maybe need ? and ?, but methods to get between them, but TypedOM doesn't need
<fantasai> chris_: Do need an intermediate way to go between colors
<fantasai> chris_: you use colors together, not in isolation
<fantasai> AmeliaBR: Base case would be converting single color into other color spaces
<fantasai> AmeliaBR: so you can convert two colors into the same color space in order to compare or calculate
<fantasai> AmeliaBR: Devs can implement the formulas that use whatever paramterization of colors that they need
<fantasai> chris_: yep
<fantasai> Rossen___: I agree
<fantasai> Rossen___: that was initial motivation here, exposing the type that will allow you to at least hoist the color space and its values
<fantasai> Rossen___: having this type, you can start adding libraries around it that do a bunch of math
<fantasai> Rossen___: as we go forward, can identify which math goes into native platform and which stays as library
<fantasai> Rossen___: but not having basic type is a blocker
<fantasai> Rossen___: My hope and ask for you, is to start defining what this type should look like
<fantasai> Rossen___: what is minimum set of parameters and stuff
<fantasai> Rossen___: I see Tab and fremy still editing TypedOM, so work with them to move it forward
<fantasai> fantasai: I want to note that Typed OM has also not been published since 2018.
Concern about attributeStyleMap updating the style attribute
github: https://github.com/w3c/css-houdini-drafts/issues/997
<fantasai> TabAtkins: I'm not sure if this is an actual concern to worry about
<fantasai> TabAtkins: wanted impl advice
<fantasai> TabAtkins: when doing high-frequency updates, like during TypedOM
<fantasai> TabAtkins: use single transform object, setting over and over again
<fantasai> TabAtkins: but are seeing the style attr get updated in real time as well
<fantasai> TabAtkins: so reserialization happening constantly as well
<fantasai> TabAtkins: we saw as a perf concern
<fantasai> TabAtkins: So is this actually causing trouble?
<fantasai> TabAtkins: person seems to believe causing perf issues, I'm not sure myself
<fantasai> TabAtkins: but if we are eagerly reserializing to style attr, not great. Negates a major advantage of TypedOM
<fantasai> TabAtkins: Apparently we don't forwarding
<fantasai> TabAtkins: but if you look in inspector, do see it being constantly updated
<fantasai> TabAtkins: But either way..
<fantasai> emilio: Mutation observer thing, it should fire mutation observer callbacks exceptin some cases
<fantasai> emilio: afaict, internally we don't serialize until asked for
<fantasai> emilio: if that's devtools, then we reserialize all the time
<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
<fantasai> fremy: meaning?
<fantasai> TabAtkins: browsers aren't eagerly serializing
<fantasai> iank_: file a bug against Chrome? we should investigate this
<fantasai> TabAtkins: apparently Chrome doesn't fire mutation events
<fantasai> TabAtkins: that's a bug in chrome
<fantasai> fremy: Because we still want to update the style attr, every single time
<fantasai> fremy: can we put something in the spec that says when?
<fantasai> AmeliaBR: it's on demand
<fantasai> TabAtkins: when someone asks for it, or is observing the style attr
<fantasai> fremy: so flag it?
<fantasai> fremy: ok
<fantasai> TabAtkins: sounds like the resolution should be, browsers should be smart enough to lazily serialize style attr when necessary
<Zakim> fantasai, you wanted to suggest a note in the spec
<fantasai> TabAtkins: I can put a note in the spec
<fantasai> AmeliaBR: One thing to consider, should this be a general thing for DOM attributes reflected?
<fantasai> AmeliaBR: working with CSSOM or other things to be consistent?
<fantasai> TabAtkins: yeah.....
<fantasai> TabAtkins: existing string OM, not doing any restringifying, but sure there are some reflected attrs
<fantasai> TabAtkins: in HTML... I'll check if HTML has wording on that
Action: TabAtkins investigate restringification of reflected attrs across OMs
<fantasai> fremy: Not always the user that gets the style attr
<fantasai> fremy: e.g. if you have a selector that depends on the style attribute's contents
<fantasai> fremy: Should never happen. Shouldn't change the DOM when recomputing CSS
<fantasai> TabAtkins: DOM has it internally tracked, doesn't need to update everything to keep consistent except on demand
<fantasai> emilio: style attr keep not a string, but a CSS declaration and an attached string
<fantasai> emilio: when request string, we serialize it
<fantasai> emilio: Someon requests DOM attr, will get the correct value
<fantasai> smfr: Normally we don't specify internal details
<fantasai> smfr: Would just be a QoI issue about when serialization happens
<fantasai> smfr: Spec shouldn't say anything, should just specify web-exposed behavior
<fantasai> TabAtkins: agree
<fantasai> TabAtkins: I will close no change, review HTML to see if they have any particular wording
<fantasai> AmeliaBR: only other thing is to make sure wording is clear wrt event hooks
<fantasai> AmeliaBR: should trigger mutation observers even if not serialized until asked for
<fantasai> 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
Simplifying away calc() wrappers around single numeric values when reifying
github: https://github.com/w3c/css-houdini-drafts/issues/968
<fantasai> TabAtkins: If serializing computed or used value of calc(), gets simplified down
<fantasai> TabAtkins: at that point, you remove the calc() wrapper if simplifies down to a single component
<fantasai> TabAtkins: This behavior doesn't happen in TypedOM
<fantasai> TabAtkins: it retains the calc() wrapper
<fantasai> TabAtkins: not sure if we should try to adopt or not
<fantasai> TabAtkins: if particular impl concern, I don't have a strong opinion...
<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()
<fantasai> AmeliaBR: e.g. calc(-5px) in property that's positive values only
<fantasai> AmeliaBR: Where the clamping value would be different with a plain -5px. Not sure how clamping would be different in TypedOM.
<fantasai> TabAtkins: if you set a calc() it'll get that behavior, if you set a simple numeric value it won't
<fantasai> TabAtkins: if you want to do math, can do it without having already wrapped in calc regardless
<fantasai> TabAtkins: in particular, emilio brought this up in a CSS issue
<fantasai> emilio: I think getComputedValue is px value because can simplify away, so I think everyone should do the same
<fantasai> emilio: would be annoying in implemntation to maintain that information
<fantasai> emilio: about whethe was wrapped in calc or not
<fantasai> TabAtkins: ok, propose to resolve that TypedOM reifies value as simplified form
Resolution: TypedOM reifies values as simplified form (mirroring getComputedStyle etc.)
<br dur=10min>
end
<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.
using ObservableArray for the list-ish values in TypedOM
github: https://github.com/w3c/css-houdini-drafts/issues/948
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> https://heycam.github.io/webidl/#idl-observable-array
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
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
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)
<fantasai> fremy: I'm entirely in favor
<fantasai> fremy: Always thought it was really weird that ? and ?? you couldn't index it
<fantasai> fremy: so much cleaner for the API ?
<fantasai> fremy: not only improvement that you get an array
<fantasai> fremy: definitely in favor
<fantasai> fremy: and forwarding? sounds like a no-brainer
TabAtkins: ok
TabAtkins: any concern from implementers?
TabAtkins: looks like no?
TabAtkins: any objection to adopt the change in the issue, with forwarding kept in?
Resolution: put the list in a "value" property, and add a forwarding for compat
ban data: url worklets
<TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/985
TabAtkins: next topic comes from Anne VK
<fremy> s/Ana Tudor/AnneVK/
<TabAtkins> 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?
Resolution: ban data url from spawning a worker
make P&V API descriptors optional
<TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/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
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 ???
<astearns> https://github.com/w3c/csswg-drafts/issues/5370
TabAtkins: so, it sounds like we should be able to resolve to close this issue no change for now
TabAtkins: any final objection?
Resolution: keep all fields in @property required
end
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: Raymond Toy 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?
<chris_> 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
AmeliaBR: but I think updating the publication before sounds useful
Resolution: 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
grid
<fantasai> https://drafts.csswg.org/css-grid-1/#changes
Rossen___: we need to publish a new CR
fantasai: yes, we have DoC, tests for changes, etc...
<fantasai> https://drafts.csswg.org/css-grid-1/issues-cr-2017
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?
Resolution: update the CSS Grid L1 CR
end of the meeting ^_^
<florian> +1
<TabAtkins> jensimmons: Do you still have a link to the cascade layers slides you presented back in Jan?
<TabAtkins> I couldn't find them in the minutes.
<jensimmons> I do. Just a sec.
<jensimmons> https://talks.jensimmons.com/QOEOYT/three-topics-for-jan-2020-csswg-meeting#srFUYHC
<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.
<fantasai> jensimmons: Can you send a copy to www-archive@w3.org?
<fantasai> gregwhitworth: Need a PDF attachment of your slides to www-archive, not just a link. The whole point is to get it archived. :)
<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
<fantasai> JonathanNeal: I'm sure there is, but I'm not sure what.
<fantasai> JonathanNeal: Chris Lilly or xfq would know
<fantasai> TabAtkins: If you approve https://github.com/w3c/csswg-drafts/pull/5377 I will merge it
<fantasai> JonathanNeal: merged
<JonathanNeal> fantasai-stic! 🎉