We should at least be testing the focus stuff and that type defaults to button.

The dependency intl-messageformat was updated from 3.0.0 to 3.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

intl-messageformat is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

When the message to be shown in the dialog gets long (63 characters in my case) there is a scroll bar added and the text is cut.

The devDependency lit-analyzer was updated from 1.1.8 to 1.1.9.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

lit-analyzer is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

These two formatjs libraries upgrade in lock-step. We'll need to also upgrade our usage in d2l-localize-behavior.

We needed to revert back to an older version of intl-messageformat because Polymer's app-localize-behavior is using the ^2 variant and we ran into conflicts in BSI.

If we investigate which BSI components are using app-localize-behavior (possibly just d2l-localize-behavior), it may be possible to switch them to use version ^4 as well.

In our .travis.yml configuration, we include several language addons so that when visual diff tests run with different languages (e.g. Japanese), the character sets are installed properly.

Installing these addons takes at least a minute per build stage. Unfortunately, simply moving them into the visual-diff stage doesn't work, since the visual diff "regenerate goldens" button creates a custom build that somehow excludes them.

The tests are being set to skip in #776.

They often fail with:

AssertionError: expected false to be true

      + expected - actual

      -false
      +true

Notes:

• They only fail on chrome (Chrome 84.0.4147 (Mac OS X 10.15.5)). Chrome 83 was also tested and fail.
• They tend to pass several times in a row then fail several times in a row.
• They only seem to fail when the whole test suite is run and not when just the dismissible or helper tests are run.

Things that have been tried:

• Adding timeouts (e.g., aTimeout)
• Moving these tests to run first within the dismissible tests
• Moving these tests to a separate describe section within the dismissible tests
• Modifying the document.dispatchEvent(event); to be within a setTimeout

Opening this per "Future Enhancements" in the README.

Is porting breadcrumbs to lit on the roadmap? Would it be made available via core?

The ability to open a d2l-tab in a new window would be really useful. We support this in IPSIS UI with paper-tabs right now and don't want to lose that functionality by switching over.

There seems to be a rounding issue leading to inconsistent displays when using d2l-meter-radial when choosing to show percents. Sometimes it says 0% even though it isn't actually zero, this makes the UI to say 0% but the meter having a blue dot. For reference they are being used at https://github.com/BrightspaceHypermediaComponents/activities/blob/1fdeffd33c50ce02c4033baa03eaec7c4b0a1b94/components/d2l-quick-eval/activity-card/d2l-quick-eval-activity-card.js#L207

Consumers commonly declare a private property for the alert state in their component, however they need to keep it in sync with the alert open/closed state so that subsequent changes to reopen the alert cause it to be displayed again. To allow this, we should dispatch a "close" event when the alert is closed, that consumers can listen for and keep their private state property in sync.

In the settings in Travis CI, there's this setting:

We've disabled it in the core repo as some things in our configuration were breaking the validation. But this setting will eventually be always-ON and enforced, so it would be good to sort out the issues now instead of kicking the can down the road.

The linear meter does not print across all browsers, because it is using a background color on a div.
The fix in firefox is to add css: color-adjust: exact;, chrome works with the css: -webkit-print-color-adjust: exact;, but I was unable to find a css fix for edge.

Perhaps a fix for edge, and all other browsers would be to change the meter-linear to be an svg path, like the other meters.

Tooltip Multi-Target Support

What do we want to do?

Allow tooltips to have multiple targets so that hovering / focusing any of the targets will trigger the tooltip. Changing for to support multiple targets like for="id1 id2 id3 id4" would allow for this.

Why do we want to do this?

In some cases it makes more sense to display a single tooltip for multiple elements rather than a tooltip for each. Currently this can be done but it requires manually handling events for anything that isn't the tooltip's target and calling show() / hide().

What challenges are involved?

The primary challenge is how to position the tooltip relative to multiple targets.

Option 1:

Compute the smallest rectangle that includes all targets. This will likely result in good positioning but might cause issues where the pointer doesn't point to any of the targets.

Option 2:

Always position relative to the first target and only use the others for focus / hover events.

Feature request: it'd be super cool to be able to resize the demo panels to test responsiveness. That could be kind of difficult though based on how media queries work, and might require that stuff get iframed, which could be gross. So maybe not feasible, but worth investigating. Maybe we can use seamless iframes?

In a complex application where form elements are spread out across multiple shadow boundaries, you still want to validate and show the error summary for the entire "page". This is possible today using nested <d2l-form>s, which is awesome. However, the error summary needs to be displayed with a form that wraps the entire page.

Ideally, we could choose which d2l-form hosts the error summary. That would allow us to handle cases like with the primary/secondary template where you have form elements in both panels but wish to display the summary in the primary panel.

In the example above, it would be good to be able to show the errors from both panels, but currently only the primary panel errors can be shown.

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency @open-wc/testing was updated from 2.5.4 to 2.5.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

#102 (review)

Is it necessary to create an observer for each LocalizeMixin instance? Can this be changed to either not handle the case where the document language changes, or to have a single global observer?

In <d2l-icon> you can set color in CSS.
By analogy it seems like that should be possible in <d2l-button-icon>, but it isn't:

<d2l-icon
    icon="tier1:close-circle"
    style="color: var(--d2l-color-feedback-error)">
</d2l-icon>

<d2l-button-icon
    type="button"
    icon="tier1:close-circle"
    style="color: var(--d2l-color-feedback-error);">
</d2l-button-icon>

Result:

In a typical scenario, a form is placed inside a panel or on a page that already has margins configured, like this:

<div style="margin: 20px;">
    <d2l-form>
        <!-- form elements -->
    </d2l-form>
</div>

That looks good when there aren't any errors:

But as soon as there are errors, the summary is placed at the top and because it has no bottom margins, the top of the form is right against it:

I think some default bottom margins on the summary would solve this nicely. In the LMS we use 10px as the bottom margin on the summary, but possibly something similar to the space between fields (1.5rem = 30px) would work better. Could use some design input (FYI @geurts).

The devDependency @open-wc/testing-karma was updated from 3.2.35 to 3.2.36.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@open-wc/testing-karma is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I'm trying to use announce to notify screenreaders when I delete rubrics from FACE one-by-one.

This seems to work fine in NVDA+FF, but in Chrome, it accumulates the messages so if I delete one rubric, I get "Rubric removed", delete another "rubric removed rubric removed", and so on (also seems to do this with JAWS).

I guess it happens because of announce re-using the same live region. If I wait the 10s between deleting each rubric for the live region to reset, it will only show the 1 message.

Comparison to v1.0.0:

Usages:
v1.0.0 branch
v1.0.3 branch

Demo doesn't appear to display text "scrunched" at all.

@m6jones

In colors.js, celestine-1 is defined as #005694, but due to our refinements to the color palette in Aug 2019 to align with WCAG 2.1, many colors (including celestine-1) were changed.

Designers will continue to spec colors by name, however, without the palette updates, we will not be able to pass the required colour contrast in all scenarios.

See:
http://design.d2l/style/colour/ > Change History > Aug 1, 2019

What do we want to do?

Integrate d2l-tooltip into d2l-button-icon so setting the text attribute on a button automatically adds a tooltip with the text inside.

Why do we want to do this?

1. Tooltips use aria-describedby or aria-labelledby to make them accessible. However, these attributes are poorly supported on non-interactive elements. As a result tooltips on static or custom elements have inconsistent accessibility across screen readers. Attaching tooltips to the native button element fixes these issues. For more information see the tooltip README.
2. This gives sighted users a consistent way to see button-icon text when the icon alone isn't enough to infer the meaning of the button.

What challenges are involved?

1. Buttons may have parents that don't have overflow: visible. This means tooltips on buttons may cause unexpected scroll or be unexpectedly cut off. The tooltip's boundary attribute can be used to prevent this but has problems because:
   1. Users of d2l-button-icon would need to manually pass a boundary into the button-icon based on which parent has non-visible overlow.
   2. These components may not know if they have a parent with non-visible overflow like d2l-calendar which would mean they would also need to allow a boundary attribute to be passed in. This could cause a huge chain of boundary attributes that need to be passed down.
   3. d2l-button-icon would need to expose d2l-tooltip attributes as part of its interface.
      
2. Resolved: Buttons may also open other components like d2l-dropdown which risks overlap. The d2l-tooltip close-on-click attribute was introduced to resolve which mimics the behavior of native browser tooltips.
   

Selecting d2l-menu-item-radio Closes Containing d2l-menu

What do we want to do?

Have the containing <d2l-menu> close when one of its immediate inner <d2l-menu-item-radio>'s is selected.

Why do we want to do this?

Only one of the <d2l-menu-item-radio>'s in a <d2l-menu> can be selected. Once one has been selected, the user is finished with the menu. For this reason, the WAI-ARIA best-practises for menus suggests that activating a menu item should close the menu.

What challenges are involved?

Should there be an attribute flag for this? If there is a use-case where the menu should always be open, this menu should not be closed on selection.

The devDependency eslint was updated from 6.1.0 to 6.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

<d2l-list-item>
    <div slot="actions"><!-- gets a z-index of 4-->
        <d2l-dropdown>
            <d2l-button-icon
                class="d2l-dropdown-opener"
                icon="tier1:more"
            ></d2l-button-icon>
            <d2l-dropdown-content>...</d2l-dropdown-content>
        </d2l-dropdown>
    </div>
</d2l-list-item>

This can be worked around by playing with z-index on the dropdown, but should work out of the box.

Here's a very common workflow: a component is clicked, which opens a dialog. Dialog is smart enough to grab the currently active element (using getComposedActiveElement in our focus helpers). When the dialog is subsequently closed, focus is returned to that opener. Brilliant!

Except it doesn't work in all scenarios. If the opener is a menu item in a dropdown, the menu will be collapsed later when focus is attempted to be returned. Since the opener is hidden, the attempt fails and focus is lost. 😭

What should actually happen: focus should return to the dropdown's opener.

I think a good generic solution to this problem would be for certain elements that collapse -- like dropdowns -- to be able to retarget/delegate opener responsibility elsewhere. That way, when dialog goes to find the currently active element, menu/dropdown would point it at ITS opener.

When disabling a <d2l-menu-item disabled>, while visually and functionally the item acts disabled, aria-disabled="true" isn't getting applied to the element with the menuitem role. So to screen readers, it does not announce that the item is disabled.

Sample resolved markup:

<d2l-menu-item disabled class="d2l-contextmenu-item" text="Paste" role="menuitem" tabindex="-1">
    <!-- shadow root --->
</d2l-menu-item>

Use Radio Icon for d2l-menu-item-radio Instead of Check Mark

What do we want to do?

Use radio icons for <d2l-menu-item-radio> elements, instead of the check mark.

Why do we want to do this?

Multiple selection menus are typically designed using checkmarks (examples), while radio selections are typically designed using radio buttons (examples). To make it more clear to the user what kind of menu they are interacting with, the <d2l-menu-item-radio> elements should use radio buttons instead of check marks.

As seen when rendering the d2l-button-subtle in RTL mode, the icon inside of the button overlaps the text.

 return html`
         <d2l-button-subtle
                 text="Manually Override Grade"
                 icon="tier1:edit"
                 @click=${() => {}}
         ></d2l-button-subtle>
 `;

the translation for https://github.com/BrightspaceUI/core/blob/master/components/dialog/dialog.js#L62
isn't the best. Can we change it?

