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

[CSSWG] Minutes New York F2F 2015-05-20 Part II: CSS UI 4: user-select, CSS UI 4: caret styling, Future Meetings

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 20 Jun 2015 08:40:44 -0400
Message-ID: <CADhPm3vt=cTsz+XdMyWSP5FxpNFbvn+E1oRXy8OvpbG08XsekQ@mail.gmail.com>
To: www-style@w3.org
CSS UI 4: user-select

  - RESOLVED: Keep the name "text" in user-select
  - RESOLVED: Selection stops at the boundary of the
              user-select:none element, when dragging from outside
              to inside.
  - Florian will come up with a proposed resolution for the working
      group's approval for user-select:none being included or not
      when selecting across.
  - RESOLVED: Keep spec-text for user-select:element as is, unless
              we uncover platform differences.

CSS UI 4: caret styling

  - Wrt caret styling, leaverou brought her proposal to use a
    pseudo-element in place of caret-specific properties.
      - The main problems with the current caret-blink-time proposal
          * only two values (auto and 0) appear to be useful
          * setting to 0 is required to set a custom animation
          * the UA stylesheet cannot use an animation due to the way
            standard animations cascade
      - However, it was pointed out that regular CSS properties
        cannot express the caret color or shape, and that most other
        properties can't apply because the caret is OS-generated, so
        special properties are needed anyway.
      - It was proposed to instead replace the caret-blink-time
        property with a caret-animation property, which accepts
        keywords for the common cases (e.g. 'auto' or 'blink' for OS-
        default blinking) and also accepts a CSS animation name. CSS
        animation syntax could then be used to control 'caret-color'
        for create custom animations.
    - Florian will explore these ideas further.

Future Meetings

  - Everyone was reminded to book now for August and book soon for
  - The current proposal is to do Sydney in winter 2016 with Houdini
      30/31-Jan, CSS WG 1/3-Feb, SVG 4/5-Feb.
  - The west coast of the US was discussed for both May and August
      2016, but dates are waiting on locations and dates for AC
      meetings as well as other May meetings.

===== FULL MINUTES BELOW =======

  Scribe: fantasai

CSS UI 4: user-select

  <Florian> http://dev.w3.org/csswg/css-ui-4/#content-selection
  Florian: Starting with user-select.
  Florian: This existed a long time ago, in precursors of UI.
  Florian: It disappeared, but got implemented anyway. There's a
           fair amount of interop, but not complete, and this spec
           is trying to work out the details.
  Florian: Several values, some of which have near-universal
           agreement, some less so.

  Florian: Basically everyone supports "text" and "none" with close
  Florian: "all" is also widely supported, maybe not all browsers.
  Florian: "element" is supported in IE, but everyone shows "element"
           -like behavior when selecting things inside of an
           editable area.
  Florian: "element" means if you start a selection inside the
           element, it'll be trapped to inside of it. This is
           standard <input> behavior.

  * tantek looks for last time user-select was in a TR draft
  <dbaron> tantek, http://www.w3.org/TR/2000/WD-css3-userint-20000216#dynamic
  <tantek> dbaron wow that old
  <tantek> I thought it made it further

user-select: none

  glazou: There's an issue before issue 20.
  glazou: Says that if a descendant of user-select:none is not
          user-select:none, it should be selectable. This is
          tremendously important for template-based editing.
  glazou: I'd like it to be marked with a note giving this as the
  <leaverou> Another use case is to prevent user selection interfere
             with dragging.

  Action Florian to add a note to user-select:none about it's use in
         template-based editing.
  <trackbot> Created ACTION-690

user-select: auto

  Florian: "auto" is also interesting. In IE, property isn't
           inherited, but in most cases, "auto" resolves to
           inheriting. Some cases it doesn't, like if parent is
  Florian: Similarly, Mozilla doesn't inherit this into abspos
           elements, presumably because they're significantly out-of-
  Florian: But it lets floats inherit.
  Florian: So I've currently specified this as non-inheriting, with
           "auto" most of the time causing inheritance except for
           some exceptions explicitly listed.
  Florian: This is a mix of IE and Firefox behavior.

