Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #10419 > unrolled thread

Shrinking the width of a WIDTH=100% table

Back to article view | Back to comp.lang.javascript

Contents

  Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-20 14:04 +0000
    Re: Shrinking the width of a WIDTH=100% table Captain Paralytic <paul_lautman@yahoo.com> - 2012-01-20 06:20 -0800
    Re: Shrinking the width of a WIDTH=100% table "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-01-20 17:04 +0200
      Re: Shrinking the width of a WIDTH=100% table Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 16:35 +0100
        Re: Shrinking the width of a WIDTH=100% table "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-01-20 19:45 +0200
        Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-20 18:49 +0000
      Re: Shrinking the width of a WIDTH=100% table "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-01-22 13:57 -0800
    Re: Shrinking the width of a WIDTH=100% table Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-20 22:17 +0100
      Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-21 06:28 +0000
        Re: Shrinking the width of a WIDTH=100% table "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-01-21 11:07 +0000
        Re: Shrinking the width of a WIDTH=100% table Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-21 19:52 +0100
          Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-22 06:54 +0000
            Re: Shrinking the width of a WIDTH=100% table Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-22 14:06 +0100
              Re: Shrinking the width of a WIDTH=100% table "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-01-22 15:17 +0200
              Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-23 06:52 +0000
                Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-23 07:10 +0000
                Re: Shrinking the width of a WIDTH=100% table Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-23 16:36 +0100
    Re: Shrinking the width of a WIDTH=100% table Dr J R Stockton <reply1203@merlyn.demon.co.uk> - 2012-01-21 20:50 +0000
      Re: Shrinking the width of a WIDTH=100% table Swifty <steve.j.swift@gmail.com> - 2012-01-22 06:42 +0000

#10419 — Shrinking the width of a WIDTH=100% table

I have a CGI script that builds a table with "WIDTH=100%"

There are many paths through the code, but they all required the table
to be WIDTH=100%

Now, I find that in just one of the paths, it would be better if that
WIDTH=100% had not been specified.

Is there any JavaScript that I can insert, after the <TABLE> has
already been started, which  will remove the effect of the WIDTH=100% 

I'm open to a CSS solution as well, but there are other tables in the
same page which must remain WIDTH=100% so it would have to be specific
to just this one table.

N.B. My environment ensures that all users will have JavaScript
enabled.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [next] | [standalone]

#10420

On Jan 20, 2:04 pm, Swifty <steve.j.sw...@gmail.com> wrote:
> I have a CGI script that builds a table with "WIDTH=100%"
>
> There are many paths through the code, but they all required the table
> to be WIDTH=100%
>
> Now, I find that in just one of the paths, it would be better if that
> WIDTH=100% had not been specified.
>
> Is there any JavaScript that I can insert, after the <TABLE> has
> already been started, which  will remove the effect of the WIDTH=100%
>
> I'm open to a CSS solution as well, but there are other tables in the
> same page which must remain WIDTH=100% so it would have to be specific
> to just this one table.
>
> N.B. My environment ensures that all users will have JavaScript
> enabled.
>
> --
> Steve Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk

Why not alter it in that one specific path through the cgi code?

[toc] | [prev] | [next] | [standalone]

#10421

2012-01-20 16:04, Swifty wrote:

> Is there any JavaScript that I can insert, after the <TABLE>  has
> already been started, which will remove the effect of the WIDTH=100%

Yes. I suppose you have considered the obvious solution of not writing 
WIDTH=100% for a specific table, and I suppose the reason for rejecting 
that idea is in the logic of your server-side code: you're in the midst 
of writing data when you find out that something should have been done 
earlier.

Using JavaScript, you could change the width property of the <table> 
element. For this, you could e.g. emit an empty <span> element with an 
id so that appears inside a cell of the table, then traverse the 
document tree upwards until you find the <table> element:

<table width="100%" border>
<tr><td>Hello world <td>Hello again
<tr><td>Foo <td> Bar
<span id="foo"></span>
<script>
var el = document.getElementById('foo');
do {
   el = el.parentNode;
   } while (el.tagName != 'TABLE');
el.width = '';
</script>
</table>

