Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Nils Dagsson Moskopp]

David Sheets  writes:

> On Sun, Feb 15, 2015 at 3:16 AM, Glenn Maynard  wrote:
>> On Sat, Feb 14, 2015 at 12:34 PM, David Sheets  wrote:
>>>
>>> I am writing a documentation generation tool for a programming
>>> language with right arrows represented as -> but would like to render
>>> them as →. Programmers are used to writing in ASCII and reading
>>> typeset mathematics. If I present documentation to them via a
>>> purpose-built document browser, I should give them the option (at the
>>> generation/styling stage) of making those documents as pleasing as
>>> possible.
>>
>>
>> Programmers a decade or two ago, maybe, but not today.
>>
>> As a programmer, if I see "→" on a page, select it and copy it, I expect to
>> copy "→", just as I selected.  This sounds like something browsers should
>> actively discourage.
>
> If you're reading documentation which includes types, it's nice to see
> implication arrows but copy valid syntax.

If you are reading documentation, it is nice to see valid syntax. What
if the user is typing the documentation? I can type “→” easily by using
a compose key and would be confused if it does not work in the language.

> Programming communities which use types or other formal methods
> commonly typeset their own documents with mathematical notation. For
> practical reasons, they define their language representations using
> ASCII.
>
> If you have nothing more useful to discuss beyond uninformed,
> opinionated naysaying, I'll be leaving this thread lie.

I find that last paragraph entirely superfluous.


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Glenn Maynard]

On Sun, Feb 15, 2015 at 4:40 AM, David Sheets  wrote:

> If you're reading documentation which includes types, it's nice to see
> implication arrows but copy valid syntax.
>

This is rather vague, but it sounds along the lines of using "→" for
pointer dereferencing in a C++ document, which sounds pretty strange and
unconventional.

There's so much rampant abuse of the user's clipboard (most notably people
inserting ads into the user's clipboard when he tries to copy text) that
whenever a feature allows a page to cause copies to grab text other than
what the user specified, we should be looking carefully at the use cases.

If you have nothing more useful to discuss beyond uninformed,
> opinionated naysaying, I'll be leaving this thread lie.
>

You should make an effort to remain civil when people don't immediately
agree with you.

-- 
Glenn Maynard

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Sun, Feb 15, 2015 at 3:16 AM, Glenn Maynard  wrote:
> On Sat, Feb 14, 2015 at 12:34 PM, David Sheets  wrote:
>>
>> I am writing a documentation generation tool for a programming
>> language with right arrows represented as -> but would like to render
>> them as →. Programmers are used to writing in ASCII and reading
>> typeset mathematics. If I present documentation to them via a
>> purpose-built document browser, I should give them the option (at the
>> generation/styling stage) of making those documents as pleasing as
>> possible.
>
>
> Programmers a decade or two ago, maybe, but not today.
>
> As a programmer, if I see "→" on a page, select it and copy it, I expect to
> copy "→", just as I selected.  This sounds like something browsers should
> actively discourage.

If you're reading documentation which includes types, it's nice to see
implication arrows but copy valid syntax.

Programming communities which use types or other formal methods
commonly typeset their own documents with mathematical notation. For
practical reasons, they define their language representations using
ASCII.

If you have nothing more useful to discuss beyond uninformed,
opinionated naysaying, I'll be leaving this thread lie.

> --
> Glenn Maynard
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Glenn Maynard]

On Sat, Feb 14, 2015 at 12:34 PM, David Sheets  wrote:

> I am writing a documentation generation tool for a programming
> language with right arrows represented as -> but would like to render
> them as →. Programmers are used to writing in ASCII and reading
> typeset mathematics. If I present documentation to them via a
> purpose-built document browser, I should give them the option (at the
> generation/styling stage) of making those documents as pleasing as
> possible.
>

Programmers a decade or two ago, maybe, but not today.

As a programmer, if I see "→" on a page, select it and copy it, I expect to
copy "→", just as I selected.  This sounds like something browsers should
actively discourage.

-- 
Glenn Maynard

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 11:11 PM, Glenn Maynard  wrote:
> On Fri, Feb 13, 2015 at 9:02 AM, Glenn Maynard  wrote:
>>
>> Copying ASCII isn't desirable.  It should copy the Unicode string "a → b".
>> After all, that's what gets copied if you had done "a → b" in
>> the first place.
>
>
> (Oh, I missed the obvious--the "->" from Firefox is coming from the HTML, of
> course.)
>
> I guess what you're after is being able to have separate text for display
> vs. copy.  I'm sure you don't actually want to use a hacky custom font.
> What's the actual use case?  In general I think browsers should always copy
> just what the user selected, and not let pages cause something other than
> that to be copied, since things like that are generally abused (eg.
> inserting linkback ads to copied text).

I am writing a documentation generation tool for a programming
language with right arrows represented as -> but would like to render
them as →. Programmers are used to writing in ASCII and reading
typeset mathematics. If I present documentation to them via a
purpose-built document browser, I should give them the option (at the
generation/styling stage) of making those documents as pleasing as
possible.

A ligature font is the closest thing I've seen so far to being
"semantically accurate" and degrades gracefully.

It's not quite totally accurate as I already have a font and it
already has all the glyphs I'd like to use. In this way, the font is a
"level too low" at character rendering rather than glyph selection.
Fortunately, the surrounding font doesn't really matter so the
ligature font can be made to fit quite well. Unfortunately, I can
imagine much simpler expressions of the behavior I'm after that don't
involve talking about vectorized graphics and transmitting kilobytes
of typeface description.

I think the current behavior of CSS content not being copied makes
some sense. It is *stylistic* content after all... I'm a bit
disappointed that vendors can't seem to agree on what content is
"hidden" as Boris has said.

> --
> Glenn Maynard
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 10:23 PM, Ashley Gullen  wrote:
> Why is it desirable to copy ASCII versions of unicode text? Doesn't most
> software now support unicode so the user can copy and paste what they see,
> rather than some ASCII-art equivalent?

I am writing a documentation generation tool for a programming language
with right arrows represented as -> but would like to render them as →.

> On 13 February 2015 at 15:45, Boris Zbarsky  wrote:
>
>> On 2/13/15 10:15 AM, David Sheets wrote:
>>
>>> I suppose currently Chrome is preventing copying hidden content but
>>> Firefox is not and neither picks up the CSS content.
>>>
>>
>> Both prevent copying hidden content, but may not have identical
>> definitions of "hidden".
>>
>> Neither picks up CSS generated content, because both represent selections
>> in terms of DOM ranges, and DOM ranges can't represent CSS generated
>> content...
>>
>> -Boris
>>
>>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Glenn Maynard]

On Fri, Feb 13, 2015 at 9:02 AM, Glenn Maynard  wrote:

> Copying ASCII isn't desirable.  It should copy the Unicode string "a →
> b".  After all, that's what gets copied if you had done "a →
> b" in the first place.
>

(Oh, I missed the obvious--the "->" from Firefox is coming from the HTML,
of course.)

I guess what you're after is being able to have separate text for display
vs. copy.  I'm sure you don't actually want to use a hacky custom
font.  What's the actual use case?  In general I think browsers should
always copy just what the user selected, and not let pages cause something
other than that to be copied, since things like that are generally abused
(eg. inserting linkback ads to copied text).

-- 
Glenn Maynard

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Ashley Gullen]

Why is it desirable to copy ASCII versions of unicode text? Doesn't most
software now support unicode so the user can copy and paste what they see,
rather than some ASCII-art equivalent?

On 13 February 2015 at 15:45, Boris Zbarsky  wrote:

> On 2/13/15 10:15 AM, David Sheets wrote:
>
>> I suppose currently Chrome is preventing copying hidden content but
>> Firefox is not and neither picks up the CSS content.
>>
>
> Both prevent copying hidden content, but may not have identical
> definitions of "hidden".
>
> Neither picks up CSS generated content, because both represent selections
> in terms of DOM ranges, and DOM ranges can't represent CSS generated
> content...
>
> -Boris
>
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Boris Zbarsky]

On 2/13/15 10:15 AM, David Sheets wrote:

I suppose currently Chrome is preventing copying hidden content but
Firefox is not and neither picks up the CSS content.


Both prevent copying hidden content, but may not have identical 
definitions of "hidden".


Neither picks up CSS generated content, because both represent 
selections in terms of DOM ranges, and DOM ranges can't represent CSS 
generated content...


-Boris

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 3:02 PM, Glenn Maynard  wrote:
> On Fri, Feb 13, 2015 at 5:45 AM, David Sheets  wrote:
>>
>> Hello,
>>
>> I have a page with
>>
>> a -> b
>>
>> and style
>>
>> .rarr span { overflow: hidden; height: 0; width: 0; display: inline-block;
>> }
>> .rarr::after { content: "→"; }
>>
>> (That's RIGHTWARDS ARROW x2192.)
>>
>> In Firefox 36, this copies and pastes like "a -> b" which is the
>> desired behavior. In Chrome 40, this copies and pastes like "a  b".
>>
>> Is my desired behavior (to show unicode but copy an ASCII
>> representation) generally possible? Are there specs somewhere about
>> copy/paste behavior? I looked in  but
>> found nothing relevant.
>
>
> Copying ASCII isn't desirable.  It should copy the Unicode string "a → b".
> After all, that's what gets copied if you had done "a → b" in
> the first place.
>
> (Chrome's issue isn't related to Unicode.  It just doesn't know how to
> select text that's inside CSS content, so it isn't included in the copy.)

The only relation this issue has to Unicode is a use case for
alternate copy/paste behavior.

Judging from the replies to my original inquiry, either Firefox or
Chrome is doing something unexpected or both are behaving unexpectedly
(and should put the unicode arrow on the clipboard).

I'm not sure if all use cases for my original trick can be covered by
using OpenType ligatures (thanks, Nils!) or if there are other
'alternative clipboard behavior' applications. Certainly, the most
consistent behavior would be for both Chrome and Firefox (and other
browsers that I haven't/don't care to test) to put the CSS content on
the clipboard and ignore hidden content.

I suppose currently Chrome is preventing copying hidden content but
Firefox is not and neither picks up the CSS content.

David

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 1:08 PM, Nils Dagsson Moskopp
 wrote:
> David Sheets  writes:
>
>> On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
>>  wrote:
>>> In this case, you can use Unicode escape values by preceding them with a
>>> slash:
>>>
>>>   .rarr:after { content: "\2192"; }
>>>
>>>
>>> This is specified in the CSS 2.1 spec:
>>> http://www.w3.org/TR/CSS2/syndata.html#characters
>>>
>>> Personally, I probably would've just started on StackOverflow with this
>>> question (e.g. [1]) but no harm done.
>>
>> Hi James!
>>
>> Sorry, I wasn't clear. The issue is not with putting Unicode values
>> into CSS. The issue is that I would like unicode values to be copied
>> and pasted as a specific ASCII fallback value.
>>
>> That is, I would like the equivalent of "a → b" to appear on a
>> page but, upon copying, "a -> b" to show up in the clipboard.
>>
>> I have a solution that works in Firefox 36 (described in original
>> mail). Chrome 40 does not behave similarly.
>>
>> I can see some arguments for Chrome's behavior along security lines. I
>> certainly can understand the utility of Firefox's behavior because I
>> am writing a documentation generation tool for a programming language
>> with right arrows represented as -> but would like to render them as
>> →.
>
> I would suggest to use OpenType ligatures for that. You could reasonably
> create a ligature font that renders any occurence of “->” as “→”.

This is a really brilliant solution that satisfies my use case
perfectly. I created the following (horrible) font that works as
expected.



The browser inconsistency in the original case still stands, though.
Is there a spec covering copy and paste?

David

> --
> Nils Dagsson Moskopp // erlehmann
> 

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Glenn Maynard]

On Fri, Feb 13, 2015 at 5:45 AM, David Sheets  wrote:

> Hello,
>
> I have a page with
>
> a -> b
>
> and style
>
> .rarr span { overflow: hidden; height: 0; width: 0; display: inline-block;
> }
> .rarr::after { content: "→"; }
>
> (That's RIGHTWARDS ARROW x2192.)
>
> In Firefox 36, this copies and pastes like "a -> b" which is the
> desired behavior. In Chrome 40, this copies and pastes like "a  b".
>
> Is my desired behavior (to show unicode but copy an ASCII
> representation) generally possible? Are there specs somewhere about
> copy/paste behavior? I looked in  but
> found nothing relevant.
>

Copying ASCII isn't desirable.  It should copy the Unicode string "a → b".
After all, that's what gets copied if you had done "a → b" in
the first place.

(Chrome's issue isn't related to Unicode.  It just doesn't know how to
select text that's inside CSS content, so it isn't included in the copy.)

-- 
Glenn Maynard

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Nils Dagsson Moskopp]

David Sheets  writes:

> On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
>  wrote:
>> In this case, you can use Unicode escape values by preceding them with a
>> slash:
>>
>>   .rarr:after { content: "\2192"; }
>>
>>
>> This is specified in the CSS 2.1 spec:
>> http://www.w3.org/TR/CSS2/syndata.html#characters
>>
>> Personally, I probably would've just started on StackOverflow with this
>> question (e.g. [1]) but no harm done.
>
> Hi James!
>
> Sorry, I wasn't clear. The issue is not with putting Unicode values
> into CSS. The issue is that I would like unicode values to be copied
> and pasted as a specific ASCII fallback value.
>
> That is, I would like the equivalent of "a → b" to appear on a
> page but, upon copying, "a -> b" to show up in the clipboard.
>
> I have a solution that works in Firefox 36 (described in original
> mail). Chrome 40 does not behave similarly.
>
> I can see some arguments for Chrome's behavior along security lines. I
> certainly can understand the utility of Firefox's behavior because I
> am writing a documentation generation tool for a programming language
> with right arrows represented as -> but would like to render them as
> →.

I would suggest to use OpenType ligatures for that. You could reasonably
create a ligature font that renders any occurence of “->” as “→”.

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Nils Dagsson Moskopp]

David Sheets  writes:

> On Fri, Feb 13, 2015 at 12:23 PM, Mathias Bynens  wrote:
>> On Fri, Feb 13, 2015 at 1:18 PM, James M. Greene
>>  wrote:
>>> In this case, you can use Unicode escape values by preceding them with a
>>> slash:
>>
>> OP’s question wasn’t about how to escape non-ASCII characters, but
>> rather about what the copy/paste behavior should be in browsers.
>>
>> @David, I don’t think it’s reasonable to expect non-ASCII characters
>> to be transliterated to ASCII characters copying them. That said, it
>> would be nice to standardize on the behavior here: should generated
>> content be included when copying or not?
>
> Hi Mathias,
>
> Do you mean that it's not reasonable for transliteration to happen
> automatically? I agree.

What do you mean with “not reasonable” ? I once noticed that where
elinks does show “ベルントとウンターアルターバッハの謎”, links shows
“BeRuN6TotoU6N6Ta-6A6RuTa-6BaTUHano***”. Now while I cannot read any
japanese, I wonder if this transliteration seems unreasonable to you.

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[James M. Greene]

To expand on my own comment:

> Personally, I would expect and desire the CSS-generated content to be
copied.

...because THAT is what the user sees, per the browser rendering. I'm
surprised that neither Firefox nor Chrome exhibits that behavior.

Sincerely,
   James M. Greene
On Feb 13, 2015 6:30 AM, "James M. Greene"  wrote:

