RE: Spec anomaly - opacity

Well I agree we do not want to introduce a dependency on CSS3, as that is moving even slower than we are.

However I still believe a value like 0.1E-35 is not a very suitable value for opacity and at odds with what we have in <color>.

Perhaps in the light of your comment it might be better to either have opacity be 0-255 like it is in our rgba expression or alternately we could use <decimal> from XML Schema for both; possibly limiting the precision support required for a conforming processor to 3 decimal places or something.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 09 December 2008 11:05
To: Sean Hayes; Public TTWG List
Subject: Re: Spec anomaly - opacity

See inline.

On 12/9/08 6:41 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> Right. But we refer to [XML Schema Part 2] § 3.2.4.1 for the syntactic space
> of opacity, which is the problem. We should refer to <alphavalue> in CSS3
> Values and Units for the syntax of this value like CSS 3 Color does.

Actually, we refer only to the syntactic representation of float from XML Schema Part 2, which is normatively used by both XSD and RNG, so we are consistent here. Now that I look at this more carefully, I see we defined the semantics of <alpha> directly in the text of 8.3.1:
An <alpha> expression is used to express an opacity value, where 0 means fully transparent and 1 means fully opaque.

We explicitly did not want to refer to CSS3 in a normative manner (since it was not and still is not yet a REC; indeed, it is now a WD rather than a CR).  I think we do not want to introduce this dependency now.

> Incidentally CSS3 Color latest http://www.w3.org/TR/css3-color/#numerical now
> uses <alphavalue> in the rgba() expression too; so we need to track that.
>
> "... can either be an <integer>, or it can be zero or more digits followed by
> a dot (.) followed by one or more digits. Both integers and real numbers may
> be preceded by a "-" or "+" to indicate the sign, and the sign character is
> considered part of the <number> value"
>
> Sean Hayes
> Media Accessibility Strategist
> Accessibility Business Unit
> Microsoft
>
> Office:  +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: Glenn A. Adams [mailto:gadams@xfsi.com]
> Sent: 09 December 2008 04:04
> To: Sean Hayes; Public TTWG List
> Subject: Re: Spec anomaly - opacity
>
>
> We simply refer to the CSS3 Color Module for the value space of opacity and
> its semantics. I think we do not want to vary from this, particularly since
> other specs, such as SVG, also use these values. DFXP also supports
> specifying alpha in RGBA tuples, in which case the value range of [0-255]
> applies. There is a straightforward transformation between alpha (A) and
> opacity (O) that is easily testable, i.e.,
>
> A = FLOOR ( O * 255 )
>
> and
>
> O = FLOAT ( A ) / 255.0
>
> Glenn
>
> On 12/9/08 7:05 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
>
>>
>> I notice that opacity is specified as a float value, implying an inordinate
>> (and completely untestable) set of gradations of alpha; while colour alpha is
>> specified as only 255 steps. This seems completely skewed to me.
>>
>> I would recommend that we align opacity and colour alpha by specifying
>> <alpha>
>> expressions as component-value.
>>
>> Whether we wish also to anticipate 16bit colour is a separate question we
>> probably ought to look at.
>>
>> Sean Hayes
>> Media Accessibility Strategist
>> Accessibility Business Unit
>> Microsoft
>>
>> Office:  +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>
>