Hacker News Reader

Comment by chrismorgan | Hacker News Reader

I’ve been tending towards the opinion that features like this are a bad idea: that we might be better served by a general “this is prose” signal that triggers things like Knuth-Plass line-breaking, partially-hung punctuation (not full, please not full, it’s awful), conservative hyphenation, maybe even spacing and stretching tweaks to reduce the need of hyphenation (like the CTAN microtype package provides), whatever else the user agent supports. Bundle it all up in an all/auto/none property that defaults to auto, and let browsers choose heuristics for normal content. (OK, so I wouldn’t limit it quite that hard, I’d make it a little more like font-variant, but I do believe the default should be heuristic-based rather than disabled.)

View on HN

The thing is, we cannot think of CSS being just for the browser anymore. More and more stuff are being typesetted or presented/designed using CSS: mobile and desktop applications UI, graphic design (the SVG vector format standard uses CSS), as well as all sorts of printed materials. Whether this is a good idea or not is another question, but it's a fact. So CSS kind of has to offer fine-tuned control over many things including tiny details.

See for example Paged.js [1], a way to use HTML and CSS to produce printed books, with complete control over the rendering and an attention to details almost of TeX level's. Using web technologies as source format tremendously facilitates the production of various electronic formats in addition to the printed/PDF version, such as ePub and well, web pages, which need free flow text that print-oriented format do not allow for obvious reasons.

All this to say, I agree with your feeling if we stick to web browsers, but CSS is so much more nowadays.

[1] https://pagedjs.org/

CSS specs are explicitly not interested in prescribing TeX-level control; text-wrap-style is a good example of this: it’s just hints, with the actual algorithms completely UA-defined. And in fact, they’re going out of their way to recommend including multiple distinct heuristics of prettiness, so that developers don’t use it as a proxy for just one thing and start relying on something that is explicitly and deliberately undefined. <https://github.com/w3ctag/design-reviews/issues/864#issuecom...> (And Chromium has done just this: <https://bugs.chromium.org/p/chromium/issues/detail?id=143279...>.)

In other words: you’ve already lost!

I understand this, but let's be more concrete: when you use CSS to design for print (that is, in general, to produce a PDF), you are using a specific implementation (e.g., Firefox will be used to produce the final PDF from your HTML and CSS, or Inkscape will be from your SVG and CSS). Given an implementation, you get a determined rendering, and it is this specific one that you need to be able to tweak to your needs. Same goes for application UI design: a given GUI framework comes with its own implementation of CSS rendering and it is its specific output that developers (or rather, theme designers) need to be able to have precise control over. In both cases, even if the standard does not precisely states what property values must give what rendering, you get something using the tools you have and you may want to tweak details to your taste using those same tools (even if only by trial and "error", but for that you need the option to fine tune the properties you want to play with).

Again, I'm not saying CSS is coherent nor that this is a good thing in the absolute sense, as I already said, I agree with your feeling, I'm just saying that I understand where the need of more precise control/tweaking over details that is sometime in the standard comes from.

You’re abusing CSS.

(Can’t say I never have…)

Well I'm not, but some people are, probably. The need exists. That's my whole point :).

HTML tables for layout FTW.

One example that I contribute to: https://homebrewery.naturalcrit.com

It is a code mirror app that outputs md styled like dnd books. It’s very much a “round peg in square hole” project, using html/css to create print materials, but for many it is good enough. It is just html and css, and allows customization, and precise styling requires precise css properties.

As you noted, it does only work well in one browser, Chrome on desktop (even though I think all the devs use FF as their daily driver). But as another commenter noted, the answer is that you design on one machine and share via pdf.

This is ridiculously well-done. Thanks for sharing.

> You’re abusing CSS.

In the spirit of "not a bug but a feature" I'd say they use is demonstrating the "full potential" of CSS...

Part of the perversion is that web standards demand "more than one implementation" (see WebSQL) so if we did the same thing and just "put TeX in the layout pipeline" that would get punted faster than SQLite was.

Text layouts being undefined is the last great tragedy of HTML, and we should fix it.

I once implemented a knuth style renderer to properly typeset books into html. IMHO If you want to do advanced typography you need to algorithmically set the width and offsets of spans and use spacer elements. Otherwise all that complexity has to go into the css spec and that will be a lot for what is otherwise a niche use-case. Another problem is that good typography is algorithmically expensive and is best computed ahead of time, rather than on page load.

Electronic books (EPUBs) are literally just HTML, CSS (plus some more standards specific to EPUBs).

Oh, tadpole...

I was once like you, thinking like "It's the web! I know this!" Turns out, no...actually you don't. I've been soaking in this for a couple weeks, trying to rid my life of the last few Word documents that I use frequently and haven't converted.

Writing HTML to mimic print layout is a bit creaky, but it's trivial compared to the kinds of shenanigans that EPUB often requires.

Despite what you might tell yourself, reader applications are not web browsers, and come with their own set of idiosyncrasies and corner cases, and will gladly barf all over your HTML or (worse) sit still and refuse to move no matter how much you cajole them.

https://getyarn.io/yarn-clip/34d4f471-2bf6-4e55-ba95-1419f20...

If web standards sometimes make you feel like ants trying to reach the top of a hill with bits of grain, EPUB might as well be rolling Sisyphus' boulder.

"It is not the web, it's the web as rendered by a schizophrenic, half crazed hamster in a wheel"

-John Siracusa

Well, Kindle books are formatted with CSS

+1 for padgedjs. I wish browsers would just implement @page on their own though.

But then you lose backwards compatibility and have no standard spec.

The compatibility hazard is negligible; hanging punctuation is the main one that can actually cause harm if misapplied, and conservative heuristics for enabling it are easily arrived at.

You might be surprised at how little of browsers’ existing functionality in these areas is actually defined, or in progressive cases how much is defined as being up to the browser.

When I mention things like Knuth-Plass: all current browsers use a greedy first-fit line-breaking algorithm, but IE actually had something better long ago in some situation (I forget), and until recently, the entire thing was simply undefined. Now, the default is declared to be UA-defined (text-wrap-style: auto) <https://www.w3.org/TR/css-text-4/#text-wrap-style> with the option to declare a preference for alternative modes like stable, balanced or pretty. Long before this, Firefox had a bug open about implementing Knuth-Plass or similar <https://bugzilla.mozilla.org/show_bug.cgi?id=630181>, and the only oppositions have been on technical implementation grounds, not that there’s anything wrong with the concept, which people generally agree is desirable.

As regards heuristics, you can define the heuristics to use completely, or you can leave it to browsers with some suggestions, or you can leave it to browsers. There’s plenty of precedent for all three of these.

The Microsoft trigger was `text-justify: newspaper` and intended for fully-justified narrow columns. I don't think it made it to Edge.

I believe it made it to Spartan Edge but not the switch to Chromium Edge.

> hanging punctuation is the main one that can actually cause harm if misapplied

Yeah, it can screw with layout. We recently removed it because it had seemed harmless to have it enabled so Safari users could enjoy it and other browsers would just ignore it, but then we discovered it was screwing up the layout on the main page's lists (https://gwern.net/index) and was not harmless after all. :(

It’s not like CSS implementations have been particularly strong in maintaining backwards compatibility.

> a general “this is prose” signal that triggers things like […] conservative hyphenation

At the least, that requires specifying the language of the text, probably even subtle differences such as those between UK and US english (although those can probably be handled very conservatively most of the time, as long words are fairly rare in English, compared to, say, Dutch or German)

`hyphens: auto` is already language-aware. (It’s just that currently it either does nothing or too much, because the first-fit line breaking algorithm is lousy for hyphenation.)

Is there a CSS setting for links not wrapping and instead being justified to a new line on Android devices?

Input:

  - URL1
    - URL2
      - https://longurl3

Output:

  - URL1
    - URL2
      -
  https://longurl3

I agree. On my e-reader I can choose to enable hanging punctuation. Why should a web developer be able to or be expected to make that choice for me?

A web developer shouldn't, but a designer should.

Otherwise, why bother with design?

How would you distinguish between web design and development?

How it's built vs what it looks like.

That's arguably a very limited view of design. Design is far more than aesthetics.

Design is visual engineering .. development is software engineering.

Both essentially involve solving problems.

