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

Extending HTML Elements

P: n/a
Hi!

I have some legacy code. DIVs are used to be dragged and dropped. Some
checks are made. For the checks information is taken out of the DIVs id.
Now my question is:
Where else could I take the information from?
Could I write something like
<div id="1" myPerson="Joe" myStartTime="10:00" myDuration="120" />
or is only the current solution
<div id="1;Joe;10:00;120" />
better?
Or is there another totally different solution?

(I ask this in this group as I want the information be saved in HTML
better than adding the information later with javascript or "saving"
them within javascript fuctions.)

Regards,

Rudi
Apr 19 '07 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On Thu, 19 Apr 2007 14:46:16 +0200, Rudi Hausmann wrote:
Could I write something like
<div id="1" myPerson="Joe" myStartTime="10:00" myDuration="120" />
or is only the current solution
<div id="1;Joe;10:00;120" />
better?
No, real programming languages can do that, but HTML can't.
You can have multiple ids:

<div id="1" id="aPerson" id="Joe".....................

....but that's not really as useful as what you want.

You could learn some server side language so that you can generate
your pages from a program, modifying them and their CSS as needed for the
information you will use. Client side JavaScript is less attractive,
because you end up with pages that are so kludged up with goo that they
are unreadable in any reasonable amount of time when it comes time to make
modifications.


Apr 19 '07 #2

P: n/a
mbstevens wrote:
On Thu, 19 Apr 2007 14:46:16 +0200, Rudi Hausmann wrote:
>Could I write something like
<div id="1" myPerson="Joe" myStartTime="10:00" myDuration="120" />
or is only the current solution
<div id="1;Joe;10:00;120" />
better?

No, real programming languages can do that, but HTML can't.
I tried:
<div id="1" test="wow" />
and it worked.. I could access the test property in JavaScript.
You can have multiple ids:

<div id="1" id="aPerson" id="Joe".....................

...but that's not really as useful as what you want.

You could learn some server side language so that you can generate
your pages from a program, modifying them and their CSS as needed for the
information you will use.
We use a server side language, but we want to do a minimum of checks on
the client side. We want to connect to the server only when really
required. (e.g. save, etc.)
Client side JavaScript is less attractive,
because you end up with pages that are so kludged up with goo that they
are unreadable in any reasonable amount of time when it comes time to make
modifications.
Well, nothing is perfect.
Apr 19 '07 #3

P: n/a
mbstevens <NO***********@xmbstevensx.comwrote:
>You can have multiple ids:

<div id="1" id="aPerson" id="Joe".....................
Only one id attribute per element is allowed.

--
Spartanicus
Apr 19 '07 #4

P: n/a
On Thu, 19 Apr 2007 15:26:06 +0100, Spartanicus wrote:
mbstevens <NO***********@xmbstevensx.comwrote:
>>You can have multiple ids:

<div id="1" id="aPerson" id="Joe".....................

Only one id attribute per element is allowed.
Of course you're right;
I must be groggy this morning.
I should have said class, not id.

Apr 19 '07 #5

P: n/a
mbstevens <NO***********@xmbstevensx.comwrote:
>Only one id attribute per element is allowed.

Of course you're right;
I must be groggy this morning.
I should have said class, not id.
Same, only one class attribute per element is allowed. However you can
have multiple classes (class="foo bar").

--
Spartanicus
Apr 19 '07 #6

P: n/a
On Thu, 19 Apr 2007 15:48:06 +0100, Spartanicus wrote:
Same, only one class attribute per element is allowed. However you can
have multiple classes (class="foo bar").
Thanks for the clarification.
I checked this, and you're right.
Apr 19 '07 #7

P: n/a
On 19 Apr, 13:46, Rudi Hausmann <rudi...@nospam.comwrote:
I have some legacy code. DIVs are used to be dragged and dropped. Some
checks are made. For the checks information is taken out of the DIVs id.
Now my question is:
Where else could I take the information from?
There are lots of ways to do, most somewhat clumsy, some are really
ugly.

* Abuse the id attribute

* Invent extra attributes.

* Re-use existing attributes.

* Use other HTML structure.

Firstly "Abuse the id attribute"

I wouldn't do this. id (and name) is important - it makes a lot of
JavaScript functions, like getElementById() work. If you duplicate
this attribute, or fill it with malformed values, then you're likely
to cause lots of other problems.

* Invent extra attributes.

