w3c
[css-text] Reconsider the initial value of the `text-autospace` property
Safari 18.4 shipped the text-autospace property, congraturations.
One thing we noticed is that its initial value is set to no-autospace (turn off the feature), while the spec defines it to be normal (turn on the feature). With this opportunity, I'd like us to discuss which is the better initial value for the text-autospace.
Here's my investigations from a few different perspectives.
For East Asian Authors and Users
Whether "on by default" or "off by default" doesn't make any differences in the majority of cases, because most existing pages have an ASCII space to where the text-autospace would insert the space, part because it's the tradition since 1980, part because the majority of style guides require to do so.
For these majority to get the benefits from the text-autospace feature, they have to opt-in, either a) by removing the ASCII spaces, or b) by adding the replace keyword. This is different from the situation of the text-spacing-trim property where "on by default" can improve the typography of the most existing pages.
For other minor cases, authors either a) don't care, or b) explicitly preferred tighter spacing. In the former case, either initial value works fine. The latter case would prefer "off by default".
For Non-East Asian Scripts
For non-East Asian scripts, turning this feature on has no impacts, or sometimes negative. Most these scripts use space to delimit words, so East Asian characters appearing as a word has no differences by this feature. In rare cases, a word may consist of East Asian characters and non-East Asian letters, such as proper nouns. In such cases, the spacing is either a) not noticed, or b) it could confuse as if there's an actual space.
Performance
This feature hits the performance in a lot higher degree than other similar features such as the text-spacing-trim property because it has a lot more candidate characters, spread across Unicode blocks. Implementing an optimization to skip most of the computation when not applicable succeeds less. The current Blink implementation can avoid most of the performance hits for Latin scripts, but all other scripts are impacted by 1-5% of the layout time.
In addition to the WebKit shipping "off by default", @masayuki-nakano, a Japanese Gecko engineer, also expressed a concern about the performance hit.
Options
We have options to:
- Make
normal(turn on) as the initial value (the current spec). - Make
no-autospace(turn off) as the initial value (what WebKit shipped). - Make the
replaceas the initial value.
While the option 3 replace can improve the majority of existing pages without requiring authors to opt-in, it could be too aggressive, may alter the semantics in the way authors don't expect. I'm hesitant to make it the default behavior.
I'm fine with 1 or 2, because either option doesn't make any differences in the majority cases of East Asian authors and users as stated above, but mildly prefer 2 given the performance hits, especially to non-CJK, non-Latin scripts where there is no benefits.
/cc @fantasai @frivoal @nt1m @vitorroriz @masayuki-nakano @jfkthame @bfgeek @chrishtr @clqsin45
Fwiw, WebKit has shipped by default to figure out the performance of the normal value, not really a choice based on user experience.
I'm not convinced at the argument that because current sites already use ASCII spaces, we don't need this. Helping future authors and making their authoring experience less hacky/painful is also super valuable.
Though I'm also not super qualified to talk about CJK scripts so I'm curious to see what Japanese authors like @sakupi01 think what the best default value for text-autospace would be (see https://drafts.csswg.org/css-text-4/#propdef-text-autospace for all the possible choices), especially considering authoring for future sites.
Thank you for the great feedback, @nt1m. I agree that we should think about future authors too, but I failed to write about them.
The future authors also need to opt-in regardless of the initial-value, because they have to change their writing style by stopping the tradition since 1980 and ignoring the required rules in the style guides, or add the replace keyword.
If they were to decide whether to opt-in or not before start writing and change their writing style accordingly, declaring their decision clearly looks like a good thing to me.
Let me also note another difference from text-spacing-trim where everyone agrees turning it on is a progression. For text-autospace, the more modern, the more people started to prefer no spaces. I guess "prefer on" is still more than half of authors, especially on paper and for professional printing typographers, but the ratio is changing gradually. For example, a style guide from JETF removed the space in their version 3.0, published in 2019.
From these, I think defaulting to no-autospace is also future looking.
My another concern about making the default behavior to new one is, it may change a layout in existing web sites, especially when the container element bounding box is too small, like a menu items. So, I basically believe that keeping the traditional behavior by default is the best for the backward compatibility. However, Chrome which has the biggest market share already shipped with the new behavior by default, so, such issues must have already been fixed in each web site side... So, I don't have strong suggestion here, but I still think that keeping the traditional behavior by default must be safer.
@kojiishi Do you have regression reports about that? Especially about broken layout?
@masayuki-nakano Chrome hasn't shipped this yet, only under a runtime flag.
My general preference would be to keep normal as the initial value, for the sake of future authors, as discussed in https://github.com/w3c/csswg-drafts/issues/12386#issuecomment-2997240401: good rendering by default with straightforward markup seems desirable to me.
I also hope that the performance concerns can be mitigated; @kojiishi pointed out that Chrome's implementation can avoid most of the performance hits for Latin scripts, and hopefully that can eventually be extended to other scripts too. And if possible, it would be better not to constrain design decision by solvable performance constraints.
As for the risk highlighted by @masayuki-nakano that some things that used to fit in a tight box no longer would, I don't have data on it, and hope it turns out not to be a problem.
All in all, as long as all variants are possible, I don't think I'm so attached to the initial value that I'd object to a change, but I'd prefer if we could keep it the way it is.
Yes, Safari 18.4 shipped text-autospace: no-autospace as the default, knowing that normal is the specified default. We did so with the awareness we can always change the default in the future.
Doing it this way is a bit more conservative, more careful, getting text-autospace into the hands of authors in one step, and potentially turning it on for all content in the future as another step. Of course, there's always a concern about compat whenever the web changes existing defaults. We are the first browser to ship support, and we took a more conservative path. We can all watch as authors use it in Safari, and ensure things are going well.
Don't misunderstand Safari 18.4 as either a mistake of incompetence or a permanent decision. It's neither.
@jensimmons in the future please raise an issue here before shipping a feature that does not match the spec.
I’d like to hear more about the notion that we can change the default in the future. Shipping a feature with a particular default usually tends to constrain us.
@kojiishi do you have any feedback from people turning on your runtime flag with the normal default?
@masayuki-nakano Chrome hasn't shipped this yet, only under a runtime flag.
Then, I love no-autospace as the default value.
@jensimmons in the future please raise an issue here before shipping a feature that does not match the spec. I’d like to hear more about the notion that we can change the default in the future. Shipping a feature with a particular default usually tends to constrain us.
The impact of changing the default to normal, is the same as shipping with the correct default (normal) without having shipped the property before in this case, since no-autospace is basically no-op compared to what browsers are shipping currently.
Thank you for pinging me @nt1m and starting this meaningful discussion concerning East Asian writing styles! Let me do a quick sum up.
Summary of the Discussion So Far
- Backward compatibility: Most existing CJK content already uses manual ASCII spaces, so normal wouldn't benefit them without the replace keyword
- Performance concerns: Non-Latin, non-CJK scripts face 1-5% layout performance hits with no benefits if normal is set
- Future authoring: Providing "better" defaults for future authors/readers/users vs. maintaining conservative defaults and opt-in if needed
- Safari shipped with
no-autospaceas a conservative step, while the specdefinesnormal - Chrome is shipping and currently it's behind a flag with
normaldefault according to the current spec
- Safari shipped with
They are what I understood so far conversation, and now I'd like to contribute my perspective on the appropriate default value.
My Point of View
I see this as fundamentally a question about whose experience we're optimizing for:
- established content creators who follow traditional style guides, or
- the broader population of web users who create content today.
I do understand that there're performance issues or backwards-and-forwards compatibility concerns to reason and solve this topic, but I believe the sociological changes in web content creation is inevitable.
Since the Web became ubiquitous and mobile devices democratized content creation, millions of people who aren't familiar with traditional style guides now publish content online. Many of these users have high possibility that they never encountered the 1980s conventions of inserting spaces between CJK and Western characters. I believe that this shift in user demographics may have influenced the JTF style guide revision in 2019 as @kojiishi mentioned earlier.
(Speaking personally, I wasn't aware of the traditional spacing convention until university. When I first read academic papers with spaces between Japanese and Western characters, I found it a bit surprising rather than natural. We've grown up reading and writing content without these spaces on social media, messaging apps et cetra before academic. (I acknowledge this is subjective opinion, which is why I'm currently conducting a little survey to gather quantitative data on contemporary spacing preferences among Japanese web users.))
While I agree that backward compatibility and performance are technical concerns in favour of setting no-autospace as the default, I believe the 'unknown human-side reason' could also be prioritised more.
If we can only "assume" or are "unsure" of the facts, I feel we should respect the organic evolution.
This doesn't prevent those who prefer traditional spacing from opting in with text-autospace: normal—it simply ensures the default matches what most users already expect and gives more capability for people who want to use spacing style!
I believe this could help to ground our decision in actual user behaviour rather than assumptions.
Fwiw, I received an interesting 2023 blog post (in Japanese) from one of the respondents that provides some data on this topic: https://devadjust.exblog.jp/29549895/
The post references a 2019 Twitter poll of around 6,800 respondents showing that approximately 60% of respondents don't insert spaces between CJK and alphanumeric characters when writing. The author also surveyed major tech companies' Japanese websites and found mixed practices.
If the majority of users are already writing without spaces, and even major companies are divided on this convention, then no-autospace as the default would better align with contemporary usage patterns, while still providing a useful auto-space-insertion feature.
Most existing CJK content already uses manual ASCII spaces, so normal wouldn't benefit them without the replace keyword
I'd like to challenge that. I don't doubt that some content does use ascii spaces between ideographic characters and either numeric or alphabetic characters where text-autospace would otherwise take effect, but "most" seems like a strong overstatement to me. In fact, outside EPUBs, I'm having a hard time finding any content that does it. Wikipedia doesn't. The websites of the Asahi Shinbun or Nikkei Shinbun newspapers don't, nor do those of Tokyo University or Keio University. The Japanese ministry of Education and Culture doesn't, nor does the JMA. Line doesn't. ascii.jp doesn't. ameblo.jp doesn't…
So, the idea that this would be a no-op on most of the web seems questionable to me.
Thank you @sakupi01 for very interesting data, they are very helpful. I also found that Japanese Wikipedia doesn't insert the space characters. I agree I should correct my view on how much impacts enabling auto-space has. It does have a quite big web-compat impacts for existing pages.
Now, there are two ways to read these data:
- Authors stopped inserting space characters because they hope someday the platforms to do it automatically.
- Authors stopped inserting space characters because the space looks excessive or weird.
The feedback to the blog post (Japanese) looks like the latter to me.
If we can assume that Japanese authors are divided to two groups:
- Half of Japanese authors insert space characters, because they want the spacing but the platform doesn't do it.
- Half of Japanese authors don't insert space characters, because they don't want spacing there.
Then enabling the auto-space by default makes no benefits to the group 1, and troubles the group 2. This seems to me that it strengthen the idea that no-autospace is the better initial value, even without the performance issues.
I hope the discussion takes the fact that the 3 native Japanese prefer no-autospace as the initial value into account, for their preferred style, web-compat, and performance.
@kojiishi There's a third way to read it.
- CJK authors don't insert spaces for the same reason Western authors don't type curly quotes: it's a fiddly typographic nicety that most people don't care enough about to fuss with, but would prefer if it “Just Worked”.
I could be wrong, but this is my interpretation of the current situation.
If that's the case, then the best thing to do would be to try to improve the performance hit and eventually turn it on by default. In the meantime, I think for the reasons Tim stated above, shipping the feature with a more conservative default while we improve the performance is an acceptable incremental way forward.
I'll note that MacOS's default typesetting for CJK uses autospacing, for example, since they're able to do it at the system level -- this points to a desire to have it Just Work. (Newspapers are probably not the best example to reference, since typesetting for newspapers tends to optimize space efficiency over readability to some extent.) If we want to survey authors for their opinions, then, we should ask the preferences of people who work in graphic design and typography rather than us programmers... and not burden them with questions wrt compat, which is for us to weigh here. :)
Also note that the auto-space in CSS is 1/8 em, not 1/4 em, so it is more conservative than some older publications where the extra spacing is more pronounced.
@astearns
@kojiishi do you have any feedback from people turning on your runtime flag with the normal default?
A few noticed, saying their pixel tests were broken and were looking for the cause.
From our experiences, issues in i18n features are found/reported only when they reach the stable channel. Beta and earlier channels rarely help, and runtime flags have even less chances to catch issues.
@fantasai I'm not saying everyone on the planet want to turn it off. I'm not surprised there are situations it's better to turn it on by default. MS Word is still on by default too, only for CJK, same as iOS/macOS. I suspect e-book readers might want on by default too. I guess JLTF wants on too.
But when a feature is controversial this much, and when we're seeing clearly a good number of native authors wanting to turn it off, and some authors even say it's "weird", forcing it on by default is too aggressive and risky. Authors who want it can always turn it on.
The auto-space has been a style preference. In my understanding, the majority liked it 30 years ago, when the original CSS Text spec was written. Fonts evolved since then and users read documents on screen more often. In this 30 years, I see more people changed to prefer off. I'm actually one of such, changed my preference some years ago.
Technically similar feature text-spacing-trim is in a different situation. It's like kerning. Turning it on is an improvement for everyone. We changed its default to be a conservative value right before shipping for web-compat, but no one wanted it to be off by default. When the feature reached the stable channel, I didn't see single complaint.
Such features are good to change the default behavior. The auto-space isn't such a feature.
The CSS Working Group just discussed [css-text] Reconsider the initial value of the `text-autospace` property, and agreed to the following:
RESOLVED: Allow shipping with no-autospace as initial value, continue discussing eventual default behavior
The full IRC log of that discussion
<emilio> Rossen: this issue is still under active discussion<emilio> ... I know this is something the chrome team wanted to bring forward to unblock implementation
<emilio> ... is koji on the call?
<emilio> fantasai: I think we all agree it should be fine to ship initially with default no autospace
<emilio> ... what the default should be ultimately is the debate in the issue
<emilio> ... but we can resolve that no autospace is an acceptable default for the time being
<emilio> florian: That's chrome's position as well
<emilio> Rossen: anything else that you want to point out?
<emilio> fantasai: I think we need to continue the discussion about eventual default
<emilio> q+
<florian> +1
<fantasai> emilio: Does the property definition allow changing defaults easily? Is there 'normal'?
<fantasai> fantasai: yes
<Rossen3> ack emilio
<emilio> emilio: then that sounds fine
<emilio> PROPOSED: Shipping with default autospace off is fine for now, keep discussing eventual default
<fantasai> RESOLVED: Allow shipping with no-autospace as initial value, continue discussing eventual default behavior
For
text-autospace, the more modern, the more people started to prefer no spaces. I guess "prefer on" is still more than half of authors, especially on paper and for professional printing typographers, but the ratio is changing gradually. For example, a style guide from JETF removed the space in their version 3.0, published in 2019.
Does that “no space” mean no U+0020 (half-width) space, or no spacing at all between Latin and CJK characters? The JETF guide explicitly mentions “半角スペース,” which refers to U+0020.
I also find it jarring and excessive to have full U+0020 spaces between Latin and Japanese letters. That said, I actually prefer the current normal behavior that inserts 1/8em spaces. I think the amount of space matters—it’s not simply a binary yes-or-no question.
Also, I’m curious about the motivation behind JETF’s decision to remove the spaces. Inserting explicit spaces between Latin and Japanese characters is quite tedious—you have to insert the character manually. It also makes things ambiguous for machines—text search and regex can behave differently depending on whether a space is there or not. So I suspect their choice might have been driven more by utility during editing, rather than purely by readability or typographic aesthetics.
Link to previous discussion: https://github.com/w3c/csswg-drafts/issues/6950
Whether "on by default" or "off by default" doesn't make any differences in the majority of cases, because most existing pages have an ASCII space to where the text-autospace would insert the space, part because it's the tradition since 1980, part because the majority of style guides require to do so.
Does Google have data to support this conclusion? My personal experience is exactly the opposite.
For example, a style guide from JETF removed the space in their version 3.0, published in 2019.
Did they publish a specific reason? I have discussed this issue with different people (for example, in https://github.com/w3c/clreq/issues/14 ). The reason many people do not add spaces is not because they do not think there is a need for the extra spacing between Chinese/Japanese and Western text, but because they think U+0020 pollutes the source code, because style and content should be separated. Many people think that this spacing is style, not content.
In addition, it is easy to make mistakes when adding spaces manually, for example, some people add spaces before full-width punctuation marks.
@myakura Thanks for the very good question. How many of those who don't want ASCII space want no space, and how many want 1/8em or 1/4em space isn't clear. It's probably not possible to know the exact numbers until they started using it, and the numbers may vary case by cases.
My best guess is 10% wants no space, 10% wants 1/8em or 1/4em space, 80% don't care. Maybe "don't care" is even more, like 5%, 5%, 90% or more.
One of the clear feedback says that they turn it off in their MS Word documents, because there are cases where it's excessively sparse, such as date (e.g., "2025 年 7 月 3 日", this example has 1/6em space, they look like fullwidth digits to me). For an example of real pages, this Japanese wikipedia page looks too sparse to me with 1/8em space. Turning off for digits can fix them, but it also makes other cases inconsistent, such as "約4kmの". When either on or off looks fine in most cases, it makes sense to me to prefer "no space" over "sometimes excessively sparse" or "sometimes inconsistent".
It should vary by fonts, the width of the screen, the kind of media, and some other factors, because they affect whether "either on or off looks fine in most cases" stands or not. If it's an e-book, where there are no side bars and the width is wider, long documents such as novels, well proofread and excessive cases manually fixed by editors, I might prefer the auto-space more.
These two different preferences should have been existed since the beginning. I remember there were some feedback to MS Word asking how to turn it off, but it was low 30 years ago. Looking at the recent data, the ratio has changed in the last 30 years. In 2025, on the web media, with web-compat and the performance considered, I think "on by default" is too aggressive and risky.
@xfq
Does Google have data to support this conclusion? My personal experience is exactly the opposite.
I have corrected this view a little ago, thanks to @sakupi01 and @frivoal. I often read Microsoft and Google technical documents, so I see the ASCII space more often, but I agree that many pages don't have ASCII space. By that, I feel that there are more web-compat risks than I expected before.
Did they publish a specific reason?
They don't, but I read various feedback linked from posts @sakupi01 quoted. As in my response to @myakura, they're mixed, some says the same reason as you wrote, and the exact ratio is not known.
The motivation of this issue is that the ratio of people wanting no space became high enough to reconsider the initial value. The risk is high to make it on by default, and authors who wrote their HTML in the specific way can always add one line CSS.
@fantasai, this is off-topic, sorry
CJK authors don't insert spaces for the same reason Western authors don't type curly quotes: it's a fiddly typographic nicety that most people don't care enough about to fuss with, but would prefer if it “Just Worked”.
I had a discussion about automatic smart quotes in browsers sometime ago, but people I talked to were all negative. Would you like it if it "just worked"?
If it is turned off by default, when a user wants to turn it on, they can only rely on the website developer to turn it on, and users have no other choice.
Ideally, I think the browser should provide a setting that allows users to turn this feature on. If this is not feasible, users can only rely on browser extensions to achieve it.
@xfq @myakura @kojiishi Thank you for developing the conversation!
Did they publish a specific reason?
I've been trying to reach out to the responsible person in JTF for the last few days, and I ended up asking my colleague, Ryutaro Nishino. He was one of the former JTF members, and he was even the chairperson in 2019, so I asked him the reason for the spacing removal in the JTF style guide. His answer was: "Tools now automatically adjust the display to prevent text from appearing too cramped, so we decided to stop manually inserting spaces." In a nutshell, they removed the manual spacing requirement because they expected tools to handle it automatically, not because spacing itself is bad. He even said he personally still believes "some spacing between half-width and full-width characters is desirable if it isn't manual." However, he was not sure whether the JTF style guide could be used as strong evidence for advocating general Japanese style standards, as it was produced only as a guide to unify Japanese translation notation. The full resource that I copy/pasted from our discussion can be referred to here in Japanese.
I agree that when people don't insert U+0020 spaces, it doesn't necessarily mean they don't want any visual spacing, as @myakura mentioned. I also agree that they might find manual spacing inconsistent, or consider it to pollute the content. As @xfq mentioned, yes, content and styles should be kept separate. In academic and e-pub contexts where Latin-CJK mixing is common, spacing has been used to improve readability - and tools like Word implement automatic spacing, as Nishino mentioned. Looking at the data showing 60% don't insert spaces - Now I wonder if this reflects the hassle of manual spacing rather than a preference against spacing itself. The tricky part is that preferences seem context-dependent, as @kojiishi rightly pointed out. Dates can look too sparse with spacing, while technical content might benefit from it.
If it is turned off by default, when a user wants to turn it on, they can only rely on the website developer to turn it on, and users have no other choice.
Yes, if we default to no-autospace, users who want spacing have to rely on developers to turn it on. But then again, if we default to normal, users who don't want it also depend on developers to turn it off. Either way, users don't have official control. This makes me think that the default should match what most users actually prefer - but that's exactly what we're struggling to figure out. It's not realistic to gather reliable data for now, and considering the future generation, it's even more complicated.
Since there are many guesses and unknowns without solid data, shipping with no-autospace seems sensible to me, also with web-compat and performance issues. And if browsers give users control (I'm not sure but something like prefers-reduced-motion?), we could revisit the default based on what people actually choose.
Maybe normal could be a desireble option after we have both the data and ways for users to override it. It wouldn't be too late to change the default appearance after users get a way to override it.
@xfq
If it is turned off by default, when a user wants to turn it on, they can only rely on the website developer to turn it on, and users have no other choice.
Ideally, I think the browser should provide a setting that allows users to turn this feature on. If this is not feasible, users can only rely on browser extensions to achieve it.
Just curious, what's wrong with extensions? I use extensions to make browsers match my personal preferences, such as changing fonts or typography settings, and I think extensions are exactly for that purpose.
@sakupi01
This makes me think that the default should match what most users actually prefer - but that's exactly what we're struggling to figure out. ...shipping with
no-autospaceseems sensible to me, also with web-compat and performance issues.
Agreed. Compared to text-spacing-trim, text-autospace is:
- Authors' Preference is a lot more controversial.
- Web-compat is similarly impacted, but when preferences are a lot more controversial, forcing on is likely to cause more complaints.
- Performance is a lot more impacted. It's more difficult, or impossible, to optimize for non-CJK scripts due to the nature of the feature.
I don't have data if authors wanting no-autospace is more than authors wanting autospace or vice versa, but given these situation, the exact ratio doesn't matter. It's controversial enough to worry about risks.
Before, I assumed that it's a lot less controversial, and it has less web-compat impacts. Thanks again @sakupi01 and @frivoal for providing data to correct me.
Hello, a random web developer from Japan here :wave:
I’d like to share my thoughts on the initial value of the text-autospace property.
First of all, I believe it’s an overly strong assumption that Japanese authors who don’t insert spaces manually also don’t want any space between CJK and non-CJK characters. Personally, I never insert manual spaces, but I would still prefer the text-autospace: normal behavior. So I’ll definitely opt in to it as soon as it becomes available, regardless of the default.
From a semantic standpoint, manually inserting spaces doesn’t feel right. Among the Japanese authors I know, there’s a shared sentiment that spacing between CJK and non-CJK text is a matter of typesetting, and should not require literal space characters in the source.
In my view, the current practices of adding spaces manually are simply workarounds. The fact that many Japanese authors don’t use those workarounds may not mean they reject spacing—it may just mean they’ve been waiting for better typographic support.
To sum up, I believe that defaulting to text-autospace: normal would better match the intent behind many (if not most) existing Japanese texts that don’t contain manual spaces.
By the way, Prettier used to automatically insert spaces between CJK and non-CJK characters when formatting Markdown, but removed that behavior in v3.0. The discussions around that change may also be relevant to this topic.
Side note: I’ve published a Japanese article on this topic to help more Japanese developers understand the issue. Many readers have expressed support for the idea that the absence of manual spaces doesn’t imply a lack of desire for typographic spacing.
Thank you @uhyo for the feedback.
Seeing more opinions wanting to turn it on is really great and helpful, thank you. It helps us to prove that our efforts to discuss, write specs, and implement, for over decades, is the right thing. I hope it also helps raising the priority of this feature for other browsers.
Forcing it on by default is a different topic. It means that we ignore authors who don't want the space. It means that we require users who don't want it to install extensions. It means that we don't care slowing down pages of other scripts, such as Arabic, Thai, Devanagari, etc.
Before, these negative impacts were thought to be little-to-none. But recent data and discussions discovered that there are real negative impacts.
Maybe there are more people who thinks it's a positive impact than who thinks it's a negative impact, I don't have the exact data at this point. But when authors and users who hit the negative impact is not little-to-none, I don't think changing the default rendering is the right way to go.
Safari has shipped it in March, and Chromium-based browsers will ship it soon too. If you want the spacing, please add text-autospace: normal to your pages. Doing so will give us more data. I can see it rising since Safari has shipped, but it's still low.
Note, the data includes both normal and no-autospace. I found some pages already added no-autospace to protect their pages from changing in case any browsers turn it on by default, so it might help us better to add a separate counter for normal.
Hi, I am a Japanese researcher of CSS.
I have summarized my views on the pros and cons of ASCII spaces before and after Western text in HTML documents or plain text. It then gives its opinion as to what would be an appropriate initial value for the text-autospace property in this case.
https://qiita.com/debiru/items/1b4a5aa73fe5c952e104
Since I have written a blog post in Japanese, only the conclusions are reprinted here.
The proper initial value for the CSS specification is normal.
In this case, we should consider what the ideal state is and whether there are any practical problems that would limit it, in that order, before finding a "realistic answer" to the question.
[css-text-4] interscript text-spacing as default #8262 has determined the following as of 2022.
Defines the interscript autospace to be 1/8 of the ideographic advance (0.125ic), which is the smallest amount in the common-use range. The primary justification for using 1/8 instead of 1/6 or 1/4 is that, since we're trying to make this the default, it minimizes the layout impact on existing pages. (Note that Antenna House uses a 1/4 default.)
There is no reason not to enable the text-autospace property by default, since the concrete values for character spacing are small to reduce the impact on existing web pages.
The default value that most recent browsers should implement is no-autospace.
Looking at the comments on the GitHub Issue, some people have suggested that no-autospace should be the default value because of performance concerns.
Personally, if applying text-autospace: normal to a web page causes performance problems, I think we can conclude that text-autospace: normal is useless, not because of the initial value.
There should be a balance between providing a function that "adjusts the spacing between Japanese and Latin characters to make it easier to read" and "providing such a function without causing performance problems".
It would be a mistake to provide the text-autospace property when both of these features have not been met. If you do not want to use the normal value as the initial value because of concerns about performance issues, but you want to provide the text-autospace property itself, then I think that no-autospace is a realistic browser implementation of the text-autospace property as an initial value.
What conclusions do you intend to draw on this topic?
Forcing it on by default is a different topic. It means that we ignore authors who don't want the space. It means that we require users who don't want it to install extensions. It means that we don't care slowing down pages of other scripts, such as Arabic, Thai, Devanagari, etc.
I think you are confusing the question of "what should be the default value as a CSS specification" with the question of "what should be the default value for the most recently released browsers (Safari, Google Chrome) as of July 2025". Performance problems occur because of the algorithm used to implement it in the browser, not because of the text-autospace property itself.
If the functionality that the text-autospace property provides inherently has performance problems, then the text-autospace property should not be supported and should be eliminated from the CSS specification.
