By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,396 Members | 1,869 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,396 IT Pros & Developers. It's quick & easy.

The best pure HTML way of doing this page?

P: n/a
Hello all, I hope you can help me.

Given graphical idea for a page:

http://www.ransen.com/temp/temp.htm

(Large image, please be patient!)

What is the best way of constructing this page so that it does not
require Flash or frames or active-x? It has to work on Mac (for
a very good reason, this is not just a whim!) as well as Win
computers.

The C shaped "frame" (which encloses the price list), can that be
done without frames?

The table with shaded background, what is the best way of
constructing it so that it appears (roughly) the same on Win
and Mac and IE and NS and Opera?

I would prefer to use pure HTML if possible...

TIA

Owen
Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
On Mon, 10 May 2004 06:30:48 +0200, O Ransen <wa***@wonky.com> wrote:
Hello all, I hope you can help me.

Given graphical idea for a page:

http://www.ransen.com/temp/temp.htm

(Large image, please be patient!)

What is the best way of constructing this page so that it does not
require Flash or frames or active-x? It has to work on Mac (for
a very good reason, this is not just a whim!) as well as Win
computers.

The C shaped "frame" (which encloses the price list), can that be
done without frames?

The table with shaded background, what is the best way of
constructing it so that it appears (roughly) the same on Win
and Mac and IE and NS and Opera?

I would prefer to use pure HTML if possible...


Use table markup for the price list, why not. It's a table.

Use a styled div for the black header, then a red background color below.
Nav menu and the bottom controls can be positioned into place. If it's
acceptable for the bottom red bit to be at the bottom of all content, your
jub is easier. If it has to stay at the bottom of the viewport, that's a
bit tougher. You can make the section with the table scrollable, but
that's kinda weird actually. Now if those buttons and such which are at
the bottom can be moved to the top, you can have them at the bottom of
content too, and that would be good.

If the page must be done precisely to the specification image, it's doable
but not ideal. Putting the controls on top under the header and down at
the bottom of the content (below the fold) would be far more usable and I
think more in line with what browsers are used to doing.
Jul 20 '05 #2

P: n/a
On Mon, 10 May 2004 01:04:32 -0400, Neal <ne*****@yahoo.com> wrote:

Use table markup for the price list, why not. It's a table.
Yes, but I had heard that NS and IE treat table images and
background images differently. Correct me if I am wrong.
If the page must be done precisely to the specification image, it's doable
but not ideal. Putting the controls on top under the header and down at
the bottom of the content (below the fold) would be far more usable and I
think more in line with what browsers are used to doing.


I agree, and will try to pursuade the customer. Maybe I'll make a
mock-up to see how it would look with stuff at the top.

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #3

P: n/a

"O Ransen" <wa***@wonky.com> wrote in message
news:a0********************************@4ax.com...
On Mon, 10 May 2004 01:04:32 -0400, Neal <ne*****@yahoo.com> wrote:

Use table markup for the price list, why not. It's a table.


Yes, but I had heard that NS and IE treat table images and
background images differently. Correct me if I am wrong.


I'm not sure what a "table image" is, but if you mean that there are spacing
issues with a table cell that contains just an image, that's usually caused
by having

<td>
<img ...>
</td>

and can be fixed by putting these tags on one line:

<td><img ...></td>

Jul 20 '05 #4

P: n/a
O Ransen <wa***@wonky.com> wrote:
http://www.ransen.com/temp/temp.htm I would prefer to use pure HTML if possible...


<table>...</table> is the first thing that comes to mind, because the 4
columns sure looks like table. The left frame can be placed at the top,
right after "LONGO..." banner, so that 10 vertical links will show up as
2 rows x 5 columns of links. The bottom navigation frame can go at the
bottom, after the price table. Basically, HTML is infinite length
scroll. So, forget about "page" nonsense.

--
William Park, Open Geometry Consulting, <op**********@yahoo.ca>
Linux solution/training/migration, Thin-client
Jul 20 '05 #5

P: n/a
On Mon, 10 May 2004 13:52:56 -0400, "Harlan Messinger"
<h.*********@comcast.net> wrote:
Yes, but I had heard that NS and IE treat table images and
background images differently. Correct me if I am wrong.


I'm not sure what a "table image" is, but if you mean that there are spacing
issues with a table cell that contains just an image, that's usually caused
by having


Thanks, that could be useful. But what I meant was a table
*background* image.

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #6

P: n/a
On 10 May 2004 18:46:03 GMT, William Park <op**********@yahoo.ca>
wrote:
O Ransen <wa***@wonky.com> wrote:
http://www.ransen.com/temp/temp.htm

I would prefer to use pure HTML if possible...


<table>...</table> is the first thing that comes to mind,


