Very interesting read, aside from the issue at hand, I was really drawn to how they pulled off this kind of change in a giant org with many heads. Routinely, the root issue is easily addressable, however, it's a different story when it's something that's cross org. Usually you hit a wall and can't move forward without a consensus and some kind of org wide champion.<p>At the end of the day the process this team followed has all the hallmarks of a great culture (-- perhaps another article?). I'm curious what kind of management by-in was required, or if this was strictly driven by engineering and design.<p>God -- It really shows I've been in an enterprise for far too long. :,)
Breaks normal in-browser search, at least for me. Since dropcap is an established layout element, maybe it should be a style property instead, so that the browser can render it correctly and also allow for search.
I'm a fan of drop caps as a visual element -- they, along with a bolded lede line, very much help draw the eye to section starts, in a way which is very nondistraction (IMO).<p>A recent example, adding drop caps (and a number of other styling changes) to unv.is:<p><a href="https://mastodon.cloud/@dredmorbius/102329333215634483" rel="nofollow">https://mastodon.cloud/@dredmorbius/102329333215634483</a><p>Because I'm restyling a page, that's restricted to CSS-only methods, which for that site works marvelously. And on the principle of divorcing content and presentation, it appeals strongly.<p>But on Wikipedia/Mediawiki, attempting to add drop-caps + bold lede-line results in a very annoying sift of the text offset by the drop cap *merely by defining a selector for ::first-line (Firefox/OSX):<p><a href="https://mastodon.cloud/@dredmorbius/102329661015728246" rel="nofollow">https://mastodon.cloud/@dredmorbius/102329661015728246</a><p>Somewhat maddenning.