A heading that reads naturally on a desktop can look unfamiliar on a phone. Words appear joined, a long expression extends beyond the screen, or a sentence breaks into fragments. Smaller type may fit, but it does not explain why the sentence became awkward.

My earlier review notes record a correction to joined-looking words in a mobile heading. Later article work checked Korean word boundaries and overflow from long titles together. The current source retains keep-all with an overflow fallback. I do not have every original screen and its matching pre-change code as a complete pair, so I avoid assigning a single cause to the first problem. Instead, I preserve a reusable order of checks.

Explore a small example

This isolated example explains the structure. The article records what has actually been verified.

I first check whether the spaces exist

Joined-looking words can describe two different problems. The text may lack an actual space, or the space may exist but appear weak because of the font and tracking. A wrapping property cannot insert the missing space needed by the first problem. I compare the stored wording with the text produced by the page before adjusting the visual treatment.

Splitting emphasis into several inline spans makes it easy to lose a space at a boundary. Different colors or weights can suggest a separation on a wide screen while the mobile version reads as a single word. I put meaningful spaces in the text itself and in the rendered nodes. Using CSS margins as a substitute can leave copied text or the content read by assistive technology without the same separation.

Explore the implementation

HTML and JSX · Explicit text boundaries in a synthetic example

<!-- The space belongs to the sentence, not to CSS. -->
<h1 lang="ko"><span>홈페이지 제작</span> <span>과정을 설명합니다</span></h1>

{/* JSX: make the boundary explicit when splitting inline nodes. */}
<h1 lang="ko">
  <span>홈페이지 제작</span>{' '}
  <span>과정을 설명합니다</span>
</h1>

I preserve word boundaries without forcing the page wider

Breaking Korean explanations character by character can make the same sentence harder to follow. The current project source uses keep-all and supplements it with overflow-wrap for long titles that exceed a narrow space. I treat these as a normal reading rule and a fallback for a string that cannot otherwise fit.

The fallback does not excuse every difficult sentence. A long expression may be better rewritten in simpler words, and a narrow card may need a different structure if it must hold a substantial title. I also do not impose the same language rule on every translation. I mark the language and give English text its own wrapping behavior.

I inspect the container as well as the letters

If reducing the title size does not remove overflow, I inspect the area holding it. A child in a grid or flex layout can retain a minimum width influenced by its content. The words are supposed to fit a phone, but a container demanding a larger width can push the entire document sideways.

The reusable example uses minmax(0, 1fr) for the grid track and min-width: 0 for the copy container. This is a method to apply after examining the parent layout, rather than a universal patch for every card and table. A comparison table may need to preserve horizontal relationships and use its own scrolling region instead.

I keep the typography rules within a small boundary

The CSS below is a new explanatory module for a reading area. It gathers title size, line height, Korean boundaries, long-string wrapping and container width without copying an entire site’s design. Buttons, price tables and code blocks have other requirements, so they are not automatically included in these selectors.

I adjust font and tracking with real sentences. Excessively tight tracking may force a heading onto one line while also weakening the apparent separation between words on a small screen. I establish a readable size and spacing first, then allow the number of lines to vary with the available width.

Explore the implementation

CSS · A scoped Korean and English reading module

/* Put the language on the document or the text container. */
.reading-layout {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
}
.reading-copy {
  min-width: 0;
  max-width: 46rem;
}
.reading-copy h1 {
  margin: 0 0 1rem;
  font-size: clamp(1.75rem, 5vw, 3.5rem);
  line-height: 1.3;
  letter-spacing: -.025em;
}
.reading-copy p { line-height: 1.85; }
.reading-copy :is(h1, h2, p, li) {
  overflow-wrap: anywhere;
}
.reading-copy:lang(ko) :is(h1, h2, p, li) {
  word-break: keep-all;
}
.reading-copy:lang(en) :is(h1, h2, p, li) {
  word-break: normal;
}
/* Preserve ordinary spaces in the actual text. */
/* Do not apply white-space: nowrap to these paragraphs. */

I use forced breaks when they carry a deliberate meaning

The actual opening-screen source I inspected uses br to divide a short question intentionally. That can establish a reading rhythm for a concise central message. Fixing every explanation and translation to desktop line positions, however, can leave a very short fragment on its own line on a phone.

I distinguish a meaningful division from a break inserted merely to fit a particular viewport. Long descriptions and article paragraphs can flow naturally while an intentional short question is divided selectively. Translation changes the length, so I do not mechanically transfer the same br positions. I rewrite the wording to preserve meaning and an appropriate reading flow.

I leave a check sequence for narrow screens and larger text

Historical notes record word-boundary reading and document overflow checks at a 390px mobile width. Those notes support the earlier work. They do not establish that I have now rendered this new CSS example on desktop and mobile. For this module I have compared source and records; a new rendered review remains a separate scope.

When applying it to another page, I would check more than one convenient screen. Short and longest titles, long English strings, the font before and after loading, and enlarged text all matter. A document can report no horizontal scrolling while part of a title is visually clipped, so measurements should be paired with reading the actual result.

  1. Do the source text and rendered text retain meaningful spaces?
  2. Do the language attributes and wrapping rules match Korean and English?
  3. Can the parent container shrink instead of growing with its content?
  4. Does larger text or a changed font clip part of a heading?
  5. Do ordinary paragraphs flow while only deliberate line breaks remain?
  6. Does copied text preserve the spacing and order of the words?

I choose readable wording over a prescribed line count

A website heading is a visual shape and the first explanation a visitor reads. Continually shrinking it to remove a line increases the effort required by a mobile reader. Correcting spaces, preserving word boundaries and giving the wording an appropriate container produces a more durable approach.

This module does not aim to make every sentence occupy identical lines. It aims to preserve meaning and readability when the wording changes and the screen narrows. I want the person editing the text to inherit that standard along with the code.