Rails spinoffs - Nov 2006 - Bug in Prototype in the evalScripts-method

Hello,

When I''m for example using the Element.update(element, html) and the
html block contains a script-block like this
<script type="text/javascript">
<!--
alert("Hello World!");
//-->
</script>

the evalScript-function crashes because the comments are not removed
before running the eval-function. If I change the ScriptFragment to
this regular exception it works though:

ScriptFragment:
''(?:<script.*?>\\s*(?:<!--)*)((\n|\r|.)*)(?:(?:\/\/-->\\s*)<\/script>)''


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

This one works even better ;-)

ScriptFragment:
''(?:<script.*?>\\s*(?:<!--)*)((\n|\r|.)*?)(?:<\/script>)'',


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Martin Odhelius wrote:
> Hello,
>
> When I''m for example using the Element.update(element, html) and
the
> html block contains a script-block like this
> <script type="text/javascript">
> <!--
> alert("Hello World!");
> //-->
> </script>
>
> the evalScript-function crashes because the comments are not removed
> before running the eval-function. If I change the ScriptFragment to
> this regular exception it works though:
>
> ScriptFragment:
>
''(?:<script.*?>\\s*(?:<!--)*)((\n|\r|.)*)(?:(?:\/\/-->\\s*)<\/script>)''
HTML comment delimiters should never be used inside script elements, a
far simpler solution is to supply valid javascript.


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Sure, that is correct, but in XHTML you often use the <![CDATA[ section
to escape the data, and to do it backwards Compatibile you can use the
following, wich makes my regex work with both ways...

<script type="text/javascript">
<!--//-->
<![CDATA[//><!--
alert("Hello World!"); 
//--><!]]>
</script>


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Martin,
Martin Odhelius a écrit :
> <script type="text/javascript">
> <!--//-->
> <![CDATA[//><!--
> alert("Hello World!"); 
> //--><!]]>
> </script>
Just out of curiosity, can you provide a reasonable browser use case
where the simpler form:
<script type="text/javascript">
// <![CDATA[
alert("Hello World!");
// ]]>
</script>
...doesn''t work for an XHTML document?
-- 
Christophe Porteneuve aka TDD
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Sure, that is correct, but in XHTML you often use the <![CDATA[ section
to escape the data, and to do it backwards Compatibile you can use the
following, wich makes my regex work with both ways...

<script type="text/javascript">
<!--//--><![CDATA[//><!--
alert("Hello World!");
//--><!]]>
</script>

Read more about it here
http://lachy.id.au/log/2005/05/script-comments


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Rewrote my post and added a link ;) Read more about it these.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Correct as long as you do not want to be compatible with clients pre
html3.2 ;)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

And I still think its good if prototype works together with as many
cases as possible, and my regex works with all three solutions: without
comments, with comments, with comments and cdata....


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Martin,
Martin Odhelius a écrit :
> Correct as long as you do not want to be compatible with clients pre
> html3.2 ;)
Ah!  Prototype scope aside, I''m glad to have a double-check on that :-)
-- 
Christophe Porteneuve aka TDD
tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Martin Odhelius wrote:
> Sure, that is correct, but in XHTML you often use the <![CDATA[ section
> to escape the data, and to do it backwards Compatibile you can use the
> following, wich makes my regex work with both ways...
>
> <script type="text/javascript">
> <!--//--><![CDATA[//><!--
> alert("Hello World!");
> //--><!]]>
> </script>
Which still leaves the opening comment delimiter as invalid javascript
- there is no sensible reason to include HTML or XML comment delimiters
in script elements.

If you are concerned about it, keep all script files external or inside
the head - browsers should not display *any* content in the head of an
HTML document, whether they know about script elements or not.

Every browser since Navigator 2 and IE 3 knows not to display the
content of script elements regardless of where they occur in the
document.  If you are concerned about documents actually served as XML,
then you are talking about a small band of browsers (count IE out)
where script files should be kept external anyway.
> Read more about it here
> http://lachy.id.au/log/2005/05/script-comments
An explanation of the history of "script comments" that encourages
non-use.  


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The thing is that the technique to use comment in script-elements are
widely spread and used on most sites, I for example am using prototypes
Element.update to take html  from different external sources and add
them into my html-document. The external sources contains html
developed by a range of people that follows the "de facto"-standards
of
the internet (in other words, when they are using scripts they
sometimes use comments in their scripts). And, as I said before, I
think its good if prototype works together with as many cases as
possible, which makes it usable in so many more situations. And the
regex in my second post solves this issue pretty painless so I do not
see what the arguments are to not include such a solution.
I''m totally with you when you are saying that comments should be left
out and that the scripts shall be valid, but I''m talking about the real
life here ;)

(Btw, If you wonder why I''m doing the things explained above I can tell
you that I''m building a "portal-framework" that reads
portlets from
different locations developed by different developers.)

*Every* browser ignore the initial comment delimiter when they parse
javascript. Every browser after html3.2 do not show inner content of
script tags. So, there are still more  sensible reasons why  to include
comment delimiters in script elements that there is not ;).

And by the way, when it comes to external scripts prototype can not
handle these at all. I''ve written an extending script for this though
that with ajax suck the src-document in and eval it which works pretty
good...


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

It is even declared in the standard that the javascript parser shall
ignore the first comment, so it is not invalid if we both can agree
that the w3c guidlines shall be considered as standard:
http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.2

;)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Martin Odhelius wrote:
> The thing is that the technique to use comment in script-elements are
> widely spread and used on most sites, I for example am using prototypes
> Element.update to take html  from different external sources and add
> them into my html-document. The external sources contains html
> developed by a range of people that follows the "de
facto"-standards of
> the internet (in other words, when they are using scripts they
> sometimes use comments in their scripts).
Presumably those scripts travel via your server prior to being placed
in pages, so you can remove comments before serving them to a browser.
It seems strange that you would ''eval'' scripts from wherever
in a
client browser without any form of quality control, or even letting the
authors know of any restrictions that might be appropriate to running
scripts in the same environment as Prototype.

> And, as I said before, I
> think its good if prototype works together with as many cases as
> possible, which makes it usable in so many more situations. And the
> regex in my second post solves this issue pretty painless so I do not
> see what the arguments are to not include such a solution.
I guess I can''t see why anyone wants to eval the content of a script
element.
> I''m totally with you when you are saying that comments should be
left
> out and that the scripts shall be valid, but I''m talking about the
real
> life here ;)
>
> (Btw, If you wonder why I''m doing the things explained above I can
tell
> you that I''m building a "portal-framework" that reads
portlets from
> different locations developed by different developers.)
>
> *Every* browser ignore the initial comment delimiter when they parse
> javascript.
Browser, yes.  Script interpreter, no.  If fed directly to a script
engine it will produce errors and likely none of the script will be
executed (which I presume is why there is a regex to remove them).

> Every browser after html3.2 do not show inner content of
> script tags. So, there are still more  sensible reasons why  to include
> comment delimiters in script elements that there is not ;).
I think we agree that comments are unnecessary.

> And by the way, when it comes to external scripts prototype can not
> handle these at all. I''ve written an extending script for this
though
> that with ajax suck the src-document in and eval it which works pretty
> good...
By external I guess you mean script loaded after the document is
created.  I''ve never used Prototype in that context, what do you mean
by Prototype "can''t handle" them?


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Martin Odhelius wrote:
> It is even declared in the standard that the javascript parser shall
I don''t see anything that supports the use of words like
"declared" and
"shall", the actual words are:

  ''The JavaScript engine allows the string "<!--" to occur
at the start
   of a SCRIPT element...''

That is not a declaration, nor does it say anywhere that the javascript
parser "shall" do anything - it is outside the scope of the W3C HTML
specification.
> ignore the first comment, so it is not invalid if we both can agree
> that the w3c guidlines shall be considered as standard:
> http://www.w3.org/TR/html4/interact/scripts.html#h-18.3.2
I think we agree that script comments are unnecessary, but the
statement in question can''t be considered a normative part of the
standard.  It can be considered a comment for information only and is
also demonstrably false - i.e. script engines don''t allow them, the
markup parser removes them first.

Observed behaviour of the most popular browsers shows that the HTML
parsing engine removes HTML comment delimiters at the start of script
element content before passing it to the script engine.  That behaviour
itself is contrary to the normative part of the specification that says
the HTML parser *must* send the content to the script engine
unmodified[1].  The reason browsers ignore the spec and remove the
comments is that script engines can''t cope with them at all - include
them in an external script and see what happens.

The use of script comments has been established by convention only and
has no normative support in any relevant specification.  It is a hack
designed to accommodate browsers that incorrectly parse script element
content when they aren''t supposed to - no such browser is in actual
use... but we agree on that :-).

It is a catch-22 situation for browser developers: as long as support
is provided for script comments, people will keep putting them in.  Any
browser that removes support for comments will get heckled for failing
to support conventions - despite their obvious uselessness and
potential to cause problems.  Extending "support" even further only
exacerbates the situation.


1. "If the src attribute is not set, user agents must interpret
    the contents of the element as the script."
    <URL: http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1 >

-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

> It seems strange that you would ''eval'' scripts from
wherever in a
> client browser without any form of quality control, or even letting the
> authors know of any restrictions that might be appropriate to running
> scripts in the same environment as Prototype.
Yes, I can actually remove them on the server before serving them to
the page, and I do not execute any script from wherever. But I still
think prototype shall handle a behavior that is commonly used and also
most backward compliant.
> Browser, yes.  Script interpreter, no.  If fed directly to a script
> engine it will produce errors and likely none of the script will be
> executed (which I presume is why there is a regex to remove them).
Prototype actually handle script-tags in this case, and not pure
scripts. Therefor I think prototype shall handle it in the same way
that the browser do.
> By external I guess you mean script loaded after the document is
> created.  I''ve never used Prototype in that context, what do you
mean
> by Prototype "can''t handle" them?
If you add a script-tag with src-attribute by using for example
Element.update. Element.update will automatically execute internal
scripts, but not scripts placed in an external file. This can be solved
thought by with a regex change thouse scripts-tags srom <script
type="text/javascript" src="/pathtoscript" /> to
<script
type="text/javascript">var scriptRequest = new
Ajax.Request("/pathtoscript", { method: "get", asynchronous:
false
});eval(scriptRequest.transport.responseText);</script>
I''m making this replacement on the server before serving it to the page
via ajax though, on the same place where I possibly can remove the
script-comments as we already mentioned ;)

