Frontend Meeting - March 21 2023 Meeting in Slack

Created on 21 March 2023, about 2 years ago
Updated 19 April 2023, about 2 years ago

This is the frontend meeting for Drupal.org. This meeting takes place bi-weekly on Tuesdays at 3pm UTC (8:30pm IST, 5pm CEST, 11am EST, 8am PST). See Time.is to see what that is in your timezone.

UPDATE (transcript added)

Introductions
9 replies

katannshaw
lauriii
mherchel
indrajith
andy-blum
cosmicdreams
ckrina
markconroy
Gauravvvv

***

What agenda items would you like to discuss today (i.e. will be added as a topic)?
2 replies

lauriii
Would be great to have dedicated thread for https://www.drupal.org/project/drupal/issues/3313520 Single directory components in core Active

andy-blum
And one for https://www.drupal.org/project/drupal/issues/3347352 Empower themes to prevent base theming Active
Empower themes to prevent base theming

***

Any further general updates from the maintainers or product managers?
2 replies

lauriii
There’s a lot of discussion going on around https://www.drupal.org/project/drupal/issues/3313520 Single directory components in core Active . Any additional input on this is appreciated! :slightly_smiling_face:
Single directory components in core

mherchel
Yep! We're hoping to get that in by 10.1 (as beta). That's a super tight deadline, so take a look!

***

Where can contributors help this week? (Note: If you want your item added to a new topic thread, add a thread icon with it)
0 replies

***

Any other general #frontend subjects to discuss can go here
4 replies

andy-blum
@lauriii any chance this one is ready to merge?
https://www.drupal.org/project/drupal/issues/3293469 📌 Automated A11y tests in Nightwatch Fixed
Automated A11y tests in Nightwatch

lauriii
I could take a look at that again

andy-blum
@amey mudras I responded to your latest changes on this issue https://www.drupal.org/project/drupal/issues/3212707 🐛 Olivero: Z-index issue with table with sticky header Needs work
if my last comment isn’t clear, feel free to DM me and we can sync up
Olivero: Z-index issue with table with sticky header

smustgrave
Posted 2 issues that are needing frontend manager review if someone could put their stamp of approval or disproval

***

Fun question: What was your favorite tv show as a kid? :tv:
7 replies

katannshaw
This is a hard one because I loved lots of shows. I’d say “Little House on the Prairie.

mherchel
https://www.youtube.com/watch?v=ULfmowbNlK0
YouTubeYouTube | roxette hd2
Airwolf Intro

katannshaw
Oh I loved Airwolf!

katannshaw
and MacGyver

mherchel
oh yeah!

mherchel
https://www.youtube.com/watch?v=yOEe1uzurKo
YouTubeYouTube | Jan Schmelter
MacGyver - Intro [HQ]

mherchel
and this https://www.youtube.com/watch?v=_MVonyVSQoM

***

TOPIC 1: https://www.drupal.org/project/drupal/issues/3313520 Single directory components in core Active (edited)
Single directory components in core

lauriii
https://drupal.slack.com/archives/C0D5GJZ8B/p1679411257832149?thread_ts=...

mherchel
Yep! We're hoping to get that in by 10.1 (as beta). That's a super tight deadline, so take a look!
From a thread in frontend | Mar 21st | View reply

lauriii
One of the open questions I had was, how would I theme something like a node using SDC?

lauriii
I’m wondering if folks have examples from pre-existing projects for how to do this?

lauriii
We have examples of the more simple use cases which is great. But it would be great if we could start expanding the examples to more advanced concepts next

mherchel
One of the open questions I had was, how would I theme something like a node using SDC?
I don't think you need to

mherchel
We have examples of the more simple use cases which is great. But it would be great if we could start expanding the examples to more advanced concepts next
Agree with this

markconroy
I think we definitely need to. Some node types will have specific fields that might be collected in specific ways - event, for example - and it would be good to know how we plan to handle this at a node level rather than just an individual field/component level.

markconroy
My thoughts are that it’s the same as any other component. And we handle it like anything else.

markconroy
Here’s an example from an old version of mark.ie when I was using patternlab - https://patternlab.mark.ie/pattern-lab/public/?p=content-blog - that’s for theming my blog content type specifically.
Components on the page - call to action, quote, text, etc - were all themed at a component level (paragraphs, which in my case here I called “building blocks”) - 4th tab on the page.
But after that, I still wanted styles for blog_title and blog_intro and things like that.

***

TOPIC 2: https://www.drupal.org/project/drupal/issues/3347352 Empower themes to prevent base theming Active (edited)
Empower themes to prevent base theming

