tin-tags standards compliant

[Thomas M. Farrelly]

hi,

Earlier, when I made the announcement about tin-tags, a js framework that
I have written, I got a lot of negatives about it not working in other
browsers than Firefox. Which was true and reasonable.

I've removed the hackish approach, and opted for a solution that uses
namespaces. This is a good idea, and gives a very clean implementation. I
also avoid the whole xhtml thing by only allowing tin-tags in xml.
Tin-tags now works in Firefox, Opera, Netscape, Konqueror and Galeon. I
have only tested it with recent versions of those browsers. It is at
www.tin-tags.org.

When attempting to port to IE, I immediately ran across a major obstacle.
Namely that IE does not give out the namespaceURI of an element to
javascript. Earlier I also noticed that IE throws away unrecognized tags
as well ( Konqueror does this too, though it supports namespaces ). The IE
environment is not very hospitable to my project.

I think I have figured out a solution to this, though. It involves using
xslt to extract the namespace URI or prefix. Either translate

<n:tag>

to

<n:tag class="n">

or something like that. Does this make sense? Is it possible to get to the
namespace data using XSLT and move it into js? Does anyone have a script
that populates a document with the namespace information?

Also I consider using either sarissa and/or the cross-browser/xlibrary.
They both seem nice. It would be nice to get some feedback from people who
have experience writing cross-browser websites.

Thanks in advance.

 

[Richard Cornford]

Earlier, when I made the announcement about tin-tags,

You announced that you had "released" it, and then admitted that it was
beta at best, which seemed contradictory.

a js framework that I have written, I got a lot of negatives
about it not working in other browsers than Firefox.

You did make the announcement in a group primarily interested in
cross-browser scripting for the web, so that sort of reaction should
hardly have been surprising.

Which was true and reasonable.

You did completely fail to mention what exactly it was that you thought
your 'framework' was for. If you don't include that sort of detail it
can look like your primarily interest is promoting the posted URL, i.e.,
spamming. That is something else that is unlikely to be well received
here.

I've removed the hackish approach, and opted for a solution
that uses namespaces.

Unfortunately the term "namespace" is (often inappropriately) applied to
too many things in javascript for you to be saying anything useful here.
I am going to assume you mean namespaces as the term applies to
qualifying XML element names.

This is a good idea, and gives a very clean implementation.
I also avoid the whole xhtml thing by only allowing tin-tags
in xml.

But XHTML is XML.

Tin-tags now works in Firefox, Opera, Netscape, Konqueror and
Galeon. I have only tested it with recent versions of those
browsers. It is at www.tin-tags.org.

When attempting to port to IE,

No, you are not going to be able to port this to IE. IE is an HTML web
browser.

I immediately ran across a major obstacle.

Yes, that IE is an HTML web browser.

Namely that IE does not give out the namespaceURI of an
element to javascript.

HTML element don't have namespaceURIs (or at least they don't need to be
exposed in HTML DOMs)

Earlier I also noticed that IE throws away unrecognized
tags as well

That is a fairly HTMLish thing to be doing, so hardly unexpected.

( Konqueror does this too, though it supports namespaces ).
The IE environment is not very hospitable to my project.

As it stands I would expect your project to be a complete non-starter on
IE, and so have no commercial applications at all (hence my interest in
what purpose it is supposed to have).

I think I have figured out a solution to this, though. It involves
using xslt to extract the namespace URI or prefix. Either translate

<n:tag>

to

<n:tag class="n">

or something like that. Does this make sense?

What you are saying makes sense. Assessing the idea/strategy in context
is not possible until you explain the context.

Is it possible to get to the
namespace data using XSLT and move it into js?

Almost certainly, but to what end?

Does anyone have a script that populates a
document with the namespace information?

And script based XML parser implementation (that builds an XML document
DOM) must populate its document with namespaces, but that may have
nothing to do with what you are talking about.

Also I consider using either sarissa and/or the
cross-browser/xlibrary. They both seem nice.

Nice? Polite, respectable, know which knife and fork to use with witch
course at dinner? The sort of libraries you wouldn't mind introducing to
your sister? ;-)

It would be nice to get some feedback from people who have
experience writing cross-browser websites.

Richard.

 

[Thomas M. Farrelly]

"Thomas M. Farrelly" wrote:

Tin-tags allows you to create your own tags using object oriented
concepts. This allows for good reuse and structuring of code. Tags can
be both classes and instances, they can specialize other tags, you have
multiple inheritance and instantiation and there is easy to use message
passing facilities to communicate between different components in your
web-pages, and you can modify the OO object model both locally and
globally. It also gives, in my opinion, a _nice_ way to integrate
javascript code in web-pages. There is a complete site example on the
project pages that demonstrate these features, but the documentation is
very sparse. There are also a number of modules that provide useful
tin-tag classes and mechanism and provide examples of usage.

The tags that are created exist in a seperate namespace. My
understanding is that this is a legitimate use of the xml namespace
mechanism. This is all XML, though the xhtml namespace is used in addition
to the tin-tag namespace.

The script inspects all xml fetched from the server and instantiates all
tin-tags. In order for the script to determine which tags are tin-tags it
needs to have access to the namespace information of each element node.

if ( node has tin-tags namespace ) {
instantiate the tin-tag node
} else {
ignore it ( probably an xhtml element )
}

And script based XML parser implementation (that builds an XML document
DOM) must populate its document with namespaces, but that may have
nothing to do with what you are talking about.

That would be the kind of script I am looking for. A replacement for
DOMParser written in javascript.

I am confident that it is possible to make tin-tags work in IE.

 

[Richard Cornford]

Tin-tags allows you to create your own tags using object
oriented concepts.

Create my own 'tags'? Where exactly would that get me?

This allows for good reuse and structuring of code.

Which code (tags being components of mark-up languages) and how?

Tags can be both classes and instances, they can specialize
other tags, you have multiple inheritance and instantiation
and there is easy to use message passing facilities to
communicate between different components in your web-pages,
and you can modify the OO object model both locally and
globally.

<snip>

Whatever it is that you are labelling 'tags' here seems very detached
from any accepted uses of the term. That is, you are not actually saying
anything here.

Richard.

 

[Thomas M. Farrelly]

Create my own 'tags'? Where exactly would that get me?

It allows you to create tags that look and behave according to your
specification. Your new tags use attributes as parameters. For example:

<tin instance="system/include" source="files/some-page.xml" />

It fetches a piece of xml, that can include for example other tin tags as
well as xhtml tags, and puts it into the content of the tag.
'system/include' is the new tag, created by yourself ( or me in this case
), that allows you to do exactly that. 'source' is a parameter, and
'instance' is an attribute that all tin-tags understand. 'system/include'
is defined in the 'tin/init.xml' module.

You use tin-tags to create new tin-tags. Here is the sourcecode that
creates 'system/include' and as a consequence allows the webdesigner to
easily include xml into a webpage.

<tin name="include"
init="
this.does( function() {
var that = this ;
this.removeContent() ;
this.send( this.getAttribute( 'source', '' ), function() {
that.appendContent( this ) ;
} ) ;
} ) ;
"
/>

Actually, this only allows you to copy xml inside the page. There is a
messaging mechanism and the 'system/resource' tin-tag allows you to create
a "channel" for transparently communicating with the server.

<tin name="resource"
init="
this.instance.send = function( path, tinReceive ) {
this.httpRequest( this.getAttribute( 'directory', '' ) + path,
( function() {
tinReceive.apply( this, [] ) ;
} )
) ;
return ( this ) ;
} ;
"
/>

Now you can declare new directories ( "resources" ).

<tin name="files" instance="system/resource" directory="" />

This makes 'files' into a mirror of the root directory on the server. As
if all the files on the server were present in the page on the
client side inside the 'files' tin-tag. Messages to the server are
currently always "read only", but as an upside, 'system/resource' enables
any tin-tag to use this service. For example 'system/include'.

<tin instance="system/include" source="files/some-page.xml" />

This sends a message "though" the 'files' resource to the 'some-page.xml'
tin-tag. The message is: "copy the xml into the tag".

In the site-example that can be downloaded, there are more down to earth
examples featuring menues, layout and templates.

<snip>

Whatever it is that you are labelling 'tags' here seems very detached
from any accepted uses of the term. That is, you are not actually saying
anything here.

