PDA

View Full Version : get by id and write??



lankinator
05-16-2007, 05:13 PM
how would i use the get element by id "star" and make it find a * and replace the * with an image?

Help appreciated :D

jscheuer1
05-16-2007, 05:26 PM
What you are saying cannot be done, but that is probably just because you haven't explained clearly, in layman's terms, what you want to do. There is no getElementById('*') that I know of, * is not technically a valid id. However, I might just be being too strict to standards in interpreting what you want. Here is one idea that would fit your question, if I've understood it:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>
<body>
<span id="*">HI</span>
<script type="text/javascript">
var star=document.getElementById('*');
var I=document.createElement('img');
I.src='http://www.google.com/intl/en_ALL/images/logo.gif';
star.parentNode.replaceChild(I,star);
</script>
</body>
</html>

But, as I say, it is invalid. As such it cannot be depended upon in all browsers. If you were to use a valid id, it would then be valid.

lankinator
05-16-2007, 05:27 PM
err, no the div id is "star" (the text not *) and i want the script to find the symbol * on the div and replace the * with an image?

jscheuer1
05-16-2007, 05:38 PM
Oh:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>
<body>
<div id="star">Hi * there!</div>
<script type="text/javascript">
var star=document.getElementById('star');
star.innerHTML=star.innerHTML.replace(/\*/, '<img src="http://www.google.com/intl/en_ALL/images/logo.gif">');
</script>
</body>
</html>

lankinator
05-16-2007, 05:39 PM
cheers :D

Twey
05-16-2007, 06:39 PM
Or, validly:
function replaceStars(element) {
var firstTextNode = element.firstChild,
texts,
img = document.createElement("img"),
i;
img.src = "star.png";
while(firstTextNode.nodeType !== 3)
firstTextNode = firstTextNode.nextSibling;
texts = firstTextNode.nodeValue.split("*");
for(i = 0; i < texts.length; ++i)
if(i &#37; 2 === 0)
texts[i] = document.createTextNode(texts[i]);
else
texts.splice(i, 0, img.copy());
texts.reverse();
element.replaceChild(firstTextNode, texts[0]);
for(var i = 1; i < texts.length; ++i)
element.insertBefore(texts[i], texts[i - 1]);
}

replaceStars(document.getElementById("star"));

jscheuer1
05-17-2007, 04:54 AM
Or, validly:

How is that any more or less valid? I will say this though, it looks like a nightmare. No wonder you have trouble sleeping at times. :p

Twey
05-17-2007, 11:04 AM
How is that any more or less valid?innerHTML isn't part of any standard. The DOM, however, is.
I will say this though, it looks like a nightmare. No wonder you have trouble sleeping at times. :pHah, that's nothing. :p

jscheuer1
05-18-2007, 03:45 AM
innerHTML isn't part of any standard. The DOM, however, is.Hah, that's nothing. :p

Heh. Yeah, I keep forgetting that, perhaps because there is so little chance that it will ever stop being supported by mainstream browsers.

Twey
05-18-2007, 09:39 AM
It's already started... most browsers won't allow innerHTML in an XHTML document.

There's little chance that broken HTML will stop being supported in mainstream browsers too. Should we all use it? :)

jscheuer1
05-18-2007, 10:25 AM
It's already started... most browsers won't allow innerHTML in an XHTML document.

There's little chance that broken HTML will stop being supported in mainstream browsers too. Should we all use it? :)

Started? Barely. Most browsers won't allow an XHTML document. Should we use it?

In HTML augmented with javascript, innerHTML will most likely work for as long as you are alive. It is not broken. It may not be part of any standard, but a browser designer would be nuts not to support it at least in some, if not all HTML modes.

In any case, the vast majority of installed browsers will not always faithfully and/or consistently render using DOM create and insert nodes. So, for the time being at least, innerHTML is a good approach.

It might be best to avoid either method, but that does limit what one can do quite a bit. Hiding and revealing, displaying and not displaying would appear to be the safest ways. These aren't always practical though.

Twey
05-18-2007, 11:10 AM
Started? Barely. Most browsers won't allow an XHTML document. Should we use it?IE isn't most browsers... Of course XHTML isn't viable now, as we've seen, but it does show that innerHTML will most certainly disappear sometime relatively soon (probably inside of five years).
It is not broken.Depends how you define "broken." It misrepresents the DOM, doesn't work across different markup languages even when they represent the same DOM tree, and needlessly recreates elements in the vast majority of cases. You're right in that it does work to some extent, though.
In any case, the vast majority of installed browsers will not always faithfully and/or consistently render using DOM create and insert nodes. So, for the time being at least, innerHTML is a good approach.Huh? There are a few bugs in IE, to be sure, but for most operations it's fine. innerHTML is still good as a fallback when DOM methods aren't available (for very old browsers), but other than that it's rather reached its sell-by date.

mwinter
05-18-2007, 02:21 PM
Of course XHTML isn't viable now, as we've seen, but it does show that innerHTML will most certainly disappear sometime relatively soon (probably inside of five years).

Why? Do you anticipate that all HTML documents will be forever removed from the Web?

jscheuer1
05-18-2007, 04:34 PM
Thanks Mike. Um, when I say the vast majority of browsers, I mean the installed base. At the moment, that means IE 6. It will probably sooner or later mean IE 7. Still no XHTML support. Now, I wouldn't go so far as to say that XHTML is only for blind people with PDA's, but it is a humorous commentary on the state of affairs with XHTML. After staring at those tiny screens for awhile, I feel like I'm going blind.

Back to browsers, don't confuse the proliferation of compliant (actually, more compliant than IE) browser models with the actual installed numbers of these things. It is the installed browsers that view the web, not necessarily the best (however that is determined) ones.

Even if it were, the 'best' browsers still continue to support HTML and innerHTML, and will probably do so for quite some time.

Perhaps we should make a small friendly wager on this 5 year prediction of yours, Twey.

Twey
05-18-2007, 08:22 PM
Why? Do you anticipate that all HTML documents will be forever removed from the Web?No, but I anticipate that should XHTML become proliferant (which I must now say it does look set to do; only IE is preventing it from having done so already) people will become more familiar with the standardised way of doing things, and thus they will stop using non-standard extensions like innerHTML in their XHTML pages, which in turn will lead to them avoiding it in HTML pages. Once there are sufficiently few HTML pages that require innerHTML, it will be removed from browsers, since there is no standard keeping it there.
Um, when I say the vast majority of browsers, I mean the installed base.Ah -- when you said on a number of browsers, I automatically assumed you meant a number of browsers, rather than a number of installations of those browsers. Sorry.
Now, I wouldn't go so far as to say that XHTML is only for blind people with PDA's, but it is a humorous commentary on the state of affairs with XHTML.Yes, but as I've said, it's only IE holding it back. As soon as IE supports XHTML, we can expect the numbers to increase dramatically.
Perhaps we should make a small friendly wager on this 5 year prediction of yours, Twey.I daresay I'd've forgotten all about it by the time it came to pass :) But certainly, I'd be willing to put a little (not a huge amount, admittedly) on it.

