- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 20 Jun 2015 08:40:44 -0400
- 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
are
* 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
October.
- 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
agreement.
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
use-case.
<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
"element".
Florian: Similarly, Mozilla doesn't inherit this into abspos
elements, presumably because they're significantly out-of-
flow.
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
it.
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
select.
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
multi-ranges.
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
better]
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
things.
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
range.
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
across.
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
suggestion.
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
animation.
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
unfortunate.
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
contrast.
Florian: Can't ask for sufficient contrast with background and
foreground.
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
possible.
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
properties.
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
limited.
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
must.
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
caret.
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
transport.
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
Proposal:
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.
[lunch]
Received on Saturday, 20 June 2015 12:41:19 UTC