- From: Paweł Dyda <pawel.dyda@gazeta.pl>
- Date: Sun, 2 Oct 2011 22:13:21 +0200
- To: www-international@w3.org
- Message-ID: <CAJJ2KzYCzM8Ag5NbsyJLzuBskW1=gTO=2-jTUn=KJn3Dxj18Ww@mail.gmail.com>
Hi, As we all know, CSS has built-in Localization mechanism that helps adapt style sheets to concrete Locale demands. One of the examples of CSS pseudo-classes designed for these purposes is :lang. Now, quite often I have a problem where I need to define certain property for a group of languages (for example set different color scheme or different font size for Asian customers). OK, if only developers would use element Identifiers, there won't be any problem: #someid:lang(ja), #someid:lang(ko), #someid:lang(zh), #someid:lang(vi) { background-color: black; .... (other properties) } Unfortunately, in my company I and my colleagues are struggling to enforce this best practice, so instead they might use an identifier for just a top-level element (like DIV, etc.) but not for its children. In such case, selector code could look like: #main p span:lang(ja), #main p span:lang(ko), #main p span:lang(zh), #main p span:lang(vi) { ... } If we have quite a few such definitions (for example some elements must be wider in German, Greek and Russian but not in other languages), maintaining such CSS file could quickly become challenging. And unfortunately, files with many such definitions could quickly become totally unreadable. Of course in my idealistic example, all the properties where grouped into one definition but in reality Localization Team would define another class for each element they need to modify - this would create terrible mess. Currently, what we do is, we actually implement server-side Localization for CSS files (i.e. generating CSS for given Locale on the fly), but this is non-standard solution which requires quite an effort to get it right. What I think we could afford to make an improvement to current :lang pseudo-selector specification - let it handle comma-separated list of languages: #main p span:lang(ja,ko,zh,vi) { ... } I understand that this could complicate CSS parsing algorithms but actually it could be viewed as just a syntactic sugar - it could be easily transformed to previous form. Please tell me what you think about it? Kind regards, Paweł Dyda.
Received on Monday, 3 October 2011 07:48:13 UTC