headers
Pascal Germroth | 1 Nov 2006 02:01
Gravatar

Re: CSS color palettes


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

> While proposals for variables in CSS get rejected on a regular and
> frequent basis, this one made me wonder if there was a backward
> compatible way after all: overloading keywords.

But wouldn't it be "semantically bad" to, for example, overload "red"
with your favorite green? Variables (or constants, if you want) would
really be better, then...
But doesn't CSS already have variables, for the counters? Wouldn't it be
easy to do something likewise for "real" variables? Like:

 <at> define menucolor { value: #f00; }
#menu { color: value-of(menucolor); }

- --
Pascal Germroth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBRUfx7IplHwrShYbrAQLTmwf+LJ7YKTfTcjqu1hj3upPdG3Yzp9BbkXpR
//sZxoaYlk3c/x2DsfzyPPDAfT+iLXJFJFLIRbZKMP1gbAjrE3+bFlWXYjuRNjTh
zpdj4I6Lj7/n2Cevn8zlFa19KHLeU1Cxw3IBlo2vAY7yP3DTMkkIMEaOsCffBufx
Ni+KcRSk9Do9V6QhgfQcqxDg81d7v4z0g5rg8PWmCOmghW+7Yw0WrdrcoWGjqLZ8
jJCdKG8LD0BaAt+6JZj1XGioKi4sY1VhNu4BcDbPy86Hw9PEpUYfk7+9E9e/vgDz
DKgrU/KKrfcPM5WjsyyfKBVfzq6fDm+IABNw67KsuNO08lX0ykdGuw==
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Ishida | 1 Nov 2006 17:49
Picon
Favicon
Gravatar

RE: bidi-override scope in CSS2 and CSS 2.1


Taking into account the previous mails on this topic, I produced a brief
summary-so-far of my thoughts wrt CSS specifically at
http://www.w3.org/International/notes/notes-rlo-blocks-css.php

I would like to take the discussion further, and to this end will send out
separate notes on what I see as the main outstanding issues.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/

> -----Original Message-----
> From: www-style-request <at> w3.org 
> [mailto:www-style-request <at> w3.org] On Behalf Of Paul Nelson (ATC)
> Sent: 25 October 2006 00:12
> To: www-style <at> w3.org
> Subject: FW: bidi-override scope in CSS2 and CSS 2.1
> 
> 
> I responded to the mail on 19 September with following:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Ishida | 1 Nov 2006 17:57
Picon
Favicon
Gravatar

Embedded block elements should not reject the override


See http://www.w3.org/International/notes/notes-rlo-blocks-css.php

Background

These notes relate to the handling of right-to-left and
left-to-right overrides in CSS and to some extent in HTML and xHTML.
They draw on information in the following mail threads:
  * [18]bidi-override scope in CSS2 and CSS 2.1

[18] http://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=bidi-override+scope+in+CSS2+and+CSS+2.1&search=Search

Suppose we have the following code in an XML application such as
XHTML2, embedded in content with a base direction of ltr:
<div dir="rlo">Some inline text
and more inline text on another line
<p>A paragraph of text</p>
Some more <em>inline</em> text
</div>

and the following CSS style in the same document:
*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}

Embedded block elements should not reject the override

With [19]CSS2.1 the result of the markup above would be (should be right-aligned):
enil rehtona no txet enilne erom dna txet enilni emoS
A paragraph of text
txet enilni erom emoS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Ishida | 1 Nov 2006 17:59
Picon
Favicon
Gravatar

rlo text should not be automatically right-aligned


See http://www.w3.org/International/notes/notes-rlo-blocks-css.php

Background (repeated)

These notes relate to the handling of right-to-left and
left-to-right overrides in CSS and to some extent in HTML and xHTML.
They draw on information in the following mail threads:
  * [18]bidi-override scope in CSS2 and CSS 2.1

[18] http://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=bidi-override+scope+in+CSS2+and+CSS+2.1&search=Search

Suppose we have the following code in an XML application such as
XHTML2, embedded in content with a base direction of ltr:
<div dir="rlo">Some inline text
and more inline text on another line
<p>A paragraph of text</p>
Some more <em>inline</em> text
</div>

and the following CSS style in the same document:
*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}

rlo text should not be automatically right-aligned

