CSS blueprints

[woylie]

Provide basic CSS examples for the essential styles of each component (e.g. rules for conditionally hiding elements depending on their attributes).

[ahacking]

I have been looking at the html structures required to implement CSS on top of headless UI for Pheonix and it appears to be a very difficult problem without requiring client side Javascript.

Two examples of CSS libraries are worth looking at, the first being Preline CSS. Quite a nice looking tailwind based "copy paste" framework supported by a JS plugin for all of the reactive parts.

The other is Ripple UI which takes a zero JavaScript approach and also based on Tailwind with a radix based color theme and a lot less tag soup.

The interesting thing is that to implement the reactive parts without JS (as Ripple UI does) would require a different HTML structure, in particular use of checkbox inputs and "label for" to implement JS free show/hide toggles.

Have you considered your approach for client side reactivity? Will it require unnecessary JS like the Preline approach or will you adopt a more JS minimalist approach like Ripple UI?

Will you consider accommodating different HTML structure that supports the Ripple UI approach?

When looking at adopting Doggo I do want all the a11y semantic goodness but I also want markup that doesn't require unnecessary JS or tailwind tag soup but still allows utility classes for special cases (more from app overriding library than by the library itself).

Ripple UI looked to be a good starting point to adapt to Doggo aside from the current show stopper on not having a strategy or markup that supports responsiveness without JS.

Interested in your thoughts and planned approach.

[woylie]

Have you considered your approach for client side reactivity?

Interactivity will be implemented with Phoenix.LiveView.JS where possible. The new toggle_class and toggle_attribute functions in LiveView 0.20.4 should cover most of the needs, except for more complex components that require keyboard interaction with multiple active keys on a focused element. These more complex cases will likely need to be handled with Phoenix hooks.

Will you consider accommodating different HTML structure that supports the Ripple UI approach?

I'm mostly following the APG patterns. Toggling visibility with checkbox hacks isn't great from an accessibility perspective. In general, the aim is to use semantic HTML and appropriate role and aria attributes, and to use the appropriate attributes to reflect state (e.g. the aria-expanded attribute for a toggle button).

[ahacking]

Thanks for clarifying the toggle hack vs APG. Agree.

I did some testing with the Ripple UI label/checkbox hack approach for menu expand toggles and adding tabindex="0" so that TAB / SHIFT+TAB focus could work and I did experience some issues. So I agree this is not the best way forward.

Some JS is a worthwhile tradeoff for accessibility and it doesn't mess with the APG patterns/structure.

On this aspect of component JS I was wondering if you have any opinions/thoughts on imolementing all of the element JS within hooks (given keyboard handling is inevitable for many components) and using websocket.execJS to achieve the same effect as what would be done with JS.foo(). My thinking is this should help keep the html markup cleaner than decorating every element instance with phoenix JS attributes.

I also like the strategy of using element and attributes as the primary selector for applying style and only using class names as a last resort to selecting styles.

Cleaner html wherever we can achieve it is preferred.

[woylie]

On this aspect of component JS I was wondering if you have any opinions/thoughts on imolementing all of the element JS within hooks (given keyboard handling is inevitable for many components) and using websocket.execJS to achieve the same effect as what would be done with JS.foo(). My thinking is this should help keep the html markup cleaner than decorating every element instance with phoenix JS attributes.

That's an interesting idea, I haven't thought about that yet. We can look into this kind of optimization once we have a working version.

[woylie]

I did some testing with the Ripple UI label/checkbox hack approach for menu expand toggles and adding tabindex="0" so that TAB / SHIFT+TAB focus could work and I did experience some issues. So I agree this is not the best way forward.

Basic interactivity and keyboard support are not the only issue. The question is also how these components are announced by screen readers, and my guess is that a label/checkbox implementation would be rather confusing.