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

Feedback #95

Open
LeaVerou opened this issue Nov 17, 2020 · 2 comments
Open

Feedback #95

LeaVerou opened this issue Nov 17, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@LeaVerou
Copy link

As requested on Twitter. I’m opening an issue because Twitter is too painful for long form text.

My thoughts as I peruse the site, in no particular order:

  • Nice design, green on white is too low contrast though
  • Premise sounds nice, but takes WAY too long to get to the meat and show a demo or something. Lots of info about how to install before I even know if I'm interested.
  • Why do I need to run JS for a purely HTML API? This excludes a bunch of designers who aren't comfortable with JS. Just make the attributes work, automatically, at least for the bundle version. Use Mutation Observers to pick up new ones too. Provide manual control for people with demanding use cases.
  • Even the "how to use" section drills down into the nitty gritty of before it convinces me I need this. Not only that, but it tells me what I shouldn't do, before it tells me what I should do! And tells me off about something I haven't even done. WAT?
  • The entire documentation suffers from the curse of knowledge. You know what this does and why it's useful, so there is almost nothing about that. There is no tutorial, no description of the main concepts, only reference-style documentation, which is useful for non-beginners. Even the examples in the docs are essentially foo/bar type examples, not real use cases. What can I make with this?? It would be good to have small demos to illustrate how each attribute works and why it's useful. Or even link to a demo that uses it.
  • I'm now in the "Advanced" section. I do not understand what the headings are. Are they attributes? Oh, I see, they are attributes, some have values. What is a group? What is a radio group? Is it the name of the radios?
    I'm even more puzzled about how these work or why would I need them.
  • Typo: "and every attributes" --> "and other attributes". I'd suggest allowing users to customize the prefix including the data- part.
  • I'm not sure how data-toggle-trigger-off works. "Add this attribute to an element inside a target to enable it to toggle the state of this target. For example, a close button inside a modal." — Show, don't tell! Include a demo!
  • I do not understand the "Toggling combination" section at all. Neither what problem it's solving, nor how it's solving it.
  • I finally got to the demos!!! After everything else! Definitely move this section WAY up.
  • Switchbox eample: aria-hidden is not changed according to which label is visible. Is this something ETS can do? If not, why? If so, this would be a good way to showcase it.
  • How is the tooltip example better than CSS? It looks like aria-hidden is toggled here. How does that work? Some text about this would be useful.
  • Idea: Make ETS attributes clickable in demos, to take you to the reference for each attribute.
  • All of these demos are very component-y. It would be nice to provide some declarative HTML syntax to turn them into a web component without writing JS!
  • Dropdown doesn't appear to work. I can't select anything. (Chrome OSX v86)
  • "Even if you want to use X in some case you can't" is incorrect grammar. It's "cases".
  • The SVG focusable attribute is not implemented in most browsers.

Comments on attribute API

  • data-toggle-escape is a bit too constrained. What about data-toggle-key="Escape"? You just use evt.key in your JS, no need to have a dictionary of all possible key names.
  • Same with data-toggle-arrows, e.g. what if you want other keys for navigation or only horizontal/vertical arrows? Maybe data-toggle-navigation="arrows" or data-toggle-navigation="horizontal arrows" or data-toggle-navigation="vertical arrows" (also offers an extension point for other keys in the future).
  • What happens if conflicting triggers are specified? E.g. data-toggle-event is mouseover and data-toggle-escape is specified?
  • It would be nice if there was a way to make data-toggle-target relative to the current element, to avoid having to generate ids for repeated elements. Perhaps by the selector using & or :scope to represent the current element?
  • It might be good for data-toggle-target-next to optionally accept a value to define what the "next" element is, when it's not the next sibling.
  • What happens if I just data-toggle-class by itself? Might be a good default to assume the target is the current element itself. Wait, this is how it works, based on the checkbox element. Something to document then!

Overall, I think this is a nice library that could be useful for developing a variety of interactions without writing JS, but the documentation needs a lot of work to be user-friendly.

@Twikito Twikito added the enhancement New feature or request label Dec 20, 2020
@Twikito
Copy link
Owner

Twikito commented Dec 20, 2020

@LeaVerou Thanks so much for your feedback! 🙏

This library was initially thought for me to avoid writing always the same thing, and an excellent sandbox to improve my JS skills, and for my students for a first approach on writing interactible web pages without writing JavaScript.

Since your feedback, I've been focusing on improving the documentation, and I hope I've succeeded on this.
Please, tell me what you think of this new version of the documentation, hoping it will help you understand more easily what this library is about and how to use it.

About the API improvements, I think you're right on most of the suggestion. I will surely take care of more improvements and features.

Still, I have some questions:

Why do I need to run JS for a purely HTML API? This excludes a bunch of designers who aren't comfortable with JS. Just make the attributes work, automatically, at least for the bundle version. Use Mutation Observers to pick up new ones too. Provide manual control for people with demanding use cases.

What did you have in mind mentioning Mutation Observers?

All of these demos are very component-y. It would be nice to provide some declarative HTML syntax to turn them into a web component without writing JS!

Did you mean give the user the possibility to automatically create a reusable named component?

It would be nice if there was a way to make data-toggle-target relative to the current element, to avoid having to generate ids for repeated elements. Perhaps by the selector using & or :scope to represent the current element?

Yes, it could be great to give the parent or ancestor selector missing in CSS, but I don't really know how to do that the right way. Although, it will be probably possible in the next few months… hopefully.

Again, thanks very much for your feedback!

@LeaVerou
Copy link
Author

LeaVerou commented Jan 5, 2021

What did you have in mind mentioning Mutation Observers?

Mutation observers can help you observe changes to the HTML, so your syntax can be reactive to changes, without user code needing to be tightly coupled to it. E.g. they change the value of an ETS attribute and you just pick up the change with no further action required

Did you mean give the user the possibility to automatically create a reusable named component?

Yes, an actual custom element. E.g. <my-fancy-switch>.

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

No branches or pull requests

2 participants