Creating custom tags/attributes .. just invalid of unacceptable?

[shachi]

Hello all,
I thought this was a HTML related post so I posted here, if I am wrong then I apologize.

The title must have cleared the point. If not can anyone tell me that using custom tags in HTML using javascript is just invalid or unacceptable?? What I mean is, "Is using custom tags/attributes invalid for the w3c standards?" or it is completely illegal(sorry could not find an appropriate word). I am asking this because I have tried to use custom attributes in one of my scripts.

Thanks everyone.

[djr33]

From my limited knowledge, I believe it would be "wrong" but not change functionality.

I believe that, due to updates to html, browsers are designed to ignore any tags/attributes they are now programmed to handle.

For example:
<iframe>this text is displayed if iframes are not enabled</iframes>

The text isn't displayed on old browsers because they are programmed to, but rather because they aren't programmed not to. The iframe tags are ignored, and the text isn't, because the old browsers don't know not to. The new browsers are programmed to ignore it and replace with the iframe.

Also, obviously attributes are ignored... <a djlkasdfjalsjfk="something" href...> won't cause an error. (But it won't validate.)

However, I'd think this isn't great practice for some reasons, so might not be a good idea.

The way to avoid this, if you need something like extra markups in the code is to use comments:

<!--mytag-->.........<!--/mytag-->

Javascript could interpret that just as easily, and it would cause no errors nor validity problems.

Hope this helps.

[shachi]

Well, in one sense this does help but can you tell me how do I make that <!--mytag--><!--/mytag--> thing work?? And what about attributes?? Can I use them?? By the way if I use my own custom dtd or xml scheme then is it possible to use custom tags/attributes without violation of the HTML 4.0 spec and validate it successfully??

Sorry for a lot of questions.:p But I am just a newbie.

Thanks again!!!:)

[djr33]

I really have no clue about the technical sides of things.

As I said... basically.... anything the browser is not specifically programmed to deal with, is ignored. (I think.)

You can't just make markups. Actually, I started a thread about this quite a while ago. Maybe there was some info in there, but the basic answer was no.
If you want to make your own, then you could have some, and interpret them with php, javascript or something else, but you'd need something more than html (and it wouldn't be particularly easy).

For the comments, that's just a comment. I just made it look like an html tag.
<!--comment here and it's ignored by html....-->
So... you can put whatever you want in there and it'll just be in the source-- not interpreted by the browser as a tag AND not displayed as text. That's what comments are for.

Comments, I have seen, are used in text files to be used in php, for example:
<!--new user data starts here-->
and php will recognize that and do some different formatting with the contents seperated at that point.

From the phrasing of your question, I assumed that you knew what you would do with it and just wanted to know if it was valid in html.
I assume there is a way to use javascript, or whatever language you want, to do something with the tag, but it depends on what you want (at least how to do it depends on that).

Not sure what you are asking about attributes. With the right coding, you could use <!--mytag attribute="..."--> and have that do something, assuming the javascript/php/etc could output the right result from that.

If you are asking about just using custom attributes, you should note that, as I said, they are ignored if not supported.

Created a custom doctype/dtd.... hmm....
I don't think this alone would create functionality for a tag. I would think the tags are hard coded into the browsers, at least generally. The dtd might be able to, for example, tell the browser to ignore a tag, or specify a particular way to handle a tag, but I don't think it could actually add a tag (or attribute).


Most of this is just guessing, based on what I've seen.

[shachi]

Thanks for you reply. I don't really think that browsers usually ignore tags/attributes which are not hard coded in them. For e.g try this in FF(only works in FF).



<html>
<head>
<script type="text/javascript">
window.onload = function(){
redlist = document.getElementsByTagName("RED");
for(var i=0;i<redlist.length;i++){
redlist[i].style.color = "red";
}
}
</script>
<body>
<red>test</red>
</body>
</html>

[boxxertrumps]

arent you able to create your own doc-type though? and wouldnt that include programming your own tags/atributes?

[mwinter]

If not can anyone tell me that using custom tags in HTML using javascript is just invalid or unacceptable??

