On Jul 8, 4:25 pm, 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">
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.
.