Path: csiph.com!news.swapon.de!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: How to pass a php variable to a javascript file (function)? Date: Tue, 06 Oct 2015 03:30:24 +0200 Organization: PointedEars Software (PES) Lines: 198 Message-ID: <3467116.VtDcax7U2a@PointedEars.de> References: <1739227.XXYPReGQTy@PointedEars.de> <13501800.DmYS3OLCIa@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1444095026 22057 eJwFwQkBwDAIA0BLJRQYcsoT/xJ2Z+riHdfNr9E46pNlMRPRkCYarG+wmifnbPLJIv0VBZAfLkERkg== (6 Oct 2015 01:30:26 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 6 Oct 2015 01:30:26 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwFwQcBACAIBMBKCjwjjqz+EbwD69UyUahgsT5W8GGqNjTuvhcRQk1ZLizJHNlQnJlDg8nbtmk55Q7oB10KFdo= Cancel-Lock: sha1:apMH88eHNn0aMp2cghUnLqrMiA8= X-NNTP-Posting-Host: eJwNwoERADEEBMCWIhy+HG7ov4T87EJdnGEON+xv7AZnK/urCsNg12VO5GFTqWLk7RydJPQBMLYRww== Xref: csiph.com comp.lang.javascript:28813 Stefan Weiss wrote: > On 2015-10-03 04:35, Thomas 'PointedEars' Lahn wrote: >> Stefan Weiss wrote: >>> I wrote (quoted) that ">> "<\script". >> This assertion is in the same sense wrong as is the following one further >> below the Specification prose, in another note: > > [ snip spec note ] > >> The problem here is that the authors make the common mistake >> and use the term “JavaScript” as an umbrella term, failing to >> differentiate between ECMAScript implementations. > > Oh, here we go again... Don't you ever get tired of this? I never get tired of the telling people the truth that virtually jumps in your face out of my more than a decade of in-depth experience with the topic, and the results of my research. If only you would find it within yourself to see it, you could make *real* progress. >>> str_replace(">> >>> Done. >> No. > > ...because? A simple unqualified "no" is not good enough. Read further below. >> (And it is bad practice to use unknown escapes in double-quoted string >> literals in PHP. > > "\s" is not an unknown escape, But it is, in *string* literals. “\” starts an escape sequence in PHP and ECMAScript. Because the escape sequence is unknown – better: *not defined* – in *string* literals, there is a fallback and it is parsed verbatim. That is also why "<\/…>" works in ECMAScript for escaping both ETAGO delimiters and end-tags of “script” elements. | […] | · The SV [String value; the ed.] of CharacterEscapeSequence :: | NonEscapeCharacter is the SV of the NonEscapeCharacter. | · The SV of NonEscapeCharacter :: SourceCharacter but not one of | EscapeCharacter or LineTerminator is the UTF16Encoding (10.1.1) of the | code point value of SourceCharacter. | […] > it's two characters. If this offends your eyes, or you're not sure what i > an what isn't an escape sequence in a PHP string, This is not about my preferences or knowledge, it is about future-proof coding. > you're free to use "\\s" or '\s'. The result is the same. Which proves my point as "\\" is the *known* – better: *defined* – escape sequence for the backslash character in both ECMAScript and PHP. Whereas in ECMAScript, “\s” is not defined in string literals, but in RegExp literals, and therefore “\\s” in string literals that are arguments for the RegExp constructor; and in PHP, different to “\s”, “\\” is defined in *both* single-quoted and double-quoted string literals. >> It is also unwise to use double-quoted string literals where single- >> quoted string literals would have sufficed, because different to >> ECMAScript, double quotes also imply interpolation in PHP [and several >> other script languages].) > > Thanks for the lecture, but I'm well aware of how PHP strings work. Evidentially you are not. > The single vs double quote issue has been discussed ad nauseam, and what > it always boils down to is that it's primarily a matter of preference […] Only to the superficial and self-deluded. The discussions you are referring to are about runtime efficiency instead. But that is not the only criterion for good code. >>> And even *IF* it was a Perl regex (which is a completely random >>> and off-topic assumption), the "\s" is in the replacement part, not in >>> the matching part. >> I was talking about code that can be (but does not have to be) contained >> in markup, code that uses regular expressions to match and process >> markup. That code will be broken by blind escaping to accomodate HTML >> parsers. > > Then you're talking about something nobody asked. You are mistaken. > This is not about escaping code, it's about escaping the contents of a > string in a ” in a “script” element is a problem, >> this should be considered a bug as (AFAICS) the given ABNF for the >> “script” element content allows “” in it. > > It's not just Chrome, you get the exact same behavior in Firefox and > IE/Edge. […] I have not doubted that, which you could have read further below. Superficial reading appears to be the major cause of your misconceptions. >>> To get a valid XML document, you'll have to escape much more than the >>> strings I mentioned. >> >> No, as I have said many times before in both in >> and here, you just have to declare the >> offending “script” element content a part of a CDATA section > > Then that's a completely different context. No, we are still talking about XHTML documents, in particular about XHTML “script” elements. You have claimed just before (for *everyone* to read) that “much more than the strings [you] have mentioned” would need to be escaped in the contents of XHTML “script” elements. That claim is incorrect. XHTML as an application of XML provides other means to ensure that source code is not misinterpreted as markup, namely marking up offending source code as CDATA. > You obviously have to use different escaping in a CDATA section... Can’t you read? CDATA sections make it *unnecessary* to do *most* of the escaping for Valid *and* working markup. But one should trigger the appropriate (XHTML) parser as well. And that is the crux of the matter, that eventually leads to the conclusion that it is easier and safer to *not* embed code in “script” elements in the first place. >> // escape “]]>” here if “<” follows > > ... but not like that! Well, it is rather difficult to give a description of the CDATA section end marker in a comment without mentioning it. If you can live better with that, replace the line in the example with // escape the CDATA section end marker here if “<“ follows where you can see (by testing it) that the markup character “<” is ignored by an XHTML/XML parser *because* it is contained in a CDATA section. The same applies to “” then, so, contrary to what you claimed, it does *not* need to be escaped then. >> But none of this is necessary, regardless of the document type, if you >> move the “script” element content to a separate file, and use the “src” >> attribute, AISB. > > Correct but off-topic. Nonsense. The topic of this newsgroup is ECMAScript-based programming, primarily in Web browsers, and the subject of this thread is how to use ECMAScript-based code in HTML properly and easily. The correct answer is that, not least because of the difficulties of embedding ECMAScript-based code in (X)HTML “script” elements, it is for several good reasons (which have been named before, but I can repeat them if necessary) better to include it using the “src” attribute of the “script” element instead. *Contrary to* what the authors of the HTML5 Specification recommend in their *non-normative* notes. > > IOW: Your logic is flawed. You should learn to control your emotions > > lest they control you. > > Somebody's taking their science fiction a little too seriously. Or perhaps the message is more important than the man? -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.