How to condense HTML source?

[Andy Dingley]

Chill out Dorkwad.

Ladies and Gentlemen !

A new winner and a personal best time for the killfile sprints !





(Actually I'm going to watch out for this idiot. Clueless and
fractious, he might be as much fun as Andkon)

 

[Hunter]

This page: http://www.soberrecovery.com/links/counselingandtherapy.html has
condensed HTML code. That is, when you VIEW SOURCE on the page, all
whitespace is removed and presumably this is done to make the file smaller
and display faster.

Are there any drawbacks to this? Can anyone refer me to a tool that
accomplishes this?

Drawbacks ? Of course - it's a complete waste of time.

White space being removed will have nothing to do with processing time - I
don't think you understand how a webpage is parsed by the browser.

 

[rblah]

Question: how is a few KB going to slow down the loading of a webpage?
Unless you have a 300 baud modem I just can't see how this is a problem.

Chris

A website without tables? I can't imagine a website except the simplest of
pages not using tables. But even just removing the <table> tags would only
amount to a few bytes. I'm looking to condense the entire HTML page saving
possibly thousands of bytes on larger pages.

Mark

 

[rblah]

Uh, may I just point out that you're the dork trying to save a few
thousand *bytes* on a webpage?

Sheesh.

Chris

 

[Barry Pearson]

Toby A Inkster wrote:
[snip]

Check out http://www.hardcandy.org/. And then try to replicate that
layout using table cells. AFAIK, can't be done.

Are you talking about the border?

It can be done, at least with some browsers. (Quick mock-up, HTML 4.01 Strict
& CSS validated at W3C):
http://www.barry.pearson.name/test/test.htm

Whether you would want to is another matter!

(And the above probably only works because I put the borders on the table
cells using CSS! I don't see things as "either tables or CSS". They are simply
techniques to be used separately or in combination to achieve what you want as
effectively as possible).

 

[Barry Pearson]

May I ask you which image editor do you use?

Photoshop 6.

If you go to the galleries (not the work in progress), the "info" link below
the photograph will show a page that gives some information about what I did
to the photograph, for example:

http://www.barry.pearson.name/photography/pictures/ch99/ch99_38_11_1.htm

 

[Steve Pugh]

Toby A Inkster wrote:
[snip]

Check out http://www.hardcandy.org/. And then try to replicate that
layout using table cells. AFAIK, can't be done.

Are you talking about the border?

And presumably the way the text flows within those borders.

It can be done, at least with some browsers. (Quick mock-up, HTML 4.01 Strict
& CSS validated at W3C):
http://www.barry.pearson.name/test/test.htm

The inside of Toby's original is a single div and thus text can just
be inserted in there and left to flow around the various boxed
intrusions. Consequently his versions adapts well to various window
and text sizes and there are no unnatural breaks within the content.

The inside of your version is 23 separate table cells. With a bit of
colspan and rowspan that can probably be reduced to 4 or 5 cells, but
still the content will have to be split up amongst those cells. The
table version is without a doubt less flexible.

Steve

 

[Leif K-Brooks]

Question: how is a few KB going to slow down the loading of a webpage?

I'm now using DSL, but I was lucky to get 3 KB per second back when I
had dialup. One extra second of load time will be noticed.

 

[Barry Pearson]

Yes - but only tabular data. To quote the HTML 4.01 specification:

"Tables should not be used purely as a means to layout document
content" -- http://www.w3.org/TR/html4/struct/tables.html#h-11.1

That is dated more than 6 years after the HTML+ proposal from Dave Raggett! It
is hardly an indication of the intent "from the start". That is what I was
talking about above - intent.

After the HTML+ statement, but before the one that you quote, came the HTML
3.2 Recommendation, which said: "Tables ... can be used to markup tabular
material or for layout purposes". And "A cell can contain a wide variety of
other block and text level elements including form fields and other tables".
(Do you think the concept of "tabular data" includes complex material like
headers, other tables, etc?)

At what date do you think people should have stopped using tables for layout?
In December 1999, the date on the document you quote?

The document you quote explained why it made that statement: ""Tables should
not be used purely as a means to layout document content as this may present
problems when rendering to non-visual media...." Then, nearly a year after
that was published, came this:

