W3C home > Mailing lists > Public > www-style@w3.org > November 2011

[CSSWG] Minutes and Resolutions TPAC 2011-10-31 Monday Morning: Values&Units, Positioning, Animations

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 28 Nov 2011 13:39:24 -0800
Message-ID: <4ED3FF8C.3030106@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Values and Units
----------------

   RESOLVED: remove <fraction> and <grid> (ISSUE-193)
             http://www.w3.org/Style/CSS/Tracker/issues/193

Positioned Layout
-----------------

   Arron presented a draft for CSS3 Positioning, which includes CSS2.1
   absolute, fixed, and relative positioning, containing blocks, and
   z-index; and that adds:
     - 'position: center', in which 'auto' offsets compute to center the element
     - 'position: page', in which the current page box is the containing block
   There were concerns raised that the page positioning scheme would result in
   layouts that broke very badly if the document were either rendered onto a
   continuous (scrolling) canvas, or if it were paginated differently than the
   author's original intent (due to differently-sized fonts, differently-sized
   pages, etc.). Thus:
   RESOLVED: Publish CSS3 Positioning as FPWD, without position: page

Animations
----------

   RESOLVED: CSS animations do not start or continue running on elements that
             are display:none or inside display:none elements.

   RESOLVED: Two new co-editors Sylvain and dbaron for Animation module.

   ACTION: Define how properties are interpolated when left out of a subset
           of keyframes.

   RESOLVED: 'all' is allowed within lists in 'transition-property' (but
             'none' is not).  Which item wins works like for shorthands,
             so it's silly to use 'all' other than at the start of the
             list, but it's not forbidden.

   RESOLVED: Fire the animation cancellation event on the disconnected element
             if the element has been removed

   RESOLVED: Will consider animating inset to outset box-shadows iff someone
             posts a proposal of exactly how that's supposed to work.

====== Full minutes below ======

http://www.w3.org/2011/10/31-css-irc#T16-07-49-1
http://krijnhoetmer.nl/irc-logs/css/20111031#l-473

Present:
   Rossen Atanassov (Microsoft)
   Tab Atkins (Google)
   David Baron (Mozilla)
   Bert Bos (W3C)
   Tantek Çelik (Mozilla)
   John Daggett (Mozilla)
   Arron Eicholz (Microsoft)
   Elika Etemad (Mozilla)
   Sylvain Galineau (Microsoft)
   Daniel Glazman (Disruptive Innovations)
   Arno Gourdol (Adobe)
   Vincent Hardy (Adobe)
   Molly Holzschlag (Invited Expert)
   Koji Ishii (Invited Expert)
   John Jansen (Microsoft)
   Brad Kemper (Invited Expert)
   Håkon Wium Lie (Opera)
   Chris Lilley (W3C)
   Peter Linss (Opera)
   Luke McPherson (Google)
   Alex Mogilevsky (Microsoft)
   Florian Rivoal (Opera)
   Alan Stearns (Adobe)
   Shane Stevens (Google)
   Steve Zilles (Adobe)


Scribe: Bert
Values and units
----------------

   <fantasai> http://www.w3.org/Style/CSS/Tracker/products/8

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/193
   fantasai: Issue 193 is about removing <fraction> and <grid>
   fantasai: Not sure they are actually used anywhere.
   fantasai: Apart from unstable modules.
   fantasai: If necessary we can add them back in Level 4
   Florian: Sounds reasonable. No hidden issues?
   Markus: If another spec needs it?
   fantasai: Some modules already define their own units.
   RESOLVED: remove <fraction> and <grid> (ISSUE-193)

   fantasai: ISSUE-195 is next
   fantasai: In CJK
   fantasai: fonts typically have 1em advance.
   fantasai: We have a ch unit.
   fantasai: Compressed CJK fonts do not advance 1em.
   fantasai: Dow we want a new unit for CJK fonts advance?
   Florian: Is font is proportional?
   fantasai: No, for compressed, but still monospaced fonts.
   jdaggett: Don't think we should add it.
   jdaggett: It is not going to help you.
   fantasai: Our feedback was that a line consisting only of ideographic
             characters should be set solid.
   jdaggett: how do you get the value?
   fantasai: Same way as ch unit.
   jdaggett: Did you ceck that fonts actually give that info?
   Koji: [...]
   Koji: Definition in Opentype.
   Koji: "if this table then use that"
   jdaggett: I'm sceptical.
   jdaggett: Would like to see a post on www-style, with use-case
   ACTION koji post use-case on www-style. Then we'll look at actual fonts.
   <trackbot> Created ACTION-386

