W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Telecon 2015-03-11

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2015 20:11:20 -0400
Message-ID: <CADhPm3sbh72wpTYOq9X_pw2O2rJaB7r8N0ppLzddCrB6ZTr22g@mail.gmail.com>
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 =======

  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

  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?

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
  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

  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
  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
  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
  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
  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

  <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

  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
  <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
  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
  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:

  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
  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
  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
  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
  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

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
  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

  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.
Received on Thursday, 12 March 2015 00:11:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:05 UTC