Using either custom elements or attributes will produce invalid markup. Using custom elements is pointless as they'll be ignored and may never make it into the document tree. The same is true more-or-less the same for attributes, though some browsers may add them to the document tree.



I am asking this because I have tried to use custom attributes in one of my scripts.

Why? If it's data for scripts, then why is it in the markup? You can quite easily associate information with an element by storing it an object and using the id attribute value (or name, for form controls) to identify that data.




I believe that, due to updates to html, browsers are designed to ignore any tags/attributes they are now programmed to handle.

It is, as I understand it, for the sake of handling various proprietary extensions implemented by different browser vendors, particularly during the early Web when elements and attributes were implemented left, right, and centre with little (or no) consensus.



The way to avoid this, if you need something like extra markups in the code is to use comments ...

I wouldn't recommend that much, either. If something really is content, it can either be marked up with the proper element, or a generic (div or span). There should be no need at all to start inventing new things. If that thing isn't content, it shouldn't be in the markup at all.




By the way if I use my own custom dtd or xml scheme then is it possible to use custom tags/attributes without violation of the HTML 4.0 spec and validate it successfully??

No. The HTML specification defines what HTML is. It cannot be extended or augmented. One can write a DTD that defines extra elements or attributes, write a document that uses them, and have it validated. However, that document is not HTML.

More the point, why do you think this would actually be useful? No browser will understand these new items. They won't assign meaning, but simply ignore them as something alien and pointless.




The dtd might be able to, for example, tell the browser to ignore a tag, or specify a particular way to handle a tag, ...

No, it cannot. The document type definition simply specifies the set of elements, their attributes and content models, and the entities that can be used in a document. The meaning of an element or attribute is defined in the prose of a relevant specification, and only there.




I don't really think that browsers usually ignore tags/attributes which are not hard coded in them.

Yes, they do. Adding an element or attribute to the document tree doesn't mean that any significance was attached to it - that would simply be a blind action on the part of the tag-soup parser.

All bets are off when one starts doing this sort of thing, which is precisely why one shouldn't.



... (only works in FF)

Thank you for making my point.

Mike

[djr33]

There's the answer... Mike's answer is more complete and correct than mine.

If you NEED to add a tag, use comments.
If you can use a div/span instead, do that... just give it a class and use css to format.

And, why?

There might be another way around it...

[jscheuer1]

Custom elements do not appear to work in IE. The example given also works in Opera though as does this:


<style type="text/css">
red {
color:red;
}
</style>


<red>Hi</red>

in both FF and Opera but, not in IE (IE thought it was javascript or active X by the way). The invented attributes and invalid to a particular element attributes thing is used in several DD scripts. Ajax Tabs comes to mind with its rev and rel attributes. Rev being invented, I think and rel, I believe invalid for the anchor tag with which it is used.

Another way can always be found.

As mwinter points out, the real problem is that these things cannot be relied upon cross browser, or even (I might add) in different situations, even if they do happen to work in some cases.

[shachi]

I don't need custom tags but attributes(because in the script I am developing(something like a rubber band selection script) there are a lots of identifiers for different objects and I can't use classes or ids the simple reason is that it needs to identify all the elements for different things like is it selected or not should it be dragged or not for more control) I hope I was able to clear my point.

[djr33]

(IE thought it was javascript or active X by the way)I'm laughing a lot right now. I'm tired. But that's funny. :D

IE is like a small child who can't quite walk or talk yet and you need to keep reminding not to do certain things, like stick his fingers in electrical sockets.



Shachi, to rephrase your question: "How can I put place-markers in html?" Is that right?

[jscheuer1]

I don't need custom tags but attributes(because in the script I am developing(something like a rubber band selection script) there are a lots of identifiers for different objects and I can't use classes or ids the simple reason is that it needs to identify all the elements for different things like is it selected or not should it be dragged or not for more control) I hope I was able to clear my point.

You can give an object properties, that is perfectly legal or whatever. You don't need to use an attribute. Once you have gotten an element say:


