In the HTML: `<h1>Hello</h1>`.
In the CSS: `h1 { text-transform: uppercase; }`.
Select the H1 and copy. On the 📋 clipboard:
Chrome: HELLO
Safari: HELLO
Firefox: Hello
@aardrian is on this since 2012 (https://adrianroselli.com/2012/06/copying-content-styled-with-text.html). I just filed a Chrome bug (https://crbug.com/1429183) after the WebKit bug by @mathias from 2010 (https://bugs.webkit.org/show_bug.cgi?id=43202).
@tomayac @aardrian @mathias The spec only requires this for plain text paste, not any other format, so you may or may not have seen a spec violation depending on how and where you pasted.
That said, I think this spec requirement for plain text paste is bad UX and should be changed in the spec. Users expect that when they copy/paste, they get the same characters. They have no way of knowing which capitalization is stylistic vs part of the content.
@othermaciej @tomayac @aardrian @mathias See step 3) of the bug I’ve filed:
3) Paste it in the URL bar (or any other plaintext input).
When the original WebKit bug was filed, the spec didn’t mandate anything. Now it does. Personally, I like the behavior it enforces, but I can definitely see others’ points, too.
@tomayac @aardrian @mathias I was responding to your Mastodon post, which just said “Select the H1 and copy. On the 📋 clipboard:”, nothing about where it’s pasted.
Nitpick: for a valid test in Firefox you have to use inline style, due to the (apparent) bug where they don’t put style from non-inline style on the clipboard at all, not even in HTML format or in properties. With inline styles, they do the thing you want for plaintext but not rich text paste, which is what the spec asks for.
@othermaciej @aardrian @mathias Fair, the toot is imprecise. Ironically, I can’t edit it now, because Mastodon thinks it’s 260 characters too long already without any editing.
¯\_(ツ)_/¯
Thanks for the additional details on the Firefox behavior.
@othermaciej @tomayac @aardrian @mathias
I’d agree with your point if the implementation is coherent, but “Paste and Match Style” does nothing to the uppercase styles, unlike the rest of them, like color, weight, underline, etc.
@tomayac @aardrian @mathias Hmm, I think Firefox behavior may be partially a bug. Firefox will copy this as all uppercase to rich text contexts but sentence case plaintext: `<h1 style="text-transform: uppercase">Hello<h1>`. But the original example it copies as mixed-case always. So it's following the spec rule for plaintext, but additionally has a bug where it won't copy styles that come from style rules, even when pasting into an editable HTML context like a macOS Mail compose window. Firefox likewise copies `color: red` when it comes from inline style but not when it comes from an external style rule.