mwinter
05-19-2007, 01:11 PM
Do you anticipate that all HTML documents will be forever removed from the Web?

No,

Looking at past trends, backwards-compatibility is an important goal. For as long as HTML remains, so too will things like innerHTML (whether we like them or not).



but I anticipate that should XHTML become proliferant (which I must now say it does look set to do; only IE is preventing it from having done so already) people will become more familiar with the standardised way of doing things, and thus they will stop using non-standard extensions like innerHTML in their XHTML pages, which in turn will lead to them avoiding it in HTML pages.

Again, looking at past trends, I would think it more likely that browser vendors will bow to pressure from the ignorant masses and retrofit HTML-specific features for use with XHTML. :(

Bob90
05-19-2007, 04:33 PM
But heres my opinion anyway.

XHTML will become the mainstream within a short time (I don't want to fall into the same traps as Twey, but I would put a date, say 7 years) When the large majority (90&#37; of pages, that matter) are XHTML and therefore .innerHTML will seldom be used. You only have to look at sites like http://www.backbase.com/demos/explorer/#examples/welcome.xml[0] to realise that as soon as there are some freely available XHTML classes (? or schemas) available then the majority of people will flock to these like, well the masses do.

Just think of the advantages. That's why its being introduced; not to mention the integration with it's superset language SGML.

So..... I guess I side with Twey, well more in the middle because innerHTML will still be there, just rarely called upon.

:)

mwinter
05-19-2007, 05:22 PM
XHTML will become the mainstream within a short time (I don't want to fall into the same traps as Trey, ...

Trey? You might want to check his username again.



You only have to look at sites like http://www.backbase.com/demos/explorer/#examples/welcome.xml[0] to realise that as soon as there are some freely available XHTML classes (? or schemas) available then the majority of people will flock to these like, well the masses do.

That document isn't XHTML. It's invalid, heavily scripted HTML - turn off scripting support and view a nice, more-or-less empty viewport.



Just think of the advantages.

As far as those that relate to most Web users, there are no applicable benefits. There are some for the author, but the author can still benefit without serving XHTML.



That's why its being introduced; not to mention the integration with it's superset language SGML.

XHTML is an application of XML, not SGML. Even if it weren't, what bearing does that have on the Web?

jscheuer1
05-19-2007, 06:01 PM
Thanks again for backing me up Mike, though I realize it is more just you expressing the facts as you see them.

In Bobo90's (couldn't resist) defense, Trey is what my spell-checker keeps wanting to use for Twey's name and I think this even tripped up dd at least once in the script library when he was giving Twey credit for a script there.

Best not to use a spell-checker with auto-correct when posting in these forums. I use one that prompts me before replacing anything.

Twey
05-19-2007, 07:31 PM
Trey? You might want to check his username again.Everyone does that. I'm not entirely sure why. I think perhaps "Trey" is an American name.

Bob90
05-19-2007, 08:12 PM
Yes. I spelt his name wrong. Sorry Twey. Minor Point.

So back to schema instead of backbase.
http://www.w3.org/TR/xmlschema-1/#d0e504
Thats the major advantage of XML; defining your own data structure. Allowing (in my mind) easier development of complex programs.

XML is a subset of SGML and XHTML is based from that. I thought the future lay with SGML databases, which could be used locally for rich data applications and data from that could easily be parsed for the web ie xml. Hence the duality of SGML and XML.

As for the advantages, well of course its for Authors; who else do we supply on DD. They all author work, that the great thing about the web.

:)

Twey
05-19-2007, 09:12 PM
XML is a subset of SGMLXML is not a subset of SGML. It has quite a few completely new very fundamental features, such as namespaces. It is an entirely new language; only its syntax is loosely based on SGML's.

Bob90
05-19-2007, 09:21 PM
It is a simplified subset of the Standard Generalized Markup Language (SGML), and is designed to be relatively human-legible. By adding semantic constraints, application languages can be implemented in XML. These include XHTML,[3] RSS, MathML, GraphML, Scalable Vector Graphics, MusicXML, and thousands of others. Moreover, XML is sometimes used as the specification language for such application languages.

http://en.wikipedia.org/wiki/XML

Well at least I thought it was. You should edit the wiki page to what it really is as it has confused me.

:eek:

Bob90
05-20-2007, 08:31 AM
Abstract
The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.

http://www.w3.org/TR/2006/REC-xml-20060816/

Just so you know how it can be confusing.

Twey
05-20-2007, 10:10 AM
Oh, apparently it is. My apologies, seems I was wrong :p

mwinter
05-20-2007, 02:00 PM
So back to schema instead of backbase.

Schemata? They are a means of validating XML documents, and are rather heavy-weight. I would be surprised to see schema implementations in browsers - certainly on mobile and embedded devices, where the ease of parsing has its greatest benefits.



Thats the major advantage of XML; defining your own data structure.

We didn't need XML do to that. SGML was quite capable, only browsers don't treat HTML as an application of SGML. Moreover, there are enough user agents with a wide enough market share that won't process XHTML as an application of XML, either.



XML is a subset of SGML and XHTML is based from that.

With the right extensions to SGML, including the correct SGML declaration, XML is a proper syntactic subset of SGML. However, whilst an XML processor might be written with a knowledge of namespaces, XIncludes, and other such things, an SGML processor will not.

As for XHTML, it is little more than a copy of HTML, albeit expressed in XML.



I thought the future lay with SGML databases, which could be used locally for rich data applications and data from that could easily be parsed for the web

If, by locally, you mean client-side, SGML isn't a possibility. It's too complex. That's the point of XML: it's simplicity.

Even using XML, what exactly does any of this have with serving XHTML (the point of the debate)? One doesn't need to do the latter to use the former.

Bob90
05-20-2007, 02:58 PM
mwinter
Schemata?
Schemas/Schemata lets not be pedantic. Actually it's more fun. While schemata is 'more' correct, both are used widely. W3C uses schemas.



mwinter
They are a means of validating XML documents, and are rather heavy-weight. I would be surprised to see schema implementations in browsers - certainly on mobile and embedded devices, where the ease of parsing has its greatest benefits.

I fail to see how, if the w3c are looking into schemas, they will not be used on the internet. For example I’m sure you’ll be seeing a lot of this schema in the near future.
http://www.w3.org/Math/XMLSchema/ :P
If you haven’t seen it before I suggest you look at it (Well, OK, only if you’re interested in mathematical notation on the web like me). This is just one example.



mwinter
We didn't need XML do to that. SGML was quite capable, only browsers don't treat HTML as an application of SGML.

I don’t believe I said HTML was ever a subset of SGML or was ever treated as one. Yes SGML is (not was) very capable of that. SGML is considered too ‘rich’ for the net.



mwinter
Moreover, there are enough user agents with a wide enough market share that won't process XHTML as an application of XML, either.

Not yet anyway. Lets not get into the size of the browser, cause we all know that an XML browser would be light-weight compared to the monsters that parse HTML. And hence more suitable for mobile devices.


w3c
XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4 [HTML4]. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents. The details of this family and its evolution are discussed in more detail in [XHTMLMOD].
XHTML 1.0 (this specification) is the first document type in the XHTML family. It is a reformulation of the three HTML 4 document types as applications of XML 1.0 [XML]. It is intended to be used as a language for content that is both XML-conforming and, if some simple guidelines are followed, operates in HTML 4 conforming user agents. Developers who migrate their content to XHTML 1.0 will realize the following benefits:
http://www.w3.org/TR/xhtml1/#xhtml



mwinter
As for XHTML, it is little more than a copy of HTML, albeit expressed in XML.
Yes you are right here. (See reasoning above: so that it can be parsed similar to XML).




mwinter
If, by locally, you mean client-side, SGML isn't a possibility. It's too complex. That's the point of XML: it's simplicity.

By locally I did not mean client-side, sorry for the confusion. I meant companies use SGML to store their documents locally to them. This information could then be parsed and used on the internet, as (at the moment XHTML) XML when more browsers support it.



mwinter
Even using XML, what exactly does any of this have with serving XHTML (the point of the debate)? One doesn't need to do the latter to use the former.
The point of the debate was the use of .innerHTML and how using XML in the future would make this obsolete.

(I suggest we use a different thread for this as it has clearly become about something else.)

mwinter
05-20-2007, 03:32 PM
(I suggest we use a different thread for this as it has clearly become about something else.)

Agreed. I didn't read your entire post, and that sentence specifically, before I started replying.




Schemas/Schemata lets not be pedantic.

You misunderstand. I wasn't trying to correct you, I was just surprised that the topic was highlighted.





They are a means of validating XML documents, and are rather heavy-weight. I would be surprised to see schema implementations in browsers - certainly on mobile and embedded devices, where the ease of parsing has its greatest benefits.

I fail to see how, if the w3c are looking into schemas, they will not be used on the internet.

Please, read more carefully. I never wrote that schemas would never be used, just that I think it unlikely. Why, the current crop of XML processors that are used with XHTML documents won't even validate against DTDs. The XML schema recommendation is even more complex and resource intensive, which goes against the point of XML.

Schemata may be used for Web development during the formation and transformation of XML documents, but I would expect them to remain there, behind the scenes.



I don’t believe I said HTML was ever a subset of SGML or was ever treated as one.

Nor did I indicate that you did. However, your statement: "Thats the major advantage of XML; defining your own data structure." implies that XML is unique in that feature, but it isn't.



Yes SGML is (not was) very capable of that.

I used past tense as it is less significant from the point of view of the Web.



SGML is considered too ‘rich’ for the net.

Quite, and not without some justification.



Not yet anyway.

Which is the surprising thing. XML and XHTML are by no means new, though the hype surrounding the two is relatively so. This raises the question (and it's not one I expect answered): if XML is so old and so easy to implement (in relative terms), why is support not universal already?



Lets not get into the size of the browser, cause we all know that an XML browser would be light-weight compared to the monsters that parse HTML. And hence more suitable for mobile devices.

Of course, which only adds to the puzzle. Perhaps it's just Microsoft's lack of concern for its browser, allowing it to languish in the content that the corporation is top-dog. Then again, maybe not.



By locally I did not mean client-side, sorry for the confusion. I meant companies use SGML to store their documents locally to them. This information could then be parsed and used on the internet, as (at the moment XHTML) XML when more browsers support it.

I can certainly see that happening in some limited cases, but I still wonder whether SGML would be a stumbling block given that even XML seems challenging in some quarters. Even if it isn't technically, I wonder if it will be financially as - so I've read on Usenet in the past - capable SGML-based software didn't (doesn't) come cheap.



The point of the debate was the use of .innerHTML and how using XML in the future would make this obsolete.

That was the point, just as it was about finding a particular character within an element. It seems to have changed again since then. :)

Bob90
05-20-2007, 04:10 PM
Quote:
I donít believe I said HTML was ever a subset of SGML or was ever treated as one.
Nor did I indicate that you did. However, your statement: "Thats the major advantage of XML; defining your own data structure." implies that XML is unique in that feature, but it isn't.

It is compared to HTML.


why is support not universal already?
Becasue, like many before, we had no need until now. HTML was suitable. It should be superceeded by XHTML/XML.


Schemata may be used for Web development during the formation and transformation of XML documents, but I would expect them to remain there, behind the scenes.

I linked to MathML for a reason; that it would be great to have equations with meaning on the web. This schema is already implemented in Firefox.
http://www.mozilla.org/projects/mathml/
I believe it only works within XML(XHTML)

mwinter
05-20-2007, 06:46 PM
It is compared to HTML.

As commonly implemented. :)



Becasue, like many before, we had no need until now. HTML was suitable. It should be superceeded by XHTML/XML.

Is there actually any need for it now?



I linked to MathML for a reason; that it would be great to have equations with meaning on the web. This schema is already implemented in Firefox.

The markup language is implemented, but Firefox couldn't care less about schemata (http://groups.google.com/group/mozilla.dev.tech.xml/msg/96a584973d86acb0) (May 9, 2007).