profile
viewpoint
Daniel Holbert dholbert Mozilla Corporation California, USA Platform engineer at @mozilla, working mostly on Firefox internals for handling layout, CSS, and SVG.

bgirard/znc-cmd-notify 24

cmd notification module for ZNC

dholbert/flexbox 2

flexbox playground, built on Knockout.js

dholbert/actix-web 0

Actix web is a small, pragmatic, extremely fast, web framework for Rust.

dholbert/arewereorganizedyet.com 0

are we reorganized yet?

dholbert/book 0

The Rust Programming Language

dholbert/browser-compat-data 0

This repository contains compatibility data for Web technologies as displayed on MDN

dholbert/cargo-update 0

A cargo subcommand for checking and applying updates to installed executables

dholbert/conduit-docs 0

Documentation for Conduit applications

dholbert/css-fixme 0

A script that adds standardised equivalents to CSS declarations that uses only prefixed code

dholbert/css-houdini-drafts 0

Mirror of https://hg.css-houdini.org/drafts

issue commentwebcompat/web-bugs

www.artigianino.com - "Register now" button is misaligned

Filed: https://github.com/webcompat/web-bugs/issues/60099

softvision-oana-arbuzov

comment created time in 5 hours

issue commentwebcompat/web-bugs

www.artigianino.com - "Register now" button is misaligned

If you view the original testcase in Chrome, and use their devtools to add style="margin:0" to the <div class="row"> ancestor of the register button (to override the negative margin styling that the page has assigned to it), then Chrome changes their rendering to match us (i.e. they pull that element up to be on the right of the wide float, so that it ends up looking broken).

This is bogus, for the reasons that I laid out in my previous comment. There's no reason that increasing the margin (from negative to 0) should make the element start fitting in a tiny space.

softvision-oana-arbuzov

comment created time in 5 hours

issue commentwebcompat/web-bugs

www.artigianino.com - "Register now" button is misaligned

This seems to be a Chrome bug, related to handling a scenario with 0 space left and a negative margin.