user-select: text

  Florian: Next issue - "text" value is strangely named. It doesn't
           restrict you to selecting text.
  Florian: It just lets you select anything.
  Florian: The WK docs say that "text" only selects text, and "auto"
           selects everything, but that's not true - "auto" computes
           to "text".
  Florian: So it's confusing enough to confuse document writers. But
           it seems like it's probably too old to change the name.
  tantek: That's my fault. I gave it a bad name.

  Florian: So even though the name is unfortunate, I'd like to
           resolve on keeping it.
  glazou: You can just turn the issue into a note.
  tantek: You can add an alias.
  Rossen: I don't think the alias will really help anything.
  tantek: One benefit of an alias is that we might be able to
          compute the old value to the new one, so we only expose
          the better name.
  Florian: Maybe, depends on how much script is already depending on
  tantek: We could have it select text, and "may" select otherwise.
  TabAtkins: No.
  fantasai: Let's not introduce ambiguity for a naming dispute.

  RESOLVED: Keep the name "text"

user-select: none (cont.)

  Florian: Next value is "none".
  Florian: Everyone agrees if you start inside the element - don't
  Florian: We disagree if you start outside.
  Florian: First is start outside, drag into it.
  Florian: My proposal is to stop at the boundary of the element.
  Florian: I think this is Firefox's behavior, and Chrome's behavior
           half of the time.
  glazou: I think this matches what the user expects.

  RESOLVED: Selection stops at the boundary of the user-select:none
            element, when dragging from outside to inside.

  glazou: Imagine you click on the inside of the user-select:none,
          and you drag outside. Do you select the stuff outside?
  tantek: That drag-out won't every do anything; like clicking down
          on a button and then dragging out.

  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20-moz-user-select%3A%20none%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3EThis%20is%20%3Cspan%3Esome%3C%2Fspan%3E%20text.%3C%2Fp%3E
  <dbaron> (or change to -moz-)
  <dbaron> or, better:
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20-webkit-user-select%3A%20none%3B%20-moz-user-select%3A%20none%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3EThis%20is%20%3Cspan%3Esome%3C%2Fspan%3E%20text.%3C%2Fp%3E
  <dbaron> (I'm seeing Gecko and Blink match on that testcase.)

  Florian: When selecting across, this is more complex. Some
           browsers support multi-ranges, some doesn't. Mozilla
           does, Webkit/Blink doesn't.
  Rossen: I think IE does.
  Florian: But the HTML Editing spec (by Aryeh) specifically forbids
  Florian: So my proposal is that if you support multi-ranges, and
           drag across, the selection skips the "none".
  Florian: If you don't support multi-ranges, the selection includes
           the "none" when you select across.
  glazou: I think I commented on that draft a while ago. You need
          multi-selection for editors.
  Florian: Agree, but this spec isn't taking a stance.
  tantek: I think as long as we specify what happens when you have
          multi-ranges, we're okay.
  glazou: Agreed.

  Florian: Subtlety: selections and copying might be different. A
           single-range selection might not copy the "none" text; at
           least, it's possible.
  TabAtkins: I'm also seeing Chrome implement the same as Firefox.
  Florian: But in Chrome the part in the middle is in the selection,
           it's just not highlighted.
  Florian: The visible selection doesn't cover the "none" in Chrome,
           but if you copy the whole thing shows up.

  <dbaron> [Tantek and glazou disagree about which behavior is

  tantek: That's intentional. I wrote "none" to support the ability
          to select across a "none".
  glazou: I disagree. As an editor author, I prefer something that
          actually skips the "none" content.
  Rossen: Maybe a second value, so both are possible.
  glazou: That sounds good to me.
  tantek: I'm okay with that. I think "none" should keep the current
          behavior, where selecting across a "none" does copy things.
  dbaron: There's been enough requests, and moz has "none", "all",
          "-moz-none", and "-moz-all", and they're four different
  Florian: I think "none" and "-moz-none" used to be different, but
           they've since merged.
  <dbaron> -moz-user-select: none and -moz-none differ in whether
           they can be overridden by other values on descendants

  glazou: So do you agree to investigate the possibility of a second
          value that actually skips elements?
  Florian: Where the new value acts the same as "none" in
           single-range browsers?
  glazou: Yeah.
  <tantek> glazou, I am ok with an additional value that means don't
           include user-select:none elements inside the selection
  Rossen: Why this exception?
  Florian: Because it's impossible for a single-select browser to
           implement it properly.

  RESOLVED: selecting across a user-select:none actually does select
            the contents. Add another value that actually excludes
            the content, in browsers that support multi-selections.

  tantek: I think it makes more sense for the split to be at "text"
          vs "all-text", which controls whether "none" gets skipped
          or not inside of it.
  glazou: I can live with that.
  Florian: So I suggest we don't resolve on the names, you just
           action me to figure this out.

  RESOLVED: Rescind previous resolution.

  Action Florian to come up with a resolution for user-select:none
         being included or not when selecting across.
  <trackbot> Created ACTION-691

user-select: element

  Florian: Next is about user-select:element
  Florian: First is bikeshedding - "element" might not have a lot of
           usage, so maybe changeable, and I hate "element". Maybe
           "contain" or "inside"?
  tantek: Note that all impls are prefixed, so we're probably okay
          with changing anything.
  Florian: Maybe, maybe not. Might be a unprefixed "future proofing"
           in use. But I think it might be okay.
  Florian: Firefox parses it, but doesn't do anything with it.
  <tantek> unlikely that autoprefixers are being used with this - as
           this property was DROPPED over 15 years ago
  <tantek> before any autoprefixers were even a gleam in anyone's eye
  <leaverou> tantek: Autoprefixers generally work with what browsers
             support, not what's in the spec. Some of them don't
             even use a list of properties, they directly get them
             from the CSSOM.
  <tantek> leaverou: autoprefixers DID NOT exist when this property
           was dropped
  <leaverou> tantek: Dropped from *where*? It is supported today, by
             several UAs and has been for quite some time.
  <tantek> leaverou: from any visible spec
  <tantek> you have to work hard to find it anywhere
  <leaverou> tantek: Exactly. I’m telling you that as far as most
             autoprefixers are concerned, this doesn't matter.
  <leaverou> tantek: Autoprefixer prefixes all values it seems.
             Check this out: http://codepen.io/leaverou/pen/aOmvJx
             (inspect <body>)

  Florian: But I don't want to spend a lot of time bikeshedding.
           Let's move on.
  Florian: Same issue as "none" applies here. When selecting out->
           in, or across.
  TabAtkins: Just do the same as <input> currently.
  Florian: I think some browsers differ on whether they select the
           element as soon as you move in, or wait until you select
           completely across.
  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0Afoooooo%3Cinput%20value%3D%22some%20text%22%3Ebarrrrrrrr
  TabAtkins: Chrome, at least ChromeOS, doesn't select until you go
  Florian: I think I've specced that behavior.
  [Looks like IE agrees with Chrome.]
  <Florian> Proposed resolution: keep the spec as it is

  RESOLVED: Keep spec-text for user-select:element as is, unless we
            uncover platform differences.

user-select: none (cont.2)

  glazou: A while ago, user-select:none on an element inside
          user-select:all wasn't working.
  Florian: I think I'm actioned to figure this out, per tantek's
  Florian: What did you suggest?
  glazou: It shouldn't select.
  dbaron: This is actually what none vs -moz-none is for; whether it
          can override a parent selection mode.
  <dbaron> and all vs. -moz-all
  Florian: I'll keep it in mind when drafting a proposal.
  <dbaron> I think
  <glazou> right

<br dur=15m>

CSS UI 4: caret styling

  leaverou: caret-color in CSS UI.
  leaverou: Many more properties in L4
  Florian: Two.
  leaverou: caret-shape and caret-blink-time
  leaverou: Right now, authors need to learn another thing for
            blink time.
  leaverou: But for more control, you need to set it to zero and use
            a CSS animation over caret-color.
  leaverou: Would prefer authors didn’t have to learn more
            properties that duplicate existing functionality,
  leaverou: So suggest a pseudo-element.
  leaverou: Use CSS Animations in the UA stylesheet.
  leaverou: Instead of using entirely different mechanism for
  leaverou: Can't do that without a pseudo-element.
  leaverou: Because if there's an animation in the UA style sheet
            that controls how the caret animates, then any author
            animations will override that,
  leaverou: and the caret will stop animating.
  leaverou: But with a pseudo-element, wouldn't have that problem.
  leaverou: Caret is in the paint tree, not in the DOM.
  leaverou: So could be a problem to have pseudo-element.
  leaverou: I don't think from author's perspective, they don't care.
  leaverou: For them it's a separate visual element,
  leaverou: so better to have as a pseudo-element.

  TabAtkins: What element would it be attached to?
  leaverou: The element that is being edited.

  dbaron: Caret is special in a bunch of ways.
  dbaron: Fits into CSS painting model very oddly.
  leaverou: Authors don't see/care about that. Just syntax.

  Florian: Been thinking about this a bit.
  Florian: I agree with your general statement about animations.
           Learning multiple ways to animate something is
  Florian: And we can't use animations in the UA style sheet unless
           we have a pseudo-element.
  leaverou: Also, if in the future we want to add more things to
            control, with a pseudo-element we wouldn’t need to add
            even more properties.
  Florian: However, some of these other things can't be done with
           regular properties.
  Florian: Initial color of the caret can't be expressed,
  Florian: Shape of caret is its own thing.
  Florian: Interaction is complicated.
  Florian: Initial value of caret is "give me good contrast", not
           necessarily currentColor.
  Florian: color/background-color do not have this value.
  leaverou: There's a CSS4 color modifier that gets you sufficient
  Florian: Can't ask for sufficient contrast with background and
  Florian: Case that's important is block caret.
  Florian: Don't want the caret to disappear.
  Florian: Presto and IE do color inversion.
  Florian: Don't expect that for all browsers, but should be
  dbaron: Gecko used to implement, but no longer made sense in new
          graphics architecture.

  leaverou: For block caret, width auto will adjust the width.
  leaverou: There are 3 shapes in UI4 - auto (usually bar), bar,
            block, underline.
  Florian: Auto allows flipping into block for insertion mode, e.g.
  leaverou: Could make the bar thicker if you want it thicker.
  <ChrisL> 4 values - auto, bar, block, underline
  Florian: The only use case I've seen for setting width explicitly
           is trying to get a block.
  leaverou: Don't think it's wise to add more if we can use existing
            CSS properties
  Florian: There are properties that are close, but not quite. Color
           is close, but not quite. Shape can't be done with existing

  fantasai: Blink time.
  fantasai: What values does blink time take?
  Florian: Mostly useful values are auto and 0 (don't blink).
  Florian: If you want to adjust, use animations.
  fantasai: What animations are needed?
  Florian: Color fading between light / dark blue
  Florian: appear/fade-away
  Florian: Can do all of that with animations.
  leaverou: Would need to reinvent animations.
  leaverou: Also confusing that the blink is turned off, and some
            other code turns it on.
  leaverou: Doesn't seem very usable to me.

  TabAtkins: In at least IE and probably Chrome our caret is
             OS-drawn, so amount of control we have is fairly
  TabAtkins: Can change color, can change blink frequency, can only
             swap between the shapes that are allowed by OS.
  TabAtkins: So the properties here are as much as we can do.

  Florian: I've tried to define shape, specifically block and
           underscore shape, to do something sane wrt the glyph size.
  Florian: Might not be possible. Could put as should rather than
  Florian: Requirement to match OS controls is also a reason for
           this definition.
  TabAtkins: Even color and width might not be able to fully apply.

  fantasai: I agree with having just the limited set of properties.
  fantasai: Because of the OS integration, the difference in values,
            all the reasons mentioned.
  fantasai: Also because pseudo-elements add a lot of complexity,
            and I don't think it's worth it in this case.
  fantasai: I do think the blink-time property needs improvement.
  <smfr> blink time is system-controlled. why should authors be able
         to change it?
  fantasai: The only thing you can animate is the color, really.  I
            would suggest defining the animation using the standard
            animations syntax, but invoke it with a special caret-
            animation property.
  fantasai: That way it won't interfere with regular animations, you
            won't have the cascading problem, but you can still use
            the standard animation syntax.
  fantasai: And we can have keywords for the common cases.
  fantasai: That would allow both controlling the blink time, also
            animating between blue and dark blue, as mentioned.
  Florian: I'm happy to explore something along the lines of what
           fantasai said.

  Florian: Before we move on to next topic, want to draw
           implementers attention to another point:
  Florian: I'm specifying how painting can work.
  Florian: Since there are system-specific restraints, not being
           super precise.
  Florian: But trying to define in a way that's not useless.
  Florian: Please look at spec and tell me if you can do that.

  Bert: Doesn't say what caret looks like when not focused.
  Bert: Might be same color but not blink, or less bright color, or
        something like that.
  Florian: I went with assumption that if not focused, don't show
  Bert: Want to show where you were typing before in unfocused
        window, but should still show some shape.
  plinss: In OS X the terminal window will change from solid box to
          open box.
  Florian: Will look into existing behavior, bring up to group
  plinss: Concerns me that we're adding more and more things that
          would be trivial by adding pseudo-element.
  Florian: I'm not sure pseudo-element is so trivial.

CSS UI 4: Future Plans

  Florian: Unless we want to go into 'appearance', that's it for UI4.
  Florian: So far I've been speccing things I've wanted, and things
           people have asked for.
  Florian: Not at FPWD yet, but getting closer.
  Florian: If something else should be in here, let me know.

  Florian: I might add a focusable property.
  Florian: This relates to directional nav-up/down etc.
  Florian: If you say next item in navigation is an unfocusable
           item, then it becomes focusable.
  Florian: You might want to target that element, but focus the next
           (in dom depth traversal) focusable element.
  TabAtkins: Investigating similar things with Shadow DOM.

Future Meetings

  <dbaron> https://wiki.csswg.org/planning
  glazou: For next meeting, suggest you book your flight ASAP.
  Rossen: Houdini is also confirmed for 2 days after CSSWG meeting.
  SimonSapin: Please add your name if you are coming,
  SimonSapin: On both wikis if you are coming to both.

  glazou: Next meeting after is Sapporo in Japan.
  glazou: There are plenty of small AirBnB flats nearby, found one
          for ~30 euros per night,
  glazou: within walking distance from venue.
  glazou: In terms of flying to Sapporo, you will have two choices.
  glazou: Buy tickets through large airlines, or choice of low-cost
          airlines within Japan.
  glazou: But hard to find if you try to find through regular
          reservation search.

  plinss: Group of people are arranging a road trip. Also pre-TPAC
          scuba diving in Okinawa. So if interested, let me know.
  Florian: I suggest considering also the train.
  Florian: Great ticket you can only buy from outside Japan that
           gives you unlimited rides in Japan.
  <Florian> "Japan Rail Pass" gives you unlimited train for a set
            period of time for a good price (Including all but the
            fastest shinkansen).

  glazou: Going to meet first days of the week: Mon-Tues.
  glazou: Plenary meeting on Wednesday.
  glazou: Originally scheduled to have 30 seats only.
  glazou: Suggested that 30 is probably not enough, if we include
          observers. Closer to 35/40.
  glazou: They will try to change the room if possible.
  Rossen: FX meeting?
  * ChrisL requests FX during Thursday-Friday

  glazou: Next meeting proposal is for Sydney.
  shane: There were some concerns about prices of lodging in Sydney.
  shane: The suggested hotels were quite expensive.
  shane: I wanted to share research with you.
  shane: Flights to/from Sydney from SF stopping in Fiji ~$1200/$1300
  shane: from Paris ~ 800 euros
  shane: If we resolve on dates, and price-sensitive ppl book soon,
         should be affordable.
  shane: wrt accommodation, booking.com has hotels for as low as
         $60/night USD.
  shane: Not super-close to venue, but in the city, so easy to get
  shane: Also lots of deals on AirBnB places.
  shane: 3-bed range from $250/night up.
  TabAtkins: Place we stayed is now $600.
  SteveZ: We used a serviced apartment near the park.
  SteveZ: It was really nice. 44th floor, looking at city.
  shane: I can't do anything about the length of time to get there,
  shane: or about the jet lag.
  iank: But we have lots of caffeine. Would make everyone coffee.

  glazou: Okay, let's look at dates
  [discussion of dates]
  SimonSapin: FOSDEM is first week of February.
  [discussion of when FOSDEM might be]
  [juggling dates]
  <dbaron> plinss, when is the TAG meeting around then?
  <plinss> jan 19-21

  CSSWG Feb 1-3 (M-W)
  Houdini Jan 30-31 (Sat Sun)
  SVG Feb 3-5 (W-F)
  FOSDEM expected on the 6th/7th
  shane: also possible to shift forward by 1 day
  <dbaron> https://wiki.csswg.org/planning/sydney-2016
  <glazou> PROPOSAL is Houdini 30/31-jan, CSS WG 1/3-feb, SVG 4/5-feb

  glazou: Next meeting after that...
  glazou: TPAC was US West Coast
  glazou: Then we did Australia
  glazou: US East Coast
  glazou: Paris
  glazou: Japan
  glazou: Australia
  dbaron: TPAC 2016 likely to be Europe
  glazou: Likely to have one of the meetings in between Australia
          and TPAC 2016 to be US West Coast.
  Proposal for San Diego in May
  SteveZ: Adobe can also host in San Jose or SF
  <tantek> SF is preferred by SF residents :)
  <astearns> SF is preferred by non-SF residents
  <glazou> SD is preferred by some non-US residents too
  <liam> [if anyone is interested in meeting alongside
         libregraphicsmeeting.org in London next May there's
         apparently meeting space]
  dbaron: Probably want to wait on solving dates, to sort out AC
          meeting etc.
  [Aiming for May, details later]

  [discussing locations for August]
  <fantasai> If TPAC is in Europe, then maybe move West Coast to
             August and West Coast in May
  dbaron: Suggest waiting for locations of AC meetings
  dbaron: Also other conferences in May, may or may not have dates
          for those yet.

Received on Saturday, 20 June 2015 12:41:19 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:51 UTC