Hello Vincent,
> So you wanna join the game? ;-)
Well, sometimes it's hard to resist :-)
>> Normally you would assume that if you define a position wrt a
>> certain area (i.c. the page viewport), percentages are also
>> interpreted wrt to width and height of that same area.
> The added remark t
Hi Paul,
So you wanna join the game? ;-)
Paul Vinkenoog a écrit :
> The (1.1) spec says that if the positioning is...
>
> - absolute:
> the positions are taken with respect to the nearest ancestor
> reference area;
>
> - fixed:
> the positions are taken with respect to the page viewport
On Mar 27, 2007, at 10:32, Vincent Hennebert wrote:
That's why I suspect that for "fixed" the ref-area to be considered
should be the region-area (for paged media), unlike for "absolute"
where
this should be the nearest ancestor ref-area. There won't be any
difference in most cases except
I wrote:
> So I hope I'm not just adding to the confusion here... :-)
...but I probably did, because I was replying with the entire thread
in mind, and the quoted text which I used as a "handle" certainly
wasn't the most appropriate for what I wanted to say -- it just
happened to be the last mess
Hi guys,
>> Diving into the viewport/reference-area relation some more, I think
>> what I could as well have said from the beginning was: If the
>> nearest ancestor reference area is the region-reference-area, then
>> the position of a fixed-positioned area in the viewport is
>> initially identica
Hi Andreas,
Andreas L Delmelle a écrit :
> On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote:
>
>>> If I understand you correctly, what you're saying is that if the fixed
>>> positioned block's nearest ref-area is not initially visible, then the
>>> top/left/etc. properties should be taken WRT t
On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote:
If I understand you correctly, what you're saying is that if the
fixed
positioned block's nearest ref-area is not initially visible, then
the
top/left/etc. properties should be taken WRT the region-viewport-
area?
Almost... What I'm sayin
>- Oorspronkelijk bericht -
>Van: Vincent Hennebert [mailto:[EMAIL PROTECTED]
Hi Vincent,
>> OK, take the region-body as an example, with overflowing content and a
>> fixed-positioned block-container that is a descendant of a block that
>> initially falls outside the region-viewport, and
Hi Andreas,
Andreas L Delmelle a écrit :
> On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
>
>> Thanks for your perseverance ;-)
>
> You're welcome. :o)
I'm sure we will manage!
>>>
>>> If the nearest ancestor ref-area is not immediately visible, then I
>>> think this implies that the fi
On Mar 21, 2007, at 22:06, Jeremias Maerki wrote:
[Me: ]
Seems my proposed fix (bugzilla 41894) goes in the right direction.
I agree.
Only it does not take reference-orientation and/or writing-mode into
account when mapping width/height to ipd/bpd... but that seems to me
currently a part
On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
Thanks for your perseverance ;-)
You're welcome. :o)
If the nearest ancestor ref-area is not immediately visible, then I
think this implies that the fixed-area's position is definitely not
relative to the viewport you refer to, but to anot
Hi Andreas,
Thanks for your perseverance ;-)
Andreas L Delmelle a écrit :
> On Mar 22, 2007, at 10:05, Vincent Hennebert wrote:
>
> Hi Vincent,
>
>>
>> Well, that's still unclear. The area should be placed like in the
>> "absolute" model, plus mustn't move WRT the viewport.
>> In case of a con
On Mar 22, 2007, at 10:05, Vincent Hennebert wrote:
Hi Vincent,
Well, that's still unclear. The area should be placed like in the
"absolute" model, plus mustn't move WRT the viewport.
In case of a continuous media, what should happen if the
nearest ancestor ref-area doesn't appear yet in the v
Jeremias Maerki a écrit :
> On 21.03.2007 21:22:04 Andreas L Delmelle wrote:
>> On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
>>
Whatever follows in that second definition is irrelevant wrt
determining the base for percentage values to compute the initial
offset (or I
On 21.03.2007 21:22:04 Andreas L Delmelle wrote:
> On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
>
> >>
> >> Whatever follows in that second definition is irrelevant wrt
> >> determining the base for percentage values to compute the initial
> >> offset (or IOW: determining which is the
On 20.03.2007 22:54:30 Andreas L Delmelle wrote:
> On Mar 20, 2007, at 21:55, Andreas L Delmelle wrote:
>
> > On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
> >
> >>
> >> Have you actually checked the code to see the difference in
> >> handling between absolute-position="absolute" and absolu
On 20.03.2007 17:18:36 a_l.delmelle wrote:
> >- Oorspronkelijk bericht -
> >Van: Chris Bowditch [mailto:[EMAIL PROTECTED]
> >
>
> >AFAICT, I don't think you've got everything nailed down here. As Vincent
> >already mentioned the ancestor reference area could change depending on
> >the v
On 20.03.2007 11:56:10 a_l.delmelle wrote:
> >- Oorspronkelijk bericht -
> >Van: Vincent Hennebert [mailto:[EMAIL PROTECTED]
>
> >Manuel Mall a écrit :
> >>
> >> My understanding of the spec is that for "top" and "bottom" percentages
> >> only make sense if the containing block has a fi
On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
Whatever follows in that second definition is irrelevant wrt
determining the base for percentage values to compute the initial
offset (or IOW: determining which is the nearest ancestor
reference area)
Indeed, you're right. In fact we d
Hi Andreas,
[EMAIL PROTECTED] a écrit :
>> - Oorspronkelijk bericht -
>> Van: Chris Bowditch [mailto:[EMAIL PROTECTED]
>>
>
>> AFAICT, I don't think you've got everything nailed down here. As Vincent
>> already mentioned the ancestor reference area could change depending on
>> the value
On Mar 20, 2007, at 21:55, Andreas L Delmelle wrote:
On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
Have you actually checked the code to see the difference in
handling between absolute-position="absolute" and absolute-
position="fixed"?
Errm, that would be a no. I've checked: a) the R
On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
Have you actually checked the code to see the difference in
handling between absolute-position="absolute" and absolute-
position="fixed"?
Errm, that would be a no. I've checked: a) the Recommendation and b)
the resulting output.
I never t
[EMAIL PROTECTED] wrote:
- Oorspronkelijk bericht -
Van: Chris Bowditch [mailto:[EMAIL PROTECTED]
AFAICT, I don't think you've got everything nailed down here. As Vincent
already mentioned the ancestor reference area could change depending on
the value of abolute-position property
>- Oorspronkelijk bericht -
>Van: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
>AFAICT, I don't think you've got everything nailed down here. As Vincent
>already mentioned the ancestor reference area could change depending on
>the value of abolute-position property. So can you clarify exact
[EMAIL PROTECTED] wrote:
CSS doesn't have the last word here. See the definition for the 'left' property
(XSL-FO 1.1 - §7.6.5) all the way at the bottom. In XSL, these are interpreted
relative to the prevailing coördinate system. Not to the containing block as in
CSS, but to the nearest anc
>- Oorspronkelijk bericht -
>Van: Vincent Hennebert [mailto:[EMAIL PROTECTED]
>Manuel Mall a écrit :
>>
>> My understanding of the spec is that for "top" and "bottom" percentages
>> only make sense if the containing block has a fixed height. If the
>> containing block has a variable height
Hi,
Manuel Mall a écrit :
> On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote:
>> A fix for the left-percentage is setting the PercentBase on the
>> PropertyMaker for "left" to LengthBase.CONTAINING_BLOCK_WIDTH in
>> FOPropertyMapping.createAbsolutePositionProperties().
>> Although I'm not
On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote:
> Begin forwarded message:
> > From: Andreas L Delmelle <[EMAIL PROTECTED]>
> >
> >>
> >>
> >>> >>> bidi="embed">
> >>> >>> left="16.0%" top="16.0%">
> >>>
> >>> 1 >>> fo:inline>
> >>>
> >>>
> >>
> >
Begin forwarded message:
From: Andreas L Delmelle <[EMAIL PROTECTED]>
bidi="embed">
left="16.0%" top="16.0%">
1fo:inline>
So now the 1, 2 and 3 are all inside the outer box, but all at
the top left corner. This could be because the inside
th
29 matches
Mail list logo
