Chromium not inferring menuitem name from shadow DOM contents - google-chrome

CodeSandbox demonstrating issue
I'm building a menu using Custom Elements. It works fine for keyboard and mouse users, but I noticed an issue when testing with a screenreader: all of my menuitems have no labels. You can see this in the Accessibility Inspector:
Each menuitem is essentially a custom element with a <slot> and some styling—that's it. When not using web components, if one does this:
<button role="menuitem">Foo</button>
Then the Chrome accessibility inspector will show "menuitem: 'Foo'" because it infers the name from the contents. With web components, this isn't the case—Chrome is showing no name. Here's a side-by-side comparison when I use the accessibility inspector inside the CodeSandbox I shared above.
Firefox and Safari both successfully infer the name of these menuitems. Chromium-based browsers are not. Is this a Chrome bug? Are the other browsers just working by coincidence? Is there anything I can do here? I'm really trying to avoid weird stuff where I pull the slot's innerText and add it to an aria-label or something.

Related

Transition not being captured by subtree & attribute breakpoints Chrome developer tools

I have a webpage on which if a tab key is pressed when in the last textbox a side pane from the right slides(like a side menu).
In chrome development tools I can see it is an aside tag with classes control-sidebar control-sidebar-dark but setting DOM break points(subtree & attribute) on the aside tag is not capturing anything.
On looking into DOM it seems like it is not being manipulated at all(which I expected sliding in should be doing) as I do not see the color blink on HTML tags that chrome developer tool shows for the affected elements.
I was expecting the javascript to be handling the sliding in of the aside tag but how could it be determined in this scenario? Could this be due to CSS only animation or something if yes than how to debug that?
I also tried to record in the animation tab of developer tools but it also stays blank.
This is happening on a privileged section of the site so I m sorry for not being able to put code sample or URL.
PS: The template is some modified version of http://www.ampleadmin.wrappixel.com/ampleadmin-html/ampleadmin-rtl/index.html(the navigation panel on right) but it is getting recorded in dev tool animation panel while mine doesnt.
I found out the cause. There are anchor tags inside the panel which get focused on when the tab is pressed from last textbox. There was no animation,CSS or JS involved.
Anchor(A) tags are focus able by default and the panel dont slide in when they are removed.

Hover and focus in browser inspection

I want to know if there is the possibility, by browser inspection of write a new class containing new hover/focus. For example
.CanIDo {
/*something css
(ex.)*/
width: 100;
}
/*my question (BY BROWSER ISPECTOR, i don't want to type it directly in my css using a text editor)*/
.CanIdo a:hover{
opacity: 0.7;
}
I think this is impossible because browser ispector don't admit to change a class directly, but only the containing of that class (right?), but maybe there are browser that have impove that, I think it can be helpful developing a web site.
Thanks!
If I understand your question, you are asking if you can write CSS "on the fly" in a browser Dev Tool and see the effects immediately on your page?
The short answer is yes. The Dev Tools in Chrome, FireFox, and even the latest IE/Edge browsers have that ability. You can tweak applied styles one by one using a DOM inspector or even wholesale update a CSS file in a Sources tab (the name varies slightly between browsers).
And yes, you can write pseudo-class rules like hover and they'll take effect. You can develop or tweak your code and see the results immediately.
Most browsers have inspect tools that allow you to add any class on the fly.
For instance on Chrome if you open Developer Tools you can add any class to your css, be that a :hover variant or any other normal class, pseudo-class.
What you have to do is open the inspector Cmd + Shift + I on OSx and you'll see this on the Elements tab:
You can see that on the Filter you have a "+" button, clicking that you'd be able to stuff like this:
Those two classes a:hvoer and other-class are added via the inspector as you can see on the right is written: inspector-stylesheet

Inspect HTML5 date picker shadow DOM

I'm trying to inspect the shadow DOM for certain HTML5 controls, like the date picker for the input type="date" and the actual suggestion dropdown list for inputs bound to a datalist. Preferably in Chrome, but other browsers will do too.
I've found that by enabling the Shadow DOM setting in Chrome's inspector options allows me to inspect the shadow DOM for the actual input (which includes the ::-webkit-calendar-picker-indicator arrow to show the datepicker) but not the datepicker itself:
The same goes for the datalist. It appears as these controls are not part of the input, but I also can't find them anywhere else in the elements panel.
Is it possible to inspect such elements?
Small edit for clarification: I'm actually looking for which pseudo-classes apply to which controls. There's plenty of sites that list some of them, but I have yet to find a source that manages to list ::-webkit-calendar-picker-indicator for the datalist element, which does get applied. I'm looking for more of those sneaky bastards, and the best source for that of course is the horse's mouth.
Looks like the actual picker is loaded in an entirely different layer (basically a different window without the titlebar). So I guess the answer is: no, you can't.
I agree it would be great to be able to customize it. And similar popups too. Mozilla in XUL has display:popup which is used by context menus, flyout and similar things. Would be definitely great being able to use that in userland content too.
The calendar popup of Google Chrome is not in Shadow DOM.
It's in a separated page mapped to a popup window. See WebPagePopupImpl.cpp
And the popup content is written by HTML/JavaScript.

Strange issue with select options in IE9

I am working on a multiselect option with jQuery UI Multiselect. The items are all inside a jQuery UI accordion. On selecting items the UI is getting updated, and code is written for persisting the selection even if we switch to another panel in Accordion. Everything works fine in FF, Chrome, IE8, IE10 but not in IE9.
After debugging and comparing in IE Dev tools I found the following -
When I log inner html of select element in Dev Tools with
console.log(selectElement.html())
I am getting the "selected" attribute in IE9. And, when I want to remove "selected" attribute for each item manually like -
item.removeAttr("selected")
it shows error as undefined.
So, is there any issue with selected attribute in IE9?
Still couldn't figure out the exact reason and fix. But, resolved it through adding another attribute to tags.
If any one has any idea about this please post your thoughts.

Is there a tool to examine HTML page without clicking?

My problem is this - when I click the down button on any input control on my form in Chrome a popup window is displayed. I am positive my code does not do it. The fact that it happens only in Chrome makes me think of some misbehaving Chrome plugin/extension.
Anyway, I would like to see the HTML element responsible for this popup. However, I cannot find it in the dev tools and trying to focus on it does not work - the popup closes the moment I click the page.
So, my question - is there a easy way to get hold on this HTML element without clicking the page?
I am using Chrome 23.0.1271.64 with the following extensions (according to the Chrome itself):
Advanced REST client 3.0.30
JSONView 0.0.32
OneClickDownload 1.2 Web
Developer 0.4.1
This looks just like the standard input field suggestion box. I suspect it is not part of the web page. Therefore it won't appear in the DOM and you can't style it, because it is part of the browser not the web page (although it appears over the top of the web page).
You can suppress it by putting the attribute & value autocomplete=off on the form field, although that is from HTML5 and will not work in all browsers just yet. See Is there a W3C valid way to disable autocomplete in a HTML form?