Given the CSS and markup above, the div when displayed would
currently be right aligned. This is due to the presence of the
[20]direction property, the value of which affects the initial
setting of [21]text-align.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Nelson (ATC | 1 Nov 2006 22:58
Picon

RE: rlo text should not be automatically right-aligned


Richard,

Your assertion that "rlo" and "lro" should not set the text direction is flawed because you are putting two
properties together. 'direction' sets initial block level text-align. The 'unicode-bidi' is a second
property that does not set the block direction. ****Please do not override the 'dir' property to contain
two properties**** It only causes confusion.

The <bdo> is an inline element and never sets the block text-align. In your example, the block level
direction is set by the <blockquote> element. If you do the following your blockquote will also be left
aligned because the 'direction' property is ltr. 

<p>The text is stored in logical order, so the order of characters in memory would  be:</p> <blockquote
style="direction: ltr; unicode-bidi: bidi-override;">םואניבה תוליעפ, W3C</blockquote>

In your exampe given below you have explicitly set the block level direction to rtl and therefore the text
should be initially right aligned...whether or not the bidi-override is applied. That is consistent
with behavior for bidi text. 
<div style="direction: rtl; unicode-bidi: bidi-override;">Some inline text
and more inline text on another line
<p>A paragraph of text</p>
Some more <em>inline</em> text
</div>

Now lets have some fun. Please don't confuse 'text-align' (a content property) with block align. Put some
width on the <div> like the following:
<hr>
<div style="width: 250px; background-color: tan; direction: rtl; unicode-bidi: 
bidi-override;">Some inline text
and more inline text on another line
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bert Bos | 2 Nov 2006 18:58
Picon
Favicon

Re: rlo text should not be automatically right-aligned


On Wednesday 01 November 2006 22:58, Paul Nelson (ATC) wrote:
> Richard,
>
> Your assertion that "rlo" and "lro" should not set the text direction
> is flawed because you are putting two properties together.
> 'direction' sets initial block level text-align. The 'unicode-bidi'
> is a second property that does not set the block direction.
> ****Please do not override the 'dir' property to contain two
> properties**** It only causes confusion.

Just another small clarification on the 'text-align' property:

The CSS2 specification is rather brief on how a block's 'direction' 
property influences the default alignment, but the right interpretation 
is that the initial value of the property is neither 'left' nor 
'right', but another, nameless value, which acts as 'left' or 'right' 
depending on the 'direction' property.

The WG already decided some time ago to give this value an explicit name 
in CSS3, viz. 'start'[1] (borrowed from XSL-FO) and now also decided to 
improve the wording in CSS2 to make it unambiguous that the initial 
value is indeed neither 'left' nor 'right'. (The CSS3 Text Module is 
already clear on that point.)

This 'start' value exists basically to ensure that documents in a single 
script automatically align to the correct side in the absence of any 
CSS rules. It may indeed lead to surprising results in documents with 
mixed scripts, because the value is inherited, and thus a nested block 
element may unexpectedly be aligned differently from its parent, just
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 3 Nov 2006 16:31
Picon
Favicon

[CSS21] Computing widths of block reflow context roots in the presence of floats


Consider the following testcase:

   <body style="width: 300px">
     <div style="float: left; height: 100px; width: 100px"/>
     <div style="overflow: hidden" id="test">
       Text
     </div>
   </body>

And assume all three elements generate block boxes and no other styles are 
applied.  What is the correct layout?  Per section 10.3.3, the computed width of 
the id="test" block is 300px, and since its margin box may not overlap the float 
I'd expect it to be cleared below the float.  But there's some sort of confusing 
wording in section 9.4.1 about "the box itself may become narrower due to the 
floats", and all current UAs make the id="test" block 200px wide and place it 
next to the float...

Is the idea that both layouts are "correct" per the spec or something?

-Boris

Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=359135
Permalink | Reply | 4 comments |
headers
Andrew Fedoniouk | 4 Nov 2006 05:21
Favicon

Re: [CSS21] Computing widths of block reflow context roots in the presence of floats


Boris, I suspect that you are using not up to date document.
The one which is published currently stays:

 "(although a box's *line boxes* may shrink due to the floats),"

See: http://www.w3.org/TR/CSS21/visuren.html#q15

Or someone just have updated the document.

Andrew Fedoniouk.
http://terrainformatica.com

----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky <at> mit.edu>
To: "www-style Mailing List" <www-style <at> w3.org>
Sent: Friday, November 03, 2006 7:31 AM
Subject: [CSS21] Computing widths of block reflow context roots in the 
presence of floats

>
> Consider the following testcase:
>
>   <body style="width: 300px">
>     <div style="float: left; height: 100px; width: 100px"/>
>     <div style="overflow: hidden" id="test">
>       Text
>     </div>
>   </body>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
L. David Baron | 4 Nov 2006 06:01
Gravatar

Re: [CSS21] Computing widths of block reflow context roots in the presence of floats

On Friday 2006-11-03 20:21 -0800, Andrew Fedoniouk wrote:
> 
> Boris, I suspect that you are using not up to date document.
> The one which is published currently stays:
> 
> "(although a box's *line boxes* may shrink due to the floats),"
> 
> See: http://www.w3.org/TR/CSS21/visuren.html#q15
> 
> Or someone just have updated the document.

No, Boris was quoting the second parenthetical in the sentence, not
the first.  The entire sentence is:

# This is true even in the presence of floats (although a box's
# *line boxes* may shrink due to the floats), unless the box
# establishes a new block formatting context (in which case the box
# itself *may* become narrower due to the floats).

which makes sense given that the message was about block formatting
context roots.

-David

--

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 4 Nov 2006 06:06
Picon
Favicon

Re: [CSS21] Computing widths of block reflow context roots in the presence of floats


Andrew Fedoniouk wrote:
> Boris, I suspect that you are using not up to date document.
> The one which is published currently stays:
> 
> "(although a box's *line boxes* may shrink due to the floats),"

The part I was quoting is in the next clause.  The full sentence is:

   This is true even in the presence of floats (although a box's
   line boxes may shrink due to the floats), unless the box
   establishes a new block formatting context (in which case the
   box itself may become narrower due to the floats).

In my case, the box has overflow:hidden, so establishes a new block formatting 
context.

-Boris
Permalink | Reply | 1 comment |

Gmane