User talk:Jabez

  • Revision slug: User_talk:Jabez
  • Revision title: User talk:Jabez
  • Revision id: 198022
  • Created:
  • Creator: Nickolay
  • Is current revision? No
  • Comment /* DOM Reference discussion */

Revision Content

Hi Jabez.

You asked "Hi Dria. Is there a ready-made page template to allow me to add new pages to the DOM reference please, in place of those red colored dead-end links?"

We don't have a template, no, but if you're going to document new things, just copy the general structure from another page in the reference. Thanks in advance for your help! -- dria 05:15, 7 July 2006 (PDT)

DOM Reference comments

Hi, thanks for your help with the DOM reference. Please use the talk pages for your comments instead of putting them (commented out) on the reference page itself. That way, people can see your comments without going into the edit mode.

And please feel free to go ahead and fix the problems you see, after some research. --Nickolay 04:10, 10 July 2006 (PDT)

Ok, thanks Nickolay. I find it helps me to learn the DOM, by trying out small code snippets, and then adding them to the reference. Currently I use Firefox 1.5.0.4 and the FireBug extension ( https://addons.mozilla.org/firefox/1843/ ) for testing examples. Aardvark is also handy at times for studying page layout. http://karmatics.com/aardvark/ - Jabez

Parameters section

We've been removing that section from the paging (merging it with the Syntax section). Please don't add it back. "Parameters" is not accurate, as it's actually "parameters and return values and maybe something more", and there's no reason for it to be in a separate section. --Nickolay 11:10, 14 July 2006 (PDT)

I did wonder about that. So when I come across a parameter or return values section, shall I just move it to the syntax section?

What about methods that have a long list of parameters, such as:

http://developer.mozilla.org/en/docs/DOM:event.initMouseEvent

what shall I do with a long list of parameters like this?

I think it goes without saying that a return value is obviously not a parameter.

Jabez

I think we should keep/move the parameters/return values/whatever in/to the Syntax section in all cases.
(By the way, on the reference pages I edited, the actual parameters were listed first, followed by the return value description. You moved the return value to be the first thing described. I'm fine with it, just FYI in case you wondered about that too.) --Nickolay 18:13, 15 July 2006 (PDT)

OK thanks Nickolay. As we read from left to right, I think it makes sense to keep the return value and the parameter description(s) in the same order as they appear in the declaration. Jabez

DOM Reference discussion

Hi, you've been actively editing the DOM reference for a while, so you might be interested in discussion about it on dev-mdc: --Nickolay 05:57, 28 August 2006 (PDT)

Thanks for the invite Nickolay. I might drop in later and see what's happening there! Jabez

Update - I think there needs to be a detailed and carefully thought out plan for a skeleton structure of how the newly re-organised DOM documentation will be organised. This would give the contributors some sort of guidelines and framework to code in. Something like a top down tree structure - similar to a detailed list of contents should do. This could start at the MDC homepage and then cover all of the documentation.

As far as interfaces go, for someone learning web development, they don't mean alot to me, although they are probably quite important to others. I'm far more concerned about what DOM objects are available, and what properties, methods and events they offer a web designer interested in DHTML. All I need is a simple example to illustrate how a particular property, method, or event can be used in my website code. Quote from http://www.w3schools.com, "Never increase, beyond what is necessary, the number of entities required to explain anything" -- William of Ockham (1285-1349).

The DOM:style documentation is a bit vague to say the least, and I'm not even sure if this is actually needed. I'm trying to think of a way to document the CSS style properties, without having multiple instances of the documents under different titles.

For non-javascripters that want to use CSS stylesheets statically, there obviously needs to be a CSS reference for their use.

For others that want to manipulate style values through the DOM dynamically with DHTML, maybe some sort of introducion on how to manipulate a page element's style values would be helpfull.

This could also cover the following objects:

  • style element object - which represents the <style> tag in an (x)html document.
  • styleSheet object - a member of the styleSheets array
  • cssRule object - a member of the cssRules array
  • style object - a property of an (x)html element

Then, for the full list of properties that can be manipulated via an element's style object, just point them to the static CSS properties reference. There also needs to be a note concerning javascript's non-use of the '-' character, and that for each style property mentioned in the static CSS reference, the '-' character needs to be removed, and the character following the '-' upper-cased, with a few examples as well. HTH.

Jabez

Could you post this to the list/newsgroup please? We're trying to keep the discussion there. --Nickolay 09:49, 28 August 2006 (PDT)

Revision Source

<p>Hi Jabez.
</p><p>You asked "Hi Dria. Is there a ready-made page template to allow me to add new pages to the DOM reference please, in place of those red colored dead-end links?"
</p>
<dl><dd> We don't have a template, no, but if you're going to document new things, just copy the general structure from another page in the reference.  Thanks in advance for your help! -- <a href="User:Dria">dria</a> 05:15, 7 July 2006 (PDT)
</dd></dl>
<h3 name="DOM_Reference_comments"> DOM Reference comments </h3>
<p>Hi, thanks for your help with the DOM reference. Please use the talk pages for your comments instead of putting them (commented out) on the reference page itself. That way, people can see your comments without going into the edit mode.
</p><p>And please feel free to go ahead and fix the problems you see, after some research. --<a href="User:Nickolay">Nickolay</a> 04:10, 10 July 2006 (PDT)
</p><p>Ok, thanks Nickolay. I find it helps me to learn the DOM, by trying out small code snippets, and then adding them to the reference. Currently I use Firefox 1.5.0.4 and the FireBug extension ( https://addons.mozilla.org/firefox/1843/ )
for testing examples. Aardvark is also handy at times for studying page layout. http://karmatics.com/aardvark/ - <a href="User:Jabez">Jabez</a>
</p>
<h3 name="Parameters_section"> Parameters section </h3>
<p>We've been removing that section from the paging (merging it with the Syntax section). Please don't add it back. "Parameters" is not accurate, as it's actually "parameters and return values and maybe something more", and there's no reason for it to be in a separate section. --<a href="User:Nickolay">Nickolay</a> 11:10, 14 July 2006 (PDT)
</p><p>I did wonder about that. So when I come across a parameter or return values section, shall I just move it to the syntax section?
</p><p>What about methods that have a long list of parameters, such as:
</p><p>http://developer.mozilla.org/en/docs/DOM:event.initMouseEvent
</p><p>what shall I do with a long list of parameters like this?
</p><p>I think it goes without saying that a return value is obviously not a parameter.
</p><p>Jabez
</p>
<dl><dd> I think we should keep/move the parameters/return values/whatever in/to the Syntax section in all cases.
</dd><dd> (By the way, on the reference pages I edited, the actual parameters were listed first, followed by the return value description. You moved the return value to be the first thing described. I'm fine with it, just FYI in case you wondered about that too.) --<a href="User:Nickolay">Nickolay</a> 18:13, 15 July 2006 (PDT)
</dd></dl>
<p>OK thanks Nickolay. As we read from left to right, I think it makes sense to keep the return value and the parameter description(s) in the same order as they appear in the declaration. <a href="User:Jabez">Jabez</a>
</p>
<h3 name="DOM_Reference_discussion"> DOM Reference discussion </h3>
<p>Hi, you've been actively editing the DOM reference for a while, so you might be interested in discussion about it on dev-mdc:
<a class="external" href="http://groups.google.com/group/mozilla.dev.mdc/browse_thread/thread/540f66c891d7d367/c9c2de8ff2881661#c9c2de8ff2881661"> </a><a class="external" href="http://groups.google.com/group/mozilla.dev.mdc/browse_thread/thread/7fe0750151b10402/ac5219efb0a9770e?lnk=raot#ac5219efb0a9770e">
--Nickolay 05:57, 28 August 2006 (PDT)
</a></p><p><a class="external" href="http://groups.google.com/group/mozilla.dev.mdc/browse_thread/thread/7fe0750151b10402/ac5219efb0a9770e?lnk=raot#ac5219efb0a9770e">Thanks for the invite Nickolay. I might drop in later and see what's happening there! </a><a href="User:Jabez">Jabez</a>
</p><p>Update - I think there needs to be a detailed and carefully thought out plan for a skeleton structure of how the newly re-organised DOM documentation will be organised. This would give the contributors some sort of guidelines and framework to code in. Something like a top down tree structure - similar to a detailed list of contents should do. This could start at the MDC homepage and then cover all of the documentation.
</p><p>As far as interfaces go, for someone learning web development, they don't mean alot to me, although they are probably quite important to others. I'm far more concerned about what DOM objects are available, and what properties, methods and events they offer a web designer interested in DHTML. All I need is a simple example to illustrate how a particular property, method, or event can be used in my website code. Quote from http://www.w3schools.com, <code><i>"Never increase, beyond what is necessary, the number of entities required to explain anything" -- William of Ockham (1285-1349).</i></code>
</p><p>The DOM:style documentation is a bit vague to say the least, and I'm not even sure if this is actually needed. I'm trying to think of a way to document the CSS style properties, without having multiple instances of the documents under different titles.
</p><p>For non-javascripters that want to use CSS stylesheets statically, there obviously needs to be a CSS reference for their use.
</p><p>For others that want to manipulate style values through the DOM dynamically with DHTML, maybe some sort of introducion on how to manipulate a page element's style values would be helpfull.
</p><p>This could also cover the following objects:
</p>
<ul><li> <i><b>style element object - which represents the &lt;style&gt; tag in an (x)html document.</b></i>
</li></ul>
<ul><li> <i><b>styleSheet object - a member of the styleSheets array</b></i>
</li></ul>
<ul><li> <i><b>cssRule object - a member of the cssRules array</b></i>
</li></ul>
<ul><li> <i><b>style object - a property of an (x)html element</b></i>
</li></ul>
<p>Then, for the full list of properties that can be manipulated via an element's style object, just point them to the static CSS properties reference. There also needs to be a note concerning javascript's non-use of the '-' character, and that for each style property mentioned in the static CSS reference, the '-' character needs to be removed, and the character following the '-' upper-cased, with a few examples as well. HTH.
</p><p><a href="User:Jabez">Jabez</a>
</p>
<dl><dd> Could you post this to the <a href="Project:en/Community#MDC_Forums">list/newsgroup</a> please? We're trying to keep the discussion there. --<a href="User:Nickolay">Nickolay</a> 09:49, 28 August 2006 (PDT)
</dd></dl>
Revert to this revision