>The implementation will look vastly different if you define 'where' as a printer, desktop, tablet, mobile phone, wearable device, etc.
Not since more than a decade ago, when we started using the same rendering infrastructure (e.g Display Postscript, Quartz, Cairo, what Windows uses etc) for both print and display.
In fact nowadays, with hidpi (retina) displays, you even get similar resolution between the average print and monitor.
HTML and CSS are very, very explicitly not WYSIWYG. Their specifications are crystal clear on this point. The same HTML document can and should be displayed differently depending on device.
Your ebooks are also not WYSIWYG. They're also specifically designed to display differently on different devices, and according to user preferences for things like font, text size, brightness, background, line spacing, etc..
WYSIWYG is exactly the opposite of these formats, and does not depend on the device. Postscript and PDF are WYSIWYG.
It's because you're not looking at the data in a WYSIWYG environment. If I take an Acrobat document or MS Word document, print it, and look it next to my screen, I'd expect the layout and 'look' to be perfectly identical (barring blurriness due to one-or-others resolution limitations)
That "all three use Display Postscript, CoreGraphics and Quartz" doesn't mean they use the respective drawing context as it's intended for screen/print work.
Editing LaTeX with Vim on a Mac also uses Quartz to render the Vim window, that doesn't mean that you get what I talked about.
With respect to your examples now, HTML and ePub/Mobi don't guarantee they are WYSIWYG and stable between different viewing devices and contexts. On the contrary, for example even something as basic as the line width can change by making your browser or eBook reader wider.
That said, they are not the standard output of WYSIWYG editors we were talking about either (despite some WYSIWYG editors being able to save in those formats too).
Word, Pages, Open Office et al have print view modes that look identical to what will be printed. As do programs such as InDesign, Quark XPress, etc.
Not since more than a decade ago, when we started using the same rendering infrastructure (e.g Display Postscript, Quartz, Cairo, what Windows uses etc) for both print and display.
In fact nowadays, with hidpi (retina) displays, you even get similar resolution between the average print and monitor.