74952 - Web standards upgrade doc needs to be sanitized and updated

Status: RESOLVED WORKSFORME

(Documentation Graveyard :: Web Developer, defect)

Description

[/\/\arcio Galli]

This document is very important and its great. But the current title is:

Web Standards: Upgrading Your Web Pages For Netscape 6

Should be..... For Mozilla. The first paragraph is okay, .. such as Netscape 6, 
etc...

Comment 1

[rudman]

-->ian.

Comment 2

[Ian Oeschger (gone)]

Jeez, thought I updated this yesterday! 

Accepting and expanding the summary:

The whole document needs to be sanitized of the Netscape 6 references, and the
content needs to be updated too, particularly the browser sniffing and user
agent descriptions. Would like to add something about Object detection and maybe
hasFeature() as stronger alternatives to ua-sniffing. We should mention that
user agent sniffing is not a very reliable way of figuring out what sort of
client you have.

Comment 3

[Ian Oeschger (gone)]

cc'ing Jim Ley, interested web developer who may help out with this update. 

Jim, if you are interested, www.mozilla.org/bugs has some good info on what this
bug tracking system is about and how it gets used for things like this. If you
have some notes or updates to the document, you can attach them here (as a diff
or as a new document) for review and discussion. Thanks!

Comment 4

[Ian Oeschger (gone)]

Attachment: updated section on sniffing (and object detection and implementation.hasFeature())

Comment 5

[Ian Oeschger (gone)]

Marcio, Bob: You guys want to take a look at this update to the "upgrading for
web standards" document? Jim Ley (cc'd here) sent this to me and I expanded it.
Our section on browser sniffing now includes a section on object detection and
implementation.hasFeature(), two things that Jim suggested would be better
alternatives to the browser sniffing examples we include in this doc.

Jim, though I tried to preserve all of your new content, I did make some fairly
big edits to the file you sent me. I'd like you to look this over again too and
give me the OK.

Thanks a lot!

Comment 6

[Bob Clary [:bc] (inactive)]

ok, will do asap. ping me if you don't hear back by end of week.

Comment 7

[Jim Ley]

The changes are all improvements as I can see it Ian, just a couple of spelling 
typos e.g. capabilityies.  The one thing that may or may not be sensible as 
you've added the hideelement function is adding code making that work in IE4 
which is a trivial extension, but I'm not sure if it's better just to pretend 
that one doesn't exist and stick with the getElementById one, which in real 
terms doesn't exclude many actual browsers in any case.

Good edit though, thanks.

Comment 8

[Ian Oeschger (gone)]

Bob - Here is your official end-of-week reminder. :) If you and Marcio give it a
once over and an OK, I will stick it in the standards doc this weekend. Thanks a
lot!

Comment 9

[Bob Clary [:bc] (inactive)]

Ok, some comments as I read along:

if (document.getElementById &&
document.getElementById(id) &&
document.getElementById(id).style)
       document.getElementById(id).style.visibility="hidden";

is very inefficient, requiring three calls to getElementById. how about:

var elm = null;

if (document.getElementById)
   elm = document.getElementById(id);

if (elm && elm.style)
   elm.style.visibility = "hidden";

Also, since accessing the style object is a common task, perhaps in your example
for hideElement you could do something like:

function getStyleObject(id)
{
  var elm = null;
  var styleObject = null;

  if (document.getElementById)
    elm = document.getElementById(id);

  if (elm && elm.style)
     styleObject = elm.style;

  return styleObject;
}

function hideElement(id)
{
  var styleObject = getStyleObject(id);
  
  if (styleObject)
    styleObject.visibility = 'hidden';
}

These examples work ok on DOM HTML/CSS capable browsers but will not do anything
for someone using Netscape Navigator 4 or Internet Explorer 4 for example. They
don't generate script errors but don't effect the change requested either.
To complete the examples, I would add some code that would show how to code the
general case for NN4/IE4 as well. 

For example, it is possible to create a function that works in NN4 to find
Layers by id, call it NN4GetLayerById and a function that works in IE4 to find
Elements by id, call it IE4GetElementById.  Using these it is possible to
'spoof' the DOM to get a general solution that works in NN4, NS6/Mozilla, IE4
and IE5 and up.function IE4GetElementById(id)
{
   return document.all[id];
}

function NN4GetLayerById(id)
{
  // see xbStyle on the evangelism site 
  // for details on a possible implementation
}

if (document.layers)
  document.getElementById = NN4GetLayerById;
else if (document.all && !document.getElementById)
  document.getElementById = IE4GetElementById;
function getStyleObject(id)
{
  var elm = null;
  var styleObject = null;

  if (document.getElementById)
    elm = document.getElementById(id);

  if (elm)
  {
     if (elm.style)
        styleObject = elm.style;
     else if (document.layers)
        styleObject = elm;
  }

  return styleObject;
}

function hideElement(id)
{
  var styleObject = getStyleObject(id);
  
  if (styleObject)
    styleObject.visibility = 'hidden';
}

This will work for all Elements in NS6/Mozilla and IE4/IE5+ and will work on NN4
for positioned DIVs.

Under the DOM implementation section, you can also add a section about
isSupported which is available in DOM CORE 2.

Hope this helps and let me know if you have additional questions.
--bc

Comment 10

[Jim Ley]

>if (document.getElementById &&
>document.getElementById(id) &&
>document.getElementById(id).style)
>  document.getElementById(id).style.visibility="hidden";
>
>is very inefficient, requiring three calls to getElementById. how about:

The idea of that was to try and get the idea of how to use Object
Detection, I don't see the suggestion as clear as using the above at
getting across this idea.

>Also, since accessing the style object is a common task, perhaps in
>your example for hideElement you could do something like:

you could, but that is still inefficient, personally if you wish to go for 
efficient code, then constructing the functions, so you have the minimum of 
comparisons necessary, see DynWrite in the comp.lang.javascript FAQ for a Cross 
browser approach to a similar problem.

window.onload=init

function init() {
 if (document.elementById) {
  getStyleObject=function(id) {
   var elm=document.getElementById(id);
   if (elm) return elm.style
    else return null;
  }
  hide=function(id) {
   var elm=getStyleObject('id');
   if (elm.style) elm.style.visibility='hidden'
  }
 }
}

A couple of other points whilst I'm here... document.styleSheets appears to 
exist in Mozilla 0.9.2 - not checked the standard, but an approach that was 
cross-browser would be preferred if you insist on including IE4/NN4 in other 
places code, the difference between Mozilla and IE are minimal...

Jim.

Comment 11

[Ian Oeschger (gone)]

What is the status of this document and conversation? Sorry, Jim, for sitting on
this. Can I fold the Object detection example into a function AND explain that
it's in the document for the purpose of explaining how to step down to the
property you want and that there may be a performance hit and then go ahead post
these updates?

Comment 12

[Jim Ley]

I think for most real inexperienced developers it's more than fast enough, and 
to say it's inefficient is whilst true, not all that helpful as the time cost 
of the javascript processing is nearly always so small that users won't notice 
it.

Those users who are creating large programs with lots of complex interaction 
would likely have the skills to optimise the code themselves.

Something along the lines of "This is not the most efficient code, but is used 
for illustration - constructing functions would likely be faster ..." - 
concentrating on the fact it's not the most efficient rather than there being a 
performance hit - there's not that the majority would ever notice.

Efficiency is often discussed in client side javascript yet it's very rarely 
that will create a noticable effect to a user.

Comment 13

[Ian Oeschger (gone)]

Updating this document today with an amalgamation of Jim's input and Bob's
review:  I think we can stand optimize the object detection code a little, but
it does illustrate in a very clear way what object detection is. 

I'll post the whole document here in a minute.

Comment 14

[Ian Oeschger (gone)]

Attachment: sniff stuff into upgrade plus sanitize plus title change

Comment 15

[Ian Oeschger (gone)]

Just checked in the update. I guess I'll keep this open for follow-up
conversation. May take a day for the content to actually update at mozilla.org

Comment 16

[Jim Ley]

Looks good.

However there's a new error I've spotted:

http://www.w3.org/TR/DOM-Level-2-Style/stylesheets.html

clearly says document.styleSheets is a DOM2 property, and it's supported in Moz 
0.9.3 - yet the document suggests it's proprietary IE. ???

Not sure how this confusion came about - presumably there's some history with 
document.styleSheets that got it added to DOM2 late?

Comment 17

[Ian Oeschger (gone)]

Well, get on it, Jim! :)
Seriously, though, thanks for spotting that. I think you are right that there
must have been a point before document.stylesheets was adopted in DOM2. Do you
want to update that section with some verbage? I will also put a pointer to this
bug at the bottom of that document (something like: feedback? see bug _74952_),
so we can continue to make updates like this.

Comment 18

[Keith Bowes]

Another thing on that page that needs updating is that the page refers to the
EMBED element as being a standard HTML 3.2 <http://www.w3.org/TR/REC-html32>
element, which it isn't.  If you try to use EMBED on an HTML 3.2 page and then
validate that page, you'll get errors about EMBED being an undefined element. 
The truth is that EMBED is a non-standard deprecated HTML element that was never
included in any endorsed W3C HTML recommedation.  See also
http://www.blooberry.com/indexdot/html/tagpages/e/embed.htm.

Also, the page still feels like a Netscape advertisement rather than an
educational introduction to using web standards (as is what the title implies).
 Case in point, would it not be better to re-phrase sentence three from "New,
Gecko-based browsers such as Mozilla and Netscape 6.1 comply with the W3C
standards and do not support these do not support these proprietary and
non-compliant elements." to something like "Newer browsers that comply with the
W3C standards, such as Gecko-based Mozilla and Netscape 6.1, do not support
these proprietary and non-compliant elements."?

Comment 19

[Ian Oeschger (gone)]

Will work on the <EMBED> stuff, Keith. Thanks. Also have another few updates to
make per suggestion from Martin Honnen, posted here:
"on http://www.mozilla.org/docs/web-developer/upgrade_2.html in the first
paragraph it is claimed:
Tags like <LAYER> and objects like document.layers[] and
document.styleSheets[], for example,
  are actually not a part of any web standard.

This is not true, as for document.styleSheets the W3C DOM level 2 style
module
 
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/stylesheets.html#StyleSheets-StyleSheet-DocumentStyle
does very well define it, and the bracket indexing e.g.
  document.styleSheets[0]
is defined in the ECMAScript binding
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/ecma-script-binding.html"


Not only is that snippet wrong, but the section below on working with
stylesheets describes how to avoid document.styleSheets, although it is now a
part of the DOM Level 2 standard. Must rewrite that whole section.

Comment 20

[Ian Oeschger (gone)]

Updated this page per Keith Bowe's comments in #18 (but keeping this bug open
for further updates coming soon).

Comment 21

[Jim Ley]

The sample in

http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access 

Just errors:
d.style.marginLeft=".5in"  is the working equivalent.

The innerHTML warning is excessive, code based on innerHTML works in 
significantly more browsers than the appropriate DOM methods, Konquerer, iCab, 
IceStorm, PocketIE at least, all implement it in addition to IE and Mozilla - 
whilst the warning to use standards is fair, I think we need to be honest about 
the level of support it has.

Comment 22

[Ian Oeschger (gone)]

Fixed innerHTML warning verbosity and style.marginLeft code per comment #21
-thanks, Jim. Nice to see you again

Comment 23

[Ian Oeschger (gone)]

moving stuff over to an outside-the-firewall email for the time being, looking
for people to pick these Help and doc bugs up for me.

Comment 24

[Daniel Wang]

taking over some of Ian's bugs

Comment 25

[Daniel Wang]

Dr. Unclear, use the Edit This Page link on the bottom of the page to make a patch.

Comment 26

[Gérard Talbot]

I believe the whole page should be redone entirely. Here's the list of items
which I believe should be covered

1- The page uses the very old doctype declaration
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
and has 261 markup errors according to W3C validator with such chosen doctype
decl. and 124 markup errors if one chooses HTML 4.01 transitional. It's
unbelievably incoherent and miserable for a document which claims to lecture
readers into upgrading webpages.