Positioned layout module
------------------------

   <arronei> http://dev.w3.org/csswg/css3-positioning/
   arronei: [shows module on screen]
   arronei: Updated with feedback from last ftf
   <arronei> http://wiki.csswg.org/spec/css3-position
   arronei: See also the issues list
   arronei: Still need to discuss some things with Tab.
   arronei: Today topic is page positioning and centering.
   arronei: Page position is absolute, but looks a bit like fixed.
   arronei: Mainly meant for Regions.
   arronei: A deeply nested regions can still be positioned relative to page.
   arronei: If not in a region, position is relative to initial CB.
   arronei: Possible problems with overlap in that case.
   Howcome: Hard to understand without examples.
   arronei: Regions create new initial containing blocks.
   howcome: Can you put something in a position on page 3, e.g.
   howcome: 'position: page' with offset?
   fantasai: Overlap if you are not on the page you expected to be on.
   arronei: Really focused on regions.
   fantasai: Don't like that fallback behavior.
   howcome: Yes, that is a problem.
   howcome: Page floats don't have that problem.
   howcome: Next float autom. goes beneath previous one.
   fantasai: page positioning seems to break too easily, and very badly.
   [dicsussion about cases]
   fantasai: At least with floats everything remains readable, visible.
   arronei: I hear some concerns. What is general feel?
   Peter: Some cases you may not care so much, e.g., create a watermark.
   arronei: Shall we pull it out then, for now?
   Steve: For named pages, can you use the name?
   fantasai: abs. pos is not the greatest thing with pagination.
   fantasai: This solution is broken enough to need redesign.
   arronei: Do you already have a better solution?
   fantasai: Not really.
   arronei: We need something eventually.
   Steve: We'll need some way to make a seq. of pages with each their own
          structure.
   Steve: As we said already with howcomes' demo yesterday.
   Tab: Something like float's ability to reposition itself.
   fantasai: important is that it doesn't break horribly if things aren't
             exactly as expected.
   (various): Changes to the page size, margins, or font size can cause
              things that were positioned on different pages to be positioned
              on the same page, so that they overlap.
   arronei: If you adjust the margins on a page, you may easily get two elements
            on the same page where you didn't have them before.
   fantasai: This will break if you either paginate differently or display in
             scrolled media
   Alex: Anything available that would work?
   howcome: page floats!
   alex: Still need to get something in top right if you want it in top right.
   Rossen: confusion between clearing and positioning.
   Rossen: Position page is not necessarily the feature at risk. It lacks
           clearing, yes, but if we solve that, we don't have the fallback
           problem anymore.
   Rossen: Do you propose to pull the feature to solve positioning or solve
           clearing?
   Florian: both.
   Alex: Exclusion, positioning and floats all needed, 3rd part not done yet.
   howcome: page floats works, in spec and tested in implementation.
   arronei: find middle ground.
   Tab: floats don't overlap, that is the big difference.
   fantasai: My issue is that something that is designed such that the fallback
             nearly always fails, is not good.
   fantasai: We can leave it in ED, but should not be like this in WD.
   Alex: Want to be able to
   Alex: General solution for floats is complex.
   Alex: We want that, but want exact algos.
   Alex: positioning to page is very important.
   Alex: Needed for pages with exclusions.
   Alex: Some of their logic will have to be in scripts.
   Alex: Very hard to do without positioning to page.
   Alex: [something]
   Alex: This will only work well with multiple positioned items if you have
         script
   Tab: only useful with scripting, you say?
   Alex: Probably.
   fantasai: So that indicates to me the model is broken and you need a better
             one.
   Tab: We should not write something that is broken just because we don't
        have time for the better one yet.
   arronei: We should think about clearing, not decide it right now, but think.
   arronei: Can put it in Editor's Draft.
   Steve: Put in the ED what the issue is, and what arguments are,
   fantasai: and look for other solution for same use cases.
   arronei: I can put that in.
   Brad: What does page float not solve that this does?
   Steve: yes.
   Alex: something that is positioned and does not collide with other things
         is a page float.
   howcome: We should find use cases and solve the problem.
   Brad: So this is complementary to page floats?
   Alex: In the future we need page floats that can be positioned absolutely
         on a page.
   Alex: Don't worry that we will have that some time in the future.
   Alex: We want more, but what we have is good enough for now.
   Howcome: We want the use cases to be solved, but we also need the fallback.
            Cannot rely on scripts to solve the fallback.
   fantasai: Good summary!
   Alex: We have no media selector to distinguish scroll from paged.
   Tab: It's not about paged vs scrolled. Even within paged media, this breaks
        if you change the pagination
   Alex: Let's make floats work.
   arronei: Yes, but we need to move this spec. There aren't many issues left.
   ACTION arronei: detail issues further and come up with use cases and solve
                   them better and pull page positioning out of WD.
   <trackbot> Created ACTION-387
   arronei: Need to handle the cases were there is overlap.

   arronei: About center positioning:
   arronei: Very old request.
   arronei: It is now similar to block-level non-replaced centering with
            auto margins.
   arronei: Margin: auto wouldn't work here.
   arronei: There is a calculation in the spec.
   arronei: Set 'position: center'
   Alex: bottom positioning is a problem.
   fantasai: This allows us to position out of flow objects, but still not
             in-flow objects.
   fantasai: And that is more important.
   Daniel: Agree.
   Tab: Can use flex box, or grid.
   dbaron: Proposal is reasonable for positioning.
   dbaron: Could add something about auto margins, not defined currently.
   Tab: horizontal only, or vertical, too.
   dbaron: Symmetric.
   fantasai: No, it is not symmetric.
   arronei: We'll keep this part in the draft.
   dbaron: you can center vertically with auto margins, in level 2, as long
           as height is fixed.
   fantasai: exactly
   [discussion about case with height: auto]
   arronei: Should work for auto height, so I'll correct that.
   dbaron: For centering in each dimension you need to set four properties
           and set height.
   arronei: Some other issues in the spec:
   arronei: No ruby values.
   arronei: Not sure what a positioned ruby works.
   dbaron: Do the spec need to redefine CSS 2.1 section?
   dbaron: Can't you just say it amends CSS 2.1 for these cases?
   Tab: Do we want to write delta specs?
   Chris: We decided to refer to CSS 2.1 from level 3 modules.
   Tab: Yes, but not the same thing.
   Chris: We decided that level 3 can refer to CSS 2.1 and to other modules.
   Steve: A module is self-consistent. It refers to other specs, of course.
   fantasai: Modules replace CSS 2.1, also to make text more readable.
   fantasai: This spec should not define display types not un CSS 2.1.
   fantasai: Flex Box defines its own display types and their interaction
             with this spec. Likewise Ruby.
   arronei: So I only need to refer to 2.1 display types here. OK.
   dbaron: You need to redefine the term "absolutely positioned" to include
           center and fixed.
   <dbaron> http://www.w3.org/TR/CSS21/visuren.html#absolutely-positioned
   <dbaron> http://www.w3.org/TR/CSS21/visuren.html#position-props (positioned)

   arronei: Next is inset-rect.
   dbaron: Yes, we resolved to add that some ten years ago :-)
   arronei: So I think we're OK with this part.
   arronei: Last issue is stacking context and opacity and transforms.
   arronei: Couldn't find any conclusions about that.
   dbaron: Both opacity and transform on elements without z-index, than act
           as if z-index is 0.
   dbaron: If it is positioned and has a z-index, than use that.
   dbaron: Otherwise do as if z-index is 0.
   arronei: Implementations seem to do that, indeed.
   arronei: How about transforms?
   dbaron: Believe they are the same.
   arronei: I will add that to this section.
   arronei: Can we then move this to WD?
   daniel: I think we should. Objections?
   [no objections]
   <dbaron> see http://lists.w3.org/Archives/Public/www-style/1999Jul/0014.html
           for inset-rect() :-)
   RESOLVED: Publish CSS3 Positioning as FPWD, without position: page

