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

Idea: Abbreviated HTML

P: n/a
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.

HTML is very verbose - this was important to its adoption, as reading
source from existing pages is one of the fastest ways to learn it -
and descriptive clear tagging is key to that.

However, there is an argument for a more concise tagging system as
well, one which can be very easily converted to and from regular html
easily.

The advantages are twofold: less typing and less bandwidth.

Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.

Recently they made some substantial changes in their new homepage
which reduced bandwidth even further.

Approaching this agressively, rarely used symbols could replace the
most common tags, and those symbols would be replaced with encoding.
Also, default expansion could be used.

As an example, $yahoo$ could be used in place of a full anchor tag to
a www.*.com site, and closed with a single $. Real dollar signs, which
dont appear on most web pages, could be replaced with encoding.

Another approach would allow constants to be set on an HTML page:

SET $l="<A HREF="http://www.yahoo.com">
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">

I guess style sheets and Javascript address some of this, but neither
is as efficient as having it built in.

Another idea would be to make whitespace significant, including
newlines.

Finally, the author would not necessarily need to author in AHTML, but
could instead simply configure the web server to convert it on the way
out, similar to mod_gzip (which I use and think is great!).

Anyways, just an idea...
Jul 23 '05 #1
Share this Question
Share on Google+
40 Replies


P: n/a
br**********@hotmail.com (Seth Brundle) wrote:
Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.


Are you taking the piss or something?

Yahoo's index page can probably be slashed down to 1/4 of it's current
size by replacing the 1996 presentational html with a css based layout.

--
Spartanicus
Jul 23 '05 #2

P: n/a
On 7 Oct 2004 15:05:03 -0700, Seth Brundle <br**********@hotmail.com>
wrote:
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.

HTML is very verbose - this was important to its adoption, as reading
source from existing pages is one of the fastest ways to learn it -
and descriptive clear tagging is key to that.

However, there is an argument for a more concise tagging system as
well, one which can be very easily converted to and from regular html
easily.

The advantages are twofold: less typing and less bandwidth.
Fot the less typing problem, consider SSI or PHP includes. This will still
send the full HTML to the UA, however.
Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.
They also create these pages with software, so no human has to read it.
Most of us do not do it that way.
Approaching this agressively, rarely used symbols could replace the
most common tags, and those symbols would be replaced with encoding.
Also, default expansion could be used.
This would require a totally new formulation. Interesting, but I doubt the
savings would be enough to get it to catch on...
As an example, $yahoo$ could be used in place of a full anchor tag to
a www.*.com site, and closed with a single $. Real dollar signs, which
dont appear on most web pages, could be replaced with encoding.
How will the browser be informed? I think you address this below
Another approach would allow constants to be set on an HTML page:

SET $l="<A HREF="http://www.yahoo.com">
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">
But all this must be sent to the UA. It requires more bytes to do this
than to simply include the link, unless you're repeating the link all over
the place, and why do that?

CSS already handles the repetitive style rules quite adequately, so your
second example isn't needed.
I guess style sheets and Javascript address some of this, but neither
is as efficient as having it built in.
Disagree. The best part of style and script is that they are optional. A
properly designed page functions even if the UA interprets the HTML file
alone, with no images, stylesheets, scripts, or anything else.
Another idea would be to make whitespace significant, including
newlines.
How will this reduce bandwidth and human readability?
Finally, the author would not necessarily need to author in AHTML,
.... negating the less typing benefit...
but
could instead simply configure the web server to convert it on the way
out, similar to mod_gzip (which I use and think is great!).


Well, I suppose there are possibilities here, but all told, the savings of
bandwidth and typing won't be sufficient to sell this idea in most
applications of HTML, IMO.
Jul 23 '05 #3

P: n/a
Seth Brundle wrote:
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.


HTML (not XHTML) allows certain SGML features for less verbosity; for
instance, <p/foo/ is equivalent to <p>foo</p>. In practice, however,
browser support is virtually non-existant.

With XHTML, you could define a custom DTD that had shorter element and
attribute names (<bq> might be used instead of <blockquote>, for
example) and use client-side XSLT to transform it back to standard
XHTML. But again, browser support is poor; also, the processing speed
would probably outweigh any speed gained from bandwidth savings.

If you're only interested in less typing and don't care about the
possible bandwidth savings, you could write an Apache module to
translate your abbreviated HTML into standard HTML before sending it to
the client.
Jul 23 '05 #4

P: n/a
Leif K-Brooks <eu*****@ecritters.biz> wrote:
With XHTML, you could define a custom DTD that had shorter element and
attribute names


For some values of "XHTML", yes. But a document that conforms to
XHTML 1.0 or XHTML 1.1 (the currently defined versions of XHTML) must, by
definition, have a DOCTYPE declaration that refers to one of given three
DTDs (for XHTML 1.0) or a given DTD (for XHTML 1.1).

Contrary to popular belief, XHTML is (at least currently) by definition
not extensible in any meaningful sense. New specifications can be written
of course, just as old HTML was "extended" by new specifications. And you
can write an XML document that contains some tags that you would like to
have interpreted as in HTML, just as you could write an SGML document
with a mixture of tags, some from HTML.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #5

P: n/a
Leif K-Brooks eu*****@ecritters.biz wrote:
Seth Brundle wrote:
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.


HTML (not XHTML) allows certain SGML features for less verbosity; for
instance, <p/foo/ is equivalent to <p>foo</p>. In practice, however,
browser support is virtually non-existant.

With XHTML, you could define a custom DTD that had shorter element and
attribute names (<bq> might be used instead of <blockquote>, for
example) and use client-side XSLT to transform it back to standard
XHTML. But again, browser support is poor; also, the processing speed
would probably outweigh any speed gained from bandwidth savings.

If you're only interested in less typing and don't care about the
possible bandwidth savings, you could write an Apache module to
translate your abbreviated HTML into standard HTML before sending it to
the client.


Who actually types any? Surely mostly one just cuts and pastes from
existing html. Pretty much all I ever actually type are specifications for
size or colour, and I'd still have to do that.

--
eric
www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Jul 23 '05 #6

P: n/a
In comp.infosystems.www.authoring.html Eric Jarvis said:
Who actually types any? Surely mostly one just cuts and pastes from
existing html.


how primitive. i just think about it really hard whilst looking at the
monitor. i use a similar technology for my newsreader.

--
i t ' s t h e l i t t l e v o i c e s
Jul 23 '05 #7

P: n/a
In article <53**************************@posting.google.com >,
br**********@hotmail.com says...
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.
Well, it is already in spec...

Some valid HTML:

<h1/heading/<p>Content<table border left><tr><th nowrap>1<th>2<tr><td
right>2<td>3</table><a href="a"/a/<ul/<li>foo/

Very nice to read, isn't it.
HTML is very verbose - this was important to its adoption, as reading
source from existing pages is one of the fastest ways to learn it -
and descriptive clear tagging is key to that.
In fact, HTML is far from verbose. XHTML is somewhat. But compare HTML to
anything but plain text, and you see...
However, there is an argument for a more concise tagging system as
well, one which can be very easily converted to and from regular html
easily.
Already exists.
The advantages are twofold: less typing and less bandwidth.
Bandwich is much easier to safe using other means. And bandwith of HTML
is most cases neglible compared to images and other fancy stuff.

Typing takes more time when you need to think more. If you are typing
using one finger, learn to use some more.
Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.
It would be easy to get rid of 90% of bandwidth yahoo uses already, and
also make the site work better on same time...

If bandwith would really cost lots of money, why all the graphics?
Approaching this agressively, rarely used symbols could replace the
most common tags, and those symbols would be replaced with encoding.
Also, default expansion could be used.
How about gzipping everything? All browsers support it already, and
nobody would need to invent anything?
As an example, $yahoo$ could be used in place of a full anchor tag to
a www.*.com site, and closed with a single $. Real dollar signs, which
dont appear on most web pages, could be replaced with encoding.
And what is often used code and what not?
Another approach would allow constants to be set on an HTML page:

SET $l="<A HREF="http://www.yahoo.com">
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">
Well, first is useless as there is no need for many links to same place
on one webpage, and second should be handled using CSS. (or better,
leaved out)
Finally, the author would not necessarily need to author in AHTML, but
could instead simply configure the web server to convert it on the way
out, similar to mod_gzip (which I use and think is great!).


Why do you think your idea would produce less bits to send than using
mod_gzip? After all, it compresses the *content* too. And I bet it will
be much less efficient when there is your shortstuff included with their
fancy special chars...

I think you should try learn some basics of technics, before making
yourself more dumm on public forum...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Jul 23 '05 #8

P: n/a
On Fri, 8 Oct 2004 08:54:54 +1000, brucie <sh**@usenetshit.info> wrote:
In comp.infosystems.www.authoring.html Eric Jarvis said:
Who actually types any? Surely mostly one just cuts and pastes from
existing html.


how primitive. i just think about it really hard whilst looking at the
monitor. i use a similar technology for my newsreader.


Have you abandoned the stick and dirt method?
Jul 23 '05 #9

P: n/a
On Fri, 8 Oct 2004 08:54:54 +1000, brucie <sh**@usenetshit.info>
declared in comp.infosystems.www.authoring.html:
how primitive. i just think about it really hard whilst looking at the
monitor. i use a similar technology for my newsreader.


I notice you haven't got uppercase letters working yet. How's that
coming along?

--
Mark Parnell
http://www.clarkecomputers.com.au
Jul 23 '05 #10

P: n/a
Jukka K. Korpela wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote:

With XHTML, you could define a custom DTD that had shorter element and
attribute names

For some values of "XHTML", yes. But a document that conforms to
XHTML 1.0 or XHTML 1.1 (the currently defined versions of XHTML) must, by
definition, have a DOCTYPE declaration that refers to one of given three
DTDs (for XHTML 1.0) or a given DTD (for XHTML 1.1).


Sorry about that, you're right. What I really meant to was was "with the
help of XHTML", since XHTML would be needed as the output medium of our
XSLT stylesheet, but I didn't make that clear enough.
Jul 23 '05 #11

P: n/a
On 7/10/04 11:05 pm, Seth Brundle wrote:
less typing
Use external CSS files.
and less bandwidth


Use mod_gzip.

--
Philip Ronan
ph***********@virgin.net
(Please remove the "z"s if replying by email)
Jul 23 '05 #12

P: n/a
begin quote from Seth Brundle in
<53**************************@posting.google.com >:
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.
Why do we need one? I fail to see it based on what you write below.
HTML is very verbose - this was important to its adoption, as reading
source from existing pages is one of the fastest ways to learn it -
and descriptive clear tagging is key to that.

However, there is an argument for a more concise tagging system as
well, one which can be very easily converted to and from regular html
easily.

The advantages are twofold: less typing and less bandwidth.
Less typing? Learn to use keyboard shortcuts. Up to a point, I fail to see a
need to conserve keystrokes, I mean, it's not like the little keys will
bite you if you press them too many times.

Less bandwidth? That's what mod_gzip and such things are for.
Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.
Last I checked, they actually broke the rules, they didn't just bend them.
Approaching this agressively, rarely used symbols could replace the
most common tags, and those symbols would be replaced with encoding.
Also, default expansion could be used.
At the expense of readability.
As an example, $yahoo$ could be used in place of a full anchor tag to
a www.*.com site, and closed with a single $.
What about sites that don't reside on a www hostname, or don't reside in the
com top-level domain? You save maybe 4 characters at the expense of a lot
of readability, on an ever-smaller portion of the total number of
hostnames.

There are protocols besides HTTP, too.
Real dollar signs, which dont appear on most web pages, could be replaced
with encoding.
Huh? Where have you been? Every shopping site will use *plenty* of them.
Another approach would allow constants to be set on an HTML page:

SET $l="<A HREF="http://www.yahoo.com">
How many times would you want to link to the exact same URL?
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">
This is presentational HTML, deprecated in HTML 4.0, and should now be
considered obsolete, or at best very nearly obsolete.
I guess style sheets and Javascript address some of this, but neither
is as efficient as having it built in.
Neither can be completely relied upon, either.
Another idea would be to make whitespace significant, including
newlines.
Ugh. Why?
Finally, the author would not necessarily need to author in AHTML, but
could instead simply configure the web server to convert it on the way
out, similar to mod_gzip (which I use and think is great!).
I don't see how this hackish bastardization of HTML would gain you any
significant bandwidth savings over mod_gzip.
Anyways, just an idea...


You strike me as the sort of person who would have conceived idiotbabble if
it didn't already exist. (Idiotbabble is what I call this unreadable
garbage some people who are afraid to actually use the keyboard use in chat
and even blog/Livejournal entries.)

I see this idea as a misguided solution to the wrong problems. You need to
find the *real* problems you're looking to solve, and fix *those* while not
breaking existing software that is not hip to this HTML-in-a-blender hack
job which you conceive.

--
Shawn K. Quinn
Jul 23 '05 #13

P: n/a
Spartanicus <me@privacy.net> wrote in message news:<9k********************************@news.spar tanicus.utvinternet.ie>...
br**********@hotmail.com (Seth Brundle) wrote:
Yahoo!, for example, scrutinizes every byte used in their high-traffic
homepage, and bends rules and abbreviates URLs so that the page is
still parseable in every browser but very, very low bandwidth.


Are you taking the piss or something?

Yahoo's index page can probably be slashed down to 1/4 of it's current
size by replacing the 1996 presentational html with a css based layout.


Um, their new homepage is a CSS-based layout.
Jul 23 '05 #14

P: n/a
On 8 Oct 2004 09:51:38 -0700, Seth Brundle <br**********@hotmail.com>
wrote:
Spartanicus <me@privacy.net> wrote in message
news:<9k********************************@news.spar tanicus.utvinternet.ie>...
br**********@hotmail.com (Seth Brundle) wrote:
>Yahoo!, for example, scrutinizes every byte used in their high-traffic
>homepage, and bends rules and abbreviates URLs so that the page is
>still parseable in every browser but very, very low bandwidth.


Are you taking the piss or something?

Yahoo's index page can probably be slashed down to 1/4 of it's current
size by replacing the 1996 presentational html with a css based layout.


Um, their new homepage is a CSS-based layout.


Barely.

<style type="text/css"><!--
..yhmpabd{border-left:solid #4d99e5 1px;border-right:solid #4d99e5
1px;border-bottom:solid #4d99e5 1px;}
..yhmnwbd{border-left:solid #9b72cf 1px;border-right:solid #9b72cf 1px;}
..yhmnwbm{border-left:solid #9b72cf 1px;border-right:solid #9b72cf
1px;border-bottom:solid #9b72cf 1px;}
//--></style>

That's the CSS, folks. The rest is table layout and font tags.
Jul 23 '05 #15

P: n/a
In <53**************************@posting.google.com >, on 10/07/2004
at 03:05 PM, br**********@hotmail.com (Seth Brundle) said:
HTML is very verbose
There are several reasons for that.

First, it is a character-oriented protocol. That automatically makes
it bulkier than it would otherwise need to be.

Second, if you want it to be editable by a human being then the tag
names should be easy to recognize and to remember.

Third, the HTML allows only a subset of SGML. That mistake is
partially rectified with XML and XHTML. Those will allow you to define
and refer to entities, using SGML syntax.

As an example, $yahoo$ could be used in place of a full anchor tag
to a www.*.com site, and closed with a single $.
Bad idea; W3C should and would shoot it down in an instant. That
*would* break existing HTML, badly.
Real dollar signs, which dont appear on most web pages,
They appear on enough, especially those dealing with programming
languages and with financial matters, to be unacceptable.
Another approach would allow constants to be set on an HTML page:
SET $l="<A HREF="http://www.yahoo.com">
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">
Why reinvent the wheel?

<!ENTITY $l "&lt;A HREF=&quot;http://www.yahoo.com&quot;&gt;" >
Another idea would be to make whitespace significant, including
newlines.
That would make things worse rather than better.
Finally, the author would not necessarily need to author in AHTML,
but could instead simply configure the web server to convert it on
the way out,


You can do that today.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to sp******@library.lspace.org

Jul 23 '05 #16

P: n/a
> Barely.
That's the CSS, folks. The rest is table layout and font tags.


You are looking at their old page - see the beta page linked at the
top of their homepage.
Jul 23 '05 #17

P: n/a
> > Another idea would be to make whitespace significant, including
newlines.


How will this reduce bandwidth and human readability?


An HTML page already contains a lot of newlines, which are ignored in
HTML parsing. <BR> is used as newline. You can save 4 chars by making
newlines meaningful.
Finally, the author would not necessarily need to author in AHTML,


... negating the less typing benefit...


Correct, this is for the bandwidth argument.
but
could instead simply configure the web server to convert it on the way
out, similar to mod_gzip (which I use and think is great!).


Well, I suppose there are possibilities here, but all told, the savings of
bandwidth and typing won't be sufficient to sell this idea in most
applications of HTML, IMO.


Its very dependant on usage, not for everyone, correct.

The other advantage I didnt mention is that abbreviated HTML would be
very helpful for mobile devices with low bandwidth, and, of course,
dial-ups.
Jul 23 '05 #18

P: n/a
> Who actually types any? Surely mostly one just cuts and pastes from
existing html. Pretty much all I ever actually type are specifications for
size or colour, and I'd still have to do that.


Lots of us do.

I have only worked on interactive websites (ie writing code to
generate dynamic pages, mostly in LAMP). Interleaving code and HTML is
ugly to read.

In many cases cut and paste does not help when you write lines like
this:

$r->print('<A HREF="http://',$server , $url ,
$query,'">',$linktext,'</A>');

Minimizing the verbosity of the HTML would be a big help.
Jul 23 '05 #19

P: n/a
On 8 Oct 2004 15:04:04 -0700, Seth Brundle <br**********@hotmail.com>
wrote:
Barely.
That's the CSS, folks. The rest is table layout and font tags.


You are looking at their old page - see the beta page linked at the
top of their homepage.


At http://www.yahoo.com/ ? I see no such link. Got the URL?
Jul 23 '05 #20

P: n/a
Neal wrote:
On 8 Oct 2004 15:04:04 -0700, Seth Brundle <br**********@hotmail.com>
wrote:
You are looking at their old page - see the beta page linked at the
top of their homepage.


At http://www.yahoo.com/ ? I see no such link. Got the URL?


http://yahoo.com/beta/
Jul 23 '05 #21

P: n/a
Leif K-Brooks <eu*****@ecritters.biz> wrote:
http://yahoo.com/beta/


Redirects to: http://www.yahoo.com/beta/ and then:

Sorry, the page you requested was not found.

--
Spartanicus
Jul 23 '05 #22

P: n/a
Spartanicus wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote:

http://yahoo.com/beta/

Redirects to: http://www.yahoo.com/beta/ and then:

Sorry, the page you requested was not found.


Sorry, the slash at the end seems to be breaking it. Try this:

http://yahoo.com/beta
Jul 23 '05 #23

P: n/a
In comp.infosystems.www.authoring.html Leif K-Brooks said:
http://yahoo.com/beta


industrial strength tag soup and my browser isn't supported until
sometime next week. fucking pathetic.

why are the shareholders happy an 8 year old with a copy of frontpage is
doing the new site?

--
v o i c e s
Jul 23 '05 #24

P: n/a
Seth Brundle br**********@hotmail.com wrote:
Who actually types any? Surely mostly one just cuts and pastes from
existing html. Pretty much all I ever actually type are specifications for
size or colour, and I'd still have to do that.


Lots of us do.

I have only worked on interactive websites (ie writing code to
generate dynamic pages, mostly in LAMP). Interleaving code and HTML is
ugly to read.

In many cases cut and paste does not help when you write lines like
this:

$r->print('<A HREF="http://',$server , $url ,
$query,'">',$linktext,'</A>');

Minimizing the verbosity of the HTML would be a big help.


I don't see how in that case, the best you could hope to save would be two
or three keystrokes at the very most. Not much advantage given that it
would require completely reworking html pretty much from the ground up.

--
eric
www.ericjarvis.co.uk
"live fast, die only if strictly necessary"
Jul 23 '05 #25

P: n/a
Els
brucie wrote:
In comp.infosystems.www.authoring.html Leif K-Brooks said:
http://yahoo.com/beta


... my browser isn't supported
until sometime next week.


Same here - and I was using Firebird. Hardly a brandnew browser.

Then I checked with IE6, looked at the source, found style tags
inside divs, tables with deprecated code, and I used the W3.org
validator on it. Only 272 errors...

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Now playing: Bodysnatchers - Ruder Than You
Jul 23 '05 #26

P: n/a
Leif K-Brooks <eu*****@ecritters.biz> wrote:
Sorry, the slash at the end seems to be breaking it. Try this:

http://yahoo.com/beta


At this time, we do not have the new page programmed for your specific
browser. We are working to have the page available to your browser in
the coming week.

Interesting since they cannot possibly detect which browser I'm using.

--
Spartanicus
Jul 23 '05 #27

P: n/a
Els
Spartanicus wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote:
Sorry, the slash at the end seems to be breaking it. Try
this:

http://yahoo.com/beta


At this time, we do not have the new page programmed for
your specific browser. We are working to have the page
available to your browser in the coming week.

Interesting since they cannot possibly detect which browser
I'm using.


The can detect it doesn't identify as IE though.

However I doubt they'll be ready for your browser next week ;-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -
Now playing: Squeeze - Cool For Cats
Jul 23 '05 #28

P: n/a
Seth Brundle wrote:
I have only worked on interactive websites (ie writing code to
generate dynamic pages, mostly in LAMP). Interleaving code and HTML is
ugly to read.

In many cases cut and paste does not help when you write lines like
this:
$r->print('<A HREF="http://',$server , $url ,
$query,'">',$linktext,'</A>');


So create reusable functions:

sub output_dotcom_link {
my $u = shift @_;
my $t = shift @_;
print qq[<a href="http://www.$u.com">$t</a>];
}

&output_dotcom_link('yahoo','Yahoo!');

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jul 23 '05 #29

P: n/a
Seth Brundle wrote:
<BR> is used as newline. You can save 4 chars by making newlines
meaningful.


I make that three characters (or two on Windows).

You'll save far more bytes using mod_gzip.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jul 23 '05 #30

P: n/a
On 9 Oct 2004 10:04:34 GMT, Els <el*********@tiscali.nl> wrote:
brucie wrote:
In comp.infosystems.www.authoring.html Leif K-Brooks said:
http://yahoo.com/beta
... my browser isn't supported
until sometime next week.


Same here - and I was using Firebird. Hardly a brandnew browser.


Opera 7.23 is not supported either. Neither is Lynx. If it were a truly
CSS design, shouldn't it work even a little?
Then I checked with IE6, looked at the source, found style tags
inside divs, tables with deprecated code, and I used the W3.org
validator on it. Only 272 errors...


Guess this is why it's still "beta"...
Jul 23 '05 #31

P: n/a
Spartanicus wrote:
Leif K-Brooks <eu*****@ecritters.biz> wrote:

http://yahoo.com/beta

At this time, we do not have the new page programmed for your
specific browser. We are working to have the page available to your
browser in the coming week.

Interesting since they cannot possibly detect which browser I'm
using.


No, they cannot detect it. But I think they used the Psychic Friends
Hotline[1] to *predict* which browser you'd be using when you visited it.

[1] The Psychic Friends Hotline was a long running "service" that was
heavily advertised on tv in the States. Its spokesperson was singer
Dionne Warwick.

--
Brian (remove "invalid" to email me)
http://www.tsmchughs.com/
Jul 23 '05 #32

P: n/a
On Sat, 09 Oct 2004 17:09:13 GMT, Brian
<us*****@julietremblay.com.invalid> wrote:
[1] The Psychic Friends Hotline was a long running "service" that was
heavily advertised on tv in the States. Its spokesperson was singer
Dionne Warwick.


.... incidentally, they went bankrupt. (The joke is they should have known
that was going to happen.)
Jul 23 '05 #33

P: n/a
Neal wrote:
On Sat, 09 Oct 2004 17:09:13 GMT, Brian
<us*****@julietremblay.com.invalid> wrote:
[1] The Psychic Friends Hotline was a long running "service" that was
heavily advertised on tv in the States. Its spokesperson was singer
Dionne Warwick.


... incidentally, they went bankrupt. (The joke is they should have known
that was going to happen.)


I bet when they went bankrupt they knew people would tell that joke.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jul 23 '05 #34

P: n/a
On Sat, 9 Oct 2004, Neal wrote:
On Sat, 09 Oct 2004 17:09:13 GMT, Brian <us*****@julietremblay.com.invalid>
wrote:
[1] The Psychic Friends Hotline was a long running "service"
[..] ... incidentally, they went bankrupt. (The joke is they should have
known that was going to happen.)


Maybe they tried to Strike a Happy Medium? SCNR.

Jul 23 '05 #35

P: n/a
In article <41**************************@news.patriot.net>,
"Shmuel (Seymour J.) Metz" <sp******@library.lspace.org.invalid>
wrote:
Third, the HTML allows only a subset of SGML. That mistake is
partially rectified with XML and XHTML. Those will allow you to define
and refer to entities, using SGML syntax.


In theory, yes. In practice, you can only do that within your own
private environment but not on the Web, because on the Web you can't
make sure everyone else is using an XML processor that processes the DTD.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 23 '05 #36

P: n/a
In <53**************************@posting.google.com >, on 10/08/2004
at 03:11 PM, br**********@hotmail.com (Seth Brundle) said:
An HTML page already contains a lot of newlines, which are ignored in
HTML parsing. <BR> is used as newline. You can save 4 chars by making
newlines meaningful.


No, because you need some way to distinguish between a line that was
wrapped and a line that must end where it does. Currently <br> serves
that purpose. You could get around it by decreeing that editors should
not wrap text, but that would make it harder for people to edit.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to sp******@library.lspace.org

Jul 23 '05 #37

P: n/a
In <53*************************@posting.google.com> , on 10/08/2004
at 03:15 PM, br**********@hotmail.com (Seth Brundle) said:
I have only worked on interactive websites (ie writing code to
generate dynamic pages, mostly in LAMP). Interleaving code and HTML
is ugly to read.
That's probably a sign that you're doing things inline that belong in
subroutines.
In many cases cut and paste does not help when you write lines like
this:
$r->print('<A HREF="http://',$server , $url ,
$query,'">',$linktext,'</A>');
Minimizing the verbosity of the HTML would be a big help.


That example looks pretty minimal already.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to sp******@library.lspace.org

Jul 23 '05 #38

P: n/a
In article <53**************************@posting.google.com >, Seth Brundle writes:
> Another idea would be to make whitespace significant, including
> newlines.


How will this reduce bandwidth and human readability?


An HTML page already contains a lot of newlines, which are ignored in
HTML parsing. <BR> is used as newline. You can save 4 chars by making
newlines meaningful.


Do you mean that every newline in HTML would be treated as a <br> by
user agents? So I would need to write every element in a single line
so as not to have undesired <br>s in them? That's hardly a plus for
readability. How often is a <br> actually going to be needed, anyway?
It seems like one of the less-useful tags around.

--
Michael F. Stemper
#include <Standard_Disclaimer>
Have you embraced Windows ... lately?

Jul 23 '05 #39

P: n/a
Seth Brundle wrote:
Another approach would allow constants to be set on an HTML page:

SET $l="<A HREF="http://www.yahoo.com">
SET $f="<FONT FACE="Arial, Helvetica, Sans-Serif" SIZE="-2">


If you introduce variables or constants you have not a markup language
anymore, but a client-side scripting language. I think there could be
possible nice features for scripting, IMO rather in CSS than in HTML; for
example dynamic calculations, such as:

#left {
width:180px;
}
#right {
width:20em;
}
#maincontainer {
width:100%-180px-20em;
}

or some kind of image size adjustment control:

if (defaultFontSize > 16px) {
img {
width:width*2;
height:height*2;
}
}

Anyway just think about how long it would take to achieve just an idea of
overall browser support for new things like that.

For the moment I guess that (as others pointed out in this thread already)
on most sites a proper HTML structure and CSS layout could save much more
typing work and bandwith than any additional abbreviations could ever.

--
Markus
Jul 23 '05 #40

P: n/a
Seth Brundle wrote:
I am surprised that no one has yet developed an HTML variant which
uses abbreviated tagging. Maybe they have, I dunno.

HTML is very verbose - this was important to its adoption, as reading
source from existing pages is one of the fastest ways to learn it -
and descriptive clear tagging is key to that.

However, there is an argument for a more concise tagging system as
well, one which can be very easily converted to and from regular html
easily.

The advantages are twofold: less typing and less bandwidth.


For less bandwidth, I believe with have (g)zipping with HTTP1.1
Compression.

For less typing, we have editors. No one in the world stops you from
doing an editor that would convert
<blockquote>
to
<bq>
before you open the editor, and convert it back to
<blockquote>
upon saving.

Would it be worthwhile? No, unless you have a monopoly you would create
an entry barrier -- nobody wants to see yet another HTML.

--
Google Blogoscoped
http://blog.outer-court.com
Jul 23 '05 #41

This discussion thread is closed

Replies have been disabled for this discussion.