2- Provided code do not work. Simple as that. 
a) font:larger is invalid CSS code. font:larger is not rendered as the author
most likely expected
b) font:Helvetica is invalid CSS code. font:Helvetica is not rendered as the
author most likely expected and I'm not even mentioning absence of generic
font-family.
c) The whole chunck of code related to the addRuleToStyleElement function does
not work. Unbelievable: about 20 lines of that document is explaining and
demonstrating a way to change "an Document's Style Sheet Using the DOM" which
DOES NOT WORK... notwithstanding the use of deprecated LANGUAGE="JavaScript" as
an attribute
d) the margin-left error was reported 20 months ago in this bug and it's still
in that page. Awful for a document with the title "Using Web Standards in Your
Web Pages"!

3- <IFRAME SRC="mylist.html" /> has to be mistaken and should not work for html
documents

4- All provided code should be quoting attribute values everywhere possible and
needed, even if not necessary. If you want to promote best, sound and safe
coding practices, then such document should be an irreproachable example of
such. Even Mozilla Composer does that. "Composer automatically places quotation
marks around any attribute text." coming from
Help/Help contents/Content Tab/Creating Web Pages/Formating your Web
Pages/Inserting HTML Elements and Attributes/Using the Advanced Property Editor/
and also:
Why attribute values should always be quoted in HTML
http://www.cs.tut.fi/~jkorpela/qattr.html

5- The document focuses and emphasis coding practices or deprecated elements
which are not that widely in use while some others are and are not sufficiently
covered: <center> is one for sure. The document addresses that deprecated
element but barely. Many people use <center> to center inline elements and/or to
center block-level elements within their immediate parent element. How to
upgrade both coding practices is not explained and no interactive demo is offered.

6- The provided chuncks of code are careless, bound to create problems
a) <button onclick="hideElement('d1');">hide div</button>
The default type of button is submit; so here, it would be necessary to add the
attribute value type="button".
b) parseInt should [always] use 2 parameters to avoid problems, to be robust.

7- Plain wrong and embarassingly awful is:
 "W3C Feature or Recommended Replacement: CSS1 color:, text-face:, text-size:"

8- Such page deserves to be 
- more interactive (say, with a button "Show me" which toggles a div with
display:block/none)
- much more compliant with all known and widely established best, sound coding
practices (e.g.: using meaningful, self-explanatory identifiers for id values,
javascript variables, etc..)
- much more accurate, tested, working, valid, etc.. It should aim to be an
indisputable reference, a model of document per se

Believe me I could go on and on here...

I want to be assigned to upgrade that page entirely and I have offered to do so.
Fair enough?

Comment 27

[Gérard Talbot]

Attachment: Corrections announced by previous comment (checked in)

- I changed the doctype declaration to HTML 4.01 strict and added a few <link>s

- I changed a few <br /> to <br>: I'm sure there might be some left.
- I removed all of odd <a name="..." /> which were external to <hn> block-level
elements
- Made the corrections to marginLeft, parseInt(..., 10), font:...,
- changed text-face to font-family, text-size to font-size
- added <center> -> margin:0px auto for block-level elements; this still needs
to be explained
- added double quotes around src attribute values
- Added Firefox here and there
- Added the notion of HTML 4.01 transitional. <OBJECT> should be used as a
replacement for <LAYER> with HTML 4.01 strict. Recent browsers (MSIE 6, Opera
7, NS 6+, Mozilla, etc..) would all render
<object data="path/filename.html" type="text/html" ...>
- I removed one example/trick of converting <layer>: there were 3 of them.
Somehow, people should be also telling their visitors to upgrade their browser.
NS 4 is now a very old browser designed more than 7 years ago.

Finally, I want readers of this bugfile to understand that these corrections
are only temporary. I'm working on an entirely restructured document with
improved content. I have already a working draft on this.

Comment 28

[Gérard Talbot]

M. Cowperthwaite rightly mentioned that 
margin-left: auto; margin-right: auto;
is superior and more precise than
margin: 0px auto;
because top/bottom margins are not overriden. I'll include that correct
modification in the next patch.

Comment 29

[Daniel Wang]

My WinCVS is very broken, and I'm still trying to fix it. Can anyone else apply
the patch?

Comment 30

[Simon Paquet [:sipaq]]

drunclear, I can apply the patch for you. Just update it with the stuff you
mentioned in comment 28 and then send me a mail and I'll check it in.

Comment 31

[Simon Paquet [:sipaq]]

cvs commit: Examining .
Checking in upgrade_2.html;
/cvsroot/mozilla-org/html/docs/web-developer/upgrade_2.html,v  <--  upgrade_2.html
new revision: 1.17; previous revision: 1.16
done

Comment 32

[Gérard Talbot]

First of all, I want to thank Simon for submiting the patch; this was needed for
a long time and, Simon, believe me, it is greatly appreciated.
I'm reopening the bugfile because there is still a lot to do.
- there are still 13 markup validation errors: it's better than 261 or 124 but
still inacceptable for an organization trying to champion W3C web standards
compliance and adherence. One can not consequently and coherently promote W3C
web standards that one does not do itself, furthermore considering the title of
such document.
- there are 3 CSS errors and a few warnings as well.
- The whole addRuleToStyleElement function needs to be updated and to become a
realistic and working exemplary of what to do in real webpage situation; right
now, the code in that document still does not work.
- I personally have never seen a document with a <div src="..."> code anywhere
before. I would be very much surprised if that sort of code was occuring
frequently. So, I question the relevance (space and importance) the document
gives to such case.
- I think the document should focus more on frequent occurences of non-standard
coding practices than rarer ones. Doing so would make the file shorter, more
useful IMO and easier to refer to.
- I believe the proposed code to replace <applet> is not even best. See
http://ww2.cs.fsu.edu/~steele/XHTML/appletObject.html
- some intra-document links need to be updated or created
- I believe this document should be able to link to live, working, entirely
valid documents serving as examples. A sort of way to give more info, more
interactivity to users willing to know more, see more,
- I have a text (27 lines, 347 words) which concisely explains the benefits of
writing compliant pages. I believe somehow this "Using Web Standards in Your Web
Pages" does not sufficiently explain the benefits of writing compliant pages.
There is a lot more to writing compliant pages than to support Mozilla and other
W3C compliant browsers.

I'm open to suggestions, feedbacks and ideas.

Comment 33

[Gérard Talbot]

Attachment: More corrections, code tweaks

I corrected
- missing closing tags
- added other <link> subsections
- rearrange code of anchors; I avoided and removed empty anchor (like <a
name="#blahblah"></a>)
- changed margin:0px auto to margin-left: auto; margin-right: auto; like
rightfully suggested
- added a few links to precise W3C TRs
- added OtherDeprecated and OtherExcluded anchors
- removed orphelined </center>
- added <abbr title="World Wide Web Consortium">W3C</abbr>
- an <a/> error

I hope there is no more validation markup error. I removed the blank spaces
formating of the source code. I am not sure how to best use that "Doctor"
editor.

Comment 34

[Gérard Talbot]

Somewhere in that document, a link to the full list of deprecated elements
should be mentioned:
http://www.w3.org/TR/html401/appendix/changes.html#h-A.3.1.2

Also, I believe it would be opportune to mention the DOM 3 Core attribute
textContent since this is the W3C DOM standard equivalent to MSIE's innerText
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent
and Mozilla 1.5+ supports it.

I'm looking for comments, feedback and suggestion on how best to replace the
current code for addRuleToStyleElement function.

Comment 35

[Simon Paquet [:sipaq]]

Comment on attachment 154963 [details] [diff] [review]
More corrections, code tweaks

>+<p>A number of elements and practices considered "standard" among web developers for adding DHTML and/or cross-browser support to their web pages were excluded from the <a href="http://www.w3c.org"><abbr title="World Wide Web Consortium">W3C</abbr></a> HTML 4.0 and Document Object Model specifications. Tags like <code>&lt;LAYER></code> and objects like <code>document.layers[]</code>, for example, are actually not a part of any web standard. Newer browsers that comply with the <abbr title="World Wide Web Consortium">W3C</abbr> web standards, such as the Netscape Gecko<sup style="font-size: smaller;">TM</sup>-based Mozilla, Firefox and Netscape 6/7, do not support these proprietary and non-compliant elements.</p>

Please avoid these over-long lines here and on other places in your patch. 
They make the HTML code hard to read and hard to maintain.

>+<ul>
>+    <li><a href="#layer">Layers and <code>LAYER</code> Elements</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#layer_up">Updating Layer Elements</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#div"><code>DIV</code> Elements</a></li>
>+    <li><a href="#deprec">Deprecated Elements</a></li>
>+    <li><a href="#OtherExcluded">Other Excluded Elements</a></li>
>+    <li><a href="#dom">Using the DOM</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#dom_unsupp">Unsupported DOM-related Properties</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#dom_access">Accessing Elements with the DOM</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#dom_manip">Manipulating Document Style and Content</a></li>
>+    <li><a href="#sniff">Developing Cross Browser/Cross Platform Pages</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#object">Using Object Detection</a></li>
>+    <li>&nbsp;&nbsp;&nbsp;<a href="#dom_imp">Using the DOM <code>implementation</code> Object</a></li>
>+    <li><a href="#jar">Components and Plug-ins</a></li>
>+    <li><a href="#summary">Summary of Changes</a></li>
>+</ul>

We should get rid of the non-breaking spaces. Make a sub-list by nesting in
another <ul> 
to get rid of the non-breaking-spaces. This should make the code cleaner and
smaller in size.

>-<div style="text-align:right; font-size: smaller">Last modified April 12, 2004.<br>
>-<a href="mailto:[e-mail]">Ian Oeschger</a>, <a href="mailto:[e-mail]">Jim Ley</a>,
>-<a href="mailto:[e-mail]">Daniel Ulrich</a>, <a href="mailto:[e-mail]">Mike Cowperthwaite</a>
>+<div style="text-align:right; font-size: smaller;">Last modified August 1st, 2004.<br>
>+<a href="mailto:[e-mail]">Ian Oeschger</a>, <a href="mailto:[e-mail]">Jim Ley</a>, <a href="mailto:[e-mail]">Mike Cowperthwaite</a>

Why are you removing your name here?

As for the rest, this looks good. Please make the proposed changes and I will
gladly check this patch in.

Comment 36

[Gérard Talbot]

(In reply to comment #35)
> (From update of attachment 154963 [details] [diff] [review])
> >+<p>A number of elements and practices considered "standard" among web > 
> Please avoid these over-long lines here and on other places in your patch. 
> They make the HTML code hard to read and hard to maintain.
> 

Every single paragraph is separated by a blank line so that the HTML code
remains readable and maintainable. I merely added a single <abbr> for W3C in
that sentence and such inline element should degrade gracefully in
non-<abbr>-supporting browsers.

> >+<ul>
> >+    <li><a href="#layer">Layers and <code>LAYER</code> Elements</a></li>
> >+    <li>&nbsp;&nbsp;&nbsp;<a href="#layer_up">Updating Layer Elements</a></li>
> 
> We should get rid of the non-breaking spaces. Make a sub-list by nesting in
> another <ul> 
> to get rid of the non-breaking-spaces. This should make the code cleaner and
> smaller in size.
> 

Yes! I agree. Adding this to my todo list. 
I prefer to make such change once the numerous changes of this patch are in the
file. I'm using that "Doctor" editor and don't understand well how it does
create a working document for the reviewer. I'm quite new to all this.

> 
> Why are you removing your name here?
> 

Ian Oeschger and Jim Ley email addresses should be removed but their names
should remain: they certainly deserve credit. I'll make that change and upload
this modification in the patch to come.

> As for the rest, this looks good. Please make the proposed changes and I will
> gladly check this patch in.
> 

Thanks!

Comment 37

[Gérard Talbot]

Attachment: Same as previous file but with names, addresses modifications

I just clarified the names and email addresses of contributors from the
previous file.

Comment 38

[Simon Paquet [:sipaq]]

>> Please avoid these over-long lines here and on other places in your patch. 
>> They make the HTML code hard to read and hard to maintain. 
>
>Every single paragraph is separated by a blank line so that the HTML code
>remains readable and maintainable.

It isn't. Before your change every line of the paragraphs you changed ended
somewhere in the 70-80 characters range. Now there a few huge one-liners. This
makes the code hard to read, especially when using editors which do not enable
word-wrapping by default and this also makes tracking the changes in CVS via the
mozilla.org bonsai system very hard. Please change that.

The doctor tool does not create these one-liners by default.

Comment 39

[Gérard Talbot]

(In reply to comment #38)
> >> Please avoid these over-long lines here and on other places in your patch. 
> >> They make the HTML code hard to read and hard to maintain. 
> >
> >Every single paragraph is separated by a blank line so that the HTML code
> >remains readable and maintainable.
> 
> It isn't. Before your change every line of the paragraphs you changed ended
> somewhere in the 70-80 characters range. Now there a few huge one-liners. 

Ok, I understand what you mean, refer to now. So, you prefer there would be a
carriage return at every 70-80 characters, right?

This
> makes the code hard to read, especially when using editors which do not enable
> word-wrapping by default 

Ok. I did not know; I always assume word-wrapping is enabled.

and this also makes tracking the changes in CVS via the
> mozilla.org bonsai system very hard. Please change that.
> 

Ok I will.

Comment 40

[Gérard Talbot]

Attachment: Same as previous but with line-wrapping CR at 80 char.

Same file as previous one but with CR at every 80 characters or so.

Comment 41

[Simon Paquet [:sipaq]]

Comment on attachment 145960 [details] [diff] [review]
Corrections announced by previous comment (checked in)

Patches that have been checked in are never obsolete.

Comment 42

[macdreamnet]

esta es prueba

Comment 43

[Simon Paquet [:sipaq]]

(In reply to comment #39)
>>>> Please avoid these over-long lines here and on other places in your patch. 
>>>> They make the HTML code hard to read and hard to maintain. 
>>>
>>>Every single paragraph is separated by a blank line so that the HTML code
>>>remains readable and maintainable.
>> 
>> It isn't. Before your change every line of the paragraphs you changed ended
>> somewhere in the 70-80 characters range. Now there a few huge one-liners. 
> 
> Ok, I understand what you mean, refer to now. So, you prefer there would be a
> carriage return at every 70-80 characters, right?

Yes, but not in the way you did it. In the updated upgrade_2.html file the body
part should not have lines longer than 70-80 characters. Let's have a look at a
random part of your latest patch to make this more clear:

-    <p><code>document.layers[]</code> and other features of the Navigator 4
Layer DOM are
-    similarly not supported, as discussed <a href="#dom">below</a>.</p>
+<p><code>document.layers[]</code> and other features of the Navigator 4 Layer
DOM are similarly not supported, as discussed <a href="#dom">below</a>.</p>
 
The lines starting with a "-" are the lines that will be removed from the file.
The lines with the starting "+" will be inserted. Here you just changed the
indentation and then you replaced the two lines in the old file with just one
line in the new file.

A correct patch would look like this:

-    <p><code>document.layers[]</code> and other features of the Navigator 4
Layer DOM are
-    similarly not supported, as discussed <a href="#dom">below</a>.</p>
+<p><code>document.layers[]</code> and other features of the Navigator 4 Layer
+DOM are similarly not supported, as discussed <a href="#dom">below</a>.</p>

Do you see the difference? Now you would replace two lines with two lines.
That's what I want to see. 

Please read http://cocoon.apache.org/2.1/howto/howto-patch.html to better
understand what a patch is and how the whole patching mechanism works.

For an immediate solution, please send me the full file with all the changes so
that I can make a patch by myself and check this patch in.

Comment 44

[Gérard Talbot]

Attachment: Indentation + line-wrap at 80 chars restored; many changes (checked in)

The document should be entirely valid now.
Summary of changes:
- restored indentation and line-wrapping at 80 chars
- gray background for the intra-navigation div removed.
- margin-left: auto; margin-right: auto; added as promised
- replaced   with nested ul as discussed before
- added corrections I listed in comment #33 (hopefully I didn't forget any)
- added a comment in source code about how to create W3C compliant marquee
since devedge has 2 articles on this
- many code fine tuning/tweaks

Comment 45

[Simon Paquet [:sipaq]]

Thanks for your efforts, Ulrich.
I will checkin this patch shortly.

Comment 46

[Simon Paquet [:sipaq]]

Comment on attachment 155980 [details] [diff] [review]
Indentation + line-wrap at 80 chars restored; many changes (checked in)

Checked in with some minor modifications from me, e.g. <b> -> <strong>

Thanks Daniel!

Comment 47

[Gérard Talbot]

Thanks Simon! I really appreciate this!
The current version still needs to be tweaked here and there. I'll do that later.


DISCUSSION
==========

a) Adding a rule to a local stylesheet:
Right now, the whole gray-background example of adding a stylesheet rule into
document's head stylesheet does NOT work. Changing a local, embedded style sheet
is quite rare, is still not widely supported (Opera 7.54 does not support
insertRule) and is rarely needed or justified.
At the very least, a mere mention of the insertRule() method might suffice;
giving a whole example seems to be suggesting that this is the normal, preferred
or frequent way to change a style declaration which isn't.
http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_manip

b) Applet translation into <object>
"The APPLET element is deprecated in HTML 4, in favor of OBJECT. The translation
between the two tags is (...)"
- The provided alternative code is not convincing
- I question its relevance if the alternative code, whatever it might be, would
not be working in MSIE 6.
If you try with MSIE 6 the 5 tests of this page
http://www.student.oulu.fi/~sairwas/object-test/java/
you'll see they will all fail.
Now, if you try with MSIE 6 this page
http://ww2.cs.fsu.edu/~steele/XHTML/appletObject.html
the test will succeed.
So, I would change the applet section to reflect all this. Valid markup code and
working cross-browser example, code must matter here.
http://www.mozilla.org/docs/web-developer/upgrade_2.html#deprec

c) Using the DOM implementation Object
Pretty much everything in the DOM implementation section
(document.implementation.hasFeature) says 
"isn't always practical", "misleading or false", "method nearly useless"
If document.implementation.hasFeature() is unreliable, untrustworthy, still
today, then I think the whole paragraph should be removed so that the document
focus on more reliable and better ways to detect object attribute, property or
method support.

d) Examples of code (furthermore long ones) should have a "Show me" button
creating a secondary window rendering an interactive demo page/example of the code.

I have other ideas.

Comment 48

[Gérard Talbot]

Attachment: Additional changes, minor ones

Changes made:
- #OtherExcluded link in the intra-navigation div corrected
- Removed CRs in <abbr> and <code> nodes because blank spaces are preserved in
such elements
- added cellpadding="8" in tables
- changed <td> to <th> for table column headers; maybe <strong> is no longer
needed
- changed <p name="yooneek" /> to <p name="yooneek">
- added semi-colon or {} when suitable
- added a few <abbr>W3C

Simon, can you upload this patch and make sure that the current content of 
<head profile="http://www.ietf.org/rfc/rfc2731.txt">...</head> which is
<link rel="subsection" ...>'s
<link rel="bookmark" ...>'s
and 
<style type="text/css">
pre {...}
.caption {...}
</style>
is included in the top <head> section. As it is, there is 2 <head> sections
(that's wrong) and the validator reports that. Thanks!

Comment 49

[Gérard Talbot]

How to add the appropriate rule to a style sheet
------------------------------------------------
I'll remove the whole section about "add the appropriate rule to a style sheet
in the document's HEAD" (insertRule) for the following reasons:
- the given code just won't work (even after correcting the id value mismatch); 
- it could be made to work in Mozilla browsers but having to use insertRule() or
having to add a css rule into a local stylesheet is rarely justified, rarely
needed, rarely seen;
- the given code will not work in MSIE 6 SP2 and Opera 7.54, even with
corrective  adjustements since these browsers do not support insertRule(): I
can't believe we would be recommending a code that wouldn't work in those 2
browsers. According to
http://www.quirksmode.org/dom/w3c_css.html
Safari 1.2 does not support insertRule() either. insertRule() is one of the
least supported DOM 2 CSS method right now.
- <style> element does not take an id attribute; so, correcting the id value
mismatch would not make the document valid. We would be proposing invalid code.

I think we shouldn't even mention the existence of such insertRule() method (or
how to add a CSS rule into a stylesheet) as dynamically modifying a style
property is much more frequent on the web and web authors and millions of
webpages still have much more difficulties with that than with adding a rule to
a style sheet.
I'll mention the "DOM Level 2 CSS" interface methods though, with the proper
link value! (should be
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html
right now, the link leads to a 404 not found page)

<applet> -> <object> conversion code
------------------------------------
I think we should propose the conversion code explained on 
http://ww2.cs.fsu.edu/~steele/XHTML/appletObject.html
because it creates valid and working markup code in MSIE 6 and Mozilla and other
W3C web standards compliant browsers.
One reason why <applet> tags are still very frequent in pages and why <object>
have not replaced <applet> is that MSIE 5+ does not support nested objects
according to spec.
I think we just can not propose a conversion code for <applet> which won't work
in MSIE 6: a very wide majority of web authors would not intentionally want to
use code that would not be supported by MSIE 6.

DOM implementation Object
-------------------------
I'll remove that section for the given reasons in comment #47

Comment 50

[Anne (:annevk)]

Some comments on the document:

* I think you want |rel="help"| instead of |rel="bookmark"|.
* Use <h2 id="foo">Foo</h2> instead of <h2><a name="foo">Foo</a></h2>.
* Use <ul class="toc"> in the beginning.
* Use <pre class="code"> instead of <pre><span... (you might want to make it
  <pre class="example code">).
* Try to avoid the STYLE attribute as much as possible.
* Tables should use TH, not TD>STRONG
* s/<code>EMBED</code> tag/<code>EMBED</code> element/ (this is not the only
  occurance)
* Instead of <code><i>element</i> use <code><var>element</var>.
* If tables are semantic, add a CLASS with the value 'data'.
* Don't use BLOCKQUOTE for indenting.

See also:
 <http://www.mozilla.org/contribute/writing/markup>
 <http://www.mozilla.org/contribute/writing/guidelines>

Comment 51

[Gérard Talbot]

> * Use <h2 id="foo">Foo</h2> instead of <h2><a name="foo">Foo</a></h2>.

Will that also work for NS 4.x users/visitors? I haven't checked. Intra-document
navigation with id="foo" must also work for older browsers.

> * Use <ul class="toc"> in the beginning.
> * Use <pre class="code"> instead of <pre><span... (you might want to make it
>   <pre class="example code">).

How do multiple class degrade for NS 4.x users? I have no idea.

> * Try to avoid the STYLE attribute as much as possible.

I certainly+definitely agree.

> * Tables should use TH, not TD>STRONG

That is already in attachment 156070 [details] [diff] [review] patch waiting. We should then remove <strong>.

> * s/<code>EMBED</code> tag/<code>EMBED</code> element/ (this is not the only
>   occurance)
> * Instead of <code><i>element</i> use <code><var>element</var>.

I agree; your suggestion is semantically richer.

> * If tables are semantic, add a CLASS with the value 'data'.
> * Don't use BLOCKQUOTE for indenting.

I agree with you about such misusing blockquote. 

> See also:
>  <http://www.mozilla.org/contribute/writing/markup>
>  <http://www.mozilla.org/contribute/writing/guidelines>

I really have no objection to such kind of suggestions; I'm all for code that
can preach by giving the better example (semantically, structurally speaking and
in other ways) and which can degrade gracefully. 
Right now, the nr 1 issue is having a better, more regular CVS access to apply
patches; I'm working on that issue.
I have right now a long todo list regarding that "Using web standards..."
document. First we have to remove, adjust code which simply just do NOT work or
can NOT work; several areas of the content of the document is pretty debatable
IMO. Then removal of validation errors must follow. On the fly, I can add code
adjustments which are safe, which don't require discussion.

Comment 52

[Gérard Talbot]

I created a patch and submitted it and apparently (?) it seems it worked:
"The file was committed to the repository:
Checking in mozilla-org/html/docs/web-developer/upgrade_2.html;
/cvsroot/mozilla-org/html/docs/web-developer/upgrade_2.html,v  <--  upgrade_2.html
new revision: 1.19; previous revision: 1.18
done
You made the following changes: (...)"

I don't understand why it isn't in the list of attachments though; maybe this
has to be done manually.

Comment 53

[Simon Paquet [:sipaq]]

Great news, Daniel. I noticed that you got cvs web access. So it seems I no
longer need to checkin your patches. You can contact me, if you need help or
support, though.

Comment 54

[Gérard Talbot]

Simon, I will certainly need some help for 2 important things related to CVS

1- How do I restore, bring back the left menu (at the top of it, there is Roadmap)

2- How do/can I bring the <link>'s, <style type="text/css"> into the document's
<head> part. It seems the only content area I can control is within the <div
id="mBody">. I still have to untangle the issues related to my <head> additions
and the whole document's <head>.

Can you help me on this?

Comment 55

[Gérard Talbot]

I tried to fix the <head> part and add the left navigation menu with another
submited patch. I have no idea if it'll work... a wild shot. If that does not
work, I'll put back the content as it was earlier today.

Comment 56

[Gérard Talbot]

Finally, that document is perfectly complying with strict HTML 4.01!

Changes done today:
- everything mentioned in comment #48 was done
- document.implementation.hasFeature section removed (see #c49 for that)
- the whole section related to insertRule() was removed (see #c47 and #c49 for that)
- <head profile="http://www.ietf.org/rfc/rfc2731.txt">, <link rel="subsection"
...> and <link rel="bookmark" ...> all removed until I know/find how to do this
- <blockquote> were removed as proposed; a few &nbsp; removed
- <i>element</i> changed to <var>element</var> as proposed
- corrected 4 links which were leading to "Not found 404 pages" at W3C
- replaced <TD><STRONG> with <th> as agreed
- added Simon and Marcia to the list of contributors
- added some comments in the code
- added a summary attribute in a table
- etc..

Priority now is restoring the left navigation menu <div id="side">

Comment 57

[Anne (:annevk)]

Multiple classes are not problem. You don't have to care about NN 4.x, the whole
mozilla.org should follow the style and markup guide. The central style sheet
takes care of browser support.

# <table border="1" cellpadding="8">

This should be changed in '<table class="data">' since it are not presentational
tables. From '<a name' to '<ele id' has also been done on most documents.

The table of contents should not have a DIV element around it. There are more
changes probably, I'll point them out after most of this and things pointed out
in comment 50 are updated.

Comment 58

[Simon Paquet [:sipaq]]

(In reply to comment #54)
> Simon, I will certainly need some help for 2 important things related to CVS
> 
> 1- How do I restore, bring back the left menu (at the top of it, there is 
>    Roadmap)

You have to remove the upgrade_2.html file from the NOMENU file in the same
directory. I can do that for you if you don't have a local copy of the website
cvs repository.

> 2- How do/can I bring the <link>'s, <style type="text/css"> into the 
>    document's <head> part. It seems the only content area I can control is 
>    within the <div id="mBody">. I still have to untangle the issues related 
>    to my <head> additions and the whole document's <head>.

Just put this stuff into the HEAD section of your file.

Comment 59

[Simon Paquet [:sipaq]]

(In reply to comment #58)

>> 1- How do I restore, bring back the left menu (at the top of it, there is 
>>    Roadmap)
> 
> You have to remove the upgrade_2.html file from the NOMENU file in the same
> directory. I can do that for you if you don't have a local copy of the website
> cvs repository.

Done.

Comment 60

[Gérard Talbot]

(In reply to comment #57)
> Multiple classes are not problem. You don't have to care about NN 4.x, the whole
> mozilla.org should follow the style and markup guide. 

You'll obviously need to make an exception here somehow. The document is for NS
4.x users as well. This document is for them to upgrade, and to update their code.
"Pages must look decent in NS4+, MSIE4+, and Mozilla. Try to avoid exposing bugs
in their CSS support; at the very least, make the page legible."
http://www.mozilla.org/contribute/writing/guidelines#style
And as far as I know, multiple classes is not supported by NS 4.x and there is
no indication whatsoever that one can or should use it. What I'm saying here is
that I'd prefer a proposal (if possible) which avoids multiple classes.

The central style sheet
> takes care of browser support.
> 
> # <table border="1" cellpadding="8">
> 
> This should be changed in '<table class="data">' since it are not presentational
> tables. 

I'm not saying "no" to this. I need to examine what that class="data" is about;
also if there isn't a better way to convey these info than a table (I checked
the page with Lynx 2.8.5 yesterday and pretty much everything looked ok, except
these deprecated->replacement tables). These deprecated->replacement tables are
*not* really tabular data to begin with. I think use of tables there is not
best; right now, I can not see a better replacement for <table>.

Note that these issues that you bring are far from what I listed as priorities
*right now* for that document: I really want to bring the left <div id="side">
navigation menu back and I want to address code which simply does not work.
Right now, the replacement for <applet> suggested by the document just will NOT
work for ~90% of users (IE 5+) on the web right now and that's nonsense. I have
proposed to implement something which will work in MSIE 5+ and which will be
using entirely valid code.

I also wish we could start discussing on the content itself rather than
presentational issues. The content is not entirely "fixed": nowhere the document
addresses issues like 
- standards compliant rendering mode vs quirks mode, 
- doctype declarations, markup validation, 
- benefits of valid markup code, etc. 
I can not believe nor understand that a document with such title does not
address these issues for starters. If more suitable, then we ought to mention a
few links on these issues.

Overall, the document itself has very little links to outside references or
documents. Why the document shouldn't link to other documents, to outside
articles when relevant? e.g.:

- regarding object detection vs userAgent string browser detection
A Strategy That Works: Object/Feature Detecting.
http://jibbering.com/faq/faq_notes/not_browser_detect.html#bdFD

Peter-Paul Koch Javascript site:
Object Detection
http://www.quirksmode.org/js/support.html

- regarding bgsound:
Why background sound (bgsound) is bad:
What we hate on the web:
http://www.lowendmac.com/musings/02/0528.html
 41.9% of survey respondents will avoid sites that automatically play music.

Ways to irritate your visitors and drive them away.
http://www.domainnamestuffetc.com/process_101_p3.htm

Why Playing Music on your Web Site is a Bad Idea
http://www.wowwebdesigns.com/power_guides/music_off.php

- regarding <FONT>
Care with font-size
Recommended Practices: Forget <font>, use CSS
"Do not specify the font-size in pt, or other absolute length units. They render
inconsistently across platforms and can't be resized by the User Agent (e.g
browser). Use relative length units such as percent or (better) em, (...)"
http://www.w3.org/QA/Tips/font-size

Here's a proprietary way to set a node's style which is rather still often
encountered in webpages but which is *not* explicitly addressed in the document:

id.style.property_name = property_value; // will be supported by MSIE 4, MSIE 5,
MSIE 6

> From '<a name' to '<ele id' has also been done on most documents.
> 

"Use <a name="anchor-name">.  Linking to an ID isn't supported in many browsers."
http://www.mozilla.org/contribute/writing/guidelines#linking

> The table of contents should not have a DIV element around it. 

I entirely, totally agree with you on this. If I can get rid of that div - only
there for presentational purposes -, (or any wrapping, nesting element which
makes the DOM tree unneedlessly more deep), I'll remove it.
I want to see what <ul class="toc"> does first also. I'm not at that point now.

I have 32 items in my todo list right now. Some of them will be done on the fly
because fixing them won't bring any kind of discussion: e.g.: spelling errors,
carriage return inside <code>...</code> or some inline elements, bad use of
&nbsp;, etc..
Some others involving content need an open discussion, I'd say.

Comment 61

[Gérard Talbot]

(In reply to comment #50)

> * Use <ul class="toc"> in the beginning.

ol.toc and dl.toc are defined at
http://www.mozilla.org/css/base/content.css
but class="toc" is not and ul.toc is not (in other stylesheets as well). So,
setting <ul class="toc"> would have no effect.

> * If tables are semantic, add a CLASS with the value 'data'.

> 
> # <table border="1" cellpadding="8">
> 
> This should be changed in '<table class="data">' since it are not presentational
> tables.

In 
http://www.mozilla.org/css/cavendish/content.css
the 4 table.data rules
only define rules for borders and background color: padding on cells is not
defined. So what I do is correct. Anyway, cellpadding is much more supported by
older/other browsers; NS 4.x's support for padding is buggy according to 
http://devedge.netscape.com/library/xref/2003/css-support/css1/mastergrid.html

I'll eventually use the classes and rules of base/content.css and
cavendish/content.css (and the 2 other linked style sheets) for optimal use and
many other reasons. For now, we're still far from this.

Comment 62

[Gérard Talbot]

(In reply to comment #59)

> > You have to remove the upgrade_2.html file from the NOMENU file in the same
> > directory. I can do that for you if you don't have a local copy of the website
> > cvs repository.
> 
> Done.

I submited another patch and your removal change worked! Thanks for your help
again, Simon. You know I really appreciate this! Now, that file 
- finally has the correct structure thanks to you
- finally is using perfectly valid markup code (a first after months and years)
- has over 20 content corrections about bad content

Comment 63

[fantasai]

> the 4 table.data rules only define rules for borders and background color:
> padding on cells is not defined. So what I do is correct. 

If lack of padding (or any other css rule) is a problem, you poke me with a
suggestion so I can fix it.

We use ol.toc and not ul.toc because a table of contents is (usually) an ordered
list, not an unordered list. Bullets vs. numbers is a stylistic issue.

Comment 64

[Gérard Talbot]

I just submitted another patch. Changes done today:

- added 2 sentences content and 2 tutorial links about <marquee>
- remove wrapping <div> and inserted <ol class="toc"> since "table of contents
is (usually) an ordered list"
- tried to make the summary of changes table narrower; needs more tweaking
- added 15 <link>'s (subsections and bookmarks) to <head>; it works now!
- removed a few &nbsp; and carriage return inside <code>...</code> here and there
- added comments in the code about CSS rules for parsing errors (when unit
length is missing) and about Migrating From the Microsoft VM for Java to the Sun
JRE. I think it would be adequate and proper to mention those links in the content.
- added a summary attribute to a table
- remove css declarations to the local rule. Eventually, and that is what we
*all* want to do, we'll only use already declared rules in the linked stylesheets.
- code nitpicking, spelling, etc..

To do next, first thing: update/create the entire content about <applet> conversion.

Enough for today!

Comment 65

[Gérard Talbot]

Attachment: Patch revision 1.18 (checked in)

Comment 66

[Gérard Talbot]

Attachment: Patch revision 1.19 (checked in)

Comment 67

[Gérard Talbot]

Attachment: Patch revision 1.20 (checked in)

Comment 68

[Gérard Talbot]

Attachment: Patch revision 1.21 (checked in)

Comment 69

[Gérard Talbot]

Attachment: Patch revision 1.22 (checked in)

Comment 70

[Gérard Talbot]

Attachment: Patch revision 1.23 (checked in)

Comment 71

[Gérard Talbot]

Attachment: Patch revision 1.24 (checked in)

Applet to Object conversion upgrade; several other minor code upgrade,
modifications

Comment 72

[Gérard Talbot]

Attachment: Patch revision 1.25 (checked in)

Fix on width of <pre> lines in the <applet> to <object> code

Comment 73

[Gérard Talbot]

Discussion about the content of the document
--------------------------------------------

1- What is the relevance of the section "Components and Plug-ins" in a document
discussing about using web standards in webpages? Why a section (admittedly
small) of this document discuss about "archive format to install and update
components and files"?

2- The document does not mention a single word about markup validation, doctype
declaration and rendering modes (standards compliant vs quirks) of document. The
document does not mention the benefits of valid markup and CSS code. The
document is missing an important issue which is at the top of most discussion
happening nowadays about updating webpages. Maybe another document should be
developed for that single matter...

3- Links to more outside references should be given for readers wishing to read
more on particular issues of importance like eg <font>, object detection,
benefits of valid markup code, valid CSS code, applet vs object, etc..

4- Div Elements section (upgrade_2.html#div): I am for removing that whole
section because <div src="..."> is very rarely seen nowadays because the
referenced content would not be rendered at all in Opera 7.x, MSIE 6 (and
presumably MSIE 5+) and Mozilla-based browsers. Now why should we, could we
expect this sort of markup code to be commonly used, commonly seen on the web?
"The SRC attribute *_commonly used_* on the DIV to import content external to
the page, however, is not a part of the official standard." That certainly is
not true today.

5- This document should be explicitly recommending that web authors ought to
tell their NS 4.x visitors to upgrade, to visit browsehappy.com, to download
Firefox or Mozilla 1.7.3 or Opera 7.x or any highly standards-compliant browser.
NS 4.x was developed more than 8 years ago. People naturally upgrade their
browsers and such expectation is normal.
Explaining strategies to offer specific, distinct support for such old browser
goes against the title, the spirit and purpose of this document. I would remove
the section starting with "Selectively displaying some content for Nav4" and
ending with "</DIV> </NOLAYER>"

Code discussion
----------------

6- Semantically speaking, this code
<P style="color: blue; font-family: Helvetica, sans-serif;">A really
<big>big</big> shoe.</P>
should be considered better than
<P style="color: blue; font-family: Helvetica, sans-serif;">
A really <SPAN style="font-size: larger;">big</SPAN> shoe.
</P>
which is what we proposed as best. I wonder if there could not be a better
working example than what the document uses right now.

"In other words, <FONT SIZE="+1"> and <FONT SIZE="-1"> may be acceptable. But
their appearance is precisely duplicated by the long-standing HTML tags <BIG>
and <SMALL>."
What's wrong with the FONT element?
http://www.mcsr.olemiss.edu/%7Emudws/font.html

"Specifically, if you need to change font sizes, try to live with SMALL and BIG
only."
http://www.cs.tut.fi/~jkorpela/HTML3.2/all.html#fontrend

7- "The best way to import content into an element in your web page is to use an
IFRAME with a SRC"; I question "best way". <object> certainly should be
mentioned as an equally valid alternative; <object> is the only valid
alternative for strict HTML.

8- The document does not cover deprecated attributes which are frequently
encountered in webpages: bgcolor, height for <td>s, align, hspace, vspace, etc..

9- Referencing an element by just invoking its id is often used in (old?)
IE-specific webpages. The document doesn't address this and it should.

Comment 74

[Gérard Talbot]

Attachment: Patch revision 1.26 (checked in)

Trim of the local stylesheet, implemented <pre class="code">, added 2 links on
sound.

Comment 75

[Gérard Talbot]

Attachment: Patch revision 1.27 (checked in)

- Added code for upgrading <layer> to <object> in HTML 4 strict
- Added 2 links on object detection
- Added <span class="remark"> here and there
- Tried to remove horiz. scrollbar created by long attribute values
- Removed inline style on div of contributors
- Removed Last modified since this was duplicating

Comment 76

[Gérard Talbot]

Attachment: Patch revision 1.28 (checked in)

- reformatted iframe and object code to avoid scrollbar
- added 4 links on web standards
- added a quote at the beginning of document (which needs formating)
- added an <abbr>W3C

Comment 77

[Gérard Talbot]

Attachment: Patch revision 1.29 (checked in)

- Corrected Foo.html.html
- removed IE4/5: element.style.visibility = value;
- id="Contributors" replaced with class="author"
- changed quote at start of page with <div class="epigraph">
- removed <ol class="toc">; I know now what needs to be corrected wrt this
- tried to add rel="author"
- several code maintenance nits

Comment 78

[Gérard Talbot]

The layer sections are not coherent and not consequent. The title of the
document, the filename of the document, the intro and the intro of the layer
section clearly indicate strategies, ways to *upgrade* non-standard code, to
*replace* deprecated or invalid markup code. So why is this document not doing
that in the layer section?

We're offering in that section ways to carry on, to support endlessly
non-standard NS4-specific markup code (layer, ilayer, nolayer). That's not using
web standards and that's not promoting valid markup coding practices.

Right now, the replacement markup strategy for <layer> explained in that section
will degrade as gracefully as possible for NS 4.x visitors (and visitors with
old browsers, text browsers, etc) but <layer> markup will not be carried on. The
content referenced by <iframe> and <object> will degrade as a link for NS 4.x
visitors which is meeting WCAG guidelines.

So, unless I hear strong objections, in my next patch, I will remove paragraphs
explaining about making a page compatible with NS 4.x (wrapping LAYER in IFRAME,
using adjacent LAYER, displaying some content for Nav4) and will rewrite those 3
sections into just 1 section.

Comment 79

[Gérard Talbot]

Attachment: Patch revision 1.30 (checked in)

- rel="author" removed
- added style for QuoteStartPage (still needs tuning)
- tuned coding of nested lists
- added height="300" width="400" in <layer> conversion code
- class="ex-ref" in many external links
- added a link to "Case Study in a Successful Standards-Based Migration"
- many other code or text tunings

Still to do:
- rewrite and reorganize the whole section regarding <layer> according to the 2
purposes used for <layer>
    1) How to embed, import HTML content within an HTML page
    2) How to code positioned DHTML layers
    this document should offer only to *upgrade* NS4-specific code, not to
carry on endlessly NS4-specific code. This will be with my next patch.
- remove the reference to getElementsByTagNameNS and other specialized DOM
methods because these are not specifically meeting the goals of the document or
serving specifically the needs of targeted audience/readers
- generally speaking, the document should focus on using valid markup code and
techniques for access to content (degrading gracefully) for older browsers
rather than carrying deprecated markup like <layer>, <ilayer>, <nolayer>.
"Support for the deprecated elements is likely to be widely available for the
foreseeable future." sentence should be removed
- The document needs to explain more the [if !IE] and [endif] code in the
applet to object conversion code: R. Lionheart explains why here:
http://www.robinlionheart.com/stds/html4/results#obj_nest_ie
etc..

Comment 80

[Gérard Talbot]

Attachment: Patch revision 1.31 (checked in)

Rewrite of the layer sections

Comment 81

[Gérard Talbot]

Attachment: Patch revision 1.32 (checked in)

- Tuning of layer section
- remove xpi/cab/jar section
- code maintenance

Comment 82

[Gérard Talbot]

Attachment: Patch revision 1.33 (checked in)

Tunings of layer upgrade sections and links to these

Comment 83

[Daniel Wang]

just to let you know, a translation of the page is in progress:
http://wangrepublic.org/daniel/mozilla/upgrade_2

What changes do you plan for the page?

Comment 84

[Gérard Talbot]

(In reply to comment #83)
> just to let you know, a translation of the page is in progress:
> http://wangrepublic.org/daniel/mozilla/upgrade_2

That is nice to know. A part of my own webpage has been translated in Chinese
btw. So, it's not that I'm against translation of "Using web standards..." in as
many languages as possible..

> 
> What changes do you plan for the page?

Many changes! Like I said in prior comments, the document focuses too much on
rare issues and not enough on more common and frequently encountered ways of
coding. I removed litterally chuncks of code, parts of text (like
dom.implementation, insertRule() stuff, .jar and .xpi etc) which was irrelevant
(or plain wrong) to the purposes of the text.

Examples:
a) element_id.style.property_name = property_value;
is very much frequently encountered (and even now, Mozilla supports this as part
of an "smart compatibility" strategy to smooth transition from MSIE) and is not
mentioned at all in the document. In many ways, this document needs to support
(and to be a relay of) what is said in the javascript console.
b) Missing unit in CSS declarations is a very frequently encountered error and a
source of differential layout: CSS1 and CSS2.x error conditions indicate that
the css rule must be ignored in such case... and we don't mention this; MSIE 5+
will honor such CSS declaration while Mozilla-based browsers won't.
c) the document does not even mention a single word on markup validation,
different rendering modes, corrected box model in standards compliant rendering
mode in MSIE 6, doctype declarations, internal error corrections mechanisms
(quirks mode), improper nesting, missing end tags, etc.
d) Another example: <div src="">, document.tags, etc... rarely seen nowadays but
we still cover this; I think we are alone on the web covering such issues. 
e) The code of the function NN4GetLayerById(id) awkwardly says "// see xbStyle
on the evangelism site". The problem is that if an ordinary reader can't find
that (and you had to figure out it was on DevEdge), then that whole section is
far from acceptable, usable.
etc.etc.

If you do a research on upgrading from NS 4 DOM to W3C DOM on google, you won't
find more than 3 documents! So, we focus way way too much on upgrading from NS 4
when the real (much more present) issue IMO, the real challenge should be to
help, to teach to upgrade webpage code from specific IE code to W3C compliant
code. Let's face it: this is where the biggest compatibility/upgrade issues are
on the web.

I personally wonder why it would be so bad to tell readers that MSIE 4 and NS 4
are not worth cross-browser DHTML/javascript support. IMO (and here you have the
right to disagree), the time, energy spent in javascript code to support MSIE 4
and NS 4 is a debatable choice, disputable decision. Right now, =~97% of all
browsers in use out there support document.getElementById. Only 1% total still
use only NS 4 (an 8+ years old browser) or only MSIE 4 (an 7+ years old browser)
without any other browser. If you are going to write javascript code to support
that single 1%, chances are that such browsers won't support (or won't support
correctly) the style properties you intended to modify on these browsers anyway.

I'm still not happy with the document. I think such document should address less
issues and address these better. The document should be viewed with the
eyes/perspectives of an MSIE 6 user to start with: I made a change in the local
stylesheet so that the chunks of code would be readable by them since such code
was frustratingly so small.

What I like in the document is the efforts to simplify the task of upgrading
from the reader's perspective. Tables with "bad", outdated, deprecated code in
the left column versus the recommendable code replacement in the right column is
something that the normal, average user, hungry for fast answers, would
appreciate, that would help the average reader, I'd say.

I wish I could trim down some sections and/or be more straightforward in some of
them: the applet section (now 60 lines), the browser sniffing section (it could
be trimmed down without compromising explanations),...

I'm open to suggestions on all these issues, you know.

Comment 85

[Gérard Talbot]

Attachment: Patch revision 1.34 (checked in)

General code maintenance. I added a link to a page on centering with CSS. I
removed local pre and code css rules since fantasai made changes in the
stylesheets. I also escaped ampersands in the pre code which Tidy reported as
warnings but not the W3C validator.

Comment 86

[Gérard Talbot]

I checked Javascript Bible 4th edition and this is what the author says about
document.ids[] and document.tags[]:
"Deployment of JavaScript style sheets is exceedingly rare. In some ways, the
document.ids [document.tags] property behaves similarly to the IE4+ document.all
[like IE4+ and NN5 document.getElementsByTagName() method], but document.ids
[document.tags] cannot be used in regular scripts to access elements objects."
The author does not mention a word on document.classes[]. 
So, since these NS 4 objects are very rarely encountered and for other reasons,
I'll remove them from the document and cover/focus on IE 5+ specific code
conversion to W3C DOM methods, in particular:
id/name to access elements which is still often encountered.

Comment 87

[Gérard Talbot]

Attachment: Patch revision 1.35 (checked in)

In this patch:
- many text trimmings
- removed references to rarely seen NS4-specific DOM collections (tags, ids,
classes)
- focused more on document.all and IE specific objects
- created 2 more anchors and made a sub-menu for deprecated elements

Comment 88

[Gérard Talbot]

To do:
- correct the anchor (name="Deprecated") at line 137
- add bgcolor in the other deprecated section; bgcolor is seen moderately often
in web pages
- create an IE-specific to W3C standards section with a table of often
encountered IE-specific ways to access specific nodes in the DOM tree:
  o document.all.id_attribute_value
  o document.all.[id_attribute_value]
  o id_attribute_value 
  o name_attribute_value
  o FormName.InputName.value

Comment 89

[Gérard Talbot]

Attachment: Patch revision 1.35 (checked in)

I added or corrected what was to do in the previous comment. I also added
explanations and references to CSS parsing rules.

Comment 90

[Gérard Talbot]

Attachment: Patch revision 1.36 (checked in)

- Added applet and font sections
- added specific conversion table for IE-specific ways to access elements
- added FormName.InputName issue which break often webpages in Mozilla
(non-standard scoping of elements)
- added info on parsing error of unitless values in CSS1 and how it is handled
in CSS1 compliant browsers
- etc.

Comment 91

[Gérard Talbot]

Attachment: Patch revision 1.37 (checked in)

- Tuned table summary
- added scope attribute in tables (<th>)
- added specifically id_attribute_value which is often encountered
- removed reference to innerHTML since Mozilla and pretty much every known
modern browser support innerHTML; in any case, explaining how to replace
innerHTML would be quite long and would go beyond the ambitions of the document

- added info and links regarding how to access forms and forms elements
- spelling of subelement -> sub-element

To do next: remove CRs in summary attributes, remove element.innerHTML in the
summary table, remove the 2nd conversion replacement to
FormName.InputName.value and remove IE4/5 document.all in 1 cell

Comment 92

[Gérard Talbot]

Attachment: Patch revision 1.37 (checked in)

- removed CRs in summary attribute value
- removed element.innerHTML in the summary table
- removed the 2nd conversion replacement to FormName.InputName.value
- removed IE4/5 document.all in 1 cell
- added a link to CSS1 background-color
- added attribute class="ex-ref" to 5 links

To do: add the missing </code> at line 1038

Comment 93

[Gérard Talbot]

Discussion about the content of the document
--------------------------------------------

1- This document should be explicitly recommending that web authors ought to
tell their NS 4.x (or any old browser) visitors to upgrade, to visit
browsehappy.com, to download Firefox or the latest Mozilla 1.x or any highly web
standards compliant browser.
NS 4.x was designed and developed more than 9 years ago. People naturally
upgrade their browsers and such expectation is normal.

2- The document does not mention a single word about markup validation, doctype
declaration and rendering modes (standards compliant vs quirks) of document. The
document does not mention the benefits of valid markup and valid CSS code. I
think another document should be developed to address the specific issue of code
validation.

3- The whole section "Changing an Element's Text Using the DOM" should be in a
distinct, separate, unique document where, at the same time, the readers could
be taught what are textnodes, DOM tree, etc. I think this "Using web standards
in your web pages" document is already long enough as it is right now.

Code discussion
---------------

4- Semantically speaking, this code
<P style="color: blue; font-family: Helvetica, sans-serif;">A really
<big>big</big> shoe.</P>
should be considered better than
<P style="color: blue; font-family: Helvetica, sans-serif;">
A really <SPAN style="font-size: larger;">big</SPAN> shoe.
</P>
which is what we proposed as best. I wonder if there could not be a better
working example than what the document uses right now.

"In other words, <FONT SIZE="+1"> and <FONT SIZE="-1"> may be acceptable. But
their appearance is precisely duplicated by the long-standing HTML tags <BIG>
and <SMALL>."
What's wrong with the FONT element?
http://www.mcsr.olemiss.edu/%7Emudws/font.html

"Specifically, if you need to change font sizes, try to live with SMALL and BIG
only."
http://www.cs.tut.fi/~jkorpela/HTML3.2/all.html#fontrend

Comment 94

[Gérard Talbot]

Attachment: Patch revision 1.41 (checked in)

- I updated many DevEdge links
- I added a notice that recommended replacements have been tested and are
working. I thought we needed to reassure readers that all proposed replacements
are safe to make.

Comment 95

[Anne (:annevk)]

Could you please add the LANG attribute back in the next version. It should have
never been removed.

Comment 96

[Gérard Talbot]

Discussion on content
---------------------
1-
Unless I hear strong objections, I will remove the following paragraph:

"Note that neither of these foregoing examples works for Navigator 4 and
Internet Explorer 4 browsers. To create object detection code that works on
these older browsers, it's necessary to add another level of checking, where
browsers that do not support the standard document.getElementById are given some
means of returning the appropriate object reference. The two functions at the
top of this listing, IEGetElementById and NN4GetLayerById are called in place of
document.getElementById on their respective browsers platforms."
and then the block of code that follows it.

That paragraph may have made some sense in 2001 or 2002 but I believe it does
not make any sense anymore half way in 2005. Both Microsoft and Netscape no
longer provide any kind of support for these browser versions.
Less than 1% of users worldwide still use either NS 4 or IE 4; and further less
percentage of websites worldwide have script content specifically written to
work in/for either NS 4 or IE 4.
I think that if an user agent does not support getElementById, then writing more
code to workaround such difficulty is not worth it and is not a defendable
coding decision anymore.

Comment 97

[Daniel Wang]

I agree with the removal

Comment 98

[Gérard Talbot]

Attachment: Patch revision 1.42 (checked in)

- removed the mentioned paragraph and code block on how to support IE4 and NS4
- added names of authors of referenced articles
- added that DHTML marquee consumes considerably a lot of user system resources
in all browsers
- added MSIE-specific document.forms(0) which apparently is not supported by
other browsers
- a few code nits and a few text nits

Comment 99

[Gérard Talbot]

To do in next patch:
- add Doron Rosenberg name as author of the 2 DevEdge articles
- add comp.lang.javascript FAQ notes as author of Referencing Forms and Form
Controls article
- restructure the format of 
 # Developing Cross Browser/Cross Platform Pages
 # Browser Sniffing Code
 # Using Object Detection: the Best Method
so that it becomes understandable that user agent string detection ("browser
sniffing") is an unreliable, not best technique of developing cross-browser web
pages while object detection is overall recognized to be the best and more
reliable technique of developing cross-browser pages. The way the document is
structured does not indicate this; it's confusing.

-------

Several aspects of the document still do not make sense and can be improved. 
1- outerHTML and outerText are mentioned but nowhere anyone can find the
beginning of a replacement or counter-proposal on these. I think the document
should answer, propose and solve the issues (and only the issues) it brings,
otherwise the document is counter-productive and inconsequent. In any case, IMO,
outerHTML and outerText are rather "rare birds" on the web.
So I think we should remove the mention of outerHTML and outerText in the
article in the next patch.
2- There are other chuncks of text that are not optimally written or not
efficiently communicating.
3- The "applet-to-object" conversion section is long and complex. If <object>
support according to specs is not that good, not uniform and not universal among
browsers, then is it safe and fully justified to develop a considerably long
alternative? For other deprecated elements/attributes (like <font>, bgcolor,
etc.) which are replaced by CSS and which are well supported by current and
widely used browsers, it makes sense to propose valid and web-standards
replacements... but maybe not for applet.
4- The "Changing an Element's Text Using the DOM" section should be updated and
upgraded. Ideally, this should be done in an separate article where more
explanations on what are DOM nodes, text nodes, where graphics of DOM tree would
be provided.

Overall, I wish this document to be more direct, to the point. When amateur web
designers want/need to upgrade, it's because their webpages have problems with
some browsers (say, Firefox). So they look for answers, solutions and they
search (google) or post help requests in web programming newsgroups/BBS or copy
code from "copy-N-paste" javascript sites (dynamicdrive.com) or look for
interactive examples where they best learn that way (w3schools.com). They are
not very patient and are hungry for answers; they don't want to read tons of
text and, unfortunately, they will settle for text that provides clear path,
clean solutions to problems they see. So, they skim text. They'll look for
easily applicable solutions, easily "digestible", assimilable ones, often not
the best. Sometimes, these amateur web designers have a binary functioning mode:
tell them what is bad and tell them "Use this: this is good" rather than
lengthly explanations. Now, if these amateurs end up reading that "Using Web
standards in your pages" article, then I wish the article would meet their needs
as they could skim over the article and figure out faster what to learn/what to
upgrade in their web pages.

Comment 100

[Daniel Wang]

"Although widely implemented, web authors should NOT blindly rely on this error
correction mechanism." - what is widely implemented?

I disagree with your recommendation on marquee. If scrolling effect is really
required (e.g. big boss's req.), then for best accessibility we should actually
use <marquee>. Both IE and Mozilla supports <marquee> and has a pausing
function. In the future, we could see more accessibility features, such as
disabling scrolling, specifying max scrolling speed, or controlling the effect
using mouse wheel or other devices. A script could not possibly handle those. In
suggesting using a script, you are effectively throwing out accessibility with
blind faith on standard recommendations.

Comment 101

[Daniel Wang]

another thing spotted while translating:

"when an <object> is not rendered (because its content type is unsupported or
because it does not support ActiveX controls),"

..."because <object> does not support ActiveX controls"?

Comment 102

[Gérard Talbot]

> "Although widely implemented, web authors should NOT blindly rely on this error
> correction mechanism." - what is widely implemented?

The mentioned error correction mechanism is widely implemented among tested
browsers (modern ones). I tested it carefully in a test page.

<asdf poiu="ghjk">TEST SUCCEEDED</asdf>

and the words TEST SUCCEEDED will be rendered in almost all browsers.

Fair enough: I will rewrite the sentence to make it more clear. What is
important to tell readers is that although that error correction mechanism
exists in browsers, it is not requirement, a specification for an user agent to
be HTML 4.01 compliant. So this is the 1st reason why web authors should always
check their document with a HTML validator. The HTML 4.01 indicate that illegal
or wrong attribute or wrong attribute values should be treated more harschly in
that document: that's a 2nd reason to check the markup code with a HTML validator.

> I disagree with your recommendation on marquee. If scrolling effect is really
> required (e.g. big boss's req.), 

I did not absolutely close the door on marquee or DHTML marquee: I provided 2
links, resources. I am aware that <marquee> or marquee effects are more popular
in Asian pages. Also, some companies offer a stock ticker in their webpages.

> then for best accessibility we should actually
> use <marquee>. 

This is where you could be right. The Doron articles rely on javascript support
enabled while <marquee> is js-independent.

> Both IE and Mozilla supports <marquee> 

"<marquee>...</marquee> is an HTML element invented by Microsoft. It is
supported by IE3 and above. The marquee element is not part of the current or
past HTML standards. There are no other browsers that currently support the
marquee element." Doron R. in July 2002
http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/index_en.html#Introduction

> and has a pausing
> function. In the future, we could see more accessibility features, such as
> disabling scrolling, specifying max scrolling speed, or controlling the effect
> using mouse wheel or other devices. A script could not possibly handle those. 

Well, the D. Rosenberg articles had all those features, controls (stop, speed,
pause, pausing on a mouseover, adding dynamic content, having multiple DHTML
marquees, etc) available at the disposal of the user and backed with all kinds
of examples: ltr, rtl, Chinese, Hebrew.

"In this document, we offer a comprehensive W3C-compliant alternative to the
proprietary <marquee> extension. The Javascript library offered here covers all
the major uses of <marquee> such as horizontal vs. vertical scroll, direction of
text flow (LtoR, RtoL,alternating, up, and down), rate of scroll, etc."
also with dynamic content, with layer/iframe, etc..

I was personally very impressed by the examples. The CPU did not get maxed on my
machine while using most of the examples. On the other hand, examine bug 137584
and its duplicates.

When I took over this bug, all that was said to the reader was "HTML 4.01 DIV or
SPAN, with content string rotated over time by JavaScript via the DOM level 1."
with a general warning against moving text. The document was providing nothing
more concrete as to how to implement a valid alternative to marquee or a link
leading to a resource/tutorial explaining how to do this according to standards.

> In suggesting using a script, you are effectively throwing out accessibility 
> with blind faith on standard recommendations.

In a perfect world, browser manufacturers would follow this recommendation:
http://www.w3.org/TR/2002/WD-css3-box-20021024/#marquee
and they would provide full control mechanism (pause, stop, speed, etc) in
settings to users to control these marquee effects.

Comment 103

[Gérard Talbot]

Daniel, this is the page I was looking for:

http://web.archive.org/web/20030604021211/devedge.netscape.com/toolbox/examples/2001/stock-ticker/

Notice all the controls at the disposal of the user.
The WikiMedia-based page 

http://developer-test.mozilla.org/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker

does not render script content. More later..

Comment 104

[Gérard Talbot]

> Both IE and Mozilla supports <marquee> 
According to bug 156979, Mozilla started to support <marquee> around somewhere
August 2002. China is the Number 2 Market in the world for Web Traffic and PC
sales and a lot of Chinese web developers use <marquee>. That explains Mozilla's
support, I'd say.

Comment 105

[Gérard Talbot]

This page
http://www.gtalbot.org/HTMLJavascriptCSS/StockTicker.html
will eventually be added, loaded somewhere in the 
developer-test.mozilla.org/docs/DHTML_Demonstrations_Using_DOM/
directory so that a link or button in the page
http://developer-test.mozilla.org/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker
will show the reader an example.
There is little more I can do about WikiMedia content script capabilities.

In my next patch, along with others mentioned updates to do, I will 
- clarify the widely implemented vs error correction mechanism issue
- change 
"when an <object> is not rendered (because its content type is unsupported or
because it does not support ActiveX controls),"
to
"when an <object> is not rendered (because its content type is unsupported e.g.
the browser does not support the ActiveX control called, requested by the <object>,"

Daniel, how far/advanced is the translation you are referring to?

Comment 106

[Gérard Talbot]

This page
http://developer-test.mozilla.org/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker
now has a link leading to a DHTML Stock Ticker example 
http://developer-test.mozilla.org/samples/StockTicker/
based on Doron's original article.

Comment 107

[Daniel Wang]

I'm still at "Deprecated elements - applet". The page is on a wiki, and I'll
check back for other changes when I hit the end of the page. Our TE really need
the translation because there's no high-quality doc on standard.

On <marquee>, my original comment was misleading and I apologize for not
correcting it sooner. My contention is that even if a script can do all that
(pause, etc.) it cannot possibly know the user's preferences. Such preferences
should be set at the user agent, not by the Web site.

I don't like xbMarquee because it uses generated content (it's probably only
useful if the source is dynamic). I much prefer the stock ticker example you
gave since everyone can see the content without JS. Another solution would be a
HTA/XBL combination (Mozilla supports HTA if it's hooked to XBL).

I think the accessibility issues with generated content, dynamic effect,
cross-browser compatibility worth writing, but I don't know if it fits in the
scope of your document.

Back to translation. If I disagree with what you write, I'll bring up to you.
I'm always open to ideas, but if we can't reach a concensus, I'll have to make
my own changes. No offense, but we all have to stick with what we believe is the
best for the Web.

Comment 108

[Gérard Talbot]

Attachment: Patch revision 1.43 (checked in)

In this patch:
- clarified the <object>'s content type vs ActiveX control support in browsers
- removed the recommendation vs error correction mechanism for simplicity
- added author names (Doron R. and comp.lang.javascript FAQ) of articles
- removed standby explanation
- removed mentions of outerText and outerHTML
- added <dfn title="Document Object Model">DOM</dfn>
- several code nits and text nits

Comment 109

[Gérard Talbot]

To do in the next patch:

1- Restructure the "Developing Cross Browser Pages" section into 2 sub-sections:
a) Browser identification via "browser sniffing": not best, not reliable method
b) Using Object Detection: Best and overall Most Reliable Method

2- Break the following 12 verbs, 97 words sentence into 2 or 3 sentences:
"One process, commonly used is to attempt to identify the browser, and have the
user at design time decide what that means by way of the capabilities of the
browser, this is fraught with problems, it requires the user to have knowledge
of the capabilities of all current browsers that may visit the page, and code
appropriately for them, it requires the user to make assumptions about what will
happen with future browsers, or be content with giving them a safe fallback
service, and it requires users to be able to identify browsers in the first place."

3- I am ready to remove the list of object attributes (code, archive, codetype,
data, type) in the "applet to object" section because such list of attributes
and their meaning/description can be fetched at the 3 link-resources mentioned.
I think the "applet to object" section is too long as it is and takes relatively
too much importance in the document. The justification for converting applet
into object is furthermore debattable if current browser support in modern
browsers for <object> attributes is not uniform, not overall that good. What I
mean here is that if I had to upgrade a webpage (update its code), probably the
last thing I would touch/upgrade is an <applet> already working well in modern
browsers.

Comment 110

[Daniel Wang]

Attachment: suggestion on "Other deprecated elements"

Remove the quotes (they are annoying). Incorporate links into the code example
(to save space). Suggest adding INS and DEL as alt replacements of <u> and <s>

Comment 111

[Gérard Talbot]

Attachment: Patch revision 1.44 (checked in)

In this patch:
- Restructure the "Developing Cross Browser ..." section into 2 sub-sections:
Done
- Break the following 12 verbs, 97 words sentence into ...: Done
- remove the list of object attributes (code, archive, codetype,...: Done
- I reworded and reformulated a few sentences or expressions in the Browser
identification and object detection subsections 
- added more details on <marquee>; since Mozilla supports <marquee> since
August 2002, then it was fair to mention this. I am sure pros and cons where
weighted
- added for testing <dfn><acronym title="Dynamic HyperText Markup
Language">DHTML</acronym></dfn>
- a few other nits

Comment 112

[Gérard Talbot]

> Remove the quotes (they are annoying). 

Ok. Will do.

> Incorporate links into the code example (to save space).

Ok. Will do.

> Suggest adding INS and DEL as alt replacements of <u> and <s>

Ok. Will do.

One problem I see with your proposal. You say "When both margin-left and
margin-right are 'auto', they will be set to equal values, thus centering the
content" but it's really that it centers the *element* inside its parent. You
could still have a centered-within-its-parent element having its text left or
right aligned. The idea that it centers within its parent (acting as the
containing block of the element) is important because that parent could also be
a floated left/right element.

Comment 113

[Anne (:annevk)]

(In reply to comment #110)
> Suggest adding INS and DEL as alt replacements of <u> and <s>

I don't think that is a good idea. INS and DEL are semantic elements. When the
author mean to do it in a presentational way, replacing the elements with INS
and DEL is not a good idea. For instance <h2><u>foo</u></h2> must not become
<h2><ins>foo</ins></h2>.

Comment 114

[Gérard Talbot]

Attachment: Patch revision 1.45 (checked in)

In this patch:
- added <abbr>JRE</abbr>
- tuned the wording/formulation of align="center" replacements;
corrected text-align: center as this was *not only* for inline elements as
suggested by previous version
- removed the whole "Changing an Document's Style Sheet Using the DOM"
paragraph as we were not giving anything else than a general link at W3C on
this whole issue; 
- inserted the code explanations into example div in cross-browser subsections;
that way, it's easier to figure out/follow the text
- added <span class="note"> at a few spots

Comment 115

[Gérard Talbot]

I will not add INS and DEL as alternate replacements for <u> and <s>: ins and
del are semantic markup. We have no idea, we can not assume/preconceive for what
purpose/context <u> and <s> where originally used for in the first place.

Comment 116

[Daniel Wang]

> According to HTML 4.01 recommendation, when an <object> is not rendered
> (because its content type is unsupported e.g. the browser does not support
> the ActiveX control called, requested by the <object>), then the browser
> should render its contents instead

what does ", requested by the <object>" mean?

Comment 117

[Gérard Talbot]

> what does ", requested by the <object>" mean?

If an <object> calls, requests a particular ActiveX control (and ActiveX
controls are identified with clsid: [bunch - of - numbers - here]) and if it can
not support such particular ActiveX control for whatever reason, then alternate
content should be rendered.

References:
"If an object is not rendered (ex. to ignore an unsupported content type, or to
reject potentially dangerous ActiveX controls), the contents of the <object>
element are rendered instead."
http://www.robinlionheart.com/stds/html4/objects#content

Interactive demo on <object> and ActiveX controls:
http://www.student.oulu.fi/~sairwas/object-test/activex/

If I remember correctly, Microsoft clsid's bunch of numbers are authenticode of
the ActiveX control and helps determine if one ActiveX control is marked safe
and/or signed. For instance, clsid="3050f819-98b5-11cf-bb82-00aa00bdce0b" calls
the ActiveX control for accessing the installed fonts on a Windows system.

I would need to explicit all this in the article and I would prefer not to as
java applets' markup code is the very last "thing" which need to be upgraded in
webpages on the web. I may just snip that ActiveX reference (clsid, etc) and
just add a link to Robin Lionheart reference mentioned above.

--------

On an entirely separate issue, I will remove references to MSIE 4 in the article
because it's obvious that no one should try to script dynamically such browser
anymore. If "the market share of IE 5 now is tiny (...) taking time to develop
new web applications with IE 5 in mind, and to test them against it, is no
longer worth the investment", then it's time to ignore IE 4. 
http://weblogs.mozillazine.org/gerv/archives/008263.html

Comment 118

[Gérard Talbot]

Attachment: Patch revision 1.46 (checked in)

- Clarifications on the clsid, ActiveX control in <object>
- Removed specific references to IE 4

Comment 119

[Daniel Wang]

The Chinese translation is finished! http://tinyurl.com/dq3bn

Comment 120

[Gérard Talbot]

Great news!
The translation may give a link to translated W3C resources in Chinese (Simplified):
http://www.w3.org/2003/03/Translations/byLanguage?language=zh-hans
In there, there is no available translation in Chinese (Simplified) for HTML
4.01 spec and CSS 1/2.1 spec but, eventually I hope, there will be.

I noticed that <!-- comments --> about textContent() and java applets have not
been inserted in the translation.

Personally, I am unhappy (before and still today) with the section
"Changing an Element's Text Using the DOM"
and the reference to how to handle/convert element.innerText.
That section has no sufficient explanations of what is a DOM tree, no graphical
representation of a DOM tree (like
http://www.webreference.com/js/column40/drawsimple.html
), what are text nodes in relationship to a document tree, no links to outside
resources for more info/explanations.
My past, previous and current opinion is that the "Using Web Standards in Your
Web Pages" should just give a link to another tutorial-document, a real tutorial
explaining what is the document tree of nodes, how to modify text nodes, a
document developing a bit more and better what was explained in these 2:

Using the W3C DOM Level 1 Core
http://www.mozilla.org/docs/dom/technote/intro/

Internet Explorer 6, Part I: DOM Standards Support (mostly DOM 2 CharacterData
attributes and methods)
http://www.webreference.com/js/column88/
    * How to create attribute nodes
    * How to replace DOM strings
    * How to delete DOM strings
    * How to insert DOM strings
    * How to append DOM strings
    etc.

I was planning to write such document-tutorial and I had this code in mind:



function ChangingElementText (Id_Attribute_Value, newText)
{
var element;

if(document.getElementById)
   {
   element = document.getElementById(Id_Attribute_Value);
   }
else
   {
   return true;
   };

if(element.childNodes && element.childNodes.length > 1)
/*
Explanations: we start first with element whose content consists of several nodes
*/
	{
	if (typeof element.textContent != "undefined") // DOM 3 Core compliant
		{
		element.textContent = newText;
		}
	else if (typeof element.removeChild != "undefined" && element.appendChild !=
"undefined")
		// DOM 2 Core compliant
		{
		while (element.hasChildNodes())
			{
			element.removeChild(element.lastChild);
			};
		element.appendChild(document.createTextNode(newText));
	/*
	getElementById()
	childNodes[]
	hasChildNodes()
	removeChild()
	lastChild
	appendChild()
	createTextNode()
	are attributes or methods supported by MSIE 5+, Mozilla 1.x, Firefox, Safari
1.x, Opera 7+
	Every single visual browser supporting getElementById, removeChild and
appendChild also supports hasChildNodes, lastChild and createTextNode; so here,
we do not test for support for these specific attributes or methods
	*/
		};
	}
else if (element.childNodes.length == 1 && element.childNodes[0].nodeName ==
"#text")
/*
Explanations: we end up with cases where element content consists of 1 single
text node
*/
	{
	element.childNodes[0].nodeValue = newText;
	}
else if (element.childNodes.length == 1 && element.childNodes[0].nodeName !=
"#text")
/*
Explanations: we end up with cases where element content consists of 1 single
non-text node
*/
	{
	element.removeChild(element.childNodes[0]);
	element.appendChild(document.createTextNode(newText));
	};
}



Regarding DOM 3 attribute textContent, I have requested to both Opera dev. team
(bug Opera 155598) and MSIE 7 dev. team via its wiki website to support and
implement textContent for their next release. 
Ideally, web developers would then avoid any kind of coding headache, complexity
(innerText, nodeValue, nodeName, createTextNode, childNodes, replaceChild, DOM 2
characterdata attributes, etc.) regarding text node replacement or text
replacement by using only 1 simple attribute like textContent. This would
greatly simplify coding tasks.


---------------

In the next patch, I will add these following references (I have some
reservations or I disagree with some of what is explained but overall, these are
good documents, useful ones for people wishing to upgrade their pages) because
these 3 references roughly address the same issues and topics that "Using web
standards in your pages" document has:

Making your web page compatible with Mozilla
http://www.reloco.com.ar/mozilla/compat.html

Preparing for standard-compliant browsers, Part 1 By Makiko Itoh, April, 2001
http://www.digital-web.com/articles/preparing_for_standard_compliant_browsers_part1/

Preparing for standard-compliant browsers, Part 2 by Makiko Itoh, July, 2001
http://www.digital-web.com/articles/preparing_for_standard_compliant_browsers_part2/

and I will add a <link rel="alternate"> to the Chinese translation.

Comment 121

[Gérard Talbot]

Attachment: Patch revision 1.47 (checked in)

- added a reference to the Chinese translation
- added 3 links/resources
- changed a <p> for a enumerative list

Comment 122

[Gérard Talbot]

(In reply to comment #73)
> 5- This document should be explicitly recommending that web authors ought to
> tell their NS 4.x visitors to upgrade, to visit browsehappy.com, to download
> Firefox or Mozilla 1.7.3 or Opera 7.x or any highly standards-compliant browser.

Netscape DevEdge had a document also doing exactly that:
http://devedge-temp.mozilla.org/upgrade.html

Comment 123

[Gérard Talbot]

In my next patch,
I will remove this:

{
document.elementName
(i.e., getting a reference to the element <p name="yooneek"> with document.yooneek)
}

and will add this in the Accessing Elements with the W3C DOM section:

IE-specific ways to (...)	W3C web standards replacements 
InputName.value                 document.forms["FormName"].InputName.value     
      
                       or document.forms["FormName"].elements["InputName"].value

This sort of problem is happening a lot as evidenced by many bugreports filed.

Comment 124

[Gérard Talbot]

Attachment: Patch revision 1.48 (checked in)

- added InputName.value and FormCtrlName
- removed <p name="yooneek">
- a few nits

Comment 125

[Gérard Talbot]

I'd like to hear some feedback on the <applet> to <object> conversion section.

- applet are rather rare on the web (compared to other features that are
commonly encountered in webpages). Even embedded flash is now more often seen
than java applets
- that section is too long and is difficult to justify, at least, hardly a major
issue on the web when referring to web standards usage in webpages. There is a
lot of other invalid markup code that breaks in W3C web standars compliant user
agents.
- <applet> do not break in Mozilla-based browsers, is supported in Mozilla-based
browsers. So why should we explain, detail on how to convert something that
already works and generally without a problem?
- typically speaking, among all of the invalid markup code that breaks in W3C
web standars compliant user agents, <applet> usage is not one of them, is not
typical
- Sun's document 
http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html
does not even promote a valid markup solution to <applet> to begin with. So, our
document is "fighting against" Sun's document in a certain manner.
- Sun's document does not offer a simple, clear and easy way to code <object>
anyway. It offers to use <embed>, <applet>, <comment>, <noembed>,
document.write(), etc.. Sun also provides an "HTML converter" to convert
<applet> into complex and invalid code. 
- web standards advocacy or tutorials sites do not even address the issue of
converting <applet> to <object>. The only rare exception I found is Shayne
Steele. Maccaws, DevEdge, A list apart, etc.. have never addressed this issue.
So why should we?
- usage of java in a webpage can lead to all sorts of code (data in jar, java
application, codetype, classes in jar or not, etc). Even Shayne Steele admits
this and only provides the minimum needed for such conversion.

So what should we do? What do you think?
a) Remove the whole <applet> to <object> section
b) Remove the "Explanations on the code" subsection in that <applet> to <object>
section and just leave the Shayne Steele resource and 2 links referencing HTML
4.01 available to readers
c) Leave everything as it is

