Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

[css-text] copying text-transform

12 messages.

[css-text] copying text-transform'd text
fantasai   Wed, 01 Apr 2015 22:41:55 -0400

www-style > April 2015 > 0000.html

Received on Thursday, 2 April 2015 02:42:26 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: brad.kemper@gmail.com
Copied to: www-style@w3.org, www-style@w3.org.

On 04/01/2015 10:20 PM, Brad Kemper wrote: > On Apr 1, 2015, at 4:01 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> On 04/01/2015 11:55 AM, Brad Czerniak wrote: >>> Specifically, for a particular use case (though there are undoubtedly others); A heading/title has text-tranform: uppercase; >>> by default. When a user selects the text for copy/paste, it gets copied in upper case. Having the option to set >>> text-transform: none; on ::selection would be a win. >> >> This seems like a browser bug. Nothing in the CSS spec says that >> 'text-transform' should affect copy/paste. And probably it shouldn't. > > I agree with you, but as I recall from last time we had the conversation, > most implementations do convert 'text-transform : uppercase' to all > uppercase letters when copied. I know Safari does. I find it pretty > annoying myself, but apparently most users are surprised when the all > caps text they copied is not all caps when they paste it as plain text. Gecko and Presto don't do this. I think we probably need to get the browsers to agree on this issue and put the required behavior in the spec, so authors know what to expect. Personally I don't think the copied text should be affected by the transform: if that's a key part of the text's presentation, then it should be done in the source. There's a lot of cases where it wouldn't make sense to copy out the style. E.g. putting the first word (or phrase) of an article is a stylistic choice that shouldn't come out in the plaintext copy. ~fantasai
Re: [css-text] copying text-transform'd text
Florian Rivoal   Thu, 2 Apr 2015 10:03:18 +0200

www-style > April 2015 > 0000.html

Received on Thursday, 2 April 2015 08:03:46 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

> > On 02 Apr 2015, at 04:41, fantasai <fantasai.lists@inkedblade.net> wrote: > > On 04/01/2015 10:20 PM, Brad Kemper wrote: >> On Apr 1, 2015, at 4:01 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >>> On 04/01/2015 11:55 AM, Brad Czerniak wrote: >>>> Specifically, for a particular use case (though there are undoubtedly others); A heading/title has text-tranform: uppercase; >>>> by default. When a user selects the text for copy/paste, it gets copied in upper case. Having the option to set >>>> text-transform: none; on ::selection would be a win. >>> >>> This seems like a browser bug. Nothing in the CSS spec says that >>> 'text-transform' should affect copy/paste. And probably it shouldn't. >> >> I agree with you, but as I recall from last time we had the conversation, >> most implementations do convert 'text-transform : uppercase' to all >> uppercase letters when copied. I know Safari does. I find it pretty >> annoying myself, but apparently most users are surprised when the all >> caps text they copied is not all caps when they paste it as plain text. > > Gecko and Presto don't do this. > > I think we probably need to get the browsers to agree on this > issue and put the required behavior in the spec, so authors know > what to expect. > > Personally I don't think the copied text should be affected by > the transform: if that's a key part of the text's presentation, > then it should be done in the source. There's a lot of cases > where it wouldn't make sense to copy out the style. E.g. putting > the first word (or phrase) of an article is a stylistic choice > that shouldn't come out in the plaintext copy. Agreed. This may be even more important in other languages. For example, when small kana are transformed to big kana*, it would be wrong to copy/paste big kana, as the plain text you'd get out of that would just be incorrect. - Florian * I know we don't have this transform now, but the need for it is clear, so we'll eventually have it, either through @text-transform or as a built-in keyword**. ** I used to be against the built-in keyword due to the possibility of @text-transform appearing, and to avoid special casing languages too much, but since there seems to be very little interest in @text-tranform and since this transform is important for accessibility I now think we should get a built-in keyword.
RE: [css-text] copying text-transform'd text
James Ross   Thu, 2 Apr 2015 09:38:10 +0100

www-style > April 2015 > 0000.html

Received on Thursday, 2 April 2015 08:38:36 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org
Copied to: fantasai.lists@inkedblade.net, brad.kemper@gmail.com.

