Please unassign me from this task (why can't I do it myself?). My patch was rejected.

My patch seems to be stuck. Oh well.

In T7897#108576, @epriestley wrote:

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

We can avoid all the issues with "order" parameter by using an entire
separate setting like `'maniphest.statuses.order' => ['open', 'resolved',
'declined']`, and indeed falling back to object order. If the set of
values specified in it would not match the set of keys of
maniphest.statuses, it could just be ignored.

While I am definitely not a fan of these, I must commend you for the least bad implementation of custom scrollbars I have seen so far. :)

It already implies display: inline in CSS, but as I have explained on the task that is not sufficient. Browser's HTML parser doesn't care what CSS rules will be applied, it only deals with the meanings of tags, and <p/> is specified as not being allowed to have a <div/> inside it. This is the same kind of thing as if you tried to nest <a/> tags, it's just not possible.

Screenshot from description for posterity:

Any feedback?

It would be a lot simpler to use HTML 5 File API together with a regular <input type=file /> field. This won't help the IE8s of the world, but will help users of non-standard, but modern operating systems and browsers.

Thanks!

bin/celerity map

Am I expected to include the result of running bin/celerity map in the diff? That feels like something that should be done automatically on merge, since it would cause tons of merge conflicts otherwise, but I see it in some commits in Git.

Note the lack of double spacing and the glorious even margins.

Meh.

I want the strings to collate as the user expects strings in their language to collate, even if the strings are not actually written in their language. This will produce the best result if the strings are written in their language, and a reasonable (consistent with expectations) result if the strings are written in some other language or a mixture of languages.

In T6616#85112, @epriestley wrote:

Assuming locale compares work in a reasonable way, it seems like they should be more correct.

For example, as an English speaker, I expect strings to sort from "a -> z". Even if I'm viewing Australian strings on an Australian install, it's still better for me as a user to see an "a -> z" sort than an Australian "z -> a" sort of the strings, because it's one I'm more familiar with.

I do get a better result for localeCompare() than for < with Ł, in English: localeCompare() correctly puts it between "L" and "M". This is where I'd expect it to appear as an English speaker, and presumably a Polish speaker searching on an English-language install would still prefer a colleague named "Stanisław" to sort between "Staniskaw" and "Stanismaw", not after "Staniszaw".

I tried submitting a patch and it seems to have worked, so I guess I could "claim" this…?

I debugged this in browser console, so no idea where this code comes from in the source, but lines that needs changing look like: