Re: [Q] The min attribute and time container constraints

Hi,

Thank you very much for your effort.
I could understand behavior of min attribute on time container.

By the way, I have another question about min attribute.
From the definition of fill attribute, there is an explanation about
with min attribute:

  The fill attribute is also used to determine the behavior when the
  active duration is less than the duration specified in the min
  attribute.

I think it is impossible that active duration is less than min
duration because active duration should be greater or equal to min
duration.
I guess this is not the active duration but the preliminary active
duration (PAD).

thanks,

--
TANAKA Kazuhide
kazuhide@access.co.jp


From: "Patrick Schmitz" <cogit@ludicrum.org>
Subject: FW: FW: [Q] The min attribute and time container constraints
Date: Tue, 2 Mar 2004 18:55:15 -0800

> 
> Sjoerd and I have talked about this, and agree with the original post.
> 
> I further agree with Sjoerd's proposal below to add a fill="freeze"
> attribute to the img element so that the behavior matches the description.
> 
> Thierry - can you write up a new proposed erratum to this effect, and
> circulate it for review?
> 
> Thanks - Patrick
> 
> -----Original Message-----
> From: Sjoerd Mullender [mailto:sjoerd@acm.org]
> Sent: Tuesday, March 02, 2004 12:46 AM
> To: cogit@ludicrum.org
> Cc: Philipp Hoschka
> Subject: Re: FW: [Q] The min attribute and time container constraints
> 
> 
> > -----Original Message-----
> > From: Patrick Schmitz [mailto:cogit@ludicrum.org]
> > Sent: Monday, March 01, 2004 9:26 PM
> > To: Sjoerd Mullender
> > Cc: Philipp Hoschka
> > Subject: FW: [Q] The min attribute and time container constraints
> >
> >
> > Hi Sjoerd -
> >
> > I think he's right. Min applies to the active duration, right? We even
> have
> > an example that shows this kind of behavior. See Example 5 under the
> section
> > on min/max within 10.3.1.
> >
> 
> min extends the active duration, but with the provision that the fill
> attribute is used to fill the gap.  It actually fills the gap after the
> *simple* duration, not the active duration:
> 
> "otherwise (repeating/simple duration not greater than min) the element
> is played normally for its repeating duration (or simple duration if the
> element does not repeat) and then is frozen or not shown depending on
> the value of the fill  attribute (see the fourth and fifth examples below)."
> 
> So indeed I would say he's right.
> 
> In order to fix this, maybe we should add a fill="freeze" to the img.
> 
> > Patrick
> >
> > -----Original Message-----
> > From: www-smil-request@w3.org [mailto:www-smil-request@w3.org]On Behalf
> > Of TANAKA Kazuhide
> > Sent: Monday, March 01, 2004 7:00 PM
> > To: www-smil@w3.org
> > Cc: kazuhide@access.co.jp
> > Subject: [Q] The min attribute and time container constraints
> >
> >
> >
> > Hi all,
> >
> > I'm reading SMIL 2.0 spec but I could not understand about the min
> > attribute and time container constraints. Let me ask you a question.
> >
> > There is explanation about the min attribute and time container
> > constraints as follows:
> >
> >   The min attribute has no effect on the time container constraint on
> >   child duration. This constraint still applies even if a child's
> >   active duration does not satisfy a min value constraint. In the
> >   following example, the image is displayed between 0 and 5 seconds.
> >
> >   <par dur="5s">
> >      <img id="img" min="7s" dur="4s" .../>
> >   </par>
> >
> > I could not understand this example. Why is img displayed for 5
> > seconds?  If no another attributes are specifed,
> >
> >   <img id="img" min="7s" dur="4s" />
> >
> > It is displayed between 0 and 4 seconds, then nothing shown till 7
> > seconds because fill behavior should be ragarded as "remove" in this
> > situation as default.
> > So, in the above example, the expected behavior is: img is displayed
> > between 0 and 4 seconds then nothing shown between 4 and 5 seconds.
> >
> > Is that correct?
> >
> > thanks,
> >
> > --
> > TANAKA Kazuhide
> > kazuhide@access.co.jp
> >
> 
> 
> --
> Sjoerd Mullender <sjoerd@acm.org>
> 
>

Received on Friday, 5 March 2004 05:17:57 UTC