Daniel Holbert comments

Results 116 comments of


                                            Daniel Holbert

Change dashboard to support showing scores as of arbitrary wpt.fyi run (or latest run) even if not all browsers have results for that run

> wpt.fyi already supports this for its regular presentation of test results, e.g. here's a run that I have in my history (which happened to only have results for Chrome...

Change dashboard to support showing scores as of arbitrary wpt.fyi run (or latest run) even if not all browsers have results for that run

@DanielRyanSmith Thanks, your `this for example` link does indeed seem like a handy way to visualize/understand changes here at least. I need a bit more guidance at how to arrive...

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 ([sec 2.2](https://wicg.github.io/layout-instability/#sec-unstable-nodes), "there does not exist an Element P such that..."), the...

Fix ambiguous language in section 2.2, "has not shifted in $X or $Y"

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

Fix ambiguous language in section 2.2, "has not shifted in $X or $Y"

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

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

CC @npm1 @mattwoodrow

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

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; and it sets a modest upper-limit on...

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