> Date: Wed, 1 Apr 2015 22:41:55 -0400 > From: fantasai.lists@inkedblade.net > > On 04/01/2015 10:20 PM, Brad Kemper wrote: > > I agree with you, but as I recall from last time we had the conversation, > > most implementations do convert 'text-transform : uppercase' to all > > uppercase letters when copied. I know Safari does. I find it pretty > > annoying myself, but apparently most users are surprised when the all > > caps text they copied is not all caps when they paste it as plain text. > > Gecko and Presto don't do this. Trident (Internet Explorer 11 on Windows 7) doesn't do this either. -- James Ross <james@james-ross.co.uk>
Re: [css-text] copying text-transform'd text
Brad Kemper   Thu, 2 Apr 2015 07:12:06 -0700

www-style > April 2015 > 0000.html

Received on Thursday, 2 April 2015 14:12:36 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: www-style@w3.org, www-style@w3.org.

On Apr 1, 2015, at 7:41 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> as I recall from last time we had the conversation, >> most implementations do convert 'text-transform : uppercase' to all >> uppercase letters when copied. I know Safari does. I find it pretty >> annoying myself, but apparently most users are surprised when the all >> caps text they copied is not all caps when they paste it as plain text. > > Gecko and Presto don't do this I stand corrected. I might start using Firefox more often when I want to copy transformed text.
Re: [css-text] copying text-transform'd text
Brad Kemper   Thu, 2 Apr 2015 07:17:18 -0700

www-style > April 2015 > 0000.html

Received on Thursday, 2 April 2015 14:17:48 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: w3c-20040125@james-ross.co.uk
Copied to: www-style@w3.org, www-style@w3.org, fantasai.lists@inkedblade.net.

> On Apr 2, 2015, at 1:38 AM, James Ross <w3c-20040125@james-ross.co.uk> wrote: > > > Date: Wed, 1 Apr 2015 22:41:55 -0400 > > From: fantasai.lists@inkedblade.net > > > > On 04/01/2015 10:20 PM, Brad Kemper wrote: > > > I agree with you, but as I recall from last time we had the conversation, > > > most implementations do convert 'text-transform : uppercase' to all > > > uppercase letters when copied. I know Safari does. I find it pretty > > > annoying myself, but apparently most users are surprised when the all > > > caps text they copied is not all caps when they paste it as plain text. > > > > Gecko and Presto don't do this. > > Trident (Internet Explorer 11 on Windows 7) doesn't do this either. > -- > James Ross <james@james-ross.co.uk> Interesting. So mainly just webkit and blink then. I remember threads from long ago when the tide went against me for saying copied text should not have the underlying character data changed due to text-transform.
Re: [css-text] copying text-transform'd text
Koji Ishii   Wed, 8 Apr 2015 20:58:30 +0900

www-style > April 2015 > 0000.html

Received on Wednesday, 8 April 2015 11:59:01 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

On Apr 2, 2015, at 11:41, fantasai <fantasai.lists@inkedblade.net> wrote: > > I think we probably need to get the browsers to agree on this > issue and put the required behavior in the spec, so authors know > what to expect. > > Personally I don't think the copied text should be affected by > the transform: if that's a key part of the text's presentation, > then it should be done in the source. There's a lot of cases > where it wouldn't make sense to copy out the style. E.g. putting > the first word (or phrase) of an article is a stylistic choice > that shouldn't come out in the plaintext copy. I disagree on both the desired behavior and standardizing this behavior. I personally prefer What You See Is What You Copy. How it’s written in the source file doesn’t matter much to me when I’m viewing a web site. Especially if we were to introduce regex based text-transform in future, it’s even more confusing. And I think plain-textizing belongs to browser UX. If you don’t like a behavior in your favorite browser, filing a bug to the browser makes more sense to me. /koji
Re: [css-text] copying text-transform'd text
Dave Cramer   Thu, 20 Oct 2016 09:03:57 -0400

www-style > October 2016 > 0000.html

Received on Thursday, 20 October 2016 13:04:28 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: kojiishi@gmail.com
Copied to: fantasai.lists@inkedblade.net, brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

