[css-ui-4] Feedback before f2f

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-ui-4] Feedback before f2f

Tab Atkins Jr.
Sorry for the generic title, but this feedback crosses across the spec. :/

We (Chrome team) reviewed UI 4 in preparation for the f2f, and have a
few bits of feedback.

1. We should just drop caret-blink-time.  We don't think there's any
actual use-case for controlling this in the first place, and doing so
is an accessibility issue (blinking things too rapidly).  Also, we're
not sure this is actually controllable in OSes.  If you really feel
like screwing with the user, you can do it by flashing caret-color.

2. We should keep 'appearance' limited to just "auto" and "none"
values.  "button" is going to be hard/weird to apply arbitrarily, and
it's not clear the use-case is strong here in the first place.  If you
want something to look like a button, use a <button>.

3. We support changing the name of the "element" value for
'user-select'.  We're happy with the "contain" idea.

4. Can we change the "text" value too?  Maybe to "contents"?  This
value means you can select everything, not just text, so the current
name is weird.

5. We're okay with the text about "user-select:none" and its
application to editting, but are concerned that this isn't the right
spec to talk about this.  Is there an "editting" spec that can talk
about this?  The Editing TF just happened - anything come out of that
we can move this to?

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-ui-4] Feedback before f2f

Florian Rivoal-4

> On 24 Aug 2015, at 12:30, Tab Atkins Jr. <[hidden email]> wrote:
>
> Sorry for the generic title, but this feedback crosses across the spec. :/
>
> We (Chrome team) reviewed UI 4 in preparation for the f2f, and have a
> few bits of feedback.
>
> 1. We should just drop caret-blink-time.  We don't think there's any
> actual use-case for controlling this in the first place, and doing so
> is an accessibility issue (blinking things too rapidly).  Also, we're
> not sure this is actually controllable in OSes.  If you really feel
> like screwing with the user, you can do it by flashing caret-color.

I agree, I am just late updating this. I will drop caret-blink-time. We should just have "caret-animation: auto | blink | none | fade", as discussed on the other thread. I'll try to have the spec updated for the meeting.

> 2. We should keep 'appearance' limited to just "auto" and "none"
> values.  "button" is going to be hard/weird to apply arbitrarily, and
> it's not clear the use-case is strong here in the first place.  If you
> want something to look like a button, use a <button>.

I'm probably ok with this, but I need to think. I am not strongly attached to the button value, but I think the underlying model I have is sound when it comes to values other than auto and none, and should any browser want to add extra values, even if these values are not in the spec, I think it would be good if they followed that model.

Let's discuss at the f2f.

> 3. We support changing the name of the "element" value for
> 'user-select'.  We're happy with the "contain" idea.

Done.

> 4. Can we change the "text" value too?  Maybe to "contents"?  This
> value means you can select everything, not just text, so the current
> name is weird.

Unlike "element", this is an old value supported across the board, so I doubt we can actually change it. You should have more data than me about whether that's doable.

If we actually can, I agree the name "text" is bad. I am not sure about "contents", as I think it would be easy to confuse with "contains". Maybe "normal".


> 5. We're okay with the text about "user-select:none" and its
> application to editting, but are concerned that this isn't the right
> spec to talk about this.  Is there an "editting" spec that can talk
> about this?  The Editing TF just happened - anything come out of that
> we can move this to?

The discussions in the Editing TF means that maybe we don't need this note
anymore at all, as js authors will be empowered to implement which ever behavior they want for deletion, making sure they can get this. I'll explain at the f2f.

 - Florian



Reply | Threaded
Open this post in threaded view
|

Re: [css-ui-4] Feedback before f2f

Brad Kemper
In reply to this post by Tab Atkins Jr.


> On Aug 24, 2015, at 3:30 AM, Tab Atkins Jr. <[hidden email]> wrote:
>
> 2. We should keep 'appearance' limited to just "auto" and "none"
> values.  "button" is going to be hard/weird to apply arbitrarily, and
> it's not clear the use-case is strong here in the first place.  If you
> want something to look like a button, use a <button>.

While I don't personally feel strongly about 'appearance: button' specifically, I wish we could stay away from this "just change the source" reasoning. A lot of us have separate people writing the source code, not the CSS authors. We can't just ask them to change hundreds of pages where they might have something like '<a role=button>' because we want it to look like an OS button. There is such a thing as separation of concerns.
Reply | Threaded
Open this post in threaded view
|

Re: [css-ui-4] Feedback before f2f

Sebastian Zartner-3
In reply to this post by Tab Atkins Jr.
On 24 August 2015 at 12:30, Tab Atkins Jr. <[hidden email]> wrote:
> 1. We should just drop caret-blink-time.  We don't think there's any
> actual use-case for controlling this in the first place, and doing so
> is an accessibility issue (blinking things too rapidly).  Also, we're
> not sure this is actually controllable in OSes.

FWIW Windows allows to control the blink rate. See
http://thewindowsclub.thewindowsclubco.netdna-cdn.com/wp-content/uploads/2012/12/cursor-speed.jpg
for a screenshot.
But I agree that this is not something an author needs to have control over.

Sebastian