Open
Bug 1252962
Opened 8 years ago
Updated 1 year ago
"text-transform: capitalize" misses word boundaries
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
NEW
People
(Reporter: mike.lewitz, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
343 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822
Steps to reproduce:
Firefox v44.0.2 (Windows 7)
<style>
#foot { font-size: 13px; text-transform: capitalize }
#foot a { padding-left: 10px; padding-right: 10px }
</style>
<div id="foot">ACME inc.<a href="contact-us">contact us</a>|<a href="privacy">privacy policy</a>|<a herf="disclaimer">income disclaimer</a></div>
Actual results:
ACME Inc. contact Us | privacy Policy | income Disclaimer
Expected results:
ACME Inc. Contact Us | Privacy Policy | Income Disclaimer
Notes: Renders correctly in other browsers...
Chrome 48.0.2564.116, Opera 35.0.2066.82, Safari 5.1.7, IE 9.0.8112.16421, Dolphin v11.5.5 (tablet).
Recognize that there are no spaces between the "pipes" (or after the period) and the html. The spaces are created visually via css. Adding a space after the pipe or period renders correctly.
|
||
Comment 2•7 years ago
|
||
Jonathan, looks like gecko current implementation is different from Blink and Webkit, is it expected or a todo?
Blocks: css-text-3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jfkthame)
Priority: -- → P3
|
||
Comment 3•7 years ago
|
||
The issue here is that browsers differ regarding what is a "word boundary" for text-transform:capitalize purposes. Reduced testcase:
data:text/html;charset=utf-8,<div style="text-transform:capitalize">
one.two_three-four/five|six%E2%80%98seven%E2%80%99eight%E2%80%9Cnine%E2%80%9Dten
Here, Gecko doesn't capitalize anything except the initial "One", while Blink also capitalizes "Four", "Five", "Six", "Nine" and "Ten".
Note that the spec[1] says:
# For capitalize, what constitutes a “word“ is UA-dependent; [UAX29] is suggested
# (but not required) for determining such word boundaries.
so as far as the spec is concerned, nobody is particularly "right" or "wrong" here; but equally, we're free to modify our behavior if we think it would improve things.
The other aspect of the original example, the CSS-created "spacing" between the items, is something of a red herring, at least from the interop PoV: in a testcase like:
data:text/html,<style>div{text-transform:capitalize}span{margin:0 1em}</style>
<div><span>one</span><span>two</span>
neither Gecko nor Blink capitalizes "two", despite the generous amount of visual space separating the "words". Arguably, it might be good to treat non-zero margin/border/padding at the inline-start/end edges of an element as constituting a word boundary here.
[1] https://drafts.csswg.org/css-text/#text-transform-propertyFlags: needinfo?(jfkthame)
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Comment 4•1 year ago
|
||
I see regression to Chromium:
<!DOCTYPE html>
<html>
<head>
<style>
#test-1, #test-2 { text-transform: capitalize }
#test-1 span { text-transform: lowercase }
</style>
</head>
<body>
<p id="test-1">Lowe’<span>s</span><br> Black'<span>s</span></p>
<p id="test-2">Lowe’s<br> Black's</p>
</body>
</html>
In Firefox 113+ we have "Lowe'S" / "Black’S" instead small "s".
|
|
||
Comment 5•1 year ago
|
||
Thanks for the report. I've filed this as bug 1827604, as it's somewhat different from what this bug was about.
You need to log in
before you can comment on or make changes to this bug.
Description
•