I agree - most of the problems listed in that article are at the core deficiencies in tools like PHP that offer no control over how HTTP resources are generated and served. IMO setting element event handlers by searching over IDs/CSS classes actually makes maintenance more difficult by introducing unneeded indirection and boilerplate.
But JS links are always the great satan.
Vladimir
2010/6/21 Daniel Gackle danielgackle@gmail.com:
That article's kind of funny because some of the reasons they give for *not* embedding css/html are the very reasons we *are* embedding it. Reduced download times, for example, and greater maintainability. Moreover, the cache issue is a non-starter when you tag your resources with a hash and make them never expire. I could go on. The point is that it really depends on the needs of your project and the tools you're using. In good CL tradition I'm sure we can all agree that PS hackers are smart enough to choose rightly.
On Mon, Jun 21, 2010 at 7:51 AM, Henrik Hjelte henrik@evahjelte.com wrote:
On Sun, Jun 20, 2010 at 8:42 PM, Haris Bogdanović fbogdanovic@xnet.hr wrote:
Sorry, I wrote that wrong. I want to set background color of td cell like this:
<td onclick='this.bgcolor="blue"'> text </td>
with cl-who and ps like:
(:td :onclick (ps ("what goes here to get 'this.bgcolor="blue"' ? ")))
There are reasons why inline javascript is out of fashion: http://css.dzone.com/news/why-inline-css-and-javascript-
I suggest setting the onclick handler from outside the html, retrieve the td element using an id and getelementbyid, or if it is not unique (an id can't be used) add a class and use some javascript library that can select elements by classname to get the dom element.
/Henrik Hjelte
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel