Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add scoped attribute back in to the standards #6228

Closed
jabcreations opened this issue Dec 15, 2020 · 2 comments
Closed

Add scoped attribute back in to the standards #6228

jabcreations opened this issue Dec 15, 2020 · 2 comments

Comments

@jabcreations
Copy link

For reasons that make no sense the scoped attribute was removed from the standards. Lack of implementation was one noted reason which is illogical, if some or even all browser vendors are too lazy to implement standards it does not negate developer demand or use.

The most important reason for the scoped attribute on my web platform has to do with HTML emails.

When we display HTML email from third parties on our platform we decode base64 and append any style elements to the primary XML container. We do not use iframes as it pointless convolutes the code. Currently this works fine for every browser engine as the styles tend to be self-contained. Until...

Our platform is Web 3.0. Each page is just part of the DOM, e.g. we don't throw away the entire DOM just to reload everything just because the user navigates to another page. What we've discovered is that the style element's CSS rules will in some circumstances start being applied to other pages (layers in the DOM) when the user navigates away from the page that displays that particular message (it's still in the DOM, no reason to unload it).

So now because scoped is not supported we're faced with having to minimally and wastefully remove the message DOM and store it in a fragment to keep it's styles (if it has any) from effecting other pages or wastefully delete the page layer. If the scoped element were properly supported no extra code would be required. No, we shouldn't be also wastefully wasting time rewriting third party code to modify their selectors, that would be yet another pointless endeavor.

Standardization was the second industrial revolution that took different factories that used different equipment that did the same things and standardized the parts they were composed of greatly reducing overall effort to be create said equipment. The same principal applies to web standards: the more effort that is required to accomplish the same goals the less overall productivity is accomplished in the end. Standards should implement support for what is needed to reduce the hassle for developers to make productive software and should not be dictated by any political fraud or apathy by outside groups such as browser vendors because historically such apathy has led to increased competition which is ultimately good for everyone.

@rniwa
Copy link
Collaborator

rniwa commented Dec 15, 2020

This seems like a duplicate of #4508.

@annevk
Copy link
Member

annevk commented Dec 15, 2020

Indeed, @jabcreations I recommend reading through https://whatwg.org/working-mode and in particular the Changes section.

@annevk annevk closed this as completed Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants