- From: Koji Ishii <kojiishi@gmail.com>
- Date: Fri, 15 Jan 2016 02:06:35 +0900
- 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