Here's a website I really like:
The HTML5 Test
Great idea! Rather than search
through a table of data with your
eyes wandering up and down the columns
trying to figure out whether
or not a particular HTML5 feature
is supported, you visit this web
page with the very browser you
wish to know more about.
Don't tell me, show me. That seems
to be the approach of this website.
I'm particularly interested in the
new audio element. Looks like
this is not yet ready for prime time
as of this writing.
This site is a wonderful idea! Match
your favorite HTML5 feature to your
favorite browser. Does it get any
simpler than this? Visit this site
with your favorite browser and look
for your favorite HTML5 feature.
Ed Abbott
Fix HTML Problems
Monday, September 27, 2010
Thursday, August 26, 2010
Image Maps and Shaped Hyperlinks
Here's someone who has coined a
new term for me:
Shaped Hyperlinks
At least, I think the term
shaped hyperlinks is
a new term. I don't find it
anywhere else.
Basically, a shaped hyperlink
is a link that takes form as
a rectangle, circle or polygon.
Furthermore, a shaped hyperlink
is one that you can give pixel-
perfect dimensions to.
In my experience, the following
seems to be true about
shaped hyperlinks:
If my writing on this topic appears to be
a bit confused, it is because I'm confused.
The HTML 4.01 spec clearly seems to be saying
that an anchor tag can be put to good
use as a shaper of links with the use of the
shape and coords attributes.
In fact, there doesn't seem to be a meaningful
use for these attributes when they are applied
to the anchor element.
Only the area element seems to make
practical use of the shape and coords
attributes.
In other words, you might as well use an
area element if you are want to make
use of the shape and coords
attributes. The area element might
make more sense because then you are not
fooling yourself into thinking you are getting
something that you are not getting.
In particular, the HTML 4.01 specification seems
to imply that block level content is possible
inside of a map element. As far as I can
tell, no such possibility exists as a practical
matter.
Of course, it makes some sense to implement this
possibility. However, nowhere do I see an
implementation of block-level content nested
inside of the map element. It's just not
a present day reality.
Are these specifications written in a vacuum?
In the future, I'm going to be more cautious when
I read these things.
There are appearances and there is reality.
Looks like I've been chasing an appearance
hoping it would turn into a reality.
Ed Abbott
new term for me:
Shaped Hyperlinks
At least, I think the term
shaped hyperlinks is
a new term. I don't find it
anywhere else.
Basically, a shaped hyperlink
is a link that takes form as
a rectangle, circle or polygon.
Furthermore, a shaped hyperlink
is one that you can give pixel-
perfect dimensions to.
In my experience, the following
seems to be true about
shaped hyperlinks:
- As a practical matter, you
cannot create shaped hyperlinks
using the map element without
an accompanying image that refers to
the map with a usemap attribute. - The HTML 4.01 specification seems to imply
that shaped hyperlinks via the map
element are possible independent of
any image but this does not appear to
be so. - The HTML 4.01 specification seems
to be saying that shaped hyperlinks
are possible by adding a shape to an
anchor element. - The HMTL 4.01 specification would
have you believe that there is a practical
use for the shape and coords attributes
when applied to the <a> tag but there are
no browsers that I know of that support this. - The only element that I know of that seems
to make actual use of the shape and coords
attributes is the area element.
If my writing on this topic appears to be
a bit confused, it is because I'm confused.
The HTML 4.01 spec clearly seems to be saying
that an anchor tag can be put to good
use as a shaper of links with the use of the
shape and coords attributes.
In fact, there doesn't seem to be a meaningful
use for these attributes when they are applied
to the anchor element.
Only the area element seems to make
practical use of the shape and coords
attributes.
In other words, you might as well use an
area element if you are want to make
use of the shape and coords
attributes. The area element might
make more sense because then you are not
fooling yourself into thinking you are getting
something that you are not getting.
In particular, the HTML 4.01 specification seems
to imply that block level content is possible
inside of a map element. As far as I can
tell, no such possibility exists as a practical
matter.
Of course, it makes some sense to implement this
possibility. However, nowhere do I see an
implementation of block-level content nested
inside of the map element. It's just not
a present day reality.
Are these specifications written in a vacuum?
In the future, I'm going to be more cautious when
I read these things.
There are appearances and there is reality.
Looks like I've been chasing an appearance
hoping it would turn into a reality.
Ed Abbott
Wednesday, August 25, 2010
Image Maps: Client Side Versus Server Side
According to the HTML 4.01
Specification, there are
two kinds of image map,
client side and server
side.
The specification clearly favors
client side image maps as a first
choice. This makes sense.
Here are some advantages of a client
side image map:
One of the key advantages of a client side
image map is that all processing of clicks
takes place inside your web visitors browser.
Therefore, a client side image map puts no
burden on your web server.
In fact, client side image maps are really
just another way to create links.
Client side image maps are particularly well
suited to creating links that have a strong
visual component.
Which is easier to implement? Client
side or server side image maps?
In general, client side image maps are
more easily implemented than server side
image maps.
However, if wish to do something really
sophisticated that goes beyond the creation
of links, you may need a server side image
map. Server side image maps need a backend
to process them.
Ed Abbott
Specification, there are
two kinds of image map,
client side and server
side.
The specification clearly favors
client side image maps as a first
choice. This makes sense.
Here are some advantages of a client
side image map:
- You don't have to set up anything
extra on your web server with a client
side image map. In particular, there
is no need to set up a program that figures
out what happens when a web visitor clicks
on your image map. - Client side image maps are limited.
Since you can only use them for linking,
they are simple. Simple is good. - The simplicity of a client-side image
map is that it defines a link, a clickable
area for that link, and that's all
One of the key advantages of a client side
image map is that all processing of clicks
takes place inside your web visitors browser.
Therefore, a client side image map puts no
burden on your web server.
In fact, client side image maps are really
just another way to create links.
Client side image maps are particularly well
suited to creating links that have a strong
visual component.
Which is easier to implement? Client
side or server side image maps?
In general, client side image maps are
more easily implemented than server side
image maps.
However, if wish to do something really
sophisticated that goes beyond the creation
of links, you may need a server side image
map. Server side image maps need a backend
to process them.
Ed Abbott
Tuesday, August 17, 2010
The HTML Map Tag
I get so frustrated at times trying
to fix HTML problems. So I'm starting
this blog to vent my frustrations and
learn at the same time.
I always hope that someone out there
will benefit from what I've written.
I hate to go through an experience like
this for nothing.
I've been working on a flash website.
For some reason, I'm not able to get
the map tag to work. All I'm
trying to do is to put navigation at
the top right above the flash navigation.
In other words, I'm building new navigation
on top of the old --- literally. It's as
if the flash animation is the first marquee and
my map tag marquee is a second marquee
built on top of the first. That's the vision.
Why won't this work? There's a lot of
weird positioning going on the code including
lots of height attributes. I find these
particularly difficult to work with as they tend
to lock things down and make it hard to modify
the page by adding something new. I don't think
I ever use a height attribute on my own.
However, sometimes I have to take what I'm given.
Of course, there is the radical solution of starting
brand new. However, I try to avoid this as I feel
that this is the worst case scenario. I try to respect
what is there and work with it rather than to destroy
it. If possible, I modify and build on top of what
is already there.
Looks like I'll be reading about image maps again
in the HTML 4.01 specification:
Image Maps
I'm doing something goofy and I don't know what it
is.
In all probability, I'm trying to make an image map
do something it was never meant to do. I'm trying
to use an image map for layout of text navigation.
I think I've got the wrong idea.
I hate to say it, but propably the best way to do
horizontal layout of text navigation is a table.
I've never found a more straight-forward way to do
it.
However, the thought occurs to me that the div
element might work well if it were turned into
an inline-level element instead of a block-level
element.
I'm trying to stretch beyond how I usually do
things.
Ed Abbott
Subscribe to:
Posts (Atom)