Re: CSS3 Color: Interaction of opacity and rgba [css3-color]

On Wednesday 2003-07-23 20:44 -0400, REFSTRUP,JACOB (HP-Vancouver,ex1) wrote:
> I had a question around opacity and rgba and their interaction based on the
> CSS3 Color module. Suppose the following style sheet:
> 
> span { 
>   color: rgba(100%,0,0,0.5);
>   opacity: 0.1
> }
> 
> Does both "alpha" values apply? I.e. would the text inside a span render
> with an effective opacity of 0.05 onto its parents element?

I managed to find this comment despite its lack of the string
"css3-color" (which is in the spec's URL).

Both alpha values do apply (but through different mechanisms).

This is tested in the test suite:
http://dev.w3.org/CSS/css3-color-test-suite/src/t32-opacity-offscreen-with-alpha-c.xhtml

I don't think any change to the specification is needed.  It
describes the two features independently, since they are in fact
independent.

-David

--

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Fwd: RE: [css3-color] RGBA Hex Notation]

These three messages were sent to www-style a number of weeks ago,
but didn't show up in the archives; I presume Bert never moderated
them through to the list.

(My responses to them did show up on the list, though.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

From: Adam Kuehn <akuehn <at> nc.rr.com>
Subject: RE: [css3-color] RGBA Hex Notation
Date: 2008-05-13 17:14:00 GMT

> -----Original Message-----
> From: L. David Baron [mailto:dbaron <at> dbaron.org] 
> Sent: Monday, May 12, 2008 7:41 PM
> To: Mikko Rantalainen; W. Leon Sutton, Jr.; fantasai; Adam Kuehn
> Cc: www-style <at> w3.org
> Subject: Re: [css3-color] RGBA Hex Notation
> 
> On Thursday 2004-09-09 16:56 +0300, Mikko Rantalainen wrote:
> > Ian Hickson wrote:

[css3-color] Moving css3-color to last call

I propose that we (the working group) publish as a last call
(dropping back from Candidate Recommendation to drop features) the
draft currently at http://dev.w3.org/csswg/css3-color/ with the
following changes:

 * Appropriate changes for "Editor's Draft" -> "Last Call Working
   Draft", plus anything else needed for pubrules

 * A link added to a disposition of comments that is just a
   color-coded version of
   http://csswg.inkedblade.net/spec/css3-color

We agreed to most of the changes (described in
http://lists.w3.org/Archives/Public/www-style/2008Mar/0304.html ) at
the last face-to-face.  Since then, the changes since then are those
listed in
http://dev.w3.org/cvsweb/csswg/css3-color/Overview.src.html , the
substantive ones being:

 + revise edits for issue 4 to reflect that we shouldn't specify a
bad behavior for clamping out-of-bounds rgb() color values.  (A
bunch of the change to do this was actually pulling over edits
between CSS2 and CSS2.1.):
http://dev.w3.org/cvsweb/csswg/css3-color/Overview.src.html.diff?r1=1.26&r2=1.27&f=h

 + add resolution for issue 26
http://dev.w3.org/cvsweb/csswg/css3-color/Overview.src.html.diff?r1=1.25&r2=1.26&f=h

 + Pull over a few other changes between CSS2 and CSS2.1, most of

Publishing the flexible box model

I'd like to move forward with publishing the flexible box model as a
working draft.  There have been specs floating around for years, but
it's never been published on the TR page (despite, I believe, a
minuted group resolution to do so at one point).

I think the newest draft is
http://xulplanet.com/ndeakin/xul/specs/flexbox.html .  (There's also
an older draft at
http://www.damowmow.com/temp/csswg/old/ui/flexbox.html .)

I propose we use the shortname css-flexbox; I'm willing to import it
into dev.w3.org space and prepare it for publication if needed.

There's a good bit more technical work needed in writing up the
details of the layout algorithm in mathematical form (and also in
adding more examples, or readding dropped ones from the older spec).
However, I don't think that prevents us from publishing it as a
working draft so that we can get wider feedback on the material we
have so far.

I'll briefly summarize the reasons for this specification:

The flexible box model module adds features to the CSS box model
that provide some of the basic formatting concepts often used in
user interface layout.  Much of the specification is implemented in
both Gecko and Webkit (with prefixes), and this implementation forms
the basis of the formatting model of XUL, the language used to build
the user-interface of Firefox and a number of other applications.
These formatting concepts have a good bit in common with other

Re: Publishing the flexible box model

L. David Baron wrote:
> I'd like to move forward with publishing the flexible box model as a
> working draft.  There have been specs floating around for years, but
> it's never been published on the TR page (despite, I believe, a
> minuted group resolution to do so at one point).
> 
> I think the newest draft is
> http://xulplanet.com/ndeakin/xul/specs/flexbox.html

How does this 'flexible box model' resolve undefined behavior in CSS2.1? 
I see this line.

#If overflow is hidden, the element will be clipped instead.

This leads back to the issues concerning block formatting context in 
this thread.

http://lists.w3.org/Archives/Public/www-style/2008May/0224.html

Alan

Re: Publishing the flexible box model

On Wednesday 2008-06-04 16:57 +1000, Alan Gresley wrote:
>
> L. David Baron wrote:
>> I'd like to move forward with publishing the flexible box model as a
>> working draft.  There have been specs floating around for years, but
>> it's never been published on the TR page (despite, I believe, a
>> minuted group resolution to do so at one point).
>>
>> I think the newest draft is
>> http://xulplanet.com/ndeakin/xul/specs/flexbox.html
>
>
> How does this 'flexible box model' resolve undefined behavior in CSS2.1?  
> I see this line.
>
>
> #If overflow is hidden, the element will be clipped instead.

I don't think it's intended to have any effect on undefined behavior
in CSS 2.1.  The wording may need to be clarified in some cases if
it can be interpreted as having one.

> This leads back to the issues concerning block formatting context in  
> this thread.
>
>
> http://lists.w3.org/Archives/Public/www-style/2008May/0224.html

This issue doesn't seem related.

Re: Publishing the flexible box model

On Wed, 04 Jun 2008 06:48:25 +0200, L. David Baron <dbaron <at> dbaron.org>  
wrote:
> I'd like to move forward with publishing the flexible box model as a
> working draft.  There have been specs floating around for years, but
> it's never been published on the TR page (despite, I believe, a
> minuted group resolution to do so at one point).
>
> I think the newest draft is
> http://xulplanet.com/ndeakin/xul/specs/flexbox.html .  (There's also
> an older draft at
> http://www.damowmow.com/temp/csswg/old/ui/flexbox.html .)

The older draft references various images for example renderings of the  
examples which seem to return 404 nowadays. It would be nice if these were  
somehow incorperated so you get a visual idea of what it does.

> I propose we use the shortname css-flexbox; I'm willing to import it
> into dev.w3.org space and prepare it for publication if needed.

Moving forward with flexbox would be great!

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: [css3-mediaqueries] Width/Height Clarifications

On Thu, 24 Apr 2008 22:59:14 +0200, fantasai  
<fantasai.lists <at> inkedblade.net> wrote:
> In the definitions of 'width' and 'height', the spec says:
>
>    # For continuous media, this is the width of the viewport
>    # (as described by CSS2, section 9.1.1 [CSS21]). For paged
>    # media, this is the width of the page box (as described
>    # by CSS2, section 13.2 [CSS21]).
>
> Opera's 'projection' mode is in some sense both paged and
> continuous. In this case you would want to use the viewport
> size, not the page box size (which depends on the content).
> In print media also the page box size can change: all even
> pages can be one size, all odd pages another, for instance.
> So Media Queries should not be referring to the page box.
> I'd suggest the terms "paper size" or "page size". (The
> interaction of media queries and the 'size' property is a
> horrible mess, but I'm hoping we can deal with that in the
> Paged Media spec.)
>
> The definitions say that 'height' "describes the height of
> the rendering surface of the output device". This would be
> a more appropriate description for 'device-height', which
> is currently described as  "the height of the output device".
> The viewport of a browser window can be smaller or larger
> than the height of the screen (which is "the rendering
> surface of the output device"). And the 'device-height'
> query isn't intended to refer to the height of the physical
> monitor box, but rather to the height of the screen.

Re: [css3-mediaqueries] Width/Height Clarifications

On Jun 4, 2008, at 3:21 AM, Anne van Kesteren wrote:

>
> On Thu, 24 Apr 2008 22:59:14 +0200, fantasai <fantasai.lists <at> inkedblade.net 
> > wrote:
>> In the definitions of 'width' and 'height', the spec says:
>>
>>   # For continuous media, this is the width of the viewport
>>   # (as described by CSS2, section 9.1.1 [CSS21]). For paged
>>   # media, this is the width of the page box (as described
>>   # by CSS2, section 13.2 [CSS21]).
>>
>> Opera's 'projection' mode is in some sense both paged and
>> continuous. In this case you would want to use the viewport
>> size, not the page box size (which depends on the content).

Does it really? I thought that the reason "The size of a page box  
cannot be specified in CSS 2.1" is because it really ends up being the  
sheet size minus the page margins. The spec says that "[t]he page area  
includes the boxes laid out on that page", but it does not say that  
the page area size equals the total size of the boxes laid out on the  
page. An ocean can "include" fish, but the volume of the ocean is  
bigger than the total volume of the fish in it.

Thus, it seems to me that page box size is really the sheet size minus  
the page margins. So Opera's "projection" mode, if it has a page box  
size, that size would be equal to the screen size minus the page  
margins. If no page margins then it equals the screen size, which is  
also the viewport size because Opera sets the viewport to fill the  

RE: [css3-mediaqueries] Width/Height Clarifications

Brad said:
  >> fantasai said:
 > >> Opera's 'projection' mode is in some sense both paged and
> continuous.
> >> In this case you would want to use the viewport size, not the page
> >> box size (which depends on the content).
>
> Does it really? I thought that the reason "The size of a page
> box cannot be specified in CSS 2.1" is because it really ends
> up being the sheet size minus the page margins. The spec says
> that "[t]he page area includes the boxes laid out on that
> page", but it does not say that the page area size equals the
> total size of the boxes laid out on the page. An ocean can
> "include" fish, but the volume of the ocean is bigger than
> the total volume of the fish in it.

I agree that the page box size does not depend on the page content.  But the page box and the page area are not the
same thing.  From http://dev.w3.org/csswg/css3-page/#page-box-page-rule,
        * The page box is a specialized CSS box that maps to a rectangular print media surface, such as a
        * page of paper. It is roughly analogous to the viewport.  As with other boxes, a page box consists
        * of margin, border, padding, and content areas.

That is, the page box does indeed contain the page margins.  The page area is synonymous with the content area
of the page box.

>
> Thus, it seems to me that page box size is really the sheet
> size minus the page margins. So Opera's "projection" mode, if
> it has a page box size, that size would be equal to the