Bug 16506 - Comments on 1.2 Conformance
Summary: Comments on 1.2 Conformance
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords: needsReview
Depends on:
Blocks:
 
Reported: 2012-03-24 14:12 UTC by Ms2ger
Modified: 2012-04-07 00:28 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ms2ger 2012-03-24 14:12:36 UTC
| 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.

| (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.

| 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 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.

| 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?

| 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.

| 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.

| 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.
Comment 1 Travis Leithead [MSFT] 2012-04-07 00:28:23 UTC
(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).