Live data from Hacker News

Layout-Isolated Components

visly.app

21–30 of 36 posts

Re: Layout-Isolated Components

#21
It's crucial to account properly for relationships between components. The best approach to this I've encountered in over 20 years of web-related experience is found at https://every-layout.dev. Compose complex, responsive layouts from expertly crafted primitives, using axiomatic CSS, and positioning becomes a breeze. The non-layout-related styling can be handled however you like; my preference is emotion for component-scoped styles (`sx` prop and styledcomponent API FTW), and design tokens for colors and typographic scale. I've been meaning to write up my approach bc it's exciting to be freed (and free others) from fighting endless css battles.

Re: Layout-Isolated Components

#22
post #20

Earlier quoted context omitted.

Margins and align-self aren’t side-effects. Their semantics are consistent and reproducible and depend only on the context a component is placed in, just as a property like width does. They’re awkward because they have bigger knock-on effects on the overall layout of components within the parent. In an OO mindset, I see this as being all about what interfaces your object exposes. For something like a button or slider…

Their semantics might be consistent, but they sort of leak into the parent. Height and width are local to what the component renders, and they don't depend on the parent (as long as they aren't relative sizes). But things like margin and align-self change how the parent renders all of its children. In other words, the view rendered by the component is a function of properties like height and width. But when you throw…

Yeah, I think we’re mostly agreeing! Encapsulation and isolation are the key bits, and both FP and OO suggest ways to achieve them.

Re: Layout-Isolated Components

#23

A fundamental problem of building isolated components in HTML/CSS is that the CSS `display` property sets both an element's inner layout (how it lays out its children) and its outer layout (how it is laid inside it parent). E.g. you have to make an element "display: inline-flex" to make it an inline flexbox. You can't just make it "flex" and have the parent decide whether it is inline, a block or whatever. The conseq…

Child selectors (including eg "adjacent siblings") can solve the hardest part of this problem. Some layouts require a wrapper element, but that is just a minor inconvenience, doesn't have to be a blocker. See https://every-layout.dev

Re: Layout-Isolated Components

#24

It's crucial to account properly for relationships between components. The best approach to this I've encountered in over 20 years of web-related experience is found at https://every-layout.dev . Compose complex, responsive layouts from expertly crafted primitives, using axiomatic CSS, and positioning becomes a breeze. The non-layout-related styling can be handled however you like; my preference is emotion for compon…

I hope you do write it up!

Here's a working link:

https://every-layout.dev/

Re: Layout-Isolated Components

#25

A fundamental problem of building isolated components in HTML/CSS is that the CSS `display` property sets both an element's inner layout (how it lays out its children) and its outer layout (how it is laid inside it parent). E.g. you have to make an element "display: inline-flex" to make it an inline flexbox. You can't just make it "flex" and have the parent decide whether it is inline, a block or whatever. The conseq…

Your vitriol towards CSSWG is misplaced. The CSSWG didn't remove the functionality of `display-inside` and `display-outside`, they just made `display` multi-valued so you can write `display: inline grid`.

https://developer.mozilla.org/en-US/docs/Web/CSS/display https://developer.mozilla.org/en-US/docs/Web/CSS/display-ins...

Re: Layout-Isolated Components

#26
The usefulness of this articled is lessened because it's React-specific and React is bad with DOM and style isolation in general.

The base problem here is that both a component and its host may want to style the component. The component model should account for this and offer some guidance.

Web components do this with the `:host` selector that styles the component from within its shadow root. The styles applied with the `:host` selector can be overridden by the outside styles, without the component needing to weaken encapsulation by allowing styling from the outside via JS properties. This means it's not really bad for a component to give itself default outside styling like block vs inline display, or even margins, because the user can always reset them as needed, much like built-in elements.

For instance, a web component might have these styles:

    
      #shadow-root
        :host {
          margin: 1em;
        }
And at its use-site, the margins can be set differently:

    
      my-element {
        margin-botton: 0;
      }
    
    ...
    
    ...
Shadow DOM also helps with specificity fights, as the cascade goes: shadow style -> light style -> light !important -> shadow !important. This way a component can define which styles are only defaults.

Edit to clarify: one of the big problems with the article is the use of inline styles. They have the highest specificity and there's no built-in way to "merge" inline styles like you normally get via inheritance and the cascade.

Re: Layout-Isolated Components

#27

The usefulness of this articled is lessened because it's React-specific and React is bad with DOM and style isolation in general. The base problem here is that both a component and its host may want to style the component. The component model should account for this and offer some guidance. Web components do this with the `:host` selector that styles the component from within its shadow root. The styles applied with…

[deleted]

Re: Layout-Isolated Components

#28

The usefulness of this articled is lessened because it's React-specific and React is bad with DOM and style isolation in general. The base problem here is that both a component and its host may want to style the component. The component model should account for this and offer some guidance. Web components do this with the `:host` selector that styles the component from within its shadow root. The styles applied with…

    const MyComponent: React.FC = (props) => {props.children}
I don't see any issue; additionally, it's well typed and you have fine control over it!

Re: Layout-Isolated Components

#29
post #24

It's crucial to account properly for relationships between components. The best approach to this I've encountered in over 20 years of web-related experience is found at https://every-layout.dev . Compose complex, responsive layouts from expertly crafted primitives, using axiomatic CSS, and positioning becomes a breeze. The non-layout-related styling can be handled however you like; my preference is emotion for compon…

I hope you do write it up! Here's a working link: https://every-layout.dev/

Thanks! (fixed link)

Re: Layout-Isolated Components

#30

The usefulness of this articled is lessened because it's React-specific and React is bad with DOM and style isolation in general. The base problem here is that both a component and its host may want to style the component. The component model should account for this and offer some guidance. Web components do this with the `:host` selector that styles the component from within its shadow root. The styles applied with…

const MyComponent: React.FC = (props) => {props.children} I don't see any issue; additionally, it's well typed and you have fine control over it!

That's not stylable from CSS though, so you have to pass JS props and can't use selectors. It also duplicates styling strings across all similar style attributes which is not good for memory or perf.
Post reply on HN