Here's a reduced testcase: https://jsfiddle.net/dholbert/ujphfkqz/

  • Firefox renders Case 1 and Case 2 the same (placing the "A B" flex container to the right of the pink area).
  • Chrome agrees with us on Case 1 there, but they disagree with us on Case 2. They push down the flex container in case 2 (as if it doesn't fit in that case).

This is bogus. The only difference between case 1 and case 2 is that the flex container is skinnier in case 2 (it's negative width there, due to having a negative margin). So there's no reason for it to be pushed down in that case, if it fit just fine in case 1.

softvision-oana-arbuzov

comment created time in 5 hours

issue commentwebcompat/web-bugs

www3.animeflv.net - The card label is placed under the card instead of being on top of the card

@dholbert do you know if this is another case of https://bugzilla.mozilla.org/show_bug.cgi?id=1573990 ?

Seems likely, yeah.

Simple workaround that we could hypothetically suggest (and that demonstrates this is likely the bug you mentioned): the bug goes away if I add display:block to this rule from https://www3.animeflv.net/assets/animeflv/css/css.css?v=1.2.6:

.Anime>*,.Noti>*{position:relative;z-index:2}
XRaTiX

comment created time in 6 hours

issue openedw3c/csswg-drafts

[css-contain-2] Spec is unclear about whether 0-sized boxes can be "relevant to the user" (since they have zero intersection area)

The "relevant to the user" ( https://www.w3.org/TR/css-contain-2/#relevant-to-the-user ) condition is defined as-follows:

An element is relevant to the user if any of the following conditions are true: The element is "on-screen": its containing box's border box intersects with the viewport, or a user-agent defined margin around the viewport.

This definition is ambiguous about whether or not a on-screen 0-sized box would be considered relevant or not. Such a box has 0 area, and hence it would have zero intersection, even if it's positioned on-screen. So it arguably never "intersects with the viewport", even when it is fully contained within the viewport.

It would be nice for the spec to make clear what happens for such boxes. Possibly just adding a sentence saying "For the purpose of this consideration, a 0-sized box is considered as intersecting this area if it is fully contained within this area."

created time in a day

issue openedw3c/csswg-drafts

[css-grid-1] Raw bikeshed markup is present in grid chapter 11.3

Chapter 11.3 ( https://drafts.csswg.org/css-grid-1/#algo-track-sizing ) currently has a 5-step listing, with step 5 showing up in the HTML as:

[[#algo-stretch|Expand Stretched auto Tracks]]

That looks like bikeshed markup that didn't get interpreted properly (maybe due to a typo somewhere).

created time in 6 days

issue commentWICG/layout-instability

Spec should clarify whether or not this is intended to serve as a "layout-changed observer" (I think it's not?)

One more reason to explicitly recommend against (and perhaps design against) the "layout changed, let's run some JS to update all our CSS and reposition these elements" use-case: we don't want to end up in a future where some fraction of websites depend on browsers supporting this feature in order to render properly.

Layout-shift is meant as a developer-facing feature for monitoring performance/user-experience; so I think we should make it clear that it's only meant to be used in a way where its implementation status is effectively undetectable to users. (This will ensure that we can safely deprecate & drop support for this API in the future, without breaking sites, once we've got a hypothetical better metric available and/or when this metric hypothetically becomes impractical for next-gen web engines to implement.)

dholbert

comment created time in 12 days

issue openedWICG/layout-instability

Spec should clarify whether or not this is intended to serve as a "layout-changed observer" (I think it's not?)

It may be tempting for web developers to use the Layout Instability API as a way of tracking when elements move (for any reason), as a way to receive callbacks when they need to recompute the positions of other related elements (e.g. overlays, focus rings).

There's a blog post here that recommends doing exactly that (find-in-page for layout shift to see the details): https://www.notion.so/Focus-Rings-4459faa9d1f643728ca8dde145a89900

(see note about it in https://twitter.com/aweary/status/1313266406641864706?s=20 as well)

So this is effectively using the Layout Shift API as a callback for when layout changed, as a hook for web-developer JS to run.

Is this an intended-to-be-useful use case for this API? The problem that comes to mind first is the magic "3px" threshold that's currently hardcoded in spec (an element that slowly moves < 3px per animation frame won't trigger a layout shift report, even if it continues moving a long distance at that rate; see first example in https://github.com/WICG/layout-instability/issues/53#issuecomment-691298116)

If in fact this "layout observer" sort of thing is not a use-case that this API intends to robustly support, then it might make sense to make that clear in the spec...

created time in 16 days

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

This wasn't actually a "move" after all... For the user, it appears out of nowhere in both cases, as if it were just added to DOM, and occupies the same overall size.

I had the same thought, and I think this is a good point. Strawman proposal: maybe we should just give a free pass to elements whose current or previous-frame "Visual Representation" is empty? (Note that the "Visual Representation" is defined such that it excludes points outside of the viewport[1].) That seems like it would match the "user-perceives-it-as-being-just-added-to-the-DOM" (or removed from the DOM) scenario pretty closely.

(The dependence on "viewport" in Visual Representation might be problematic for our purposes here -- it might not handle elements that are out-of-the-scrollable-region inside a scrollable div, e.g. the abspos "Hi" text in this example. If you adjust the left and/or top for the "Hi" text such that it's entirely out of its scrollframe, it's clearly not visible; but it's still inside the geometry of the document's viewport, sort of.)

dholbert

comment created time in 19 days

issue closedwebcompat/web-bugs

app.slack.com - Wide images are clipped in slack threads

<!-- @browser: Firefox 77.0 --> <!-- @ua_header: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0 --> <!-- @reported_with: -->

URL: https://app.slack.com/

Browser / Version: Firefox 77.0 Operating System: Linux Tested Another Browser: Yes Chrome

Problem type: Design is broken Description: Items not fully visible Steps to Reproduce: wide images are clipped in slack threads (with redesigned slack UI)

STR:

  1. Create a "thread" in some slack room.
  2. Paste this URL (or the URL of some wide image) into that thread: https://pocket-syndicated-images.s3.amazonaws.com/5df8fc2de1fd4.jpg
  3. Make your browser window kinda skinny (say, ~1000px wide)

ACTUAL RESULTS: The image runs off the right side of the thread pane. EXPECTED RESULTS: The image should shrink to fit.

Firefox gives "actual results". Chrome gives "expected results".

This is a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1316534 . I'll post more details below. <details><summary>View the screenshot</summary><img alt='Screenshot' src='https://webcompat.com/uploads/2020/4/3a868d4b-4f03-4524-ba2f-db18ae68d9b2.jpg'></details>

<details> <summary>Browser Configuration</summary> <ul> <li>None</li> </ul> </details>

From webcompat.com with ❤️

closed time in 22 days

dholbert

issue commentwebcompat/web-bugs

app.slack.com - Wide images are clipped in slack threads

@karlcow I think that means we can close this as a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1316534, right?

(Closing; hopefully I'm not doing anything wrong, please clean up after me if I am. :) thanks!)

dholbert

comment created time in 22 days

issue commentwebcompat/web-bugs

app.slack.com - Wide images are clipped in slack threads

TYLin and I confirmed that this is fixed in current Nightly 83, almost certainly due to the patches that landed last week in https://bugzilla.mozilla.org/show_bug.cgi?id=1316534.

I can't repro with the STR here anymore (in builds-that-should-be-broken), but I was able to repro in Nightly 2020-09-18 via a slack thread where someone had posted this tweet that has a long image included: https://twitter.com/damnonss/status/1306417115549716482

Nightly 2020-09-18 lets the image be large & cropped (and the tweet text runs off the side and is cropped as well, since it's filling the same cropped area). Nightly 2020-09-28 does not have this issue -- it shrinks the image nicely so that it fits.

dholbert

comment created time in 22 days

issue commentwebcompat/web-bugs

research.google - The blue line overlaps the text

I left some comments on the bugzilla bug report. Thanks!

annygakh

comment created time in 23 days

pull request commentweb-platform-tests/wpt

[css-flex] Change some test expectations for image flex items

@davidsgrogan Yes, I think you're correct.

For reference, Firefox's bug here seems to be a "stretch-specific" variant of https://bugzilla.mozilla.org/show_bug.cgi?id=1665532

chromium-wpt-export-bot

comment created time in a month

issue commentwebcompat/web-bugs

payroll.jobcan.jp - design is broken

This looks like a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1469649 (and in fact someone posted a mention of this site there already).

critical-bug

comment created time in a month

issue commentWICG/layout-instability

Define how much data should be buffered (also: does 'buffered' impose a substantial cost on the whole web here?)

@mmocny:

Trying to summarize this thread: [...] Could perhaps a Document Policy be used to opt-in to buffering of default-off metrics?

Thank you for that summary - that's a good encapsulation of the points/concerns here.

I'm not familiar with Document Policy itself, but from a glance at the proposal, it seems like a suitable opt-in mechanism for these sorts of metrics, assuming it's eventually implemented outside of Blink.

@npm1:

we should await for the Firefox feedback from their implementation.

You might be waiting a little while for this. Nobody is currently working on a Firefox implementation, and it's not a priority for the immediate future, as far as I know. My github-issues & feedback have mostly been to inform our standards-positions assessment and to be sure we can eventually implement it, when we've got resources to put into an implementation.

But at this point, I would not bet on this falling cleanly into "trivial-to-compute/cost-already-paid" category, for Gecko. Note that your comment in https://github.com/WICG/layout-instability/issues/53#issuecomment-673506384 suggests that it's also not in that trivial-cost bucket for Blink, either, without a kinda-magic threshold being baked into the feature.

It's possible we could make it trivial-cost with a sufficient magic-threshold & perhaps with other shortcuts; but I'd much prefer a wholly opt-in mechanism for enabling this, so we don't need to worry as much about shoehorning it into being trivial-cost.

dholbert

comment created time in a month

pull request commentmozilla/sccache

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846.

(Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1665540 to bump the m-c sccache version.)

dholbert

comment created time in a month

pull request commentmozilla/sccache

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846.

Thanks, everyone! Yup, I'll file a bug to bump the m-c sccache version.

dholbert

comment created time in a month

pull request commentmozilla/sccache

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846.

@froydnj would you mind merging this backout, if it looks good to you? (assuming the CI likes it; presumably it should pass since it's just a targeted backout of a library version bump)

dholbert

comment created time in a month

pull request commentmozilla/sccache

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846.

This should fix #846 , according to https://github.com/mozilla/sccache/issues/846#issuecomment-692226002

dholbert

comment created time in a month

PR opened mozilla/sccache

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846.

This reverts commit bdaa65aead6053ff707b1c20320e213d29d4bb55.

(This commit was generated by simply doing git revert bdaa65aead6053ff707b1c20320e213d29d4bb55.)

+7 -31

0 comment

2 changed files

pr created time in a month

push eventdholbert/sccache

Daniel Holbert

commit sha 926e2e9f6286596fda948c44ef56ec5155cdb12e

Revert "Bump to tiny-http 0.7.0 (#830)" because it caused a regression, #846. This reverts commit bdaa65aead6053ff707b1c20320e213d29d4bb55.

view details

push time in a month

fork dholbert/sccache

sccache is ccache with cloud storage

fork in a month

issue closedmozilla/wg-decisions

[css-logical] Mapping of logical values in 'resize'

A resolution was made for csswg-drafts/#3281.

**[css-logical] Mapping of logical values in 'resize' **

  • RESOLVED: have the logical value of resize that of the element itself

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue commentmozilla/wg-decisions

[css-logical] Mapping of logical values in 'resize'

Based on the discussion, it sounded like the resolved-on behavior matches what Gecko already does. (@emilio can hopefully sanity-check my understanding on that)

mozilla-apprentice

comment created time in a month

issue commentmozilla/wg-decisions

[css-text] Reconsider the resolution on #855

@emilio I think we need a bug for this, correct?

mozilla-apprentice

comment created time in a month

issue openedw3c/csswg-drafts

A bunch of specs say "CSS-wide keywords keywords" (repeating the word "keywords") in their "Value Definitions" section

This applies to various specs, as well as the sample "Foo" spec: https://drafts.csswg.org/css-module-bikeshed/#values https://www.w3.org/TR/css-display-3/#values https://www.w3.org/TR/css-sizing-3/#values ...and more.

These specs all say (emphasis added):

all properties defined in this specification also accept the CSS-wide keywords keywords as their property value

I think the second "keywords" is a typo, right?

Google Search to find the affected specs: https://www.google.com/search?client=firefox-b-1-d&q=site%3Aw3.org+%22CSS-wide+keywords+keywords%22

CC @tabatkins @fantasai

created time in a month

issue commentWICG/layout-instability

Spec's usage of the term "line box generated by N" might be imprecise/incorrect (where N is a text node)

(I don't think there's any ambiguity; this was just a language-lawyer sort of thing.)

dholbert

comment created time in a month

issue closedWICG/layout-instability

Spec's usage of the term "line box generated by N" might be imprecise/incorrect (where N is a text node)

In this section... https://wicg.github.io/layout-instability/#sec-terminology ...the spec defines the "starting point" and "visual representation" of a text node N in terms of "the first line box generated by N".

I think this might be misusing terminology -- I'm not sure it's correct to say that text nodes "generate line boxes", really. They're contained within line boxes, and they do (in aggregate) cause line boxes to exist, but their block container (or their inline formatting context) is really the thing that generates the line boxes.

As a concrete example, consider e.g. a line box which is formed to contain all of this content (with many individual text nodes): 1<a>2</a>3<i>4</i>5<u>6</u>7 . It would be misleading to say any individual one of the text nodes here "generated" the line box. Really, the line box was generated by the block container / inline formatting context, and it contains boxes for all of these text nodes, I think.

So, anyway -- assuming that the spec really wants to refer to the whole line box (rather than just the box around the text): maybe it wants to say something like "the first line box that contains a piece of N's content"? (or use "contains" / "participates-in" terminology, rather than "generates")

closed time in a month

dholbert

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

One option for solving this: we could disregard movement that's outside of a scroll frame's scrollable overflow area.

Per https://drafts.csswg.org/css-overflow-3/#scrolling-direction : "UAs must clip the scrollable overflow area of scroll containers on the block-start and inline-start sides of the box (thereby behaving as if they had no scrollable overflow on that side)." If we could arrange to exclude layout shifts that occur in that region (i.e. ignoring the portion of the movement vector that is outside of the scrollable overflow area, or something to that effect), then that would address my concerns here, I think.

dholbert

comment created time in a month

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

@skobes: right, there's no difference between -100vw and larger values. My concern here is about the fact that we're giving better scores to stuff positioned adjacent to the viewport as opposed to separated a healthy distance from the viewport.

@npm1: Yes, your example is the scenario I'm talking about. (though let's disregard top since it's unnecessary; left on its own is sufficient to get us offscreen. The same concerns apply regardless of whether you use top or left or both of them, though.)

My concern is: (1) We're incentivizing the web developer to use left:-100 in your example there (rather than a larger offset) since it gives the minimum CLS penalty. (2) That is precisely the wrong thing that we want to incentivize, because if the web developer has any sort of mistake that creates a small amount of >100px overflow (e.g. unexpectedly wide image or word, unexpected font on user's system, unaccounted-for box-shadow), then that overflow will end up leaking onscreen and breaking the user experience.

So it would be better for us not create this incentive for bad/fragile behavior.

dholbert

comment created time in a month

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

@npm: I see this is now closed - I'd still be interested in your / @skobes 's thoughts/feedback on the issue that I brought up in my most recent comment here.

dholbert

comment created time in a month

pull request commentmozilla/sccache

Bump to tiny-http 0.7.0

heads-up, this seems to have broken sccache configurations on Ubuntu (at least) - see #846

philn

comment created time in a month

issue commentmozilla/sccache

Distributed compilation jobs fail because scheduler thinks that assign_job request times out

Note: I ran into this on Ubuntu as well (version 20.04 in my case), and it happens for me even in the relatively-straightforward configuration of scheduler/server/client all running on the same machine.

mstange

comment created time in a month

issue commentmozilla/sccache

Distributed compilation jobs fail because scheduler thinks that assign_job request times out

Seems like we should get @philn's attention here, then (and consider rolling back that update for now, I guess?)

mstange

comment created time in a month

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

Basically: for sites that hide content by positioning it offscreen (e.g. so they can measure it and reason about its layout before displaying it), I'm concerned that this piece of the spec is incentivizing them to position their offscreen content as close to the viewport as possible, i.e. directly adjacent to the viewport. (e.g. at left:-100px for a 100px-wide div). I can absolutely see this being part of a "Top 10 easy ways to do SEO by improving your CLS score" clickbaity webdev blog post.

And despite "optimizing" the CLS score, this choice (placing stuff just offscreen) has no upside, and has definite downsides. If the offscreen div happens to have content that overflows a little bit in a particular configuration (e.g. due to the user having an unexpected set of fonts, or an a11y-related minimum font size, or a particular piece of unexpectedly-wide content), then that overflowing content will leak out of the offscreen element & onto the viewport, where otherwise it would not have been visible if the web developer had kept it at left: 10000px or whatever.

dholbert

comment created time in a month

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

Hmm, fair point; that means #73 (limiting the move vector to 2x the viewport) is probably redundant & doesn't make a meaningful difference.

The original scenario that I had in mind here was content appearing from "just-offscreen" vs. "somewhat further offscreen", and it just feels odd (from a user-impact perspective) that we penalize these differently depending on how far offscreen (in terms of fraction-of-viewport-size) the content was. I think I was originally envisioning that maybe we'd clamp the move vector to only incorporate the on-screen portion of movement, or something. Having said that, maybe it's simpler to not bother with this.

dholbert

comment created time in a month

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

You mean flexibility on all of the testcases mentioned in the original issue, or which of them?

Some of them. In particular, I think visibility:hidden and opacity:0 both could be problematic for us to track, if we hook in at the point in the layout/paint pipeline that we were thinking about.

We could keep the existing text and add some text saying the user agent may choose to ignore shifts of content that they deem invisible?

I'm conflicted, but I think I like this.

(If this were a purely opt-in feature, I'd feel much more in favor of strictly defining the behavior, without regard for computational cost. But since it's not opt-in -- browsers must collect the first 150 samples for all pageloads per #52 -- that means we have to be careful about requiring any computations whose value is dubious.)

Are there any unexpected consequences of allowing different behaviour between UAs here? For example, if an author optimizes their page using a UA that doesn't penalize invisible content, are there downsides for them still receiving a poor score in a different UA?

This is a good point & is something that we'll definitely need to weigh whenever taking advantage of a "The UA may decide..." route.

Given that this metric will impact search rankings, it's clear that web developers will largely have search ranking in mind, and they'll expect their browser to be at least as strict as the web-spidering-UA that's used for search ranking computations.)

So for cases that web developers are likely to stumble across, I think we need to be very careful about diverging. But for more extreme edge cases, I'd think we could diverge if it helps simplify the implementation.

dholbert

comment created time in a month

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

(I think I would prefer for the spec to allow for some flexibility on this - the approach that @mattwoodrow and I were envisioning would need to exclude some of these unpainted cases, at least. But perhaps this can fall under the umbrella of user agents "compromis[ing] precision in the interest of calculation efficiency".)

dholbert

comment created time in a month

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

Yes, I think Chrome's implementation has become spec complaint on the cases that I'd brought up (since all of these cases "generate boxes", which means their movements should be considered as contributing to layout shift, and now Chrome does seem to consider them.)

dholbert

comment created time in a month

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

Because multiplying by movement distance is part of the score calculation, there is hardly any difference between counting vs. not counting such small movements.

For an individual animation-frame's measurement, perhaps this is true. But if the moving thing is moving continuously for some period of time (i.e. being animated), then counting vs. not counting could make a huge difference in the CLS score (particularly if the rest of the page is mostly static).

the user agent could still implement such a threshold under the general allowance for trading off precision and efficiency.

I agree with this, yeah.

dholbert

comment created time in a month

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

To have something concrete to look at, here are two testcases (where I'm assuming ~60 FPS):

  • Here's a testcase with a ~2px-per-animation-frame movement, where Chrome reports no layout shift: https://jsfiddle.net/dholbert/bwkvqm61/
  • If I adjust the testcase to double the speed (so, ~4px-per-animation-frame), Chrome does report a layout shift: https://jsfiddle.net/dholbert/bwkvqm61/1/

Chrome's behavior on these testcases matches the spec (honoring the 3px threshold), but it doesn't feel like it makes much sense.

dholbert

comment created time in a month

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

Just from the perspectives of understandability, theoretical purity/coherence, and avoiding the feature being "gameable"/arbitrary: yeah, I think it would be preferable to remove the threshold.

I can imagine there being cases where there's a lot of content moving and things would get heavyweight for the engine. But in those cases, your points in https://github.com/WICG/layout-instability/issues/52#issuecomment-651192820 suggest that you think this cost should only be measurable if the feature is being used (i.e. the mandatory buffered measurements aren't expected to ever be too expensive). And if the feature is being used, then presumably the site would be interested to be informed about all their micro-shifts & the resulting relayout that they cause, so the cost is worth it.

dholbert

comment created time in a month

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

One other update: it seems Chrome's behavior has changed here, such that all the cases in my fiddle (discussed in the original comment here) do all now report a layout shift.

I'm testing Chrome 87.0.4259.3 (Official Build) dev (64-bit) on Ubuntu 20.04.

dholbert

comment created time in a month

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

Hmm, ok.

It's not intuitively obvious to me why changing the threshold from 1px to 3px would make a substantial difference in an animation test... I have a nagging feeling that the testcase must have been animating a layout-impacting property at ~1-2px per animation-frame -- this would report a shift on every refresh if we use a 1px threshold, but it never reports any shift at all if we use a 3px threshold. But a marginally-larger animation (animating 3px per animation-frame) would still have the same problem (reporting a shift on every tick).

I can't kick the feeling that this threshold feels pretty hacky, due to (a) the "all or nothing" stuff discussed above (3px-per-tick gets you horrible layout-shift-scores, 2px-per-tick gets you zero layout-shift-scores), and (b) the presence of this magic number.

dholbert

comment created time in a month

pull request commentWICG/layout-instability

Clamp move vector to 2x viewport.

That sounds good, yeah. Thanks!

skobes

comment created time in a month

issue commentmozilla-mobile/fenix

Crash in [@ java.lang.RuntimeException: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java)]

I haven't hit the crash since my comment yesterday (when I installed the update). Previously I was seeing this several times per day, so I'd call this confirmation that this is fixed.

(Regarding the STR: I think it was something like: start fenix, then switch apps, then wait for a little while.)

kbrosnan

comment created time in a month

issue commentmozilla-mobile/fenix

[Bug] "null Downloads failed" notification, when you have some failed downloads and you swipe away the last notification

screencast: https://www.dropbox.com/s/qnr1nxrytdu8k4e/null-download-failed.mp4?dl=0

(The issue is visible at approximately 0:05 in the screencast.)

dholbert

comment created time in a month

issue openedmozilla-mobile/fenix

[Bug] "null Downloads failed" notification, when you have some failed downloads and you swipe away the last notification

Steps to reproduce

  1. Follow STR for #14790, with several failed downloads.
  2. Swipe away all of the notifications for the individual failed downloads.

Expected behavior

"null" shouldn't be shown as a string

Actual behavior

The system tray grouping section briefly says "null Downloads failed", before disappearing altogether.

Device information

  • Android device: Pixel 3, running Android 10 and 11 (recently upgraded from 10 to 11, and I've noticed this issue with both)
  • Fenix version: Nightly 200910 06:07 (installed from play store, latest version currently available)

Screenshot showing the "null Downloads failed" notification: screenshot

created time in a month

issue commentmozilla-mobile/fenix

Crash in [@ java.lang.RuntimeException: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java)]

I'm hitting this reliably several times per day, FWIW; I'll glance at my phone and notice a notification telling me "Sorry, Firefox Nightly had a problem and crashed". Logcat shows "ActivityManager: Background start not allowed: service Intent { cmp=org.mozilla.fenix/.downloads.DownloadService (has extras) } to org.mozilla.fenix/.downloads.DownloadService" which is what brought me to this issue here.

Looks like the Play Store has a update for Nightly available for me right now. Not sure if it has the fix mentioned above yet (I'm guessing yes since it was merged 23 hours ago). In any case, I can report back regarding whether this seems fixed or not.

kbrosnan

comment created time in a month

issue closedwebcompat/web-bugs

www.innovelsolutions.com - site is not usable due to failing to send intermediate SSL certificates

<!-- @browser: Firefox 63.0 --> <!-- @ua_header: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 --> <!-- @reported_with: web -->

URL: https://www.innovelsolutions.com/

Browser / Version: Firefox 63.0 Operating System: Linux Tested Another Browser: Yes

Problem type: Site is not usable Description: I get a SSL/HTTPS error page (in a fresh Firefox profile). Steps to Reproduce:

  1. Start Firefox with a fresh browser profile (e.g. by visiting the special URL "about:profiles" and clicking the button to create a new profile)

  2. Visit https://www.innovelsolutions.com

I believe the issue is that they use a chained certificate (their cert isn't signed directly by a root, but rather by a signing cert that itself is signed by a root) -- and they're not providing the intermediate certificate, which means Firefox is unable to verify their certificate's authenticity. This is demonstrated by the "Chain issues": "Incomplete" report at https://www.ssllabs.com/ssltest/analyze.html?d=www.innovelsolutions.com&s=18.219.206.72&latest

Screenshot of the error page that you get when trying to visit innovelsolutions in a fresh browser profile: Screenshot Description

From webcompat.com with ❤️

closed time in a month

dholbert

issue commentwebcompat/web-bugs

www.innovelsolutions.com - site is not usable due to failing to send intermediate SSL certificates

Fixed for me, too (including in the Nightly from back when I reported it, tested via mozregression --launch 2018-08-01).

Thanks!

dholbert

comment created time in a month

issue closedmozilla/wg-decisions

[css-conditional-3] Let's finish the specification

A resolution was made for csswg-drafts/#5315.

[css-conditional-3] Let's finish the specification

  • RESOLVED: Add chris and fantasai as editors to CCSS Conditional 3

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue closedmozilla/wg-decisions

[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text

A resolution was made for csswg-drafts/#5233.

[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text

  • RESOLVED: we're interested and would like chrishtr to pursue and come back with proposal text

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue closedmozilla/wg-decisions

[css-pseudo-4] Standardizing input[type="range"] styling

A resolution was made for csswg-drafts/#4410.

[css-pseudo-4] Standardizing input[type="range"] styling

  • RESOLVED: Continue working on standardizing these 3 pseudos

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue commentw3c/csswg-drafts

[css-sizing-4][css-flexbox] How to calculate the content-based minimum sizes when applying aspect-ratio on the flex container

@BorisChiou:

Do we just use the outer hypothetical main size of each flex item to calculate the main size, and compare this with the main size of the flex container from aspect-ratio (i.e. flexContainerMainSize = std::max(mainSizeFromContent, mainSizeFromAspectRatio))?

For single-line flex containers, yeah, I think that's a reasonable approximation of what the spec asks for.

Strictly speaking: to determine the min-content size here, we should be following https://drafts.csswg.org/css-flexbox-1/#intrinsic-main-sizes (which is effectively trying to reverse-engineer the flex algorithm to produce the flex container size that would avoid overflow), I think.

For multi-line flex containers, though, there's a special-case at the bottom of that section:

  However, for a multi-line container, it [the min-content main-size]
  is simply the largest min-content contribution of all the flex items
  in the flex container.

where min-content contribution is defined at https://drafts.csswg.org/css-flexbox-1/#intrinsic-item-contributions .

That special-case means biesi's assessment here is wrong, and we should technically wrap in this testcase. (Its flex container's min-content height [the lower-bound that aspect-ratio can shrink it to here] is 50px, which comes from the individual items, rather than coming from the sum of the items' heights.

BorisChiou

comment created time in a month

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

That seems fine, though I still really want to understand what specifically was problematic when you tried a value of 1 (and why, and how switching to 3 fixed it). What sorts of content/movements seemed to be causing your lab bots to complain about performance when you used the 1px threshold?

In particular: was it for individual layout shifts that happen during pageload that are specifically only 1-2px in size (e.g. from resources loading)? Or was it for slowly-animating content that's animated with abspos & left at 1px-per-frame? Those are the sorts of things I can imagine causing reports at a 1px threshold but not at a 3px threshold, but intuitively I don't imagine either would be super-common. Maybe there's another category that benefits here that I'm not thinking of?

dholbert

comment created time in a month

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

Sure, I think I'd be OK with leaving it up to UA discretion for those visibility and opacity cases.

One other loop to close here, though -- Chrome does also disagree with the spec on the "contain:paint and zero size" scenario. (The spec considers movement inside of such an element as contributing to shift, but Chrome does not, last time I checked.) That should probably either be considered a Chrome bug (and tracked as such), or it needs a spec exception of some sort (whether general or specific).

dholbert

comment created time in a month

issue commentmozilla-mobile/fenix

"Download Failed" when downloading a PDF on some websites. [Bug]

I've been running into this same issue with Fenix Nightly (and then the failure notifications respawn on every app restart, per #14790)

The PDFs that Fenix is having trouble with, most recently on my device, are the "Bottle Capacity Chart" and "Product Manual" linked under "Manuals and Guides" near the bottom here: https://www.costco.com/wine-enthusiast-somm-series-2-door-dual-zone-wine-and-beverage-center.product.100458858.html

Both PDFs download fine in Chrome.

Sodel-the-Vociferous

comment created time in a month

issue openedmozilla/pdf.js

Find-in-page highlight-box is at wrong y-position in Coway airmega PDF-manual

Attach (recommended) or Link to PDF file here: https://images-na.ssl-images-amazon.com/images/I/D1SWYNC4nwS.pdf D1SWYNC4nwS.pdf

Configuration:

  • Web browser and its version: Firefox Nightly 82.0a1 (2020-09-05)
  • Operating system and its version: Windows 10
  • PDF.js version: Not sure; whatever's shipped with Nightly right now
  • Is a browser extension: not an extension that I manually installed; just the built-in version.

Steps to reproduce the problem:

  1. Load attached PDF
  2. Find-in-page (Ctrl+F) and type "clean".
  3. (optional): Ctrl+G to skip through a few matches

What is the expected behavior? The text "clean" should be highlighted for each match.

What went wrong? (add screenshot) The highlighted box is above the text, approximately one line-height away: image image

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

created time in 2 months

issue commentmozilla/fx-private-relay

[Button] On auth0 (e.g. sso.mozilla.com), the "Log in with email" label/placeholder-text is missing

Screenshot of expected rendering: image

Screenshot of actual rendering: image

dholbert

comment created time in 2 months

issue openedmozilla/fx-private-relay

[Button] On auth0 (e.g. sso.mozilla.com), the "Log in with email" label/placeholder-text is missing

STR:

  1. View the https://sso.mozilla.com/ login page (i.e. visit that URL in a profile where you're not logged in with Mozilla LDAP

EXPECTED RESULTS: There should be "Log in with email" placeholder text in the textfield, which jumps to be above the textfield when you the field gets focus.

ACTUAL RESULTS: There is no such text (if you have the FX Private Relay add-on installed & enabled).

created time in 2 months

issue commentwebcompat/web-bugs

goalkicker.com - Missing blurr effect

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1661147

webcompat-bot

comment created time in 2 months

issue commentwebcompat/web-bugs

goalkicker.com - Missing blurr effect

I can only reproduce this in a profile where I have WebRender enabled, so I think this is just a bug in the WebRender blur(...) implementation. I'll file a bug.

webcompat-bot

comment created time in 2 months

issue commentwebcompat/web-bugs

www.engadget.com - Incorrect text alignment

@dholbert we have a difference here.

(Sorry for delayed reply)

Are you sure we have a difference? If I load the site in Chrome-in-RDM with a Firefox UA string, it looks like Firefox-in-RDM. (with "The Latest" section smooshed against left edge of page)

Screenshot of Chrome-with-Firefox-UA showing the same issue: image

ktaeleman

comment created time in 2 months

issue commentmozilla/fx-private-relay

relay icon is giant at https://dcwineanddine.com/

When I check now, I don't see any icon on dcwineanddine but I do see the right-sized Relay icon on Scalyr.

Same here. Maybe we can close this as fixed?

(A bit curious that the icon stopped showing up on https://www.dcwineanddine.com/ . In devtools, I can actually see that it's still there, but it's 30px by 2px (i.e. basically 0-height) and not visible, for that reason and perhaps also other reasons.)

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

(To clarify: I'm not arguing for a different threshold and I'm not necessarily saying it should be UA-dependent, though if it is truly magic then perhaps it should be. I'm mostly just wanting to understand the reasoning, since it superficially seems pretty arbitrary.)

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

Explain (and perhaps make configurable) the magic number 3 in "3 or more pixel units" (when determining which nodes are shifted)

3px is still pretty magic, though; presumably a higher threshold of 5px or 10px (or even 1rem or 1vw) would make it even more performant. And on the flip side, a lower threshold of 1px would make it more correct (and 0.5px would make it even still more correct).

Can you clarify why a 1px threshold has significantly-worse-enough performance than 3px to rule that out? e.g. is there a lot of content with rapid 1px or 2px shifts that would overwhelm this API in a way that hurts performance (but not much content with >3px shifts that cause the same problem?)

I'm interested to hear/discuss the reasoning here, but it also would eventually be nice to include a Note in the spec to explain the choice of 3 and the drawbacks of going too small / too large.

Thinking out loud: some possible non-performance-related justifications that I can imagine [though I have no idea if these are the actual reasons]:

  • While small 1px shifts are user-perceivable, they're less likely to trigger the "clicked the wrong button" sort of pain-point which IIUC is a large motivator for this feature, so maybe we care less about shifts of that magnitude
  • Maybe allowing 1-2px shifts can allow for certain motion animations that don't want to penalize. (i.e. maybe there was a judgement that 1-2px movement per paint is "smooth enough" for an animation to be user-pleasing, but significantly more is too jarring?)
dholbert

comment created time in 2 months

issue closedmozilla/wg-decisions

[mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS

A resolution was made for csswg-drafts/#2943.

[mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS

  • RESOLVED: Change high and low in the MQ to more and less

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in 2 months

mozilla-apprentice

issue commentmozilla/wg-decisions

[mediaqueries-5] `prefers-contrast: high` media feature doesn't account for macOS and iOS

@zekemedley is already on top of this in https://bugzilla.mozilla.org/show_bug.cgi?id=1658780

mozilla-apprentice

comment created time in 2 months

issue commentWICG/layout-instability

Define how much data should be buffered (also: does 'buffered' impose a substantial cost on the whole web here?)

Thanks. Yeah, I was musing over those same options (reducing/disregarding buffered and/or tracking a somewhat different set of geometric data about repaints that's more readily available).

  1. Change the definitions to better match with what browsers would typically compute during paint invalidation, if this is feasible

(For the record, Chrome's implementation seems to already be doing this internally, to some extent, per #65 and related issues. :) )

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

layout instability spec doesn't account for paint-only effects that don't influence css box size (e.g. box-shadow)

It falls under the category of "things that fall naturally out of the engine-specific paint pipeline, which are difficult to avoid, and also difficult/undesirable to specify".

If this is difficult to fix, that suggests to me that Chrome's implementation is in terms of paint primitives rather than layout primitives -- do you know if that's the case? (And/or: would you be able to sum up Chrome's implementation approach somewhere, and/or is that documented somewhere that I could look at?)

This sort of distinction (box-shadow included/excluded) seems superficially trivial but matters a great deal for how we might approach a Gecko implementation -- where we plug into our relayout/render pipeline, which box tree / primitives we're dealing with, etc.

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

Fix ambiguous language on "has not shifted in $X or $Y" language

Put another way: its not clear to me which of these is what the spec is trying to say:

Interpretation A: "N counts as 'stable' if it stayed fixed in either the local coordinate system of of P or in the scrollable overflow region of P"

...vs: Interpretation B: "N counts as 'stable' if it stayed fixed in both the local coordinate system of P and in the scrollable overflow region of P"

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

Fix ambiguous language on "has not shifted in $X or $Y" language

Note that this section is particularly tricky to reason about given all of the layers of negation ("N is unstable if: [...] there does not exist an element P such that: [...] N has not shifted in ...")

(Hence the importance of making the language as explicit & unambiguous as possible.)

dholbert

comment created time in 2 months

issue openedWICG/layout-instability

Fix ambiguous language on "has not shifted in $X or $Y" language

Ambiguous language in section 2.2 here: https://wicg.github.io/layout-instability/#sec-basic-concepts

there does not exist an Element P such that [...conditions...] and: 4. N has not shifted in the coordinate space of the local coordinate system or scrollable overflow region of P.

This language is currently ambiguous -- it's not clear what the "or" means here.

This could be read to mean two very different things: Interpretation A: "Either: N has not shifted in the local coordinate space of the local coordinate system of P, or N has not shifted in the scrollable overflow region of P"

Interpretation B: "N has not shifted in the local coordinate space of the local coordinate system of P, nor has it shifted in the scrollable overflow region of P."

Please reword to make it unambiguous.

created time in 2 months

issue commentmozilla/standards-positions

Layout Instability API

I've now filed https://github.com/WICG/layout-instability/issues/66 on the transform stuff and added it to my list above.

RE scroll input, I think the spec's snippet about "an Element P" is meant to be what excludes scrolling from being considered as layout shift. Though if the site uses additional transform effects for this sort of scrolling, then I think you're correct that it would be counted, per https://github.com/WICG/layout-instability/issues/66#issuecomment-671492844 (but that might be a spec bug).

skobes

comment created time in 2 months

issue commentWICG/layout-instability

The spec should make it clearer whether `transform` affects "visual representation" and layout shift

One other problematic spot with respect to transforms:

In the piece of the spec that excludes scrolling elements ("there does not exist an Element P such that..."), the spec discusses whether the node N's position has changed within its scroll-container's "scrollable overflow region".

And importantly, transform does change an element's position within (and its contribution to) this scrollable overflow region. Here's a demo which changes transform of something in a scrollport on hover: https://jsfiddle.net/dholbert/n937w14L/ (note that the scrollbars change when transform changes, indicating that the scrollable overflow area has changed size, and obviously the transformed thing has changed position within it).

So it seems that at least this section of spec text does not exclude transforms right now - it would consider transforms as contributing to layout instability. That may be problematic...?

dholbert

comment created time in 2 months

issue openedWICG/layout-instability

The spec should make it clearer whether `transform` affects "visual representation" and layout shift

The explainer and spec don't seem to agree on what the impact of CSS transform is, with respect to layout shift.

The spec: (1) doesn't mention the word transform at all, ever. (2) Defines layout shift in terms of the "visual representation" (3) Defines "visual representation" in a way that's not immediately obvious as to whether it includes transforms or not.

The explainer: (4) ...says that "Changing an element's transform affects its visual representation" (direct quote, emphasis added) (5) ...says that transform changes aren't treated as layout shifts https://github.com/WICG/layout-instability/blob/master/README.md#transform-changes

Concerns:

  • Taking (2) and (4) together, it seems quite clear that transform does impact layout shift. (But that disagrees with (3).) But maybe the explainer is just misusing the spec's specially-defined term "visual representation"?

  • The expectation should be made clearer in the spec itself. If we want to exclude transforms (and I think we do), then the spec should explicitly say something about that; possibly as a Note after whatever definition / concept-usage that it's currently leaning on to implicitly exclude them.

created time in 2 months

issue commentmozilla/standards-positions

Layout Instability API

@emilio does this snippet of the explainer address your concerns? (see the sections with titles "Shifting Nodes" and "Transform Changes")

(Perhaps those explainer sections need to be better captured in the spec... I am noticing that e.g. the word "transform" never appears in the spec right now.)

skobes

comment created time in 2 months

pull request commentmozilla/standards-positions

Standards Position for Layout Instability API

Optionally consider adding a brief mention that you’ve filed issues on the draft that express our concerns.

Done.

dholbert

comment created time in 2 months

push eventdholbert/standards-positions

Daniel Holbert

commit sha cbb83d8bbee5667aee27767506197d71ecd6f15b

be internally consistent about using two spaces between sentences

view details

push time in 2 months

push eventdholbert/standards-positions

Daniel Holbert

commit sha 07e2428ef953c52cc29473252ebe86056811b1bf

Add a mention that we've filed some spec issues (per tantek's suggestion).

view details

push time in 2 months

issue commentmozilla/standards-positions

Layout Instability API

I've posted a pull request https://github.com/mozilla/standards-positions/pull/425 to mark this spec as "worth prototyping".

There are some pieces that still need clarity, which I've filed spec issues for[1], and the editors have been responsive on those & hopefully we'll have (or can propose) answers when prototyping.

Assuming reasonable resolutions to those issues, the only piece I'm unsure about is whether this can be implemented efficiently such that it's ~zero-cost for sites that don't use the feature, given the requirements of buffered. That's something we'll know more about after prototyping the feature, so I don't think that should block this assessment. But, that issue could hypothetically change our assessment down the line, if prototyping suggests that the feature imposes a measurable cost for our rendering engine. (The cost may vary between rendering engines, too; I believe Blink's LayoutNG might cache the results of earlier layouts, or at least that was part of the design at one point -- that might make this feature "free" for them, in a way that it is not free for Firefox. On the other hand, maybe the cost will still be negligible; I'm not sure.)

skobes

comment created time in 2 months

pull request commentmozilla/standards-positions

Standards Position for Layout Instability API

I've noted some minor unease in the "mozPositionDetail" field:

"mozPositionDetail": "We're somewhat uneasy about the potential burden that this feature imposes on sites that don't use it, due to the requirements of the "buffered" flag. However, setting that reservation aside, we think this sort of feature is worth exploring.",

See https://github.com/WICG/layout-instability/issues/52#issuecomment-670777941 for more thoughts on this.

@mattwoodrow , do you agree with the overall "worth prototyping" assessment here? (modulo the aforementioned unease)

dholbert

comment created time in 2 months

PR opened mozilla/standards-positions

Standards Position for Layout Instability API

This closes #374

+12 -0

0 comment

1 changed file

pr created time in 2 months

push eventdholbert/standards-positions

Daniel Holbert

commit sha 078166dfac76906341219e84948cec3535e42a54

Standards Position for Layout Instability API This closes #374

view details

push time in 2 months

push eventdholbert/standards-positions

Daniel Holbert

commit sha 467d7e3d45b28a26379237805a1dca96806e9f44

Standards Position for Layout Instability API This closes #374

view details

push time in 2 months

issue commentWICG/layout-instability

Define how much data should be buffered (also: does 'buffered' impose a substantial cost on the whole web here?)

you do not need to compute anything once the buffer is full and there are no observers.

This addresses my concern about imposing a cost on sites that don't use this feature, I think. Sorry for not noticing that sooner.

I should walk this ^^ back somewhat; I am still somewhat concerned about the burden that this spec imposes on every pageload (given that the browser now has to do bookkeeping to accumulate 150 observations for every page ever loaded, despite no observer being registered & devtools not being open, etc.) If there's any perf overhead at all to this bookkeeping, then it will obviously have an impact on pageload time, which an especially important performance metric.

Hypothetically, if this feature's newly-required bookkeeping were to match up in a straightforward way with the sorts of things that the browser already has to keep track of for paint invalidation (e.g. if we were just making a note of the invalidated/repainted area), then perhaps this would be believably zero-cost.

But right now, the spec doesn't match up with the sorts of things that the browser would normally have to keep track of for paint invalidation (though perhaps Chrome's implementation has blurred it in that direction, based on observations/testcases in e.g. #61 and #65?) So, to conform with the spec, an implementation necessarily has to maintain additional state ("previous painted position & size" for each text node & each box in the box tree) which it otherwise does not have any need to maintain; and it'll have to do geometric comparisons between those states, for the first 150 paints of each site.

It's possible this is negligible, but without having implemented it yet, I'm not sure.

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

layout instability spec doesn't account for paint-only effects that don't influence css box size (e.g. box-shadow)

Here's a related slightly-different scenario:

  • In Chrome 84, if you move a 0x0 box (e.g. by adjusting margin-top), it does not get reported as a layout shift.
  • BUT if that box has a 0x0 shadow, then it does get reported as a layout shift (even though it looks exactly the same -- nothing painted -- and the box tree is the same, etc)

Testcase: https://jsfiddle.net/dholbert/5u0depzk/ (This^ testcase triggers a console.log() for a layout shift. If you remove the box-shadow styling, then it does not trigger a console.log for a layout shift anymore.)

dholbert

comment created time in 2 months

issue openedWICG/layout-instability

layout instability spec doesn't account for paint-only effects that don't influence css box size (e.g. box-shadow)

tl;dr: Chrome seems to be considering box-shadow as something that contributes to the Visual Representation of a node, which seems superficially reasonable but disagrees with the spec's definition of Visual Representation. So this is a case where Chrome & the spec disagree. Not sure whether it's a spec bug vs. Chrome bug. --> Starting out as a spec bug.

STR:

  1. Load this testcase in Chrome, with the devtools console open (F12): https://jsfiddle.net/dholbert/6rw8oqsf/
  2. Make a note of the logged layout-shift value.
  3. Edit the testcase to remove the box-shadow declaration, and re-run the testcase, and look at the logged layout-shift value.

ACTUAL RESULTS: The layout shift value changes. EXPECTED RESULTS: Per the current spec, the layout shift value should not change.

NOTES: box-shadow is a paint effect which is defined as not influencing layout. Quoting the spec that defines box-shadow:

Shadows do not influence layout [...]

Shadows do not trigger scrolling or increase the size of the scrollable area.

https://drafts.csswg.org/css-backgrounds-3/#shadow-layers

layout-shift is defined in terms of an element's "boxes" (from the box tree): https://wicg.github.io/layout-instability/#visual-representation Shadows attach themselves to those boxes, but they do not increase the size of the boxes.

They do increase the size of the "ink overflow" region -- one possible resolution here would be to redefine the Visual Representation in terms of the Ink Overflow. That would be a somewhat substantial change, though.

created time in 2 months

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

update the spec to say that a node in a visibility:hidden subtree is not considered unstable

Nit: for this hypothetical spec text, you probably really would want s/a visibility:hidden subtree/a node with visibility:hidden/

Subtrees aren't really relevant for visibility:hidden -- it's a decision that each node can make independently (it does inherit, but children can override the inherited value and show themselves). (But they are relevant for display:none, of course, since that nukes the subtree & the descendants have no say about that.)

I would be ok with allowing the UA to decide.

Cool - it would be great if there was some spec text (e.g. "For nodes that generate boxes that are not painted for whatever reason..." Not sure what the best spec terminology is to use there, but I think that would be the rough qualifier for this category.

dholbert

comment created time in 2 months

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

For partially-onscreen stuff, I suspect the current algorithm is fine, yeah.

(Thoughts on that, for the Move Distance metric: if an element moves by 100px, then the user still sees something moving by 100px, regardless of whether the element is fully vs. partially onscreen. So it makes sense for us not to care whether the element is fully vs. partially onscreen for this calculation.

And the offscreen portion will still be "discounted" via the reduction in Impact Area for the moved thing, since the Impact Area excludes offscreen stuff, via the definition of Visual Representation.)

dholbert

comment created time in 3 months

issue openedWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

Suppose you have an element that is positioned offscreen (e.g. with position:absolute; left: -50px) which then snaps onscreen (e.g. by changing left to 0)

The spec currently requires us to consider how far the element moved, as one of the inputs to layout shift. (It moved 50px in this example, so it would contribute 50px to the maximum move distance calculation, which then determines the Distance Fraction)

Now: if the node's initial offscreen position were left:-1000px, then we would instead contribute 1000px to the maximum move distance calculation, and this node would have a much harsher impact on the Layout Shift value.

This doesn't really make sense. From a user's perspective, this is content that has just appeared, and the user doesn't know & doesn't care how far offscreen it was before it appeared. (It's not any better or worse for its prior posiiton to be at -1000px vs. -50px, as long as it was entirely clipped at that point, so the score shouldn't give any advantage to one value or another.)

It feels like we should treat this scenario the same as we treat content that was freshly-created (i.e. don't consider it "moved" at all; there's no last-position), in order to capture that actual user experience.

created time in 3 months

issue commentmozilla/standards-positions

CSS Images 4: cross-fade()

CC @emilio @ZekeMedley

tantek

comment created time in 3 months

more