You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: