Closed Bug 1023702 Opened 10 years ago Closed 7 years ago

Tracking: Italic style in the UI is considered harmful for non-Latin/Greek/Cyrillic scripts, consider allowing these locales to opt-out from it

Categories

(Firefox OS Graveyard :: Gaia, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: timdream, Unassigned)

References

Details

(Keywords: l12y)

Since 2.0 we update the style to use italic extensively in FxOS. Italic style does not actually exists for CJK characters, and browser/font has to simulate that by skewing the characters. This is really bad for readability of the labels for these locales, and the UI looks visually amateurish too (unfortunately). Simply do a web search on "italic Chinese character" you will find many supporting argument on the statement above. Please consider allowing these locale to opt-out the italic style. Technically, we can do it in framework CSS. More importantly, please refrain from creating visual styles where emphasis is only distinguishable by italic styling.
Flags: needinfo?(padamczyk)
Flags: needinfo?(mtsai)
Flags: needinfo?(l10n)
Flags: needinfo?(firefoxos-ux-bugzilla)
I agree. We should never use italics unless they are native to the language. We should also be specifying the font by style and not using the <i> so I am not sure why CJK is being skewed programmatically. +Przemek for FYI
Flags: needinfo?(padamczyk)
Flags: needinfo?(pabratowski)
Flags: needinfo?(mtsai)
Note, Arabic script probably has the same problem. The problem is in shared/elements/gaia_header/style.css, h1 {... font-style: italic;...} Our platform goes out its way to make italic look like italic, even if it's a bad idea for a particular script. Not sure if there's a better way to do unitalic than to add a bunch of lang() selectors.
Flags: needinfo?(l10n)
(In reply to Axel Hecht [:Pike] from comment #2) > Note, Arabic script probably has the same problem. It's pretty questionable for Hebrew, too -- and probably for the majority of scripts and languages outside the Latin/Greek/Cyrillic world. In most cases, we'll end up with an artificially-slanted version of the default font face, and this both looks poor, and does not provide an equivalent stylistic contrast to the Roman/Italic distinction in Latin script.
(In reply to Patryk Adamczyk [:patryk] UX from comment #1) > I agree. We should never use italics unless they are native to the language. > We should also be specifying the font by style and not using the <i> so I am > not sure why CJK is being skewed programmatically. It doesn't matter whether we use <i> or something less direct via a stylesheet -- in the end, <i> resolves to font-style:italic via html.css anyway. So we'll use the italic face of the current font-family. But if the family doesn't have an italic face, we'll artificially slant the default (font-style:normal) face as a fallback. This behavior is specified by CSS Fonts[1], though it's worth noting that the spec warns that oblique versions of normal faces may not be appropriate in all scripts. In theory, the use of synthetic oblique as a fallback for an unavailable italic face can be disabled via the font-synthesis:none property[2] (or font-synthesis:weight, to allow artificial bold but not italic). However, this would simply erase the style distinction that the designer was trying to make, so by itself it may not be a satisfactory solution. Also, font-synthesis isn't currently implemented in Gecko (bug 871453). :( [1] http://www.w3.org/TR/css3-fonts/#propdef-font-style [2] http://www.w3.org/TR/css3-fonts/#propdef-font-synthesis
(In reply to Axel Hecht [:Pike] from comment #2) > Not sure if there's a better way to do unitalic than to add a bunch of > lang() selectors. There aren't ... I was thinking about this in comment 0.
(In reply to Jonathan Kew (:jfkthame) from comment #3) > It's pretty questionable for Hebrew, too -- and probably for the majority of > scripts and languages outside the Latin/Greek/Cyrillic world. Sounds like we should just ditch italic altogether for the sake of internationalization?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6) > (In reply to Jonathan Kew (:jfkthame) from comment #3) > > It's pretty questionable for Hebrew, too -- and probably for the majority of > > scripts and languages outside the Latin/Greek/Cyrillic world. > > Sounds like we should just ditch italic altogether for the sake of > internationalization? That's a hard call. Ideally, localizers would be able to decide whether to allow italic or replace it with some other stylistic choice such as a different font-family. But I don't know how feasible this is within our l10n workflow. And they may not have an alternative font available anyhow. Note that in non-Latin/Greek/Cyrillic scripts, we *also* won't have the wide range of weights that our designers are used to using in Fira Sans. So the available options for making typographic distinctions between elements will be much more limited: in many cases, there's a single font face, with two weights "normal" and "bold" (though in some cases that's an artificial bold), and that's it. I'm not suggesting our designers need to limit themselves to two weights of Fira, and no italics; that'd be terribly constraining. But this is an issue to keep in mind: many of the more subtle typographic distinctions we like to make in Latin script simply won't be possible across all locales.
I would suggest we not artificially slant any fonts and only use italic when the font has an italic version in the font family. It's very important that we are able to design with italics and a wide range of font width so lets not remove these things.
Flags: needinfo?(pabratowski)
For the record, though: we will need to change our use of italics, as a pattern exception, for languages for which they do not make sense, like Arabic and others. This has been noted in our UX patterns backlog.
Flags: needinfo?(firefoxos-ux-bugzilla)
Depends on: 871453
Just was thinking of filing this bug, thanks Tim. For zh-TW I support to make the use of italic fonts optable.
It's been discussed in the world ready list where |font-synthesis| will not solve uses like below: "您正在使用 Firefox OS 手機" ("You are using a Firefox OS phone.") When |font-synthesis| property is applied, it will not stop the word "Firefox OS" shown with true italic style. This unfortunately means we need to go back to lang() selecter solution in comment 2... :'(
No longer depends on: 871453
Update based on comment 2 and comment 3.
Summary: Italic style in the UI is considered harmful for CJK languages, consider allowing these locales to opt-out from it → Italic style in the UI is considered harmful for non-Latin/Greek/Cyrillic scripts, consider allowing these locales to opt-out from it
Copying my lists from world-ready: My guess would be With italic: ast be bg bs ca cs cy da de el en-GB en-US eo es et eu ff fr fy-NL ga-IE gd gl hr ht hu id it lij lt mk ms nb-NO nl pl pt-BR ro ru sk sl son sq sr-Cyrl sr-Latn sv-SE sw tr vi xh Without: ar as bn-BD bn-IN fa gu he hi-IN ja km kn ko mai ml mr ne-NP or pa si ta te th ur zh-CN zh-TW There are a few border-line examples like Vietnamese, which are in latin-derived scripts, for which we may or may not have glyphs in the italic variants of our font?
(In reply to Axel Hecht [:Pike] from comment #13) > There are a few border-line examples like Vietnamese, which are in > latin-derived scripts, for which we may or may not have glyphs in the italic > variants of our font? AFAIK, we should have the same character repertoire in the italic and regular faces of Fira, so Vietnamese will be OK.
Converting this to a tracking bug because it's unlikely I can get this fixed in one patch.
Assignee: nobody → timdream
Summary: Italic style in the UI is considered harmful for non-Latin/Greek/Cyrillic scripts, consider allowing these locales to opt-out from it → Tracking: Italic style in the UI is considered harmful for non-Latin/Greek/Cyrillic scripts, consider allowing these locales to opt-out from it
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #11) > It's been discussed in the world ready list where |font-synthesis| will not > solve uses like below: > > "您正在使用 Firefox OS 手機" ("You are using a Firefox OS phone.") > > When |font-synthesis| property is applied, it will not stop the word > "Firefox OS" shown with true italic style. Is this the only reason font-synthesis can not solve our problem? What if we wrapped "Firefox OS" with an inner <span> element, "您正在使用 <span class="no-synthesis">Firefox OS</span> 手機", could something like that work? Alternatively can we only enable font-synthesis for whitelisted languages? The solution in bug 1041293 does not seem very scalable to me.
Flags: needinfo?(timdream)
(In reply to Kevin Grandon :kgrandon from comment #16) > Is this the only reason font-synthesis can not solve our problem? What if we > wrapped "Firefox OS" with an inner <span> element, "您正在使用 <span > class="no-synthesis">Firefox OS</span> 手機", could something like that work? > I don't think it make sense to do non-trivial change on the DOM for this work -- especially when UX people simply say yes this is a problem, but this not a problem we are going to schedule effort to address when half of the team is in Taiwan. I am simply doing what's available to me. Besides, it's really possible to wrapping /every/ Latin wording in Gaia. > Alternatively can we only enable font-synthesis for whitelisted languages? > The solution in bug 1041293 does not seem very scalable to me. Something like |*:lang(zh) { font-synthesis: none !important }| ? That still don't fix the comment 11 example without heavy-lifting on the DOM.
Flags: needinfo?(timdream)
s/I am simply doing what's available to me./I am simply doing what's doable for me on weekend w/o taking too much time./ s/it's really possible/it's really NOT possible/
In the prefect world we should have something similar to https://developer.mozilla.org/en-US/docs/Web/CSS/:dir , but we don't live in the prefect world and I am tired of arguing about it.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #19) > In the prefect world we should have something similar to > https://developer.mozilla.org/en-US/docs/Web/CSS/:dir , but we don't live in > the prefect world and I am tired of arguing about it. Should we talk to some layout/css guys to see what solutions we can come up with here? My personal thought is that this is a huge workaround for a missing platform feature. I'd rather not land these workarounds without a clear path of moving away from them. Maybe we also hastily implemented the italic font, and perhaps that should be removed until we can properly support it?
I've just send an e-mail to dev-webapi.
(In reply to Kevin Grandon :kgrandon from comment #20) > Maybe we also hastily implemented the > italic font, and perhaps that should be removed until we can properly > support it? comment 8 objects removing italic from their solutions.
Taking this to product planning to make sure we don't get late surprise from partners.
feature-b2g: --- → 2.2?
(In reply to Kevin Grandon :kgrandon from comment #20) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #19) > > In the prefect world we should have something similar to > > https://developer.mozilla.org/en-US/docs/Web/CSS/:dir , but we don't live in > > the prefect world and I am tired of arguing about it. > > Should we talk to some layout/css guys to see what solutions we can come up > with here? My personal thought is that this is a huge workaround for a > missing platform feature. I'd rather not land these workarounds without a > clear path of moving away from them. Maybe we also hastily implemented the > italic font, and perhaps that should be removed until we can properly > support it? This is really a UI design problem, not a layout/css problem. If your design needs to work across scripts, using italics is problematic. Whatever you wanted to achieve by using italics, you need to adjust your design to create a similar design contrast in the context of scripts that don't have something akin to an italic tradition. Using a different weight is used in CJK contexts but that's probably not possible given available Firefox OS fonts.
(In reply to John Daggett (:jtd) from comment #24) > This is really a UI design problem, not a layout/css problem. If your design > needs to work across scripts, using italics is problematic. Whatever you > wanted to achieve by using italics, you need to adjust your design to create > a similar design contrast in the context of scripts that don't have > something akin to an italic tradition. Using a different weight is used in > CJK contexts but that's probably not possible given available Firefox OS > fonts. Yes. Just to close the loop here. The conversation on dev-webapi concludes that we should be using CSS variable to toggle italic font style, without trying to proposing any platform feature for now.
Per our earlier comments, please remember that we must be able to use italics in languages that use REAL italics, not a fake slant forced on languages that don’t work with italics. Axel's comment #13 is great. I don't understand the comments about "not prioritizing this." We had indeed prioritized it for 2.2, but due to the updated timeline it got pushed to 2.3. Also please remember that Przemek should be flagged on ui-review? to review any font related changes, anywhere on the OS. Thanks!
One thing I came across recently is a proposal to have a script() selector added to CSS, which would fold many of those language selectors into just a few. Don't have better references than Gunnar Bittersmann's talk at MLW in Limmerick, http://www.multilingualweb.eu/documents/limerick-workshop/limerick-workshop-report#bittersmann. Don't think this even ever made it to www-style.
No longer blocks: 1096865
Depends on: 1096865
This is not committed feature for 2.2.
feature-b2g: 2.2? → ---
I am to frustrated to work on this and I want to get this out of my assigned bug list. Ping me once this gets more traction.
Assignee: timdream → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.