W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

[Bug 16506] New: Comments on 1.2 Conformance

From: <bugzilla@jessica.w3.org>
Date: Sat, 24 Mar 2012 14:12:38 +0000
To: www-dom@w3.org
Message-ID: <bug-16506-4009@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16506

           Summary: Comments on 1.2 Conformance
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: normal
          Priority: P2
         Component: DOM3 Events
        AssignedTo: travil@microsoft.com
        ReportedBy: Ms2ger@gmail.com
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org


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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Saturday, 24 March 2012 14:12:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT