[CSSWG] Minutes Virtual F2F 2020-07-31 Part I: CSS Pseudo Elements, CSS Inline 3, CSS Layout API [css-pseudo] [css-inline-3] [css-layout-api]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Pseudo Elements

  - RESOLVED: Spaces separating punctuation from first letter don't
              interrupt ::first-letter (Issue #5154: ::first-letter
              should include space separators)

CSS Inline 3

  - RESOLVED: Accept the addition of the terms with the current
              proposed definitions. (Issue #5312: Define em-top and
              em-bottom baselines)
  - RESOLVED: When 'over-sunk', an initial-letter is aligned with the
              top metrics instead. (Issue #5329: Initial-letter
              alignment when 'over-sunk')

Houdini: CSS Layout API

  - There was general interest in further pursuing a string based
      inline layout API (Houdini Issue #990) so discussions will
      continue outside the call. There were also some concerns about
      accessibility and internationalization/character mapping that
      will need to be addressed for this to be successful.
  - RESOLVED: Any Houdini JS that needs to run for style / layout calc
              needs to run for print (Houdini Issue #978: Print
              Behavior and Test Requirements)


Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#friday

  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos Álvarez, Mozilla
  Elika Etemad, Invited Expert
  Simon Fraser, Apple
  Megan Gardner, Apple
  Daniel Holbert, Mozilla
  Koji Ishii, Google
  Brian Kardell, JS Foundation
  Jonathan Kew
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Alison Maher, Microsoft
  Tess O'Connor, Apple
  François Remy, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, IBM
  Devin Rousso, Apple
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: TabAtkins
Scribe's Scribe: fantasai

CSS Pseudo Elements

::first-letter should include space separators
  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 languages,
            because 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
          punctuation, 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
          punctuation 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
            punctuation 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.
  <astearns> there is also https://github.com/w3c/csswg-drafts/issues/4988
             for changing size of components of initial-letter

  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.
  fantasai: As astearns said, 2040 is about the formatting question if
            you want the punctuation and letter different.
  fantasai: Richard said we didn't need to include U+0020 space,
            because the spaces used here are typically other spaces,
            not the standard word separator.
  fantasai: So if we're really concerned, we can exclude U+0020 and
            only include the other spaces.
  fantasai: And note that the punctuation by itself won't 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 standard space
  AmeliaBR: But probably the more exotic spaces can be ignored.
  <fantasai> Anyone who's fussy about typography will use the correct
             space, I think :)
  AmeliaBR: The one common thing from tantek's examples, and some in
            the issue, where the initial punctuation 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.
  AmeliaBR: If we don't come up with a special solution for people who
            want the punctuation to be offset or smaller, there's
            always the option of people including spans to mark off
            certain characters.

  <tantek> if I paste this here does it work?

  florian: Good guides about typography will say to use various
           spaces, but most people don't know how to type those.
  florian: At least in French, it's pretty common to say ordinary
           spaces, probably same in Norwegian. So I'd include standard
  <astearns> I think we should allow the regular space, even though
             I'm fussy about typography

  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 punctuation-space-letter, maybe the letter
          itself should be the only thing included as the
          ::first-letter, and the punctuation gets normal inline
  tantek: That would look closer to the 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, like the way large text
          messes up the line rhythm.
  tantek: So I'm concerned if we add one more papercut.
  tantek: 5154 shows what browsers are currently doing
  tantek: There's an example with the leading quote... [missed]

  <chris> so now we need a term for "the characters before the first
          actual letter"?
  <fantasai> chris, we need a pseudo-element, yes :)
  <chris> ::first-letter-before

  <astearns> in the examples provided for this issue, the punctuation
             *does* take the same styling as the letter:

  fantasai: I think tantek is getting caught up in the not-perfect
  fantasai: I think you're forgetting that English and French
            punctuation 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 and doesn't solve those
            problems anyway
  florian: Having ::first-letter select the letter and not the
           preceding punctuation seems bad, 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
  <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 won't want the punctuation large, but
           those apply equally to the existing punctuation-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
  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.

  Rossen: So I think there were several reasons for having this,
          including some existing shipping impls
  Rossen: So it's probably not a compat risk, or at least not a big

  <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: I don't actually see the Safari example as proof of no
          compat problem
  tantek: Safari applies all the punctuation 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 wouldn't surprise me if people are already not giving
          that styling to Safari to avoid that problem.
  astearns: Also in Chrome
  tantek: Ok. So that's a bug, and I don't think we should be
          designing based on a bug.
  florian: We're not saying it's a bug, we're saying it's desirable.
  <fantasai> If the compat problem isn't a concern can we just fix
             this and move on?
  tantek: I'm talking just about the hyphen.
  tantek: Because of that I think authors might be picking different
          techniques. So maybe we don't 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 should 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
  tantek: They're both ::first-letter
  [back and forth]
  <astearns> +1 to resolving on this now

  TabAtkins: Today, a single quote and no space, will be combined
  TabAtkins: and the quote won't be sized "correctly" in that case
  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 punctuation from first letter don't stop