var band1=document.getElementById('b1');

You can then define all sorts of properties for it and these will remain with it and can be changed and checked just like attributes:


band1.pitch=0.5;
band1.angle=45;
band1.crl='red';

But, since you haven't hard coded them to the tag, they will not be seen as invalid HTML.

You could even assign these properties with a default set of values to an entire class of objects, just to get the ball rolling as it were. Each will be unique to its object and can be independently manipulated and read, from there on out.

[mwinter]

The invented attributes and invalid to a particular element attributes thing is used in several DD scripts. Ajax Tabs comes to mind with its rev and rel attributes. Rev being invented, I think and rel, I believe invalid for the anchor tag with which it is used.

Their use might be incorrect (I haven't looked at the script), but both attributes are valid for anchors and links. Both specify the relationship to the current document: rel indicates the forward relationship; rev indicates the reverse.

Mike

[jscheuer1]

Their use might be incorrect (I haven't looked at the script), but both attributes are valid for anchors and links. Both specify the relationship to the current document: rel indicates the forward relationship; rev indicates the reverse.

Mike

I would think that the href would be the forward relationship. Href always takes us forward in the heap of pages on the history stack unless it is a specific javascript:history.go(-1) type reference.

Documentation on their use with the anchor tag is rather circular (rel is the opposite of rev and rev is the opposite of rel) and, as these attributes usually are not used with the anchor tag, I didn't find any concrete examples. However, from what I could glean from the top results on Google for this no, they are not used correctly in the aforementioned script.

I've always gotten the impression that other than in rel's use with the link tag, as in rel="stylesheet" neither of these attributes has much value. This is not because the concepts (which I still really don't get) involved aren't of value but, due to an apparent lack of implementation in most browsers.

[mburt]

You can give an object properties, that is perfectly legal or whatever. You don't need to use an attribute. Once you have gotten an element...
Can you give variables attributes too?
Eg:

var win = "test"
win.hello = "foo"
alert(win.hello)

?

[jscheuer1]

Can you give variables attributes too?
Eg:

var win = "test"
win.hello = "foo"
alert(win.hello)

?

I don't see why not.

[Twey]

Indeed you can. Everything in Javascript is an object; even what would be primitives in other languages have constructors (Boolean, Number...).
You can then define all sorts of properties for [a DOM node]It's possible and safe in most browsers, but still frowned upon: the DOM model is meant to accurately reflect the layout of the document, and in this paradigm appending arbitrary properties to DOM nodes is analogous to using arbitrary HTML attributes.

[jscheuer1]

Indeed you can. Everything in Javascript is an object; even what would be primitives in other languages have constructors (Boolean, Number...).It's possible and safe in most browsers, but still frowned upon: the DOM model is meant to accurately reflect the layout of the document, and in this paradigm appending arbitrary properties to DOM nodes is analogous to using arbitrary HTML attributes.

In that case, you could have an object or variable. You could assign it an element as one of its properties:


var band1;
band1.el=document.getElementById('b1');
band1.pitch=0.5;
band1.angle=45;
band1.crl='red';

It would just make accessing the properties a little different visa vis the element with which they are still associated.

Ever the pragmatist, could you tell me of a case where assigning the property directly to the element object is really a problem. Reserved words and valid attribute names don't count, they should be avoided in all code.

[mwinter]

I would think that the href [attribute of links or anchors] would be the forward relationship.

It's only the destination; the target. There's no particular relationship.



Href always takes us forward in the heap of pages on the history stack unless it is a specific javascript:history.go(-1) type reference.

Sure, but that's the user's movement. It's not a relationship, as such, beyond the fact that one document is referencing another.



Documentation on their use with the anchor tag is rather circular (rel is the opposite of rev and rev is the opposite of rel) and, as these attributes usually are not used with the anchor tag, I didn't find any concrete examples.

True, they aren't going to be easy to come by. Usage with a link element is far more common (in a relative sense).



I've always gotten the impression that other than in rel's use with the link tag, as in rel="stylesheet" neither of these attributes has much value. This is not because the concepts (which I still really don't get) involved aren't of value but, due to an apparent lack of implementation in most browsers.

Other link relationships are used with link elements, but it isn't often apparent. MSIE certainly doesn't support them, and I don't think that Firefox will present the necessary controls (at least without an extension). However, both Opera and Mozilla will, as I'm sure other browsers do, too. The usual rendering (for anyone not aware) is a horizontal bar with labels like "Contents", "Home" (or "Start"), "Next", etc. that act like navigation links.

The concept is quite simple, really (and difficult to describe without stating the obvious). Consider, for example, a series of documents, each one following from the last. Links and anchors can use the rel attribute to signify the relationship to other documents in that series. The "next" link type would be used when linking to the document that immediately follows, whilst "prev" would be used when linking to the immediately preceeding document.

The HTML specification lists the various link types (http://www.w3.org/TR/html4/types.html#h-6.12) with a short description.

The rev attribute is a little odd. Rather than indicating the relationship from the current document to the one referenced by the href attribute, the order is reversed. That is, whilst



<link href="foo" rel="help">

suggests that foo provides help for the current document,



<link href="foo" rev="help">

would suggest that the current document provided help for foo.

Perhaps practical use would be aimed at tools, rather than users. For example, rather than write a sitemap, a spider would walk through a set of documents analysing the link relationships. Those relationships, more than anything else (like filenames or directory structure) would determine how that portion of the site was interlinked. Any other meta analysis, including that performed by search engines, might also benefit.




Can you give variables attributes too?



var win = "test"
win.hello = "foo"
alert(win.hello)


Objects, yes. Primitives, no. In the code above, win is a string value. When it appears in a member expression (specifically, dot or bracket notation to its right), it will temporarily be converted to an object. The property will be added to that object, both of which will then be destroyed. If win was a string object, the created property will remain:



var win = new String('test');

win.hello = 'foo';
alert(win.hello); // foo

By the way, be careful when using the term "attribute" instead of "property". In ECMAScript, properties (variables) have attributes that describe aspects of their behaviour: DontEnum, ReadOnly, and DontDelete. In a technical discussion, I'd assume if you were asking whether these attributes can be controlled (the answer to which is no - only built-in and host-defined properties can have them).




Everything in Javascript is an object

That is certainly not true. There are types, values, and objects, all of which are distinguished from one another. Types are the set of data values. For example, the Undefined type has only one value, undefined. Values (primitives) are data directly represented by the language. For example, string values are a finite, ordered sequence of 16-bit unsigned integers (that is, codepoints represented in UTF-16). An object is an unordered collection of properties, each of which may contain primitives or other values.



even what would be primitives in other languages have constructors (Boolean, Number...).

but that doesn't make your previous statement true. That just means that a subset of built-in primitives can be represented as objects, where an internal property of that object holds the value of its respective type.

Mike

[shachi]

Sorry guyz I couldn't reply for long(actually I wasn't here because I didn't have internet at home). But anyways thanks all for your time replying my question and sorry to bother everybody. So, does this conclude that using custom attributes is invalid "AND" unacceptable?

[Twey]

Ever the pragmatist, could you tell me of a case where assigning the property directly to the element object is really a problem. Reserved words and valid attribute names don't count, they should be avoided in all code.No. As I said, it's possible and safe in most browsers (although, I believe, theoretically speaking, some browsers could refuse to support it without breaking the DOM standard). However, that doesn't mean it's right. Invalid HTML will also work in every major browser today, but that doesn't make it equal in quality to valid HTML.
So, does this conclude that using custom attributes is invalid "AND" unacceptable?Invalid, certainly. "Unacceptable" is difficult to define. You won't suffer severely from using it, at least now (and probably in the future; Mozilla seems to actually encourage this with the introduction of prototype objects for DOM nodes), but I'd say it's definitely better to avoid it where possible.

[shachi]

So ... DTDs, XML schemes, et cetera. won't help would it?

[Twey]

Probably not, no.

[shachi]

Ok, thanks guyz, thanks everybody.