Hi dorayme

Apologies for the delay in replying, but I've been experimenting and
creating more mock-ups.

On 19 Mar, 03:30, dorayme <doraymeRidT...@optusnet.com.au> wrote:

> I have little doubt that Ben's suggestion would work. My concerns
> were twofold. One, if something goes wrong with absolute
> positioning, you will have to ask Ben again how to fix it. In
> other words, it is a trickier business. What is your final code
> looking like?

The code for just positioning the three icons is at http://tinyurl.com/34j9ws
.. However, to see the icons in some context, see the mock-up at
http://tinyurl.com/3yqf5t . (Or to see it in much fuller context, but
with external stylesheets and much more code, and therefore harder to
follow, see http://tinyurl.com/28mcte).

You'll notice that I have given the leftmost icon a Left value of
10px, so it isn't at the far left of the div. The reason for this is
that the right-most icon of the three is supposed to look as if it is
centred on the same point that the page number graphic below it is
centred on (which is the same point that the text below that is
justified to), and in order for this to be possible and yet for the
div itself to be centred, and for the left icon to line up with the
text below it, as it's meant to, the left edge of the div had to be
wider than it would otherwise have been, necessitating the left value
of 10px. I found this relatively easy to get my head around using
absolute positioning of the icons, but more complicated using the
inline method.

Another reason for my preferring the absolute positioning method is
that the gap between the bottoms of the icons and the "document page"
below them (see the second two mock-ups linked to above) needs to be
the same regardless of the height of the icons (some pages don't
contain all three icons, and therefore the maximum height varies).
This is automatic using absolute positioning of the images, but not if
the images are inline.

A third reason is that if you look at the source of the third mock-up
above, you'll see that the icons contain a lot of javascript (roll-
overs and tooltip-like hover text), so they're a lot more than just
images; and having to put all three images on one line would therefore
make the code less readable and maintainable, in my opinion.

***

But you're right that I did immediately hit a snag with the absolute
positioning method, which I have solved with some offline from a
friend, but neither he nor I fully understand the solution.

In order to push the "document page" (div.DocumentPage) below the
icons, I had to make its position relative and specify a value for
Top, which was fine and dandy except that I wanted there to be a space
below the "document page" (as in the second mock-up above - or in the
case of the third mock-up, I wanted a space between the document page
and the "Next/Previous" footer below it. To achieve this, I had to add
a spacer div below the document page, as in:

div.BelowDocSpacer {height: 95px}

<div class="BelowDocSpacer">&nbsp;</div>

What confuses me is that the height I had to specify of 95px is 44px
larger than the actual height of the space created below the "document
page" by it, which is 51px, not 95px. Do you know why one has to
specify a height for the spacer div of 44px greater than the space one
actually wants to create?

Dave

Hi dorayme

On 19 Mar, 03:12, dorayme <doraymeRidT...@optusnet.com.au> wrote:

> > But for layout I thought tables were considered a no-no these
> > days?
>
> I was suggesting to be a bit naughty to ease the pressure on
> yourself, that's all.

I'm trying to find the right balance between good practice (it's going
to be a public site viewed by a large number of people) and yet not
being so fanatical about avoiding tables that it ends up defeating the
object. So I went with your suggestion to use tables for numbering,
including for heading numbering; and (see my most recent reply to Ben
C) it looks as if I may end up keeping some of my layout tables after
all; but in the case of the three icons that I posted about at the
start of this thread, I've managed to replace my table with a div, and
I'd like to replace as many of my tables as divs as I can, but subject
to the above qualifications.

Dave

On 2008-03-27, Dave Rado <dave.rado@dsl.pipex.com> wrote:
[...]
> Apart from the lack of vertical centring, mock-ups 2 and 3 do look
> almost identical to each other in *non*-Microsoft browsers, but they
> don't in IE. In IE 6 and 7, in "mock-up 3", an unwanted 3px gap has
> appeared between the article title/page no. div and the orange line
> below it, for some reason that I can't fathom; and in IE 5.5, in
> addition to this problem, the right-hand edge of the page no. graphic
> is hidden, again for some reason that I can't fathom. Do you
> understand why, and how to fix this?

I don't know anything about IE.

> I didn't get the latter (IE 5.5)
> problem with the three icons that you ed me position earlier in
> the thread.
>
> In order to try to fix the IE 5.5 problem of the right-hand edge of
> the page no. graphic being hidden, I then tried using:
> img.PgNo {position: absolute; right: 0}
> (instead of using {float: right}), which was the method that you had
> suggested and which worked well for the rightmost of the three icons
> (img.TopOfPageIconsRight) above the document page earlier in this
> thread; but instead of aligning the image to the right of its parent
> div, (div.Header), it aligned it to the right of that div's parent div
> (div.DocumentPage) - in all browsers - and I don't understand why -
> see my "mock-up 4" at http://tinyurl.com/3dfm37 . Again, do you
> understand why, and how to fix this?

Position: absolute; right: 0 puts the box 0px from the right edge of its
container, which is the nearest ancestor with position: relative, fixed
or absolute.

In your case that's DocumentPage. If you make div.Header position:
relative then it will become the container for the PgNo which is what
you want.

>
> ****
>
>> Ben wrote:
>> You won't get anything vertically centered though. The only way to do vertical centering of a shrink-to-fit block is with tables.
>
> I've found several web tutorials that claim it is possible to do this
> (e.g. see http://tinyurl.com/2jhlbp)

That is using tables (display: table-cell is tables, but in a good way,
but it won't work in IE).

Position: absolute and top: 50% does sort of work. This is a useful page
about vertical centering:

http://www.student.oulu.fi/~laurirai/www/css/middle/

[...]
> I'm starting to think that you're right and that those web tutorials
> that imply thyat one can have cross-browser table-like vertical
> centring using css are misleading, in that while it is possible to get
> a sort of vertical centring in IE with css, it only seems to work
> properly if one can guarantee that the height of the contents of the
> div will never exceed the height of the div

That's basically the problem with position: absolute and top: 50%.

> - which I can't guarantee. So I think this is probably a case where
> I'll have to stick with using a table.

That is the best course of action, unless you can compromise on wanting
vertical centering.

[...]
> The reason I need vertically centred text for this, by the way, is
> that when the header only contains one line of text, which it
> frequently does, it looks much more pleasing on the eye if it is
> vertically centred relative to the page number graphic, as in "mock-up
> 2" (http://tinyurl.com/3yqf5t) than it does if it is not, as in "mock-
> up 3" (http://tinyurl.com/32xotl) - even in Firefox (and the
> difference is much more stark in IE).

To my eye the one that isn't vertically centered looks just fine

> I have some other layout tables that I had been hoping to convert to
> divs but in which the text also need to be vertically centred,
> although unlike the above table, I think I *can* guarantee that the
> height of the content of the other tables or divs will never be
> greater than the height of the divs themselves, so I guess I *could*
> use the vertical centring workaround method described at
> http://tinyurl.com/2jhlbp to replace those tables with divs, but I'm
> wondering whether it's really justified, given that this workaround
> seems quite clunky to me (in order for it to work in IE). See my
> mock-up of a menu at http://tinyurl.com/36pscl , and of a footer at
> http://tinyurl.com/33fej9 , which currently both use simple css-based
> tables. (Or you can see both of them in full context at
> http://tinyurl.com/28mcte, but the othetr mock-ups are much simpler
> and easier to make sense of).
>
> In your opinion, would it be advisable to convert these tables to divs
> using the above workaround?

In my opinion stick with the tables if you must have vertical centering.

> The reason I'm not sure is that most of the normal reasons for using
> divs rather than tables don't seem to me to apply in either case,
> mainly because the workaround to get the vertical centring in IE seems
> quite clunky to me

I agree.

[...]
> - and - correct me if
> I'm wrong, but I doubt it would make the html any easier for a screen
> reader to navigate, because it requires several additional divs to
> make it work.

I don't know much about screen readers but someone here I think once
pointed out that his screen reader just reads what's actually
_displayed_ in the browser window-- in other words it grabs text off the
page like a clipboard copy operation, and doesn't look at the HTML
source at all.

On 2008-03-27, Dave Rado <dave.rado@dsl.pipex.com> wrote:
> Hi dorayme
>
> Apologies for the delay in replying, but I've been experimenting and
> creating more mock-ups.
>
> On 19 Mar, 03:30, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
>> I have little doubt that Ben's suggestion would work. My concerns
>> were twofold. One, if something goes wrong with absolute
>> positioning, you will have to ask Ben again how to fix it. In
>> other words, it is a trickier business. What is your final code
>> looking like?
>
> The code for just positioning the three icons is at http://tinyurl.com/34j9ws
> . However, to see the icons in some context, see the mock-up at
> http://tinyurl.com/3yqf5t . (Or to see it in much fuller context, but
> with external stylesheets and much more code, and therefore harder to
> follow, see http://tinyurl.com/28mcte).
>
[...]
> But you're right that I did immediately hit a snag with the absolute
> positioning method, which I have solved with some offline from a
> friend, but neither he nor I fully understand the solution.
>
> In order to push the "document page" (div.DocumentPage) below the
> icons, I had to make its position relative and specify a value for
> Top, which was fine and dandy

Moving things with position: relative is a bit risky, because in a sense
they don't really move, they just get rendered offset from their real
position as it were at the last minute. The space they occupy and their
effect on the positions and sizes of sibling and parent boxes is just
the same as if you didn't offset them.

In this case, it might have been better to give body margin-top: 80px or
something instead, because that moves everything down properly.

> except that I wanted there to be a space
> below the "document page" (as in the second mock-up above - or in the
> case of the third mock-up, I wanted a space between the document page
> and the "Next/Previous" footer below it. To achieve this, I had to add
> a spacer div below the document page, as in:
>
> div.BelowDocSpacer {height: 95px}
>
><div class="BelowDocSpacer">&nbsp;</div>
>
> What confuses me is that the height I had to specify of 95px is 44px
> larger than the actual height of the space created below the "document
> page" by it, which is 51px, not 95px. Do you know why one has to
> specify a height for the spacer div of 44px greater than the space one
> actually wants to create?

It's because your DocumentPage is "really" 84px higher up than it looks.
You've also got a 40px bottom margin on DocumentPage which is the extra
40px. 40 + 44 = 84.

Think of relative positioning like this: the whole page is first laid
out as if all relatively positioned boxes had top: 0 and left: 0. Then,
afterwards, each relatively postioned box is translated by whatever you
set for top, left, bottom or right. It takes its descendents with it
when it moves, but that's all, nothing else is affected. The page isn't
laid out again.

A simple example:

<div id="container" style="border: 1px solid black">
<div style="height: 100px" id="A"></div>
<div style="height: 200px" id="B"></div>
</div>

Normally, B's top edge will start 100px from the top of the container.

Now make A position: relative; top: 150px. *B doesn't move*. Its top is
aligned with where the bottom of A was before A was offset.

But if you give A instead a top margin of 150px, it moves down properly,
and B flows underneath it like it should.

Hi Ben

On 27 Mar, 22:25, Ben C <spams...@spam.eggs> wrote:

> Position: absolute; right: 0 puts the box 0px from the right edge of its
> container, which is the nearest ancestor with position: relative, fixed
> or absolute.
>
> In your case that's DocumentPage. If you make div.Header position:
> relative then it will become the container for the PgNo which is what
> you want.

That fixed the IE5.5 problem, thanks. For some reason IE5.5 can cope
with Position: absolute; right: 0 but seems not to be able to cope
with float: right.


> In my opinion stick with the tables if you must have vertical centring.

Thanks, that's one decision made, anyway.


> I don't know much about screen readers but someone here I think once
> pointed out that his screen reader just reads what's actually
> _displayed_ in the browser window-- in other words it grabs text off the
> page like a clipboard copy operation, and doesn't look at the HTML
> source at all.

Okay thanks, that's a relief to know. Given this, it's odd, though,
that screen reader accessibility is often given in tutorials as a
primary reason not to use tables for layout.

Dave

Hi Ben

On 27 Mar, 22:43, Ben C <spams...@spam.eggs> wrote:

> Moving things with position: relative is a bit risky, because in a sense
> they don't really move, they just get rendered offset from their real
> position as it were at the last minute. The space they occupy and their
> effect on the positions and sizes of sibling and parent boxes is just
> the same as if you didn't offset them.
>
> In this case, it might have been better to give body margin-top: 80px or
> something instead, because that moves everything down properly.

Except that doing that also moves the three icons above the document
page down to below the top of the document page, when I try it - see
my mock-up at http://tinyurl.com/2j68p3 (the mock-up showing how I
want it to look is at http://tinyurl.com/3yqf5t). This was my original
reason for setting the DocumentPage div to have a relative position.

If I make div.TopOfPageIcons have an absolute position instead of a
relative one (which does fix the above problem), it stops being
centred.

What do I need to change to my code at http://tinyurl.com/2j68p3 to
make it look like http://tinyurl.com/3yqf5t ?


> Think of relative positioning like this: the whole page is first laid
> out as if all relatively positioned boxes had top: 0 and left: 0. Then,
> afterwards, each relatively positioned box is translated by whatever you
> set for top, left, bottom or right. It takes its descendents with it
> when it moves, but that's all, nothing else is affected. The page isn't
> laid out again.
>
> A simple example:
>
> <div id="container" style="border: 1px solid black">
> <div style="height: 100px" id="A"></div>
> <div style="height: 200px" id="B"></div>
> </div>
>
> Normally, B's top edge will start 100px from the top of the container.
>
> Now make A position: relative; top: 150px. *B doesn't move*. Its top is
> aligned with where the bottom of A was before A was offset.
>
> But if you give A instead a top margin of 150px, it moves down properly,
> and B flows underneath it like it should.

A very clear and ful explanation, thanks.

Dave

Hi dorayme

On 27 Mar, 23:02, dorayme <doraymeRidT...@optusnet.com.au> wrote:

> You might consider it revelatory to *not* require such complicated and
> exact layout. Have you really taken your head out of the considerable
> details you are involved with and really thought how you might deliver
> your material in a much simple way without compromising what the end
> user will truly benefit from?

I believe so. I hope that if you disagree, you will still be willing
to me find solutions to specific problems that I post about.

Dave

On 2008-03-28, Dave Rado <dave.rado@dsl.pipex.com> wrote:
[...]
>> I don't know much about screen readers but someone here I think once
>> pointed out that his screen reader just reads what's actually
>> _displayed_ in the browser window-- in other words it grabs text off the
>> page like a clipboard copy operation, and doesn't look at the HTML
>> source at all.
>
> Okay thanks, that's a relief to know. Given this, it's odd, though,
> that screen reader accessibility is often given in tutorials as a
> primary reason not to use tables for layout.

Well you can't believe everything you read in tutorials

There may be other screen readers that do use the HTML, or it may just
be one of those myths that gets around.

In principle you'd think a screen reader _should_ read the HTML, not the
screen. But, they may be designed to read text off any application, not
just a browser, and since lot of websites don't follow accessiblity
guidelines it may also work better in practice just to read the screen.