profile
viewpoint
Sangwhan "fish" Moon cynthia @oddconcepts Tokyo | Seoul https://sangwhan.com Engineering Director at @oddconcepts. Local joker at @w3c and @w3ctag. Text wrangler at @nlp-titech.

chokkan/crfsuite 549

CRFsuite: a fast implementation of Conditional Random Fields (CRFs)

chokkan/liblbfgs 436

libLBFGS: a library of Limited-memory Broyden-Fletcher-Goldfarb-Shanno (L-BFGS)

chokkan/simstring 98

SimString

cynthia/art_of_fighting_neogeo_mvs 20

Archive of the original source code for Art of Fighting (Neo-Geo and MVS).

cynthia/chromevox 4

NOTE: This repository is not maintained. - was: Chromevox only export of Chrome accessibility suite (https://code.google.com/p/google-axs-chrome/).

cynthia/CenterNet_Pytorch_1.2 2

Object detection, 3D detection, and pose estimation using center point detection:

alice/focus 1

Collection of ideas around focus on the web

cynthia/ama 1

An educational experiment.

cynthia/fastsha1.js 1

Fast implementation of SHA-1 in pure JavaScript. (Experimental.)

cynthia/fourletterword 1

A simple four letter word generator for Processing

issue openedw3ctag/design-reviews

Limit allowed "accepted" extensions in File System Access API file pickers.

HIQaH! QaH! TAG!

I'm requesting a TAG review of a small tweak to the File System Access API.

Initially the File System Access API (previously known as Native File System API) had no limitations on what strings were allowed to be used as accepted file extensions in the showOpenFilePicker and showSaveFilePicker methods.

Since the file picker (on most platforms) appends these extensions to the filename the user enters, this can result in filenames with characters we don’t want to allow/that are otherwise problematic. In particular we don't want to allow control characters or whitespace in suffixes, or filenames that end in a '.'. As such we add restrictions on what characters are allowed in accepts file extensions/suffixes, as well as limiting their length to 16.

Limiting extensions to only contain alphanumeric characters, + or . still allows all extensions in the shared-mime-info database as well as nearly all extensions in Wikipedia's List of filename extensions.

  • Explainer/Specification URL: https://github.com/WICG/file-system-access/pull/252
  • Tests: will be added to https://github.com/web-platform-tests/wpt/tree/master/native-file-system
  • Security and Privacy self-review²: Original self-review for the File System Access API https://github.com/WICG/file-system-access/blob/master/security-privacy-questionnaire.md
  • GitHub repo (if you prefer feedback filed there): https://github.com/wicg/native-file-system/issues/
  • Primary contacts (and their relationship to the specification):
    • Marijn Kruisselbrink (@mkruisselbrink), Google
  • Organization(s)/project(s) driving the specification: Google
  • Key pieces of existing multi-stakeholder review or discussion of this specification: The File System Access API (previously known as Native File System API) as a whole was reviewed in https://github.com/w3ctag/design-reviews/issues/390
  • External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/4768827940274176

Further details:

  • [x] I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: As this fixes potential security issues we will be shipping these changes as soon as possible. We will try to address any feedback that comes in afterwards.
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WebAppsWG
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mkruisselbrink

created time in 20 minutes

issue openedw3ctag/design-reviews

CSS overflow: clip and overflow-clip-margin

HIQaH! QaH! TAG!

I'm requesting a TAG review of CSS overflow: clip and overflow-clip-margin

[One paragraph summary of idea, ideally copy-pasted from Explainer introduction]

Adds two CSS features. The 'clip' value results in a box’s content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content can not be scrolled by the user or programmatically. The overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped.

  • Explainer¹: None

  • Specification URL: https://drafts.csswg.org/css-overflow-3/#valdef-overflow-clip and https://drafts.csswg.org/css-overflow-3/#propdef-overflow-clip-margin .

  • Tests: css/css-overflow/clip-001.html css/css-overflow/dynamic-visible-to-clip-001.html css/css-overflow/overflow-body-propagation-007.html css/css-overflow/overflow-body-propagation-008.html css/css-overflow/overflow-body-propagation-009.html css/css-overflow/overflow-clip-* css/css-overflow/overflow-clip-margin* css/css-overflow/overflow-clip-scroll-size.html

  • Security and Privacy self-review²: Not aware of any security or privacy implications

  • GitHub repo (if you prefer feedback filed there): None

  • Primary contacts (and their relationship to the specification):

    • sky@google.com
  • Organization(s)/project(s) driving the specification: CSSWG

  • Key pieces of existing multi-stakeholder review or discussion of this specification: Continued evolution of overflow.

  • External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/feature/5638444178997248

Further details:

  • [ ] I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: Would love to enable this now (89) in chrome.
  • The group where the work on this specification is currently being done: CSSWG
  • Major unresolved issues with or opposition to this specification: none
  • This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

created time in an hour

issue commentw3c/clipboard-apis

What does ClipboardItem.getType do

Thanks @pwnall. I was mostly speaking in terms of what the spec wants. Because Chrome only supports creating ClipboardItem with a Blob this question doesn't really come into play.

mkruisselbrink

comment created time in 3 hours

issue commentw3ctag/design-reviews

Storage Buckets API

Hi @kenchris ! We added an API.md file that outlines the IDL to go with the proposal. Thanks!

ayuishii

comment created time in 5 hours

issue commentw3c/clipboard-apis

What does ClipboardItem.getType do

(Also, to be clear, I fully support the idea of fixing the spec. I explained what Chrome does above to unblock @evilpie.)

mkruisselbrink

comment created time in 5 hours

issue commentw3c/clipboard-apis

What does ClipboardItem.getType do

/cc @garykac @dway123 for visibility.

Chrome's implementation doesn't do anything clever in getType(), like handling image/*. IOW, I think getType() will only return data if passed one of the elements of the array returned by types().

mkruisselbrink

comment created time in 5 hours

startedjmptable/rm-dl-annotated

started time in 13 hours

startedtycrek/degoogle

started time in 13 hours

startedhse-aml/natural-language-processing

started time in 13 hours

fork songys/CrossWOZ

A Large-Scale Chinese Cross-Domain Task-Oriented Dialogue Dataset

fork in 15 hours

startedthu-coai/CrossWOZ

started time in 15 hours

startedSKTBrain/KoBERT

started time in 20 hours

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Note: We're probably changing the constants to enums.

fordacious

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

I can update the explainer to use the iterator where possible!

Oh, actually, both examples need it to be explicit. A structured API around this might be useful, and I'm open to adding one, but I'm wary of locking out accessibility in the future as platforms start exposing more info about hands with more or less than 5 fingers.

fordacious

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Can you expand on this? How would someone using hand input access the default action?

It depends on the platform, it's typically some kind of pinching gesture. It's whatever people use for "select" when using hands on the rest of the platform, outside of the web. This is how the WebXR API treats the primary action for physical controllers as well: it's whatever button people will be using on the rest of the platform (usually a trigger).

Each XRHand is owned by an XRInputSource, which represents an input source, and the actions are tied to that, as defined in the core spec. The XRHand surfaces additional articulated joint information about physical hand input sources, but it was already spec-compliant for an XR device to use hands as input without needing to opt in to the XR Hand Input specification.

fordacious

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Regarding naming: I see that the Unity hand tracking API, for example, doesn't use the medical names for bones. They use a number to indicate the joint number.

A problem with this is that it's not extensible, we're not exposing all of the hand joints that exist, we're exposing all of the hand joints that are typically used in VR hand tracking.

I find numbering to be more confusing because different platforms may choose to index differently: e.g. the indexing changes based on which carpals and metacarpals you include. For example, on Oculus/Unity only the thumb and pinky fingers have metacarpals, and the thumb also has a trapezium carpal bone. On the other hand (hah), OpenXR provides a metacarpal bone for all fingers, but no trapezium bone. So numbers don't really carry a cross-platform useful meaning.

If you just want to iterate over all of the joints, you can do that without knowing the names, but if you're going to be thinking about detecting gestures, I find names and a diagram to be far easier than plain numbers. Most humans have more than these 25 bones (+ tip "bones") in each hand, "index joint 0" doesn't tell me anything unless you show me a diagram.

I don't think using the bone name reduces the ambiguity either, since you're referring to a joint rather than the bone in any case.

it's both, really, since the orientation of that space is aligned with the named bone.

I'm also trying to understand the relationship between hand as a member of XRInputSource, and the primary action concept. Does hand input provide a way of generating a primary action?

Yes, but that's not under the purview of this spec at all. Oculus Browser and Hololens use pinch/grab actions for the primary action. The precise selection for the primary action gesture is up to the platform defaults.

Actual code wouldn't use those structures. I think @Manishearth provided that to clarify how the mapping is done.

The first example is doing this because it is outdated: it is iterable now so you don't need that array. The second example does need this.

I considered a structured approach in the past but there are basically many different ways to slice this data based on the gesture you need, so it made more sense to surface it as an indexable iterator and let people slice it themselves. Also, starting with a structured approach now may lock us out of being able to handle hands with more or less than five fingers in the future.

I can update the explainer to use the iterator where possible!

Also, can you give some background on how hand tracking works for people who are missing or unable to use one or more fingers on the hand(s) being used for hand tracking - how does this affect the data which is provided to the application?

As Rik said, https://github.com/immersive-web/webxr-hand-input/issues/11 covers this. At the moment this is entirely based on platform defaults: some platforms may emulate a finger, others may not detect it as a hand (unfortunate, but not something we can control here).

Currently all of the hand tracking platforms out there are all-or-nothing, AIUI, which means that they will always report all joints, and if some joints don't exist they'll either emulate them or refuse to surface a hand.

I want to make progress here, but I fear that doing so without having platforms that support it is putting the cart before the horse. A likely solution would be where you can use an XR feature descriptor to opt in to joints being missing as an indicator of "I can handle whatever configuration you throw at me". Polydactyl hands will also need a similar approach.

fordacious

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Should we rename the joints with simpler names, much like the unity example you listed?

I think that would be helpful to at least consider - naming the joints by number also makes it easier to understand the ordering without memorising or looking up the names of the bones each time (and also remembering that the joint comes before the named bone).

Actual code wouldn't use those structures. I think @Manishearth provided that to clarify how the mapping is done.

I see. Could we see some more realistic code examples somewhere?

The hands API is not involved in this. Each hand will also be a "controller" which has actions associated with it.

Can you expand on this? How would someone using hand input access the default action?

There is an issue on this. The spec currently defines that the hand will always returns all the joints.

Great issue, thank you!

fordacious

comment created time in a day

issue commentw3ctag/design-reviews

Review of NativeIO

I’ll try to reply to everything that has come up:

@torgo

  • Re: Other implementers, we’ve received feedback from people working on Firefox and Safari in the issues of the explainer, in particular #4, #9, and #12 and informally at TPAC. That being said, we haven’t yet met or discussed next steps.

  • Re: Bugs showing requested use cases, I don’t have publicly linked bugs at hand. The project was started before I joined, so I’m asking the people involved, I’ll update this issue once I have links to share. We have received direct positive feedback from partners, saying that NativeIO unblocked critical parts of their applications.

  • Re: Naming, we agree. We’ve been meaning to change the name soon, the current candidates are Direct Access Storage API (to highlight the performance and direct random access of the allowed by the API), and Storage Foundation API (to highlight the main use cases, where the API acts as a low level backend for more sophisticated libraries e.g. SQLite or a bespoke cache).

  • Re: Beyond WICG, we were thinking that it should be worked on WebAppsWG

@kenchris

  • Re: Similarities with File System Access API, we differ on goals and surface, although we’ve had some conversations on possibly merging some of the functionality offered by the Origin Private File System and NativeIO. From my understanding, File System Access API was added to allow more powerful access to files stored in the client, with the Origin Private File System acting as helper for testing and allowing the writing of data before prompting for permission. NativeIO acts as a more traditional storage API, with data being bound to the origin and not necessarily accessible to applications in the host. The difference in interface (like File System Access API relying on Streams, while NativeIO using buffers) and assurances (like File System Access API requiring SafeBrowsing checks and creating file copies before writing to them) are usually in the service of performance and genericity. We are currently benchmarking and prototyping to see if it’s possible to merge parts of the APIs, with the main risk being that trying to cover many diverse needs, we won’t meet the requirements that make NativeIO useful.

@cynthia

  1. We hadn’t considered sharing files between origins, it hasn’t come up in our dev trial yet. I agree it would be interesting, I’ll look into what changes would have to be made and update this issue.

  2. Indeed, since we see NativeIO purely as a storage API, we haven’t added ways to interact with the OS. I think that may be covered by the File System Access API, so detailing the interaction between the two APIs might be useful. Generally exploring and documenting the interaction between NativeIO and other storage APIs was on our list, so we’ll eventually add it to the explainer.

  3. The proposals are not directly related, but we expect that NativeIO would support buckets when they ship. It would probably mean that developers could specify to which bucket a file belongs to. We also talked about relying on buckets to mark files as temporary or ephemeral, but we haven’t really explored much of that.

  4. Yes, “ephemeral” files have come up on partner feedback. We’ve internally discussed a proposal to add a flag to the open method that allows marking a file as “deleteOnClose”, which would work for new and existing files. I’ll update the explainer as soon as the details of the design are hammered out. As for immutability, we haven’t discussed it so far. I could see how it might be useful if files can be shared between origins, but right now an origin has to create all the data within NativeIO by themselves. Is there a particular use case that you have in mind?

Thank you all for the feedback and help!

fivedots

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Regarding naming: I see that the Unity hand tracking API, for example, doesn't use the medical names for bones. They use a number to indicate the joint number.

I agree that the current names are not easily understood, even by native English speakers. Should we rename the joints with simpler names, much like the unity example you listed?

Each of your examples sets up a structure like: ... ... would it work to have the API expose the hand data via a richer data structure?

Actual code wouldn't use those structures. I think @Manishearth provided that to clarify how the mapping is done.

I'm also trying to understand the relationship between hand as a member of XRInputSource, and the primary action concept. Does hand input provide a way of generating a primary action?

The hands API is not involved in this. Each hand will also be a "controller" which has actions associated with it.

Also, can you give some background on how hand tracking works for people who are missing or unable to use one or more fingers on the hand(s) being used for hand tracking - how does this affect the data which is provided to the application?

There is an issue on this. The spec currently defines that the hand will always returns all the joints.

Finally, maybe a silly question - if an application wanted to track both hands, would that be two separate InputSources?

Yes :-)

fordacious

comment created time in a day

startedantontarasenko/awesome-economics

started time in a day

issue commentw3ctag/design-reviews

Require embedees to opt-in.

Thanks, @lknik! Reaching the long tail of sites is, indeed, important. I hope we'll be able to do so effectively via mechanisms like blog posts and tooling (devtools, lighthouse/observatory, deprecation reports, securityheaders.io and similar, etc). I don't think marking sites as unsafe because they embedded a page that didn't opt-in will be terribly effective, as the warning would seem to accrue to the wrong entity (embedder rather than embedee), but I'm open to additional ideas!

mikewest

comment created time in a day

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

An issue that may be of interest to the TAG, as it concerns design guidelines for modern APIs: https://github.com/immersive-web/webxr-hand-input/issues/70

fordacious

comment created time in a day

issue commentw3c/clipboard-apis

Spec readiness and compat

cc @rniwa @plehegar @foolip @rbyers

evilpie

comment created time in 2 days

issue commentw3c/clipboard-apis

What does ClipboardItem.getType do

It seems the constructor is basically not defined? 😟

mkruisselbrink

comment created time in 2 days

issue openedw3c/clipboard-apis

Spec readiness and compat

I started working on an implementation of ClipboardItem and clipboard.write using that in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1619947

I don't think the current spec can be implemented without either reverse-engineering other browser or just guessing.

  • Especially ClipboardItem is missing descriptions of all its methods and properties. Some behavior can not just be inferred by name.

    • What is createDelayed? It's not implemented by Chrome
    • How to handle DOMString in ClipboardItemDataType. The rest of the spec only seems to handle Blob.
    • Chrome only supports the types property. Safari seems to support presentationStyle as well.
    • I am especially concerned about the missing Promise support for ClipboardItemData in Chrome.
  • The spec doesn't really define which MIME types should be supported for write. Chrome only supports a handful.

Sorry I can't easily test Safari, but looking at their IDL definition they also only implement a subset of this spec.

created time in 2 days

startedmonologg/ner-sample

started time in 2 days

issue commentw3c/clipboard-apis

What does ClipboardItem.getType do

I am implementing the clipboard API in Firefox and this and other issues makes everything guess work. ClipboardItemDataType is defined as (DOMString or Blob), but getType just returns a Blob. How does that work? Is there a Blob created internally?

mkruisselbrink

comment created time in 2 days

startedmatthen/dstc

started time in 2 days

issue commentw3ctag/design-reviews

WebXR Hand Input API Specification

Regarding naming: I see that the Unity hand tracking API, for example, doesn't use the medical names for bones. They use a number to indicate the joint number.

The TAG design principles doc notes:

API naming must be done in easily readable US English. Keep in mind that most web developers aren’t native English speakers. Whenever possible, names should be chosen that use common vocabulary a majority of English speakers are likely to understand when first encountering the name.

and also:

You will probably not be able to directly translate an API available to native applications to be a web API.

Instead, consider the functionality available from the native API, and the user needs it addresses, and design an API which meets those user needs, even if the implementation depends on the existing native API.

I don't think using the bone name reduces the ambiguity either, since you're referring to a joint rather than the bone in any case.

Each of your examples sets up a structure like:

[ [XRHand.INDEX_PHALANX_TIP, XRHand.INDEX_METACARPAL],
  [XRHand.MIDDLE_PHALANX_TIP, XRHand.MIDDLE_METACARPAL],
  [XRHand.RING_PHALANX_TIP, XRHand.RING_METACARPAL],
  [XRHand.LITTLE_PHALANX_TIP, XRHand.LITTLE_METACARPAL] ]

... would it work to have the API expose the hand data via a richer data structure?

Regarding privacy: the strategy @cabanier mentions seems like a good start.

I'm also trying to understand the relationship between hand as a member of XRInputSource, and the primary action concept. Does hand input provide a way of generating a primary action?

Also, can you give some background on how hand tracking works for people who are missing or unable to use one or more fingers on the hand(s) being used for hand tracking - how does this affect the data which is provided to the application?

Finally, maybe a silly question - if an application wanted to track both hands, would that be two separate InputSources?

fordacious

comment created time in 2 days

more