You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sorting tracks alphabetically is underspecified #1772
I am not a Unicode expert but I think sorting by codepoint is wrong. The
Unicode spec defines a default collation algorithm for sorting (
http://unicode.org/reports/tr10/) that would seem a better choice.
But it seems JS sorts strings by codepoint as well, so maybe that's best.
The problem with codepoints is that the mapping between visual glypths and
codepoints is not unique. I guess that's not out problem to solve here.
Note that there was further discussion of this issue by I18n WG on their github. Note that they suggest not doing casefolding (not even ASCII-only casefolding) which then makes this super simple.
We should put w3c/i18n-activity#598 (comment) in the spec. I think the current prose is not what implementations are doing, and that's a mistake in the spec.
Teleconf: Remove "lexicographic". But still require sorting by code units because that's how Javascript sorts strings. (Code points and code units are different.)
@aphillips yes, these are opaque IDs for individual tracks, and are not presented to the user. The intent is simply that implementations all have a consistent track ordering. The term code unit is not an error and is due to the fact that Javascript stores strings in UTF-16 and indexes by code unit not code point, so non-BMP characters take two units.
The choice of sorting on code points or code units depends on what one wants to do with the resulting list or array of items. Because this is a list of opaque IDs and the goal is a fast deterministic sort, it makes all kinds of sense to do code unit sorting. The change looks good to me.
@svgeesus Please don't remove our label. While the title seems kind of "active" (suggesting the issue isn't resolved), it's actually how we track where our issues are--we don't have an "i18n-resolved" label or such to keep the label clutter down. You are more than welcome to close this issue once you're done with it.
Just note: W3C i18n WG closed our tracker with actions taken satisfactory. (please not remove i18n-needs-resolution label which is used by our bot and tracking system)
Activity
[-]Sorting nodes alphabetically is underspecified[/-][+]Sorting tracks alphabetically is underspecified[/+]padenot commentedon Nov 7, 2018
Let's order by code point. It's not that important, it just needs to be a stable sort.
rtoy commentedon Nov 7, 2018
svgeesus commentedon Nov 29, 2018
I agree it just needs to be
a) stable
b) defined
code point is easy, fast, and meets the needs.
svgeesus commentedon Jan 9, 2019
Note that there was further discussion of this issue by I18n WG on their github. Note that they suggest not doing casefolding (not even ASCII-only casefolding) which then makes this super simple.
Define which track to use in MediaStreamAudioSourceNode more clearly.
Define which track to use in MediaStreamAudioSourceNode more clearly.
7 remaining items
padenot commentedon Mar 19, 2020
We should put w3c/i18n-activity#598 (comment) in the spec. I think the current prose is not what implementations are doing, and that's a mistake in the spec.
rtoy commentedon Mar 19, 2020
Chrome sorts by code units because that's how Javascript sorts strings.
But I agree with everything else in that comment.
rtoy commentedon Mar 26, 2020
Teleconf: Remove "lexicographic". But still require sorting by code units because that's how Javascript sorts strings. (Code points and code units are different.)
svgeesus commentedon Apr 9, 2020
@aphillips yes, these are opaque IDs for individual tracks, and are not presented to the user. The intent is simply that implementations all have a consistent track ordering. The term
code unitis not an error and is due to the fact that Javascript stores strings in UTF-16 and indexes by code unit not code point, so non-BMP characters take two units.Fix WebAudio#1772: Sort tracks by code units
aphillips commentedon Apr 10, 2020
The choice of sorting on code points or code units depends on what one wants to do with the resulting list or array of items. Because this is a list of opaque IDs and the goal is a fast deterministic sort, it makes all kinds of sense to do code unit sorting. The change looks good to me.
aphillips commentedon Apr 10, 2020
@svgeesus Please don't remove our label. While the title seems kind of "active" (suggesting the issue isn't resolved), it's actually how we track where our issues are--we don't have an "i18n-resolved" label or such to keep the label clutter down. You are more than welcome to close this issue once you're done with it.
svgeesus commentedon Apr 30, 2020
@aphillips aha, sorry! Understood.
svgeesus commentedon Apr 30, 2020
@rtoy we could remove the v1Blocker though, I think.
rtoy commentedon Apr 30, 2020
When the issue is closed, I don't think it's necessary. Might be handy if we ever need to look at closed issues to see which were blockers.
himorin commentedon Jan 29, 2021
Just note: W3C i18n WG closed our tracker with actions taken satisfactory. (please not remove i18n-needs-resolution label which is used by our bot and tracking system)
Fix WebAudio#1772: Sort tracks by code units (WebAudio#2189)