- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2015 20:11:20 -0400
- To: www-style@w3.org
Add Property Value to Allow Scrolling Without Scrollbar
-------------------------------------------------------
- RESOLVED: Don't add a property to hide scrollbars at this time
pre-wrap and whitespace
-----------------------
- Florian brought up the two different allowed implementations of
pre-wrap in the CSS Text spec and his belief that it's
confusing to have two different behaviors and that neither of
the spec'ed behaviors may meet author expectations.
- Everyone spent time with the examples and comparing them to text
editors and word processing software to determine if there
really is a expected behavior.
- None of the implementors had an interest in changing their
version and the group wasn't convinced this is necessary given
that most editing on the web is done with custom code.
Not Underlining Trailing Spaces
-------------------------------
- RESOLVED: Add the trailing-spaces value to text-decoration-skip
word-break for Korean
---------------------
- It was agreed that, though the proposal was possible, it wasn't
necessary as feedback from Koreans has been that the current
default is acceptable behavior.
====== FULL MINUTES BELOW =======
Present:
Rossen Atanassov
David Baron
Sanja Bonic
Bert Bos
Dave Cramer
Elika Etemad
Simon Fraser
Daniel Glazman
Dael Jackson
Toru Kawakubo
Brad Kemper
Chris Lilley
Peter Linss
Shinyu Murakami
Simon Pieters
Matt Rakow
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Tab Atkins
Angelo Cano
Tantek Çelik
Alex Critchfield
Michael Miller
Mike Sherov
Lea Verou
Ian Vollick
Scribe: dael
plinss: Let's get started.
plinss: Anything to add to the agenda?
[silence]
Behavior of MouseEvent.offsetX/Y
--------------------------------
plinss: Anyone on that can talk about this one?
plinss: That sounds like a no.
Unrestricted Double on ScrollToOptions
--------------------------------------
plinss: I guess that's zcorpan
<zcorpan> i'm trying to speak :-(
<zcorpan> ok i don't know why it's not working
plinss: We'll come back if you can sort out sound zcorpan
<zcorpan> ok i left so me and SimonSapin were mixed up
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.
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.
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.
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.
<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.
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.
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.
<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.
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.
Not Underlining Trailing Spaces
-------------------------------
Florian: If you do whitespace pre-wrap and you have a line with a
few spaces at the end. It doesn't matter about how they
wrap, but you have non-collapsed spaces and then you
continue and underline. Currently the underline will also
underline the spaces. This isn't what Word does and it's
prettier.
Florian: I don't think we can change what we have, but adding a
value saying that trailing spaces do not get underlined
sounds useful.
Rossen: I can agree on that.
smfr: Us too.
fantasai: I think this goes back to the issue of, are you dealing
with code where you care about number of spaces or is it
not code where you want pretty.
fantasai: I know that Chrome and Safari when it's about collapsing
spaces it is optimized for let's make this pretty. That
does indicate to trim underlining. So if we create where
spaces wrap and are visible we should underline them.
Florian: But in this case there is no difference because we don't
get into a case about wrapping. I'd be okay with people
who wrap spaces like Chrome to not underline. This feels
like something you should be able to control at the
author level.
Florian: Whether you're in pretty or code mode depends on browser.
So having this as an author level control instead of a
spec allowance would make sense to me.
plinss: I'm hearing people in favor.
Florian: I'm suggesting an additional value to text-decoration-
skip with an extra value of trailing-spaces.
plinss: Objections?
RESOLVED: Add the trailing-spaces value to text-decoration-skip
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.
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.
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 00:11:49 UTC