Comment 126

[Gérard Talbot]

Attachment: Patch revision 1.49 (checked in)

- Added 4 recommendable resources (guide, lesson, tutorials) on upgrading
webpages with CSS
- replaced "element" for "ElemRef" in code examples; using "element" everywhere
was an instructional error as "element" was used indistinguishly to refer to
scriptable object and HTML element.
- replaced Nav* with NS*
- several text improvements

Comment 127

[Gérard Talbot]

Regarding <applet> vs <object, Sun says:
"The HTML specification states that the applet tag is deprecated, and that you
should use the object tag instead. However, the specification is vague about how
browsers should implement the object tag to support Java applets, and browser
support is currently inconsistent. Sun therefore recommends that you continue to
use the applet tag as a consistent way to deploy Java applets across browsers on
all platforms."
http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/using_tags.html#applet
The document was edited, reviewed several times in 2005.

Unless I hear objections, I will reduce the current section on applet conversion
to minimum in my next patch; the next patch will include other changes I'm
working on.

Comment 128

[Reed Loden [:reed]]

(In reply to comment #127)
> Unless I hear objections, I will reduce the current section on applet conversion
> to minimum in my next patch; the next patch will include other changes I'm
> working on.

Is this patch coming anytime soon? :)

I know Deb wants to redirect this page to something like [http://developer.mozilla.org/en/docs/Web_Standards].

Comment 129

[Gérard Talbot]

> Is this patch coming anytime soon? :)

I decided to postpone this decision regarding the java-<object> section indefinitely because
- IE7 will have to modify its support for <object> since Microsoft will have to modify its support for java applet before December 2007.
- I've sent so far 2 feedback forms to Sun regarding updating their 
"Using applet, object and embed Tags" page and asking them to upgrade their page.  The idea is it's more profitable for everyone if everyone's documents go in the same direction

> I know Deb wants to redirect this page to something like
> [http://developer.mozilla.org/en/docs/Web_Standards].

The thing with the current document is that it still needs updates and upgrades:
- I think that the "Upgrading Layer Elements (Netscape 4)" section now can be entirely and safely dropped. Google's recent survey on 1 billion webpages 
http://code.google.com/webstats/2005-12/pages.html
suggest we can do this. In web programming newsgroups, I have not heard nor seen a single question in the last 18 months about how to upgrade <layer>, <ilayer> into  a standards compliant HTML 4.01 webpage (or anything close to such subject). NS 4.x represents less than 0.5% of browser share in all of world stats sites.
- The "Changing an Element's Text Using the DOM" section should be entirely upgraded. Also, as I said in this bugfile, it would be best to write a specific and unique document on how to change an element's text using the DOM and then to link to it in http://developer.mozilla.org/en/docs/Web_Standards , so that a "Web Standards in your page" document would be more compact. By itself and for itself, changing an element text with DOM rightly requires a single document. We hope (and am pretty sure) IE7 will support DOM3 textContent attribute.
- All 4 issues mentioned in comment #93 should be done IMO.

Comment 130

[Gérard Talbot]

I'm working on a patch right now in which web standards compliance (valid markup code, CSS code, benefits of valid code, doctype switching, rendering modes, where to validate, etc.) will be defined, explained, addressed. Generally speaking, the document will be updated to reflect the biggest and most frequent problems on the web right now: tag soup, document.all usage, invalid (markup and/or CSS) code. The whole "Upgrading Layer Elements (Netscape 4)" part will be dropped, removed: it's blatant-obvious this is no longer a need for such section. 

Also, the <applet> section will be replaced by a single paragraph explaining how to use <object> tag.

I hope to be able to submit the whole text in the next 3 days.

Comment 131

[Gérard Talbot]

The current sections

1. Upgrading Layer Elements (Netscape 4)
2. Deprecated Elements

   o Applet
   o Font
   o Other Deprecated

3 Other Excluded Elements


will be replaced in this manner:


1.Benefits of using web standards
=================================
    a) What are the benefits
    ------------------------
        a1) for valid markup code
        a2) for CSS implementation
        a3) for valid CSS code
    b) Reduced browser incompatibilities
    ------------------------------------
    c) 2 risks regarding editing with a WYSIWYG HTML editor
    -------------------------------------------------------
    d) References
    -------------

2. Making your markup code valid: how to
========================================
    a) Step 1:  Choosing a doctype declaration
    ------------------------------------------
        a1) "doctype switching"
    b) Step 2: Validate your HTML 4 code
    ------------------------------------
        b1) Where can I validate my webpages? How to validate webpages?
        b2) the top 5 most frequently encountered validation errors and how to fix them
        o improper nesting of elements
        o unescaped ampersands in URLs
        o misplaced elements (eg block-level element nested within inline element)
        o missing elements (eg <title> not in <head>)
        o missing alt attribute in <img>
        b3) How to upgrade markup code in some frequently encountered cases
        -------------------------------------------------------------------
        o what if I use <font>? how to define a font with CSS?
        o what if I use <center> or align="center"? how to align with CSS?
        o what if I use bgcolor? how to colorize background with CSS?
        b4) How to upgrade markup code in specific cases
        ------------------------------------------------
        o what if I use <embed> for flash or for a video?
        o what if I use <applet>?
        o what if I use <marquee>
        o what if I have <bgsound>
    c) Step 3: Validate your CSS code
    ---------------------------------
        c1) Where can I validate my CSS code?
        c2) Top 2 most frequently encountered CSS errors and how to fix these
        o Missing units
        o ?


Note here that explanations on how to replace <layer>, <ilayer> are dropped; also explanations on how to replace s, strike, u, dir, menu, and blink are also dropped.

Patch coming up in a few days...

Comment 132

[Gérard Talbot]

4 patches have been checked in. The new content still has to be revised, streamlined and tweaked. Comments and feedbacks are welcomed.
Once the document gets more finalized, I will transpose/transfer the new version to the page

http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages

With the new Doctor interface, I couldn't figure out how to save the submitted patches before checking in.

Comment 133

[Gérard Talbot]

To do later:

- Object/Feature detection approach: best, most reliable
into
Object/Feature support detection approach: best, most reliable

- The "2 risks regarding editing with a WYSIWYG HTML editor" section should be more compact and to the point; I think it is appropriate to mention that Nvu 1.0 and KompoZer 0.77 have built-in markup cleaner and can install HandCoder 0.3.4 to clean a lot of deprecated stuff and bloated code.

- I need to complete the "Top 5 most frequently encountered validation errors and how to fix them" section, with examples and some explanations.

- bgcolor section: I need a better example where removing bgcolor would "pay back" more, "return" better, like a whole table column being colorized. The current example is not best as, I believe, bgcolor is supported by Gecko even in standards compliant rendering mode.

- The "Top 2 most frequently encountered CSS errors and how to fix these" section needs to be completed.

Comment 134

[Gérard Talbot]

Attachment: Patch revision 1.57 (checked in)

Checking in mozilla-org/html/docs/web-developer/upgrade_2.html;
/cvsroot/mozilla-org/html/docs/web-developer/upgrade_2.html,v  <--  upgrade_2.html
new revision: 1.57; previous revision: 1.56
done


Added a link to frequent validation markup errors; removed the top 2 CSS errors and put back the explanation on the CSS missing units error; made 2 sentences a bit less repetitive; broke 1 sentence into 2 sentences.

Comment 135

[Gérard Talbot]

Hello all,

The June version of the document has been migrated to MDC 

http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages

and the last 10 changes made to the document since then will be added/inserted in it in the coming next few days or so. So, in practical terms, this bug is RESOLVED.

What still needs to be done in the document?

1- As I explained in comments #93, #99, #120 and #129, the whole section "Changing an Element's Text Using the DOM" should be upgraded and then should be removed and should be placed into a distinct, separate, unique document where, at the same time, the readers would be explained what are textnodes, DOM tree, DOM nodes, white-space. Changing, manipulating text nodes can not be done/taught without explaining what are DOM nodes. A good example of how the whole section "Changing an Element's Text Using the DOM" could be redone is the document
http://developer.mozilla.org/en/docs/Using_the_W3C_DOM_Level_1_Core

2- Several examples need to be improved or better chosen

 a) 
 Semantically speaking, this code
 <P style="color: blue; font-family: Helvetica, sans-serif;">A really
 <big>big</big> shoe.</P>
 should be considered better than
 <P style="color: blue; font-family: Helvetica, sans-serif;">
 A really <SPAN style="font-size: larger;">big</SPAN> shoe.
 </P>
 which is what we proposed as best.
 b) 
 The example
 var arrCollection_Of_Anchors = document.getElementsByTagName("a");
 is not best as 
 var arrCollection_Of_Anchors = document.links;
 is a DOM 1 method which is overall more supported by browsers than 
 getElementsByTagName. The use of getElementsByTagName here is not best or 
 ideal.
 c) 
 The bgcolor attribute CSS conversion example is not best: at the time, I 
 couldn't think of a better example
 d) 
 "Top 5 most frequently encountered validation errors" should have mentioned
 <p><table></table></p>
 and
 <p><ul>...</ul></p>
 which are fairly often seen on the web

3-
This quote 
"Quirks mode is different for each browser, and is generally much harder to develop for and maintain than the alternative 'standards compliance mode'."
from David Hammond at http://www.webdevout.net/articles/my_site_doesnt_work_in_x_browser.php
fits perfectly what I'm saying in the "Doctype switching" section of the document and therefore should be inserted in the document.


Resolving as WORKSFORME