textarea/table
Randy Kimple
html formated text in one of the cells. My problem is that I would like
to be able to insert the text in a textarea or some other scrollable
field so that I don't lose the rest of the table off the screen. Other
limitations of this project forbid the use of frames. Any suggestions?
Thanks,
Randy
Robin
Randy Kimple wrote:
You might be able to do it with DHTML code, but I don't know much about
it...
--
Robin Bank
rb...@csf.edu
**************************
-Addictions cannot be outlawed. *
**************************
++++ stop de execution of Mumia Abu-Jamal ++++
++++ if you agree copy these 3 sentences in your own sig ++++
++++ more info: http://www.xs4all.nl/~tank/spg-l/sigaction.htm ++++
..
The actuall limits are not specified in the specs and relate more to the
platform involved.
Either way it is highly un-likely that you will encounter any difficulties.
The only thing you will need to be concerned with is encoding all
those characters that might be mis-interpreted < > & "
< =<
> =>
& =&
" ="
There is a C/C++ code snippet available for this in the "C++ code snippets"
section of
my HTML/CGI guide
http://www.drclue.net/F1.cgi/HTML/HTML.html
Randy Kimple wrote:
> I am using a table to format a page and need to insert a large amount of
> html formated text in one of the cells. My problem is that I would like
> to be able to insert the text in a textarea or some other scrollable
> field so that I don't lose the rest of the table off the screen. Other
> limitations of this project forbid the use of frames. Any suggestions?
>
> Thanks,
> Randy
--
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=--
--=<[]>=- http://www.drclue.net
--=<[]>=- C++ HTML JavaScript JAVA VRML
--=<[]>=- CGI NSAPI TCP/IP SQL Sybase Informix (Interest In Oracle)
--=<[]>=- Dr. Clue's famous HTML/CGI guide.
--=<[]>=- http://www.drclue.net/F1.cgi/HTML/HTML.html
Hell Hound a.o.d. [AGQ2]
you mean an inline frame? where it looks like a frame? with a page in it? if
you want to see the text itself, use textarea. otherwise give up, because
there is no way w/o the use of frames to insert one.
Randy Kimple wrote:
> I am using a table to format a page and need to insert a large amount of
> html formated text in one of the cells. My problem is that I would like
> to be able to insert the text in a textarea or some other scrollable
> field so that I don't lose the rest of the table off the screen. Other
> limitations of this project forbid the use of frames. Any suggestions?
>
> Thanks,
> Randy
--
Hell Hound -aod- (E.G. Dodds)
BSBH...@aol.com
ICQ UIN: 8878412
http://www.geocities.com/timessquare/castle/2231/
just sitting there ->http://members.aol.com/bsbhhound/
"Incoming fire always has the right of way"
Jukka Korpela
> I am using a table to format a page
Please reconsider this choice. If you would use a table just to
get a particular layout, you are causing problems, not solving them.
See what the newest official HTML specification says:
"Tables should not be used purely as a means to layout document content
as this may present problems when rendering to non-visual media.
Additionally, when used with graphics, these tables may force users
to scroll horizontally to view a table designed on a system with
a larger display."
( http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.1 )
(And that's just a list of _some_ of the problems caused.)
Naturally, you might have a real table - data which is logically tabular -
but typically people who run into problems with tables are trying
to do layout.
> and need to insert a large amount of
> html formated text in one of the cells.
This is going to cause problems if you manage to do that, no matter
how you do that. It will be difficult to view such pages on normal
screens even if one runs a browser in full-screen mode, still less
in normal use.
> My problem is that I would like
> to be able to insert the text in a textarea or some other scrollable
> field so that I don't lose the rest of the table off the screen.
What I primarily suggest is that you reconsider the design. Can't you
just provide links to documents which contain the texts? The links
could be followed by opening them in new windows, positioned and
sized by the user according to what's possible and convenient to him.
There is no element in HTML which specifies a scrollable area. The
TEXTAREA element is _typically_ _implemented_ that way, but it would
be misleading since the typical presentation suggests it's a form
field for user input - which is, after all, what TEXTAREA is for.
Another problem with TEXTAREA is that it is typically presented
in monospaced font. And _by definition_ the content of TEXTAREA
element is plain character data - you can't use any HTML markup there.
(If by "html formated text" you really mean that you _want_ to present
HTML markup as such, as character data instead of being formatted
by a browser for presentation normally, I wonder what you are trying
to do. Not writing an HTML tutorial I hope.)
There's one technical possibility if you want a scrollable area:
use OBJECT. When used for HTML documents, it is typically implemented
_if implemented at all_ using a scrollable area. See
http://www.w3.org/TR/REC-html40/struct/objects.html#edef-OBJECT
but also
http://www.webreference.com/dev/html4nsie/objects.html
which explains how horrible the implementation status is. However,
it seems that something like the following _might_ work reasonably,
giving a scrollable area on IE 4.0 and Netscape 4.0 and a normal
link on older versions and most other browsers:
<OBJECT DATA="something.html" WIDTH="450" HEIGHT="200">
<P><A HREF="something.html">The something</A>
is available as a separate document.</P>
</OBJECT>
The problem with this is that contrary to the letter and spirit
of the specification, IE 4.0 and Netscape 4.0 _require_ the
WIDTH and HEIGHT attributes, thus forcing you to give fixed
dimensions in pixels.
--
Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Michael Powe
Jukka> Randy Kimple <Randall...@med.unc.edu> writes:
>> I am using a table to format a page
Jukka> Please reconsider this choice. If you would use a table
Jukka> just to get a particular layout, you are causing problems,
Jukka> not solving them. See what the newest official HTML
Jukka> specification says: "Tables should not be used purely as a
Jukka> means to layout document content as this may present
Jukka> problems when rendering to non-visual media. Additionally,
Jukka> when used with graphics, these tables may force users to
Jukka> scroll horizontally to view a table designed on a system
Jukka> with a larger display."
"By design, HTML tables let authors create appealing, accessible
tables of information. But the HTML table tags also can be exploited
to create innovative, attractive page designs that are otherwise
unobtainable in standard HTML." -- <HTML: The Definitive Guide>,
Chuck Musciano & Bill Kennedy (ORA)
I'm certainly far from any kind of expert in html, but I would be
curious to know how it is possible to design a page with graphics that
won't go bonkers when the user starts changing font sizes. I started
using tables to maintain the relationship between graphics and text
after I accidently changed font sizes on my own page and saw what a
mess it made. "Confining" certain sections of the page within a table
assures that if the font size goes up, the graphics won't be "pushed"
out of place.
I'm not particularly a lover of graphics but I do think they can play
a proper role in making a page "easy on the eyes."
I may add that I do 80% of my own 'surfing' in lynx and emacs/w3, and
so I have had ample opportunity to see badly-designed graphics-based
pages. They're generally unusable. That's not what I'm referencing.
I'm not particularly happy with the way my page views in lynx right
now, but still, it's better than lots of others.
Anyway, just my .02.
mp
--
Michael Powe
mic...@trollope.org http://www.trollope.org
Portland, Oregon USA
Alan J. Flavell
> "By design, HTML tables let authors create appealing, accessible
> tables of information. But the HTML table tags also can be exploited
> to create innovative, attractive page designs that are otherwise
> unobtainable in standard HTML." -- <HTML: The Definitive Guide>,
> Chuck Musciano & Bill Kennedy (ORA)
Anyone who has the nerve to call themselves "definitive" without any
clear authority for doing so deserves to be criticised.
The truly definitive document says:
| Tables should not be used purely as a means to layout document content
| as this may present problems when rendering to non-visual media.
| Additionally, when used with graphics, these tables may force users to
| scroll horizontally to view a table designed on a system with a larger
| display. To minimize these problems, authors should use style sheets
| to control layout rather than tables.
^^^^^^^
http://www.w3.org/TR/REC-html40/struct/tables.html
It should perhaps have said "suggest" rather than "control", but
there you have it.
> I'm certainly far from any kind of expert in html, but I would be
> curious to know how it is possible to design a page with graphics that
> won't go bonkers when the user starts changing font sizes.
One can do it with careful use of the available HTML elements, leaving
it to the browser to do its best to present the material in each
browsing situation that it finds at its disposal.
It's disappointing just how few pages are making use of the simple <IMG
ALIGN=LEFT|RIGHT ...> to inset an image into running text - everyone
seems to immediately grab for the more complex and less resilient TABLE
tag. I guess it's mostly just because they're using brain-dead
wannabe-WYSIWYG authoring packages (what I recently saw aptly described
as WYSIcrap).
> I started
> using tables to maintain the relationship between graphics and text
Well, if there's a "relationship" (e.g between an image and its
caption), then it's certainly arguable that a table would be an apt way
to present that relationship, in the absence of some more-appropriate
HTML way of tagging the text as a figure caption (OBJECT was a great
idea, but - like its predecessor FIG - the browser makers don't seem
inclined to support it properly).
If, on the other hand, the "relationship" is nothing more than your
belief that these objects look pretty neat on your own display at your
chosen settings, then you lose, in terms of authoring HTML for the WWW.
Stewart D will be along any moment to tell you that this is precisely
what "real world" web sites do and where all the action is, and in
statisticial terms he'd be right. But in statistical terms
ninety-something percent of everything is crap, and in the end the
choice is yours. After all, you yourself have provided one very good
argument for _not_ trying to produce a precise layout: you said "go
bonkers when the user starts changing font sizes". But there's more to
it than that, across the entire range of WWW client agents (not all of
which are browsers).
> after I accidently changed font sizes on my own page and saw what a
> mess it made. "Confining" certain sections of the page within a table
> assures that if the font size goes up, the graphics won't be "pushed"
> out of place.
You've identified the problem OK. But a better solution might be to
give up the idea that everything needs a precise visual "place", across
all browsing situations, and instead look to creatively exploit HTML's
ability to mark up content in ways that adapt themselves automatically
to the browsing situation. It ain't perfect, for sure, but there's
plenty of scope even within the existing markups.
> I may add that I do 80% of my own 'surfing' in lynx and emacs/w3, and
> so I have had ample opportunity to see badly-designed graphics-based
> pages. They're generally unusable. That's not what I'm referencing.
Hmmm.
> I'm not particularly happy with the way my page views in lynx right
> now, but still, it's better than lots of others.
Looks better than you make it out to be. There's a few adjustments I
might suggest. These two links for example need a delimiter of some
kind:
About the Owner Mail
There's some suggestions on my ALT text pages if you're interested:
http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html
Perhaps Lynx should provide its own delimiters around ALT texts (as
emacs-w3 puts [ ] around them, at least in the versions I've seen), but
Lynx doesn't, and there _are_ situations where emacs-w3's delimiters are
a nuisance.
all the best
Michael Powe
>>>>> "Alan" == Alan J Flavell <fla...@mail.cern.ch> writes:
Alan> On Sun, 19 Jul 1998, Michael Powe wrote:
>> "By design, HTML tables let authors create appealing,
>> accessible tables of information. But the HTML table tags also
>> can be exploited to create innovative, attractive page designs
>> that are otherwise unobtainable in standard HTML." -- <HTML:
>> The Definitive Guide>, Chuck Musciano & Bill Kennedy (ORA)
Alan> Anyone who has the nerve to call themselves "definitive"
Alan> without any clear authority for doing so deserves to be
Alan> criticised.
Yeah, well ... I spent quite a bit of time looking over the ridiculous
number of "html authoring" books at the local tech bookstore & -- as
usual -- the ORA book was the only one that seemed more than half-way
sensible. And, to be fair, here's what they say in Chapter One:
"Before you can fully appreciate the power of the language and begin
creating effective HTML documents, you must yield to its one
fundamental rule: HTML is designed to structure documents and make
their content more accessible, not to format documents for display
purposes."
IMO, the necessity is to balance "easy to look at" and "easy to use."
Alan> It's disappointing just how few pages are making use of the
Alan> simple <IMG ALIGN=LEFT|RIGHT ...> to inset an image into
Alan> running text - everyone seems to immediately grab for the
Alan> more complex and less resilient TABLE tag. I guess it's
Alan> mostly just because they're using brain-dead wannabe-WYSIWYG
Alan> authoring packages (what I recently saw aptly described as
Alan> WYSIcrap).
The "align" tags don't work in lynx -- that's a big problem. In
addition, shifting font sizes will override the align setting. Or, to
be more precise, if you have text with an image set to align=right and
you increase the size of the font, you will push the image out of
place. I always use these alignments. But, realistically, the only
"safe" way to avoid a really scrappy looking page is to never have
text and graphics alongside each other. Unless you're willing to
confine the materials in a table.
>> I started using tables to maintain the relationship between
>> graphics and text
Alan> Well, if there's a "relationship" (e.g between an image and
Alan> its caption), then it's certainly arguable that a table
Alan> would be an apt way to present that relationship, in the
Alan> absence of some more-appropriate HTML way of tagging the
Alan> text as a figure caption (OBJECT was a great idea, but -
Alan> like its predecessor FIG - the browser makers don't seem
Alan> inclined to support it properly).
Alan> If, on the other hand, the "relationship" is nothing more
Alan> than your belief that these objects look pretty neat on your
Alan> own display at your chosen settings, then you lose, in terms
Alan> of authoring HTML for the WWW. Stewart D will be along any
Well, maybe. To me, it seems like the objective is to make the
content look good no matter what the person is doing on the other end
with her browser. When I look at a web page, I look at it with the
same "design-sense" I use when I look at the page of a book.
>> after I accidently changed font sizes on my own page and saw
>> what a mess it made. "Confining" certain sections of the page
>> within a table assures that if the font size goes up, the
>> graphics won't be "pushed" out of place.
Alan> You've identified the problem OK. But a better solution
Alan> might be to give up the idea that everything needs a precise
Alan> visual "place", across all browsing situations, and instead
Alan> look to creatively exploit HTML's ability to mark up content
Alan> in ways that adapt themselves automatically to the browsing
Alan> situation. It ain't perfect, for sure, but there's plenty
Alan> of scope even within the existing markups.
It's not that everything needs a "place," but that everything needs to
relate properly on the page. Obviously, the page looks very different
in lynx from the way it looks in netscape which again looks different
from the appearance in IE.
>> I may add that I do 80% of my own 'surfing' in lynx and
>> emacs/w3, and so I have had ample opportunity to see
>> badly-designed graphics-based pages. They're generally
>> unusable. That's not what I'm referencing.
Alan> Hmmm.
>> I'm not particularly happy with the way my page views in lynx
>> right now, but still, it's better than lots of others.
Alan> Looks better than you make it out to be. There's a few
Alan> adjustments I might suggest. These two links for example
Alan> need a delimiter of some kind:
Alan> About the Owner Mail
I mostly have fixed these problems this morning, with an experimental
usage of <pre></pre> tags. These don't override the align= tags in
Netscape -- don't have IE handy so I can't be sure how that works.
So, in NS the images locate properly; and the alt=text is properly
positioned in lynx.
I've done everything I can to avoid any proprietary "extensions" --
that's one of the reasons I invested in the ORA book. Another reason
was because I wanted to learn how to use style sheets. That may have
been a waste of money, they seem to be not universally supported,
either.
Alan> There's some suggestions on my ALT text pages if you're
Alan> interested:
Alan> http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html
I'll take a look, thanks.
Pattyandme
maximised
to a diffrent location so it basicly reformats the entire page were tables fix
the text and pics in a piticular location reguardless of the size of the
brouser.
Alan J. Flavell
> [...] as
> usual -- the ORA book was the only one that seemed more than half-way
> sensible. And, to be fair, here's what they say in Chapter One:
>
> "Before you can fully appreciate the power of the language and begin
> creating effective HTML documents, you must yield to its one
> fundamental rule: HTML is designed to structure documents and make
> their content more accessible, not to format documents for display
> purposes."
That's good, and O'Reilly have a good reputation. It's that word
"Definitive" in the title that seemed very out of place.
> IMO, the necessity is to balance "easy to look at" and "easy to use."
Indeed it is. And "looking" is only the most visible part of a web
page's life.
> Alan> It's disappointing just how few pages are making use of the
> Alan> simple <IMG ALIGN=LEFT|RIGHT ...> to inset an image into
> Alan> running text
..
> The "align" tags don't work in lynx -- that's a big problem.
I've never perceived it to be a problem. Lynx has its own way of
rendering a page, that's sometimes more appropriate for a character cell
browser than what emacs-w3 is doing when it solemnly tries to honour
layout-type markups, that were intended for laying out images that it
isn't displaying.
Once you have a feel for what Lynx is doing, it's possible to even take
advantage of it, rather than considering it to be a "big problem". IMO,
of course. Nobody's forced to consider Lynx: its users are accustomed
to "designed" pages looking like rodent droppings, and are only too glad
to get an honestly marked-up HTML page now and again.
> In
> addition, shifting font sizes will override the align setting. Or, to
> be more precise, if you have text with an image set to align=right and
> you increase the size of the font, you will push the image out of
> place.
How are tables better in that respect? As the authors of the HTML4 spec
noted, the use of tables for this purpose can put the browser into a
position where it has to use horizontal scrolling; that's something
which those who study user acceptability seem to have concluded is a big
minus (and, as a user, I can only agree with them).
> Well, maybe. To me, it seems like the objective is to make the
> content look good no matter what the person is doing on the other end
> with her browser.
That's the principle (using "look good" in a general sense, i.e not to
exclude speaking browsers or various kinds of indexing/ summarising/
translating/ whatever robots). But you don't achieve that by trying to
force the same appearance in every situation (that's impossible anyway),
but by exploiting HTML's ability to adapt the presentation to different
browsing situations. That's my plan, anyhow: I'm well aware that
there's a whole cottage industry of "web designers" out there who reject
this plan in favour of their pixel-exact triple-nested tables and
nbsp-stuffing and all.
> When I look at a web page, I look at it with the
> same "design-sense" I use when I look at the page of a book.
Sure, but books don't adapt themselves to the viewing situation.
[..]
> Another reason
> was because I wanted to learn how to use style sheets. That may have
> been a waste of money, they seem to be not universally supported,
> either.
The fact that they're not _supported_ by some browsers is a deliberate
design aim. Style sheets have been working for several years already,
in a couple of more specialised browsers. Those without support for
them just never knew they were there, unless they inspected the HTML
source.
More of a problem than browsers that don't support CSS at all, is those
browsers that aim to support them, but do it badly. Fact is, with the
mass-market browsers (just as with the earlier free stuff from NCSA and
others) we're all using what in any other field would be regarded as
alpha test versions. Before they get a chance to have the bugs cured,
it's time for the alpha versions of the next release, with a whole new
crop of bugs (and as often enough still with many of the same bugs that
were in the previous release). Still, it's a full life on the WWW.
all the best
Shawn K. Quinn - NO SOLICITING
| The "align" tags don't work in lynx -- that's a big problem.
They "don't work" on speech browsers either. Quite frankly, I'm quite
glad the ALIGN attributes (not tags, but attributes) "don't work" in
Lynx in this circumstance.
| In addition, shifting font sizes will override the align setting.
Theoretically, the user can override the align setting anyway.
| Or, to be more precise, if you have text with an image set to
| align=right and you increase the size of the font, you will push the
| image out of place.
This is due to a fault in the rendering engine in question. This isn't
HTML's (or CSS's) fault.
| Well, maybe. To me, it seems like the objective is to make the
| content look good no matter what the person is doing on the other end
| with her browser. When I look at a web page, I look at it with the
| same "design-sense" I use when I look at the page of a book.
The World Wide Web is not print. It is not even exclusively a visual
medium. There is no guarantee the browser will be a GUI client or that
it will even render content visually at all.
--
Shawn K. Quinn - skq...@wt.net - please consider visiting my home page
at http://purl.oclc.org/net/skquinn/personal
Geek code listed
Posting from a fake address is letting the spammers win
Michael Powe
Alan> On Sun, 19 Jul 1998, Michael Powe wrote:
Alan> It's disappointing just how few pages are making use of the
Alan> simple <IMG ALIGN=LEFT|RIGHT ...> to inset an image into
Alan> running text ..
>> The "align" tags don't work in lynx -- that's a big problem.
Alan> I've never perceived it to be a problem. Lynx has its own
Alan> way of rendering a page, that's sometimes more appropriate
Alan> for a character cell browser than what emacs-w3 is doing
Alan> when it solemnly tries to honour layout-type markups, that
Alan> were intended for laying out images that it isn't
Alan> displaying.
Well, it's a problem for lynx users when they have to view pages that
rely completely on the ALIGN setting. Of course, I know about the
problem and have pretty well adjusted my front page to counteract the
bad effects. Not all of my pages are "enhanced for lynx" ... yet.
Alan> Once you have a feel for what Lynx is doing, it's possible
Alan> to even take advantage of it, rather than considering it to
Alan> be a "big problem". IMO, of course. Nobody's forced to
Alan> consider Lynx: its users are accustomed to "designed" pages
Alan> looking like rodent droppings, and are only too glad to get
Alan> an honestly marked-up HTML page now and again.
"Navigation bars" are the bane of the lynx user. Dejanews is a good
example of a really badly designed front page.
>> In addition, shifting font sizes will override the align
>> setting. Or, to be more precise, if you have text with an
>> image set to align=right and you increase the size of the font,
>> you will push the image out of place.
Alan> How are tables better in that respect? As the authors of
Alan> the HTML4 spec noted, the use of tables for this purpose can
Alan> put the browser into a position where it has to use
Alan> horizontal scrolling; that's something which those who study
Alan> user acceptability seem to have concluded is a big minus
Alan> (and, as a user, I can only agree with them).
Hmm, well, my observation has been that the text-holding cell expands
vertically when the font size is increased. There may be an upper
limit to this that I have not observed.
>> When I look at a web page, I look at it with the same
>> "design-sense" I use when I look at the page of a book.
Alan> Sure, but books don't adapt themselves to the viewing
Alan> situation.
Of course, there are lots of design factors besides pictures.
Granted, the web is not a design-friendly space in the sense that I
can never see what you actually designed. Most of one's designing is
geared toward preventing the page from looking horrible under bizarre
circumstances. A sort of "negative capability" in the design sense is
required.
Alan> [..]
>> Another reason was because I wanted to learn how to use style
>> sheets. That may have been a waste of money, they seem to be
>> not universally supported, either.
Alan> The fact that they're not _supported_ by some browsers is a
Alan> deliberate design aim. Style sheets have been working for
Alan> several years already, in a couple of more specialised
Alan> browsers. Those without support for them just never knew
Alan> they were there, unless they inspected the HTML source.
My original idea was to use CSS to "regularize" and stabilize some of
the document design features. I guess this is what CSS is supposed to
be for. But, considering that most of what I have in mind for design
features will be irrelevant to the viewer (who will "do with it what
he will" and probably will not even see what I've done), it hardly
seems worth the bother.
Alan J. Flavell
> Alan> It's disappointing just how few pages are making use of the
> Alan> simple <IMG ALIGN=LEFT|RIGHT ...> to inset an image into
> Alan> running text ..
..
> Well, it's a problem for lynx users when they have to view pages that
> rely completely on the ALIGN setting.
In terms of writing HTML for the WWW, there is a massive difference
between "making use of" and "relying completely on". Until someone has
understood that difference, it's unlikely they will be making accessible
web pages. I sense that you already agree with this, but I just wanted
to spell it out in case of misunderstanding.
> Not all of my pages are "enhanced for lynx" ... yet.
I'm really rather queasy about this slogan "enhanced for lynx". I
prefer pages that are "enhanced for the WWW", so that they convey their
message in any WWW browsing situation - looking visually attractive when
that is a feasible option, and just being all-round helpful and
accessible when it isn't.