The thread is super long but tl;dr:

We're trying to figure out if someone has both AOM and ARIA on an element, which one should win. Answering this question is incredibly difficult. But howto-components are well positioned to try out the various suggestions and give feedback to the standard.
WICG/aom#60 (comment)

Right now there are two elements and two styles of writing comments:

• say what the function does wrt to the spec (from Surma): constructor, createdCallback
• say what the element does in that function (from Rob): constructor, createdCallback

Both are great! Should we do both?

Tracking bug for <howto-toast>

Tracking bug for <howto-accordion>

TODO:

• MutationObserver

• Accordion
• Checkbox
• Radio Group
• Tabs
• Tooltip
• Tree

Space should check the currently focused radio

I figure with enough folks working on this we'll quickly hit a point where there are code style conflicts. Would be nice to add these in early to validate any incoming PRs.

Tracking bug for <howto-combobox>

TODO:

• Update to all the new patterns, styles etc etc

From Rob:
I'd really like to see an example of at least one nested menu item that uses aria-haspopup.

In general we've tried to avoid developers needing to write out ARIA attributes themselves, so it might be a good use case to create a element that automatically self applies aria-haspopup if it has children.

I'd like to show two different radio groups, 1 using roving tabindex and 1 using aria-activedescendant. What do you all think would be the best way to handle variations of a pattern?

Tracking bug for <howto-progress-bar>

Hi,
I am really curious about the goal of such example library which seems to be fully focused on Javascipt ES6.
Do you pave the way to an upcoming migration of Polymer elements in pure 2.0 implementation?
Do you recommend to progressively move away from HTML for Web Component development in general?
Cheers,
Pascal

There are a number of places where elements are referred to as HowToTree versus <howto-tree>. Need to be consistent throughout. I think I prefer using <howto-tree> instead of the class names everywhere.

Tracking bug for <howto-listbox>

By @robdodson:

I'd be curious to see if it's possible to build the entire structure out of custom elements, something like:

<dash-tabs>
  <dash-tab></dash-tab>
  <dash-tabpanel></dash-tabpanel>
</dash-tabs>

You could do some (possibly weird 😄 ) things for PE like give the tab a role=heading explicitly in markup, but then that gets swapped out with role=tab when the element upgrades. The more I think about this the more I kinda like this idea. It seems to dovetail well into the PE use case because it's saying "if JS doesn't load, this thing's role is something more basic, but if js does load, it's new role is more advanced". Most importantly it gives the user a signal that the thing is now keyboard interactive.

My tab panel pretty much made it to the repo without any actual reviews. I’d appreciate if either of you would give it a look to make sure I’m not doing random crap.

Tracking bug for <howto-spinner>

Demonstrated in this PR.

Make sure any property set on the instance before the element has upgraded will get picked up.

• Accordion
• Checkbox
• Radio Group
• Tabs
• Tooltip
• Tree

Tracking bug for <howto-menu>

Tracking bug for <howto-carousel>

I've noticed every time I load the docs for an element the first time I briefly get the unupgraded version, quickly followed by the upgraded version. This usually causes the page to flash two different layouts. But I don't think in the real world this behavior would be desirable. For a page with a lot of CEs it's going to cause a bunch of things to move around on first load.

I'm not sure the best solution tbh.

Tracking bug for <howto-slider>

Here's an example from the dash-tree doc that looks a little funky. It might be nice to just have an explicit html, css, js sections. Happy to move demo css into standalone files

In earlier elements like <howto-radio-group>, I relied on aria-* for styling and behavior. Instead, ARIA should be an implementation detail.

So instead of styling aria-checked I would expose a checked attribute/property on the element, and style that. Setting checked would, as a side effect, also set aria-checked. We should use this pattern throughout.

• Accordion
• Checkbox
• Radio Group
• Tabs
• Tooltip
• Tree

Making issue because @robdodson looped in @alice:

Looking at the JS implementation of OAA’s tab panel they are skipping their keyboard processing code when the alt key is pressed. Any idea why that is?

tabpanel.prototype.handleTabKeyPress = function($tab, e) { 
  if (e.altKey) { 
    // do nothing 
    return true; 
  } 

  switch (e.keyCode) { 
  // ...
  }
}

• Accordion
• Checkbox
• Radio Group
• Tabs
• Tooltip
• Tree

Tracking bug for <howto-drag-drop>

Tracking bug for <howto-side-nav>

Tracking bug for <howto-datepicker>

Looking at the demo code in @notwaldorf’s PR I feel like it’s probably good to comment the CSS, too. Should we format the code in the same 2-column format as the implementation?

The parser isn’t currently able to (I think), but can be adjusted.

@notwaldorf @robdodson WDYT?