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

On 7 Nov 2012, at 14:35, Jacob Reiff <jacob+webplatform@jaacob.com> wrote:

> Chris - thanks for the feedback. I have threaded my response inline.
> 
> On Nov 5, 2012, at 6:43 AM, Chris Mills wrote:
> 
>> 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
>> 
>> 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!
> 
> Is the idea that on the DOM Interface page, we list the events, properties and methods that are either unique to this element or aren't applicable any higher up the DOM tree? So if HTMLElement already has the event, you don't list it again on HTMLParagraphElement because HTMLParagraphElement subclasses HTMLElement. 

Hrm, really good question. It would make sense to use an intelligent automated process to associate parent and child Interfaces, and their properties and methods in this way. But until we have one of those, I'd just list all of them where appropriate.

Received on Wednesday, 7 November 2012 21:11:07 UTC