daniel: One remark: you cannot actually search for "issue" in the draft.
daniel: Can that be fixed?
fantasai: I think it is a bug in browsers that they don't find generated text.
daniel: But we need a way to find issues now.

Animations
----------

   [discussion about agenda, break, joint meetings...]
   Daniel: yesterday already some issues.
   Dean: Most editorial issues were addressed already. So we can today talk
         about difficult issues.

   sylvaing: What happens when an animation is cancelled: is there an event?
   dean: You mean, ended before it completed?
   Dean: What would you do at that point?
   Dean: Just a notification?
   Dean: I'd be OK with that.
   sylvaing: Need to put in one place all the things that can happen on
             cancellation.
   Dean: Give me an action to add an event?
   ACTION Dean add an event for animation cancellation
   <trackbot> Created ACTION-406

   Dean: display: none is tricky.
   sylvaing: People expect that properties continue to change, even if you
             don't see anything.
   sylvaing: But you can achieve that with a delay.
   Dean: Computed style of a property exists even when display is none,
         doesn't it?
   dbaron: starting an animation is result of computing a value.
   dbaron: We don't define *when* you compute style.
   dbaron: Just assume it happens at proper time.
   dbaron: Authors depend on display: none content not having a performance
           effect.
   dbaron: But changing this will have such a performance effect.
   Shane: Not so much impact, only looking at selectors that apply.
   sylvaing: Animation delay solves it.
   dbaron: Not so sure about shane's performance assessment. There's also
           memory, and inheritance.
   shane: It doesn't fundamentally change the behavior of 'display: none'
   dbaron: It doesn't change for authors who don't have animations.
   dbaron: But it does change where there are animations.
   shane: Yes, in some cases.
   [discussion about impl. architecture and impact, scribe didn't understand]
   Chris: The author will expect that hidden stuff is still up to date.
   sylvaing: Use delay.
   Tab: Cannot know delay in advance.
   Dean: Calculate time line in advance for part of the tree.
   Dean: In some future version of the spec we can define that animations
         can be aligned.
   Dean: Problem that we cannot do that now.
   Dean: But we can still say things in current spec so that implementations
         don't have to compute for elements with display: none.
   Dean: No events.
   Dean: You could use script and set delays as well.
   Dean: What happens if you animate 'display: none' in a key frame?
   Tab: As soon as we can animate keywords, you mean.
   Dean: Yes, that is not yet in spec, but will add it.
   Dean: I propose display: none means element is not animated.
   Luke: What does it mean?
   Dean: Elements with display: none and animation property, we don't even
         look at animation.
   Luke: So as author I first need to set to block, then add animation,
         so GetComputedStyle(), then set display again.
   Dean: Not sure I understand.
   Dean: Just set display: inline or whatever and animate.
   Dean: The rules for starting an animation should include that animation
         starts as soon as display changes from 'none'.
   Shane: Could get interesting.
   Shane: Change in display may trigger an animation.
   Dean: Is that any worse than applying animation styles? Performance hit?
   sylvain: Problem if middle key frame has 'display: none'
   brad: Say I want to move from left to right in 10 sec, and after 5 secs
         I set display.
   dbaron: So question is if display becomes none in middle of animation
           and then becomes block again, does animation continue? Gecko
           does that.
   Brad: So I can stop animation that way and get my use case?
   [Scribe didn't understand]
   Florian: Spec doesn't really say it has to be that way.
   Tab: Say 'display: none' is set during animation.
   dbaron: We recompute style while the animation is running.
   Tab: It won't restart until the display: none goes away?
   Tab: Mental model is not obvious.
   Florian: Simpler to say display: none doesn't animate?
   sylvaing: We still need to define
   Shane: Should we look at implications for perf. of running in display: none?
   Markus: Also look at battery life.
   dbaron: Animation can stop while display: none is in effect, you still
           need to detect that.
   Luke: No need to do that in real time.
   dbaron: Yes, need to do that at each tick.
   Luke: What if element itself is removed?
   dbaron: We remove the animation as well.
   Tab: It doesn't have any CSS anymore at that point, that is a distinct case.
   dbaron: We explicitly stop animations when an element moves in the DOM.
   dbaron: We have the code to preserve animations during display: none'
           precisely to deal with the DOM issues.
   dbaron: Harder to do if an ancestor has 'display:none' instead of the
           element itself.
   Tab: Model is really confusing, except if you understand browser kernels...
   Tab: Simplest is that animations keep running, even if not displayed.
   [scribe missed some]
   Dean: Take a spinner, and you set 'display: none' to hide it and expect
         it to start from zero when it reappears.
   Tab: [explains an solution]
   Tab: Instead of putting anim. on spinner. set it on spinner.shown.
   Tab: No restarting involved.
   Tab: Just add/remove the class when needed.
   [some discussion not minuted during network outage]
   Molly: When display is none, animation should not apply.
   Molly: That is easy to explain.
   sylvaing: But what if display is set to none in middle of key frame?
   molly: Keep consistent.
   Florian: Set none at 50% just kills the animation, that is consistent.
   <ChrisL2> For clarity, I prefer to modify what Molly suggested - when display
             is none, CSS animation must not apply
   <ChrisL2> (because smil-based animation does apply when display=none)
   Steve: display triggers a relayout, can use visibility hidden instead.
   Steve: So letting display: none turn off anim seems reasonable.
   Markus: Steve's solution is good.
   dbaron: So I hear consensus that display: none breaks animations, stops them.
   RESOLVED: CSS animations do not start or continue running on elements that
             are display:none or inside display:none elements
   RESOLVED: Two new co-editors Sylvain and David for Animation module

[break]
[Joint meeting with WebApps, scribed in #webapps, see their minutes]

ScribeNick: fantasai
   sylvaing: Issue is what if a property is not specified in all keyframes.
   sylvaing: Also what if one keyframe has an invalid value
   dbaron: What happens in gecko when a property is not valid in all keyframes:
           every animations animates all properties that are in any keyframe
           of the animation, over the entire duration of the animation
   dbaron: The animation interpolates each property across the keyframes
           from the keyframes in which the property was present.
   dbaron gives an example
   smfr: Imagine exploding keyframes into keyframes per property. For keyframes
         in which the property isn't specified, you ignore that keyframe.
   sylvaing: So if I had an animation with keyframes at 0%, 50% and 100%, and
             'width' appeared only in 0% and 100%, it just animates between
             those two values and ignores 50% (for 'width')
   dbaron: The fun case there, and one I'm not sure we agree on, is what happens
           if some of the values are values you cannot interpolate between
   dbaron: In Gecko, if there are such values, I drop the property from
           animation completely
   dbaron: So if you animate from width: 100% to width: 50% to width: auto,
           I say you can't animate between 50% and auto, so I'm not going to
           animate 'width' at all
   Luke: If you have, say, an abspos div and it's specified left in the
         initial state and right in the final state, you  can't actually
         do an animation for that thing.
   smfr: It's the same problem as not being able to animate to/from auto

   dbaron: Another issue here from testcase on www-style last week (from Lea?)
   dbaron: In some cases, the computed value of one prop depends on computed
           value of another property
   dbaron: If your animation is multiple properties, what basis values are
           you using?
   dbaron: So in Gecko, I didn't really think about this when implementing,
           so what I implemented is that it ignores other properties in the
           animation
   dbaron: That's probably wrong
   dbaron: If we want this to work right, for some definition of right, things
           can get pretty complicated quickly
   dbaron: So I'm not sure what to do there.
   example was animating stuff in ems and font-size (?)

   Luke: Has anyone considered doing this in computed space instead of
         precomputed?
   Tab, dbaron: Happens over computed values
   Luke: Instead of being ems and whatever, then you'd want these things to
         be final pixel values
   Luke: Instead of ...
   dbaron: You want to animate used values instead of computed values. That's
           hard because it depends on layout. Would rather not go there.
   dbaron: I'd be more interested in solving those problems by making things
           like calc(50% + 2px + auto) work
   dbaron: or calc(auto * 0.5)
   dbaron: Then it's much easier to solve these problems
   smfr: theoretically you could lay out at the final state to find what
         'auto' means
   dbaron: The problem there is that might depend on other things that animate
   smfr: So does Gecko explicitly not do animations that involve 'auto'?
   smfr: In WebKit we have a bug where we treat 'auto' as 0
   smfr: That makes things like left -> right work
   Luke: So if you have these calc() expressions, you can defer layout
   dbaron: Yes, you can do the animation on computed values and then you do
           the layout with the interpreted calc() expression
   dbaron: background-position has a problem, too -- it needs calc()
   Shane: It's pretty much impossible to animate gradients without deferring
          layout
   Shane: For gradients, you can't generate and interpolate a computed state.
          You need to do layout
   dbaron: I think we have a lot of agreement on this. We need to write it up.
   dbaron: a) How the loop over properties works: properties, the keyframes
   dbaron: b) be clear that interpolation happens on computed values (think
              we say that already)
   dbaron: c) Issue on what to do with non-interpolatable pairs in the animation
   fantasai: dropping it entirely seems like a better idea.
   fantasai: More straightforward, and if we later figure out how to
             interpolate it and people add it, it'll either work or not work
             (in older browsers): you won't get this halfway jumpy thing
   smfr: If the property is missing from a 100% keyframe and the animation
         is looping, you could look for the next value in the loop rather
         than going back to the base value
   fantasai: so if you only have a property specified in one keyframe
   smfr: It would go from base value to that value, stay at that value,
         and then come back down to the base value once you stop animating
   ACTION dbaron to write up description of how animations of properties
                 only in some keyframes work
   <trackbot> Created ACTION-389

   sylvaing: next issue is on transition property
   sylvaing: Idea was that you could set a duration for all properties
   sylvaing: and then override that separately
   sylvaing: And we talked about the none case. We said that if you have 'none'
             in the list of properties, that kills everything before it
   dbaron: Right now none and all can't be part of a list
   sylvaing: We agreed to fix that
   dbaron: Missed that thread
   dbaron: Seems like it makes more sense for all than none. Maybe fix it
           for all and not for none?
   Dean: So you can't put none in a list, but all you can
   fantasai: so, can you put all anywhere in the list?
   sylvaing: It will override anything before it
   TabAtkins: So 'all' just happens to be a really big shorthand
   fantasai: Reminds me of a request for blocking inheritance. Could do
             "all: initial" for that
   plinss: Anything else on animations?
   RESOLVED: 'all' is allowed within lists in 'transition-property' (but
             'none' is not).  Which item wins works like for shorthands,
             so it's silly to use 'all' other than at the start of the
             list, but it's not forbidden.

   dean: We had an issue on the animation cancel event -- an event that
         fires when an animation gets cancelled
   dean: The event fires on the element. But what if the element is removed?
   dean: Do you fire on its parent? Or not fire the event?
   dbaron: I'm inclined it should fire on the element or it shouldn't fire
   dbaron: I'm not sure firing an event on something not in the document is
           something to do
   Tab: Not sure it's a problem. Your target phase is weird. You have events
        firing at DOM non-elements all the time
   dbaron: I'd prefer to ask a DOM Events expert; I'm not one
   dean: If we do decide to fire on an element that's no longer in the DOM,
         then it obviously can't bubble up to its parent.
   dean: Typically people want to listen for events on an ancestor
   dean: I'm tempted to say it doesn't fire
   Tab: I'm not certain if I want to object yet.
   Dimitri says something about not getting an event on an event listener
   ...
   AlexRussell: In webkit [...]
   AlexRussell says something about bubbling being useful...
   Tab: Ms2ger says that firing a DOM event on a disconnected element should
        be fine
   RESOLVED: Fire the event on the disconnected element
   plinss: Does anyone want to check with other DOM Event experts on that?
   dbaron: I'll double-check with smaug as well
   <Ms2ger> Please do :)
   ACTION dbaron to check with smaug about firing DOM events on disconnected
                 elements
   <trackbot> Created ACTION-390

   plinss: Anything else?
   sylvaing: One interesting piece of feedback from people internally using
             them to dev applications
   sylvaing: They're trying to animate inset box-shadows to outset box-shadows,
             and it doesn't work
   dean: We could do that..
   smfr: I almost did that at one point, but gave up because it seemed a
         little tricky
   smfr: What do you do with spread, if it's nonzero?
   dean: I still can't work out how you'd do it.
   fantasai: You'd have to bring everything down to zero, then bring it all
             back up on the other side
   dbaron: Could you pretend that instead inset, you use negative numbers?
   fantasai: You could define this, but it wouldn't be simple: have to bring
             the offsets and spread and blur radius down to zero and bring
             them back up. Do you do that simultaneously, one after the other?
   dbaron: If someone comes up with a way to represent all these intermediate
           states
   plinss: You want to make it look like raised above, then you're sinking it
           down
   dbaron: You have to model it with a light source
   TabAtkins: The shadows are not necessarily representable by a single
              light source
   dbaron: Assume the light source is a point at infinite distance, and then
           only modify the distance fo the box to the canvas
   dean: With a special model of physics, we can come up with a model for the
         animation of inset to outset box-shadows. :)
   * ChrisL wonders if relativistic effects have been ignored
   smfr: Any more serious issues?
   <dbaron> assume the light source is 45 degrees from vertical
   Seems we will consider animating inset to outset box-shadows iff someone
     comes up with a proposal of exactly how that's supposed to work.
   plinss: They all have to hit zero at the same time or its going to look
            stupid
   dbaron: I could try writing it up, but not sure it's a high priority
   fantasai: I think you have more important things on your to-do list :)
   szilles: +1 to that
   <ChrisL> so the question is how to simultaneously animate three properties
            through zero and out the other side without a discontinuity?
   <dbaron> I think it's relatively straightforward to break down each shadow
            as something created by an infinite light source and a box elevation.
   RESOLVED: Will consider animating inset to outset box-shadows iff someone
             posts a proposal of exactly how that's supposed to work.
   <dbaron> assume the infinite light source is at 45 degrees for both endpoints

Regexp matching and values of text-combine
------------------------------------------

   <Bert> text-combine-horizontal property
   Florian: We rejected regexp matching in selectors, but you have to do
            similar for text-combine
   Florian is asking for the ability to make pseudo-elements out of something
           that matches a regexp
   jdaggett: yes, it's a contextual role, but it's far more finely scoped
   fantasai: When you're dealing with text-combine, you're doing it as you're
             evaluating the text. It's not part of selector matching.
   Florian: Just a question, not an issue.
   fantasai: from the spec: " If the content contains any element boundaries
             this is treated as text-combine-horizontal: none on the element
             and any descendants."
   <fantasai> It's a theoretical box, as soon as you notice a boundary you
              abort constructing it.
   Tab: OK, clear what is supposed to happen, still have editorial reservations.

<br type=lunch>
Received on Monday, 28 November 2011 21:59:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT