I find, though that full-hung punctuation is a bit much. When I was publishing Serif in the 90s, I did half-hung punctuation where punctuation at the beginnings and ends of lines extended just half the width of the character. Most software makes this pretty much impossible,¹ although there are sneaky ways to do it manually: I wasted some time making a nice title page for the manuscript of the novel I’m writing,² titled, We, the Rescued and I set the “We,” on its own line, centered, but it looked off that way. putting a white comma before We helped, but now the off-centeredness went the other way, so I changed the type size of the white comma to half that of the black comma and boom, everything looked much better.³
⸻
1. I did it in TeX. I had to make modified versions of the fonts that had a separate hyphen character which went past the margin and insert manual \penalty0 points after en- and em-dashes since they no longer automatically were breakpoints since the hyphen was not the hyphenchar.
2. Despite my typographic background, I generally try to avoid spending time on manuscript formatting beyond the absolute basics.
3. Still not exactly half-hung punctuation with this trick. The exact hung fraction is left as an exercise to the reader.
You never want it to stand out, you just want everything to look balanced.
A slight amount of hanging looks like it's not hanging at all -- it just looks right. The same way the top and bottom of an 'O' are higher/lower than the top and bottom of an 'X', even though it doesn't look like it.
It's all about visual weight -- how the eye perceives it.
Fully hanging punctuation is just way overdoing it.
Try to follow that baseline with your eye. It's a roller coaster of chaos.
Type designers like to add overshoots merely out of habit, not aesthetics. They might have made sense in the lead type era, but simply look like mistakes today.
They're not hideous. Overshoots sage there because at normal reading sizes sizes, or on poster sizes read from far away, if letters like o, n, O, A, etc. don't have overshoots, then they'll look too small compared to the other letters, even though they're technically the same size. It's an illusion that type designers work around using letter overshoots.
Look at sequences of capital letters in Kabel a typeface which doesn’t use overshoots and you will see that you’ve been ignoring overshoots all over the place.
> Most software makes this pretty much impossible…
I've definitely gone through similar machinations to achieve something less extreme than full "Roman Hanging Punctuation". If you ever need to do this again, Adobe's "Optical Margin Alignment" and Affinity's "Optical alignment"¹ are worth checking out.
Any amount of overhang is too much. It makes the edge of the container look bumpy and messy.
Even if you think it looks stylish, it nonetheless creates a semantic distraction: it makes paragraphs that start with quotation marks look different from paragraphs that don't, when there is no intended difference in meaning. It costs the reader effort to remember that things that look different are actually supposed to be the same, and reduces your dynamic range for visually conveying meaningful differences.
If you want to stylize a quotation mark or draw attention to it, make it a special graphic element, clearly outside the container. Be deliberate. But don't violate the container boundary by misaligning a quotation mark that's part of the text flow; that just looks like an error.
> Any amount of overhang is too much. It makes the edge of the container look bumpy and messy
Quite the opposite. When you look at most fonts in detail, the topmost parts of e.g. AEO will differ slightly; this is because visually, the pointed top of the A has much less 'mass' than the flat bar that is the top of E; the O will be higher than the top of the E bar as well. The same applies to the left and right edges; it's not a matter of taste, it's physiological. In so far a truly 'optical margin' or whatever Adobe chose to call it would have to take into account the shape of each singly glyph, not only punctuation. Quotes are only always mentioned because they're the most obvious application; full stops, commas, hyphens—all of these dittels have a minimum of 'flesh' and should therefore be pushed further than, say, an X or an M.
But I agree that putting a double quote 100% outside the left margin is a bit too much of a good thing; my guess is that it should be more like 50% or somesuch to avoid the "bumpy and messy"ness that you rightly dislike.
The idea that overshoots are necessary to create the appearance of equal height is a myth; you can see for yourself that they are clearly visible as irregularities when you run your eye along the baseline, mean line, or cap line.
Man you're doing it wrong. You're like that guy in the old MAD Magazine cartoon who wants to look at the mountains with a binocular but happens to see his wife's face in ultra-macro and goes "eew mountains are gross".
It's not like typographers can't see that these orderly lines that you crave are 'overshot' by the glyphs, they sure do! And it's not necessarily an effect that works at constant ratio for every magnification either; the overshoot in a font intended for footnotes is probably different from the overshoot in a font designed to be displayed a meter high on the sides of a van.
In your other comment you say it's a 'holdover' from metal type. "Holdover" is such a dog whistle word you know, it always comes from people who want to do away with accumulated wisdom, who claim that "we can do this better now" (i.e. now that we have digitized every aspect of life); they more often than not are not willing and not prepared to recognize Chesterton's fence, they just want to rid the world of any kind of perceived messiness. All lines must be straight.
Other than that, there certainly are details in type design that are there solely to accommodate for hot metal typesetting, but overshoot as such is not. And your super-macro-closeups aren't proof of anything, they just demonstrate that overshoots are big enough to be clearly seen when enlarged. Type designers have been aware of this fact for centuries. Also, as for the https://live.staticflickr.com/5300/5482446696_1fa1ff2b45_b.j... one, where you write "Hideous. Try to follow that baseline with your eye. It's a roller coaster of chaos." that's just you disliking a type design that is somewhat playful.
You prolly dislike cursive handwriting for all the same reasons. You do you, but BRRRR.
I doubt the designer of the font in that image was trying to make the letters look different sizes for fun. If that was the goal, though — great, mission accomplished!
You say it's wrong to judge overshoots by these examples because the text is too large. Okay. Show me an example of appropriately sized type that looks more _uniformly sized_ with overshoots than without, and I'll agree with you. (Remember, the justification for overshoots is uniform optical size, not playfulness!)
First off the bat, I dislike the FedEX typography at least as much as you; it is not a very sensibly, sensitively done design. With that out of the way, let me start with a few quotes.
The first emphasizes that overshoot is just one of many aspects of typography that require the designer to tweak forms; the platonic, geometric ideal has to be adapted to the realities of human perception:
Typefaces are born from the struggle between rules and results. Squeezing a square about 1% helps it look more like a square; to appear the same height as a square, a circle must be measurably taller. The two strokes in an X aren't the same thickness, nor are their parallel edges actually parallel; the vertical stems of a lowercase alphabet are thinner than those of its capitals; the ascender on a d isn't the same length as the descender on a p, and so on. For the rational mind, type design can be a maddening game of drawing things differently in order to make them appear the same.—Jonathan Hoefler & Tobias Frere-Jones [1]
This fact has been well known the world over and throughout the ages; for example, in the game of go, the stones, which are black and white, are of slightly different sizes (black slightly larger), to give the appearance of being the same size [1]
Likewise the Parthenon in Athens: "[The Greeks] achieved global perfection through deliberate departure from local precision. Minor geometric irregularities were incorporated by the architects to enhance the beauty of the building. It is paradoxical that these modifications create the impression of great geometric perfection, even though they involve deliberate departures from strict regularity." [2]
As for type design, the maybe most geometric-in-appearance modern typeface in wide use, Futura by Paul Renner (1927) is not perfectly geometric: The design of Futura [...] makes subtle departures from pure geometric designs that allow the letterforms to seem balanced. This is visible in the apparently almost perfectly round stroke of the o, which is nonetheless slightly ovoid, and in how the circular strokes of letters like b gently thin as they merge with the verticals. Renner's biographer Christopher Burke has noted the important role of the Bauer Foundry's manufacturing team in adapting the design for different sizes of text, a feature not seen in digital releases.
As becomes evident from the last sentence and as is widely known by graphic designers, many / most digital typefaces forego adaptation to different perceived sizes (I'd say that is one major culprit in what makes the FedEX logo so awkward: they just took a design that would have worked well for a magazine headline and blew it up to cover a room-sized area). In so far overshoots are not a holdover from metal type; rather, digital type through it's negligence of established designer sensibilities has produced awkward and ugly results that more traditional craftspeople would've been ashamed of (this BTW is quite parallel to the discussion around putting two spaces after the full stop).
I refuse to show you another image to which you will doubtlessly just reply "meh, overshoot bad". It's also a matter of taste.
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.)
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.
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...>.)
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.
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.
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.
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.
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"
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.
> 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. :(
> 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.)
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 <p> 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?)
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.
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.
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?
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.
That's p as in paragraph. <p> also has some honestly pretty weird end-tag omission rules that makes it very unsuitable for any other semantic than demarcating a paragraph.
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 <p> tag? Can you describe a situation where you've used the <p> tag that wasn't "prose"?
Matthew Butterick, of typography and Racket fame, used a neat and/or slightly insane CSS hack for hanging punctuation in his online booklets, leading me to a round of web-inspectoring some years back:
He programmed his site builder to insert two elements at the site of the punctuation:
E.g. the first elements pushes the following element further back, but the second element pulls itself back in that negative margin. The resulting effect is that in normal flow both the positive and negative margin of these cancel each other out, leading to quasi normal inline flow:
text text text text PUSH↔PULL text text
But if there is a line break between the elements the the push element pushes invisible into the right margin and the pull element pulls itself in the left margin, leading to hanging punctuation:
text text text text text text PUSH→
←PULL text text text text text text
So the trick with negative margin not only works at the beginning of block elements but inside the inline flow without leading to a negative experience - e.g. it also works with unpredictable line lengths.
I really like the going of the extra mile, although now with `hanging-punctuation` it is unnecessary.
Note: Butterick programmed his own site builder - Pollen - and designs his own fonts - that makes such customisability more achievable, I assume. Not the biggest fan of using custom elements instead of span but modern HTML and web components makes this syntax valid.
This is pretty much the typical way things are done in TeX: having glue or penalties that “cancel out” in the usual case but do the right thing when line breaks are involved. Unlike CSS that has lots of special cases and keeps adding more, TeX has a very simple algorithm for breaking paragraphs into lines, but the box-glue-penalty model is general enough that a lot of things can be achieved with it. (I like the way these are explained in the paper by Knuth and Plass; see e.g. https://tex.stackexchange.com/a/469908 and https://tex.stackexchange.com/a/423578 .)
Why is it a no no? My personal rule of thumb is that as long as Reader Mode can render it fine (which implies coherent semantics), then the markup can do whatever it likes.
Imagine there was a hobby that was as marginal to ham radio operators as ham radio is to the rest of the population. That is about how relevant user stylesheets are.
I think simple changes like changing fonts etc would be more popular if people knew they could. But it's not made easy nor is it generally effective on badly designed websites (most of them).
Yes, the users of Stylish, Stylus, usercss.com, TamperMonkey, GreaseMonkey, ...
It's definitely not a 'regular user' thing, but I'm fairly sure it's more common than things like 'r/unixporn', or theming Linux to look like Windows XP or macOS, that are themselves quite large niches.
I think I've seen it on quite a few sites. It would be nicer if you could do a ::before and maybe also specify pull width to be the width of a quotation mark:
(I think you can do something like that with container query units [1], but I haven't managed to do it just yet.)
UPD: container query wouldn't work here because if you set `container-type: inline-size` on dquo-pull, it will get inline size set to zero, as if it had no content [2].
If I remember correctly, pseudo-elements act as they are children of their "parent" element, e.g.
<dquo-pull><::before></::before>... </dquo-pull>
In that case the ::before element doesn't linebreak independently from its "parent" element and so those two elements are always together, even at a break before the start of a new line.
You could set `display: contents` on the outer element – this will put ::before in the parent flow instead. But then the quote mark becomes a text node and you can't pull that back without another wrapper element:
And then she said:
<char-hang><span>“</span></char-hang>Hello,
handsome! What a day, huh?
which will be rendered like this:
"And then she said: "
<!-- push: -->
<char-hang::before />
<!-- pull: -->
<span>“</span>
"Hello, handsome! What a day, huh?"
Without adding another element, you can use a hack though: make the quote mark transparent and use text-shadow to “move” it back instead: https://jsfiddle.net/utjxnv1r/3/
And if we allow JS, we can just create a custom element and avoid those hacks altogether (also you don't have to calculate / eyeball the offset you need anymore): https://jsfiddle.net/c72uLtma/
Pollen is really impressive, for programmers it's probably the most accessible way to get professional quality typesetting for web and small documents. I use it for my resume, contracts, flyers, anything intended to printed out.
It's missing some tools you'd need for full printed & bound books but it can cover pretty much everything else. Learning curve is acceptable if you know css well and lisp somewhat. Might be a struggle if not but still more flexible for a beginner than luatex I think.
That sounds cute but potentially expensive: a span for every single double-quote in the page! I know Butterick's pages are short and don't usually feature lots of quotations or bibliographies like mine, but still.
I've always liked the visual effect of the East Asian typographic rule that commas and periods at the end of a line hang. Makes the entire block of text look better aligned.[1] Probably matters more for text in those languages since the width of normal text characters doesn't vary as much as Latin text characters do.
e. More to the specifics of its use in CSS, it looks like Safari doesn't support the attribute to aggressively follow that rule,[2] as in the bottom right example of the previously linked image.
> The hanging-punctuation property in CSS is almost a no-brainer
For me it's a brainier. Neither is better or worse, it's just different. I prefer having hanging-punctuation off by default because the text fits into its container, but if I was making something fancy for some reason I might turn it on.
Because the punctuation hangs off the edge, if you don’t have any available space, it can trigger a horizontal scroll bar, which sucks
Awesome" CSS model on top of a regular (quite limiting) box model in action. Now if you want to have a specific padding, you have to calculate how much space that quote took and subtract it from it. CSS is full of bs like that. Feels like it was taken for its first principles. I don't get how people praise it. Maybe they don't work with it often and only build chains of paragraphs with bells and whistles, while frameworks do all the heavy lifting and conceal learning cliffs.
Before receving arguments on Complexity and Layouts and Variety, I'd like to test HN. Please solve this easy puzzle and explain why your solution is logical, intuitive or sane:
You encounter the following html+css code in a mudball of a frontend.
Make .rest vertically (i.e. up and down) scrollable without the help of the internet and without checking your solution or comparing to others before posting. Just post what you think should work and (very optionally) your YOE in CSS/Web. Also feel free to ignore it. Upvoted solutions will receive score. Good luck!
But after clicking around you realize that it does not anymore. Waaat? Maybe it's related to sidebar visibility changes? You open the inspector and see that .parent is {display:block}. Seems like some jQuery code assumed that display property is either `block` or `none`. Or something. Aaargh. The "sane" attribute of this solution was violated due to its non-locality to the `.rest`. Who could think that changing the display mode for the parent, which is indeed a private property of the parent, would lead to such an issue. You live and you learn css!
(Also, explanations for "intuitive" and/or "logical" are still missing.)
ah yes, jQuery. Indeed hide()/show() just set css to display: none/block, but it can vary (inline/flex/...).
CSS is a bit of a mess the last few years, with so many caveats... Just look at why position sticky will sometimes not work: "If you are trying to use position: sticky and it is not working, it is because one of the elements wrapping it is using overflow with a value of hidden, auto or scroll."[1]
But it's weird, it should work, or at least this should be documented somewhere. Also why should overflow: hidden break the functionality... If you know all the caveats of css, then you can safely say "I know CSS".
Speaking as someone who is dyslexic, please don’t do this. It might look “prettier” (though even that is purely subjective) but it also creates a wall of text that is much harder to read.
It’s conversations like this that make this site such a pleasure to read. The original article plus the commentary here gave me a ton of context I wouldn’t have had any other way.
I am a typography nerd, so naturally I love this. I also think it would be most useful with text set in full justification, where you have your text in a nice rectangle and punctuation sticking out destroys the aesthetics.
If full justification is helpful in general is another question but it certainly is out of fashion now.
If full justification is possible at all with the currently used browser rendering pipelines is yet another interesting questions. Intuitively I would have assumed so, but I remember past discussions here on HN that convinced me that this is not easy at all.
EDIT:
I liked the HN thread I was referring to below. I think good full justification needs Knuth-Plass but don't know enough to be sure.
Maybe it's just because I'm so used to text not doing this (or at least failing to notice it except in rare cases like big magazine insets where it stands out), but I actually kind of hate it for normal paragraph text? It just looks weird and wrong to shove the quote-marks right out of the normal flow of paragraph text to me.
There's no right answer— it depends on leading and tracking, type size, presence of drop caps, proximity to other elements such as pictures, other columns, or the edge of the page, etc etc etc. Just like everything else in graphic design, it's all about the way something hits in context. It's just one element of a whole.
I’ve started using a sort of hanging quotation style for block quotes in commit messages.
From commit 3927bbe9a4:
“ This matches the behavior of COMMIT_EDITMSG, which stays around
in case of error.
Two spaces, one quote character, one space, then the quote on that
indentation. This might look a bit off with a proportional font.
Linus Torvalds[1] uses a kind of hanging quote for his merged pull
requests. But it looks a bit too subtle since the quotation character hugs
the first character.
I would never notice this. Seems such an edge case that it would only pollute the namespace of properties. There are already so many properties to learn, and something that you will use once in your lifetime does not belong in the language itself.
The existence of this property kind of dances around the real problem. The quotes should be omitted entirely because in a block quote you already know where the quotation begins and ends, additional punctuation adds no value, only noise. We wouldn't be trying to hang the leading quote off the side to get it out of the way (because it conveys information we already have and thus only gets in the way) if we just excluded it altogether.
It depends. Some of those examples look good, and some don't. In a big block quote it looks the part, like a magazine. Also the cyan line in Julia's blog makes it look good to me for some reason. I think it is the association of that line with a paper workbook.
> In a big block quote it looks the part, like a magazine.
Doing a google image search for "magazine blockquote" isn't giving me anything with hanging punctuation, just oversized decorative quote marks, mostly at opposite corners of the blockquote box, sometimes even just the opening one. Most of them are also in a different color than the text.
I agree. I don't think it looks better at all, and I feel it makes the structure of the text somewhat more difficult to see.
I have this reaction to a lot of established typographical rules actually. Digits with descenders to name just one ("font-variant-numeric: oldstyle-nums" in CSS): I think they're ugly and make reading numbers unnecessarily difficult.
I feel like CSS has grown too much and has too broad scope now - I didn't even know that properties like 'text-indent' and this punctuation one even exist and I'm doing web-development related work.
The problem with CSS is that one cannot just learn and use new features because usually it's unsupported by at least on of major browsers for an indefinite amount of time - after few months/years it's easy to forget that something significant/important/useful could be possible to do with CSS - and of course in meantime more new features and properties are being added.
There are people who deal with css and typography on web full time. Those people surely remember css rules that exist. It's fine, allow them do nice websites.
Btw text-indent is not some crazy new css unused thing it's actually very old (like 20yo) essential type setting rule. It's from times where CSS was mostly occupied with text documents, floats and inline elements.
If you look at the recent CSS additions It's all stuff concerned with responsive layouts and effects - very little to do with typography. It makes sense since web became app platform more than document platform.
It's understandable given its history but sort of wild how robust the support is for text / document formatting in HTML, compared to the much better than it used to be but still fairly anemic layout support.
Same browser, and same result (probably). The left negative margin on the first line is too large, the initial "i" is too far to the left and overhangs the line.
O.45em vs other sizes probably depends a lot on font/rendering/minor details that the website may not be able to control.
The point of much punctuation is to help inform the parse, and understanding semantic intent. This is why I find the whole "two spaces after full stop not needed" thing to be a very odd argument: Those spaces aided reading. They had a purpose.
Quote blocks are embedded, nested structure. Sure seems to me like a punctuation model and a layout model which can understand that, is net beneficial.
I always liked the french <<this is a quote>> model. Somehow it felt more like an embedded thing.
Double quotes have the additional burden MICROSOFT WORD I AM LOOKING AT YOU of the random interpolation of what the editor YES MICROSOFT WORD I MEAN YOU thinks it knows you meant to say. Additionally hijacking the text into badly encoded iso-latin1 or utf-8 mis-parsed, as a free gift.
if I mean to say:
“a quote” (left and right double quotation mark)
I will say it. When I say
"a quote" (apostrophe, used twice)
please.. leave those quote-marks alone.
(double-dash to em-dash.. same problem: free uplift to UTF you didn't ask for)
Did they though? When I read old books vs new books, I don't notice the difference at all. Especially with justification, spaces are already quite variable per line.
I don't think it aided reading at all. It was just a kind of random convention -- maybe somebody thought there was a logic to it -- that got dropped because it wasn't doing anything. One less rule to worry about.
A study showed that it's hard to measure any difference in reading speed and there is no difference in comprehension.
The difference in reading speed only applies to people who are used to double-spaces, there is no difference in reading speed single-spaced vs. double-spaced for people who are conditioned to read single-spaced.
> Although the type of spacing following punctuation marks did not seem to have an effect on those individuals who type with one space after a period, those who type with two spaces after a period had greater reading speed when paragraphs were presented in the same way in which they type: with two spaces following periods and one space following commas.
I'd argue this data suggests the double-spaces are a waste of space that accomplishes nothing except slightly handicapping people who become accustomed to it and then read text without it.
Yep, I use vimwiki where it's all monospace, and two spaces between sentences is a massive readability benefit there. I also type it when making comments here because these input boxes are also monospace, even though the extra space isn't displayed after posting.
Guillemets require using space around them («wrong», « correct ») which makes typesetting so hard as you have to hunt for each guillemet that fell to the next line to manually fix it.
And even that's not possible on the web, so you have to get used to dangling punctuation.
In LaTeX it’s quite easy to change the kerning so that one needn’t leave a space in the plaintext. It’s akin to e.g. east Asian full-width Unicode punctuation marks, or even slightly dated English typography (when there was a little more space before most semi-colons).
I’m pretty sure there is a setting in Word that allows you to turn off the automatic conversion of quotes. And I think that defaulting to performing the replacement is sane, as most people do just type “"” whenever they need any quotation mark and cases where “curly” quotation marks are appropriate are much more common than straight-quote cases outside of tech-related contexts.
"There is some risk to the property. Because the punctuation hangs off the edge, if you don’t have any available space, it can trigger a horizontal scroll bar, which sucks. This is probably why it’s not a default. It’s rare there is zero space on the edge of text, though, so meh."
If you're a designer looking to design to the point of using this styling, you're going to be adding the padding/margin to allow for that space. I would agree that having it set to off is a good default. I like when defaults are sane.
Not just sane, also safe. Designers will add the needed padding but people just banging together a site will not and this default then saves us from scrollbars.
#/media/File:Kabel_new_specimen.png){kind=link}
⸻
1. I did it in TeX. I had to make modified versions of the fonts that had a separate hyphen character which went past the margin and insert manual \penalty0 points after en- and em-dashes since they no longer automatically were breakpoints since the hyphen was not the hyphenchar.
2. Despite my typographic background, I generally try to avoid spending time on manuscript formatting beyond the absolute basics.
3. Still not exactly half-hung punctuation with this trick. The exact hung fraction is left as an exercise to the reader.