Remove <Host/> component

Is your feature request related to a problem?

If it’s "possible to remove <Host/>, let’s remove it.

Describe the solution you’d like

Idea from a discussion @mhevery and I just had:

• Internally, there always needs to be an actual actual <div> (or whatever) host component
• However, what if the <Host/> component user’s write never existed at all, it’s not something they import and use
• And the “host” component qwik generates, ALWAYS is display: contents??
• So “qwik’s” host is kinda never really there to begin with.
• It’s a host element for qwik to interact with, but it’s not something to the user has to worry about since it’s basically silent.
• The “user’s” host is whatever the heck they want it to be, or no host at all
• Exactly like react in how it can return a top level element, or a fragment with an array of children

So user could return

return (
  <footer>my footer</footer>
)

And qwik would generate

<div q:host>
  <footer>myfooter</footer>
</div>

Or the user could return

return (
  <Fragment>
    <span>a</span>
    <span>b</span>
  </Fragment>
)

And qwik would generate

<div q:host>
    <span>a</span>
    <span>b</span>
</div>

And now the component’s css would flow how they’d expect, and their component could continue act like display inline if that’s what the top level components were. Just like how react devs would expect their components to render and flow.

This allows us to completely remove <Host/>, and now users wouldn’t have to worry about adding { tagName: 'footer' }, which are both strange to traditional JSX frameworks.

export default component$(() => { 
    return (
      <Host>
        <ul>
          ...
        </ul>
      </Host>
    );
  },
  {
    tagName: 'footer',
  }
);

becomes

export default component$(() => {
    return (
      <footer>
        <ul>...</ul>
      </footer>
    );
  } 
);

I also think this makes the internal code much easier now, because it doesn’t have to worry about merging attributes.

For example, let’s say that below is a React app.

export default function App() {
  return (
    <div>
      <CmpA style={ { color: 'red' } }/>
    </div>
  );
}

function CmpA() {
  return (
    <>
      <h1>Hello!</h1>
    </>
  );
}

The red color styles wouldn’t actually apply to the h1, cuz what would the “style” be getting assigned to? It’s a component prop, not an actual attribute. The example above wouldn’t work in React (which is expected).

Thoughts

Describe alternatives you’ve considered

Keep <Host/> :

Additional context

No response

[adamdbradley]

Ok, I wasn’t aware of the accessibility tree issues. Here’s the latest research: https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-mostly-safari-still-break-accessibility-via-display-properties.html

[manucorporat]

I am all for removing the host element, but technically extremely challenging. If we cant remove the actual host element, we cant remove apis to control it, aka <Host/> but I guess some better default like display:contents makes it less of a pain.

Also, i also find it arbitrary that we default to <div>