(In reply to comment #0)
> | For example, behavior in exceptional circumstances (such as when a null
> | argument is passed when null was not expected) is discussed under
> | DOMException,
> 
> This is now handled by WebIDL; the parenthetical should probably be removed
> or replaced.

I removed this, as well as the example of exceptions, since that also has transitioned over to WebIDL's definition (not DOM L3 Core's usage).


> | (e.g., a conforming DOM3 Events user agent must support the DOMString data
> | type as defined in DOM3 Core, but need not support every method or data type
> | defined in DOM3 Core in order to conform to DOM3 Events).
> 
> DOMString, too, is defined in WebIDL.

Made this example a reference to WebIDL instead of DOM3 Core--the spirit of the sentence is still intact.


> | A dynamic or interactive user agent [...] conforms to DOM Level 3 Events if
> | it supports the [features] which are not marked as deprecated,
> 
> This seems like an uncommon use of the word "deprecated". Not sure what to say
> instead, though.

A little awkward, I agree. I tried to re-phrase and clarify but I'm stuck with the word "deprecated" unless I want to make a more invasive change (which I don't want to do :)

 
> | A conforming browser must support scripting, declarative interactivity, or
> | some other means of detecting and dispatching events in the manner described
> | by this specification, and with the attributes specified for that event type.
> 
> It seems strange to call out "attributes" here; maybe "interfaces" or "APIs"
> would be better.

I went with "APIs" and rephrased a bit.


> | A declarative browser may still conform to this specification if it does not
> | directly support or expose the methods defined for the DOM Level 3 Events
> | interfaces, but it should provide compatible functionality by other means.
> 
> I don't think this sentence is necessary; why would a "declarative browser",
> whatever that is, need to claim conformance to D3E?

Dropped. Additionally (in my view) that sentence contradicted the previous sentence. (A MUST requirement, then an opt-out via a MAY requirement?)


> | A conforming browser may also support features not found in this
> | specification, [...] Such features may be later standardized in future
> | specifications.
> 
> The second "may" probably doesn't want to be a RFC2119 keyword.

Now a "can" (my favorite "may" substitute).


> | Conforming content must use the semantics of the interfaces and event types
> | as described in this specification, and must follow best practices as
> | described in accessibility and internationalization guideline specifications.
> 
> I'm all for following best practices, but I don't think it is up to D3E to tell
> me that.

Pulled this part out as a note, remvoed the RFC2119 keywords, and linked to some
interesting starting points for accessibility and internationalization guides and resources on the W3C.


> | Events defined in conforming specifications must not have name conflicts with
> | known languages,
> 
> I'm not sure what "name conflicts" means here, but if it means you can't
> define events with the same type, but different interfaces, I believe that
> would be widely violated. I doubt we really need this requirement, in fact.

I'm wondering if it was describing defining events with names like "class", "var", "unsigned"...? Either way, it doesn't seem like a necessary requirement, so I removed it. I also removed the last sentence which asked any editor referencing this spec to consult with the this working group prior to _using_ or extending the features defined herein. I also don't think that's necessary to indicate in the spec, since that kind of thing happens naturally as part of the editorial and review process defined by the W3C. No need to state it as a SHOULD requirement (that can't be tested).