And use fixed size table cells with a background image
to get those buttons?

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #7

P: n/a
On Mon, 10 May 2004, O Ransen wrote:
The table with shaded background, what is the best way of
constructing it so that it appears (roughly) the same on Win
and Mac and IE and NS and Opera?

I would prefer to use pure HTML if possible...


"Pure" HTML is for marking up logical structure, not for visual
appearance. It sounds as if you're struggling to use *impure*
HTML - but why? The days of HTML/3.2 and pseudo-DTP-quasi-HTML
are over, and I see no reason to believe that they'll come back.
Jul 20 '05 #8

P: n/a
On Tue, 11 May 2004 17:22:43 +0200, O Ransen <wa***@wonky.com> wrote:
On 10 May 2004 18:46:03 GMT, William Park <op**********@yahoo.ca>
wrote:
O Ransen <wa***@wonky.com> wrote:
http://www.ransen.com/temp/temp.htm

I would prefer to use pure HTML if possible...


<table>...</table> is the first thing that comes to mind,


And use fixed size table cells with a background image
to get those buttons?


Is that a good way to do it? I'm ignorant in the HTML of
tables (among other things), but if that is a good portable
way of doing it I'll be happy...

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #9

P: n/a
On Tue, 11 May 2004 17:20:57 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:
On Mon, 10 May 2004, O Ransen wrote:
The table with shaded background, what is the best way of
constructing it so that it appears (roughly) the same on Win
and Mac and IE and NS and Opera?

I would prefer to use pure HTML if possible...


"Pure" HTML is for marking up logical structure, not for visual
appearance.


What I mean is no Flash or Java or Direct-X and not using a
single bitmap "map" as a page
Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #10

P: n/a
On Wed, 12 May 2004 05:54:43 +0200, O Ransen <wa***@wonky.com> wrote:

Is that a good way to do it? I'm ignorant in the HTML of
tables (among other things), but if that is a good portable
way of doing it I'll be happy...


Table markup is meant for tables. Read up, soldier:
http://www.w3.org/TR/html401/struct/tables.html
Jul 20 '05 #11

P: n/a
On Wed, 12 May 2004 00:29:14 -0400, Neal <ne*****@yahoo.com> wrote:
On Wed, 12 May 2004 05:54:43 +0200, O Ransen <wa***@wonky.com> wrote:

Is that a good way to do it? I'm ignorant in the HTML of
tables (among other things), but if that is a good portable
way of doing it I'll be happy...


Table markup is meant for tables. Read up, soldier:


But will it work sonny?

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #12

P: n/a
/O Ransen/:
Table markup is meant for tables. Read up, soldier:


But will it work sonny?


Please, define "will it work" more importantly the meaning of "work".

--
Stanimir
Jul 20 '05 #13

P: n/a
On Wed, 12 May 2004 21:29:55 +0300, Stanimir Stamenkov
<s7****@netscape.net> wrote:
/O Ransen/:
Table markup is meant for tables. Read up, soldier:


But will it work sonny?


Please, define "will it work" more importantly the meaning of "work".


Will fixing the cell size of tables to match that of the images
used as their backgrounds work in the popular browsers,
including browsers on the Mac?

Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #14

P: n/a
/O Ransen/:
Will fixing the cell size of tables to match that of the images
used as their backgrounds work in the popular browsers,
including browsers on the Mac?


Then you most probably need to address your questions in the
c.i.w.a.stylesheets group. Your HTML document carries just the data
you're supplying (some elements have functional semantics but which
is not tied to any particular presentation, again). The
presentational hints are carried by stylesheets.

I recommend you to familiarize yourself with the CSS visual
formatting details because that's how browsers currently work (use
to visualize the information). HTML is not meant to describe visual
page appearance. It just describes/marks up a data forming logical
structure which could be processed by various agents (not necessary
browsers which visualize the information).

Here's a basic example:

http://www.geocities.com/stanio/test/rasen.html

Generally you don't need to fix the widths. Notice I've used extra
markup to be able to stylize it additionally, but this a and the
rest (how to achieve rounded corners, etc.) are details to be
discussed in the c.i.w.a.s group.

--
Stanimir
Jul 20 '05 #15

P: n/a
On Fri, 14 May 2004 15:30:57 +0300, Stanimir Stamenkov
<s7****@netscape.net> wrote:

I recommend you to familiarize yourself with the CSS visual
formatting details because that's how browsers currently work (use
to visualize the information).
What % of current browsers support CSS?
Here's a basic example:

http://www.geocities.com/stanio/test/rasen.html


Thanks, I'll have a look.
Unique and easy to use graphics programs
http://www.ransen.com
Jul 20 '05 #16