The word 'tag' is used to mean what it means in the context of XML. XML is
short for eXtensible Markup Languages. To my understanding you are actually
supposed to define new tags when working with XML. That is the purpose of
XML. That and nothing else.

When it comes to porting this to IE, I have made progress. IE is happily
putting my tin-tags into the document object where I have access to the
tintag attributes. IE is of course ignoring my namespace declaration, which
is no big surprise and not a big problem. The above code example works in
IE - it imports and instantiates the tin-tags as it is supposed to. There
are issues, though. It throws some errors that are hard to find the cause
of, so the site isn't working yet. I'm doing this offline. The debugging
tools I'm using are pretty useless:-(

 

[Richard Cornford]

It allows you to create tags that look and behave according to
your specification.

The word 'tag' is used to mean what it means in the context
of XML.

<snip>

So, as XML does not define 'tag' at all but instead asserts that it is
"an application profile or restricted form of SGML", it must be the SGML
defenition of 'tag' that is applicable here. Well I have ISO 8879 at
hand so I can look that up. Section 4 "Definitions" seems like a
reasonable place to start:-

| 4.314 tag: descriptive markup.

- so look up 'descriptive markup':-

| 4.92 descriptive markup: Markup that describes the structure
| and other attributes of a document in a non-system-specific
| manner, independently of any processing that may be perfored
| on it. In partiucalr, it uses tags to express the element
| structure.

So a 'tag' (as the term is used in SGML/XML) is something that is used
in markup to express the element structure of a document in a
non-system-specific manner. Fine, so where does the ability to create
one "using object orientated concepts" get me?

Richard.

 

[Thomas M. Farrelly]

I'm sure people here understand what one refers to when using the word
'tag'. I am tired of discussing this with you, Richard. You can stop now.

cheers!

 

[Animesh K]

I'm sure people here understand what one refers to when using the word
'tag'. I am tired of discussing this with you, Richard. You can stop now.

cheers!

He is very well exposing that you don't even understand the difference
between XML, XHTML, HTML, etc. Your work seems at the beginner's level,
at best.

I think you should stop arguing and focus more on basics.

 

[Thomas 'PointedEars' Lahn]

Tin-tags allows you to create your own tags using object oriented
concepts. This allows for good reuse and structuring of code. Tags can
be both classes and instances,

ISTM you have not understood that the programming language you are
developing this for is not class-based.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<tin name="resource"
init="
this.instance.send = function( path, tinReceive ) {
this.httpRequest( this.getAttribute( 'directory', '' ) + path,
( function() {
tinReceive.apply( this, [] ) ;
} )
) ;
return ( this ) ;
} ;
"
/>

XML attribute values SHOULD NOT contain newline characters.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<snip>

So, as XML does not define 'tag' at all

It does.

http://www.w3.org/TR/REC-xml/#sec-starttags

but instead asserts that it is "an application profile or restricted
form of SGML", it must be the SGML defenition of 'tag' that is
applicable here.

Since XML is a application profile/restricted form of SGML, both apply.

http://www.w3.org/TR/REC-xml/#sec-intro


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn :

That's news to me. Any references?

AIUI, that recommendation is implicit:

http://www.w3.org/TR/REC-xml/#AVNormalize


PointedEars

 

[Thomas 'PointedEars' Lahn]

[Thomas 'PointedEars' Lahn] XML attribute values SHOULD NOT contain
newline characters

[Johannes Baagoe] That's news to me. Any references?

[Thomas 'PointedEars' Lahn] AIUI, that recommendation is implicit:

Please don't use initials of any kind (and certainly not those) for quoting:

http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1LwQu

Which is exactly why your "SHOULD NOT" surprises me, since if there should
be no newline characters in attribute values, it hardly seems worth the
trouble to explain at such length what happens to them when they are there.
One does not usually make rules for round squares.

From the requirement of attribute value normalization in XML follows that
newline characters are not parsed into newline characters. Especially with
a programming language that uses automatic semicolon insertion such as
J(ava)Script/ECMAScript, that feature can render the code syntactically
invalid or change its meaning.


PointedEars

 

[Jeremy]

Tin-tags allows you to create your own tags using object oriented
concepts. This allows for good reuse and structuring of code.