CSS Inline 3

Define em-top and em-bottom baselines
  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 have a section in css-inline which defines a bunch of
            these metrics, noting their opentype equivalents
  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 don't
            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 definition
  <fantasai> fontBoundingBoxAscent/Descent
  fantasai: Those map to our ascent/descent
  <fantasai> emHeightAscent/Descent
  fantasai: Then there's the em height ascent/descent, which doesn't
  <fantasai> "highest top of the em squares in the inline box"
  fantasai: Which don't have a definition in HTML; the definition 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
  <AmeliaBR> +1 for keeping all definitions in one place

  fantasai: I talked to jfkthame about what he thinks the metric
            should be
  fantasai: Idea is [in the issue]
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5312#issue-654391546
  <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 don't use the actual size, but use the proportions?
  faceless2: Lots of fonts don't have these metrics add up to 1, so
             normalizing is important
  AmeliaBR: So looks like midpoint of ascent/descent, then .5em both
  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 about it
  koji: They'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
  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-like apps
  Rossen: So more and more need doing higher-fidelity typography thru
  iank: The exact use-cases are basically "everything you can 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 definition solving what's
  AmeliaBR: I don't know, because 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/
  fantasai: Yeah, not always. 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 most 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
  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
        undefined 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
  koji: we probably need more heuristic investigations
  koji: In canvas we don't have font cascading, right?
  AmeliaBR: Canvas does do font fallback like CSS does.

  Rossen: So looking for progress.
  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 definitions, and note
            we don't plan to use them in CSS.

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

  <br dur=15m>

Initial-letter alignment when 'over-sunk'
  github: https://github.com/w3c/csswg-drafts/issues/5329

  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, fantasai 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 the
  fantasai: But when size < sink, we align to the top metric so we're
            pulling up
  florian: And the initial definition just only considered one case
           and we forgot the second half?
  fantasai: pretty much
  Rossen: Any other opinions?

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

Houdini: CSS Layout API
  Scribe: fantasai
  Scribe's Scribe: TabAtkins

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> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md
  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,
  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
  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
  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
  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
  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
  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 work
  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,
            though, right?
  sushanth: true
  sushanth: Some other issues also?
  <AmeliaBR> This is similar to how the SVG API works: multiple
             characters will match to the same glyph box

  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

  fantasai: Just wanted to say, I echo concerns about getting i18n
  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
  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 people using the API
  fremy: Draw on the canvas, put this in the DOM, and gets updated
  fremy: enables selection, a11y, etc. everything to work
  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 this
  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 iank 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

  fantasai: Heard 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/
  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

  Myles' comments on designing text APIs, see all of “Houdini <3 Text”:

Print Behavior and Test Requirements
  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
  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: you 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

  sushanth: For printing, I work on canvas so I know how it works for
  sushanth: There's an 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
  emilio: we fire before print 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
  <smfr> we should probably specify when houdini js runs

  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
  iank: So on Chromium project to add support reftests of that form
  iank: Testing strategy should be no different from other printing

  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: definitely 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 reftests
  iank: First half of next year will be focusing solely on printing,
  iank: will add a lot more reftests
  iank: Will work on supporting print reftests in chromium at the same
  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 asynchronous?
  TabAtkins: Nope. Very intentionally

  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


  fantasai: Layout API hasn't been published since 2018, and I'm
            guessing edits have happened since then
  Rossen: Yes Ian and I both attempted to publish this and both failed
  fantasai: If you have mechanics issues, can you get a staff contact
            to help?
  Rossen: Yes.
  <astearns> apparently houdini js is failing to run on a publishing

<break type=long>

Received on Sunday, 16 August 2020 12:04:51 UTC