P: n/a
Quoth the raven O Ransen:
On Fri, 14 May 2004 15:30:57 +0300, Stanimir Stamenkov
<s7****@netscape.net> wrote:
I recommend you to familiarize yourself with the CSS visual
formatting details because that's how browsers currently work
(use to visualize the information).


What % of current browsers support CSS?


Well, if you subtract the tiny bit of visitors that use text browsers,
or aural browsers, what are you left with?

98% ?

You said browsers, so you're not talking about other means of access
such as the Googlebot.

--
-bts
-This space intentionally left blank.
Jul 20 '05 #17

P: n/a
Tim
On Sat, 15 May 2004 07:03:20 +0200,
O Ransen <wa***@wonky.com> posted:
What % of current browsers support CSS?

^^^^^^^

I'd say most of them. And if you consider the major current ones that most
people would have, that's just about all of them. And quite a lot of the
alternative browsers support it too (remember that anyone deliberately
choosing to use a non-mainstream browser is probably *expecting* different
behaviour than the main ones).

I think you'd probably find that the vast majority of people currently on
the net are probably using fairly recent browsers, too. I wouldn't worry,
too much, about the lesser amount of people using older browsers; so long
as you're not trying to do something overly special with CSS.

In my opinion, how some browser is going to handle something like scripting
is more of problem than how well they might handle CSS.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #18

P: n/a
Beauregard T. Shagnasty wrote:
Quoth the raven O Ransen:
On Fri, 14 May 2004 15:30:57 +0300, Stanimir Stamenkov
<s7****@netscape.net> wrote:
I recommend you to familiarize yourself with the CSS visual
formatting details because that's how browsers currently work
(use to visualize the information).
What % of current browsers support CSS?


Somehow, I think that requires to define word "support" first.
Well, if you subtract the tiny bit of visitors that use text browsers,
or aural browsers, what are you left with?
And things like @page , display:marker dropped of when considering CSS
(and not care that support bugginess of float, positioning and )
98% ?


If support = some CSS features are supported

If support = everything works according to spec, then about 2%. 2% being
the browsers that don't support CSS at all, so they don't break
anything... (by spec, ignore all CSS rulse you don't understand...)

CSS support is better than HTML support though, when thinking as
limitedly, as HTML is not optional... (and many very useful features of
HTML aren't supported for IE, for example. Those are not known many
people for obvious reasons though...)
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä
Jul 20 '05 #19

P: n/a
Quoth the raven Lauri Raittila:
Beauregard T. Shagnasty wrote:
Quoth the raven O Ransen:
On Fri, 14 May 2004 15:30:57 +0300, Stanimir Stamenkov
<s7****@netscape.net> wrote:

I recommend you to familiarize yourself with the CSS visual
formatting details because that's how browsers currently work
(use to visualize the information).

What % of current browsers support CSS?

Somehow, I think that requires to define word "support" first.
Well, if you subtract the tiny bit of visitors that use text
browsers, or aural browsers, what are you left with?


And things like @page , display:marker dropped of when considering
CSS (and not care that support bugginess of float, positioning and
)
98% ?


If support = some CSS features are supported


In the perceived context of the OP's question, yes.
If support = everything works according to spec, then about 2%. 2%
being the browsers that don't support CSS at all, so they don't
break anything... (by spec, ignore all CSS rulse you don't
understand...)


Personally, I feel that most modern browsers support enough of CSS for
an author to create a worthwhile fluid web site without worrying about
the quirks of "everything according to spec."

So, I'm sticking by 98%. <g>

--
-bts
-This space intentionally left blank.
Jul 20 '05 #20

P: n/a
Beauregard T. Shagnasty wrote:
Quoth the raven Lauri Raittila:
Somehow, I think that requires to define word "support" first.
Well, if you subtract the tiny bit of visitors that use text
browsers, or aural browsers, what are you left with?
And things like @page , display:marker dropped of when considering
CSS (and not care that support bugginess of float, positioning and
)
98% ?


If support = some CSS features are supported

Personally, I feel that most modern browsers support enough of CSS for
an author to create a worthwhile fluid web site without worrying about
the quirks of "everything according to spec."


Unfortunately, I find limitations of browser support very annoying daily.
Tou might have learned to live with them, just like me, but for new
person on CSS, it is not at all that clear. How can he know that >
selector don't work on IE, that display:inline-table only works on Opera
and that all browsers implement floats slightly different way, and none
correct.
So actually browser support is limit to CSS use everyday. It limits what
you can do, even if with current browser support, making CSS based
layouts is better than html layouts.

It is easy to style HTML page that is well authored using CSS. But to
make it work on IE, for example, you need to change that HTML, to get
things work. (mainly adding )
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä
Jul 20 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.