headers
Patrick Garies | 1 Nov 2009 05:42
Picon

Re: [CSSWG] Minutes and Resolutions 2009-10-28

On 10/30/2009 2:13 PM, fantasai wrote:
> - As of 2003 the CSSValue interface is deprecated+obsolete
> <http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html>
> and other specs should not rely on it. In response to
> <http://lists.w3.org/Archives/Public/www-style/2009Oct/0011.html>
> CSSWG will update the DOM-L3-Style spec to include this note inline.

Where is the DOM3 Style spec located? Or is this a reference to CSSOM? 
(If this is a reference to CSSOM, is there a plan to rename the spec 
"DOM3 Style"?)
Permalink | Reply | 1 comment |
headers
Dean Jackson | 1 Nov 2009 21:56
Picon
Favicon

Re: [css3-transitions] When do transition property changes change already-running transitions?


On 31/10/2009, at 6:45 AM, L. David Baron wrote:

> The css3-transitions spec should answer the question of which
> changes to the transition-* properties affect transitions that have
> already started.
>
> It seems highly impractical to start transitions for changes that
> have already completed if the transition properties change such that
> they would still be transition had the transition properties been
> set that way when the change originally occurred.
>
> This suggests that it might be best to ignore all dynamic changes to
> transition-duration and transition-delay (and probably
> transition-timing-function, although that's not as much of an
> issue).
>
> And it seems entirely reasonable, and probably most visually
> desirable, to run transitions to completion on the same animation
> function and timing that they started with.
>
>
> However, authors sometimes want to stop currently running
> transitions.  I think the solution here that imposes the least
> inconsistency is the spec saying that running transitions should
> stop if the 'transition-property' value changes such that the
> property/element pair would no longer transition.  This appears to
> be what WebKit does, and is what I plan to implement in Mozilla.

Right, this is what we do in WebKit. The spec should be more clear
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Jackson | 1 Nov 2009 21:59
Picon
Favicon

Re: [css3-transitions] Missing apostrophes in value definition of 'transition' shorthand


On 30/10/2009, at 2:43 AM, Øyvind Stenhaug wrote:

> A minor issue in <http://www.w3.org/TR/css3-transitions/#the-transition-shorthand-property- 
> >: I believe there should be apostrophes before the greater-than  
> signs and after the less-than signs. I.e.
>
> [<'transition-property'> || <'transition-duration'> || <'transition- 
> timing-function'> || <'transition-delay'> [, [<'transition- 
> property'> || <'transition-duration'> || <'transition-timing- 
> function'> || <'transition-delay'>]]*

Fixed, thanks Øyvind.

Dean
Permalink | Reply | 0 comments |
headers
Dean Jackson | 1 Nov 2009 22:09
Picon
Favicon

Re: [css3-transitions] animation of shadows


On 23/06/2009, at 11:40 AM, L. David Baron wrote:

> http://dev.w3.org/csswg/css3-transitions/#animation-of-property-types-
> currently says:
>  # shadow: interpolated via the color, x, y and blur components
>  # (treating them as color and numbers where appropriate).
>
> However, properties with shadow values take lists of shadows.  I
> presume the intent is to be like gradients and only support
> animation when there are the same number of shadows.  If that is the
> case, I would suggest adding a sentence saying so, and also adding
> text saying that each shadow in one list is animated to the
> corresponding shadow in the other list.

I've noted this.

An alternative would be (as François suggested) to fill the lists with  
default shadows (say zero offsets and blur, transparent black). WebKit  
implemented something like this but it can often look a little weird.

Dean
Permalink | Reply | 0 comments |
headers
Dean Jackson | 1 Nov 2009 22:13
Picon
Favicon

Re: [css3-transitions] transition properties should apply to all elements


On 27/06/2009, at 9:46 AM, L. David Baron wrote:

> The properties defined in
> http://dev.w3.org/csswg/css3-transitions/#transitions- are currently
> all described as applying to "block-level and inline-level
> elements".  I don't see any reason they shouldn't apply to other
> elements (e.g., internal table elements), so I think the spec should
> instead say "all elements".

I've made this update.

> (It might also want to say that they apply to the :before and :after
> pseudo-elements.  I think this would be quite reasonable.)

This too.

Dean
Permalink | Reply | 0 comments |
headers
Dean Jackson | 1 Nov 2009 22:14
Picon
Favicon

Re: [css3-transitions] stroke-width transition type

Hi Erik,

I ended up removing the mention of individual SVG properties and  
instead referencing the SVG specification.

Dean

On 15/05/2009, at 10:46 PM, Erik Dahlström wrote:

> On Fri, 15 May 2009 13:08:00 +0200, Erik Dahlström <ed <at> opera.com>  
> wrote:
>
>> Hello www-style,
>>
>> The CSS3 transitions spec lists some SVG properties in section 5.2  
>> [1]. There are some slight errors in the types, probably because  
>> <length> in the SVG spec includes percentages, while the CSS spec  
>> definition of <length> does not. Also some properties use "float"  
>> instead of "number".
>>
>> Suggested changes to the table:
>>
>>  fill-opacity: number
>>  stroke-dasharray : list of lengths, percentages
>>  stroke-dashoffset: length, percentage
>>  stroke-opacity: number
>>  stroke-width: length, percentage
>>
>> [1] http://dev.w3.org/csswg/css3-transitions/#properties-from-svg-
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brad Kemper | 2 Nov 2009 06:03
Picon

Re: Inconsistent treatment of "em" and "ex" unit when used to specify "font-size"


On Oct 30, 2009, at 7:03 AM, Bert Bos wrote:

> On that last sentence of the quoted text (which is marked as an  
> issue in
> the working draft): The WG currently believes that the text of CSS 2.1
> ("In the cases where it is impossible or impractical to determine the
> x-height, a value of 0.5em should be used.") is still the best and can
> be inserted unchanged at that point in the CSS3 module.

Should a note about this also be added to 'font-size-adjust'? [1]

That part of that module does not actually mention 'ex' units, but if  
I understand it correctly, it would need the same bit of info from the  
font, and would also need to guess at it, if it is "impossible or  
impractical to determine the x-height" by reading it directly from the  
font metrics.

Or maybe the wording of 'font-size-adjust' can be adjusted to describe  
what it is doing in terms of equalizing the 'ex' measurement of all  
the fonts in the font-family list? For instance, maybe "aspect ratio"  
can be defined as "1ex, as measured in ems" (thus, if '0.5' is the  
'aspect ratio' for a given font, then it is actually '1ex', measured  
as '0.5em'). In this case, no other explanation about the undetermined  
x-heights is needed in the fonts module, because that explanation is  
already in the "CSS Values and Units" module.

I also think that would be a bit easier to comprehend than the current  
opening explanation, which speaks of "the relative height of lowercase  
letters", and then later uses a lower case "b" as an example (which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Dahlstrom | 2 Nov 2009 11:01
Picon
Favicon

Re: [css3-transitions] stroke-width transition type

Hi Dean,

Sounds good, I would suggest referencing both SVG 1.1 and 1.2T to get the  
full set of animatable properties, or possibly the SVG Integration spec. I  
see that the references haven't yet been added to the references section.

Minor thing: might be good if the sentence in section 5.2 "Properties from  
SVG" linked to section 4 "Animation of property types" so as not to  
confuse it with the table of animatable properties in section 5.1  
"Properties from CSS".

Cheers
/Erik

On Sun, 01 Nov 2009 22:14:52 +0100, Dean Jackson <dino <at> apple.com> wrote:

> Hi Erik,
>
> I ended up removing the mention of individual SVG properties and instead  
> referencing the SVG specification.
>
> Dean
>
>
> On 15/05/2009, at 10:46 PM, Erik Dahlström wrote:
>
>> On Fri, 15 May 2009 13:08:00 +0200, Erik Dahlström <ed <at> opera.com> wrote:
>>
>>> Hello www-style,
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
fantasai | 2 Nov 2009 18:27

Re: [CSSWG] Minutes and Resolutions 2009-10-28

Patrick Garies wrote:
> On 10/30/2009 2:13 PM, fantasai wrote:
>> - As of 2003 the CSSValue interface is deprecated+obsolete
>> <http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html>
>> and other specs should not rely on it. In response to
>> <http://lists.w3.org/Archives/Public/www-style/2009Oct/0011.html>
>> CSSWG will update the DOM-L3-Style spec to include this note inline.
> 
> Where is the DOM3 Style spec located? Or is this a reference to CSSOM? 
> (If this is a reference to CSSOM, is there a plan to rename the spec 
> "DOM3 Style"?)

Sorry, that should have been L2:
   http://www.w3.org/TR/DOM-Level-2-Style/

~fantasai
Permalink | Reply | 0 comments |
headers
fantasai | 2 Nov 2009 18:35

Re: font features in CSS

John Daggett wrote:
> fantasai wrote:
> 
>>> Yes, the appropriateness is font-specific, but with  <at> font-face we are
>>> soon going to be fairly sure about what font we are getting, much of
>>> the time (and with the font fallback stack we can be sure to specify
>>> as fallback something that is unlikely to trigger an undesired result
>>> for selecting alternate ampersand #27).
>> I think you're much too optimistic about this. Maybe on desktops in
>> the broadband world there will be enough consistency that you can
>> ignore the few percent of anomalies, but in other environments font
>> downloads are just as likely to be either not available for the
>> device/OS or turned off due to limited download speeds or memory.
> 
> I definitely understand the problem with font-specific feature settings
> like stylesets being applied to fallback fonts but I think this argument
> is dubious, I highly doubt any device that's disabling downloadable
> fonts because of size/speed concerns would be one fully supporting all
> the features of OpenType layout *and* contain fallback fonts with
> font-specific features enabled!!  
> 
> Maybe iPhone 4GS-loving penguins in Antartica would be affected perhaps...  ;)

How about people on a MacBook Pro on an overloaded dial-up connection?
Or people on dial-up who have to pay per megabyte? Some countries have
such systems. I might want to turn off font downloads if I'm on such a
system; doesn't mean I don't have a full-fledged OpenType engine with
a set of high-quality fonts installed locally.

~fantasai
(Continue reading)

Permalink | Reply | 0 comments |

Gmane