Re: Editor/proofreader request on html/elements/body

Thanks for the mail Jacob - sounds like some great work was done at the Adobe event!

I've included some replies to your message inline, below.

Chris Mills
Open standards evangelist, Opera Software
W3C fellow
Co-chair, web education community group, W3C

* Author of "Practical CSS3: Develop and Design"
  (http://my.opera.com/chrismills/blog/2012/07/12/practical-css3-my-book-is-finally-published)
* The definitive guide to developing with the webplatform:
  http://www.webplatform.org

On 3 Nov 2012, at 23:28, Jacob Reiff <jacob@jaacob.com> wrote:

> I'd like a editor/proofer and have the following questions regarding what I've done so far.
> 
> http://docs.webplatform.org/wiki/html/elements/body

I have a comment here - when frozenice did some work on speccing out how to edit the HTML reference, he did the paragraph element, and HTMLParagraphElement DOM interface:

http://docs.webplatform.org/wiki/html/elements/p
http://docs.webplatform.org/wiki/dom/HTMLParagraphElement

Then we documented it in the most wanted tasks page, in the "Specific call to action: help clean up HTML element references" section, see

http://docs.webplatform.org/wiki/WPD:Most_Wanted_Tasks

We decided that it would be more correct to put the events, properties and methods in the DOM Interface page, and just leave the basic info in the element page. I see you've not done that, so a heads up there. Perhaps we should put a prominent link in the element page somewhere, to points readers to the DOM interface page for info on events, etc.

Good work though - thanks for your help on the project!

> 
> Meta:HTML/Elements/body and original MSDN article were merged in.
> 
> In the HTML Event Handler Content Attributes table, should the events link to (for example) /events/onblur or dom/events/blur ?

I would say the latter, as the "on" bit is implied by the fact it's an event. When we talk about events, do we commonly include the "on" bit? We surely say "A click event", not "an onclick event" ? Thoughts?

This seems to be the convention that has been followed on other pages too.

> 
> From the MSDN import, I moved what seemed appropriate into the correct fields. I updated the formatting on the tables under the Members subsection, but left that MSDN data in the Import Notes section, because my inclination was that that data belongs in dom/HTMLBodyElement.

Yup, that's wise.

> 
> I left the following tags:
> + Data Not Semantic: because of the imported data in Import Notes
> + Unreviewed Import: because the data in Import Notes needs to be reviewed and appropriately dealt with
> + Cleanup: because that data potentially needs to be cleaned up/out.
> 
> I strayed on the side of leaving more tags than removing them. If there's a more conforming way I should have tagged it, please let me know.
> 
> Every time an actual element was mentioned, I wrapped it in <code>. I'd like to update the Style Guide to be explicit about this, one way or the other. (My preference is to include the brackets on elements and wrap everything that makes sense in <code>, but I'd like direction on what is preferred.) Although, I ran into a bug: <code><div></code> is interpreted. (Filed bug 19849.)
> 
>    + Wow, HTML is an amazing markup language! (no <code>)
>    + You always put the <code><body></code> element inside the <code><html></code> element.
>    + Only sites with light background colors are legible.
>    + I used <code>background-color: #222;</code> on my site because it's easier to read.

Yeah, there are still some issues here - thanks for filing the bug.

> 
> On a sidenote: I enjoyed the doc sprint today at Adobe and look forward to contributing further to the project.
> 
> --
> Jacob Reiff / jaacob
> http://about.me/jacobreiff
> 
> 
> 
> 
> 
>

Received on Monday, 5 November 2012 14:43:44 UTC