The toolbar should be usable without JS

And here we are back to discuss button html tags for menu items which contains sub-items ))

So yes, obviously we have to provide good support for disabled js case -> in that case there should be no button html tags for the parent menu links. Should be links instead. So i'm currently thinking what to do when js is enabled? Replace parent menu links by button html tags from js?

Actually not really clear which exact behavior you wanna have. On mobile we have burger button to expand/collapse navigation. Currently it's button HTML tag.

I just checked behavior of Toolbar core module under Drupal 11.x -> this burger element is an actually link. So with disabled js it is currently impossible to interact with toolbar. When user with disabled js will click on toolbar's burger element -> he will be redirected to /admin page and that's it.

With new navigation what do you plan to have? Obviously behavior described above (with current core module Toolbar) is a kind of easy to implement & will not take a lot of time. However - we can try to display full toolbar on desktop even with disabled js. But what to do on mobile

Expected behavior when no JS:

• Desktop: the menu should stay on a region on the left (right on rtl), scrollable. If the sub-menus are all opened by default or collapsible with any valid HTML native tag that makes sense I'd leave it open to whoever implements it. So the goal is to navigate with the sidebar, no clicking on admin lists.
• Mobile: The menu list should be collapsible and be printed on top of the content. There are several solutions out there, specially for heavy content menus. So I'll leave the implementation to whoever takes this on.

The existing markup implementation hasn't taken the no-js situation into account so far because the goal was to have a working prototype fast to test it. So now we are at the point where we can change and improve the markup, but ideally not the functionality (for example no link on the top menu) since that has been tested. So feel free to suggest improvements :)

@kostyashupenko I hope I solved the questions!

Well, this is POC. Still not sure what to do with mobile view. Currently there is pretty similar behavior to desktop > we are displaying everything at once. Maybe we can provide some kind of checkbox? Like in old days. This checkbox could be "Expand sidebar" on mobile. Once it's checked we can display a whole navigation. By default checkbox is unchecked. CSS selectors we can use are. What do you think?

input.my-checkbox:checked + .some-toolbar-container {}

Also -> parent menu links are not buttons anymore. It is always links (just because for no-js solution we have to let user click even on parent menu link, otherwise it will be just a text. So here i tried to simulate Drupal core toolbar no-js behavior. But it's still to be discussed.
Currently links which contains sub-menu items has attribute role="button"

Desktop no js:

Mobile no js:

Thanks @kostyashupenko!

I'd say the desktop implementation looks great as a POC the way you did it. I'm not sure about using links on the parent, but maybe it makes sense because of what you're saying for now. I'll try to bring it up on the weekly meeting we have today to gather more opinions (about the link itself, the rest looks great).

For the mobile, I remember using the checkbox implementation some time ago. I haven't done any research to see if there is any newer/better way so the checkbox makes sense to me unless someone comes up with a better proposal :)

I'll leave as NR so it gets the attention from others.

Rebased and added checkbox to trigger menu visibility on mobile. Checkbox and its associated label are hidden on desktop.

I haven't yet tested this out, but I'm concerned about using the html.js method for styling without JavaScript. This can lead to a flash of unstyled content and perception that the content is jumping around on page load.

A better way to do this would be using https://developer.mozilla.org/en-US/docs/Web/CSS/@media/scripting. Note that it won't be available on Chrome for 2 more versions (120) but it is available in FF and Safari. By the time this toolbar becomes stable, this feature will be stable.

We just discussed this in Slack with @mherchel and @bnjmnm, and the approach should go with @mherchel 's proposal in #9 even thought it's still not fully supported.

So moving this to NW to adjust the approach to use @media (scripting: none).

Attempted to rebase with version 1.x, but encountered numerous conflicts in CSS files. Deciding to leave it for a front-end developer to address.

On desktop, the menu items appear to be displayed and functioning correctly with JavaScript disabled. However, identified an issue where menu items are not shown as active.

Thanks.

I am picking up some work for this.
#11- indeed this current branch is aged and not up-to-date with general line of work. lots of changes from main line (over last 5mon)..

@ckrina (& @mherchel and @bnjmnm). re: use of @media (scripting: none)
i do have some worry around using this method. it is indeed still 'very new'. what is core's support suppose to be for this then? indeed, this is an exciting method, of course there is no polyfill for it and is not indented to be used as a replacement for

#6 'working degrade' notes around using input. --> likewise button:checked css will also allow for some. if there a pref around this? seems Input needs matching id's (not the largest concern directly). as we're in a state without 'js aria changes' i'm not clear on what may be expected around this..

https://www.drupal.org/docs/system-requirements/browser-requirements#s-s... →
[#2779179]

https://caniuse.com/?search=scripting

-> Samsung Internet (last 2 versions) does not support this method.

@SKAUGHT you killed me :D

Ok, let's think this: the specific styles for the non-JS situation would go inside @media (scripting: none). So a user that navigates with Samsung Internet browser AND wouldn't have JS enabled would be the only user affected (the rest of Samsung users would use the default styles). Samsung Internet accounts for a 2.65% on Feb 2024. And the percentage of them without JS will be really small.

So I'd the work here with @media (scripting: none) because we see the non-JS functionality as not critical, and if we see it ends up causing too many problems we can port it to <noscript> afterwards. But at least we'll already have the styles in place.

Also, about #13: "this current branch is aged", feel free to open a new branch, import what you need from the old one and hide it. If a clean state helps after so much time feel free to do so.

And I also don't have an answer for the non-js without 'js aria changes'. Just keep in mind that whatever is done here is better that what we have right now, that doesn't work without JS. So we could go with one solution and improve it later in a follow-up.

I would favour this new method too, simply. As we know we can only follow requirements from above (:

#9

I haven't yet tested this out, but I'm concerned about using the html.js method for styling without JavaScript

the problem here is that drupal rely in script to add this to the page, then of course it cascades down.
-> the other side of this technique would be to reverse the js lag by using 'nojs' that is actually in the html output and once js triggers than removes the nojs class (than 'has-js'). Secondly, not on the html tag for the class but the outer most wrapper of our Navigation block (rely on the content we product not what 'something already did to the page' (we understand this is widely added by drupal.js for us.)
...funny to see how techniques spread, become their own usual.

@mherchel. could this be the other side of this question? .nojs to start VS .js added after page finish??

#11
"However, identified an issue where menu items are not shown as active. Possibly because the "is-active" class added through JS. Please check the attached file." indeed there is a lot of twig and JS is in control.

-----
TIME: I wonder how long before samsung would support it VS drupal changing support list. and when this work could be included in core.

-->is it better to wait on this issue this this reason? let the project work more of the actual JS/CSS work to level down,

A Stepback to the pre-standing branch work:
attached 3396174-comment8-re-verify.mp4 is a review of the work left for #7/#8.

In my own QA of this work I do not see any problem with 'flashing' with JS disabled. clip containts both toggling js on the page, and as a clean pageload never having js on would be for a user. IMO: Our concern for flash happening with 'all the js on' isn't going to be the worry in a js-less state.

I do have local work still in progress to try to pull it forward, have a working state.. indeed the overall pcss changes (tnot the complied css to worry of..) do need touchups. I do have some time i can put into this still..

I've pushed branch '3396174-the-toolbar-should-alt' which is the best i can restore the original work state. Indeed, some co-ordination around this trigger is now bumping mainline work.

Rminder that in this line it is actually using html:not(.js) {} for the base (not just html.js {}) -- perhaps this is what's is more successful around 'flashing' concerns. come next attempts with this issue.

Note that html:not(.js) method can still create a flash of unstyled content, as the CSS applied will change when JS is enabled.

ckrina → changed the visibility of the branch 3396174-the-toolbar-should-alt to hidden.

Resolved the conflicts, please review if there is something needs to be updated.

ckrina → changed the visibility of the branch 3396174-the-toolbar-should-alt to active.

js.module.css already has this:


/**
* Use the scripting media features for modern browsers to reduce layout shifts.
*/
@media (scripting: enabled) {
/* Extra specificity to override previous selector. */
.js-hide.js-hide {
display: none;
}
.js-show {
display: block;
}
}
Doesn't that mean that when browsers support this, those classes already work without FOUC?

Showing the full tree of links here may not be compatible with 📌 Implement a caching strategy for the menu links Active but also that issue is still in progress. I think only showing the top level of links would count as graceful degradation though? I can't remember where I read it, but screenreaders etc. all use js now, so the non-js case is more about very bad internet connections where the js fails to load etc., which we should still handle gracefully but is more dealing with something going wrong than people's regular workflows when administering a site.

Are you sure about this? My thought process is that if we make it useable without JS, it will likely negatively affect the complexity of the code, with much more work needed to be done to make this work 100%.

My thought is that we should do a best effort on this and maybe make sure the hyperlinks work?

I also recall @lauriii stating that within the admin UI (in general), it's not necessary to be 100% workable without JS.

As an aside, maybe it's worthwhile putting together a formal policy on functionality being able to work without JS. Thoughts on all of this?

Yeah I think if the top level of links work, that is enough - you can then browse from there without JavaScript.

@lauriii commented at https://drupal.slack.com/archives/C7AB68LJV/p1714402683585049?thread_ts=...

I agree that we should not prioritize this

By @plopesc in Slack
JFYI the cacheable menu links approach is AJAX based, so it would not work without JS 📌 Implement a caching strategy for the menu links Active .

ckrina → credited mgifford → .

ckrina → credited plopesc → .

@mherchel
In my mind there's a happy medium, which is just letting the top level nav be links. (when no JS)

Mike Gifford (CivicActions)
@bnjmnm is closer to this than I am. As I understand it the challenge is that without JS it is very difficult to make the entire navigation accessible. However, it is possible to make the first level accessible to assistive technology users who have also disabled javascript.
If I am understanding this correctly, than I am in agreement with that.

Based on this, changing the direction of this issue and updating the issue summary accordingly.

@bnjmnm
Not a stable blocker at all IMO. Disabling JavaScript does not prevent any content from being reached, nor does it make it inaccessible. It's less convenient without JS enabled, but that tends to be the case when disabling something that exists to make the web more convenient

Removing the Navigation stable blocker tag.

ckrina → credited bnjmnm → .