On Wed, Apr 8, 2015 at 7:58 AM, Koji Ishii <kojiishi@gmail.com> wrote: > On Apr 2, 2015, at 11:41, fantasai <fantasai.lists@inkedblade.net> wrote: >> >> I think we probably need to get the browsers to agree on this >> issue and put the required behavior in the spec, so authors know >> what to expect. >> >> Personally I don't think the copied text should be affected by >> the transform: if that's a key part of the text's presentation, >> then it should be done in the source. There's a lot of cases >> where it wouldn't make sense to copy out the style. E.g. putting >> the first word (or phrase) of an article is a stylistic choice >> that shouldn't come out in the plaintext copy. > > I disagree on both the desired behavior and standardizing this behavior. > > I personally prefer What You See Is What You Copy. How it’s written in the source file doesn’t matter much to me when I’m viewing a web site. Especially if we were to introduce regex based text-transform in future, it’s even more confusing. > > And I think plain-textizing belongs to browser UX. If you don’t like a behavior in your favorite browser, filing a bug to the browser makes more sense to me. Per the Working Group call yesterday, here are some browser bugs around this issue: Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=35148 Webkit (old): https://bugs.webkit.org/show_bug.cgi?id=3429 Webkit (new): https://bugs.webkit.org/show_bug.cgi?id=43202 There doesn't seem to be consensus, but it's only been sixteen years. Dave
[css-text] JS editors and copying text-transform'd text (was: Re: Proposed Agenda)
Johannes Wilm   Tue, 25 Oct 2016 15:58:38 +0200

www-style > October 2016 > 0000.html

Received on Tuesday, 25 October 2016 13:59:11 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: daniel.glazman@disruptive-innovations.com, www-style@w3.org, public-editing-tf@w3.org, public-editing-tf@w3.org.

Hey, as promised, I did a little survey among some of the main JS based editors that exist as of today and how they look at plaintext on the clipboard when an HTML version is available. I only contacted the main ones that have been responsive in the past this time, and I left out those maintained by browser makers, as I assume that others on the list have a more direct line of communication with them. I had conversations with each of the editor developers on their usage of the plaintext clipboard contents when handling paste and what they think about the application about text transform on the part of the browser for both plaintext and html. Some of the answers/discussions that resulted from my initial questions were much longer than what I summarize below, and some of the developers may decide that they want to respond with more detail themselves here. In brief, the answers were as follows: 1. Usage of the plaintext version of the clipboard contents: CKEditor: Makes use of the plaintext version when there is no HTML-version. In those cases it attempts to create a pseudo-HTML version based on the plaintext version. When there is an HTML-version, it uses that instead,. If it needs a plaintext version and there is an HTML-version available, it creates its own plaintext version based on the HTMl version. ProseMirror: Uses the plaintext version if the user hits Shift + paste-shortcut. QuillJS: Is not directly using either plaintext or html version "because of inconsistencies across browsers. For example copying from IE11 and pasting into Chrome will include the entire document markup including <head> and <style> tags and in some cases <script> tags". Paste is handled by moving the caret into an offscreen contenteditable element and then cleaning up whatever ends up in there. Substance.io: Uses the plaintext version as a backup, if they cannot figure out what's supposed to be in the HTML-version. TinyMCE: Makes use of the plaintext version when plaintext is needed. 2. Ideas about application of text-transform in plaintext: CKEditor: -- Doesn't apply -- ProseMirror: "transforming text before putting it on the clipboard is probably a bad idea" QuillJS: "[...] it should not transform. There should be a separation between data and presentation [...] . Trying to be helpful by changing the data breaks this paradigm because now the data is wrong. This also leads down a deep dark rabbit hole. Should you put '-' in front of list elements? What if CSS and inline styles changes or hides list-style? This in my view is a classic example of trying to be too helpful." Substance.io: Applying the transformation seems consistent with the HTML version. TinyMCE: "the data put on the clipboard should be available though the clipboard API as raw as it can be some security filtering needs to exist. So if I copy content from a browser it should basically be innerHTML and innerText of the fragment being copied. Then on paste it should do no fancy stuff at all just provide what ever is in the plain text and html mime types as raw data." 3. Ideas about application of text-transform in html (see https://jsfiddle.net/johanneswilm/b054qzts/2/ in Chrome ) CKEditor: Problematic. "We'd like the HTML to stay as it was on copy. We've been complaining a lot about the spans which Chrome adds, because it's hard to understand which of them should be filtered out. Applying text transformation is even bigger problem, cause then we have no clue about the original case." ProseMirror: -- same as plaintext -- QuillJS: -- same as plaintext -- Substance.io: "If you use the Clipboard HTML between applications, you have to accept some losses. I would prefer to express as much as possible with simple HTML and only to put unimportant stuff into styles, just as a hint for the other [receiving] app. [...] It's a technical, internal detail how an app/website arrives at its capital letters." (my translation) TinyMCE: as plaintext + "[...] you want to distinct between style that was in the page and styles that was computed and added by the browser. In this case: <style> .bgRed { background: red; } </style> [<p style="color: red" class="bgRed">abc</p>] The contents on the clipboard on some browsers would be in Chrome for example: <p style="color: red; background red;">abc</p> So there is no way for us to know that supposed to be in there or not. What they could do is to generate classes so the clipboard would be: <style> .bgRed { background: red; } </style> <p style="color: red" class="bgRed">abc</p> This way it would be up to the implementer to get rid of the bgRed and style element or compute the runtime styles." -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [css-text] copying text-transform'd text
Koji Ishii   Wed, 26 Oct 2016 02:38:49 +0900

www-style > October 2016 > 0000.html

Received on Tuesday, 25 October 2016 17:39:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: dauwhe@gmail.com
Copied to: fantasai.lists@inkedblade.net, brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

Replied to github but this seems to be the place to reply, sorry. I collected major issues we're aware of, from out bug database and user forum. Given the Greg's request, the list isn't limited to text-transform. 1. Most of feedback are about preserving format in the way users expect when copy/pasting formatted text, either from browser or to browser. 2. There are cases where we don't handle spaces (collapse too much or to little) and new lines (fail to generate new lines for end of blocks etc.) in the way users expect. One example is crbug.com/318925. 3. There are cases where selecting linked text is hard or impossible. One example is crbug.com/446391. The text-transform didn't come up in either places. /koji 2016-10-20 22:03 GMT+09:00 Dave Cramer <dauwhe@gmail.com>: > On Wed, Apr 8, 2015 at 7:58 AM, Koji Ishii <kojiishi@gmail.com> wrote: > > On Apr 2, 2015, at 11:41, fantasai <fantasai.lists@inkedblade.net> > wrote: > >> > >> I think we probably need to get the browsers to agree on this > >> issue and put the required behavior in the spec, so authors know > >> what to expect. > >> > >> Personally I don't think the copied text should be affected by > >> the transform: if that's a key part of the text's presentation, > >> then it should be done in the source. There's a lot of cases > >> where it wouldn't make sense to copy out the style. E.g. putting > >> the first word (or phrase) of an article is a stylistic choice > >> that shouldn't come out in the plaintext copy. > > > > I disagree on both the desired behavior and standardizing this behavior. > > > > I personally prefer What You See Is What You Copy. How it’s written in > the source file doesn’t matter much to me when I’m viewing a web site. > Especially if we were to introduce regex based text-transform in future, > it’s even more confusing. > > > > And I think plain-textizing belongs to browser UX. If you don’t like a > behavior in your favorite browser, filing a bug to the browser makes more > sense to me. > > Per the Working Group call yesterday, here are some browser bugs > around this issue: > > Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=35148 > Webkit (old): https://bugs.webkit.org/show_bug.cgi?id=3429 > Webkit (new): https://bugs.webkit.org/show_bug.cgi?id=43202 > > There doesn't seem to be consensus, but it's only been sixteen years. > > Dave >
Re: [css-text] copying text-transform'd text
Johannes Wilm   Wed, 26 Oct 2016 18:44:36 +0200

www-style > October 2016 > 0000.html

Received on Wednesday, 26 October 2016 16:45:06 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: kojiishi@gmail.com
Copied to: dauwhe@gmail.com, fantasai.lists@inkedblade.net, brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

On today's call the direction application (changing the html structure rather than keeping it in the styles so that <span style="text-transform:uppercase;">Hello</span> turns into <span>HELLO</span>) in the case of html was mentioned. There is a bug for this on Chrome that has been open since 2013: crbug.com/325231 . In my personal opinion, this is the more serious issue, because as long as there is an HTML-version of the clipboard with the original capitalization information, pasting applications can always use the HTML version to create a custom plaintext version if they want a plaintext version that is different from what the browser delivers. On Tue, Oct 25, 2016 at 7:38 PM, Koji Ishii <kojiishi@gmail.com> wrote: > Replied to github but this seems to be the place to reply, sorry. > > I collected major issues we're aware of, from out bug database and user > forum. Given the Greg's request, the list isn't limited to text-transform. > > 1. Most of feedback are about preserving format in the way users expect > when copy/pasting formatted text, either from browser or to browser. > 2. There are cases where we don't handle spaces (collapse too much or to > little) and new lines (fail to generate new lines for end of blocks etc.) > in the way users expect. One example is crbug.com/318925. > 3. There are cases where selecting linked text is hard or impossible. One > example is crbug.com/446391. > > The text-transform didn't come up in either places. > > /koji > > 2016-10-20 22:03 GMT+09:00 Dave Cramer <dauwhe@gmail.com>: > >> On Wed, Apr 8, 2015 at 7:58 AM, Koji Ishii <kojiishi@gmail.com> wrote: >> > On Apr 2, 2015, at 11:41, fantasai <fantasai.lists@inkedblade.net> >> wrote: >> >> >> >> I think we probably need to get the browsers to agree on this >> >> issue and put the required behavior in the spec, so authors know >> >> what to expect. >> >> >> >> Personally I don't think the copied text should be affected by >> >> the transform: if that's a key part of the text's presentation, >> >> then it should be done in the source. There's a lot of cases >> >> where it wouldn't make sense to copy out the style. E.g. putting >> >> the first word (or phrase) of an article is a stylistic choice >> >> that shouldn't come out in the plaintext copy. >> > >> > I disagree on both the desired behavior and standardizing this behavior. >> > >> > I personally prefer What You See Is What You Copy. How it’s written in >> the source file doesn’t matter much to me when I’m viewing a web site. >> Especially if we were to introduce regex based text-transform in future, >> it’s even more confusing. >> > >> > And I think plain-textizing belongs to browser UX. If you don’t like a >> behavior in your favorite browser, filing a bug to the browser makes more >> sense to me. >> >> Per the Working Group call yesterday, here are some browser bugs >> around this issue: >> >> Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=35148 >> Webkit (old): https://bugs.webkit.org/show_bug.cgi?id=3429 >> Webkit (new): https://bugs.webkit.org/show_bug.cgi?id=43202 >> >> There doesn't seem to be consensus, but it's only been sixteen years. >> >> Dave >> > > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [css-text] copying text-transform'd text
Johannes Wilm   Thu, 27 Oct 2016 00:49:26 +0200

www-style > October 2016 > 0000.html

Received on Wednesday, 26 October 2016 22:49:55 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: kojiishi@gmail.com
Copied to: dauwhe@gmail.com, fantasai.lists@inkedblade.net, brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org.

Here is the corresponding Webkit issue from 2010: https://bugs.webkit.org/show_bug.cgi?id=43202 In the discussion of that issue there are actually some who support keeping the current behavior. So maybe this is more controversial anyway? On Wed, Oct 26, 2016 at 6:44 PM, Johannes Wilm <johannes@fiduswriter.org> wrote: > On today's call the direction application (changing the html structure > rather than keeping it in the styles so that <span style="text-transform:uppercase;">Hello</span> > turns into <span>HELLO</span>) in the case of html was mentioned. > > There is a bug for this on Chrome that has been open since 2013: > crbug.com/325231 . > > In my personal opinion, this is the more serious issue, because as long as > there is an HTML-version of the clipboard with the original capitalization > information, pasting applications can always use the HTML version to create > a custom plaintext version if they want a plaintext version that is > different from what the browser delivers. > > > > On Tue, Oct 25, 2016 at 7:38 PM, Koji Ishii <kojiishi@gmail.com> wrote: > >> Replied to github but this seems to be the place to reply, sorry. >> >> I collected major issues we're aware of, from out bug database and user >> forum. Given the Greg's request, the list isn't limited to text-transform. >> >> 1. Most of feedback are about preserving format in the way users expect >> when copy/pasting formatted text, either from browser or to browser. >> 2. There are cases where we don't handle spaces (collapse too much or to >> little) and new lines (fail to generate new lines for end of blocks etc.) >> in the way users expect. One example is crbug.com/318925. >> 3. There are cases where selecting linked text is hard or impossible. One >> example is crbug.com/446391. >> >> The text-transform didn't come up in either places. >> >> /koji >> >> 2016-10-20 22:03 GMT+09:00 Dave Cramer <dauwhe@gmail.com>: >> >>> On Wed, Apr 8, 2015 at 7:58 AM, Koji Ishii <kojiishi@gmail.com> wrote: >>> > On Apr 2, 2015, at 11:41, fantasai <fantasai.lists@inkedblade.net> >>> wrote: >>> >> >>> >> I think we probably need to get the browsers to agree on this >>> >> issue and put the required behavior in the spec, so authors know >>> >> what to expect. >>> >> >>> >> Personally I don't think the copied text should be affected by >>> >> the transform: if that's a key part of the text's presentation, >>> >> then it should be done in the source. There's a lot of cases >>> >> where it wouldn't make sense to copy out the style. E.g. putting >>> >> the first word (or phrase) of an article is a stylistic choice >>> >> that shouldn't come out in the plaintext copy. >>> > >>> > I disagree on both the desired behavior and standardizing this >>> behavior. >>> > >>> > I personally prefer What You See Is What You Copy. How it’s written in >>> the source file doesn’t matter much to me when I’m viewing a web site. >>> Especially if we were to introduce regex based text-transform in future, >>> it’s even more confusing. >>> > >>> > And I think plain-textizing belongs to browser UX. If you don’t like a >>> behavior in your favorite browser, filing a bug to the browser makes more >>> sense to me. >>> >>> Per the Working Group call yesterday, here are some browser bugs >>> around this issue: >>> >>> Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=35148 >>> Webkit (old): https://bugs.webkit.org/show_bug.cgi?id=3429 >>> Webkit (new): https://bugs.webkit.org/show_bug.cgi?id=43202 >>> >>> There doesn't seem to be consensus, but it's only been sixteen years. >>> >>> Dave >>> >> >> > > > -- > Johannes Wilm > Fidus Writer > http://www.fiduswriter.org > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [css-text] copying text-transform'd text to HTML (was copying text-transform'd text
Koji Ishii   Mon, 31 Oct 2016 14:07:58 +0900

www-style > October 2016 > 0000.html

Received on Monday, 31 October 2016 05:08:54 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: johannes@fiduswriter.org
Copied to: dauwhe@gmail.com, fantasai.lists@inkedblade.net, brad.kemper@gmail.com, www-style@w3.org, www-style@w3.org, yosin@chromium.org, yoichio@chromium.org.

Forking a thread since what Johannes says "more important" is different from the current topic. 2016-10-27 7:49 GMT+09:00 Johannes Wilm <johannes@fiduswriter.org>: > Here is the corresponding Webkit issue from 2010: https://bugs.webkit.org/ > show_bug.cgi?id=43202 > > In the discussion of that issue there are actually some who support > keeping the current behavior. So maybe this is more controversial anyway? > > On Wed, Oct 26, 2016 at 6:44 PM, Johannes Wilm <johannes@fiduswriter.org> > wrote: > >> On today's call the direction application (changing the html structure >> rather than keeping it in the styles so that <span >> style="text-transform:uppercase;">Hello</span> turns into >> <span>HELLO</span>) in the case of html was mentioned. >> >> There is a bug for this on Chrome that has been open since 2013: >> crbug.com/325231 . >> >> In my personal opinion, this is the more serious issue, because as long >> as there is an HTML-version of the clipboard with the original >> capitalization information, pasting applications can always use the HTML >> version to create a custom plaintext version if they want a plaintext >> version that is different from what the browser delivers. >> > Thank you Johannes for the issue links. Both crbug.com/325231 and wkb.ug/43202 look a bit ambiguous to me whether people are discussing about plain-text copy or formatted-text copy. For the formatted-text copy, I agree it should not be applied. We'll see if we can re-prioritize this one, but also note that contributions are greatly appreciated. /koji