I don't think this agrees with how the term is used. I've never heard of anyone being said to design a painting or a sculpture. Meanwhile, engineers are said to design things that aren't visible, such as algorithms or a circuits.

We're talking about web design.

If we consider art .. sculpture and painting do require planning, preparatory sketches or a maquette. Design thinking allows us to build and solve.

I don't see any obvious reason why design should come to mean pure aesthetics in this particular domain, and even if we do, what word is left to mean actual design work in the traditional sense of the word?

It doesn't mean pure aesthetics .. the way something looks affects it's affordance.

For the same reason a web page can choose what font to use even of your ereader has a feature to change fonts.

Why should the typesetter of a dead-tree book be able or be expected to make that choice for me?

Because it's impossible while it's not in the digital medium?

Don't tell the CSS zealots, but mainstream eBook readers (for the XHTML-based EPUB) basically throw the CSS away and reflow everything anyway based on a generic prose style with a heavily optimized serif and user preferences for font size. Most importantly, they're applying proper hyphenation and justification, as expected by book readers and unsupported by CSS for a much better reading experience compared to browsers. The extent of this might not be readily apparent in English language publications (with relatively short words and long phrases), but in German almost every other line has hyphenated words at the end (and I'm guessing in other languages with long composed words such as Finnish or Hungarian as well). EPUB uses extra tags for eg. spreading (responsive layout) anyway.

Reading EPUB 3 specs is almost comical when compared with the feature set of real world EPUB publications and reader software: CSS trickery (such as pointless SVG wrappers around raster images), yet not using floated elements even for the few cases where it's a good fit (initials, flowed images), using Unicode quotations and mdash/ndash, not using CSS paged media for pagination and line numbering, EPUB 3 reference examples crashing reader software, Amazon and Apple using proprietary EPUB extensions for these reasons anyway (and having good technical reason to) while not contributing to W3C, Inc's spec., ...

The last useful EPUB spec version appears to be 3.0. from 2014 before IDPF merged into W3C, Inc. Later versions reference the "HTML living standard" and CSS snapshots (with CSS-everything that no reader software is going to support, ever). To bring old reference examples into compliance with 3.3/epubcheck, the only thing the WG bothered to do was to put secondary headings into elements where they used <h2> in <hgroup> to match the changed spec (removal of the so-called HTML outlining algorithm). Great so this makes the reference examples nominally conformant, but leaves the installed base of eBooks out there without backward compatibility (and e-readers are far from evergreen browsers). Not that it matters anyway: calibre's conversion manpage strongly recommends and defaults to EPUB 2 anyway, supporting EPUB 3 only since 2019. In a way, EPUB 3.3 with its generic forward compat reads like the last spec its authors intend to publish, before the major organizational and funding changes at W3C, Inc in 2023.

I'm seriously beginning to wonder if PDF is the better format for reading and archival after all as 7+ inch reading devices become the norm (or don't they?)

> as […] unsupported by CSS

Actually, slap `hyphens: auto` onto the CSS (since its default value is `manual`), and whatever your ebook reader does for things like hyphenation and justification is almost certainly spec-compliant, because all of that stuff is explicitly UA-defined these days.

Interesting opinion. Why?

If these things are a good idea, they should be applied generally. Depending on individual sites to apply them, and individually at that, means that most sites will never get them, and that the “best practice” has an ever-increasing weight and burden over time.

The problem is, changes to the web platform need to be backward compatible. You can't make a global change without potentially breaking existing content. In this case, you could easily end up triggering scrolling in a bunch of places, or with punctuation being invisible or looking bad. So it has to be opt-in.

Refer to my response to jahewson. You can easily apply this to the vast majority of content with negligible hazard.

The "prose" signal exists, it's called the HTML tag.

That's p as in paragraph. also has some honestly pretty weird end-tag omission rules that makes it very unsuitable for any other semantic than demarcating a paragraph.

A paragraph... of what? Just think about it for a minute...

Of any sort of text, including but not limited to prose.

I don't know what you call "prose", but something that needs to be split into paragraphs is called prose in my book. Maybe you've been misusing the tag? Can you describe a situation where you've used the tag that wasn't "prose"?

Anything on verse for one.

That's a joke, right?

Reply on news.ycombinator.com