> Sorry, David & Mathias. Hasty 6:00am reply here before my brain and eyes
> fully woke up!
>
> Interesting question. Personally, I would expect and desire the
> CSS-generated content to be copied.
>
> Sincerely,
>James M. Greene
> On Feb 13, 2015 6:24 AM, "David Sheets"  wrote:
>
>> On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
>>  wrote:
>> > In this case, you can use Unicode escape values by preceding them with a
>> > slash:
>> >
>> >   .rarr:after { content: "\2192"; }
>> >
>> >
>> > This is specified in the CSS 2.1 spec:
>> > http://www.w3.org/TR/CSS2/syndata.html#characters
>> >
>> > Personally, I probably would've just started on StackOverflow with this
>> > question (e.g. [1]) but no harm done.
>>
>> Hi James!
>>
>> Sorry, I wasn't clear. The issue is not with putting Unicode values
>> into CSS. The issue is that I would like unicode values to be copied
>> and pasted as a specific ASCII fallback value.
>>
>> That is, I would like the equivalent of "a → b" to appear on a
>> page but, upon copying, "a -> b" to show up in the clipboard.
>>
>> I have a solution that works in Firefox 36 (described in original
>> mail). Chrome 40 does not behave similarly.
>>
>> I can see some arguments for Chrome's behavior along security lines. I
>> certainly can understand the utility of Firefox's behavior because I
>> am writing a documentation generation tool for a programming language
>> with right arrows represented as -> but would like to render them as
>> →.
>>
>> This seems like a pretty straightforward document feature but I can't
>> seem to get interoperable behavior (or even find where such behavior
>> might be specified).
>>
>> Thanks,
>>
>> David
>>
>> >
>> > [1]:
>> >
>> http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
>> >
>> > Sincerely,
>> > James Greene
>> >
>> >
>> > On Fri, Feb 13, 2015 at 5:45 AM, David Sheets 
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have a page with
>> >>
>> >> a -> b
>> >>
>> >> and style
>> >>
>> >> .rarr span { overflow: hidden; height: 0; width: 0; display:
>> inline-block;
>> >> }
>> >> .rarr::after { content: "→"; }
>> >>
>> >> (That's RIGHTWARDS ARROW x2192.)
>> >>
>> >> In Firefox 36, this copies and pastes like "a -> b" which is the
>> >> desired behavior. In Chrome 40, this copies and pastes like "a  b".
>> >>
>> >> Is my desired behavior (to show unicode but copy an ASCII
>> >> representation) generally possible? Are there specs somewhere about
>> >> copy/paste behavior? I looked in  but
>> >> found nothing relevant.
>> >>
>> >> Is this the right venue for this question? Should I take it somewhere
>> >> else?
>> >>
>> >> Thanks,
>> >>
>> >> David Sheets
>> >
>> >
>>
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[James M. Greene]

Sorry, David & Mathias. Hasty 6:00am reply here before my brain and eyes
fully woke up!

Interesting question. Personally, I would expect and desire the
CSS-generated content to be copied.

Sincerely,
   James M. Greene
On Feb 13, 2015 6:24 AM, "David Sheets"  wrote:

> On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
>  wrote:
> > In this case, you can use Unicode escape values by preceding them with a
> > slash:
> >
> >   .rarr:after { content: "\2192"; }
> >
> >
> > This is specified in the CSS 2.1 spec:
> > http://www.w3.org/TR/CSS2/syndata.html#characters
> >
> > Personally, I probably would've just started on StackOverflow with this
> > question (e.g. [1]) but no harm done.
>
> Hi James!
>
> Sorry, I wasn't clear. The issue is not with putting Unicode values
> into CSS. The issue is that I would like unicode values to be copied
> and pasted as a specific ASCII fallback value.
>
> That is, I would like the equivalent of "a → b" to appear on a
> page but, upon copying, "a -> b" to show up in the clipboard.
>
> I have a solution that works in Firefox 36 (described in original
> mail). Chrome 40 does not behave similarly.
>
> I can see some arguments for Chrome's behavior along security lines. I
> certainly can understand the utility of Firefox's behavior because I
> am writing a documentation generation tool for a programming language
> with right arrows represented as -> but would like to render them as
> →.
>
> This seems like a pretty straightforward document feature but I can't
> seem to get interoperable behavior (or even find where such behavior
> might be specified).
>
> Thanks,
>
> David
>
> >
> > [1]:
> >
> http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
> >
> > Sincerely,
> > James Greene
> >
> >
> > On Fri, Feb 13, 2015 at 5:45 AM, David Sheets 
> wrote:
> >>
> >> Hello,
> >>
> >> I have a page with
> >>
> >> a -> b
> >>
> >> and style
> >>
> >> .rarr span { overflow: hidden; height: 0; width: 0; display:
> inline-block;
> >> }
> >> .rarr::after { content: "→"; }
> >>
> >> (That's RIGHTWARDS ARROW x2192.)
> >>
> >> In Firefox 36, this copies and pastes like "a -> b" which is the
> >> desired behavior. In Chrome 40, this copies and pastes like "a  b".
> >>
> >> Is my desired behavior (to show unicode but copy an ASCII
> >> representation) generally possible? Are there specs somewhere about
> >> copy/paste behavior? I looked in  but
> >> found nothing relevant.
> >>
> >> Is this the right venue for this question? Should I take it somewhere
> >> else?
> >>
> >> Thanks,
> >>
> >> David Sheets
> >
> >
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 12:23 PM, Mathias Bynens  wrote:
> On Fri, Feb 13, 2015 at 1:18 PM, James M. Greene
>  wrote:
>> In this case, you can use Unicode escape values by preceding them with a
>> slash:
>
> OP’s question wasn’t about how to escape non-ASCII characters, but
> rather about what the copy/paste behavior should be in browsers.
>
> @David, I don’t think it’s reasonable to expect non-ASCII characters
> to be transliterated to ASCII characters copying them. That said, it
> would be nice to standardize on the behavior here: should generated
> content be included when copying or not?

Hi Mathias,

Do you mean that it's not reasonable for transliteration to happen
automatically? I agree.

Do you mean that it's not reasonable to support specific replacements
during copying? Firefox seems to support this currently (and
perfectly).

There are user trickery concerns here but, at least in my case, I
think codepoint -> 2 byte replacement is probably safe...

Thanks,

David

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

On Fri, Feb 13, 2015 at 12:18 PM, James M. Greene
 wrote:
> In this case, you can use Unicode escape values by preceding them with a
> slash:
>
>   .rarr:after { content: "\2192"; }
>
>
> This is specified in the CSS 2.1 spec:
> http://www.w3.org/TR/CSS2/syndata.html#characters
>
> Personally, I probably would've just started on StackOverflow with this
> question (e.g. [1]) but no harm done.

Hi James!

Sorry, I wasn't clear. The issue is not with putting Unicode values
into CSS. The issue is that I would like unicode values to be copied
and pasted as a specific ASCII fallback value.

That is, I would like the equivalent of "a → b" to appear on a
page but, upon copying, "a -> b" to show up in the clipboard.

I have a solution that works in Firefox 36 (described in original
mail). Chrome 40 does not behave similarly.

I can see some arguments for Chrome's behavior along security lines. I
certainly can understand the utility of Firefox's behavior because I
am writing a documentation generation tool for a programming language
with right arrows represented as -> but would like to render them as
→.

This seems like a pretty straightforward document feature but I can't
seem to get interoperable behavior (or even find where such behavior
might be specified).

Thanks,

David

>
> [1]:
> http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value
>
> Sincerely,
> James Greene
>
>
> On Fri, Feb 13, 2015 at 5:45 AM, David Sheets  wrote:
>>
>> Hello,
>>
>> I have a page with
>>
>> a -> b
>>
>> and style
>>
>> .rarr span { overflow: hidden; height: 0; width: 0; display: inline-block;
>> }
>> .rarr::after { content: "→"; }
>>
>> (That's RIGHTWARDS ARROW x2192.)
>>
>> In Firefox 36, this copies and pastes like "a -> b" which is the
>> desired behavior. In Chrome 40, this copies and pastes like "a  b".
>>
>> Is my desired behavior (to show unicode but copy an ASCII
>> representation) generally possible? Are there specs somewhere about
>> copy/paste behavior? I looked in  but
>> found nothing relevant.
>>
>> Is this the right venue for this question? Should I take it somewhere
>> else?
>>
>> Thanks,
>>
>> David Sheets
>
>

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[Mathias Bynens]

On Fri, Feb 13, 2015 at 1:18 PM, James M. Greene
 wrote:
> In this case, you can use Unicode escape values by preceding them with a
> slash:

OP’s question wasn’t about how to escape non-ASCII characters, but
rather about what the copy/paste behavior should be in browsers.

@David, I don’t think it’s reasonable to expect non-ASCII characters
to be transliterated to ASCII characters copying them. That said, it
would be nice to standardize on the behavior here: should generated
content be included when copying or not?

Re: [whatwg] Unicode -> ASCII copy/paste fallback

[James M. Greene]

In this case, you can use Unicode escape values by preceding them with a
slash:

  .rarr:after { content: "\2192"; }


This is specified in the CSS 2.1 spec:
http://www.w3.org/TR/CSS2/syndata.html#characters

Personally, I probably would've just started on StackOverflow with this
question (e.g. [1]) but no harm done.


[1]:
http://stackoverflow.com/questions/10393462/placing-unicode-character-in-css-content-value

Sincerely,
James Greene


On Fri, Feb 13, 2015 at 5:45 AM, David Sheets  wrote:

> Hello,
>
> I have a page with
>
> a -> b
>
> and style
>
> .rarr span { overflow: hidden; height: 0; width: 0; display: inline-block;
> }
> .rarr::after { content: "→"; }
>
> (That's RIGHTWARDS ARROW x2192.)
>
> In Firefox 36, this copies and pastes like "a -> b" which is the
> desired behavior. In Chrome 40, this copies and pastes like "a  b".
>
> Is my desired behavior (to show unicode but copy an ASCII
> representation) generally possible? Are there specs somewhere about
> copy/paste behavior? I looked in  but
> found nothing relevant.
>
> Is this the right venue for this question? Should I take it somewhere else?
>
> Thanks,
>
> David Sheets
>

[whatwg] Unicode -> ASCII copy/paste fallback

[David Sheets]

Hello,

I have a page with

a -> b

and style

.rarr span { overflow: hidden; height: 0; width: 0; display: inline-block; }
.rarr::after { content: "→"; }

(That's RIGHTWARDS ARROW x2192.)

In Firefox 36, this copies and pastes like "a -> b" which is the
desired behavior. In Chrome 40, this copies and pastes like "a  b".

Is my desired behavior (to show unicode but copy an ASCII
representation) generally possible? Are there specs somewhere about
copy/paste behavior? I looked in  but
found nothing relevant.

Is this the right venue for this question? Should I take it somewhere else?

Thanks,

David Sheets