Replies: 2 comments
-
This sounds reasonable to me, since the alternative would be to have empty CSS files cluttering the repo. A |
Beta Was this translation helpful? Give feedback.
-
I don't think so. First, this would be in opposition to Franklin product patterns. I have yet to see a block that is JS only or a block that could not benefit from a little CSS. The reverse is also true for CSS only blocks. Maybe more importantly... const BLOCKS = [
marquee: {}, // both implied
aside: { js: true },
merch: { css: true },
]; It's bad enough we have to maintain a list in milo for what blocks we support, but then we would have more to maintain. This doesn't include the loadBlock code that would have to be changed and maintained to support such complexity. |
Beta Was this translation helpful? Give feedback.
-
As per https://github.com/adobecom/milo/blob/main/libs/utils/utils.js#L366, milo expects a block css file to be present. Lacking this, a corresponding 404 is surfaced to the client.
Since we're building (internal) tools with blocks and documents like any other regular content page, there is not always a need for a block css.
Should we consider relaxing a block css file being mandatory?
Beta Was this translation helpful? Give feedback.
All reactions