//<![CDATA[

Discussion in 'Javascript' started by shapper, Jun 23, 2008.

  1. shapper

    shapper Guest

    Hello,

    Why do some pages I have seen have //<![CDATA[ in the beginning of a
    script tag before the script itself?

    Do I need this?

    Thanks,
    Miguel
    shapper, Jun 23, 2008
    #1
    1. Advertising

  2. Sun, 22 Jun 2008 18:17:49 -0700 (PDT), /shapper/:

    > Why do some pages I have seen have //<![CDATA[ in the beginning of a
    > script tag before the script itself?


    http://www.w3.org/TR/xhtml1/#h-4.8

    > Do I need this?


    If you're authoring an XHTML document, yes - you would probably need
    it, but as the above link suggests an alternative to use external
    scripts - then you wouldn't need it.

    --
    Stanimir
    Stanimir Stamenkov, Jun 23, 2008
    #2
    1. Advertising

  3. shapper

    Henry Guest

    On Jun 23, 5:42 am, Stanimir Stamenkov wrote:
    > Sun, 22 Jun 2008 18:17:49 -0700 (PDT), /shapper/:
    >
    >> Why do some pages I have seen have //<![CDATA[ in the beginning
    >> of a script tag before the script itself?

    >
    > http://www.w3.org/TR/xhtml1/#h-4.8


    That is explaining the appearance of '<![CDATA[' (and for that matter
    ']]>') in script and style elements in XHTML documents, but the
    question being asked here is about the sequence '//<!CDATA[' (and
    '//]]>' in principle), that is, with two slash characters in front of
    the CDATA section markers. Those two slashes make a huge difference to
    the significance of '//<![CDATA[' because they are not at all
    necessary in XHTML documents. They appear in HTML documents that are
    using mark-up that is intended to give the impression that it is
    (maybe valid) XHTML (documents exclusively served as text/html and so
    only interpreted as HTML by web browsers), and in Appendix C XHTML
    documents that are served as both text/html and application/xhtml+xml
    depending on content negotiation (or something resembling it to some
    degree).

    In the case of documents served as exclusively as text/html the '//<!
    [CDATA[' character sequence is no more than a javascript comment and
    has no meaning or consequences beyond that so it is not necessary and
    can be removed. One of the consequences of removing them would be that
    such documents would no longer validate as XHTML, but if the intention
    is that they never be interpreted as XHTML by any web browsers (but
    instead as the tag soup HTML that they actually are) then there is
    little sense in validating the mark-up as XHTML. (It makes much more
    sense to write valid HTML form the outset).

    In the case of Appendix C XHTML documents served as both text/html and
    application/xhtml+xml the '//<![CDATA[' (and '//]]>') sequences may be
    necessary to achieve consistent handling of the javascript source text
    within the script elements, but as soon as that consistency has been
    achieved the script is then gong to have to cope with the
    inconsistency of interacting with an HTML DOM if the document was
    served as text/html and an XHTML DOM if it was served as application/
    xhtml+xml. Almost no non-trivial scripts actually can cope with this,
    and the extra level of testing and branching on top of what is
    necessary for cross browser code, and the added authoring and testing
    effort involve in coping with both types of DOM means that scripting
    content negotiated documents is extremely rarely even attempts. Even
    the W3C, who content negotiate most of their content give up the
    attempt as soon as scripting comes into the picture.

    So the '//<!CDATA[' may be necessary if scripting content negotiated
    Appendix C XHTML, but content negotiated Appendix C XHTML is such a
    nightmare to script that mostly nobody even attempts it, and anyone
    needing to ask this question is certainly not going to be attempting
    it in the foreseeable future.


    >> Do I need this?

    >
    > If you're authoring an XHTML document,


    The two slash characters are not needed at all in XHTML document.

    > yes - you would probably need it, but as the above link
    > suggests an alternative to use external
    > scripts - then you wouldn't need it.


    Another alternative is to convert the mark-up significant characters
    into their entity equivalents. This is actually the most reliable
    approach to including inline scripts in XHTML documents (that is real
    XHTML not HTML in the guise of XHTML). The problem with wrapping
    scripts in CDATA markers is that, while it may avoid problems with the
    mark-up significant characters such as '<' and '&' that are so common
    in script source code, they do not eliminate the issue entirely
    because the character sequence ']]>' remains subject to having
    significance attached to it by the browser, and ']]>' is a possible
    and valid character sequence in javascript source code (i.e. -
    if(a[b[c]]> 5){ ... } -). Thus CDATA sections reduce the issue to the
    point its being difficult to observe but do not solve it.
    Henry, Jun 23, 2008
    #3
  4. shapper

    Tim Slattery Guest

    shapper <> wrote:

    >Hello,
    >
    >Why do some pages I have seen have //<![CDATA[ in the beginning of a
    >script tag before the script itself?


    >Do I need this?


    If you're writing xhtml and you want to be 100% complaint, then yes.

    Javascript uses the characters < and & (and &&). In an XML document,
    and therefore also in xhtml, those characters have specific meanings:
    < starts a tag (like <img...>) and & starts an entity (like &nbsp;).
    The xhtml syntax scanner (like at http://validator.w3.org/) only looks
    at tags and entities and compares what it finds to the DTD, so it
    knows nothing about Javascript. So the <![CDATA[ syntax is used to
    tell the scanner that what follows - until it encounters ]]> - is
    simply character data and does not contain any tags or entities. Since
    few browsers nowadays know much of anything about xhtml, these things
    are put into Javascript comments, which explains the leading //.

    --
    Tim Slattery

    http://members.cox.net/slatteryt
    Tim Slattery, Jun 23, 2008
    #4
  5. shapper

    Tim Slattery Guest

    Tim Slattery <> wrote:

    >>If you're writing xhtml and you want to be 100% complaint, then yes.


    <<Sigh>> that should be "compliant", not "complaint"!

    --
    Tim Slattery

    http://members.cox.net/slatteryt
    Tim Slattery, Jun 23, 2008
    #5
  6. shapper

    shapper Guest

    On Jun 23, 5:34 pm, Tim Slattery <> wrote:
    > Tim Slattery <> wrote:
    > >>If you're writing xhtml and you want to be 100% complaint, then yes.

    >
    > <<Sigh>> that should be "compliant", not "complaint"!
    >
    > --
    > Tim Slattery
    > ://members.cox.net/slatteryt


    Hi,

    I am a little bit lost. In all my pages I am using:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
    www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    Could someone please tell me what should I use for inline CSS Styles
    ans Scripts?

    I am using the following:

    <style type="text/css">
    <!--
    .style1 {font-size: 12px;}
    -->
    </style>

    And

    <script type="text/javascript">

    //<![CDATA[
    // Scripts go here
    //]]>

    </script>

    Yes, I want my web pages to be validated by W3C.org validators.

    Am I doing this right or should I change something?

    Thanks,
    Miguel
    shapper, Jul 8, 2008
    #6
  7. shapper

    Tim Slattery Guest

    shapper <> wrote:

    >I am a little bit lost. In all my pages I am using:
    >
    ><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
    >www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


    OK, that's XHTML.

    >Could someone please tell me what should I use for inline CSS Styles
    >ans Scripts?


    I don't think there's any problem with CSS. AFAIK, the < and &
    characters aren't used in CSS.

    >And
    >
    ><script type="text/javascript">
    >
    >//<![CDATA[
    > // Scripts go here
    >//]]>
    >
    ></script>


    That looks right to me. The CDATA directive tells an XHTML parser that
    the following should be interpreted as character data, not XMTHL. The
    directive and its ender are in Javascript comments, so browsers that
    don't know anything about XHTML (most of them, AFAIK) won't see them
    and won't be bothered by them.

    --
    Tim Slattery

    http://members.cox.net/slatteryt
    Tim Slattery, Jul 8, 2008
    #7
  8. shapper wrote:
    > On Jun 23, 5:34 pm, Tim Slattery <> wrote:
    >> Tim Slattery <> wrote:
    >>>> If you're writing xhtml and you want to be 100% complaint, then yes.

    >> <<Sigh>> that should be "compliant", not "complaint"!

    >
    > [...]
    > I am a little bit lost. In all my pages I am using:
    >
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
    > www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


    That is unwise.

    <http://www.w3.org/TR/xhtml-media-types/#summary>
    <http://hixie.ch/advocacy/xhtml>
    <http://hsivonen.iki.fi/xhtml-the-point/>

    > Could someone please tell me what should I use for inline CSS Styles
    > ans Scripts?


    Read the Spec: <http://www.w3.org/TR/xhtml1/#h-4.8>

    > I am using the following:
    >
    > <style type="text/css">
    > <!--
    > .style1 {font-size: 12px;}
    > -->
    > </style>


    An XML parser is allowed to parse this as if it were

    <style type="text/css">
    </style>

    Furthermore, any "<", ">" and "&" in the stylesheet need to be escaped with
    character references or character entitity references as you are not
    declaring them CDATA.

    > And
    >
    > <script type="text/javascript">
    >
    > //<![CDATA[
    > // Scripts go here
    > //]]>
    >
    > </script>


    I think (although Hixie's advisory says otherwise) that this would be
    syntactically correct in all conceivable cases. A true SGML or an XML/XHTML
    parser would regard the `script' element content as CDATA and pass the
    script code enclosed in two empty single-line comments to the script engine;
    a tag soup parser would not care for the CDATA declaration and pass the
    content verbatim to the script engine; an ECMAScript-compliant script engine
    would ignore the single-line comments.

    However, the CDATA declaration was not needed if you declared and used HTML
    in the first place.

    > Yes, I want my web pages to be validated by W3C.org validators.


    Despite the Validator's current default recommendation, XHTML is not
    required for that.

    > Am I doing this right or should I change something?


    You should declare and use HTML 4.01 instead.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Jul 8, 2008
    #8
  9. Tim Slattery wrote:
    > shapper <> wrote:
    >> I am a little bit lost. In all my pages I am using:
    >>
    >> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://
    >> www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    >
    > OK, that's XHTML.
    >
    >> Could someone please tell me what should I use for inline CSS Styles
    >> ans Scripts?

    >
    > I don't think there's any problem with CSS. AFAIK, the < and &
    > characters aren't used in CSS.


    You are mistaken, and the `>' character is also relevant. For example, this
    is Valid CSS:

    #foo > .bar:before {
    content: "< ";
    }

    #foo > .bar:after {
    content: " &";
    }

    >> And
    >>
    >> <script type="text/javascript">
    >>
    >> //<![CDATA[
    >> // Scripts go here
    >> //]]>
    >>
    >> </script>

    >
    > That looks right to me. The CDATA directive tells an XHTML parser that
    > the following should be interpreted as character data, not XMTHL.


    You meant to say: not parsed character data (PCDATA).

    > The directive and its ender are in Javascript comments, so browsers that
    > don't know anything about XHTML (most of them, AFAIK) won't see them
    > and won't be bothered by them.


    The *user agent's *tag-soup parser* (there may be others) would "see" them,
    but their *script engine* would ignore them when they were passed to it,
    instead.


    PointedEars
    Thomas 'PointedEars' Lahn, Jul 8, 2008
    #9
  10. shapper

    Henry Guest

    On Jul 8, 4:25 pm, shapper wrote:
    <snip>
    > I am a little bit lost. In all my pages I am using:
    >
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    >
    > Could someone please tell me what should I use for inline
    > CSS Styles ans Scripts?


    There is no strong relationship between the DOCTYPE declaration used
    in mark-up and the 'correct' approach to use when handling SCRIPT (or
    STYLE) elements' contents.

    Web browsers determine how they are going to handle a document
    received over HTTP(S) based upon the Content Type header sent with
    that document. There are two likely candidates for content types in
    this context, and three possibilities in terms of document serving.

    If the content type sent with a document is - text/html - the browser
    will (regardless of any DOCTYPE declaration or the nature of the mark-
    up) interpret the page as a (tag soup) HTML document, and expose an
    HTML DOM to be scripted (the latter assuming the browser is scriptable
    at all (and modern enough to be using a standard or semi-standard
    DOM)).

    If the content type sent with a document is - application/xhtml+xml -
    the browser will either interpret the document as XHTML or fail to
    handle it at all sensibly/usefully (as would be the case with previous
    and current IE versions). If the browser can handle XHTML and is
    scriptable it will expose an XHTML DOM to be scripted.

    A third possibility when it comes serving documents (that have XHTML-
    like mark-up) is content negotiation, where if it looks like the
    browser can handle XHTML the content type header sent with the
    document is - application/xhtml+xml - and if the browser looks like it
    cannot the content type header used is - text/html -.

    Very few web sites attempt content negotiation, and particularly when
    the documents are to be scripted. Even the W3C, who content negotiate
    much of their content, do not attempt to combine content negotiation
    and scripting (i.e. the mark-up validator page is scripted, and it is
    always sent with the Content Type header even if the browser is
    something like Firefox which can handle XHTML). The main reason for
    this is that XHTML DOMs and HTML DOMs are very different and if you
    attempt to script a content negotiated page the script is going to
    have to be able to cope with both types of DOM in order to work. We
    live in a world where the vast majority of web developers have no
    inkling even that there are two DOMs to be considered, and so are a
    very long way from being in a position to cope with their differences.
    See:-

    <URL: http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff >

    - and note that a script that (unconditionally) uses any of -
    createElement -, - document.write - or - innerHTML - is not a script
    that will function with an XHTML DOM (it is an HTML DOM only script
    (and this is the case for almost all 'common' general purpose
    javascript libraries)).

    There are a huge number of web pages which are marked-up in an XHTML
    style that have been scripted using exclusively HTML DOM scripts and
    so must be served with a text/html content type because they would
    promptly break in the event of their mark-up ever being interpreted as
    XHTML. So despite the mark-up these are actually tag soup HTML
    documents, and all of there space-slash terminated empty elements,
    namespace declarations and so on, are just treated as erroneous HTML
    and error corrected out of the document. No more than a processing
    overhead for the browser when it receives them.

    So before deciding how to handle SCRIPT (or STYLE) elements in your
    documents you need to decide what type of documents they are. Are they
    content negotiated, and so both HTML and XHTML? Are they served as -
    application/xhtml+xml - and so real XHTML documents (and so unusable
    by IE browsers)? Or are they served as - text/html - and so in reality
    no more than formally malformed HTML documents?

    > I am using the following:
    >
    > <style type="text/css">
    > <!--
    > .style1 {font-size: 12px;}
    > -->
    > </style>


    In an XHTML document (that is, a document marked-up with XHTML and
    served as - application/xhtml+xml -) the contents of a style element
    are PCDATA, and so mark-up comments (<!-- to -->) are treated as mark-
    up comments. Thus in an XHTML document this formulation is effectively
    commenting out the entire contents of the script element. The usual <!
    [CDATA[ ... ]]> wrapping would be effective at dealing with mark-up
    significant characters within the CSS, as would substituting such
    characters with the appropriate entities.

    In an HTML document there is no need for any special handling of the
    contents of SCRIPT elements because they are CDATA already. (The days
    of browsers that would display CSS because they did not understand
    what a STYLE element was are long gone now.)

    Content negotiated documents would be more of a problem and so if mark-
    up significant characters were to appear in the CSS then using CSS
    comment delimiters (/* to */) to conceal <![CDATA .. and ]]> from the
    CSS engine when the document was handled as HTML would be the sensible
    approach (or, better, moving the CSS into an external file).

    > And
    >
    > <script type="text/javascript">
    >
    > //<![CDATA[
    > // Scripts go here
    > //]]>
    >
    > </script>


    This formulation is only necessary in a content negotiated document.
    In a real XHTML document the javascript end of line comment delimiters
    can be omitted, or the <![CDATA[ ... ]]> delimiters could be omitted
    entirely and the mark--up significant characters substituted with the
    corresponding entities. And in an HTML document the //<!
    [CDATA[ and //]]> sequences could be omitted as SCRIPT element content
    is CDATA to stat with and so in that context they are no more than
    javascript end of line comments.

    > Yes, I want my web pages to be validated by W3C.org validators.


    But validate as what? The implications of what you have written are
    that you are using XHTML style mark-up in a document that must never
    be interpreted as anything but (tag soup) HTML (based on observing
    your STYLE element and that its contents would be commented out in a
    real XHTML document, which would be pretty obvious in testing, and on
    your needing to ask the question in the first place while scripting
    the document). If the document must only ever be interpreted as an
    HTML document then it would make more sense to mark it up as an HTML
    document, and validate it as the HTML document that it must be treated
    as by any web browser receiving it. Validating it as a type of
    document that it is never interpreted as by a web browser is
    pointless.

    > Am I doing this right or should I change something?


    The combination of things that you are doing is certainly wrong. Which
    you should change and how depends on how you are serving and scripting
    the documents.
    Henry, Jul 9, 2008
    #10
  11. shapper

    Tim Slattery Guest

    Henry <> wrote:

    >There are a huge number of web pages which are marked-up in an XHTML
    >style that have been scripted using exclusively HTML DOM scripts and
    >so must be served with a text/html content type because they would
    >promptly break in the event of their mark-up ever being interpreted as
    >XHTML.


    Yeah, I'm quite sure that we're in that boat. Some number of years
    ago, somebody here though it would be a wonderful idea to code all our
    pages in xhtml. But we've never served them that way, always as
    text/html. And we don't conform 100% to xhtml standards for a number
    of reasons (Struts version, the <map> tag weirdness) anyway.

    I have no clue how an HTML DOM script would differ from an XHTML DOM
    script, and I'm quite sure none of our scripts were written with XHTML
    DOM in mind.

    At this point, I think we should drop back to HTML 4.something. I see
    no advantage at all in trying to use XHTML. But I don't make the
    decisions.....

    --
    Tim Slattery

    http://members.cox.net/slatteryt
    Tim Slattery, Jul 9, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Schmidt

    CDATA in XMLout

    Stefan Schmidt, Dec 28, 2003, in forum: Perl
    Replies:
    1
    Views:
    1,271
    Andy R
    Dec 31, 2003
  2. chrisn
    Replies:
    1
    Views:
    3,582
    Bruce Barker
    Sep 13, 2005
  3. Forest
    Replies:
    0
    Views:
    313
    Forest
    Oct 20, 2003
  4. John Davison
    Replies:
    1
    Views:
    569
    Hal Rosser
    Jul 7, 2004
  5. Replies:
    3
    Views:
    737
    Joe Kesselman
    Mar 6, 2006
Loading...

Share This Page