

Adobe and Google enhancing WebKit for better typography - kreek
http://blogs.adobe.com/jnack/2010/11/adobes-enhancing-webkit-for-better-typography.html

======
aristus
:( No hyphenation, kerning or leading. Knuth and Liang solved this problem
decades ago. I dislike like having to hack it with Javascript. That lack is
what makes web typography ugly, even in this demo.

~~~
foljs
Yes, they solved it alright.

In an entirely different context.

~~~
RodgerTheGreat
Can you point out some reasons the algorithms in TeX cannot apply to reflowing
text in a browser, rather than a static page? It seems like a very similar
context to me.

~~~
neild
My understanding is that the reason WebKit does not use the TeX layout
algorithm is performance. WebKit has a zero-tolerance policy on performance
regressions; the only way the TeX layout algorithm will make it in is if it
can do so without sacrificing rendering speed.

~~~
aristus
You tempt me to try submitting a patch. I suspect it's a bikeshed problem, but
I could be wrong. There is no technical reason why you couldn't enable it only
on elements with a "-webkit-hyphenation" CSS rule. Then it's not a regression,
it's an optional feature.

You are right that there are real perf concerns. A web page reflows multiple
(sometimes hundreds) of times during pageload, unlike a print document.

~~~
RodgerTheGreat
TeX was designed to work on computers of the late 1970's. It seems pretty
reasonable to think that algorithms that were practical to execute then can be
carried out more or less instantaneously on machines available today. If you
think you can pull off a port, by all means try.

------
gallerytungsten
This is an interesting demo, but it seems to focus more on "whizzy" things,
instead of fixing more basic problem.

Now, in their defense, I thought the baseline alignment idea was pretty good.
But if you look at their first demo of the "callout" text, you'll note that
there are horrible rivers (open spaces) running through the type, making it
look all clunky.

What's really needed is a straightforward wysiwig layout tool (like Quark or
Illustrator, for example) that can generate clean CSS layouts.

------
itg
Interesting response in the comments section

[http://bureau.tsailly.net/2010/11/wow-adobe-is-really-
cool.h...](http://bureau.tsailly.net/2010/11/wow-adobe-is-really-cool.html)

~~~
amadiver
That article would have been a lot more useful if they reduced the snark.
Thank you for linking it though.

~~~
thwarted
Snark indeed. All of paragraph 5 could have been left out.

 _As for the communication part, there is a name which, because it is omitted
with so much efforts, can only be noticed: Apple. They are working with Google
to enhance Webkit, not Google and Apple, the originator of Webkit._

Apple was, apparently, so slighted by this ommission that we have to forget
that Apple derived the WebKit code from KHTML. "Originated" is kind of a
strong word.

<http://en.wikipedia.org/wiki/WebKit#Origins>

~~~
GHFigs
Snark indeed.

------
starpilot
The least they could do is have the q tag render with smart quotes. This is
already handled in Firefox properly.

~~~
masklinn
> The least they could do is have the q tag render with smart quotes

Fuck no. I will decide on the fucking quotes I want around my quotes, unless
you decide to cleanly and perfectly support all international quote style
guides[0], you do not touch the content I create and you do not start changing
my quotes.

[0] [http://en.wikipedia.org/wiki/Quotation_mark,_non-
English_usa...](http://en.wikipedia.org/wiki/Quotation_mark,_non-
English_usage)

------
wdewind
Web kit is a fail that has a tiny percentage of the browser use. Safari has
too small of a % to be relevant (except mobile obv), and Chrome just screws up
too many small things (despite being an otherwise overwhelmingly better
browser than the alternatives).

~~~
masklinn
> Web kit is a fail

How?

> that has a tiny percentage of the browser use

Yeah, on the desktop, now consider the fast-growing mobilespace.

iOS? Webkit. Android? Webkit. WebOS? Webkit. Blackberry 6? Webkit. Bada?
Webkit.

And they're making deep inroads in libraries (QtWebkit, which means all of
Nokia's future is likely linked to webkit as well) and embedded in software
(Steam switched fully to webkit a while ago).

Webkit definitely isn't "a fail". Not in the long run (it will keep growing in
importance) but not right now either, it's given a good kick to the 'nads to
the Mozilla team, it iterates and develops fast (and is a standard driver),
it's where innovation now happens in the OSS browserspace (the other source of
innovation being mostly Opera) and the sole reason we have mobile browsers
worth using these days is webkit. Webkit is a resounding success considering
the first public release was 7 years ago and pretty dreadful.

~~~
wdewind
I guess you ignored the part where I said except mobile obv.

My biggest issue with webkit is that there was a perfectly fine rendering
engine to begin with that both Safari and Chrome could've simply built a new
UI around. Instead they gave us yet another OS to support.

Web developers complain all the time about supporting multiple browsers, yet
support web kit?

And for the record, steam is a great example of what I'm talking about:
completely mediocre rendering performance for really simple tasks (essentially
a web browser). It's shocking how bad web content looks in steam, I'm kind of
surprised you even brought it up.

Yes - Webkit long term will be good, it can't not (even IE9 is looking alright
at this point). Right now though (ruling out IE6), > 50% of my web dev cross
browser issues are dealing with web kit, not IE7+, and for a much less
significant audience (ie: expensive).

So you're right, it's not a "fail," but I think how great the response is to
it is really disproportional. I REALLY want to love chrome etc but I just
can't - it's not ready yet.

~~~
naz
> My biggest issue with webkit is that there was a perfectly fine rendering
> engine to begin with that both Safari and Chrome could've simply built a new
> UI around.

You're right, there was. It was called KHTML, and they did.

~~~
wdewind
<http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29>

Not that it really matters for the sake of the argument, because my point was
that gecko was widely used already whereas KHTML was not and so they should've
used it instead, but gecko was also around before KHTML.

~~~
pyre
When Apple announced that they were going to use KHTML in Safari (when they
announced Safari) they stated that it was due to the library's small
footprint. I assume that they didn't want to spend the time to reign in the
Gecko engine to do what they wanted it to do (or hack/optimize it down to
size).

Just because something exists and seems to be 'good enough' doesn't
necessarily mean that it would be a good fit. Unless you develop for WebKit,
Safari, Firefox and/or Gecko, I'm not sure any of us are really qualified to
make those kinds of statements. Also remember that you can't compare the
current state of the two codebases. You have to compare the state of the
codebases at the time that Apple created Safari/WebKit.

~~~
wdewind
Agree to disagree, but I hope you don't complain about browser fragmentation.