🚨 The automated release from the 1.72.x branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the 1.72.x branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The release 1.72.2 on branch 1.72.x cannot be published as it is out of range.

Based on the releases published on other branches, only versions within the range >=1.72.1 <1.72.2 can be published from branch 1.72.x.

The following commits are responsible for the invalid release:

• ci: deploy on all branches (b68d56c)
• fix: Do the bump again (53a24df)
• Merge branch '1.72.x' of github.com:BrightspaceUI/core into 1.72.x (1af81f1)
• fix: Do the bump (b7145c8)
• fix: cert: translation updates for 20.20.9 (#801) (5ad5c27)

Those commits should be moved to a valid branch with git merge or git cherry-pick and removed from branch 1.72.x with git revert or git reset.

A valid branch could be 1.59.x or master.

See the workflow configuration documentation for more details.

Good luck with your project ✨

Your semantic-release bot 📦🚀

When clicking link on d2l-list-item with href the navigation is broken.

Test:
steps: git checkout && npm start && test links navigation for list items on http://localhost:8000/components/list/demo/list.html
expected: navigating to http://www.d2l.com

Results:
for release v1.79.1 - navigation is correct
for release v1.79.2 - navigation is broken and tries to go to http://localhost:8000/components/list/demo/undefined

it seems that the recommended way to open a dialog is by selecting the dom element and setting opened to true:
this.shadowRoot.querySelector('d2l-dialog').opened = true;

But how come I can't do this declaratively? doing this:

<d2l-dialog title-text="Dialog Title" opened="${this.someProperty}">
				<d2l-button slot="footer" primary dialog-action="done">Done</d2l-button>
				<d2l-button slot="footer" dialog-action>Cancel</d2l-button>
			</d2l-dialog>

causes a stack overflow and crashes my chrome 😢

I thought doing things declaratively is the best practice?

The info tooltip is super handy, especially when using the keyboard as it tells you the date format and how to open the mini calendar.

However, when you click into the input the mini calendar opens automatically. But for a brief moment before it does, the info tooltip is shown, which creates some jitter.

Ideally we would only show the tooltip when focused using the keyboard. If a click event was the source, we'd just open the calendar and not show the tooltip.

Quickly switching between parent and child (for example in the hierarchical-view demo clicking view 1 and 2b buttons very quickly on small display (seen in attached gif), or in menu navigating with left and right arrow keys quickly) can cause an infinite loop in __dispatchViewResize in the check if isActive and lead to a view not loading and maximum call stack size exceeded in console.

This happened prior to lit conversion and is not a regression. Low priority to fix.

When you put the numeric input into an invalid state, a console warning appears:

d2l-tooltip may be being used in a non-accessible manner; it should be attached to interactive elements like 'a', 'button','input' 'select', 'textarea' or static / custom elements if a role has been set and the element is focusable.

This is caused by the for of the tooltip pointing at the d2l-input-text element and not the underlying native input. For/id references can't cross shadow boundaries though anyway.

I believe the date/time inputs get around this by using the announced attribute on the tooltip, which will cause it to be announced and not rely on the for/id linkage.

This may require some experimentation.

When a project consuming core runs lit-analyzer in strict mode, it complains about no-unknown-tag errors for all our element definitions. For some reason, it's not smart enough to see our customElements.define calls.

One solution is to include a TypeScript definition file for each element. For example, button.d.ts:

export class ButtonElement {
  disabled: boolean;
}

declare global {
  interface HTMLElementTagNameMap {
    "d2l-button": ButtonElement;
  }
}

We wouldn't want to create that manually though, so would want a way to generate it and include that in the NPM package. This looks promising.

Alternately, there seems to be some gaining traction around having a custome-elements.json file that can be generated automatically and then linters and editors use that. Doesn't seem to be working just yet though.

In light of the recent Future Enhancements sections on the README, I thought it would be pertinent to formalize this request in an issue.

On our LitElement product, we tried to use d2l-table and ran into a number of problems with the styles. Particularly, the styles would often not work on all/any of the tables on the page under inconsistent circumstances. We determined that it was likely to do with the <custom-style> element that is required to add the table styles onto the page, which do not work well/at all with LitElement.
When this was last brought up, there were some efforts to lit-ify the styles, but in the interim we wrote our own styles that emulate the d2l-table component's. We would like to move to the official d2l table if ever it became possible.

This is specifically seen with input-time and input-date-time.

I added performanceTimer: true to the running of the aXe tests (needed to modify chai-a11y-axe/src/accessible.js) and the following were the rule checks that took longer than 20 ms (bolded the biggest ones):
rule_aria-allowed-attr#gather took 100ms
rule_aria-allowed-attr took 102ms
rule_aria-allowed-attr#gather_axe.utils.isHidden took 60ms
rule_aria-allowed-role took 19ms
rule_aria-valid-attr-value#gather took 30ms
rule_aria-valid-attr-value#gather_axe.utils.isHidden took 30ms
rule_aria-valid-attr-value took 31ms
rule_aria-valid-attr#gather_axe.utils.isHidden took 27ms
rule_aria-valid-attr#gather took 28ms
rule_aria-valid-attr took 28ms
rule_autocomplete-valid#gather_axe.utils.isHidden took 28ms
rule_autocomplete-valid#gather took 28ms
rule_autocomplete-valid took 28ms
rule_color-contrast#matches took 1215ms
rule_color-contrast took 1281ms
runchecks_color-contrast took 66ms
rule_landmark-unique#gather took 21ms
rule_landmark-unique took 21ms
rule_scrollable-region-focusable#gather_axe.utils.isHidden took 21ms
rule_scrollable-region-focusable#gather took 21ms
rule_scrollable-region-focusable took 21ms

By default, lit-analyzer runs in non-strict mode. This means we're missing a bunch of warnings. We should enable strict mode and fix the warnings.

In an effort to move away from Polymer utils, it would be helpful to have a common non-Polymer (and, framework-independent) debouncer. Probably a class similar to, or matching, the Polymer 3 debounce API would be perfectly suitable (on second thought, that's overcomplicated/clumsy compared to our needs), but if there's something common we do that can be factored in, would be good to consider that also.

Alternately, we could use more standard utility libraries (lodash, underscore, etc.), so long as we standardize.

Each time getLocalizeResources is called in LocalizeMixin and LocalizeStaticMixin, some work occurs. This work is repeated for every instance of that component, when it only needs to happen once.

We should investigate caching the results of the call for a given set of input languages.

Watching @svanherk's GAAD demo today made me wonder if we shouldn't be treating the printable characters in menu items in a case sensitive way? It seemed really unintuitive to me to need to know whether a menu item is "Delete" vs. "delete" to know whether to hold down shift.

The spec is ambiguous:

Any key that corresponds to a printable character (Optional): Move focus to the next menu item in the current menu whose label begins with that printable character.

Thoughts?

A scroll method would be valuable for dialogs. Currently, there is no way to access the scrollable content panel of a dialog without deep querying.

Background: The new Learning Paths feature uses a dialog to add activities to a learning path. Within the dialog, there is a list component with selectable activities, along with a "load more" button at the bottom. When the load more button is pressed, a spinner is revealed, but is partially cut off by the footer of the dialog.

This would be solved by the ability to scroll to the bottom of the content. It may also be helpful to have the ability to scroll to a specific position.

See also the related PR: https://github.com/BrightspaceHypermediaComponents/activities/pull/655

If focus() is called on <d2l-input-text> before it's had a chance to render, focus is not placed on the input.

We could handle this by waiting for an internal updateComplete and then trying again to focus. We could even make the method async so that folks would know when focus had actually been placed (e.g. for visual diffs).