- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 08:03:55 -0400
- To: www-style@w3.org
- Cc: public-houdini@w3.org
=========================================
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)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#friday
Present:
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?
https://github.com/w3c/csswg-drafts/issues/2040
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
space.
<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
styling.
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:
https://github.com/w3c/csswg-drafts/issues/5154#issuecomment-659129316
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
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 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
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.
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
one.
<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
languages.
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
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 punctuation from first letter don't stop
::first-letter
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
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 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
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-like apps
Rossen: So more and more need doing higher-fidelity typography thru
canvas
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
needed?
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/
descent.
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
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
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
position.
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
definitions.
<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
paragraph
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,
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: 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
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 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/
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
Myles' comments on designing text APIs, see all of “Houdini <3 Text”:
https://lists.w3.org/Archives/Public/www-style/2019May/0011.html
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
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: 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
expectation
sushanth: For printing, I work on canvas so I know how it works for
Canvas
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
printing
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
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: 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,
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 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
Publishing
----------
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
step
<break type=long>
Received on Sunday, 16 August 2020 12:04:50 UTC