The W3C's HTML Techniques for Web Content Accessibility Guidelines 1.0:
"5.3 Do not use tables for layout unless the table makes sense when
linearized. Otherwise, if the table does not make sense, provide an
alternative equivalent (which may be a linearized version)."

"5.4 If a table is used for layout, do not use any structural markup for the
purpose of visual formatting."

The point I am making here is that whether people should or should not use
layout tables should be based on the consequences of doing so, not just on an
opinion some people (however clever) stated years before. And simple layout
tables have good characteristics. They do *not* become inaccessible just
because they are layout tables. They can be (very) flexible to viewport width.
If controlled by CSS, their presentation can easily be changed. They are not
large. They can be presented on a 240px screen using a suitable browser such
as Opera. They are well supported by a variety of browsers of various ages on
various platforms.

I have personally checked these characteristics, and I have also read the
accessibility guidelines, and what a book on the subject of accessibility
says.

 

[David Dorward]

That is dated more than 6 years after the HTML+ proposal from Dave
Raggett! It is hardly an indication of the intent "from the start". That
is what I was talking about above - intent.

I prefer the design after 6 years of additional experience then the early
version.

After the HTML+ statement, but before the one that you quote, came the
HTML 3.2 Recommendation, which said: "Tables ... can be used to markup
tabular material or for layout purposes". And "A cell can contain a wide
variety of other block and text level elements including form fields and
other tables". (Do you think the concept of "tabular data" includes
complex material like headers, other tables, etc?)

HTML 3.2 was not an attempt to design a good markup language. It was an
attempt to describe the state of 'HTML' after the browser wars.

At what date do you think people should have stopped using tables for
layout? In December 1999, the date on the document you quote?

Irrelevent. The state of the browser market _now_ is such that alternatives
are not feasable.

The document you quote explained why it made that statement: ""Tables
should not be used purely as a means to layout document content as this
may present problems when rendering to non-visual media...." Then, nearly
a year after that was published, came this:

The W3C's HTML Techniques for Web Content Accessibility Guidelines 1.0:
"5.3 Do not use tables for layout unless the table makes sense when
linearized. Otherwise, if the table does not make sense, provide an
alternative equivalent (which may be a linearized version)."

Yes, WCAG is overly 'pragmatic' for my tastes in some places - but note the
date at the top. In May 1999, support for CSS from user agents was poor.
Technology moves on and CSS is now a feasable layout tool.

 

[Kris]

Uh, may I just point out that you're the dork trying to save a few
thousand *bytes* on a webpage?

http://www.netmeister.org/news/learn2quote.html

 

[Barry Pearson]

Toby A Inkster wrote:
[snip]

Check out http://www.hardcandy.org/. And then try to replicate that
layout using table cells. AFAIK, can't be done.

Are you talking about the border?

And presumably the way the text flows within those borders.

I wasn't sure which aspect he was saying couldn't be achieved with table
cells. He said "... replicate that layout ...". My guess was that he felt that
the border was the impossible part.

(I only did what I showed to see if I sort out the border quickly. I certainly
have no wish to replicate it in full!)

The inside of Toby's original is a single div and thus text can just
be inserted in there and left to flow around the various boxed
intrusions. Consequently his versions adapts well to various window
and text sizes and there are no unnatural breaks within the content.

I wouldn't recommend doing it the table way. But he issued a challenge!

The inside of your version is 23 separate table cells. With a bit of
colspan and rowspan that can probably be reduced to 4 or 5 cells, but
still the content will have to be split up amongst those cells. The
table version is without a doubt less flexible.

(23?) Indeed. I think he has a very attractive and effective layout, and
wouldn't put tables foreward as an alternative. But sometimes it is
interesting to play with ideas.

Personally, I think one of my own layouts (below) may be even harder to
achieve with table cells, but I guess there are people who could do it in
minutes!

http://www.barry.pearson.name/articles/templates/extra_effects.htm

 

[Barry Pearson]

Barry Pearson wrote: [snip]

The W3C's HTML Techniques for Web Content Accessibility Guidelines
1.0: "5.3 Do not use tables for layout unless the table makes sense
when linearized. Otherwise, if the table does not make sense,
provide an alternative equivalent (which may be a linearized
version)."

Yes, WCAG is overly 'pragmatic' for my tastes in some places - but
note the date at the top. In May 1999, support for CSS from user
agents was poor. Technology moves on and CSS is now a feasable layout
tool.

It is a poor tool. See "Reflections on CSS Positioning":

http://www.barry.pearson.name/articles/layout_tables/css_positioning.htm

 

[David Dorward]

It is a poor tool. See "Reflections on CSS Positioning":

http://www.barry.pearson.name/articles/layout_tables/css_positioning.htm

I gave up after "Simple photograph pages" since:

(a) I don't see how it relates to CSS positioning (which the document claims
to be about specifically)

and

(b) Its still less markup then tables!

 

[Steve Pugh]

I wasn't sure which aspect he was saying couldn't be achieved with table
cells. He said "... replicate that layout ...". My guess was that he felt that
the border was the impossible part.

(I only did what I showed to see if I sort out the border quickly. I certainly
have no wish to replicate it in full!)

As your proved, the border on its own is easy and I'm sure Toby knows
that so I think that his challenge was to recreate the text flow as
well.

Personally, I think one of my own layouts (below) may be even harder to
achieve with table cells, but I guess there are people who could do it in
minutes!

http://www.barry.pearson.name/articles/templates/extra_effects.htm

Hmm, I reckon I could do that in tables. Probably would'nt need more
than one level of nesting as well.

However, I also think I could do this layout of mine (excuse the
colour scheme): http://steve.pugh.net/vtt/ with tables. It sure
wouldn't be nice though. I was working on commercial web sites back in
1998 so I've loads of practice at building very complex layouts with
tables.

Steve

 

[Spartanicus]

It is a poor tool. See "Reflections on CSS Positioning":

http://www.barry.pearson.name/articles/layout_tables/css_positioning.htm

Creating a visual layout using a grid with CSS floats and positioning is
indeed complex, but this is not a deficiency of CSS. It's possible with
CSS2 to create visual layouts with almost the same ease as with tables:
by using CSS tables.

Problem: IE doesn't support them. Had that been the case then we
wouldn't have nearly as much moaning about how difficult CSS is,
Dreamweaver and perhaps even Frontpage (spit) would probably have used
it instead of HTML tables.

 

[Toby A Inkster]

As your proved, the border on its own is easy and I'm sure Toby knows
that so I think that his challenge was to recreate the text flow as
well.

Well yes, the combination of the two really. It is easy enough to do a
border using tables. Easier still to just use a giant image for a border
and be done with it.

I was referring to the way the text could flow within a jagged border.

 

[Lauri Raittila]

That is dated more than 6 years after the HTML+ proposal from Dave Raggett! It
is hardly an indication of the intent "from the start". That is what I was
talking about above - intent.

Well, html never was well thought, and all kinds of ideas, mostly stupid,
have been already forgotten.

After the HTML+ statement, but before the one that you quote, came the HTML
3.2 Recommendation, which said: "Tables ... can be used to markup tabular
material or for layout purposes".

I already quoted you that HTML3.2 also states that it should not be done.

The point I am making here is that whether people should or should not use
layout tables should be based on the consequences of doing so, not just on an
opinion some people (however clever) stated years before. And simple layout
tables have good characteristics. They do *not* become inaccessible just
because they are layout tables. They can be (very) flexible to viewport width.
If controlled by CSS, their presentation can easily be changed. They are not
large. They can be presented on a 240px screen using a suitable browser such
as Opera. They are well supported by a variety of browsers of various ages on
various platforms.

You say same thing again and again. *plonk*. The fact is that tables are
not meant for layot, and that it causes problems. Other fact, that it is
sometimes sencible to use table layout, as there is no other suitable
tool, doesn't make it right thing to do.

 

[rblah]

http://www.netmeister.org/news/learn2quote.html

OK.

 

[Michael Fesser]

You say same thing again and again. *plonk*. The fact is that tables are
not meant for layot

A table is meant for layout by definition, it's a layout for presenting
data in a tabular form. It only depends on how one defines 'data' ...
(IMHO)

and that it causes problems.

And these problems actually are ... ?

Micha