Layout components

[atoy40]

Hello,

I'd like to know if it's planned to implement layout and content components found in the react or css implementation (flex, view, etc) ?

thks
Anthony.

[benjamind]

Can you explain what the advantage of these components is over just using css grid and flex capabilities?

[atoy40]

@benjamind IMHO, sure you can do it this way, but having layout components is useful to have coherent theming/styling (colors, pad/marg in respect to spectrum good practices, etc...), it also simplifies usage to just have to instanciate a WC with attributes .... I think it's all the same good reasons you have when you choose a WC/UI framework instead of doing everything yourself using raw html/css, and likely the same reasons thoses comps exist in the react implementation of spectrum ?

Anthony.

[benjamind]

Do we not get this consistency through the use of css custom properties though?

It seems to me to mostly just be more page weight for an arguably negligible improvement in developer experience, i.e. trading UX for DX.

Not only do developers using these components end up at another level of abstraction from what's really going on (css grid / css flexbox) they have to learn a non-standard api to use it. I'd argue that we would be better off laying out best practices for usage of these css capabilities with the spectrum css custom properties.

[benjamind]

To be clear I'm not saying we shouldn't do this. But I'm not yet convinced of the value for these components over just using the css equivalents.

[hunterloftis]

I agree that layout components are an area where it's better to err on the side of too little rather than too much. Otherwise, you just end up re-implementing some subset of CSS.

However, I do see some value in higher-order abstraction layout components. I've re-implemented the entire application frame for example, and an <sp-app-frame> codifying that design would have been welcome. A grid component that enforces the design requirements could also be useful.

[bengfarrell]

I kind of agree that some higher order offerings like the application frame would be nice. I'm almost wondering if it needs to be a component, though. There's no real interactivity to speak of, so it can be achieved alone with CSS. Plus in my work, my designer has some slight deviations from the Spectrum specs occasionally that make sense for our specific app. If things like these were a SWC, I'd probably need to override the component just for the purposes of altering the CSS. I think I'd much prefer consuming Spectrum CSS markup and patterns when I need a layout like this. AFAIK, the app frame patterns aren't even in Spectrum CSS yet though. Putting them in SWC might be jumping the gun a bit anyway until then, right?

[Westbrook]

@atoy40 in the context of layout components, I find them to be quite complex, varied, and the real question is not when/if you need to make them, but what line you draw at which you stop making them. At current, we draw that line at "we don't ship things that are not a part of Spectrum CSS". That may change over time, but for now it's an easy and clear line for us to draw. In particularly, I do worry about recreating a subset of CSS, and my vote will likely shy away from the <Flex>, <Grid>, <View> shaped offering that you see in something like React Spectrum as I feel they are more a representation of how that project restricts your access to styling content built with it in general as opposed to actually offering you a quality styling approach for you content or application.

If there are Spectrum patterns that are currently available on https://opensource.adobe.com/spectrum-css/index.html and you either don't find them in our published packages or tracked in some way as part of https://github.com/adobe/spectrum-web-components/projects/2, please submit specific issues so we can begin the discussion of prioritization and scoping the work required to ship them.

On the topic of content patterns, we do suggest that consumers of our library lean towards the raw Spectrum CSS approach in order to customize their content in accordance with the Spectrum specification. In that way, you can work directly with the Spectrum CSS packages or you can leverage as yet undocumented css literal tagged exports of the same specifically covering body styles, code styles, detail styles, and heading styles for ease on use in a lit-element context.

However, we are constantly reevaluating these sorts of decisions, especially as we expand to a larger user base, and would love to hear from you if you felt that there was a specific use case or cases that you work in that you feel would be better supported at our library level as opposed to your application level.