- From: Kuzcoo <notifications@github.com>
- Date: Sat, 16 Mar 2019 08:15:03 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Saturday, 16 March 2019 15:15:25 UTC
> I think one of the reasons for this rejection is that the use-cases for HTML imports have been so narrowly scoped to defining custom elements. But the reason to have HTML imports extends far, far beyond web components to the fundamentals of web page construction. I think this issue should leave on its own, as @matthew-dean clearly explained the problem at stake in the quote above. The #645 dicussion seems to be js oriented, and I think the @matthew-dean snippet is a very promising js free approach. We should forget highly dense js webapp for a moment, and think of a html/css first approach, progressively enhanced by js if supported/loaded/not breaking. All web apps are not rich and complex applications, but just a bunch of nav and form aggregations with strong visual identity, and we rely on heavy js client side render and tooling for a bunch of UI functionnal components. We should be able to load the html/css of the component even if the js is breaking or is disabled. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/677#issuecomment-473542554
Received on Saturday, 16 March 2019 15:15:25 UTC