W3C home > Mailing lists > Public > www-style@w3.org > January 2016

Re: [css-text] pre-wrap / pre-wrap-auto

From: Koji Ishii <kojiishi@gmail.com>
Date: Fri, 15 Jan 2016 02:06:35 +0900
Message-ID: <CAN9ydbWgUQwyUwm_i9whpmxriWdHD8QqHa=DJkF3Ddnk9E0LYw@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Hi Florian, sorry I'm intermittent. Yeah, talking, probably us two
before we discuss at WG might work better, Sun/Mon/Tue night probably?

My position is:
1. I'm not happy with the last resolution, thank you for your understanding.
2. IIUC you want to solve this rather broadly, while I believe this
issue needs adaptation for each case. I'm guessing this is making our
discussion hard. I mean, I believe that TEXTAREA, word processors,
code editors, or non-editors (code listing etc.) have each different
requirements and that was why I asked you about use cases or real
examples, but your replies were mix of these. We probably need to
resolve this first.
3. I don't have a proposal, nor I'm not really motivated to fix this
issue since:
  a. TEXTAREA is not about interoperability and is not something
you're trying to solve, correct?
  b. In js-based editors, I suspect js can solve many of such issues
anyway, so I'm not really sure if this is something js developers want
UA to solve. Since UA is underlying platform for editor developers,
I'd like to hear what they say, and see if there were consensus.
  c. For non-editors, yeah, that belongs to CSS WG, but I haven't seen
big complaints for non-editors scenario unless I missed something
(sorry if I did...)
  d. I have one experience in the past to conclude that this is an
unsolvable issue after a good amount of efforts to solve, because any
solutions will come with side-effects that are oftentimes
uncomfortable for other users, and took different higher-level
approach to solve user issues. For example, in TEXTAREA, we could
insert ENTER if user pressed SPACE at the beginning of a wrapped line.
We can't do that in contenteditable because js developers do not want
UA to do automatic things, but it also means that js developers could
possibly solve user problems. That experience drives me to the less
motivations for UA to solve this.

I hope this makes my thoughts clearer and helps you to figure out something.

/koji


On Mon, Jan 11, 2016 at 6:18 PM, Florian Rivoal <florian@rivoal.net> wrote:
>
>> On Nov 21, 2015, at 18:57, Florian Rivoal <florian@rivoal.net> wrote:
>>
>> What isn't clear to me is whether anything other than status quo is ok for you. I hope not, since status quo means spec violations and no interop. (see https://lists.w3.org/Archives/Public/www-style/2015Mar/0386.html).
>>
>> If I understand correctly, if the spaces are preserved, you want overflow-wrap:break-word to let them overflow rather than wrap them. This is not the status quo. Firefox (and Presto, and Prince) wraps them, IE sometimes does depending on the type of element. (Webkit/Blink neither wrap nor overflow since they don't preserve the spaces in the first place)
>>
>> If you have a proposal, I'd like to hear it. The set of things that seem acceptable to me is broader than the specific proposal of mine that you're rejecting, so maybe what you have in mind would work for me.
>
> Hi Koji,
>
> Since all the people involved or interested in this discussion will be in Sydney, I think this will be a good opportunity to try and resolve this. As I say above, you've made it quite clear that the last resolution and my latest proposition aren't acceptable to you. But it is still not clear to me what is acceptable to you.
>
> If you have a proposal, could you make it explicit, so that I can see if it works for me as well?
>
> If you don't have one, could you make it clear at least what your requirements are, so that I can try to find some solution that satisfies both your requirements and mine?
>
>  - Florian
Received on Thursday, 14 January 2016 17:07:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:59 UTC