| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
This styling suggestion c/o Jessamyn Smith! Thanks, Jess. I like it.
|
| |
|
|
| |
This prevents the need to go and un-apply unwanted styles when considering code blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For reasons known only to the author, marked emits code blocks as
<pre><code>your code here</code></pre>
Inline code, on the other hand, is emitted as
<p>Non-code text <code>code text</code> non-code text.</p>
In d15bfb2b9a4872cba99bc966fe5c9c4399b3323c, we added a rule to give inline code nicer leading and trailing space, so that the borders don't directly abut the letters. However, we neglected to consider code blocks; the padding added for inline code also affected their first line, pushing it in slightly. This removes the padding from `<code>` when it is a direct child of a `<pre>`, as per the markup emitted by marked.
|
| |
|
|
|
|
| |
This is a fairly simple approach using a linearly-reducing scale (from 2.25 down to 1.0) to adjust both the font size and the line height. All headings are bold, and are in the body typeface.
People who actually use headings in _chat messages_ are doing a bit, but hey, bits are valid.
|
| | |
|
| |
|
|
| |
There isn't a good way to target "any <code> not inside a <pre>" so we do a little reverse logic here, as a treat.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our reset strips out a ton of default browser styles, which is good, but we haven't yet gotten around to adding styles we're using. This left formatted messages
feeling a
lot like
this
regardless of the intended formatting. (Is the above an example of a paragraph? A list? A single line that has gotten wrapped? The answer was "yes.")
To make the margins and padding work out nicely, I've rearranged the positioning containers used for message runs and messages. We also no longer `float` the message handles, since we no longer need to: they can be positioned relative to the message they're part of.
Styling on long bodies of inline code (`like this`) is a bit shaky. The outline overlaps with the following line. I think having a visual cue for where the code block begins and ends is _good_, but I'd like to pick apart some of the other examples on the internet because I think this needs more work.
This change also makes code blocks wrap lines at the page edge where possible (it'll still scroll if wrapping isn't possible). This won't affect _most_ code blocks much - code tends to not be that wide - and it means that using a code block for effect doesn't require people to manually wrap strings. Having tried it both ways, this feels more human.
Dumbnailing is not a _great_ solution to dealing with huge images, but it's the best we can do at rendering time. A more complete solution would require generating images at multiple sizes.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The rounded corners on an iPhone shouldn't be cut off now.
|
| |\ |
|
| | |
| |
| |
| | |
own/other messages.
|
| | | |
|
| |/
|
|
|
| |
We're not using Overlock currently, but I think it'll be good on headers
and stuff?
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