(So the <span> and <script> elements are what you would need to add to 
the generated markup. The identifier 'foo' can be anything as long as it 
is unique within the document.)

> I'm open to a CSS solution as well, but there are other tables in the
> same page which must remain WIDTH=100% so it would have to be specific
> to just this one table.

You cannot validly emit CSS code that would affect the table that has 
been started. No style attribute can do that. A <style> element would, 
but it's invalid in <body> (though browsers allow it, to the extent that 
it might even be declared a feature). And to make a CSS rule apply to a 
specific table, you would probably need a class attribute on it, but I 
suppose it would be too late to emit one.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#10422

On 1/20/2012 4:04 PM, Jukka K. Korpela wrote:
> 2012-01-20 16:04, Swifty wrote:
>
>> Is there any JavaScript that I can insert, after the <TABLE> has
>> already been started, which will remove the effect of the WIDTH=100%
>
> Yes. I suppose you have considered the obvious solution of not writing
> WIDTH=100% for a specific table, and I suppose the reason for rejecting
> that idea is in the logic of your server-side code: you're in the midst
> of writing data when you find out that something should have been done
> earlier.
>
> Using JavaScript, you could change the width property of the <table>
> element. For this, you could e.g. emit an empty <span> element with an
> id so that appears inside a cell of the table, then traverse the
> document tree upwards until you find the <table> element:
>
> <table width="100%" border>
> <tr><td>Hello world <td>Hello again
> <tr><td>Foo <td> Bar
> <span id="foo"></span>
> <script>
> var el = document.getElementById('foo');
> do {
> el = el.parentNode;
> } while (el.tagName != 'TABLE');
> el.width = '';
> </script>
> </table>

Why not simply give the table an id and use that?

Regards,
Erwin Moller


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#10427

2012-01-20 17:35, Erwin Moller wrote:

> On 1/20/2012 4:04 PM, Jukka K. Korpela wrote:
[...]
 >> I suppose you have considered the obvious solution of not writing
>> WIDTH=100% for a specific table, and I suppose the reason for rejecting
>> that idea is in the logic of your server-side code: you're in the midst
>> of writing data when you find out that something should have been done
>> earlier.
[...]
> Why not simply give the table an id and use that?

Because you cannot do that when you have already generated the <table> 
tag and a few rows.
Or, you could do that by operating in the document tree, but this would 
be just
a more complicated version of doing what I suggested.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#10440

On Fri, 20 Jan 2012 16:35:43 +0100, Erwin Moller
<erwinmollerusenet@xs4all.nl> wrote:

>Why not simply give the table an id and use that?

I couldn't have put that better myself. I'll explain a little further
(albeit still simplified):

At the beginning of my CGI, I create the table. There are other tables
making up the header and the footer, but the body of the table
contains only the one. THE table. After the table has started, the
code can take myriad paths, resulting in different rows. One of these
paths would look better without the WIDTH=100%

So I can easily make this something like:

<TABLE WIDTH=100% ID=Body_Table>

Presumably I need some GetElementByID call, and then I'll be all set. 

I have a GetElementByID call somewhere in the pages that I look after;
I'll use that as my working example.

I've had too good a day to risk spoiling it by an utter failure in my
JavaScript, but I'll try it over the weekend.

Today:

1. My dog, Nelly, found my bluetooth earpiece that I lost yesterday,
about 800m away from where I live. http://www.swiftys.org.uk/blog

2. I found the fragment of the tooth that broke four days ago. I
thought that I must have swallowed it, and was worried that it might
do me some harm. I had swallowed it. I won't go into further details.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#10498

On Jan 20, 9:04 am, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> A <style> element would,
> but it's invalid in <body> (though browsers allow it, to the extent that
> it might even be declared a feature).

Scoped styles are defined in HTML 5:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/
semantics.html#attr-style-scoped>

[toc] | [prev] | [next] | [standalone]

#10448

Swifty wrote:

> I have a CGI script that builds a table with "WIDTH=100%"

First of all, CGI is an obsolete technology [1].  Use server extensions or 
FastCGI [2] instead.

> There are many paths through the code, but they all required the table
> to be WIDTH=100%

Second, do not do that.  Learn and apply CSS instead [3].
 
> Now, I find that in just one of the paths, it would be better if that
> WIDTH=100% had not been specified.
> 
> Is there any JavaScript that I can insert, after the <TABLE> has
> already been started, which  will remove the effect of the WIDTH=100%

Since the `width' attribute has no specified default value [4], the only 
proper way is to program what you would do manually: remove the attribute.

  elem.removeAttribute("width");

However, if you had used CSS, you could have reset the `width' property to 
its specified initial value [3, 5]:

  elem.style.width = "auto";


PointedEars
___________
[1] <http://en.wikipedia.org/wiki/Common_Gateway_Interface#Drawbacks>
[2] <http://www.fastcgi.com/drupal/>
[3] <http://www.w3.org/TR/CSS21/visudet.html#propdef-width>
[4] <http://www.w3.org/TR/html4/struct/tables.html#adef-width-TABLE>
[5] <http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties>
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#10451

On Fri, 20 Jan 2012 22:17:02 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>However, if you had used CSS, you could have reset the `width' property to 
>its specified initial value [3, 5]:
>
>  elem.style.width = "auto";

I'm happy to convert to CSS if that helps. It means having to make two
changes, where perhaps one change would have been sufficient. I'm
under time constraint... I have only 363 working days left in my
career.

So, as you see, CGI is an appropriate obsolete technology for me, as
both I and my skill will be obsolete next year.

I'm going for a record in the IT industry. When I joined the company
that I work for in 1976, the programming language that I use was in
the early stages of its development, and some of my suggestions were
incorporated. I've now been programming in that language for 35 years
and 26 days; effectively doing the same job throughout that time.

This, for me, is the attraction of building webpages with CGI. It
hardly matters what programming language you use. 

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#10452

Swifty wrote on 21 jan 2012 in comp.lang.javascript:

> On Fri, 20 Jan 2012 22:17:02 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>>However, if you had used CSS, you could have reset the `width'
>>property to its specified initial value [3, 5]:
>>
>>  elem.style.width = "auto";
> 
> I'm happy to convert to CSS if that helps. It means having to make two
> changes, where perhaps one change would have been sufficient. I'm
> under time constraint... I have only 363 working days left in my
> career.
> 
> So, as you see, CGI is an appropriate obsolete technology for me, as
> both I and my skill will be obsolete next year.
> 
> I'm going for a record in the IT industry. When I joined the company
> that I work for in 1976, the programming language that I use was in
> the early stages of its development, and some of my suggestions were
> incorporated. I've now been programming in that language for 35 years
> and 26 days; effectively doing the same job throughout that time.
> 
> This, for me, is the attraction of building webpages with CGI. It
> hardly matters what programming language you use. 

While I grand you your personal hobbies in your career,
you do not respond on the part of PE's posting you quote above.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#10455

Swifty wrote:

> Thomas 'PointedEars' Lahn wrote:
>> However, if you had used CSS, you could have reset the `width' property
>> to its specified initial value [3, 5]:
>>
>>   elem.style.width = "auto";
> 
> I'm happy to convert to CSS if that helps. It means having to make two
> changes, where perhaps one change would have been sufficient. I'm
> under time constraint... I have only 363 working days left in my
> career.

Please read my posting again, and whole this time.

> [snipped autobiography]


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#10464

On Sat, 21 Jan 2012 19:52:40 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Please read my posting again, and whole this time.

While I appreciate the effort you went to, I've never read anything in
its entirety in my life. I read the bits that interested me, ignored
the parts that I've already discounted (for practical reasons) and
skimmed the rest.

The largest practical reason is that I have only 363 working days
before I retire. A number of the projects that I've worked on over the
past 35 years still require my presence in order to continue
functioning properly, and fixing that will consume about 362 of my
remaining days.

So, these days, I'm only ever looking for the "quick fix".

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#10469

Swifty wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Please read my posting again, and whole this time.
> 
> […]
> So, these days, I'm only ever looking for the "quick fix".

You must be getting senile already.  The quick fix is in my posting!


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#10471

2012-01-22 15:06, Thomas 'PointedEars' Lahn trolled:

> You must be getting senile already.

I would rather be senile than a troll or a person who publicly insults 
people for senility.

 > The quick fix is in my posting!

Your posting was your usual pointless lecturing on irrelevant things, 
and your "quick fix" simply did not address the problem that was 
presented. Almost anyone (even you) could solve the problem that you 
addressed, but the problem posed was something quite different - not at 
all the extremely trivial problem about which you gave a long lecture.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#10500

On Sun, 22 Jan 2012 14:06:51 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>You must be getting senile already.  The quick fix is in my posting!

Apparently it starts at 37 (or is it 45? I don't recall exactly; it
was in the news recently), so how close are you? :-)

Yes, I saw your answer, and in all probability I will use it. Thank
you.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#10501

On Mon, 23 Jan 2012 06:52:56 +0000, Swifty <steve.j.swift@gmail.com>
wrote:

>I saw your answer, and in all probability I will use it.

Well, the gods are smiling on me today, with the FAQ article being on
getting the element from the ID. It was a sign, so I went and
implemented this solution.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [next] | [standalone]

#10508

Swifty wrote:

> On Sun, 22 Jan 2012 14:06:51 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> You must be getting senile already.  The quick fix is in my posting!

And I do _not_ mean using CSS instead.

> Apparently it starts at 37 (or is it 45? I don't recall exactly; it
> was in the news recently), so how close are you? :-)

Too close to those figures, I'm afraid ;-)

> Yes, I saw your answer, and in all probability I will use it. Thank
> you.

You are welcome.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#10461

In comp.lang.javascript message <8nsih7pjdunj21096qub8tnr1mluk2bons@4ax.
com>, Fri, 20 Jan 2012 14:04:31, Swifty <steve.j.swift@gmail.com>
posted:

>I have a CGI script that builds a table with "WIDTH=100%"
>
>There are many paths through the code, but they all required the table
>to be WIDTH=100%
>
>Now, I find that in just one of the paths, it would be better if that
>WIDTH=100% had not been specified.
>
>Is there any JavaScript that I can insert, after the <TABLE> has
>already been started, which  will remove the effect of the WIDTH=100%
>
>I'm open to a CSS solution as well, but there are other tables in the
>same page which must remain WIDTH=100% so it would have to be specific
>to just this one table.
>
>N.B. My environment ensures that all users will have JavaScript
>enabled.


That suggests to me that your CGI is emitting the table piece-by-piece,
which makes it harder to change what has already been sent.

Perhaps you can instead collect the table within the CGI as a string, or
as an array of strings later joined, and send it out from CGI only when
you can no longer want to change it.  You can then alter the width in
the table within the CGI, before sending.

Conceivably, your code could be clearer if the table were contained
within a div, and that of size 100% or not - or otherwise.


-- 
 (c) John Stockton, nr London UK.  ?@merlyn.demon.co.uk  DOS 3.3 6.20 ; WinXP.
   Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
   PAS EXE TXT ZIP via  <http://www.merlyn.demon.co.uk/programs/00index.htm>
   My DOS  <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.

[toc] | [prev] | [next] | [standalone]

#10463

On Sat, 21 Jan 2012 20:50:14 +0000, Dr J R Stockton
<reply1203@merlyn.demon.co.uk> wrote:

>Perhaps you can instead collect the table within the CGI as a string, or
>as an array of strings later joined, and send it out from CGI only when
>you can no longer want to change it.  You can then alter the width in
>the table within the CGI, before sending.

I use that technique, but for other reasons. It is best done from the
outset; retrofitting it to a working program is harder.

The other reason is performance. Most of my CGI scripts generate quite
small pages, but some of them generate pages greater than 1MB of HTML.

If I create the 1MB page using 10,000 statements like:

Say '<TABLE tag that is 100 characters>' 

...then the transfer rate between the apache server and my browser is
often as little as 20KBps.

If I buffer the individual lines, then I achieve the full transfer
rate that my ADSL connection provides. However, it can take a long
time to fill this buffer, and in the meantime the page seems
unresponsive.

So, I take a compromise; I buffer the lines, but limit the buffer to
about 10KB. 

I've often wondered what slows the transfer rate when I'm sending
small chunks; presumably some inefficiency in the IP protocol when
faced with small transmissions.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web