andy-blum
Im interested in people’s opinions on this. Why is this a good idea? why is it a bad idea? what side effects could this have?

mherchel
I'm not sure this is a good idea. If people want to live dangerously, I'm okay with letting them.

mherchel
live dangerously (964 kB)
https://media3.giphy.com/media/DwIdasRkFKsMg/giphy.gif?cid=6104955e4sqcr...
Posted using /giphy

lauriii
I’ve definitely heard some anecdotes where people have not known about a best practice and have accidentally lived dangerously

andy-blum
cc @Nik Hurwood

mherchel
Maybe display a warning on the admin/appearance screen?

mherchel
Or! Require an override in their subtheme

mherchel
ignore_no_subtheme: true

andy-blum
related: https://www.drupal.org/project/drupal/issues/3281690 Warn users attempting to use Olivero as a base theme Needs work
Warn users attempting to use Olivero as a base theme

mherchel
or something

Nik Hurwood
thanks for the tag
@andy-blum. My main thought on this isn't specific to Olivero, but rather the "core" theme being untouchable. The sole purpose of a subtheme is supposed to be that it allows for changes without breaking BC, of course any subtheme where the parent get's updated also needs to check for breaking changes.

Nik Hurwood
So I guess, where I'm not really comfortable is that we have a core theme which technically should be a release candidate due to known and planned changes. I may be an outlier in the direction of travel, but I see this as a closed approach to what the purpose of Olivero (or any theme that sits as the new face of Drupal) is to be usable by a large number of people, as easily as possible. To make sub-theming a lower priority (or not supported) provides a barrier to people actually using it - which is IMHO the opposite of what core should provide.

Nik Hurwood
Basically, I've interrupted with philosophy rather than a solution :slightly_smiling_face:

***

TOPIC 3: https://www.drupal.org/project/drupal/issues/3346539 🌱 [Plan] Improve field creation experience Active
[Plan] Improve field creation experience

lauriii
Just wanted to mention that we are making progress on this. If there are folks who are interested in working on user experience related issues, I’m happy to help folks get started on this

lauriii
If you’d like to get involved, feel free to ping me on #field-ux

***

Is this a good time to get feedback on a (somewhat old) demo of a new feature: https://www.loom.com/share/425c0abedaf448f486a0289a7121361d
Same Page Preview - Status Update 3-14-2023
A demo of the Same Page Preview feature. We're getting ready for our 1.0.0 launch. Let us know what you think.
41 replies

cosmicdreams
Progress on this is happening over in #preview

andy-blum
@mherchel @lauriii this could be cool to use with theme settings as well, like Olivero’s color settings

cosmicdreams
Interesting

lauriii
@cosmicdreams was this a setting on the content type?

cosmicdreams
The main way this works is:
Drupal already has the "guts" of saving a preview of a piece of content into the TempStore
That preview already gets a link (that's how core's preview system works)
We're just shoving that into an iframe on the content edit page.
In order to get this to work for Theme Appearance page, we'd have to have the ability to push an unedited node into the tempstore and get a url for it. Then show the preview in an iframe.
It .... sounds .... doable???

cosmicdreams
@lauriii Specifically what bit are you asking about?

lauriii
I’m asking if the toggle to turn this on was something that is controlled on per content type basis

lauriii
Or is it enabled to all content types once you enable the module?

cosmicdreams
I'm working on that here: https://www.drupal.org/project/same_page_preview/issues/3348559 📌 Add per Content Type enablement of same-page-preview Fixed
Add per Content Type enablement of same-page-preview

cosmicdreams
I've got that mostly working, working on a bug report with it.

cosmicdreams
@lauriii Thing I got did yesterday is pretty cool:
https://www.loom.com/share/46d9c0b255ac46c1a8f740c83e84d526
Same Page Preview | Checkbox works!
I've been able to get the checkbox to work. Here's a quick demo of it.

cosmicdreams
@lauriii Yes, by default this preview is available for all content types. You then can opt-out for specific content types

lauriii
nice!

lauriii
I mean the demo :smile:

lauriii
Starting to look more refined

cosmicdreams
@lauriii https://git.drupalcode.org/project/same_page_preview/-/merge_requests/20 is the MR for the checkbox if you want a peek. Not sure if this is the "right" way to do it. But it works.
Resolve #3344837 "Use checkbox" (!20) · Merge requests · project / same_page_preview · GitLab
Closes #3344837
Author
Chris Weber

cosmicdreams
OH @lauriii we had a question for you

cosmicdreams
@lauriii How can you have the page load with the off-canvas dialog open by default (without driving js to click the button on load)? (edited)

