*attached

And here is the forgotten attachment.
I saved the AMP version, since it is less cluttered and reproduces the issue as well.
http://www.vanityfair.com/news/2016/09/elizabeth-holmes-theranos-exclusive/amp

The custom font also affects the rendering.

Deleted: vanity-fair-issue.zip 207 KB

vanity-fair-issue.zip 207 KB Download

I can no longer reproduce this at
https://www.vanityfair.com/news/2016/09/elizabeth-holmes-theranos-exclusive

Tested on Windows 10, stable 60.0.3112.101 and canary 62.0.3191.0

Please let us know if you still encounter this.

I attached a local version in comment 2. It reproduces the issue consistently.

Actually, the online version reproduces this as well (search for "t was late morning on Friday, October 16" in the text, though every section suffers from the issue).

On the operating system level -
ClearType is disabled.
Font smoothing is also disabled.


about:version -
Google Inc.
Copyright 2017 Google Inc. All rights reserved.
Google Chrome	60.0.3112.78 (Official Build) (64-bit) (cohort: 60_78_win)
Revision	f901216ec1e383df23283fec9bc8f4e8b67aa0fb-refs/branch-heads/3112@{#671}
OS	Windows
JavaScript	V8 6.0.286.44
Flash	26.0.0.151 C:\Users\PhistucK\AppData\Local\Google\Chrome\User Data\PepperFlash\26.0.0.151\pepflashplayer.dll
User Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-renderer-accessibility --flag-switches-begin --enable-devtools-experiments --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path	C:\Users\PhistucK\AppData\Local\Google\Chrome\User Data\Default
Variations	98ee9f3e-98ee9f3e
ea8deb27-3f4a17df
241fff6c-4eda1c57
c68ab9a3-3f4a17df
3095aa95-3f4a17df
6c43306f-ca7d8d80
7c1bc906-f55a7974
47e5d3db-3d47f4f4
1c752ce9-33c3eba5
d43bf3e5-ad6ab04f
884ba84d-ca7d8d80
ba3f87da-b4a760c3
5ca89f9-3f4a17df
f3499283-7711d854
9e201a2b-1359b0af
5b3ed0a1-ca7d8d80
68812885-ca7d8d80
9bd94ed7-b1c9f6b0
b791c1b8-ca7d8d80
9773d3bd-ca7d8d80
2e109477-f3b42e62
99144bc3-132064d0
9e5c75f1-40093a1
f79cb77b-3d47f4f4
b7786474-d93a0620
9591f600-d93a0620
be3b5415-ca7d8d80
27219e67-b2047178
23a898eb-e0e2610f
d39326b0-d93a0620
e856c60b-ca7d8d80
4ea303a6-ecbb250e
3d7e3f6a-2eb01455
7aa46da5-669a04e0
64224f74-5087fa4a
56302f8c-2f882e70
de03e059-e65e20f2
f56e0452-ca7d8d80
b2f0086-93053e47
5eb7295f-ca7d8d80
6844d8aa-669a04e0
494d8760-3d47f4f4
f47ae82a-86f22ee5
3ac60855-486e2a9c
f296190c-a2200d3b
4442aae2-a90023b1
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-7158671e
e7e71889-4ad60575
288c530e-3d47f4f4
828a5926-ca7d8d80
a88c475d-3d47f4f4
90fec5c8-9bb9261b
Compiler	MSVC 2015 (PGO)

Deleted: gpu.htm 182 KB

gpu.htm 182 KB View Download

Thank you, tried the ZIP in #2, is this what you're seeing? The left is Chrome canary, the right is Edge.

Deleted: first-letter-658449.png 11.1 KB

	first-letter-658449.png 11.1 KB View Download

This is by design, because the content has

.article section > p:first-of-type:first-letter {
  line-height: .5em;
}

and ".5em" isn't enough for this "I". Make it to ".6em" to fix the issue.

Not what I am seeing. Much worse.
Same in incognito.

It looks fine in Internet Explorer 11 and Firefox 54 on the same machine.

Deleted: first-letter-issue.png 308 KB

	first-letter-issue.png 308 KB View Download

Interesting...on my PC, IE, Edge, Chrome overlaps (slightly) while Firefox doesn't. On the other hand, IE, Edge, Chrome has less padding-top than Firefox. Your screenshot indicates you disabled antialias/cleartype, maybe that's the cause.

Can you change ".5em" to ".6em" to see if it fixes?

This test has several absolute numbers assuming UA puts baselines at the very specific position, and font height be the specific value. The CSS has padding-top too:

.article section > p:first-of-type:first-letter {
  line-height: .5em;
  padding-top: .24324em;
}

and there's no guarantee that the bottom of "I" fits to ".5em"; it's UA/platform dependent.

Since it's so UA/platform dependent, W3C went to define a new property for drop caps:
https://drafts.csswg.org/css-inline/#sizing-drop-initials
but unfortunately this isn't widely supported yet, including Blink.

I changed it to 0.6em and it pushes the text.
Why would 0.5em overlap and not push the text, though?

(Note - this is not my website, I just detected an issue on the web)

Yes, I indicated in comment 6 that I disabled ClearType and font smoothing.

Deleted: first-letter-issue-with-0.6em.png 97.7 KB

	first-letter-issue-with-0.6em.png 97.7 KB View Download

The :first-letter has "float:left" without its height set, so the height of the float is determined by the content height. The page sets "line-height: .5em", which means "I don't care if lines overlap when the font is tall, just set the height of the line box to the value I set." It's similar to setting the 'height' property to a box; honor the author-specified height by allowing contents to overflow.

So the height of the float is set to .5em. If the (glyph+padding-top+leading-top+(some UA dependent paddng for ascent)) is shorter than .5em, you won't see the overlap, but it's not true in all cases. It depends on UA/OS/fonts combinations.

There are discussions in CSS WG to make line/inline layout more predictable and interoperable for over a decade, but unfortunately, none had really made yet.

I'll continue discussions there and hope we have something better in do future.

Forgot to mention, I understand you're trying to help. Deeply appreciated, as always.

#13 - :) I clarified just because your wording sounded as if you suggested that I am the author of the page :)

#12 - oh, yeah, I forgot about the line-height thingy, yeah. Got it. Just an unfortunately stray pixel that ruins everything. :)