| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
modification.
This also avoids using `placeholder` on elements where it's nonstandard, like `<div>`s.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is purely an aesthetic choice:
* The DOM `reset()` function can be used to clear the form, but can't be used to clear editable DIVs. Binding the editable div to a (hidden) form field allows `reset()` to clear both.
* We can find the target `form` element out of the event, but the API needed to do so differs between events dispatched to form controls and events dispatched to random DOM nodes. Using `closest('form')` works for both kinds of event target.
In practice, there is little need to make sure the message input form uses "normal" DOM APIs for functional reasons. Everything inside `MessageInput` is controllable through the component's script. This change isn't based on a functional need, but rather in the hopes that integrating with the DOM APIs makes it easier for _code we don't control_ - screen readers, password managers, saved-form support in browsers, &c - to integrate with Pilcrow. It is purely speculative.
(This also used to be necessary because Firefox didn't support `contenteditable="plaintext-only"`, but [support was added in March][ff-pto]
[ff-pto]: https://www.mozilla.org/en-US/firefox/136.0/releasenotes/#:~:text=The%20value%20plaintext%2Donly%20can%20now%20be%20specified%20for%20the%20contenteditable%20attribute%2C%20making%20the%20raw%20text%20of%20an%20element%20editable%20but%20without%20supporting%20rich%20text%20formatting.
|
| |
|
|
|
| |
* Suppress input (including paste) while the input is disabled.
* Style the input to make it visible that it's not accepting input.
|
| |
|
|
|
|
| |
It's not much, but it makes it a bit easier to see that the placeholder text _is_ a placeholder.
Not sure what to do about it vanishing permanently once the element is edited, until the element is formally `reset()`, though.
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a subtle race conditon in this code, which is likely not fixable without a protocol change:
* Ghost messages can disappear before their "real" message replacement shows up, if the client finishes sending (i.e., receives an HTTP response on the POST) before the server delivers the real message.
* Ghost messages can be duplicated briefly, if the client receives the real message before the client finishes sending.
Both happen in practice; we make no ordering guarantees between requests.
To aviod this, we'd to give clients a way to correlate pending sends with received messages. This would require fundamentally the same capabilities, like per-operation nonces, that preventing duplicate operations will require.
|
| | |
| |
| |
| | |
Using a wildcard selector here makes this rule surprisingly hard to override, which will be a problem for styling unsent messages.
|
| |/
|
|
|
|
| |
This was causing problems with message colouring, as these rules had specificity similar to constructs like `.message.deleted`.
This approach removes their browser default styles, then adds styling specific to the channel sidebar, the app bar, and the message view.
|
| |
|
|
|
|
|
|
| |
contrast.
We were ending up with colours picked by a more specific rule (`a, a:hover, a:visited, a:active`, from `app.css`), which was suppressing the colours we wanted. This is not a particularly elegant solution, but it is _an_ solution.
Code organized this way to avoid giving `a` elements a background colour.
|
| |
|
|
| |
Browsers cope with weird nestings mostly fine, but there's no upside for us in testing that.
|
| |
|
|
|
|
| |
According to <https://stackoverflow.com/a/6803278>, this was needed for old versions of Safari. However, since at least 2022, Safari has supported `content: none` just fine.
Related Safari bug (still open as of this writing, comments relevnat): <https://bugs.webkit.org/show_bug.cgi?id=20032>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Let's try this.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The rounded corners on an iPhone shouldn't be cut off now.
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
out overlapping with the main area
|
| | |
| |
| |
| | |
own/other messages.
|
| | | |
|
| | |
| |
| |
| | |
some visually-displeasing shapes and gaps near the bottom of the app.
|
| |/
|
|
|
| |
We're not using Overlock currently, but I think it'll be good on headers
and stuff?
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