lauriii
I don’t think we have any examples of that. I’m not sure there’s an easy way to do that

cosmicdreams
It might be better to continue this conversation in #preview but I did a ton of research on this question yesterday

cosmicdreams
I could break down what I've found if you have time?

lauriii
I have a moment :+1:

cosmicdreams
OK
Findings:
Off-Canvas dialog is our custom implementation of jQuery's dialog. Which they largely made for modals.
jQuery has a setting called autoOpen that we set to True for all of our modals. This is good because the dialog is active as soon as it's inserted.
Opening the dialog is also the action of generating the markup and inserting it into the page. The dialog's markup isn't in the DOM until then.
Nearly every code example I can find online says just click the element that opens the modal on document load to open the modal by default.
In order for the dialog to be loaded by default, we'll need to get it's markup into the DOM without needing to click. We could then, maybe, just use the CloseDialogCommand toggle it off (but retain the markup in the page)
(edited)

DuaelFr
Just a side thought about that auto opening side panel: these are modals so focus is supposed to be trapped inside for keyboard users. I'm not sure it would pass accessibility gate (neither it would be a good ux) to load a page where the user is trapped in an area where the actions they want to do (edit content) are not.

cosmicdreams
@DuaelFr from this perspective, is it prudent to open the preview and keep focus in the edit side of the page?

DuaelFr
I honnestly don't know.
I'd say why not but it leads to new problems like how keyboard users will be able to get inside the preview if its already open and their focus is outside. I guess they could close it then reopen it but it seems a bit odd.
The other thing is that when I'm thinking about use cases and persona three comes to my mind:
people navigating with keyboard : they might need to get into the preview to hit the refresh button, see their changes, scroll the preview down, then get out to make new changes and repeat. They wouldn't like to be focus-trapped into the preview because they would need to close it to get back to editing. Maybe they would benefit of a button allowing to get back to the edit form and unlock the focus trap.
people using a screen reader: I assume they would have a very little use of the preview panel but they could need it to check that their change has the effect they think it should. In that case, they would need the same features that keyboard users.
people using voice navigation (like Dragon): I don't think it should be a big deal if Dragon allows to manipulate elements outside of a focus trap but I don't know much about this software so I cannot say.
Given the two first use cases, I'd suggest to have a visually-hidden focusable link just after the toggle when the preview is open so people can jump in if they need. The preview opening would not move the focus but announce to screen readers that it has been opened and that a link would provide a way in. Inside the panel, another link should allow to get out without closing the panel, probably placing the focus back on the link to get in.
I believe it would be a good idea to bring your goals and these constraints to the UX and a11y teams to figure out the best way to implement this as I'm not an expert at all. (edited)

mherchel
FWIW, during accessibility office hours, Rain said that blind users will user the standard preview functionality.

DuaelFr
If same page preview is open by default when loading the form, they will have to deal with it before using the standard one.

cosmicdreams
Open by default would be a setting that users can opt-out of

cosmicdreams
If accessibility tooling is being combarded with prompts then we could start that bombardment with a notice that the user can turn it off.

cosmicdreams
@DuaelFr and ultimately we may remove the refresh button and go with auto-refresh

cosmicdreams
I love the idea of a keyboard shortcut that toggles the focus from edit -> preview and back.

mherchel
My thought is that it doesn't even need to be open by default. If the user toggles it open, it'll then stay open (until they don't want it anymore). I'd personally make this a per-content-type thing

DuaelFr
per-content-type and per-user thing then? No sitewide default for all users?

mherchel
My thought (I'm not developing it) is that it can be turned off by default. If the user toggles it on, it remembers the setting for that content type in localStorage

mherchel
So, if they switch devices, they'd need to toggle it again. But, IMO that's totally fine

cosmicdreams
Talked about this strategy yesterday with Brian. Current thinking is:
Check if user has permission (site-admin choice)
Check if content type has permission (site admin opt-out, per bundle)
Turn on by default, allow user to opt-out.
That user opt-out is a "across the board" opt out and not Content Type specific. (edited)

andy-blum
I’d recommend opt-in for the user

cosmicdreams
@andy-blum I can see that as a good point if this was a core-included feature. But right now, its a contributed module. The opt-in is installing it.

cosmicdreams
Actually, you know what? With the recent work, it actually is opt-out by default. (edited)

cosmicdreams
Previously we were setting #default_value on the field and now we handle all that with javascript. (edited)

📌 Task
Status

Fixed

Version

10.1

Component
Meetings 

Last updated about 1 month ago

Created by

🇺🇸United States katannshaw Kansas

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024