There was a time when this sort of thing seemed like a good idea to me
as well. I thought it would be great to use my own tags and then make
them function using DOM manipulation. I invented tags such as <slider>
and <panel> and <dock>, under my own namespace (i.e. <nifty:dock>). I
thought I was a friggin' genius.

I had no trouble getting it to work perfectly cross-browser. IE does
not "throw away" tags that it does not understand. You just have to
find them in a slightly different way. For example,
getElementsByTagName("dock") will return the <nifty:dock> element on one
browser, but on another you have to use
getElementsByTagName("nifty:dock"). It's hardly surprising that this
isn't consistent, because nifty:dock is not a legal tagname in HTML.

In practice, this all worked fine, and from one point-of-view it was
pretty cool as a developer to have such clean, self-commenting markup.
So why did I shortly thereafter realize that it was at best a pointless
exercise?

Because niceties for the developer, ultimately, do not matter one bit.
Designing an application is about making it work best for the user. Not
the developer. If the developer is too lazy to type out valid markup,
he (or she) should take their lazy markup and transform it server-side
to valid markup. You should not risk users getting screwed over by some
non-functioning quirks for the sake of your laziness.

And that is my opinion.

Jeremy

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn :

Why not?

Because they are not part of the quoted text, and so cause confusion as to
what is the initial and what part of the the quoted text. Especially as
bracketed prose is suitable and used for summaries of quoted text.

Did the result wrap improperly?

Inevitably. The first line started with the "> " followed by the initial
followed by quoted text, the second line (after wrapping) started with the
"> " and quoted text.

I find that the mention of the author's name in brackets the first time
that author is quoted makes it easier to remember how many ">"s are
associated with whom, especially when using newsreaders that add colour.

Coloring is another reason why initials should not be used, as delimiter
characters in the initials such as ":", "[", and "]" can be misrecognized
as quotation level indicators. That would color the quotation to be of at
least one level deeper than it actually is.

The usual practice has an annoying way of associating the author whose
name is preceded by n angles with text marked by n + 1 angles.

The usual practice is one that is widely recognized by people and supported
by their newsreader software. I don't find it annoying in any way, because
the quotation levels are the logical way to mark quotes, and they make it
easy to trim those quotes. A quoted B, but B may have quoted C before aso.
With separate attribution lines and quotation levels, that is made clear.
In longer discussions, I also would not mind the required attribution lines
to be repeated above each longer quoted section to see without further
scrolling who wrote what.

Still, if you confirm that you don't like my way of treating multiple
quotes, or even better, point out a real drawback, I won't do it again.

Thank you in advance.

I have tried hard to find an example, but without success.

var foo = function(y)
{
return
--y;
}

var x = foo(2);

compared to

var foo = function(y) { return --y; } foo(2);

Yes, if the semicolon would have been inserted explicitly before the foo()
call, it would not have been parsed into syntactically invalid code, but the
meaning would also have changed from foo() returning `undefined' in the
first case 1 in the second one. (And that could have been avoided with
appending a semicolon after `return'.)

The issue here is the same as it is with code minimizers: newlines reduced
to space require many expressions to be delimited or the result is often
syntactically invalid code. That is why code that is minimized this way
may end up being *larger* than the original code.

Unless, that is, the offending newline is between (single) quotes: that
could change the meaning, but not, AFAICT, render the result syntactically
invalid.

Yes, in that case it would only change the meaning because it would render
the parsed content syntactially valid although the original was not
(unterminated string literal).

