info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: A few Qs about Specification_list
9 views
Skip to first unread message
Sebastian Zartner
May 23, 2016, 3:47:22 AM5/23/16
to art.b...@gmail.com, mozilla...@lists.mozilla.org
Obviously this mail got overlooked before. Sorry for that!
On 25 September 2015 at 14:00, <art.b...@gmail.com> wrote:
> Hi All,
>
> I recently made a few updates to [Spec_list] and the [SpecName] and
> [Spec2] templates. I have some Qs about a few other specs and Jean-Yves
> suggested I send them to this list ...
>
> * "HTML APIS" - generally, it appears that if WHATWG has an active
> spec/standard, a link to its LS should be used as the url in SpecName. The
> following five specs - which are included in the WHATWG's HTML spec and
> also published by WebAppsWG - don't follow this pattern: Web Storage, HTML
> Web Messaging, Web Workers, Web Sockets and Server-sent Events. The first
> four use github/w3c/<shortname> for their url and the last one uses
> w3.org/TR/<shortname> (where <shortname> is, for example "webstorage").
> Should the urls for these specs be changed to links to the HTML LS (f.ex.
> Web Storage would use <
> https://html.spec.whatwg.org/multipage/webstorage.html#webstorage>)? If
> this change is made, perhaps the status for these specs would be (using
> webstorage as an example) "LS Living Standard (also REC Recommendation)".
> WDYT?
>
I didn't check each mentioned specification yet, though I'd say the link
and the status should always be kept consistent. If there is a
recommendation and a living standard, both should be added to the macros
and listed within the articles' specification tables.
* Selectors API L2 - WebAppsWG stopped working on this spec several years
> ago and published a "Working Group Note". The expectation is the spec's
> features would be included in DOM. As such, perhaps the url should use the
> DOM LS. Additionally, the status is WD which isn't accurate but it doesn't
> appear "WG Note" is supported by Spec2. Perhaps the status should be
> something like "DOM LS Living Standard (also WG Note)".
>
I agree that the status of the Selectors API L2 should be changed to a
note. I disagree to change the link to the DOM LS, though. Instead, we
should add the DOM4 spec. to the specifications table where it's missing.
* Progress Events - the url correctly uses the XHR LS but the status says
> CR. Since a REC for this was published but no further work by W3C is being
> done, perhaps the status should be changed to something like "LS Living
> Standard (also REC Recommendation)".
>
Same as for the first point. When there is a recommendation and a living
standard, both should be available in the macros and listed separately in
the specifications tables.
Regarding the specifications list, I think we should only list the latest
spec. defining a feature.
If there are no objections or other opinions, say in the next two weeks,
I'll file a bug for this and start adjusting SpecName, spec2 and the
Specifications list accordingly.
Sebastian
On 25 September 2015 at 14:00, <art.b...@gmail.com> wrote:
> Hi All,
>
> I recently made a few updates to [Spec_list] and the [SpecName] and
> [Spec2] templates. I have some Qs about a few other specs and Jean-Yves
> suggested I send them to this list ...
>
> * "HTML APIS" - generally, it appears that if WHATWG has an active
> spec/standard, a link to its LS should be used as the url in SpecName. The
> following five specs - which are included in the WHATWG's HTML spec and
> also published by WebAppsWG - don't follow this pattern: Web Storage, HTML
> Web Messaging, Web Workers, Web Sockets and Server-sent Events. The first
> four use github/w3c/<shortname> for their url and the last one uses
> w3.org/TR/<shortname> (where <shortname> is, for example "webstorage").
> Should the urls for these specs be changed to links to the HTML LS (f.ex.
> Web Storage would use <
> https://html.spec.whatwg.org/multipage/webstorage.html#webstorage>)? If
> this change is made, perhaps the status for these specs would be (using
> webstorage as an example) "LS Living Standard (also REC Recommendation)".
> WDYT?
>
I didn't check each mentioned specification yet, though I'd say the link
and the status should always be kept consistent. If there is a
recommendation and a living standard, both should be added to the macros
and listed within the articles' specification tables.
* Selectors API L2 - WebAppsWG stopped working on this spec several years
> ago and published a "Working Group Note". The expectation is the spec's
> features would be included in DOM. As such, perhaps the url should use the
> DOM LS. Additionally, the status is WD which isn't accurate but it doesn't
> appear "WG Note" is supported by Spec2. Perhaps the status should be
> something like "DOM LS Living Standard (also WG Note)".
>
I agree that the status of the Selectors API L2 should be changed to a
note. I disagree to change the link to the DOM LS, though. Instead, we
should add the DOM4 spec. to the specifications table where it's missing.
* Progress Events - the url correctly uses the XHR LS but the status says
> CR. Since a REC for this was published but no further work by W3C is being
> done, perhaps the status should be changed to something like "LS Living
> Standard (also REC Recommendation)".
>
Same as for the first point. When there is a recommendation and a living
standard, both should be available in the macros and listed separately in
the specifications tables.
Regarding the specifications list, I think we should only list the latest
spec. defining a feature.
If there are no objections or other opinions, say in the next two weeks,
I'll file a bug for this and start adjusting SpecName, spec2 and the
Specifications list accordingly.
Sebastian
Sebastian Zartner
Jun 7, 2016, 7:58:28 AM6/7/16
to mozilla...@lists.mozilla.org
On Monday, May 23, 2016 at 9:47:22 AM UTC+2, Sebastian Zartner wrote:
> Obviously this mail got overlooked before. Sorry for that!
>
> Obviously this mail got overlooked before. Sorry for that!
>
Sebastian
0 new messages