This is pretty good, although it breaks the validity standard.
Browsers are reliably safe against unexpected attributes with unknown
names.

Just do this (or something like it)
<div id="cant_start_with_a_digit_1" myPerson="Joe" myStartTime="10:00"
myDuration="120" >

In some contexts you might even use XML namespacing here, but that's
unworkable on today's web.
* Re-use existing attributes.

Use title, class etc. (for <ait's common to use rel too) and stick
string-formatted values in there in a format like DCSV Then parse and
process these with your own code.

It's clean, it's valid, it works, but it might be using-up an
attribute that you'd also like to use for some other purpose.

* Use other HTML structure.

Embed one or more <spanwithin your <div>, place the content inside
there and apply some CSS to make it invisible. It's valid, it's easily
parseable through the DOM and it's only a little verbose.


Apr 19 '07 #8

P: n/a
Andy Dingley wrote:
On 19 Apr, 13:46, Rudi Hausmann <rudi...@nospam.comwrote:
>I have some legacy code. DIVs are used to be dragged and dropped. Some
checks are made. For the checks information is taken out of the DIVs id.
Now my question is:
Where else could I take the information from?

There are lots of ways to do, most somewhat clumsy, some are really
ugly.

* Abuse the id attribute

* Invent extra attributes.

* Re-use existing attributes.

* Use other HTML structure.

Firstly "Abuse the id attribute"

I wouldn't do this. id (and name) is important - it makes a lot of
JavaScript functions, like getElementById() work. If you duplicate
this attribute, or fill it with malformed values, then you're likely
to cause lots of other problems.

* Invent extra attributes.

This is pretty good, although it breaks the validity standard.
Browsers are reliably safe against unexpected attributes with unknown
names.

Just do this (or something like it)
<div id="cant_start_with_a_digit_1" myPerson="Joe" myStartTime="10:00"
myDuration="120" >

In some contexts you might even use XML namespacing here, but that's
unworkable on today's web.
* Re-use existing attributes.

Use title, class etc. (for <ait's common to use rel too) and stick
string-formatted values in there in a format like DCSV Then parse and
process these with your own code.

It's clean, it's valid, it works, but it might be using-up an
attribute that you'd also like to use for some other purpose.

* Use other HTML structure.

Embed one or more <spanwithin your <div>, place the content inside
there and apply some CSS to make it invisible. It's valid, it's easily
parseable through the DOM and it's only a little verbose.
It's also thoroughly bad. SPAN is meant to contain content, not metadata
for other tags. It would also be messy to associate each DIV with its SPAN.
Apr 19 '07 #9

P: n/a
On 19 Apr, 16:21, Harlan Messinger <hmessinger.removet...@comcast.net>
wrote:
* Use other HTML structure.
Embed one or more <spanwithin your <div>, place the content inside
there and apply some CSS to make it invisible. It's valid, it's easily
parseable through the DOM and it's only a little verbose.

It's also thoroughly bad. SPAN is meant to contain content, not metadata
for other tags. It would also be messy to associate each DIV with its SPAN.
Interesting comment. You're right of course, but I'd see this as
awfully nit-picking.

Where is it carved in stone that <spancan't contain metadata? Look
at how many W3C pages, and even W3C examples include $Date: ... $
metadata in visible elements. Although <spanis intended for
content, I see no real reason it can't be used for either if the
existing metadata facilities are inadequate.

In practical terms, this works fine (and is easy to implement) for
anything except a non-CSS browser. As the whole point is to support
some JavaScript, then that's unlikely to be a major problem.

Apr 19 '07 #10

P: n/a
Harlan Messinger wrote:
Andy Dingley wrote:
>>
Embed one or more <spanwithin your <div>, place the content inside
there and apply some CSS to make it invisible.

It's also thoroughly bad. SPAN is meant to contain content, not metadata
It also degrades poorly when CSS isn't applied. CSS is supposed to be
optional, after all.

--
Berg
Apr 19 '07 #11

P: n/a
Andy Dingley wrote:
On 19 Apr, 16:21, Harlan Messinger <hmessinger.removet...@comcast.net>
wrote:
>>* Use other HTML structure.
Embed one or more <spanwithin your <div>, place the content inside
there and apply some CSS to make it invisible. It's valid, it's easily
parseable through the DOM and it's only a little verbose.
It's also thoroughly bad. SPAN is meant to contain content, not metadata
for other tags. It would also be messy to associate each DIV with its SPAN.

Interesting comment. You're right of course, but I'd see this as
awfully nit-picking.

Where is it carved in stone that <spancan't contain metadata?
It isn't carved in stone, just as it isn't carved in stone that you
can't print the even-numbered pages of a book in mirror image and ask
the reader to hold them up to a mirror to read them. By the nature of
HTML, though what's in the body that isn't in SCRIPT tags or comments is
generally content, the head section contains metadata about the
document, and tags' attributes contain metadata about the tags. To do
something else would just be odd.
Look
at how many W3C pages, and even W3C examples include $Date: ... $
Where?
metadata in visible elements. Although <spanis intended for
content, I see no real reason it can't be used for either if the
existing metadata facilities are inadequate.

In practical terms, this works fine (and is easy to implement) for
anything except a non-CSS browser. As the whole point is to support
some JavaScript, then that's unlikely to be a major problem.
Apr 19 '07 #12

P: n/a
On 19 Apr, 18:39, Harlan Messinger <hmessinger.removet...@comcast.net>
wrote:
Where is it carved in stone that <spancan't contain metadata?

It isn't carved in stone,
just as it isn't carved in stone that you
can't print the even-numbered pages of a book in mirror image and ask
the reader to hold them up to a mirror to read them.
Should my UTF characters be big-endian or little-endian then? After
all, they're very human-sensitive to their octet ordering. Or should
I just realise that the human doesn't interact with them directly but
through a machine, and that the machine hides this detail perfectly
readily.

Of course I'm not suggesting that this metadata shoudl be obviously
visible -- but we have simple techniques to stop it being so. A
context where CSS visibility isn't available is pretty extreme.
By the nature of
HTML, though what's in the body that isn't in SCRIPT tags or comments
Using comments would be yet another way to do it (would work, but
might be non-robust against some comment-stripping processes)
is generally content,
"generally", yes. But it's a big world and general rules don't stretch
across it too well.

the head section contains metadata about the
document, and tags' attributes contain metadata about the tags.
Tags have limited (valid) attributes. They're very possibly not
descriptive enough.
To do something else would just be odd.
Most interesting things in life are odd. I was in Barcelona this week,
looking at Gaudi's buildings. The fact that he made the dragon-shaped
roof of Casa Battlo downright weird didn't stop it working perfectly
well as a roof (he did much better roofs than Frank Lloyd Wright).

Is it actually _harmful_ to do this? How harmful? How big a scope
of exposure to harm is there?

Look
at how many W3C pages, and even W3C examples include $Date: ... $

Where?
As a quick example, the description of <address>
http://www.w3.org/TR/html4/struct/gl...l#edef-ADDRESS

Apr 19 '07 #13

P: n/a
Scripsit Rudi Hausmann:
I have some legacy code. DIVs are used to be dragged and dropped. Some
checks are made. For the checks information is taken out of the DIVs
id. Now my question is:
Where else could I take the information from?
I'm not sure I understand the situation, and I'm not sure of other people's
understanding of it either. As usual, a URL would clarify, especially if
this is an existing page (as "legacy code" suggests).
Could I write something like
<div id="1" myPerson="Joe" myStartTime="10:00" myDuration="120" />
or is only the current solution
<div id="1;Joe;10:00;120" />
better?
First, they are both wrong in the use of <div .../>, which should not be
used even if you play the XHTML game. XHTML doesn't work on the web unless
you fake it as text/html, and then you should follow Appendix C.

The current solution is wrong because it uses a syntactically malformed id
value (with the non-name character ";"). Anything may happen.

The tentative solution is syntactically wrong too, though - as Andy wrote -
you could use imaginative attribute names, thereby most probably getting
away with it.

Using valid attributes is problematic too. Some comparable approaches use
the title attribute, which has the nice feature of swallowing everything,
i.e. it has CDATA declared value, so that the value can be any string. Yet,
modern browsers tend to display the title attribute on mouseover, and the
effect would be rather odd.
Or is there another totally different solution?
Probably...
(I ask this in this group as I want the information be saved in HTML
better than adding the information later with javascript or "saving"
them within javascript fuctions.)
Since this is essentially for JavaScript, I would put the information itself
into JavaScript code and use just identifiers for it in HTML, e.g. id="x1"
or id="Joe" in a <divtag, so that there is a data structure in the
JavaScript code that holds the information associated with each id. Perhaps
just an array. If desired, you could make that code part of the HTML source,
by putting it inside a <scriptelement rather than an external file.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Apr 19 '07 #14

P: n/a
On 04/19/2007 07:46 AM, Rudi Hausmann wrote:
Hi!

I have some legacy code. DIVs are used to be dragged and dropped. Some
checks are made. For the checks information is taken out of the DIVs id.
Now my question is:
Where else could I take the information from?
Could I write something like
<div id="1" myPerson="Joe" myStartTime="10:00" myDuration="120" />
or is only the current solution
<div id="1;Joe;10:00;120" />
better?
Or is there another totally different solution?

(I ask this in this group as I want the information be saved in HTML
better than adding the information later with javascript or "saving"
them within javascript fuctions.)

Regards,

Rudi
I am not knowledgeable enough about HTML to advise, but I shall anyway.
The worst that could happen is that I could be wrong.

You might be able to create your own custom "stylesheet," e.g.:

<style type="text/x-checkspec">
n1 ="Joe;10:00;120"
</style>
....
<div id="n1"Content </div>
Obviously your software would have to have some way to parse and update
your "stylesheet" text.

--
Count the YOYOs:
http://home.earthlink.net/~mumia.w.18.spam/games_fever/
Apr 20 '07 #15

P: n/a
On 20 Apr, 11:20, "Mumia W." <paduille.4061.mumia.w
+nos...@earthlink.netwrote:
You might be able to create your own custom "stylesheet," e.g.:

<style type="text/x-checkspec">
n1 ="Joe;10:00;120"
</style>
...
<div id="n1"Content </div>

Obviously your software would have to have some way to parse and update
your "stylesheet" text.
That's a workable approach, and one that Jukka suggested. The obvious
"stylesheet" technology is JavaScript, where there's some array-like
structure on the page to map n1 onto "Joe;10:00;120"

The drawback to this (and why I don't like it) is that it separates
two parts of the "source code" from each other. Somewhere in the HTML
is <div id="n1" and somewhere else a long way from it is the rest of
the metadata. Although this is possible, long experience has shown
that coding in this disjointed style leads to more errors.

It's particularly bad if the JavaScript moves out to a separate
document. The tightly-coupled data is now stored in two different
locations. If you're tempted to do this (moving JavaScript libray
functions into a shared .js document is generally a good practice)
then you should strongly consider leaving this array population inside
the <scriptelement within the HTML page that uses it.

Apr 20 '07 #16

P: n/a
On 04/20/2007 06:41 AM, Andy Dingley wrote:
[...]
The drawback to this (and why I don't like it) is that it separates
two parts of the "source code" from each other. Somewhere in the HTML
is <div id="n1" and somewhere else a long way from it is the rest of
the metadata. Although this is possible, long experience has shown
that coding in this disjointed style leads to more errors.
[...]
Separating the metadata from its associated HTML code does make the
program that manipulates all of this more complicated. If the OP chooses
the SPAN method, in addition to using CSS to hide the span, it's
probably also possible to make the metadata look "appropriate" in case
the CSS is not available, e.g.:

<div id="n1">
<spanValidation-Code:4a6f653b31303a30303b313230 </span>
<br>
Content
</div>

The <BRcould be eliminated by using a div:

<div id="n1">
<div class="val"Validation-Code:4a6f653b31303a30303b313230 </div>
Content
</div>

The hex string is 'Joe;10:00;120' encoded.
--
Count the YOYOs:
http://home.earthlink.net/~mumia.w.18.spam/games_fever/
Apr 20 '07 #17

P: n/a
Scripsit Andy Dingley:
><style type="text/x-checkspec">
- -
That's a workable approach, and one that Jukka suggested.
Well, not quite the same. There's something in common between the
approaches, but using <stylewith undefined type is rather different from
using a <scriptelement that conforms to all relevant specifications.
The drawback to this (and why I don't like it) is that it separates
two parts of the "source code" from each other. Somewhere in the HTML
is <div id="n1" and somewhere else a long way from it is the rest of
the metadata. Although this is possible, long experience has shown
that coding in this disjointed style leads to more errors.
But that's what we do in using CSS and JavaScript, isn't it? We separate
presentational and behavioral issues from markup, and it's generally
regarded as good practice to use external files rather than embedding.

You have a point though. The separation often works too well. However, if
this is a problem, you could use an approach like

<div id="n1">
<script type="text/javascript">
... code that e.g. puts data associated with n1 into an array ...
</script>
... content of the div ...
</div>

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Apr 20 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.