Nabble - w3.org - www-style

Re: [css3-transitions] supporting 'transition-delay' on non-animatable properties?

2009-11-28T10:33:52Z

On Sat, Nov 28, 2009 at 12:04 PM, L. David Baron <dbaron@...> wrote:

> Currently
> http://www.w3.org/TR/css3-transitions/#animation-of-property-types-
> has a special case for the animation of 'visibility' to allow
> authors to perform certain special effects, such as hiding elements
> at a certain time after a transition starts.
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=521890#c4 Justin
> Dolske (who was converting the animations in our videocontrols for
> HTML5 video to transitions) suggested that perhaps
> 'transition-delay' could apply to all properties, not only those
> that are animatable.
>
> This would be relatively straightforward for us to implement, and
> would give authors significantly more flexibility in handling
> transitions of non-animatable properties that they want to happen at
> the end of a transition of animatable properties. (And, in
> particular, they could use 'display', which often has better
> performance characteristics when large amounts of content are
> hidden.)
>
> If we did this, though, we may (or may not) want to remove the
> exception for visibility. Removing the exception would require
> adding a transition-delay for visibility using the trick for getting
> reversing transitions, e.g.:
> p { visibility: hidden; }
> p.shown { visibility: visibile; }
> p.shown { transition: visibility 0 1s; } /* not specified for p */
> which would likely make the 'transition' property more complicated
> when combined with other properties.
>
> Do people think this would be useful, and are other implementors
> interested?

I think it would be quite useful, for precisely the reason you give -
it would let us easily time the changeover of non-animatable
properties to match up with the animations of other properties.

Having to manually set delays for the visibility property is
acceptable to me. It gives more flexibility in any case - you can
have the switchover happen at either the beginning or the end as
appropriate.

~TJ

[css3-transitions] rule for animation of 'visibility' is backwards

2009-11-28T10:06:52Z

http://dev.w3.org/csswg/css3-transitions/#animation-of-property-types-
says:
# visibility: interpolated via a discrete step. The interpolation
# happens in real number space between 0 and 1, where 1 is
# "visible" and all other values are "hidden".

Based on
http://dbaron.org/css/test/2009/transitions/transition-visibility it
appears that what WebKit implements is that values between 0 and 1
are treated as 'visibile', which makes more sense to me. (For
example, it means that you can animate 'opacity' and 'visibility' on
the same function and end up with an element that ignores mouse
events only when 'opacity' is '0'.)

(Though see my previous message for other comments on this:
http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html )

-David

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

[css3-transitions] supporting 'transition-delay' on non-animatable properties?

2009-11-28T10:04:04Z

Currently
http://www.w3.org/TR/css3-transitions/#animation-of-property-types-
has a special case for the animation of 'visibility' to allow
authors to perform certain special effects, such as hiding elements
at a certain time after a transition starts.

In https://bugzilla.mozilla.org/show_bug.cgi?id=521890#c4 Justin
Dolske (who was converting the animations in our videocontrols for
HTML5 video to transitions) suggested that perhaps
'transition-delay' could apply to all properties, not only those
that are animatable.

This would be relatively straightforward for us to implement, and
would give authors significantly more flexibility in handling
transitions of non-animatable properties that they want to happen at
the end of a transition of animatable properties. (And, in
particular, they could use 'display', which often has better
performance characteristics when large amounts of content are
hidden.)

If we did this, though, we may (or may not) want to remove the
exception for visibility. Removing the exception would require
adding a transition-delay for visibility using the trick for getting
reversing transitions, e.g.:
p { visibility: hidden; }
p.shown { visibility: visibile; }
p.shown { transition: visibility 0 1s; } /* not specified for p */
which would likely make the 'transition' property more complicated
when combined with other properties.

Do people think this would be useful, and are other implementors
interested?

-David

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

Redesign Styles Hypocritical

2009-11-28T09:05:17Z

I guess I must not have been subscribed to the right mailing list while the
redesign was going on. Apparently the fact that I noticed on
http://lists.w3.org/Archives/Public/site-comments/2009Sep/0005.html didn't
get seen by the right people.

How on earth does the W3 reconcile the new styles' "body: font: 13px..." in
http://www.w3.org/2008/site/css/advanced with best practices as expressed on
http://www.w3.org/QA/Tips/font-size ? How is 13px in the new better than user
default in the old? If not better, then why changed?

Quoting that URL:

'Size: respect the users' preferences, avoid small size for content

* As a base font size for a document, 1em (or 100%) is equivalent to
setting the font size to the user's preference. Use this as a basis for your
font sizes, and avoid setting a smaller base font size
* Avoid sizes in em smaller than 1em for text body, except maybe for
copyright statements or other kinds of "fine print."'

How does this hypocrisy happen? Why does the W3 need to be as rude as most of
the rest of the web? Is it really possible to meet WCAG 2.0 while setting
font sizes in px? Even if technically allowable, does it meet the
accessibility spirit?

Is there some reason for not maximizing readability? Gray (#333) text on
white background, though technically meeting the luminosity threshhold,
really doesn't, since that standard presumes out-of-the-box settings on a
brand new LCD, not one that is correctly set for an environment that is not
as bright as a retail store shelf, or a faded older one whose brightness and
contrast are already maximized to insufficient effect.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV

Team OS/2 ** Reg. Linux User #211409

Felix Miata *** http://fm.no-ip.com/

Re: [CSS WG] minutes 2009-11-25

2009-11-27T13:01:03Z

On Nov 26, 2009, at 6:50 AM, Bert Bos wrote:

> <bradk> gah

FYI, this exclamation of mine was because of my phone dropping the line, and not about anything that was said.

smime.p7s (3K) Download Attachment

Re: [CSS21] Scaling of replaced elements

2009-11-26T17:02:43Z

> Currently, the spec [1] states that, for replaced elements with an
intrinsic ratio, it is an optional requirement that a UA scale the
element.
>
> I'd like to propose that the current spec is further clarified so that
scaling a replaced element is recommended (SHOULD), as opposed to just
optional (MAY).
>
> Leaving scaling as optional could (although unlikely) result in a vendor
implementing behavior that differs from currently consistent
implementations in other browsers - FF, Safari, IE, and Opera all scale
replaced elements (which have an intrinsic ratio) in this way. More so,
authors have become reliant on the behavior found in these existing
implementations, and to allow the possibility of a differing
implementation would no doubt affect interoperability.
>
> *ASIDE*
> Surely, the aforementioned prose should be repeated in
> http://www.w3.org/TR/CSS21/visudet.html#the-height-property
> too?

James,

I second and support your proposal.

Actual content [1]:
"
The width of a replaced element's box is intrinsic and may be scaled by
the user agent if the value of this property is different than 'auto'. "

Proposed change:
"
The width of a replaced element's box is intrinsic and should be scaled by
the user agent if the value of this property is different than 'auto'. "

[1] http://www.w3.org/TR/CSS21/visudet.html#the-width-property

regards, Gérard Talbot

[CSS21] Scaling of replaced elements

2009-11-26T14:49:19Z

Currently, the spec [1] states that, for replaced elements with an
intrinsic ratio, it is an optional requirement that a UA scale the
element.

I'd like to propose that the current spec is further clarified so that
scaling a replaced element is recommended (SHOULD), as opposed to just
optional (MAY).

Leaving scaling as optional could (although unlikely) result in a
vendor implementing behavior that differs from currently consistent
implementations in other browsers - FF, Safari, IE, and Opera all
scale replaced elements (which have an intrinsic ratio) in this way.
More so, authors have become reliant on the behavior found in these
existing implementations, and to allow the possibility of a differing
implementation would no doubt affect interoperability.

*ASIDE*
Surely, the aforementioned prose should be repeated in http://www.w3.org/TR/CSS21/visudet.html#the-height-property
too?

[1] http://www.w3.org/TR/CSS21/visudet.html#the-width-property

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-26T14:35:52Z

On Nov 25, 2009, at 19:51 , Dean Jackson wrote:
>
> Yeah, this is a problem. We've discussed lots of different approaches
> internally at Apple but didn't find anything flawless. I'm sure
> there will be cases when people don't want reversability.

But it's worth noting that if the automatic reverse behavior is not wanted, it's fairly easy to defeat it.

David Singer
Multimedia and Software Standards, Apple Inc.

[CSS WG] minutes 2009-11-25

2009-11-26T06:50:24Z

Present
Dave Singer, Brad Kemper, Elika Etemad, Simon Fraser, Bert
Bos, Sylvain Galineau, Håkon Lie, Cesar Acebal, Steve Zilles,
Tab Atkins
Regrets
Daniel, Chris
Chair
Peter
Scribe
Bert

Contents

1. Agenda
2. css3-backgrounds to CR?
3. 'display: run-in' and replaced elements.
4. Individual properties for text-shadow and box-shadow
5. HTML5 dependencies
6. Proposed W3C spec conventions
7. Selectors status
_________________________________________________________

Agenda

Peter: Anything for the agenda?

css3-backgrounds to CR?

http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0144.html

Peter: Elika sent a message.
Håkon: I'd like border-shadow to be in, or at least moved to
somewhere.
Elika: It was dropped, because it was unclear yet how it worked.
We're still discussing how it should work, but the other parts are
ready for CR. Brad made some drawings.
Håkon: What is the schedule for it?
Elika: It may be even be a module on its own, when we know what it
should do. But not hold up Backgrounds. If it reached CR while
Backgrounds is also still CR, we could even merge them back.
Håkon: I'd like to get it back in eventually, indeed. What were the
controversies?
Elika: Not so much disagreements, just lots of discussions. Too many
things we don't know yet.
Tab: Looking also at filter and such. A simple box shadow for now is
acceptable for me.
Elika: Concern with a simple and a full-fletched one is that the
cascade may be difficult.
Elika: Fear that this will be difficult for authors and difficult in
future.
Tab: Maybe it can become an alias or shorthand.
Elika: That is something to consider, but later.
Håkon: I'd also like to move ahead with just the simple box shadow
already. It is so incredibly useful.
Steve: We had a huge discussion at ftf.
Håkon: Can we put box shadow back in?
Elika: No, I don't want that. Don't want to hold the draft back any
longer. Too many useful features that are ready.
Håkon: Who is looking at the future shadow properties?
Elika: Nobody right now.
Håkon: I think there are box shadow implementations, aren't there?
Elika: Yes, but there are some issues.
Tab: Can I make a quick box shadow draft over the weekend?
Håkon: I would really like this feature as soon as possible. So I
support that.
Tab: I will work with Elika on it.
Brad: Shadow can maybe be represented with filters. Make sure they
work together.
Tab: We can already decide what we want without having to wait for
full filters.
<fantasai> I'm still concerned about the cascading and
forwards-compatibility issues with box-shadow and filters
Peter: So does that remove Håkon's issue with publishing CR?
Håkon: I want to note something in the draft about shadow.
Tab: Can be an informative note.
Sylvain: Move it to a different module?
Peter: Does it matter if it is in the Background module or in a
separate one?
Håkon: No, but it seems to fit in this one.
Elika: So we make a note about a possible new module, or a later
version of this one.
Bert: I have some uncertainty about the use of "mouse" and "event"
in solving [13]issue 1. So far, CSS only used "designating an
element with a pointing device" (for hover) which is more generic.
But I guess we can clarify later if needed.
[13] http://dev.w3.org/csswg/css3-background/issues-lc-2009
Peter: So OK to publish as CR?

Nobody objects

RESOLUTION: request to publish css3-background as CR

'display: run-in' and replaced elements.

http://lists.w3.org/Archives/Public/www-style/2009Nov/0280.html

Elika: Don't see why they should not run in. Nothing in spec
indicates otherwise.
Tab: Yes, agreed. I want it to go inline. Brad had an example.
Peter: Is this just a bug in browsers then?
Tab: IE makes it inline, others make a block. May need
clarification.
Peter: Any opinion on it from Apple? Bug or not?
Håkon: Edge case…
Simon: Seems a bug.
Håkon: "run-in" is traditionally applied to text, but I can see the
effect being useful.
Steve: Using a symbol instead of a font is a use case.
Håkon: Yes, I can live with that.
Peter: So we agree, but do we need a clarification in the spec?
Tab: Given that both Opera and Apple are happy, I'm fine with text
as it is.

Individual properties for text-shadow and box-shadow

Tab: Generally in favor of individual properties.
Simon: Need to have logic to match up values in comma-separated
lists in separate properties.
Tab: Sometimes easier to specify just one sub-property without
repeating the whole.
Håkon: The multiple comma-separated lists seems a pain.
Simon: Already for backgrounds; we can deal with it.
Håkon: Not happy wth background either…
Peter: Maybe a functional notation?
Tab: Yes, comma lists are weird. Would like to work on that some
time. But OK with it for now,
Simon: More generally, do we ever want compound properties with
individual properties for each part? Explosion of properties.
Peter: Seems not a question of storage or performance. Need to deal
with the components anyway.
Elika: If we split a property, than the old property becomes a
shorthand.
Elika: I would like to hear David Baron on this. He sent an
[15]e-mail about it today.
[15] http://lists.w3.org/Archives/Public/www-style/2009Nov/0315.html
Simon: I think we should make a general policy about compound
properties.
<fantasai>
http://lists.w3.org/Archives/Public/www-style/2009Nov/0315.html
<smfr> ok for me
Peter: Consensus seems to be that this is part of a wider policy and
we need more feedback before a decision.
Steve: Maybe we need a naming convention?
Tab: In what way?
Steve: Basically to take the base name of the property and append
something to name the component.
Tab: So we don't have to describe so much, because it is systematic?
Peter: Indeed good to keep the first part of the name the same
between shorthand and individual properties.

HTML5 dependencies

Peter: Daniel noted that HTML5 refers to BECSS, which we don't work
on anymore.
Tab: Hixie [17]mentioned in e-mail the references he was aware of.
[17] http://lists.w3.org/Archives/Public/www-style/2009Nov/0314.html
Peter: Need somebody to check. HTML5 is easy reading :-)

Proposed W3C spec conventions

Peter: Doug Schepers wrote a [18]message proposing specification
conventions.
[18] http://lists.w3.org/Archives/Public/www-archive/2009Nov/0027.html
<fantasai>
http://lists.w3.org/Archives/Public/www-archive/2009Nov/0027.html
<fantasai> my reply:
http://lists.w3.org/Archives/Public/www-archive/2009Nov/0032.html
Peter: He also mentioned some tools.
<fantasai>
http://www.w3.org/People/Schepers/spec-conventions.html
<fantasai> current proposal 6
Brad: Template and script looked pretty cool. Less chance of doing
things wrong.
<oyvind> padding/background/border on inlines doesn't look so good
Peter: We need people to look it over. Give feedback.
<bradk> gah

Selectors status

Peter: PR was approved.
Bert: But we cannot advance to Rec before CSS 2.1 is PR.

Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@... 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France

Non-prefix namespace support

2009-11-26T05:32:40Z

Hi,

Would it be possible to add some sort of prefix independent namespace support to
selectors? This would allow querySelector/querySelectorsAll (which don't support
prefixes) to handle namespaced content.

Perhaps something like:

url("http://www.w3.org/XML/1998/namespace")|tag

or:

namespace("http://www.w3.org/XML/1998/namespace")|tag

or:

ns("http://www.w3.org/XML/1998/namespace")|tag

Background:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/thread.html#msg971

Jonathan

Re: [CSS21] "containing block" disambiguation"

2009-11-25T23:45:04Z

On 11/26/2009 12:39 AM, sam wrote:

Hi.

In section 9.1.2 of CSS2.1 spec, I think it should be explained better that the term "containing block" applies to boxes of inline and block elements. The term is misleading isnt it?

Thanks,

Sam.

Hmm, yes I agree its misleading and ambiguous at best.

hyperlinks from "containing block" scattered through document should link to 10.1 Definition of "containing block" not 9.1.2 Containing blocks.

Cheers.

Re: How percentage heights could have worked (and maybe still could)

2009-11-25T23:35:27Z

L. David Baron wrote:
> After seeing another set of complaints about how percentage heights
> don't do what authors want in CSS, I had an idea about how they
> could have worked better.
>

In fact in most cases when people are asking for better percentage
heights handling they mean flex units - not percents.

If to speak about percents per se then here is another possible way of
their computation.

For the given DOM [sub]tree do:

Phase I. "Initial calculation". Compute all length values as usual to
get dimensions of all elements.

So if some container has 'height:auto' then all children that have
percentage heights will have them treated as height:auto at this phase.

Phase II. "Fixed lengths". Use dimensions computed at phase I as input
values (in your terms) of percentable heights that were replaced by the
'auto' value in Phase II.

(I suspect that Phase I together with Phase II is just a paraphrase of
the algorithm defined in your message)

And if your UA support flex units in one form or another do:

Phase III. "Flexes and final replacement".
At this moment we know min/max widths of all containers and their
children so we can compute values of attributes given in flex units.

--
Andrew Fedoniouk.

http://terrainformatica.com

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-25T19:51:11Z

On 25/11/2009, at 8:51 AM, L. David Baron wrote:

> Dean added a new section on reversing of partially-completed
> transitions: http://dev.w3.org/csswg/css3-transitions/#reversing
> This is intended to solve a problem that shows up in WebKit's
> implementation: for example, if an element has a transition for a
> style that changes on :hover, and the user moves the mouse into the
> element (starting the transition) and then out of the element well
> before the transition repeats, the movement back to the original
> position ends up much slower than the movement away from it, since
> it uses the full transition-duration for just a partial change in
> the movement.
>
> I'd implemented a different approach for fixing this in Mozilla.
> There, I'd actually used distance computation (the code for which is
> required for paced animation in SMIL, although perhaps not for as
> many value types as we want to support transitions on). So I
> computed the ratio of:
> (a) the distance between the current (in-transition) style and the
> new style
> (b) the distance between the endpoint of the current transition and
> the new style
> and if this ratio was less than 1, I simply multiplied the
> transition-duration by this ratio (and, if the transition-delay was
> negative, also multiplied the transition-delay by it). Then I ran
> the original function on the delay.
>
> However, I was already thinking of changing this approach, since I
> wasn't sure I wanted to support distance computation on all value
> types (I think it starts getting harder once calc() is introduced;
> though without calc it's relatively straightforward to come up with
> a distance measure whose ratios are meaningful, even if it doesn't
> have any meaningful units). In other words, I was thinking of
> changing to an approach that (like Dean's) would only handle the A
> to B to A case and just run transitions as specified if they aren't
> exactly reversed.

Out of interest, did the distance computation approach "feel" right?

> One thing I'm concerned about with the text that Dean added to
> http://dev.w3.org/csswg/css3-transitions/#reversing is that it
> introduces the concept of running a transition function in reverse.
> I'm a little uncomfortable with introducing that concept only here,
> but not anywhere else in the spec. It would create discontinuities:
> for example, if an element has an 'ease-in' or 'ease-out'
> transition-timing-function for an effect that happens much like in
> the :hover example above, you'll get an entirely different effect if
> the mouse moves out of the element just before the initial
> transition completes (you'd essentially get whichever of
> ease-in/ease-out wasn't specified) vs. just after the initial
> transition completes (in which case you'd get ease-in or ease-out as
> specified).

Yeah, this is a problem. We've discussed lots of different approaches
internally at Apple but didn't find anything flawless. I'm sure
there will be cases when people don't want reversability.

>
> If we don't do that, the question is what to do instead. I can
> think of a two other possibilities:
>
> (1) shorten the transition-duration (and any negative
> transition-delay) by the ratio of the time elapsed so far in the
> initial transition to the total time of that transition (much
> like what I did above, except using time instead of distance)
>
> (2) jump to the point in the timing function (at the specified
> transition-duration) for the reverse transition that would have
> the element at its current position (and thus ignore
> transition-delay entirely)
>
> Either of these could be combined (or not) with reducing positive
> transition-delays, though my initial inclination would be not to do
> so.
>
> -David
>
> --
> L. David Baron http://dbaron.org/
> Mozilla Corporation http://www.mozilla.com/
>

Re: Individual properties for text-shadow and box-shadow

2009-11-25T09:45:49Z

One other point about adding individual properties for text-shadow
and box-shadow: this would add yet another case (in addition to
multiple background layers and transitions) where is a single list
spread across multiple properties with complex rules for matching
the items across the lists when the length of the property lists
don't match. *That* has been a significant source of implementation
complexity, and I really don't want to have to implement that more
than necessary.

-David

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

Re: Individual properties for text-shadow and box-shadow

2009-11-25T09:06:52Z

On Friday 2009-11-20 17:21 -0500, Dave Methvin wrote:
> We have a discussion thread going in the jQuery Dev group [1] about the CSS3
> text-shadow property and how it might be used in jQuery. Because of the
> proposed syntax for this attribute [2,3] it would be complex to parse in
> Javascript.

For what it's worth, the syntax is a little more than proposed, it's
been in call-for-implementations for almost 11 years, since CSS2
became a REC:
http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#text-shadow-props

There are also two other arguments to consider:

(1) Splitting something into subproperties can limit future
extensibility. It's often done in order to add a bunch of new
features (and thus say that that one direction is how the property
is being extended). I'd be somewhat hesitant to do it without
adding features.

(2) The separation of properties ought to be determined by what the
unit of cascading should be. In other words, if authors would
regularly want one part of the property to come from one source and
another part to come from another source, then separate properties
are desirable, but if the author almost always wants all the parts
to come from a single place, it's *better* as a single property.

And, as has already been mentioned, a number of working group
members are concerned about the dramatic increase in the number of
CSS properties.

I also think text-shadow is relatively straightforward to parse.

-David

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

[CSS21] "containing block" disambiguation"

2009-11-25T08:39:26Z

Hi.

In section 9.1.2 of CSS2.1 spec, I think it should be explained better
that the term "containing block" applies to boxes of inline and block
elements. The term is misleading isnt it?

Thanks,

Sam.

Re: Agenda conf call 25-nov-2009

2009-11-24T20:47:31Z

(replying on the public list)

On Tue, 24 Nov 2009, Linss, Peter wrote:
>
> 4. HTML5 dependencies
>
> HTML5 has a dependency on BECSS which we are not working on. Are there
> others?

I'm happy to take BECSS to LC and CR. I only stopped working on it because
I was waiting for more implementation experience, but whether we do this
at WD or CR is not important to me.

Other dependencies from HTML5 to CSSWG specs are the basic grammar/syntax/
cascade model (currently referencing 2.1), Color, Web Fonts, CSSOM and
CSSOM View, and UI.

HTH,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T19:21:19Z

On Nov 24, 2009, at 5:08 PM, David Singer <singer@...> wrote:

> It sounds like you want asymmetric behavior (transition in, abrupt
> out) whereupon the rule that Dean wrote wouldn't apply.

Well, I was mostly responding to Tab's case, where he started with "If
I'm going to be using an asymmetric timing function...". Except I was
taking duration instead of timing function, but same idea: TJ seemed
to be saying that even if one of the states (:hover) had an explicit
non-initial transition value and the other didn't, then unhovering
would "*always* run in reverse when the state transitions
back to 'normal'", regardless of the computed value of a non-
explicitly set 'transition-duration' on the non-hover rule, or the
amount of time hovering. That's how I understood his emphasized
*always* to mean, and that's what I was debating. If I misunderstood
what I was arguing against (it wouldn't be the first time), then
please correct me.

> It's only in the case where you transition each way and you
> interuupt the forward to go back again, that most people expect it
> to back down in the same amount of time as it has taken so far to
> come up, as it were.

Yes, for symetrical transitions, I would completely agree.

> I think a 'guess of intentions' is needed here. I think the
> duration has to be 'right' (shorter); whether the function has to
> be perfectly reversed I am less clear. And delays confuse me.

I think I would have to see a few examples of different uses to know
what feels more natural. You probably have a better sense of that than
I do right now.

> On Nov 24, 2009, at 16:47 , Brad Kemper wrote:
>
>> On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr."
>> <jackalmage@...> wrote:
>>
>>> If I'm going to be using an asymmetric timing
>>> function for state transitions, though, as an author I'm going to
>>> expect that they *always* run in reverse when the state transitions
>>> back to 'normal'. This includes transition-delays. I'm not
>>> thinking
>>> of the transition from :link to :hover to :link as two independent
>>> changes, I think of them as being a change and then a reversal of
>>> that
>>> change.
>>
>> But you could think of them as two independent changes, and set the
>> transition on each. I think that would be better than the UA trying
>> to guess your intentions. I don't think I would expect it to run in
>> reverse, unless (possibly, and that's the question) it hadn't
>> finished running in forward. If you didn't set the :link version
>> (or the no pseudo-class version), then unhovering would cause an
>> abrupt change back. If that's what you wanted (and sometimes it
>> might be), you'd be done; if not, you'd notice pretty quick and
>> know what to do to fix it.
>>
>> I can imagine, for instance, wanting a tooltip thingy that faded in
>> (with opacity) after a second or two delay when hovering, and then
>> disappearing to opacity:0 abruptly as soon as I moved the cursor
>> away. If it was only half opaque, I would want the change back to
>> be just as abrupt (with no delay or duration) as it would have been
>> if the first transition had played out. I would expect that to
>> happen if I didn't set any transition values on the :link, because
>> the initial transition-duration without me setting it would be 0.
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T18:55:07Z

On Nov 24, 2009, at 6:12 PM, "Tab Atkins Jr." <jackalmage@...>
wrote:

> On Tue, Nov 24, 2009 at 6:47 PM, Brad Kemper <brad.kemper@...>
> wrote:
>> On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr."
>> <jackalmage@...> wrote:
>>
>>> If I'm going to be using an asymmetric timing
>>> function for state transitions, though, as an author I'm going to
>>> expect that they *always* run in reverse when the state transitions
>>> back to 'normal'. This includes transition-delays. I'm not
>>> thinking
>>> of the transition from :link to :hover to :link as two independent
>>> changes, I think of them as being a change and then a reversal of
>>> that
>>> change.
>>
>> But you could think of them as two independent changes, and set the
>> transition on each. I think that would be better than the UA trying
>> to guess
>> your intentions. I don't think I would expect it to run in reverse,
>> unless
>> (possibly, and that's the question) it hadn't finished running in
>> forward.
>> If you didn't set the :link version (or the no pseudo-class
>> version), then
>> unhovering would cause an abrupt change back. If that's what you
>> wanted (and
>> sometimes it might be), you'd be done; if not, you'd notice pretty
>> quick and
>> know what to do to fix it.
>
> Do you mean something like:
>
> a { transition-timing-function: ease-in; }
> a:hover { transition-timing-function: ease-out; }
>

Sure, according to your preference (if you set the timing function
for :hover and wanted something other than the default initial value
for going in reverse). Perhaps you'd prefer it to ease out in both
directions, for instance. Or you could have a different duration
depending on if you were going into the hover or coming out of it. I'd
think you'd want to set that yourself.

>
>> I can imagine, for instance, wanting a tooltip thingy that faded in
>> (with
>> opacity) after a second or two delay when hovering, and then
>> disappearing to
>> opacity:0 abruptly as soon as I moved the cursor away. If it was
>> only half
>> opaque, I would want the change back to be just as abrupt (with no
>> delay or
>> duration) as it would have been if the first transition had played
>> out. I
>> would expect that to happen if I didn't set any transition values
>> on the
>> :link, because the initial transition-duration without me setting
>> it would
>> be 0.
>
> Sure, you want a transition one way, and no transition the other way.
> I don't think that's going to be the common case, though. I think it
> should be handled by explicitly specifying such.

I think the least unexpected thing is to explicitly specify whenever
you want a value other than the initial value.

> By default, though,
> if I specified such a transition on a tooltip, I'd expect it to
> transition in reverse when I stopped hovering.

Well, I haven't been that involved in the transition and animation
discussions before this, so maybe I'm missing something, but I didn't
think CSS worked that way usually. I would expect the initial value to
be present on any state I didn't set a value for (such as the non-
hover in this example) with properties like 'transition-duration' or
'transition-timing-function'.

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T18:12:40Z

On Tue, Nov 24, 2009 at 6:47 PM, Brad Kemper <brad.kemper@...> wrote:

Do you mean something like:

a { transition-timing-function: ease-in; }
a:hover { transition-timing-function: ease-out; }

?

> I can imagine, for instance, wanting a tooltip thingy that faded in (with
> opacity) after a second or two delay when hovering, and then disappearing to
> opacity:0 abruptly as soon as I moved the cursor away. If it was only half
> opaque, I would want the change back to be just as abrupt (with no delay or
> duration) as it would have been if the first transition had played out. I
> would expect that to happen if I didn't set any transition values on the
> :link, because the initial transition-duration without me setting it would
> be 0.

Sure, you want a transition one way, and no transition the other way.
I don't think that's going to be the common case, though. I think it
should be handled by explicitly specifying such. By default, though,
if I specified such a transition on a tooltip, I'd expect it to
transition in reverse when I stopped hovering.

~TJ

Re: [css21] Forced linebreaks and BiDi

2009-11-24T17:53:33Z

On Tue, Nov 24, 2009 at 03:14:43PM -0800, fantasai wrote:

> Here's a question: If a block splits an inline, should that be
> interpreted as a Line Separator or a Paragraph Separator?
>
> <p>Some text here
> <blockquote>Some block item</blockquote>
> More text here</p>

I'll note that this is a misleading question as stated, in that the example is
written in an HTML-like syntax, and HTML has its own handling of missing </p>,
and its own handling of bidi.

pjrm.

Re: [css21] Forced linebreaks and BiDi

2009-11-24T17:19:29Z

See http://lists.w3.org/Archives/Public/public-html/2009Oct/0992.html for a bit more discussion.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T17:08:07Z

It sounds like you want asymmetric behavior (transition in, abrupt out) whereupon the rule that Dean wrote wouldn't apply. It's only in the case where you transition each way and you interuupt the forward to go back again, that most people expect it to back down in the same amount of time as it has taken so far to come up, as it were.

I think a 'guess of intentions' is needed here. I think the duration has to be 'right' (shorter); whether the function has to be perfectly reversed I am less clear. And delays confuse me.

On Nov 24, 2009, at 16:47 , Brad Kemper wrote:

> On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr." <jackalmage@...> wrote:
>
>> If I'm going to be using an asymmetric timing
>> function for state transitions, though, as an author I'm going to
>> expect that they *always* run in reverse when the state transitions
>> back to 'normal'. This includes transition-delays. I'm not thinking
>> of the transition from :link to :hover to :link as two independent
>> changes, I think of them as being a change and then a reversal of that
>> change.
>
> But you could think of them as two independent changes, and set the transition on each. I think that would be better than the UA trying to guess your intentions. I don't think I would expect it to run in reverse, unless (possibly, and that's the question) it hadn't finished running in forward. If you didn't set the :link version (or the no pseudo-class version), then unhovering would cause an abrupt change back. If that's what you wanted (and sometimes it might be), you'd be done; if not, you'd notice pretty quick and know what to do to fix it.
>
> I can imagine, for instance, wanting a tooltip thingy that faded in (with opacity) after a second or two delay when hovering, and then disappearing to opacity:0 abruptly as soon as I moved the cursor away. If it was only half opaque, I would want the change back to be just as abrupt (with no delay or duration) as it would have been if the first transition had played out. I would expect that to happen if I didn't set any transition values on the :link, because the initial transition-duration without me setting it would be 0.

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T16:47:29Z

On Nov 24, 2009, at 2:28 PM, "Tab Atkins Jr." <jackalmage@...>
wrote:

> If I'm going to be using an asymmetric timing
> function for state transitions, though, as an author I'm going to
> expect that they *always* run in reverse when the state transitions
> back to 'normal'. This includes transition-delays. I'm not thinking
> of the transition from :link to :hover to :link as two independent
> changes, I think of them as being a change and then a reversal of that
> change.

But you could think of them as two independent changes, and set the
transition on each. I think that would be better than the UA trying to
guess your intentions. I don't think I would expect it to run in
reverse, unless (possibly, and that's the question) it hadn't finished
running in forward. If you didn't set the :link version (or the no
pseudo-class version), then unhovering would cause an abrupt change
back. If that's what you wanted (and sometimes it might be), you'd be
done; if not, you'd notice pretty quick and know what to do to fix it.

I can imagine, for instance, wanting a tooltip thingy that faded in
(with opacity) after a second or two delay when hovering, and then
disappearing to opacity:0 abruptly as soon as I moved the cursor away.
If it was only half opaque, I would want the change back to be just as
abrupt (with no delay or duration) as it would have been if the first
transition had played out. I would expect that to happen if I didn't
set any transition values on the :link, because the initial transition-
duration without me setting it would be 0.

Re: [css21] Forced linebreaks and BiDi

2009-11-24T15:14:43Z

Øyvind Stenhaug wrote:

> CSS 2.1 (<http://www.w3.org/TR/CSS21/visuren.html#direction>) says:
>
> # User agents that support bidirectional text must apply the Unicode
> # bidirectional algorithm to every sequence of inline boxes
> uninterrupted by a
> # forced line break or block boundary. This sequence forms the
> "paragraph" unit
> # in the bidirectional algorithm.
>
> By my reading this implies that two text segments separated by a line
> feed would each have the bidi algorithm applied to them separately. From
> what I can tell only currently WebKit does so, the others I tested
> (Gecko, Presto, Trident) all seem to keep them as one paragraph.
>
> The spec also says HTML4 "defines bidirectionality behavior for HTML
> elements", and <http://www.w3.org/TR/html4/struct/text.html#edef-BR>
> explicitly states that <BR> "should behave the same way the [ISO10646]
> LINE SEPARATOR character behaves in the bidirectional algorithm"[1]. It
> seems inconsistent to choose another approach for other types of
> linebreak, especially given the expected UA styling of <br> (as given by
> both CSS2.1 and HTML5).
>
> Demo:
>
> <!doctype html>
> <div style="white-space:pre">1ع
> 1ع</div>

Filed CSS2.1 Issue 145: wrt BIDI treat forced line breaks as LS not CR/LF
http://wiki.csswg.org/spec/css2.1#issue-145

Here's a question: If a block splits an inline, should that be
interpreted as a Line Separator or a Paragraph Separator?

<p>Some text here
<blockquote>Some block item</blockquote>
More text here</p>

~fantasai

Re: [CSS21] Outline versus border edge

2009-11-24T15:02:59Z

Gérard Talbot wrote:

>
> If the "may be" remains in CSS 2.1, then CSS 3 outline-offset property
> definition should change
>
> initial: 0
>
> to
>
> initial: user agent dependent
>
> Either way, whatever is decided, some verse should be updated to reflect
> this.

The UA-dependence allowed in 2.1 can be described as a different
UA style sheet in CSS3, rather than as a different initial value.
So I don't think either spec needs to change.

~fantasai

Re: [css3-transitions] faster reversing of partially completed transitions

2009-11-24T14:28:53Z

On Tue, Nov 24, 2009 at 3:51 PM, L. David Baron <dbaron@...> wrote:

That's a problem. If I'm going to be using an asymmetric timing
function for state transitions, though, as an author I'm going to
expect that they *always* run in reverse when the state transitions
back to 'normal'. This includes transition-delays. I'm not thinking
of the transition from :link to :hover to :link as two independent
changes, I think of them as being a change and then a reversal of that
change.

Is there some way to codify that concept? If so, we'll simultaneously
address author expectations and have a tool to properly resolve this
issue (just treat transitions from A->B->A as 'reversing' a state
change).

~TJ

[CSS21] Outline versus border edge

2009-11-24T14:25:01Z

Hello all,

The latest CSS 2.1 spec says

"
The outline may be drawn starting just outside the border edge.
"
http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines

One of the previous CSS 2 version was saying

"
The outline is drawn starting just outside the border edge.
"

Why the "is" was changed to "may be" ?

My opinion is that the previous "is" should be reinstated, restaured in
CSS 2.1, section 18.

CSS3 Basic User Interface Module, 8.5 'outline-offset' property says

"
By default, the outline is drawn starting just outside the border edge.
"
http://www.w3.org/TR/css3-ui/#outline-offset

If the "may be" remains in CSS 2.1, then CSS 3 outline-offset property
definition should change

initial: 0

to

initial: user agent dependent

Either way, whatever is decided, some verse should be updated to reflect
this.

regards, Gérard

[css3-transitions] faster reversing of partially completed transitions

2009-11-24T13:51:57Z

Dean added a new section on reversing of partially-completed
transitions: http://dev.w3.org/csswg/css3-transitions/#reversing
This is intended to solve a problem that shows up in WebKit's
implementation: for example, if an element has a transition for a
style that changes on :hover, and the user moves the mouse into the
element (starting the transition) and then out of the element well
before the transition repeats, the movement back to the original
position ends up much slower than the movement away from it, since
it uses the full transition-duration for just a partial change in
the movement.

I'd implemented a different approach for fixing this in Mozilla.
There, I'd actually used distance computation (the code for which is
required for paced animation in SMIL, although perhaps not for as
many value types as we want to support transitions on). So I
computed the ratio of:
(a) the distance between the current (in-transition) style and the
new style
(b) the distance between the endpoint of the current transition and
the new style
and if this ratio was less than 1, I simply multiplied the
transition-duration by this ratio (and, if the transition-delay was
negative, also multiplied the transition-delay by it). Then I ran
the original function on the delay.

However, I was already thinking of changing this approach, since I
wasn't sure I wanted to support distance computation on all value
types (I think it starts getting harder once calc() is introduced;
though without calc it's relatively straightforward to come up with
a distance measure whose ratios are meaningful, even if it doesn't
have any meaningful units). In other words, I was thinking of
changing to an approach that (like Dean's) would only handle the A
to B to A case and just run transitions as specified if they aren't
exactly reversed.

One thing I'm concerned about with the text that Dean added to
http://dev.w3.org/csswg/css3-transitions/#reversing is that it
introduces the concept of running a transition function in reverse.
I'm a little uncomfortable with introducing that concept only here,
but not anywhere else in the spec. It would create discontinuities:
for example, if an element has an 'ease-in' or 'ease-out'
transition-timing-function for an effect that happens much like in
the :hover example above, you'll get an entirely different effect if
the mouse moves out of the element just before the initial
transition completes (you'd essentially get whichever of
ease-in/ease-out wasn't specified) vs. just after the initial
transition completes (in which case you'd get ease-in or ease-out as
specified).

If we don't do that, the question is what to do instead. I can
think of a two other possibilities:

(1) shorten the transition-duration (and any negative
transition-delay) by the ratio of the time elapsed so far in the
initial transition to the total time of that transition (much
like what I did above, except using time instead of distance)

(2) jump to the point in the timing function (at the specified
transition-duration) for the reverse transition that would have
the element at its current position (and thus ignore
transition-delay entirely)

Either of these could be combined (or not) with reducing positive
transition-delays, though my initial inclination would be not to do
so.

-David

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

Re: [css3-transitions] edits to transitions spec

2009-11-24T13:29:23Z

On Tuesday 2009-11-24 08:18 -0600, Tab Atkins Jr. wrote:

> On Tue, Nov 24, 2009 at 7:57 AM, Giovanni Campagna
> <scampa.giovanni@...> wrote:
> > Section 3, it says: "Implementations must not start a transition when
> > the computed value of a property changes as a result of declarative
> > (as opposed to scripted) animation. "
> > I read this as "changing the :hover state of an element must not start
> > a transition", which is obviously against the purpose of declarative
> > transitions (as opposed to script-controlled animations)
>
> Note the word "animation" at the end of that sentence. Changing the
> :hover state is not a declarative animation, and so doesn't fall under
> the scope of that sentence.

I changed:
declarative (as opposed to scripted) animation.
into:
declarative animation (as opposed to scripted animation).
to avoid this confusion.

-David

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

[css21] Forced linebreaks and BiDi

2009-11-24T10:18:02Z

CSS 2.1 (<http://www.w3.org/TR/CSS21/visuren.html#direction>) says:

# User agents that support bidirectional text must apply the Unicode
# bidirectional algorithm to every sequence of inline boxes uninterrupted
by a
# forced line break or block boundary. This sequence forms the "paragraph"
unit
# in the bidirectional algorithm.

By my reading this implies that two text segments separated by a line feed
would each have the bidi algorithm applied to them separately. From what I
can tell only currently WebKit does so, the others I tested (Gecko,
Presto, Trident) all seem to keep them as one paragraph.

The spec also says HTML4 "defines bidirectionality behavior for HTML
elements", and <http://www.w3.org/TR/html4/struct/text.html#edef-BR>
explicitly states that <BR> "should behave the same way the [ISO10646]
LINE SEPARATOR character behaves in the bidirectional algorithm"[1]. It
seems inconsistent to choose another approach for other types of
linebreak, especially given the expected UA styling of <br> (as given by
both CSS2.1 and HTML5).

Demo:

<!doctype html>
<div style="white-space:pre">1ع
1ع</div>

[1] HTML 5 currently does not:
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=8363>
--
Øyvind Stenhaug
Core Norway, Opera Software ASA

Re: [css3-transitions] edits to transitions spec

2009-11-24T08:49:24Z

2009/11/24 Tab Atkins Jr. <jackalmage@...>:

> On Tue, Nov 24, 2009 at 7:57 AM, Giovanni Campagna
> <scampa.giovanni@...> wrote:
>> Section 3, it says: "Implementations must not start a transition when
>> the computed value of a property changes as a result of declarative
>> (as opposed to scripted) animation. "
>> I read this as "changing the :hover state of an element must not start
>> a transition", which is obviously against the purpose of declarative
>> transitions (as opposed to script-controlled animations)
>
> Note the word "animation" at the end of that sentence. Changing the
> :hover state is not a declarative animation, and so doesn't fall under
> the scope of that sentence.

You're right, sorry for the noise

> ~TJ
>

Giovanni

Re: [css3-transitions] edits to transitions spec

2009-11-24T06:18:28Z

On Tue, Nov 24, 2009 at 7:57 AM, Giovanni Campagna
<scampa.giovanni@...> wrote:
> Section 3, it says: "Implementations must not start a transition when
> the computed value of a property changes as a result of declarative
> (as opposed to scripted) animation. "
> I read this as "changing the :hover state of an element must not start
> a transition", which is obviously against the purpose of declarative
> transitions (as opposed to script-controlled animations)

Note the word "animation" at the end of that sentence. Changing the
:hover state is not a declarative animation, and so doesn't fall under
the scope of that sentence.

~TJ

Re: [css3-transitions] edits to transitions spec

2009-11-24T05:57:36Z

Section 3, it says: "Implementations must not start a transition when
the computed value of a property changes as a result of declarative
(as opposed to scripted) animation. "
I read this as "changing the :hover state of an element must not start
a transition", which is obviously against the purpose of declarative
transitions (as opposed to script-controlled animations)

I think it would be better to only consider specified values instead
of computed values, but there may be cases I'm not considering.

Giovanni

2009/11/23 L. David Baron <dbaron@...>:

> I made some additional edits to
> http://dev.w3.org/csswg/css3-transitions/ to address a number of
> issues (most of which I orginally raised) and call out a few others
> as issues within the spec.
>
> The changes I made are described in my changelog entry at:
> http://dev.w3.org/csswg/css3-transitions/ChangeLog
> (and were actually split across a number of CVS commits).
>
> The full changes are available in a text diff at:
> http://dev.w3.org/cvsweb/csswg/css3-transitions/Overview.src.html.diff?r1=1.5&r2=1.10
> or an HTML diff at:
> http://dev.w3.org/cvsweb/csswg/css3-transitions/Overview.src.html.diff?r1=1.5&r2=1.10&f=h
>
> -David
>
> --
> L. David Baron http://dbaron.org/
> Mozilla Corporation http://www.mozilla.com/
>
>

RE: [cssom] unrecognized rules and properties

2009-11-24T00:43:24Z

Anne van Kesteren wrote:
> On Sun, 22 Nov 2009 13:14:58 -0200, Mike Wilson wrote:
> > What case has been made for removing this support? IMO
> > there are strong arguments for having it.
>
> This was decided long ago based on that implementations did
> not have to keep the rules around.

@implementors
Would you please speak up and tell what specific problems you
were having with retaining this data?

> If we want to change this I'm not sure a grammar-based
> approach for the defining the CSS parser is appropriate
> anymore since we'd need to define exactly which strings end
> up in the DOM for any kind of input.

I've been assuming that any unrecognized entity still need to
conform to the basic CSS syntax, so that unrecognized
statements don't throw the parser off-route.
To me the intent with CSSUnknownRule seems to be mainly to
support rules formated according to normal syntax, but with
an unrecognized identifier after the @-sign. This seems
trivial to include in the parser, but you mention that the
grammar-based approach may have a problem with that.

One may choose to apply grammars at different levels of
detail, so I'm not entirely sure what is the specific problem.
Have there been changes in these areas since the last CSSOM
spec? (sorry if this is obvious, haven't been following)

When it comes to unrecognized properties, I don't see any
parsing problems really. Of course, the CSSOM cannot do any
processing of property values as the type is unknown, and
should return them literally, but apart from that I see no
big impact. Or am I missing something?

Finally, I'd like to mention a few reasons why unrecognized
CSS should be retained:

1) It is the nature of the web to be permissive and let
unrecognized data be dealt with downstream.

2) The DOM retains unrecognized elements and attributes (I
don't think anybody is suggesting to throw them out?),
which for the sake of discussion map well to CSS rules
and properties, respectively.

3) CSS not recognized by a certain browser may very well be
inspected by a client-side library emulating the
feature instead. This very mail thread sprung from a
discussion about being able to implement CSS transitions
for older browsers, by examining the CSSOM and running
client code for browsers without transition support.
IMO weighing in the ability to use client-side libraries
for compatibility support is a major point for CSS
forwards compatibility, and is something that should be
taken into account for any new standard.

4) IE does it.

--
Mike