🇫🇷France @spryah

just_like_good_vibes → credited spryah → .

Please don't mind me. I'm only posting an updated version for 1.0.x (still contains utility classes to polish the appearance of the tasks menu)

Screenshot enclosed

Hello,

The MR doesn't exist but it peeked at the changes and it seems to me that the line 5 should be changed

From this:

{% if caption or transcription %}
  {% set attributes = attributes.setAttribute('role', 'group') %}
{% endif %}

To this:

{% if caption %}
  {% set attributes = attributes.setAttribute('role', 'group') %}
{% endif %}

Hello @sourav_paul
Thank you for taking charge of this issue!
The changes look good except for the following file: templates/system/input--submit--search-submit.html.twig
This is an actual submit button, which will receive the type="submit" attribute, so it should be best to revert just this part

Hello @just_like_good_vibes
I initially associated the issue with DSFR v1.13 but this is actually an issue that already causes trouble whenever one of these components are inside a form, so I believe that it should be addressed regardless of the DSFR version

Ah, I see what you mean. But card titles often come with a link, so maybe it would be more accurate to keep it as a slot?

Hello and thanks for the proposal, Mikael!

I'm not sure if the DSFR really is responsible for this case since we're using fr-tabs classes to make a group of links look like tabs, and it seemed normal to me that the DSFR script uses these classes to convert the list into a tab group component..

Anyway I'll just drop my version of the fix here, as a patch, just in case people are interested in cute vertical margins
I also added an icon to the active link to make it more visible

spryah → created an issue.

May I add that the markup in a few templates and patterns seems to have fallen out-of-date, for example:
- The classes, fr-card__link and fr-tile__link are gone since DSFR 1.5
- The dialog element in the transcription pattern changed to a div in DSFR 1.10
- The classes in the form fields' error messages have changed multiple times according to the history (but it looks like it was not mentioned in the log ?)

Okay!
Since we need a semantic element, I kept the title inside a <p> tag and set it as a setting/prop.
I also changed its type from text to token but I'm not sure how I can anticipate this kind of information?

Hello Pierre,
Thank you for your feedback. I understand your concern. Should we set the title as a setting/prop then?

spryah → created an issue.

spryah → created an issue.

Any piece of advice is welcome

spryah → made their first commit to this issue’s fork.

spryah → created an issue.

Hello @pdureau,
I never had the chance to use this pattern so now that i'm looking at the difference in the merge request, it seems to me that the commits were somehow lost in a parallel universe?
Should I try to rebase?

I'm sorry I didn't notice that the commit was empty """"

spryah → created an issue.

My thoughts after testing.

- Not passing data-fr-group is the same as passing data-fr-group="true".
- As shown in the demo page, the default behavior is "all accordions are grouped".
- We need to explicitly add data-fr-group="false" if we want to dissociate the accordions.

Hi @pdureau!
I'm sorry I came back after so long.
For this issue I only updated my MR to add a "pictogram" settings.
This pattern has been very useful inside our projects up to now and I have trouble understanding how an example could be more useful to our developers?

It's OK for me! (^_^)b

spryah → created an issue.

spryah → made their first commit to this issue’s fork.

spryah → made their first commit to this issue’s fork.

@pdureau Although I think I understand your statement, I believe this issue requires a lighter modification than expected ^^?

spryah → changed the visibility of the branch 3445147-default-card-title-tag to hidden.

spryah → created an issue.

spryah → created an issue. See original summary → .

We put this issue on hold because the DSFR maintainers have yet to release a fix that will allow developers to define sub-partners without having to define a main partner (it shouldn't be long now)

spryah → made their first commit to this issue’s fork.

I found the following classes in the v1.10.0 version of DSFR: fr-error-text, fr-valid-text, fr-info-text.
In UI Suite DSFR, only the class fr-error-text was found and replaced with fr-message--error (+ fr-error-group wrapper).

I think this means that the other messages will have to be handled manually?

spryah → made their first commit to this issue’s fork.

spryah → made their first commit to this issue’s fork.

spryah → made their first commit to this issue’s fork.

spryah → made their first commit to this issue’s fork.

In accordance with the classes found in the source code of version 1.10.1, the following variables have been added:

• fr-icon-arrow-right-down-circle-fill: arrow-right-down circle fill
• fr-icon-arrow-right-up-circle-fill: arrow-right-up circle fill
• fr-icon-equal-circle-fill: equal circle fill
• fr-icon-threads-fill: threads fill
• fr-icon-threads-line: threads line
• fr-icon-twitter-x-fill: twitter-x fill
• fr-icon-twitter-x-line: twitter-x line

spryah → made their first commit to this issue’s fork.

spryah → made their first commit to this issue’s fork.

I've made a lot of refactoring and I also made it so the state of the collapsible can be configured using the is_expanded variable.
Please let me know if the new version meets your standards

spryah → created an issue.

spryah → created an issue.

spryah → created an issue.

Hi @pdureau,
We had some trouble using your code snippet: we get an error that says "Call to undefined function setAttribute()". We could not manage to figure out in which cases $variables['attributes'] would be empty or null (we tried using instanceof Attribute for example), so instead, we suggest setting an empty Attribute in case $variables['attributes'] were NULL.

  if (UrlHelper::isExternal($variables['url'])
    && !UrlHelper::externalIsLocal($variables['url'], \Drupal::request()->getSchemeAndHttpHost())) {
    $attribute = $variables['attributes'] ?? new Attribute;
    $attribute->setAttribute('rel', 'noopener');
    $variables['attributes'] = $attribute;
    $variables['target'] = 'blank';
  }

Would that be okay with you?

Ah. My bad, I'll fix this.
And I'll open an issue to do the same for the link pattern.

Hi @pdureau,
Thanks a lot for your detailed answer. I carried out a few tests to replace the occurrences of pattern_with_settings with pattern and all proved conclusive. I suppose that simplifies a lot of things.

spryah → created an issue.

Added a clarification concerning the layout of the document

Fixed missing words in summary...

spryah → created an issue.

Edit title.

spryah → created an issue.

Fixed link in summary.

spryah → created an issue.

Aaah, you're absolutely right. Now you're making me realize that we're missing an important behavior in case of an external link defined in the button pattern. The element should get a rel="noopener" attribute, similar to the external links defined in link pattern. Am I allowed to fix this in the same MR or do you require that I open a different issue?

Hello @pdureau

Thank you for your reply.
I'm not used to working with UI Patterns so please forgive me if I made a mistake.
I see a target variable in the settings, line 38. Was it not appropriate to use it here?

spryah → created an issue.

Edited title and summary.

spryah → created an issue.

spryah → created an issue.

spryah → created an issue.

spryah → created an issue.