[HN Gopher] Declarative Shadow DOM
___________________________________________________________________
Declarative Shadow DOM
Author : ingve
Score : 117 points
Date : 2023-02-13 18:50 UTC (4 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| pyrolistical wrote:
| Can't wait for this to be everywhere. React was amazing to get us
| where we are today but this shadow dom without js will allow
| server side rendering components without react
| misterbwong wrote:
| After this TP gets released, it looks like FF will be the only
| outlier[1]
|
| [1] https://caniuse.com/declarative-shadow-dom
| j79 wrote:
| Thankfully Firefox recently changed their stance from
| "Neutral" to "Positive".
|
| https://github.com/mozilla/standards-positions/pull/740
|
| > Neutral stance: We're not convinced that the complexity
| this feature introduces upon the HTML parser carries its
| weight in terms of usefulness for web developers. There's
| also a risk that the processing model is not compatible with
| a future declarative custom elements feature as it was
| developed in isolation. Having said that, the proposal is a
| reasonable approach for this functionality that takes into
| account the various constraints and security considerations
| that come with changing the HTML parser.
|
| > Positive Stance: This is a reasonable proposal which takes
| into account the various constraints and security
| considerations that come with changing the HTML parser.
|
| Hopefully that's a sign of things to come! (Fingers crossed)
| dmitriid wrote:
| You don't need React to server-side render anything, including
| components.
|
| Besides, if you need components, web components are probably
| the last thing you want to reach for.
|
| Edit: Also, none of the major frameworks, and very few of the
| new frameworks target web components for many reason fully
| ignored by browser vendors. They can "consume" them (that is
| embed them in code), but at most compile to web components,
| reluctantly. And still provide components and SSR, and have for
| years.
| lab14 wrote:
| Why would you need react to render server side components?
| whatever1 wrote:
| With this SSR trend do we now need three job families ? The front
| end engineer, the render-backend engineer and the api-backend
| engineer?
| wizzwizz4 wrote:
| You're forgetting the UX designer, the UI designer, the UX
| researcher, the UI translator, the database administrator, the
| system administrator...
|
| We have always been able to break complex tasks down into
| multiple, simpler job descriptions. That doesn't mean each
| person is limited to doing at most one of them.
| chrisweekly wrote:
| I've seen candidates describe themselves as "Front of the
| Front-End" in the context of job interviews where the web UI
| stack included a BFF (Backend-for-Frontend, eg Next.js or
| Remix). It actually makes sense. The corresponding "Back of the
| FE" skillset encompasses proxy servers, API gateways, routing,
| observability, browser networking, server APIs, deployment
| infr, etc., on top of pure UI per se. There's a breadth of
| knowledge required that puts many backend-oriented "full-stack"
| devs to shame.
| mgerdts wrote:
| I first encountered shadow roots while trying to use tampermonkey
| to work around a problem with the latest release of Gerrit. What
| I thought would be a relatively trivial effort to find the right
| element and modify its style turned into a lot more effort.
|
| https://gist.github.com/mgerdts/f508ae81795097397106156fa291...
|
| While I get that the purpose of the shadow roots is to provide
| isolation, is there a simple way to break through that isolation
| without manually walking the DOM tree and traversing all of the
| .shadowRoot elements?
|
| It seems Gerrit wraps most elements with a shadow root. For
| someone that doesn't do front-end development, is there an
| explanation for how this is helpful?
| tehbeard wrote:
| > This meant that this feature was not available when JavaScript
| is disabled such as in email clients
|
| This reason to be add it seems, really out of touch with reality.
|
| I mean, most of html is not available, or horrendously borked in
| email clients. Hence the continuation of table within table
| within table to make anything other than plain text.
| rektide wrote:
| Nolan Lawson's recent talk on CSS Runtime Performance[1] show
| some pretty amazing styling performance wins for Shadow DOM. It's
| nice we can do more of this easily!
|
| I think this should all work outside <template> tags. Re-
| remembering how they worked slowed down my comprehension some.
| The MDN article[2] was a solid refresher.
|
| [1] https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-
| pe...
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/Web_Components/...
| di4na wrote:
| So as someone that work only with server side rendered stuff, you
| know, no JS on the browser and css loaded as one big blob, is
| there something useful for me here? I feel i am missing the point
| completely...
|
| I really feel like html has been totally forgotten by the power
| that be that work on CSS...
| ljm wrote:
| Do you realise that if you only work with server-side code, you
| can't use client-side code?
| di4na wrote:
| Yes? That is kinda my point?
| ljm wrote:
| It seems like Web Components want to take the place
| di4na wrote:
| Except web components are client side only.
| rezonant wrote:
| A sibling thread mentions performance improvements, so maybe?
| di4na wrote:
| I mean afaict rn the perf improvement need me to inject the
| style in the shadow dom element. So tons of small css,
| possibly with duplications and less compression, or css in
| style elements.
|
| That... Can be useful but kinda problematic
| koolala wrote:
| Isn't it similar to a generic idea like Object Oriented
| programming? It's a pattern that can work on a server or a
| client. Unless your server isn't using a DOM of course.
| ricardobeat wrote:
| > many modern websites and web-based applications deploy a
| technique called "server-side rendering" whereby programs running
| on a web server generate HTML markup with the initial content for
| web browsers to consume, instead of fetching content over the
| network once scripts are loaded
|
| I chuckled reading this. It's like someone landed in 2020 and
| learned web development while being completely unaware of events
| in the preceding decade.
| superkuh wrote:
| It's like Isaac Asimov's short story, "A Feeling of Power"
| about a far future where humanity had forgotten how to do math
| manually and relied entirely on expensive computers to do it.
| But then a technician discovered the rules of arithmetic on
| paper and the revolutionary new human powered "graphitics"
| allowed them to win "the war".
| dmitriid wrote:
| > It's like someone landed in 2020 and learned web development
| while being completely unaware of events in the preceding
| decade.
|
| To quote Rich Harris, the author of Svelte, on the whole web
| component saga: "It's almost as if congealing 2010-era best
| practices in the platform before we'd finished exploring this
| territory was a mistake" [1]
|
| [1] https://twitter.com/Rich_Harris/status/1513668040784814084
| [deleted]
| CharlesW wrote:
| > _I chuckled reading this. It's like someone landed in 2020
| and learned web development while being completely unaware of
| events in the preceding decade._
|
| Note that they mean SSR specifically here vs. just server-
| generated web pages. Server-rendering of component updates is a
| post-SPA innovation (2018?), so it still seems worth explaining
| for most web developers.
| dvt wrote:
| > Server-rendering of component updates is a post-SPA
| innovation (2018?), so it still seems worth explaining for
| most web developers.
|
| Absolutely not true. I was doing this in 2009 and so were
| many other people (albeit through janky XMLHttpRequest via
| PHP polling ways).
| CharlesW wrote:
| Agreed, it was super common. I'm attempting to say
| something slightly different, which is that SSR -- as a
| technique that was codified, named, and supported in modern
| frameworks -- first appeared around 2018 by my
| recollection, and so may be a new-ish concept for many web
| developers.
|
| My assumption is that the WebKit team understands their
| average web developer (which may be notably different than
| an average HN developer) enough to know whether an
| explanation is worthwhile.
| jalino23 wrote:
| client-side rendering was coined because server-side rendering
| was the default. now that client-side rendering is ubiquitous,
| being explicit about server-side rending became necessary and
| along lost in translation became "technique" - is what I think
| happened here.
| [deleted]
| azangru wrote:
| Is the repeated inclusion of the <style> tag into every copy of a
| declaratively rendered component -- with the same css strings
| repeated every time for every instance of a component -- a
| concern at all?
| spankalee wrote:
| gzip/brotli handles this very well, but it still is text to
| parse through.
|
| Some form of declarative CSS module scripts would help a lot. A
| feature request for that here:
| https://github.com/WICG/webcomponents/issues/939
| mattigames wrote:
| You can use good old regular link tags as well to avoid that
| kind of repetition.
| schemescape wrote:
| I'm not familiar with Shadow DOM. The links in the article seem
| to indicate that the main use case is working around how CSS
| styling works.
|
| Surely there is more to it than that. What am I missing?
| 88913527 wrote:
| Shadow DOM isn't a totally sandboxed construct, though it
| mostly is. You can't load font-face's within shadow dom's. They
| have to be defined in light dom, and then are available in
| shadow dom. Most other CSS styling seems to be totally
| isolated, given this exception.
|
| It appears custom CSS properties pierce through as well.
| https://open-wc.org/guides/knowledge/styling/styles-piercing...
| infogulch wrote:
| There was a thing called "scoped css" back in 2012 that never
| went anywhere which seems similar. But I think Shadow DOM also
| mixes in some notion of DOM access protection iirc. Also
| interested in a description of what shadow dom is and what it
| can be used for.
|
| https://developer.chrome.com/blog/a-new-experimental-feature...
| a13o wrote:
| The isolation was primarily designed with Web Components in
| mind, but it's popular as well in browser extensions. Content-
| scripts might want to inject elements into a host page without
| being subject to that page's styles or JavaScript. (e.g. the
| host page calling normalize() on their DOM.)
| throwaway894345 wrote:
| It exists to help you define components without running into
| naming conflicts. For example, if I want to make a "my-button"
| component that has a <button class="button"> and some CSS that
| targets `.button { ... }`, I won't end up styling a bunch of
| other things that have `class=button`. Pretty sure it also
| protects against other things doing
| `document.getElementById("button")` and getting the element
| whose ID is `button` from your component instead of whatever
| the caller was expecting. Effectively, shadow DOM provides
| _encapsulation_.
| riquito wrote:
| That's true, but they didn't ratify yet a standard on how to
| handle web components naming collision, so if you create `my-
| button` and another developer register `my-button`... Or if
| you want to use two different version of your own `my-
| button`...
|
| This is the proposal for scoped elements:
| https://github.com/WICG/webcomponents/blob/gh-
| pages/proposal...
| rossmohax wrote:
| Is it accurate to mentally model this feature as browser
| mounting/applying CSS not to the document, but to the
| arbitrary DOM element in it?
| mrassili wrote:
| Indeed, Shadow DOM is a great way to isolate styles when
| working with browser extensions. In fact I've made a tutorial
| and it shows how CSS is scoped to the extension without
| interfering with any website style:
| https://www.freecodecamp.org/news/chrome-extension-with-parc...
| no_wizard wrote:
| Does this mean we'll finally get Template-Instantiation[0],
| providing a native way to do HTML templates in the browser?
|
| There's been a bunch of hand waving that the reason we still
| don't have this is because they needed a solution for
| encapsulation and a solution for SSR. Now we have both. Can we
| please finally deliver on something people have been asking for
| since the mid 2000s?
|
| [0]: https://github.com/WICG/webcomponents/blob/gh-
| pages/proposal...
| spankalee wrote:
| Declarative shadow roots and Template Instantiation are very
| different proposals with no overlap.
|
| The only relation here is that with some critical feature done
| like this and shadow selection, there will be more time to work
| on Template Instantiation.
| no_wizard wrote:
| I know, as I highlighted, it appears to me that all the
| hurdles for Template Instantiation have been passed, and its
| about time we start to see actual movement and traction on
| this.
|
| its been in the pipeline since 2017 with little major
| movement on it, while a bunch of things developers didn't
| actually ask for have managed to have more precedence.
| Whenever I've pressed for reasons for this, it gets hand
| waved away that they need solutions for SSR and
| encapsulation. We have both now.
|
| Honestly should have shipped day one with Web Components,
| would have made it far more compelling. It has always felt
| like such a big miss to me by the standards bodies that this
| didn't get attention.
| rickstanley wrote:
| Very good! I can already see Lit-Element[0], one of the
| beneficiaries, leveraging this!
|
| When I first started writing/exploring Shadow DOM API I felt so
| weird writing inline `class`, but then again, it's just a
| syntactic sugar for prototype functions.
|
| - [0]: https://lit.dev/docs/ssr/overview/
| azangru wrote:
| > I felt so weird writing inline `class`, but then again, it's
| just a syntactic sugar for prototype functions
|
| You felt weird using standard ES6 syntax? Did you prefer
| writing Thing.prototype.method = function(){}... ? Or
| Derived.prototype = Object.create(Base.prototype)?
| rezonant wrote:
| I think they mean class expression (ie const c = class {})
| versus class declaration (class c {}). Both are indeed ES
| standard though.
| jacobr wrote:
| Almost all examples of Shadow DOM uses Custom Elements, but
| that's not required. I think this conflation harms adoption of
| Shadow DOM.
|
| As an example of what you can use the Shadow DOM for - it works
| fine as the node to render a React app/component in. So if you
| need a couple of React components on a page to not affect each
| others style, you can do React.createRoot(myShadowRoot) and
| they're fully encapsulated.
| MuffinFlavored wrote:
| When would somebody want to use Shadow DOM instead of just the
| regular DOM? Is shadow DOM the next incarnation of the previous
| fad before it (virtual DOM)?
| vhiremath4 wrote:
| When you have an extension that modifies a given page/injects
| them with some elements and you don't want the class names or
| styles of those elements to interfere with the class names
| and styles of the parent page. There are lots of extensions
| like this.
| ithkuil wrote:
| It scopes styling
| skerit wrote:
| Finally. Not being able to pre-render shadow dom on the server is
| what made me just skip it entirely.
| tambourine_man wrote:
| When people start claiming that Safari is the new IE, dragging
| its feet, etc, I just point them to the WebKit blog. Apple just
| has different priorities and visions for the Web than Google.
| taeric wrote:
| So, it is exactly like IE, in many ways? :D
|
| It isn't like IE was completely lacking of innovation. To wit,
| div/span/XMLHttpRequest/BorderBox. Lots of things did come from
| there. I remember they used fieldset and legend in a much
| cleaner way, too.
___________________________________________________________________
(page generated 2023-02-13 23:00 UTC)