[HN Gopher] The `hanging-punctuation property` in CSS
___________________________________________________________________
The `hanging-punctuation property` in CSS
Author : surprisetalk
Score : 246 points
Date : 2023-11-28 02:58 UTC (20 hours ago)
(HTM) web link (chriscoyier.net)
(TXT) w3m dump (chriscoyier.net)
| dylan604 wrote:
| "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.
| leokennis wrote:
| 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.
| dhosek wrote:
| 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,1 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,2 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.3
|
| [?]
|
| 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.
| crazygringo wrote:
| Totally agreed.
|
| 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.
| zestyping wrote:
| Overshoots are an unfortunate holdover. In many fonts, "C"s
| and "O"s are too big and "A"s are too tall. I mean, just look
| at this:
|
| https://typography.guru/uploads/monthly_2020_01/overshoot.th.
| ..
|
| Or this:
|
| https://ilovetypography.com/img/2015/03/Caslon-
| overshoot-500...
|
| Or this:
|
| https://ktla.com/wp-
| content/uploads/sites/4/2020/06/GettyIma...
|
| Or this:
|
| https://live.staticflickr.com/5300/5482446696_1fa1ff2b45_b.j.
| ..
|
| Hideous.
|
| 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.
| CharlesW wrote:
| > _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"1 are worth
| checking out.
|
| 1 https://affinity.help/publisher/en-
| US.lproj/index.html?page=...
| zestyping wrote:
| 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.
| DemocracyFTW2 wrote:
| > 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.
| ggm wrote:
| 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)
| pimlottc wrote:
| > I always liked the french <<this is a quote>> model. Somehow
| it felt more like an embedded thing.
|
| Those << >> characters are called "guillemets" [0]. Fun fact,
| they're named after an early French typecutter, Guillaume Le
| Be!
|
| https://en.wikipedia.org/wiki/Guillemet
| ahmedfromtunis wrote:
| No, they are the worst.
|
| 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.
| RHSeeger wrote:
| Could you use non-breaking space instead?
| uxp8u61q wrote:
| Use non breaking spaces between the content and the
| guillemet...
| eynsham wrote:
| 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).
| realusername wrote:
| That's also required with every punctuation symbol with two
| parts in French so : ; ! and ? also require an extra space.
| chrismorgan wrote:
| You should use U+202F NARROW NO-BREAK SPACE for French
| punctuation spacing.
| chrishill89 wrote:
| They don't require a space around them. That's a French
| thing. They don't require that in Swiss German.
|
| Also not in Norwegian and probably others.
| crazygringo wrote:
| > _Those spaces aided reading. They had a purpose._
|
| 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.
| oxygen_crisis wrote:
| 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.
|
| https://link.springer.com/article/10.3758/s13414-018-1527-6
| pixel8account wrote:
| >slightly handicapping people who become accustomed to it
| and then read text without it.
|
| Or maybe slightly boosting when reading double spaced? (I
| didn't read the article yet, my plane is just starting).
| o11c wrote:
| Books are typically not monospace, which is where the two-
| space rule really applies.
| Izkata wrote:
| 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.
| crazygringo wrote:
| No, the two-space rule _was_ used in books a ~century ago.
| That 's what I'm comparing with.
|
| The habit was adopted for monospace typewriters precisely
| to try to match book typesetting.
|
| Then the books dropped it, but it persisted in typing
| habits.
|
| Then once Mac/Windows allowed anyone to use proportional
| fonts, we were taught to use a single space again.
| zestyping wrote:
| They do. The end of a sentence is not the same as the space
| after an abbreviation. There is a semantic difference, and
| it's useful.
| rjh29 wrote:
| The '. ' is already wider than a normal space though, so
| personally I find it easy to parse both.
| Skeime wrote:
| 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.
| shannifin wrote:
| > Hanging that opening curly-quote into the space off to the
| start of the text and aligning the actual words is a better look.
|
| Eh... no it's not?
| betenoire wrote:
| That was my reaction, as well. Maybe if it were bigger and
| stylized, but that's not really a trend anymore anyway.
|
| This just distracts me and makes me forget what I was reading
| quickthrower2 wrote:
| 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.
| Izkata wrote:
| > 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.
| paradox460 wrote:
| It happens a lot in prose magazines like The New Yorker,
| Harpers, and Lapham's
| roelschroeven wrote:
| 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.
| curtgrimes wrote:
| As of November 2023, only available in Safari.
|
| https://caniuse.com/css-hanging-punctuation
| masswerk wrote:
| I can confirm that - as of writing - Safari/Mac supports this
| feature and that Firefox does not.
| prosody wrote:
| 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.
|
| [1] https://www.thetype.com/wp-content/uploads/2017/11/AI-
| hangin...
|
| [2] https://developer.mozilla.org/en-US/docs/Web/CSS/hanging-
| pun...
| tomcam wrote:
| 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.
| esafak wrote:
| I did not even know this was possible. So CSS has microtypography
| features after all!
| pxtail wrote:
| 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.
| omnimus wrote:
| 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.
| Macha wrote:
| text-indent is a CSS1 property.
| k8svet wrote:
| Huh. Both hanging and not hanging feel both right and wrong for
| their own kinda conflicting reasons. And til. Thanks op and
| author.
| chefandy wrote:
| 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.
| ttepasse wrote:
| 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: <dquo-open-push></dquo-open-
| push> <dquo-open-pull> "That's</dquo-open-pull>
|
| and styles them with this CSS: dquo-open-push {
| margin-right: 0.5em } dquo-open-pull { margin-left: -0.5em
| }
|
| 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.
|
| An example is on this page: https://practicaltypography.com/are-
| two-spaces-better-than-o...
|
| 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.
| lwhi wrote:
| Call me old fashioned, but contaminating the markup like this--
| for something that's aesthetic--is a no no.
| Retr0id wrote:
| _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.
| globular-toast wrote:
| Because users should be able to make their own stylesheets
| and having a bunch of stuff in there that isn't relevant is
| annoying.
| immibis wrote:
| Has anyone ever done this?
| Retr0id wrote:
| Yes, it's a whole thing, e.g. https://userstyles.world/
|
| But, I don't think those `dquo-open-*` tags would get in
| the way at all.
| OJFord wrote:
| 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.
| velcrovan wrote:
| 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.
| globular-toast wrote:
| 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).
| nlitened wrote:
| When I hear "old fashioned", I imagine <table> layouts,
| transparent pixel gifs, and <marquee>.
| lwhi wrote:
| To me, old fashioned means sticking to semantic principles
| and separation of concerns.
|
| (P.S. get off my lawn)
| reddalo wrote:
| I can only imagine what you think of TailwindCSS so...
| lwhi wrote:
| Counterintuitively, I'm okay with it .. but just because
| it solves problems I see as more important than purity in
| the codebase.
|
| Large FE projects often have multiple developers, which
| come and go .. and have differing levels of ability.
|
| Tailwind provides a framework that's easy to jump into,
| provides consistency and is widely known.
|
| --
|
| However, that doesn't mean I can't think this particular
| technique isn't a good idea.
| madeofpalk wrote:
| What markup?
|
| If it's generated, does it matter?
| lakpan wrote:
| Are we looking at the same page? Where's the contamination?
| It's pure CSS applied to a basic `blockquote` element. There
| are no spans and no divs.
| svat wrote:
| 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 .)
| notpushkin wrote:
| 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: dquo-
| pull::before { margin-right: -made-up-string-width("); }
| dquo-pull { margin-left: calc(-1 * -made-up-string-
| width(")); } She said: <dquo-pull>"That's</dquo-
| pull>
|
| (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].
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/CSS/length#cont...
|
| [2]: https://drafts.csswg.org/css-contain-3/#containment-
| inline-s...
|
| > although now with `hanging-punctuation` it is unnecessary
|
| `hanging-punctuation` only works at the start of the block
| element though. Maybe that'll change in the future though!
| ttepasse wrote:
| 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.
| notpushkin wrote:
| 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/
| giraffe_lady wrote:
| 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.
| gwern wrote:
| 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.
| thriftwy wrote:
| Lebedev's design bureau had hanging punctuation since 2005.
|
| https://www.artlebedev.com/mandership/120/
|
| Not submitting this one since it is light on technical details.
| chrismorgan wrote:
| 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.)
| globular-toast wrote:
| 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?
| lwhi wrote:
| A web developer shouldn't, but a designer should.
|
| Otherwise, why bother with design?
| marginalia_nu wrote:
| How would you distinguish between web design and
| development?
| lwhi wrote:
| How it's built vs what it looks like.
| marginalia_nu wrote:
| That's arguably a very limited view of design. Design is
| far more than aesthetics.
| lwhi wrote:
| Design is visual engineering .. development is software
| engineering.
|
| Both essentially involve solving problems.
| marginalia_nu wrote:
| 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.
| lwhi wrote:
| 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.
| marginalia_nu wrote:
| 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?
| charcircuit wrote:
| For the same reason a web page can choose what font to use
| even of your ereader has a feature to change fonts.
| Sharlin wrote:
| Why should the typesetter of a dead-tree book be able or be
| expected to make that choice for me?
| neoberg wrote:
| Because it's impossible while it's not in the digital
| medium?
| tannhaeuser wrote:
| 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?)
| chrismorgan wrote:
| > _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.
| jahewson wrote:
| But then you lose backwards compatibility and have no standard
| spec.
| chrismorgan wrote:
| 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.
| epeus wrote:
| The Microsoft trigger was `text-justify: newspaper` and
| intended for fully-justified narrow columns. I don't think
| it made it to Edge.
| WorldMaker wrote:
| I believe it made it to Spartan Edge but not the switch
| to Chromium Edge.
| gwern wrote:
| > 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. :(
| layer8 wrote:
| It's not like CSS implementations have been particularly
| strong in maintaining backwards compatibility.
| qaisjp wrote:
| Interesting opinion. Why?
| chrismorgan wrote:
| 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.
| chilmers wrote:
| 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.
| chrismorgan wrote:
| Refer to my response to jahewson. You can easily apply
| this to the vast majority of content with negligible
| hazard.
| p4bl0 wrote:
| 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/
| chrismorgan wrote:
| 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!
| p4bl0 wrote:
| 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.
| chrismorgan wrote:
| You're abusing CSS.
|
| (Can't say I never have...)
| p4bl0 wrote:
| Well _I_ 'm not, but some people are, probably. The need
| exists. That's my whole point :).
| jjgreen wrote:
| HTML tables for layout FTW.
| gazook89 wrote:
| 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.
| eropple wrote:
| This is ridiculously well-done. Thanks for sharing.
| DemocracyFTW2 wrote:
| > 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...
| postmodest wrote:
| 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.
| fvdessen wrote:
| 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.
| SigmundurM wrote:
| Electronic books (EPUBs) are literally just HTML, CSS (plus
| some more standards specific to EPUBs).
| chrisfinazzo wrote:
| 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
| neves wrote:
| Well, Kindle books are formatted with CSS
| Vt71fcAqt7 wrote:
| +1 for padgedjs. I wish browsers would just implement @page
| on their own though.
| uxp8u61q wrote:
| The "prose" signal exists, it's called the <p> HTML tag.
| marginalia_nu wrote:
| 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.
| uxp8u61q wrote:
| A paragraph... of what? Just think about it for a minute...
| marginalia_nu wrote:
| Of any sort of text, including but not limited to prose.
| uxp8u61q wrote:
| 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"?
| marginalia_nu wrote:
| Anything on verse for one.
| uxp8u61q wrote:
| That's a joke, right?
| Someone wrote:
| > 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)
| chrismorgan wrote:
| `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.)
| westurner wrote:
| 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
| benatkin wrote:
| > 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.
| zestyping wrote:
| Hanging punctuation looks sloppy. It's not worth it.
| lwhi wrote:
| The magic number version is completely unaligned for me.
|
| It could be a nice property; but it isn't ready for primetime
| yet.
| 8organicbits wrote:
| Which browser/OS?
| lwhi wrote:
| Firefox on Android
| Groxx wrote:
| 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.
| petters wrote:
| > Here's a demo:
|
| Does not work in mobile Safari. It hides the quotation mark
| hnlmorg wrote:
| 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.
| mattsan wrote:
| Yeah I found the example without the italic text much harder to
| read when it was aligned. When it was italic the quote was in
| view though
| bombela wrote:
| I am slightly dyslexic and I actually find it pleasing. To me,
| the hanging quote acts like an anchor to my eyes instead of a
| wall of text.
| wruza wrote:
| As a non-dyslexic I prefer to read normal text without
| justification or hanging anything (apart from narrow columns of
| physical newspapers).
| weinzierl wrote:
| 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.
|
| https://news.ycombinator.com/item?id=19473101
| chrishill89 wrote:
| 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.
|
| [1]
| https://github.com/torvalds/linux/commit/5b2b1173a93fa056b45...
| bmacho wrote:
| The first picture both look ugly to me. I don't like rows
| starting with ", not italic.
|
| On the second picture, with italic:
|
| https://i0.wp.com/chriscoyier.net/wp-content/uploads/2023/11...
|
| the left one, thank you.
| amadeuspagel wrote:
| Hanging punctuation breaks web conventions, where every element
| has margin and padding, to make websites look like print. It
| looks terrible.
| aronhegedus wrote:
| Not a fan of this, too many ways it can fail, and have ugly
| scroll bars, and the gain is little to me
| wruza wrote:
| _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. <div class="parent"> <div
| class="header">Dynamic-height header</div> <div
| class="rest">...many divs...</div> </div>
| .parent { width: 20vw; height: 100vh; } .header { }
| .rest { }
|
| 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!
| ioulian wrote:
| Maybe I'm missing something about your question, but:
|
| ``` .parent {display: flex; flex-direction: column;} .rest
| {flex-grow: 1; overflow-y: auto;} ```
| wruza wrote:
| It works! Congrats, you did it!
|
| 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.)
| ioulian wrote:
| 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".
|
| [1] https://robertmarshall.dev/blog/solution-to-why-css-
| position...
| ryanbrunner wrote:
| 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.
| adaboese wrote:
| 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.
| Pxtl wrote:
| 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.
| culi wrote:
| Note: not supported in any major browser currently. Except for
| Safari which has partial support
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/hanging-pun...
| enathan wrote:
| Good to see CSS getting some of the granular type controls that
| have existed in Photoshop/Illustrator/Figma since the beginning.
___________________________________________________________________
(page generated 2023-11-28 23:02 UTC)