We need to override the default render for "Action.Submit" element (we just need to remove "aria-label" attribute from HTML that is generated by default).
But regarding this documentation: https://learn.microsoft.com/en-us/adaptive-cards/sdk/rendering-cards/javascript/extensibility it is required using TypeScript.
Also, the above documentation provides only creating the new element, but not extending the existing element.
Please, could anyone provide the example how to override default render for any standard AdaptiveCard element with using plain JS?
Thank you in advance.
Related
One of the brilliant features in Vue.js is the ability to assign new attributes to a specific element in the template. known as Transparent Wrapper Components
In this sample, I can send all existing HTML attributes to a specific element. (in here with v-bind="$attrs" for input)
How to assign all existing HTML attributes to a specific element of a template without coping as binding property in Angular 6+?
I don't think you can do this out of the box, and I think that is by design.
Its kind of ugly but I got similar functionality writing a BindAttrsDirective here:
https://stackblitz.com/edit/angular-bind-attrs
Note: won't support SSR
Can anyone guide me about this? Can Stencil.js add Custom attribute / Directive like Aurelia/Angular to existing elements or not?
I don't find any doc about this on their site. Only creating a new component nothing about extending existing elements.
I want to add a custom attribute to div or any HTML element Is it possible in Stencil.js?
Attribute-based components aren't possible with Stencil. The library implements the Custom Elements spec, which only works with tags.
Extending existing elements isn't supported either. The spec allows extensions of builtins, but it isn't implemented in Stencil and browser support is limited.
I'm seeing weird behaviour when using containerless functionality for aurelia components. We're creating custom elements for in SVG container, which required us to use containerless tag to strip the custom element tags before adding it to the DOM, as only SVGElements tags are allowed within a SVG container.
We're using Aurelia release version 1.0.0 and build our SPA with webpack.
Here you can find a gistrun example which displays the 2 implementation of containerless usage.
https://gist.run/?id=58ba6282ad54c1263eec3a141fe42183
In this example i've created 2 viewmodels and bind this to our custom elements. Using as-element="compose" to tell aurelia that i've created the viewmodel and that Aurelia shouldnt create a VM. The difference between these to custom elements are the containerless tag:
CustomElement doesnt have the #containerless tag in the Viewmodel but have 'containerless' in the HTML view.
withattr component does'nt have 'containerless' in the HTML view, but it does have the #containerless tag in the Viewmodel, as described in the Aurelia HUB.
I expect in both situations that I would see a blue rectangle. customelement tags are stripped by Aurelia because of the containerless tag. however the #containerless tag doesnt seems to work, as in implementation 2.
Question:
Any clue why these implementation have different outputs?
Which is the correct one? I would expect 2, as stated in the Aurelia Docs that the #containerless tag should be placed on the viewmodel.
Any help would be appreciated :)
The #containerless decorator works directly on the element you place it on.
What's happening is that the decorator is applied to your withattr element, but as-element="compose" turns it into a compose element under the hood. This compose element then does not have the #containerless tag applied to it.
Likewise, with your customelement you are in fact not applying #containerless to customelement, but to the compose that it is turned into.
Remove the as-element="compose" part and simply declare your <withattr/> element naked in the markup, and containerless will work because the actual element will still be withattr.
Note that it's not recommended to use #containerless with as-element unless there is no other way to accomplish something, as is the case with using custom elements inside table elements.
Why not simply have a compose inside your custom element, and bind the path to the view through a bindable property on the custom element?
EDIT
Sorry, I kind of overlooked the fact that you wanted to specify your own ViewModel instance.
This requirement limits you to using the compose element because that's the only way Aurelia supports providing your own ViewModel instance.
It's also certain that you need #containerless. And you need that #containerless to be on the compose element.
Conclusion, your first solution seems perfectly fine from a technical perspective.
As a matter of personal preference, I would do this:
<compose containerless view.bind="'./customelement.html'" view-model.bind="customElementViewModel"/>
Instead of this:
<customelement containerless as-element="compose" view-model.bind="customElementViewModel"/>
To be a little more flexible with dynamic views, make it clearer that we're using compose, and not having to <require> the view. But that really boils down to preference and other requirements.
I built an application using Polymer and its working as intended. I'd like to style it with a totally custom look and feel.
Is it possible to disable default styling of Polymer elements via a flag or some roundabout way, or will I have to manually override everything I want to change?
To override an element's styles from the outside, you can use ::shadow and /deep/:
http://www.polymer-project.org/articles/styling-elements.html#style-fromoutside
Those pierce through the Shadow DOM boundaries and allow you to target nodes internal to the element. Unfortunately, this means you need to explicitly write rules that target these nodes. This is sort of the deal with components...an author defines the look and feel, but you're welcome to override it as consumer/developer.
It's also worth noting that the visual elements use the non-visual core-*/polymer-* elements to get their job done. If you need a completely different UI, I'd create an element that reuses those core elements.
I am working with a server-side framework that will not allow the creation of some new HTML 5 attributes. Though eventually it will be upgraded to allow, I need a temporary fix to insert attributes such as placeholder.
The jsFiddle below creates the attribute with js/jQuery from a pseudo-attribute class.
Are there any downsides to this method (other than its hackishness)
Is there a better way?
http://jsfiddle.net/luke_charde/HCMUJ/
Well you could use the jQuery "metadata" plugin, which would allow you to migrate your class-based attribute scheme to something like "data-foo" (if you wanted to) later without having to change the JS code.
However I don't see anything particularly wrong with what you've done, though because I'm lazy I'd probably have picked a shorter marker string :-)