Attribute value normalization certainly has an impact on other content.
Multi-line attribute values also make the content harder to maintain (see
`style' attribute values), so they should be avoided. With XML, element
CDATA content should be used instead.


PointedEars

 

[Thomas M. Farrelly]

ISTM you have not understood that the programming language you are
developing this for is not class-based.

It doesn't matter that javascript is not class based.

Let me give an example of why tin-tags need to differentiate between
subclassing and instantiation. Lets say the following code define and
use the concept of buttons.

<tin name="button" ... />

...

<tin instance="button" caption="submit" ... />
<tin instance="button" caption="reset" ... />

If I did not differentiate between subclassing and instantiation, then the
definition of 'button' would be a button itself. And you do not want that.
( Read this paragraph again, please. )

However, tin-tags are _not_ either classes or instances. They are allways
both. So the object model is in fact best described as prototype based. It
is just that all objects allow subclassing and instantiation unlike
traditional class-based object models where only classes allow
those operations and instances do not.

 

[Thomas M. Farrelly]

There was a time when this sort of thing seemed like a good idea to me
as well. I thought it would be great to use my own tags and then make
them function using DOM manipulation. I invented tags such as <slider>
and <panel> and <dock>, under my own namespace (i.e. <nifty:dock>). I
thought I was a friggin' genius.

I agree that creating custom tags left and right is not a good idea. I am
not doing that. I have a framework that handle this in a organized fashion.

[...]

Because niceties for the developer, ultimately, do not matter one bit.
Designing an application is about making it work best for the user. Not
the developer. If the developer is too lazy to type out valid markup,
he (or she) should take their lazy markup and transform it server-side
to valid markup. You should not risk users getting screwed over by some
non-functioning quirks for the sake of your laziness.

"Niceties" for developers matter. Writing and maintaining software takes
alot of effort. Simplifying software development is a good thing.

I see two primary things you may want to do to a web-page.

1. Place something in the page.
2. Specify something about a part of the page.

The page is described using markup. Markup does both 1 and 2 but is
limited. Additionally, you probably use CSS to do 2, but it is
limited to cosmetics. So you need javascript.

In my opinion extending the markup is a better approach then having
scripts somewhere that finds elements in the page and patches
them.

I want to give an example using templates. It shows how to create new
tags without using javascript. Templates are defined in 'tin/template.xml'.
A template lets you create new tin-tags using patterns.

<tin name="term" instance="template/template" >
<xhtml:b>
<tin instance="template/attribute" label="term" />
</xhtml:b>
<tin instance="template/tag" />
<xhtml:br/>
</tin>

Now you can write:

<tin instance="term" term="someword" >
some definition
</tin>

to get html equivalent of:

<b>someword</b> : some definition <br>


Templates can be arbitrarily complex. In my opinion this is good stuff.

 

[Thomas M. Farrelly]

Don't forget &lt; &gt; &amp; and &quot;

;-)

 

[Thomas 'PointedEars' Lahn]

Don't forget &lt; &gt; &amp; and &quot;

;-)

Are you referring to something?


PointedEars

 

[Jeremy]

A template lets you create new tin-tags using patterns.

<tin name="term" instance="template/template" >
<xhtml:b>
<tin instance="template/attribute" label="term" />
</xhtml:b>
<tin instance="template/tag" />
<xhtml:br/>
</tin>

Now you can write:

<tin instance="term" term="someword" >
some definition
</tin>

to get html equivalent of:

<b>someword</b> : some definition <br>


Templates can be arbitrarily complex. In my opinion this is good stuff.

But in this case, what's wrong with using the final markup to begin
with? (In fact, for the example you gave, there are semantic XHTML tags
for that precise purpose - dl, dt, and dd - which would be styled
appropriately using CSS.)

Can you give me an example of the benefit of serving <tin...>...</tin>
and transforming it with javascript on the client side, rather than
either a) writing out the final markup to begin with, or b) using custom
markup on the server side, but transforming it before it gets to the client?

I am not saying your idea is useless; it's not my place to say so. I'm
just saying I can't think of any scenario when doing this kind of work
client-side is better than doing it server-side.

I agree that extensible markup is a really good idea in theory. This is
essentially the purpose of XHTML. In theory, it could make for clean,
beautiful code that works wonderfully for both the developer and the
user. In practice, this will not happen in the foreseeable future.
These things are extremely difficult to standardize, and even once they
are standardized, they won't be adopted because nobody will use them
unless Microsoft supports them - and Microsoft can't be bothered.
Hacking such support into place with Javascript is essentially trading
off client-side robustness for the benefit of the developer.

I have no problem with making things easier on the developer. You just
have to realize that the user is infinitely more important. The
application will only be developed once, but will be used by (hopefully)
incalculable multitudes, with no guarantee that your shortcuts will work
as intended. If you are trading off their experience for yours, when a
little extra typing will do the trick, you are making the wrong choice IMHO.

Jeremy