I've defined a draggable element (menu) and its handle, which is nested (menuHandle).
There's a droppable element elsewhere. Apparently, setting the droppable's accept property to menuHandle does not work and it must be set to menu.
How can a droppable element accept a draggable handle instead of the entire draggable element?
Related
I'm writing a custom input element called fancy-input, which can participate in a form via the FormInternals API. In particular, the ElementInternals.labels property gives me a list of the label elements associated, via their for attributes, to an instance of fancy-input.
But now let's say I also want to write a custom label element called fancy-label. It renders a native label element in its shadow DOM with fancy styles, formatting, etc. How do make it known that an instance of fancy-label is the "label" associated with an instance of fancy-input. In particular, I'd like my fancy-label node appear in the NodeList returned by calling ElementInternals.labels on the associated fancy-input element.
One possible approach would be for fancy-label to render a native label into a slot, keeping it in the light DOM and, hence, visible to the form and the fancy-input element. But is there a solution with the native label in the shadow DOM of fancy-label?
I have created a custom header component ( a child component within the component containing ag-grid). The header component will add some buttons along with the header name. While clicking on the buttons, the column field has to change accordingly. The code to change column definition is in parent component. I could achieve this functionality with normal buttons within the parent component. But while using header component, I don't know how to pass which button has been clicked from child (header) to parent (ag-grid). If I use event bus, (Subject and Observer) I couldn't specify the header component in grid options (shows type error). Event emitter is not working.
As the title states: Will focus still be set on form controls with autofocus="autofocus" even if they are hidden with display: none; or visibility: hidden;?
If your question is whether a hidden field can steal autofocus from a visible one, the answer is no.
Hidden fields with an autofocus property get focus when they are made visible.
Here's a jsFiddle that shows what happens if you have a visible field and a hidden field, then show the hidden field.
And here's a variation that demonstrates what happens if the visible field does not have an autofocus property.
The HTML5 draft standard only requires that an element be "focusable" where focusable means:
An element is focusable if the user agent's default behavior allows it
to be focusable or if the element is specially focusable, but only if
the element is either being rendered or is a descendant of a canvas
element that represents embedded content.
User agents should make the following elements focusable, unless platform conventions dictate otherwise:
a elements that have an href attribute
link elements that have an href attribute
button elements that are not disabled
input elements whose type attribute are not in the Hidden state and that are not disabled
select elements that are not disabled
textarea elements that are not disabled
command elements that do not have a disabled attribute
Elements with a draggable attribute set, if that would enable the user agent to allow the user to begin a drag operations for those
elements without the use of a pointing device
Editing hosts
Browsing context containers
It does say "but only if the element is either being rendered..." and the standard defines "rendered" as:
An element is being rendered if it is in a Document, either its parent
node is itself being rendered or it is the Document node, and it is
not explicitly excluded from the rendering using either:
the CSS 'display' property's 'none' value, or
the 'visibility' property's 'collapse' value unless it is being treated as equivalent to the 'hidden' value, or
some equivalent in other styling languages.
Just being off-screen does not mean the element is not being rendered. The presence of the hidden attribute normally means the
element is not being rendered, though this might be overridden by the
style sheets.
User agents that do not honor author-level CSS style sheets are nonetheless expected to act as if they applied the CSS rules given in
these sections in a manner consistent with this specification and the
relevant CSS and Unicode specifications.
In short, the answer appears to be that if all other requirements are met then display:none won't be focused but display:hidden will - Assuming all browsers actually follow the spec.
I was studying the jQuery UI Sortable widget and it said that all callback functions receive a ui object. Two of its properties are ui.helper nad ui.item. ui.helper is mentioned to be mostly a clone of ui.item, but I can't get the significance of calling it 'helper'. Also, the offset and position properties are defined in terms of the helper and not the item. What's the difference between the two ?
One of the answers mention that the helper fills the void, but the I read in the docs that the helper element is "used for dragging display". What exactly is this helper element and why is it named so?
From what I understand ui.helper is a "clone" of the ui.item. It is cloned so you can edit it with css and make it look like whatever you want it to look like while you are dragging it and it won't effect the original ui.item. So if you had a box and while it was being dragged you wanted it to turn into a blue box with curved edges but only while it was dragging you can by modifying ui.helper.
The helper is the element that fills the void (with visibility: hidden) when the item is dragged.
How do you constrain the elements of a PanelPositioned so they can only be dragged within the current panel? I have two vertical lists of different data types, one above the other. Both use a PanelPositioned to allow drag & drop reordering, but the elements can be dragged up and down to the other panel, generating an error
<ice:panelPositioned id="dragPanel1" var="dataType1var"
value="#{displayBean.dataType1List}" constraint="vertical">
<ice:panelGroup style="cursor:move;">
</ice:panelGroup>
</ice:panelPositioned>
<ice:panelPositioned id="dragPanel2" var="dataType2var"
value="#{displayBean.dataType2List}" constraint="vertical">
<ice:panelGroup style="cursor:move;">
</ice:panelGroup>
</ice:panelPositioned>
For icefaces 3.0, add a beforeChangeListener to the ice:panelPositioned element. This listener should then call event.cancel() if the event.getType() != to PanelPositionedEvent.TYPE_MOVE and the event.getIndex() and event.getOldIndex() are both greater than 1. If it is a move, then it is within panel. add/delete are moving between panels.
For icefaces 1.8.2 (neve used 2.0), you would need to add a listener to the ice:panelPositioned element. There is no beforeChangeListener. you will need a before list and current list (two copies). Both initialize to same elements when initializing backing bean. The listener, if a move - set before list to current list otherwise set current list to before list. Must be a copy, not a reference.