Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2012-07-31 13:04:13

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,199
Website

Re: Remora_arabic : textpattern admin theme for rtl langage

OK, I’ve made these changes as suggested. Is that OK to put into SVN and the admin themes now?

Offline

#12 2012-07-31 15:13:39

Gocom
Plugin Author
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Remora_arabic : textpattern admin theme for rtl langage

phiw13 wrote:

and looking close, remove the universal selector everywhere. Just set the font-family on the root element, it will cascade through

Yes it does cascade. But that doesn’t override fonts for every element. You will have to specify override rules for everything that uses a specific font-family, otherwise the browser chooses the first font from the stack that is considered appropriate. In the frontend theme I see three different fonts in use total.

  • Courier: pre, code, kbd, samp, var
  • Arial: select, optgroup, buttons, inputs
  • And the override.

Since it cascades it always uses the first font that is appropriate from the stack. I.e. Arial for anything and everything Latin. E.g. missing translation, terminology, latin options in setting fields.

Last edited by Gocom (2012-07-31 15:29:25)

Offline

#13 2012-07-31 15:47:47

Gocom
Plugin Author
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: Remora_arabic : textpattern admin theme for rtl langage

philwareham wrote:

OK, I’ve made these changes as suggested. Is that OK to put into SVN and the admin themes now?

html[lang="ar-dz"] {
	font-family: Tahoma;
}

The above rule should have no effect, since Arial already contains Hebrew and Arabic glyphs.

Offline

#14 2012-08-01 01:06:47

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,715
Website

Re: Remora_arabic : textpattern admin theme for rtl langage

Gocom wrote:

Yes it does cascade. But that doesn’t override fonts for every element. You will have to specify override rules for everything that uses a specific font-family, otherwise the browser chooses the first font from the stack that is considered appropriate.

That is not necessarily a bad thing… Given that for many languages there aren’t appropriate fonts for monospace available on the various platforms. Having that kind of cascading do its job will at least guarantee that e.g. pre text is displayed in a monospace font. And I’ve aways argued that it is a bad idea to specify a font-family for form controls. Leaving it at the OS default is often the best course of action. There are often subtleties that are hardcoded by the UA and out of reach of the designer.

(and btw, in the default classic/textpattern.css, the font-family is specified on the body element; the rules note in previous posts in this thread will be overridden – I had forgotten about that. The font-family should always be specified on the root element. Instead of body {font-family:}, use html {font-family:}). It is more efficient esp. for a stylesheet that is used in a multi-lingual environment)

(and note that I haven’t had a look at the default front-end theme for a long while, my primary concern is the back-end themes atm)

But anyway, bickering over fonts is an endless discussion that won’t bring us very far and derails the purpose of this thread. There are (in my book) some more important things to edit to make the default (back-end) themes more RTL friendly: the usage of text-align should be checked, and make sure that everything is mirrored. E.g.

th,
td {
	text-align: left;

Then the use padding-left, padding-right (and margins) should also be checked, as is the use of pinning things with absolute positioning. Borders are another potential candidate (I noted that in my first post in this thread, dunno if anybody has taken the time to check what I do in Sandspaces 4… – note that in Sandspaces I don’t specify fonts for non-western languages, except Jpn; the browser / OS font fallback does its job correctly, at least for the environment in which the stylesheet is used. If I were to design a front-end theme, that would be another matter.)

Offline

Board footer

Powered by FluxBB