no more hardcoded html inside .js files. actually, i cannot say how much html is hardcoded. but i expect there to be new skins for at least the most frequently used html tags with many attributes (like img, a, input). i don't want to make promises but i think in the end there will be between 5 and 10 more skins...

and, uhm, yes, the encoder output of the br tag i already changed to <br />. is that ok, too?

but the place where this is probably more important is in helma/util/HtmlEncoder.java. Feel free to change it there too (just search and replace "<br>), otherwise I can do it.

PS: I propose writing empty tags without space between element name and slash. I think that's the more common way to write them.

"IMPORTANT Compatibility Note: To make your XHTML compatible with today's browsers, you should add an extra space before the "/" symbol like this: <br />, and this: <hr />." (source).

see

the browsers won't complain if a story or comment contains invalid xhtml and this is mixing up with the default, (hopefully) valid antville markup. i won't use the strict doctype anyway, but the transitional one. and your proposal sounds like a lot of work, honestly (rage, rage, rage!)

maybe my comment was too short. i think it is necessary that all antville code is valid in xhtml. what i was referring to is given the admin an easy menu to change the doctype used the template. but this is not an issue if browsers do render invalid xhmtl sufficiently well.

but we don't even need the skin, I think. Since HTML and XML tags always look the same (and this is infact cast in stone for eternity), we could directly write out the formatted tag in the global renderMarkupElement() function.

Very smart + elegant!

Re: fexibility: This is a perfect solution whenever tags are "pushed" from the code. When they're pulled together from skins, the skin author has to do with what macros are provided anyway, so I'd say this is nothing to worry about here.

this looks fabulous! +1 for directly writing out the tag in renderMarkupElement(), and one question:

in your example you have attr.style = param.style; which i assume will end up as style="[css-definition]". now using an additional parameter "class" is prohibited by Fesi ("EcmaScriptParseException: Keyword ' class' reserved for future extension"), what about "sclass"? (not as nice, i know ...)

because id will do the same (you just have to define your custom styles as "#cssDefinition", ie. using the hash instead of the period).

and no problem with backwards compatibility, because we can define both, the old "classes" as well as the new "ids" in one stylesheet:.title, #title {...}

thanks for supporting my proposal. i will include the tag in the code and get rid of the htmltag skin.

to be forced to go one way or the other because something in the underlying technology interferes. But I think using

param["class"] = "...";

instead of

param.class = "...";

we can smuggle it past the parser.

if that'll work, i'll happily add it to the code. thanks!

sorry, tobi, i didn't have the time 'til now. i'll give it a try tonight.

If your changes are in the main branch then I'm using them already. Didn't see any special behaviour, but all i did was rendering main.hac pages.

the first steps i made (until i wrote the story above) i checked into the main cvs branch. however yesterday, i continued with the work and created a new branch called "devjamtobi". there are just too many lines of code that i had to touch, i was afraid to put it in the main branch. and because this time i already know that there are bugs in my current code, i think this was a good decision, too.