from Hacker News

Drop Caps and Design Systems

by willlll on 6/25/19, 9:40 PM with 9 comments

• by johnnyAghands on 6/26/19, 4:32 PM

  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.

  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.

  God -- It really shows I've been in an enterprise for far too long. :,)

• by dusted on 6/26/19, 11:15 AM

  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.

• by dredmorbius on 6/26/19, 7:02 PM

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

  A recent example, adding drop caps (and a number of other styling changes) to unv.is:

  https://mastodon.cloud/@dredmorbius/102329333215634483

  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.

  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):

  https://mastodon.cloud/@dredmorbius/102329661015728246

  Somewhat maddenning.