w3ctag / design-reviews Goto Github PK

W3C specs and API reviews

License: Creative Commons Zero v1.0 Universal

JavaScript 100.00%

design-reviews's Introduction

W3C TAG Specification Reviews

This repository is for specification reviews by the W3C Technical Architecture Group; usually (but not always) from W3C Working Groups.

How reviews are performed/prioritized

We use the issues list to track our reviews; you can request a review for your spec by adding a new issue. Please include a link to the relevant specification(s). As well, please include info on timeliness of the required review, whether a security review / privacy been done and the expectation of what happens next after the review. We have included a useful template for new issues that should lead you through the process. In most cases the review will be completed and documented in the comments field of the issue itself.

If you have general questions about the design review process, the application of the Web Platform Design Principles or other aspects of web platform architecture or design, please feel free to open up a discussion thread.

Generally speaking, we will discuss and review in our own issue list and cross-link to relevant issues in the specs we are reviewing. See #112

Code of Conduct

Discussions in this repo are subject to the W3C Code of Ethics and Professional Conduct.

More detailed reviews

In some cases we have prepared more detailed review documents in response to request for review. The ones we have prepared thus far are:

design-reviews's People

Contributors

Stargazers

Watchers

Forkers

torgo twirl chrislo rainbowarray jlukic diracdeltas kleopatra999 modulexcite alexxnica kenjibaheux orijtech peterkinalex siusin frivoal clelland burnburn mlagally sebastiankb coliff alexcross11248 enumerrata daukantas wseltzer ssult dbaron plehegar leobalter rashadtr27 e1r2-2864 davidnrw82 cathy-png ivanveulru joshuakoran whitemike889 chenrykowski-prawo-dzieci daasin slimsix ladyk-21 msalgado1988 xfq the-delta-slumerican-organization qpc-github alastor0325 ressmann gonzo510 clebcp idayy16 jyasskin aphillips

design-reviews's Issues

JSON Feedback

It's been suggested that we send some formal feedback to the JSON working group in IETF suggesting a stronger (normative) link back to the ECMA-404 draft.

Extensibility of Accessibility

Per F2F conversations with @chaals and @travisleithead at the July Berlin meeting, we are going to sketch out design alternatives for low -> high level event synthesis and reuse of behavior and ARIA roles/states for new elements (i.e., avoiding re-creating all of the infrasturcture to manage focus/assistive state for everything that's button-alike).

/cc @domenic

Browser Fingerprinting Document

What feedback can we give to Nick Doty around the fingerprinting guide he is putting together int he privacy interest group? https://w3c.github.io/fingerprinting-guidance/

Web MIDI

http://webaudio.github.io/web-midi-api/

(TR version has wrong Editors Draft link; I had to track it down on GitHub. http://www.w3.org/TR/webmidi/).

I have independently left some feedback on their repo before (issues here).

The attempts at making a Map-like class seem to have gone horribly awry: http://webaudio.github.io/web-midi-api/#midiinputmap-interface

Compositing and Blending Level 1

Editor's draft:
http://dev.w3.org/fxtf/compositing-1/

Network Service Discovery

Spec: https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

multipart/form-data

Larry Masinter in IETF would appreciate our feedback

Presentation API Request for Feedback

François has requested our feedback https://lists.w3.org/Archives/Public/www-tag/2015Jul/0001.html on the presentation API: https://w3c.github.io/presentation-api/

Upgrade Insecure Requests

Hello, lovely TAG members. Would you mind reading over https://w3c.github.io/webappsec/specs/upgrade/ in your copious free time, and providing some feedback to the WG?

We're shipping an initial cut at this in Chrome 43, so I expect implementation experience to help shape the near-term future of the feature. It would be excellent to get your take on the broader problem of migration to HTTPS to see what else we could be doing to address it.

http-problem

IETF spec in the APPSAWG -
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/

May be interesting for TAG review as it effectively defines an object to convey an (HTTP) API error.

Quota Management API

https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html

This is somewhat urgent as Blink is planning to implement and ship in the near-ish future.

Custom Elements

LC As of http://www.w3.org/TR/2013/WD-custom-elements-20131024/
Edcopy: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

Web Components

Nottingham Get Off My Lawn RFC

We've been informed about the following RFC by Mark Nottingham : http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-01

Might be useful to send a comment or even to file a formal liaison about it if we feel strongly.

But blink-dev has an intent to implement for some version of it. (link?)

Cross-spec device identification & association

We're developing several specs that interact with physical devices. Several of these specs provide IDs for their devices to let web developers associate properties with the devices over time. MediaDeviceInfo takes the extra step of providing separate IDs for the "device", meaning a particular microphone, camera, speaker, etc., and for the "group", meaning a collection of devices on the same physical hardware. But media devices aren't the only thing that can come in a group, so we should be thinking about how to let web developers associate device groups between different specifications.

A particular use case for this is associating a headset's audio channels with the headset's Bluetooth settings channel.

@jan-ivar was kind enough to write down in w3c/mediacapture-main#202 some of the properties of the existing IDs:

MediaDeviceInfo.groupId is not persisted to disk, but stable within a browser-session and not origin-unique.
MediaDeviceInfo.deviceId is origin-unique, and persistent only when permission is granted: w3c/mediacapture-main#218
MIDIPort.id - is persistent but may not be origin-unique.
BluetoothDevice.id is origin-unique, not available at all until permission is granted, and persistent until permission is revoked.

Unless someone argues otherwise, I'm going to treat any lack of origin-uniqueness as a bug.

As an initial base for discussion, I'd suggest that we add a groupId property to at least BluetoothDevice, and specify that it's shared with MediaDeviceInfo.

I think we don't need the groupId to persist across browser sessions as long as the individual devices in a group do have persistent IDs, but it might be easier for developers if it is persistent. Do we make platform evolution harder in any way if the group ID is persistent?

Where should we put the algorithm for generating group IDs? How do we word that? I don't think we can specify how a UA figures out that two devices are in the same group: it'll depend a lot on the connection technologies.

Revise CSS regions draft based on outcome of 19-March discussion

https://github.com/w3ctag/spec-reviews/blob/master/2015/01/CSS%20Regions.md

CSV on the Web

TAG alumna @JeniT has requested TAG feedback on the CSV on the Web working drafts.

The Screen Orientation API

Spec: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

CSS Regions

http://dev.w3.org/csswg/css-regions-1/

Editors are specifically asking for TAG review and guidance

JSON Form Submission

http://darobin.github.io/formic/specs/json/

Subresource Integrity

https://w3c.github.io/webappsec/specs/subresourceintegrity/

@mnot wants to keep an eye on this; it also has lots of general architectural implications we should all keep in mind.

Screen orientation

https://w3c.github.io/screen-orientation/

Already had some good discussions with @mounirlamouri and @marcoscaceres.

File URI Scheme

The IETF APPSAWG is working on the file scheme:
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-02

WebRTC Identity Provider Selection

Via @annevk:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity-provider-selection

Mozilla intent to implement

The API design doesn't make sense to me, and perhaps we could help with that, but I think that's a lesser concern next to the idea of an entirely new identity primitive. This is worth us all understanding and making sure it fits well with the rest of the platform.

I need to do a lot of reading to really get this. The Mozilla intent to implement gives a nice one-paragraph overview, but the entire WebRTC world is pretty far outside my area of expertise. Any help would be welcome.

Doubling up of normative surface area.
Lack of ctors
No explanation of <audio>, only wrapping
No de-sugaring of most block types into Script Block code
TAG didn't understand why Script nodes have such a buffering/stuttering penalty...is this only in naive implementations?

Performance Observer Review (formerly Navigation Timing 2 concepts)

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming2/Overview.html

At first glance getEntriesByType seems ... weird.

contributing.md document needed for tag reviews

Document the following:

timeliness of required review
has a security review been done?
expectation of what happens next

Technical Architecture Group, for an overall review of the API,
especially the introduction of the concept of a IANA registry-based
constraints system, the use of promises, and our handling of persistent
permissions

The last call period ends on May 15.