
The State of Web Type - robin_reala
https://dev.opera.com/articles/state-of-web-type/
======
dghf
> Browsers could implement the same line breaking algorithm as used in TeX,
> but have decided not to for performance reasons. This is an odd reason — TeX
> was developed and runs on computers much less powerful than those commonly
> used in mobile phones.

Yes, but not at a speed that many would find acceptable for formatting a web
page, even on a modern computer.

Nor need it be: you only have to generate your (La)TeX document while creating
or editing it; a couple of seconds for a short document is thus tolerable.
Whereas a web page has to be formatted by every visitor on every visit --
maybe several times if they resize their browser. It needs to be more or less
instant.

~~~
jacobolus
There’s clearly a trade-off here. Personally I would love to have a page that
I’ll spend 30 minutes reading take 1 second longer to render in return for
dramatically better paragraph composition.

~~~
dghf
Fair point. It sounds like the ideal would be a browser setting: fast-and-
dirty justification for the impatient vs TeX-style line-breaking for
aesthetes.

------
joshuapants
Interesting, I would have figured that Apple would be tops in typography given
their pedigree. Even weirder that (recent) IE does so well in this space.

~~~
mkozlows
See also the recent "Safari is holding back the web" articles. IE is
historically awful, but modern IE is generally better than modern Safari.

~~~
arclight
Do you have a link to this series? I found some articles on the subject, but
nothing that looked like what you were describing.

Thanks!

------
mkozlows
I'm more skeptical of the benefit of auto-hyphenation than the author is; it's
been my experience that even with a proper hyphenation dictionary, you get
some weird hyphenations that you want to manually undo (or force).

Which means that if you're working with print, where you can do those
corrections/fixes, hyphenation is great; let the algorithms work, do your
little bit of fine-tuning, and it's good. But on the web, you can't do your
fine-tuning, so it's auto or nothing -- and "nothing"/unjustified text
typically has less annoying failure modes than auto-hyphenated/justified text
does.

And I think the author is flat wrong about preferring unstyled content flashes
over delayed rendering of content that's waiting for a font. The unstyled
flashes are massively distracting and disorienting to a reader; the delayed
rendering just makes it seem like the page is a bit slow to finish loading.

~~~
KwanEsq
> But on the web, you can't do your fine-tuning, so it's auto or nothing --
> and "nothing"/unjustified text typically has less annoying failure modes
> than auto-hyphenated/justified text does.

Can fine-tuning not be achieved with the soft-hyphen [0] and the word joiner
[1] ?

[0]
[https://en.wikipedia.org/w/index.php?title=Soft_hyphen&oldid...](https://en.wikipedia.org/w/index.php?title=Soft_hyphen&oldid=625641896)

[1]
[https://en.wikipedia.org/w/index.php?title=Word_joiner&oldid...](https://en.wikipedia.org/w/index.php?title=Word_joiner&oldid=644348648)

~~~
mkozlows
You can't see the rendered-on-the-user's-screen result, is the thing, and
dynamic layouts mean that it might appear differently in different places.

------
buro9
The link is good [http://stateofwebtype.com/](http://stateofwebtype.com/)

But it doesn't detail the real-world differences in hyphenation support. We
ultimately chose to disable features that were claimed to be supported as the
support was there but inconsistent.

A great start though, but it would be nice to also see the CSS and examples
for each browser cited as supporting something.

------
alricb
One potential issue with Web fonts: security. The formats are notoriously
complex, and FreeType has had a lot of vulnerabilities related to that.