Not a very common problem though, but as I said, I''m making a
portlet-framework where several developers shall be able to make
portlets, and I use prototype and script.acoul.us in the edit-mode
where they can edit, add and drag around protlets. those portletst can
in some cases contain scripts (like WSRP, JSR168, webparts etc). And I
want the edit-mode to be as near the parsed page as possible and
therefor want to execute possible scripts also on add...
> I guess I can''t see why anyone wants to eval the content of a
script
> element.
Prototype already does, and I think it is great and very usefull in my
case.

We can actually discuss this forever and will probably also have
different opinions on this forever ;) But as long as prototype execute
script-tags and also browsers support the initial comment delimiter, I
think that also prototype shall take care of that.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/23/06, Martin Odhelius
<martin.odhelius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Prototype actually handle script-tags in this case, and not pure
> scripts. Therefor I think prototype shall handle it in the same way
> that the browser do.
Good argument.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Martin Odhelius wrote:
[...]
> > Browser, yes.  Script interpreter, no.  If fed directly to a script
> > engine it will produce errors and likely none of the script will be
> > executed (which I presume is why there is a regex to remove them).
>
> Prototype actually handle script-tags in this case, and not pure
> scripts. Therefor I think prototype shall handle it in the same way
> that the browser do.
I understand your point, however I would not implement a system that
expected to get script comments.

> > By external I guess you mean script loaded after the document is
> > created.  I''ve never used Prototype in that context, what do
you mean
> > by Prototype "can''t handle" them?
>
> If you add a script-tag with src-attribute by using for example
> Element.update. Element.update will automatically execute internal
> scripts, but not scripts placed in an external file. This can be solved
> thought by with a regex change thouse scripts-tags srom <script
> type="text/javascript" src="/pathtoscript" /> to
<script
> type="text/javascript">var scriptRequest = new
> Ajax.Request("/pathtoscript", { method: "get",
asynchronous: false
> });eval(scriptRequest.transport.responseText);</script>
That''s rather messy - doesn''t it require eval twice?
> I''m making this replacement on the server before serving it to the
page
> via ajax though, on the same place where I possibly can remove the
> script-comments as we already mentioned ;)
So we agree on that is the better architectural solution and therefore
there is no need for prototype to support comments.  ;-p

> > I guess I can''t see why anyone wants to eval the content of a
script
> > element.
>
> Prototype already does, and I think it is great and very usefull in my
> case.
An alternative to using eval is to replace the script element with a
new one and use the replaced element''s text attribute for the text
attribute of the new one, something like:

  var s = ''<br><script
type="text/javascript"><!--''
        + '' alert(\''hi 0\'');//
--><\/script>''
        + ''<script
type="text/javascript"><![CDATA[''
        + '' alert(\''hi 1\'');//
--><\/script>'';

  var div = document.getElementById(''xx'')
  div.innerHTML = s;
  var el, els = div.getElementsByTagName(''script'')
  var oScript, elText;
  for (var i=0, len=els.length; i<len; i++){
    el = els[i];
    if (el.src && el.src != ''''){
      /* use request to get source */
      elSource = responseText;
    } else {
      elSource = el.text;
    }
    oScript = document.createElement(''script'');
    oScript.text =
el.text.replace(/^\s*(<!--)|(<!\[CDATA\[)/,'''');
    el.parentNode.replaceChild(oScript, el);
  }
}

No doubt you have some Prototype method of implementing that, I''m just
demonstrating that you can execute the script using a new script
element and setting its text property to that of the original script
element rather than using eval.

Note that the it doesn''t work in IE if the first element is a script
element, hence the inclusion of a <br>, but you could put anything
there, including an HTML entity (e.g. &nbsp;).
> We can actually discuss this forever and will probably also have
> different opinions on this forever ;) But as long as prototype execute
> script-tags and also browsers support the initial comment delimiter, I
> think that also prototype shall take care of that.
A reasonable argument, but there is more than one way to skin a cat.
The method suggested above avoids eval and simplifies the (grudgingly
included) regular expression.   :-)

It doesn''t need non-greedy operators and only has to remove the opening
comment delimiter.


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

> I understand your point, however I would not implement a system that
> expected to get script comments.
I''ve never suggested a system that *expects* comments. My solution
works with *and* without comments.
> So we agree on that is the better architectural solution and therefore
> there is no need for prototype to support comments.  ;-p
No, we do not agree on that. I still think prototype shall be able to
handle comments as long as the browser do.
> A reasonable argument, but there is more than one way to skin a cat.
Sure, there is, the only thing I care about is that prototype shall
handle script-tags even with comments. Prototype already makes use of
eval though, and I do not really see the advantages of using the
text-attribute rather than the eval-function. To put a br or a no
breaking space is not a very good thing to do because that will change
the layout of the html, does it also work with a span-tag?


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---