Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard layout is unintuitive :( #2

Closed
ajwood-acquia opened this issue May 7, 2019 · 15 comments
Closed

Keyboard layout is unintuitive :( #2

ajwood-acquia opened this issue May 7, 2019 · 15 comments

Comments

@ajwood-acquia
Copy link

Can we use a table to force the button layout into a more natural layout? e.g. ergonomic left-handed programmer dvorak

@hagabaka
Copy link

hagabaka commented May 8, 2019

Why couldn't it just be a form with a text input?

@yrral86
Copy link

yrral86 commented May 8, 2019

A form could work... We just need a css selector for every possible message they might type...

input[value="a"]
input[value="aa"]
etc.

@cloudrac3r
Copy link

A text input box would work. But not in the way you're thinking.

First, have a text box with selectors that test for every letter and set the background image. Then, when the server resends the page to update the image URLs, also shift the current text box data into an element and make a new empty input box. So typing the next letter would appear to clear the text box and shift the letter into an element.

I don't see why this wouldn't work.

@HacKanCuBa
Copy link

Perhaps because nobody coded it yet? Go write some PRs!

@hagabaka
Copy link

hagabaka commented May 8, 2019

Well, what are your requirements? It says "async web chat using no JS whatsoever on the frontend", and you do have a backend. Is the page not allowed to navigate or submit? Is that what you mean by "async"?

@Clasen00
Copy link

Clasen00 commented May 8, 2019

Well, what are your requirements? It says "async web chat using no JS whatsoever on the frontend", and you do have a backend. Is the page not allowed to navigate or submit? Is that what you mean by "async"?

Maybe author mean by async that page doesn't reload when it send or get messages

@kkuchta
Copy link
Owner

kkuchta commented May 8, 2019

Yeah, the idea was definitely "no reloads." If we relax that and allow form submissions, it becomes a lot easier - none of the CSS nonsense is necessary. You just need form submission and chunked content delivery. In fact, check out Harmless, which is exactly that (not sure who built it). :)

@kkuchta
Copy link
Owner

kkuchta commented May 8, 2019

As for input[value="..."], I wish that worked. Unfortunately, that only matches on initial values of an input field - it's not recalculated as you type. Here's a quick example - try changing the text in the input to 'a' or 'c'. Nothing happens. :(

@GalvinGao
Copy link

As for input[value="..."], I wish that worked. Unfortunately, that only matches on initial values of an input field - it's not recalculated as you type. Here's a quick example - try changing the text in the input to 'a' or 'c'. Nothing happens. :(

We may use some workaround based on that too - after the initial value has been typed, the server will 'inject' a new set of style which uses the initial value as its prefix, e.g.:

  1. (initial) style: ... input[value="a"] input[value="b"] ...
  2. now user inputs a
  3. html changes to: <input value="a">
  4. server receives the a type
  5. (new injected) style: ... input[value="aa"] input[value="ab"] ...
  6. then just keep going

@kkuchta
Copy link
Owner

kkuchta commented May 8, 2019

How would you detect that the user inputted a? The value attribute selector doesn't ever respond to user input, as far as I can tell.

@GalvinGao
Copy link

How would you detect that the user inputted a? The value attribute selector doesn't ever respond to user input, as far as I can tell.

😅 didn't consider that problem. I tried to find some way to force the browser to recalculate the whole page's css, but as far as I can tell there's no way to do it in pure css.

@ThomasBower
Copy link

Why not use the [value$=...] attribute selector to capture the last character in the input box. I'm fairly confident you could use this technique to send requests as the user types in an input text box.

e.g.

If the input value is "h" then [value$=h] would match. Then if it's "he", [value$=e] would match, and so on. The only difficulty I foresee is multiple of the same letters in a row, but I suspect a similar technique to what is currently used might be able to work.

Additionally, if the input box gets unfocused every time the content gets updated, you could probably stick the autofocus attribute onto the input to avoid a clunky UX.

@David-Mulder
Copy link

David-Mulder commented May 9, 2019

@ThomasBower As was already explained twice [] in CSS are attribute selectors, not property selectors. The attribute is static, the property is dynamic.

Been brainstorming whether html form validation could be, so you could in theory have a regex rule which only allows anything but an a and based on the invalid state know an a was typed, but best I know that won't allow recognizing more than one letter.

@ThomasBower
Copy link

@David-Mulder Yep, my bad. I tested it soon after. Another idea would be to use different fonts and assign them to different characters as seen here.

@David-Mulder
Copy link

@ThomasBower yeah, that's definitely a smarter idea than mine xD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants