STR:

1. Open a new tab.
2. Ctrl-click some of the recommended articles after the first row.

ACTUAL RESULTS:
For these further-down articles (under e.g. "health and fitness", "Tech", and "Entertainment" headings for me), the focus-rectangle that appears ends up overlapping the text.

EXPECTED RESULTS:
No overlap. They should be styled with some padding between where the focus rectangle draws and where the content is.

Note: the first row of articles (directly under "Recommended by pocket") do not have this problem. They have more padding (i.e. a smaller content area) than the further down articles, apparently.

I am using Nightly 68.0a1 (2019-05-02) (64-bit)

Here's a screencast showing the issue. The first half of the screencast shows the expected results with the top row. The second half shows the actual/problematic results with a lower row.

Bug 1548915 changed the cards to all be "bordered" cards instead of the previous "borderless" so this is no longer an issue with the default layout but if we have an experiment with "borderless" this bug will appear there.

The borderless cards are implemented to design specifications. The focus shadow doesn't actually overlap, but it is flush to the interior text, which is maybe not ideal.

Wolasi, how do you want to address this? Does this need a new design pass or is this ok as it is?

Yes, implementation is to specifications and Photon guidelines. We're not using any border-less formats in the confirmation study so we can put this on the back burner for now. We can revisit if and when we decide to use a border-less format.

(In reply to Gavin [:gvn] Suntop from comment #3)

The focus shadow doesn't actually overlap, but it is flush to the interior text, which is maybe not ideal.

Good point -- I overstated things by using the word "overlap".

Part of the reason this is an issue is that the border-color is basically the same as the (hovered) blue color of the title-text, which makes them visually bleed together, which looks like an overlap.

Anyway, not a big deal if we're not pushing forward with this design at the moment.

Just for reference if/when this is revisited, here's a screenshot from Nightly 2019-05-03

(possibly easier to see the issue in this static lossless screenshot than in the dynamic/fuzzy screencast)

Thanks for reference! Will keep you posted if/when we iterate on this.

This issue no longer reproduces on the new design (tested on Nightly 91.0a1, Win 10), so closing as RWFM.