[crud] It is really difficult to style the fields inside the editor/form

[jouni]

I would like to customize the widths of certain fields inside the form, but it’s really difficult to get styles injected in the right scope so that they apply to the form inside the dialog.

Partially related: https://github.com/vaadin/vaadin-form-layout/issues/96

[jouni]

We should expand the “custom form” example to show you can change the widths of the fields.

[manolo]

User can provide any form, not necessarily a form-layout, we recommend that because of responsiveness. Probably some form-layout conventions adding certain attributes to fields might be useful

[jouni]

Well, I meant that it seems rather difficult to provide extra styles for the form that you provide. Is it possible to wrap the whole form into a new custom element, and provide styles inside that?

[manolo]

True, the auto-generated form does not have any way to style, not sure about wrapping it, but we need to figure out a solution anyways

[jouni]

True, the auto-generated form does not have any way to style

Even if you provide your own form there’s no way to style that easily. It’s always behind at least one shadow root.

[manolo]

It’s always behind at least one shadow root

You can provide your own dom structure, it's not mandatory to nest your fields in a vaadin-form-layout, so in theory the user might e.g. add a component made with designer, etc

[jouni]

Hmm, seems like I was wrong about this. I thought that since the dialog is being created/attached inside the CRUD’s shadow DOM, the contents that are rendered inside it would automatically also be inside a shadow root inside the dialog-overlay.

But now that I actually tested it, the form is nicely in the light dom of the dialog-overlay.

So, a custom form always ends up in the global style scope? Does that seem right?

[manolo]

Yes, user's custom form is directly available in global scope, unlike generated form that is in the default slot inside shadow roots (probably we might move that with code)

[jouni]

Basically, I would like us to have an example where the form field widths are customized. Currently I don’t know how to do that, except by copy-pasting a <style> element from the example code to demo/index.html

[manolo]

You can follow the same pattern than in text-field, the styles to apply are in index.html and need to be in sync with the demo snippet which is shown to the user. Take a look to these blocks:

https://github.com/vaadin/vaadin-text-field/blob/master/demo/text-field-styling-demos.html#L21 https://github.com/vaadin/vaadin-text-field/blob/master/demo/index.html#L25

[jouni]

Yeah, I wrote that example 😄

a custom form always ends up in the global style scope? Does that seem right?

Yes, user's custom form is directly available in global scope

I was referring to the fact that an app, the crud component, together with the form inside it, can potentially be inside some “view component” with its own shadow root. In that case you’d expect form to also be inside that style scope and you should be able to style inside that style scope.

So I was trying this (it doesn’t work, the text is not red):

<dom-module id="foo-bar">
  <template>
    <style>
      .red {
        color: red !important;
      }
    </style>
    <vaadin-crud>
     <span class="red" slot="form">text</span>
    </vaadin-crud>
  </template>
  <script>
    class foo extends Polymer.Element {
      static get is() {
        return 'foo-bar';
      }
    }
    customElements.define('foo-bar', foo);
  </script>
</dom-module>

But this is the known limitation with <vaadin-overlay> basically. I suppose I was thrown off because now there’s no <template> element in between.

<vaadin-crud>
  <template slot="form">
    <vaadin-form-layout>
      ...
    </vaadin-form-layout>
  </template>
</vaadin-crud>

Just to illustrate the difference. I’m not suggesting we force users to add the extra <template>. Just documenting my thoughts and learning journey.

[web-padawan]

Related to #503