W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 3 Jun 2010 23:22:06 -0700
Message-ID: <B31B6D5C603A4A019482466F2B3CC325@terra3>
To: HåkonWium Lie <howcome@opera.com>
Cc: "www-style list" <www-style@w3.org>

--------------------------------------------------
From: "HåkonWium Lie" <howcome@opera.com>
Sent: Thursday, June 03, 2010 10:34 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "www-style list" <www-style@w3.org>
Subject: Re: [css3-text-layout] New editor's draft - 
margin-before/after/start/end etc.

> Also sprach Andrew Fedoniouk:
>
> > CSSOM/RTL discussion reminded me one question that I wanted to ask:
> > Are we going to "virtualise" coordinate based DOM events also
> > with respect of these -start/end properties?
> > So MouseEvent.clientX/Y will get also
> > MouseEvent.clientStart/???? logical, direction dependent cousins?
> >
> > Sorry in advance if you think that the question is out of scope of the
> > discussion.
>
> I hope we all have a sense of humor, even in culturally sensive topics :-)

I hope so either :) But I am not the author of that one.
How about this:
http://www.microsoft.com/middleeast/msdn/mirror.aspx ?
It was quite hard for me to get used to the fact that the left edge of the 
window
rectangle becomes the right edge in a mirrored window, and vice versa.
My reaction was precisely as yours. I have no idea about motivation
behind such a solution.

My own experience shows that it just creates even more problems.
But that's probably for me only.

>
> > Something tells me that solution that leads to combinatorial
> > explosion of properties number in CSS is a "solution
> > of bad quality" in technical terms.
>
> Yes, I'm concerned as well. I'd like to see an overview of all the
> direction-dependent properties/aliases/values that one plans to
> propose. For example, will there be aliases for the
> top/right/bottom/left properties?
>
> In general, I do not believe one can simply switch writing direction
> and reuse the same style sheet; there are more properties that
> should be adjusted when the writing direction is changed. As such, I
> believe your :rtl, :lrt, :ttb proposal has the potential for producing
> better typography as you can add more declarations. E.g.,
>
> p:rtl {
>  font-family: ...;
>  margin-right: ...;
> }
>
> p:rtl em {
>  letter-spacing: ...;
> }
>

Yep. Practice shows that :rtl and :ltr are quite useful
and well understandable by authors.
el:rtl is pronounced as "when element is in RTL environment ...".

And I also think that "one can simply switch writing direction"
is quite naïve expectation.  There are also images for example.
And, woo-hoo!,  the <canvas>, ladies and gentlemen.

> > Can we try to solve the problem some other way?
> > E.g. by introducing something like single 'orientation' property
> > instead of the whole bunch?
>
> What do you have in mind?

Something as straightforward as that WS_EX_LAYOUTRTL
window style (from the link above).

But our practice shows that having 'direction'
and :rtl/:ltr environment states are just enough
for the RTL/LTR handling. Authors who care about this
will use :ltr/:rtl rules rather than those  magic
auto-switchable-and-reversible  "***-start" constructions.

The 'direction' defines two things:
1) 'base direction of text' in UNICODE sense and
2) order of horizontal blocks - e.g. in tables and in our case
when flow:horizontal is used. Not more not less.

And :rtl/:ltr states allows to define *precisely and predictable*
different margins/paddings/borders/etc. for different modes.

I've been told by professional designers that typographic
preferences for Arabic are quite different from ones used
in Latin.  Making them automatically applied can make
the problem even worse.

-- 
Andrew Fedoniouk

http://terrainformatica.com
 
Received on Friday, 4 June 2010 06:22:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT