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

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

From: Zack Weinberg <zweinberg@mozilla.com>
Date: Sat, 29 May 2010 15:31:53 -0700
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: HĂ„konWiumLie <howcome@opera.com>, <www-style@w3.org>
Message-ID: <20100529153153.7f3f4d1f@moxana.local>
"Andrew Fedoniouk" <news@terrainformatica.com> wrote:
> 
> I don't think that guessing :rtl or :ltr values by using particular
> character runs is a good idea at all.
> 
> E.g. there is a task of presenting file names or URLs in UI.
> Think about file name in e.g. Hebrew but with ".htm" extension.
> Usually this is treated as <div dir="ltr"> so overall directionality
> is still LTR.  To be short: :ltr and :rtl are explicitly @dir based.
> 
> Is this the answer?

Yeah, that's the answer to the question I was asking.  Your proposal
completely ignores what the Unicode bidi algorithm computes, and looks
only at explicit attributes on HTML elements.

It seems to me that this is almost certainly not what authors want,
but I have no great experience with multi-language presentation, so I
could be wrong.  My proposal would be ::ltr, ::rtl, ::ttb, etc
pseudo-elements rather than pseudo-classes; they would match ranges of
text that were resolved to be drawn in a particular direction,
regardless of why the bidi algorithm made that decision, and they would
ignore element boundaries.

(A difficulty with this is that you have to set things like margin on
elements. Perhaps we could relax the "pseudo-element only at end"
rule?  Then you could do

::ltr p ::first-line { padding-left: 2em }
::rtl p ::first-line { padding-right: 2em }

for instance.  (In a world where padding on first-line actually did
anything, of course.))

zw
Received on Saturday, 29 May 2010 22:32:28 GMT

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