- From: Florian Rivoal <florian@rivoal.net>
- Date: Thu, 12 Mar 2015 11:01:17 +0100
- To: Dael Jackson <daelcss@gmail.com>
- Cc: www-style@w3.org
A few of the things I said got a bit garbled, so here are corrections. Sorry for not speaking slower / clearer in the first place. I left the rest of the discussion for context to make it easier to re-read the whole thing. > Add Property Value to Allow Scrolling Without Scrollbar > ------------------------------------------------------- > > Florian: There was a request on the ML to add a property to let > authors decide if scrollbars are visible, invisible or > autohide. > Florian: This isn't about changing behavior. There's already a > property version of this from Microsoft that's recycling > overflow-styling that we dropped. overflow-styling -> overflow-style > Florian: If we want to do this, they probably have the right > behavior, though we might want to rename. scrollbar: > visible etc. is more reasonable. > Florian: The question is if we should do it. If you're thinking in > an app context you might want this. But how scrollbars > behave seems more platform level. > Florian: So what does the group think? > Rossen: I missed the last sentences from echo. Can your repeat? > Florian: If you're doing native control and you don't want native > scrollbars to show because you're providing a different > UI it seems reasonable to ask for scrollbars to be hidden > or something like that. It makes some amount of sense. > Florian: If we're going to make it work, the way MS has is > reasonable, but should we provide that control for > authors? > > smfr: Some people choose to use legacy scroll bars, but we feel > the user should be in control of the scrollbars. > Florian: So Microsoft obviously feels differently. > smfr: We want users to control scrollbars, not authors. > > Rossen: Right. Um. In our case when the feature was developed and > spec'ed internally we looked at various app scenarios > between small and larger form factors. > Rossen: In a lot of cases where you use mouse or high fidelity > precision, having the scrollbar makes sense. When you use > touch and larger corner devices, scrollbars are kinda > inadequate. > Rossen: So that's where the discussion began internally. > Florian: If that's the motivation, why isn't the UA that switches > instead of authors controlling? > Rossen: Some of the reasons are people are picky about layouts. > When scrollbars are visible they take space. When people > want to account for that space when they create tight > layouts. > Rossen: Just like when we're letting authors control padding, > scrollbars are in the same realm. > > plinss: Bert? > Bert: I agree with smfr. It should be associated with the > environment a user is working in. I agree on a small screen > you don't want scrollbars, but on my laptop I'd rather see > them. > Bert: If it works that way in one program, it should work that way > in browsers. Doesn't mean you always have to use the > scrollbars for scrolling. You can always swipe even if > they're showing. Arrows, mouse wheel, all those aren't > excluded. > Florian: And where we have apps where people want control, using > overflow: hidden and working your way through is probably > +the right way to do it. [...] and working your way through *with scripts* [...] > plinss: Other opinions? > plinss: I'm not hearing people in favor except for Microsoft. > Florian: Rossen, do you want to add this, or are you happy about > us not adding this to platform? > Rossen: I won't force anyone. This is a currently proprietary > feature that is being used successfully on our platform so > we won't stop even if you don't add it. But if it doesn't > make sense to further extend it, that's probably okay. > Florian: And bikeshedding aside if we'll have it you've got it > right, but I sympathize that it's user level. > > RESOLVED: Don't add a property to hide scrollbars at this time > pre-wrap and whitespace > ----------------------- > > <Florian> http://jsbin.com/jiduc/1/edit?html,css,output > Florian: There's a thread here that's linked in the agenda. The > thing is we don't have interop on pre-wrap which has been > the question on how should it behave. If you look into > it, the spec approach isn't obviously the right one. > Florian: The way Firefox and IE do this is what the spec says. > Florian: When you have more than one whitespace when there's > pre-wrap it's turned into a run and prevents them from > collapsing, but it also won't wrap. [...] If you have a run of that extends beyond the end of the line, it just gets truncated at the end of the line. > Florian: Chrome and Safari do it differently. If you have a run it > just gets completed at the end of the line. > Florian: That's not what the spec says, but it happens that that > behavior is a match for word processors. > Florian: So I'd like to hear a bit from people from Chrome or > Safari if they can confirm that this is an intentional > match. > > <dbaron> Is the thing with spaces going past the end of the line > specific to pre-wrap, or just a lot easier to see with > it? > > fantasai: It is intentional. This came up earlier in text cycle > and there's a prevision to allow this. > Florian: I missed that. Where is this allowed? > <fantasai> http://dev.w3.org/csswg/css-text/#white-space-phase-2 > <fantasai> item #4 > Florian: Okay. > Florian: So both behaviors are allowed. > > Florian: But I'm not sure either behavior is exactly what authors > want. The Chrome behavior variant, you want things to > behave like a text editor where spaces don't collapse, > but they do wrap. That's not exactly something you can > get. [...] The Chrome behavior variant is confusing because you cannot see any effect when you type more white space beyond the end of the line. The other behavior you may want would be similar to plain text editors where spaces don't collapse but they do wrap. [..] > <Florian> http://jsbin.com/bokato/1/edit?html,css,output > Florian: You can approximate, but it's not quite the same. If you > look at the link above and try to insert a space before > the first letter, second line what happens is in line > with the spec, but not what you would expect from a text > editor. You can approximate it using "word-wrap: break-word;", but it's not quite the same. [...] > Florian: It's nice that the spec allows both, but we have two > non-interoperable behaviors and neither behavior allows > you to do what you would do in a plain text editor. > Florian: Do we want to try and reopen this and get both > interoperable, or are we happy? > > fantasai: There's 3 behaviors you listed. One is don't wrap and > don't collapse, I don't understand why that would be > what you want. > fantasai: Where you overflow with spaces, it seems no one would > want that. > Florian: That's the one Firefox does, right? > fantasai: We inherited that from Unicode. > Florian: What's nice on this one from Chrome, if you add a lot of > spaces there's no magic where the caret doesn't move > until you add something that isn't a space. Other than > that I agree it's not very desirable. What's nice with this one *compared to* Chrome [...] > fantasai: I'd be okay with allowing spaces to wrap. That seems > sensible and straightforward. I'm not sure if we can > make that change. We'd have to see what the other > implementors think about that since it would be a change. > As far as the collapsing, it would be good to hear if > people want to implement that. We could have 2 keywords. > The main downside of the collapsing is if you have a > caret and it's not moving. I'd want it to keep moving so > you can see what you're typing, > fantasai: but not render that way. > Florian: There's something in between as well. If you had > something just like the Firefox behavior where you > overflow at the end of the line. You could hide it with > overflow: hidden to get something like the Chrome. But > one thing that's nice about Chrome, if you have a word, > one space, another word, a lot of spaces and the lot of > spaces don't fit, the second word doesn't go onto the > second line. > Florian: If we can keep the two words on the same line you would > end up with a behavior that's interesting. If you had a > switch somewhere to control. > Florian: I think it's a bit too subtle to define who wants what. > I'm just wondering if there's room to try and define > something better. [...] to define what we want verbally during the conf-call. [...] > <Rossen> http://jsfiddle.net/py1s28je > Rossen: I pasted a jsfiddle. What would be your expected behavior > in that one? Chrome or Firefox? > fantasai: Whitespace pre means don't wrap the line. We're talking > about pre-wrap. Same with no wrap. > Rossen: Okay. I think I misread your ex. Sorry. > > Florian: For interest to implement, Bloomberg has been playing > with this. They have an extra value that wraps the spaces. > > smfr: So Florian in your fiddle you have a span in the div. It's > changing behavior. If you remove it, it changes Chrome and > Safari. > Florian: Which? > <smfr> http://jsbin.com/bokato/1/edit?html,css,output > smfr: Your single line one. This one (above). > Florian: Okay. If you remove the span it changes? Um...no, it does > not change? I don't see any difference in Chrome. What > difference did you see? > smfr: Okay. Now I'm not seeing it. I don't know why. > > Florian: There are a number of oddities. With Chrome if you keep > adding spaces, you don't see it until you put something > after the space. And I don't think you can opt into the > other behavior. The Firefox one causes long overflow and > adding word-break gives you an approximation, but it is > worse than the real thing. > Florian: Again, I think we can't do exact spec on this call, but > is there interest for implementors to do this or accept > patches, or are we stuck with the current? > > Bert: I think I agree with all Florian's examples. I have > different editors that do different things. > Bert: They are confusing. I have several programs that do things > differently. Some show the spaces, some that don't and those > that don't I find more confusing, though spaces at the end > are always confusing. So I would prefer to make the spaces > as visible as possible. > Bert: I'm not sure we...we need to spell it out completely. We put > in the spec, in the published draft, that both are allowed. > Florian: The spec does allow both, but neither is what I think we > want for a behavior. > Florian: I think authors may want to switch between two behaviors, > but those aren't the two the spec allows and you can't > switch as an author. > Bert: Then I'm not sure I understand. > > <Florian> http://jsbin.com/bokato/1/edit?html,css,output > Florian: If you open this in Firefox or IE and you try to insert a > space at the beginning of the 2nd line, what you probably > want is for the second line to indent one space. That's > not what happens. > gregwhitworth: That's not what happens in IE. > gregwhitworth: Are you saying because the 'world' bumps to the > second line? > Florian: Correct. > gregwhitworth: Then IE does the same. > Florian: So this is allowed by the spec, but I don't think this is > something people want. > Rossen: You're saying that Word doesn't do that? > Florian: Word doesn't. There is no character return. If you keep > adding spaces they disappear off the right end of the > first line. That's what Chrome does. If you open that > example in Chrome it does what Word does. > Rossen: I'm looking at Word 2013 and it's not the same behavior. > Florian: Did you do hello, space, world, lots of space, and then > more text? > Rossen: Yes. > Florian: And if you add more space it disappears at the end of the > first line. > Rossen: Yes. > Florian: Which is what Chrome does. > Florian: And is arguably confusing. You have a million spaces for > the caret and you don't know where until you add > something else and discover how far you were. > Florian: In that case wrapping after 'world' makes more sense, but > it's saner to have things overflow to the right instead > of disappear. If you want disappear there's overflow: > x-hidden > > Florian: I'm not sure I want a resolution, I want to hear if > trying to explore what the desirable behaviors may be and > then try and spec, is that something we want to try and > do? > smfr: Safari matches a text editor I tried, BBedit. > Florian: I think Chrome matches general word processors. > smfr: I don't think Word is the final word on text editors. > smfr: There's a difference between plain text and rich text. > Florian: Yes. Chrome and Safari can't get the plain text. > smfr: I just tested BBEdit and Text Edit and they have the Safari > behavior. > Florian: In plain text it doesn't. > smfr: That's not what I'm seeing. It never wraps 'world' and the > spaces just pile up. > Florian: Let me check. > Rossen: Are you sure you don't see the same thing in Word where > the spaces are piling up? > <BradK> Mail.app on Mac also matches BBEdit and Safari > Florian: smfr, you're right, I was confused about text edit. I > found some other ways where it didn't match Safari, there > seemed to be different subtleties. > Florian: Rossen, when it comes to Word I think if you add spaces > at the end of the first line it's different than adding > at the beginning of the second. > <BradK> Adding spaces to beginning of second line or end of first > line is the same on Mac. > > plinss: We've spent a lot of time on this. The question I heard is > do we want to explore changing this. I'm not sure anyone > has answered that. > Florian: And why this came up initially was Bloomberg in their > Chromium fork has added something to have the same > behavior as the Sublime text editor. Bloomberg is > interested in getting something that isn't what's on the > web. Do we want to figure out what the ideal is and how > we get there? > smfr: I just tried sublime text and its got weird behavior. > Florian: Then that's not exactly what we want. > <Bert> (I like Emacs (spaces not collapsed) rather than kedit > (spaces beyond window edge appear to have zero width).) > > smfr: I don't think Safari is interested in changing. If you want > to add maybe. > > Florian: If you look up HTML editing spec, if whitespace is normal > it has a complex thing about inserting non-breaking and > regular spaces so you get spaces that don't collapse. > This then says it's insane and authors should just go > into pre-wrap. Which indicates that the author assumes > you'd get a different behavior then you get. [...] don't collapse and also do wrap. [...] > Rossen: How much does this matter? I think there's diminishing > returns. Most editing tools on the web are custom and > don't rely on underlying platforms. All your e-mail, > social, etc. none of them rely on the underlying platform. > This is from the 80s and not that important now days. > Florian: Maybe one reason they don't rely on it is because it > doesn't do what they want. > Rossen: There's no reason for them to come back. All their > underlying scenarios are so different. > Rossen: I guess I'm with smfr. If you want to add something > probably but I have a hard time imagining us changing from > the current. > Florian: Neither changing nor adding? > Rossen: When you're adding, it's easy to not add. > Florian: But adding something that won't be implemented isn't > useful. > Rossen: I think that's what smfr said and I'm seconding that. > Florian: Even though current isn't what we really want? > Rossen: People who care about the consistency of their editing > behavior moved on 15 years ago. > > plinss: Okay. Anyone in favor of changing the existing spec > behavior? > [silence] > plinss: That's a no. Florian if you want to explore a property to > fine tune on the ML that's fine. > fantasai: I think it would be a new value. I think it is a problem > that we don't have interop. I think we can explore that > in the next level. > Florian: Okay. I don't care about what level. That we don't have > interop isn't great. > fantasai: But IE and Apple don't agree on how it behaves. > <Florian> http://jsbin.com/jiduc/1/edit?html,css,output > Florian: And if you look at the link, you get very different > things. > word-break for Korean > --------------------- > > Florian: There's two different behaviors that are valid for Korean. > The normal line-breaking applies after every syllable. > You can switch, but it switches for every language. If > you tag your language you can use a ko language selector > and that's fine. But where users can type, you don't know > what they'll enter. [...]The word-break:normal line-breaking wraps after each syllable, and word-break:keep-all line breaking only breaks at spaces. [...] > Florian: Bikeshedding aside, if we add to word-break something > that does the same as normal for everything unless > there's a Hangul symbol, that allows you to get keep-all > when you're next to Hangul. > > Florian: Someone mentioned on the list that it's not true that > both behaviors are equal. That the one for normal is > what's commonly wanted so it might not be worth > supporting. I don't know personally, I just know the > Korean language document indicates that both exist. > fantasai: I don't think this is worth adding. We've heard that > Korean people are okay with how it exists and the > default of breaking everywhere is fine. This is a > specialized case that doesn't seem particularly > necessary. I don't think the benefit is worth the cost > of implementation time, testing time, complication to > the language, etc. > Florian: You're saying it might be right, but not worth the cost? > fantasai: I don't think it's even correct, necessarily. Whomever > is using a mixed language should just get the default > behavior which is perfectly fine for Korean which the > Korean people think is perfectly fine instead of doing > this other behavior that you can only do if you know > what the content is. > Florian: I think this can be worked around if you really want this. I thinks this can be worked around *by sniffing the content in javascript* if you really want this. > fantasai: If you want language detection to find out if a > paragraph is Korean you can do that. I don't think this > needs to be automatic. It's a heuristic and not > necessarily a needed heuristic. > fantasai: If you really want to do this, you can do it in JS. The > Koreans aren't asking for it and it doesn't seem to be > needed for the use case of 'is this being done > correctly'. > > plinss: So that's a vote for no change. Any objections? > plinss: I'll take that as no change. > plinss: That's the top of the hour. Thanks everyone and we'll talk > next week. > > <Florian> fantasai: I think your point about wanting this for > hanja as well as for hangul if you're going to do it at > all seals the deal for me. > > <zcorpan> i will have to leave now. as for the "unrestricted > double in ScrollToOptions" topic, that issue is resolved > already so i think doesn't need further discussion. > https://lists.w3.org/Archives/Public/www-style/2015Mar/0048.html >
Received on Thursday, 12 March 2015 10:01:46 UTC