[WSG] Mixing innerHTML and DOM - test and question
Yet another test/demo-case, this time it's about innerHTML and W3C DOM.
I have a question towards the end...
Trying to explain to my students how innerHTML works and how DOM-methods work,
and why one should not mix them, I set up the following page:
http://ne.keryx.se/dhtmldemo/inner_html_and_dom.php
Beware, it's in Swedish, but should be understandable in essence anyway. There
are four divs, with green borders. Except for the headings (Test 1, Test 2, etc)
their content should be identical. Commentaries in the JS-code are in English.
The first div is filled with static XHTML.
The contents of the second one are made with DOM-methods.
That content will be read with innerHTML and reproduced, also using innerHTML,
in the third div.
That div in turn will be parsed with W3C DOM-methods and yet again reproduced in
the fourth and last div.
There are two links above the boxes. One will cause the page to be sent as
text/html, the other as application/xhtml+mxl.
My results are as follows:
When sent as text/html:
Perfect result in Firefox 1.5
Perfect result in Opera 8.52
Perfect result in Safari (according to http://www.snugtech.com/safaritest/)
Failing in MSIE. innerHTML can't access content created with DOM-methods.
When sent as application/xhtml+xml:
Perfect result in Firefox 1.5 (I know it won't work in 1.0x, as innerHTML is
unavailable.)
Flawed result in Opera 8.52.(See my question below.)
Failing in Safari (innerHTML seems to be unavailable, as in FFox 1.0x).
Failing in MSIE. It does not - as we all know - support this content-type.(
These results will no doubt not be surprising to most members of this list, but
I thought it could be useful to actually see a test. As you won't be able to see
the php-code otherwise I am enclosing the source code below.
If you want to set upt this page yourselves, there are two auxiliary files:
addEvent.js and jsUtilities.js. The first contain my implementation of John
Resig's addEvent. Any X-browser addEvent-function will do. The second contains
(among other things) Simon Willisons createElement, which will abstract away the
difference between document.createElement and document.createElementNS.
Back to my question:
The Opera bug: The second h2-tag (first one made with JS) won't render properly,
nor will its title-attribute work. Which is strange, because it will be
reproduced in the following two divs correctly!
Can anyone explain this?
Lars Gunther
* @license Creative Commons Share Alike
*/
if ( isset($_GET['ctype']) && $_GET['ctype'] == 'xhtml' ) {
header('Content-type: application/xhtml+xml; charset=iso-8859-1');
echo '<'.'?xml version="1.0" encoding="iso-8859-1" ?'.">\n";
} else {
header('Content-type: text/html; charset=iso-8859-1');
}
$self = basename($_SERVER['SCRIPT_FILENAME']);
?>
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml""; xml:lang="sv" lang="sv">
Inner HTML test and demo
body {
font-family: Verdana, Arial, Helvetica, "sans serif";
font-size: small;
}
strong {
font-size: medium;
}
#wrapper {
width: 70%;
margin: auto;
}
h1 {
font-family: Georgia, Garamond, "Times New Roman", serif;
font-size: x-large;
color: #0066FF;
text-align: center;
}
#wrapper div {
margin: 1em;
border: 2px ridge green;
padding: 0.5em 1em;
}
//if (!createElement || !document.createTextNode ||
!document.getElementById) {
alert("Browser lack necassary methods for test 2!"); return;
}
var htag = createElement('h2');
var pstart = document.createTextNode('Test 2');
htag.appendChild(pstart);
htag.setAttribute('title',hTitleText);
var ptag = createElement('p');
var pstart = document.createTextNode(pstartText);
ptag.appendChild(pstart);
var strongtag = createElement('strong');
var strongcnt = document.createTextNode(strongText);
strongtag.appendChild(strongcnt);
ptag.appendChild(strongtag);
pend = document.createTextNode(pendText);
ptag.appendChild(pend);
document.getElementById('test2'
Re: [WSG] Re: Encoding test page
Andrew Cunningham wrote: Keryx webb writes: According to my tests Firefox *will* use the charset specified in the http-header over the one in the XML-prologue if a page is sent as application/xhtml+xml. (Or more exactly, regardless whether the page is sent as text/html or application/xhtml+xml.) As will Opera. isn't that the way the browsers are supposed to operate? That the http-header has precedence? Andrew Cunningham That's what we were discussing. If a page is sent as XHTML, one could argue that it's supposed to be self-documenting, and that it might mean that the xml-prologue should be more important than the http-header. As my page proves, in FFox, MSIE and Opera (the three I've tested) that is not the case. If the page is sent as application/xhtml+xml and no encoding has been specified in the http-header, the prologue will be used, though. If the page is sent as text/html Firefox will ignore the prologue even if I've excluded the encoding from the http-header. Lars Gunther ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
[WSG] Encoding test page
Hello all!
I month or so ago Lachlan and I had a discussion concerning how browsers
interpret different ways of specifying charsets.
I've written a small test-page, located at:
http://ne.keryx.se/xhtmldemo/encoding_tests.php
(That server is primarily intended for the use of my students and I'd encourage
you to set up a page of your own if you intend to use this more than once or twice.)
According to my tests Firefox *will* use the charset specified in the
http-header over the one in the XML-prologue if a page is sent as
application/xhtml+xml. (Or more exactly, regardless whether the page is sent as
text/html or application/xhtml+xml.) As will Opera.
The meta-tag mostly seems to go ignored, at least for pages sent over http.
There might be some issues with the servers default http-header settings or with
the browsers cache that I have not tested. The results differ somewhat when I
test on my laptop (apache on Win) and on the public server (apache on Linux),
but the apache response headers are exactly the same for both!
Lars Gunther
P.S. My script is attached.
Make sure there are no whitespace before the opening php-tag
as that will make it impossible to send http-headers.
Title: Encoding demo
* @license Creative Commons Share Alike
*/
define('ISO','iso-8859-1');
define('UTF','UTF-8');
// Set headers
$httpHeaderChar = 'Not set';
if ( isset($_POST['httpHeaderChar']) ) {
if (strcmp($_POST['httpHeaderChar'],'ISO') == 0 ) {
$httpHeaderChar = ISO;
} elseif (strcmp($_POST['httpHeaderChar'],'UTF') == 0 ) {
$httpHeaderChar = UTF;
}
}
$httpHeaderHtml = 'text/html'; // default
if ( isset($_POST['httpHeaderType']) && strcmp($_POST['httpHeaderType'],'xhtml') == 0 ) {
$httpHeaderHtml = 'application/xhtml+xml';
}
$headerString = $httpHeaderHtml;
$headerString.= ( $httpHeaderChar != 'Not set' ) ? '; charset='.$httpHeaderChar : '';
header('Content-type: '.$headerString);
ob_start();
// Set XML-prologue
$xmlPrologue = 'Not set';
if ( isset($_POST['xmlPrologue']) ) {
if (strcmp($_POST['xmlPrologue'],'ISO') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" encoding="'.ISO."\"?>\n";
} else if (strcmp($_POST['xmlPrologue'],'UTF') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" encoding="'.UTF."\"?>\n";
} else if (strcmp($_POST['xmlPrologue'],'NOCHAR') == 0 ) {
$xmlPrologue = '<'.'?xml version="1.0" '."?>\n";
}
}
if ( $xmlPrologue != 'Not set' ) echo $xmlPrologue;
?>
Test of different ways to specifying the encoding
The next paragraph should read "å, Å, ä, Ä, ö, Ö". But if
the browser interprets the text using the wrong charset, it will look weird or be squares or question marks.
å, Å, ä, Ä, ö, Ö.
Current values
a.k.a.ISO-8859-1';
echo 'Real encoding'.$realEncoding."\n";
echo 'Http-headers'.$headerString."\n";
echo 'XML-prologue'.htmlspecialchars($xmlPrologue)."\n";
echo 'Meta-tag'.htmlspecialchars($metaString)."\n";
?>
Specify encoding for the page
Encode page with UTF-8.
Encode page with Latin-1 (default).
Set new values for HTTP-header
Set http-header to UTF-8.
Set http-header to Latin-1.
Do not specify charset in http-header (default).
Set http-header to text/html (default).
Set http-header to application/xhtml+xml.
Set new values for XML-prologue
Set XML prologue to UTF-8.
Set XML prologue to Latin-1.
Do not specify charset in XML-prologue.
Do not include XML-prologue at all (default).
Set new values for the meta-tag
Set meta-tag to UTF-8.
Set meta-tag to Latin-1.
Do not set meta-tag at all (default).
Apache response headers
Re: [WSG] Announcing GrayBit v0.5 Beta
Mike at Green-Beast.com wrote: Russ, Steve, Thank you. Mike Cherim http://green-beast.com/ http://accessites.org/ http://graybit.com/ Hmm. I tried one of my sites, but except for the index-page, it does not pick up my CSS-file. See http://graybit.com/files/graybit.php?url=http%3A%2F%2Fpenilla.nu And http://graybit.com/files/graybit.php?url=http%3A%2F%2Fpenilla.nu%2Fcolophon.php Also, my site uses iso-8859-1. Graybit sends it back as UTF-8, with predictable results for my Swedish letters, å, ä and ö. Lars Gunther ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
[WSG] IE7 and scripting
There has been much talk about improved CSS-support in MSIE 7, but what about
improved ECMAScript and DOM-support in MSIE 7?
Except for non Active-X XMLHttpRequest I've yet to see any explanations about
improvements in this area. Anyone who has?
I played (a small) part of reporting IE's incorrect handling of getAttribute,
setAttribute and removeAttribute on
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28DOM%29. Naturally I
wonder: Will these methods be fixed?
Another thing I've seen is that many scripts that test for 'document.all' or
'attachEvent' or some other similar MS proprietary function often do so *before*
they test for W3C functions, as in John Resig's winning addEvent
(http://ejohn.org/projects/flexible-javascript-events/)
function addEvent( obj, type, fn ) {
if ( obj.attachEvent ) {
obj['e'+type+fn] = fn;
obj[type+fn] = function(){obj['e'+type+fn]( window.event );}
obj.attachEvent( 'on'+type, obj[type+fn] );
} else
obj.addEventListener( type, fn, false );
}
*If* MS in the future will start supporting the better function, but continues
to support their old one as well, wouldn't it be better if the checks were done
in different order?
Or to make my question really MSIE 7 specific: What will be *dropped*? What
proprietary HTML, CSS and DOM will they stop supporting, if any?
Lars Gunther
P.S. I will start using a combination of the techniques demonstrated by John
Resig and Dean Edwards (at http://dean.edwards.name/weblog/2005/12/js-tip1/) for
my own event-handling in the future.
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
[WSG] Intrapage-navigation and Jakob Nielsen
Hello again! A few days ago there were some postings concerning Jakob Nielsens alertbox in which he condemned the use of intra-page links. http://www.useit.com/alertbox/within_page_links.html I wrote him the following feedback, slightly condensed: --- your article on intra-page links or at least it's sidebar perhaps should mention that (for browsers that support it) the :target pseudo-class can make the result of ones actions clearer, especially when intra-page links are used with multi-column layout. This is not spoken in defense of bad use of such links per se, but in case one do use them (skip-links, TOCs, etc) this might be of help. In the case of a skip-link one might think this will not be necessary, but if they are hidden with display:none many screen readers won't find them. Instead they might be hidden by moving them 4000 pixels left or something, which in turn might lead to their being included in the page tab-order. This is actually a good thing, if one likes to include phones, PDAs and other devices with small screens. Browsing, using my phone, I like skip links even though I'm sighted. They are much more convenient than scrolling myself. JN:s reply: Good points, thank you. I wonder if I will show up as well on his page... Lars Gunther ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] content type etc
Lachlan Hunt wrote: > That makes no sense whatsoever! You never need to use the meta element for content served over HTTP for *any* browser. IE supports the HTTP headers just fine: I agree with Lachlan, to 90 %. If I recall things correctly, this is how things *should* work. 1. If the server sends a MIME-declaration, that should be used by user agents. This happens almost always. 2. If not (1): If the content is XML-ish, as in XHTML, and has an XML prologue where the encoding is specified, UAs use that. 3. If not (2): If the content is (X)HTML, UAs use the meta-tagg. When loading pages from local files or from an FTP-server, where obviusly no HTTP-headers are sent, this is what the browser should use to get the encoding. Value of declaratons: HTTP-headers > XML-prologue > Meta-tags But then there is MSIE, a browser that thinks that it actually knows better than the server or HTML-coder, and inspects the actual content and overrides all settings if it feels like it. This behaviour makes it very "forgiving" when things are set up in the wrong way, but that is *not* a good thing as it may lead to bigger problems further down the road. I have had problems with this behavior when I for a while was forced to use a server that sent CSS-files as "text/html", but MSIE forgave that and the admin (himself only using IE) refused to admit that it was wrongly configured. In Firefox the CSS was not used even if the link tag said . I've seen other sites where swedish letter fail to show up properly, etc. MSIE-values: It's own "judgement" > HTTP-headers > XML-prologue > Meta-tags Bottom line: Meta-tags do *not* override http-headers, but MSIE sometimes override them, having inspected the actual content of a file. Lars Gunther ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] semantic way to use subscript or superscript
I agree to a large extent, but sometimes one has to consider: 1. Using MathML or CML is not an option as they are not supported by most (actually used) user agents. CML, one can argue, is also not a W3C-standard. 2. For very simple math or chemistry MathML and CML could be considered overkill. If I just wan't to mention a simple oxygen molecule in a sentence I think it is quite alright to use O2. The markup should not cause a screen-reader to say anything special - and that's how I intend it to be. There are many XML-implementations that does a better job at conveying semantic meaning than XHTML for various niche data. I would argue as long as one is writing normal, non-expert level detailed, text, XHTML is doing fine. If I was to write a essay specifically about chemistry it becomes another ballgame, though. 3. Span is no more semantic than sub or sup, if its only used to create a visual effect. I can't see why lang="fr">Mlle is worse than using a span. Actually I like it better, as the superscript in a way is part of the language idiom. Lars Gunther Patrick H. Lauke wrote: > In my opinion, sub and sup have a primarily visual/presentational > nature, rather than a semantic one. I'm still puzzled as to why they're > still included in the specs, which does nothing to clarify the *meaning* > of superscript and subscript...only their visual rendering. > http://www.w3.org/TR/html4/struct/text.html#h-9.2.3 > > Even the three examples given are flawed, IMHO: the first two should > arguably not be marked up in HTML at all, but via a more appropriate > (though admittedly not universally supported) one like CML and MathML, > respectively; the third is also just a matter of presentation, and could > possibly be marked up a lot better via > > Mlle (with an > appropriate style defined for the span to make it visually render as > superscript). > ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
