Define supportedEntryTypes #108
Conversation
Add supportedEntryTypes and include an example of how it would be used. Solves w3c#77
|
@yoavweiss @rniwa @toddreifsteck can you take a look? I can't edit the "Reviewers" section of PR so using comment to ask for review. @igrigorik for when you're back. |
|
cc @spanicker |
|
BTW this is ready for review again, please take a look. Thanks! |
|
Hm... |
|
Consistency with completely unrelated APIs is probably not something we should worry too much about. Otherwise I could say we should also be consistent with PushManager and we will never be happy :) A better question is what would be more ergonomic to web developers. I think both ways are valid so don't have a strong opinion on which is better. |
|
You say that but all these inconsistencies throughout various features is the worst thing about the Web platform. Ideally, TAG or some other group familiar with all aspects of the Web API should be noticing these differences and fixing them but that doesn't seem to be happening either. |
|
@rniwa hmm, I like the idea — good catch. One gotcha I see here is that it also supports add/remove/toggle, which are a bit odd in our context. That said, if we're returning an array, then perhaps there is no difference? |
|
index.html
Outdated
| @@ -428,6 +438,22 @@ <h2><dfn>disconnect()</dfn> method</h2> | |||
| "WHATWG-DOM#context-object">context object</a>'s <a>observer | |||
| buffer</a>.</p> | |||
| </section> | |||
| <section> | |||
| <h2><dfn>supportedEntryTypes</dfn> attribute</h2> | |||
There was a problem hiding this comment.
I don't think you want 2 <dfn> to the same attribute, so this should probably be an <a> (with the dfn being in the paragraph below)
There was a problem hiding this comment.
Changed the dfn to the place where attribute getter is described. However, there's not quite repetition. There's supportedEntryTypes, the attribute, and supported entry types, the list maintained by the user agent which is used as the return value.
There was a problem hiding this comment.
Added a few nitty comments, but I think we're almost there. One thing that bugs me is tests: we can test the presence of the methods, but not necessarily check their return values. I guess we should add tests for those when adding support for that in the various specs that use PO.
|
I'll followup with modifications to other specs as well as tests. |
|
Yoav, there should not be a need for such a test. That's what idlharness is for. When the spec crawler gets updated, it should start failing for implementations that do not have this attribute implemented. So, are you ok just landing this? |
|
Makes sense. Ship it! :) |
Add supportedEntryTypes and include an example of how it would be used. Solves #77
Preview | Diff