Re: [csswg-drafts] [css-scoping] Support for CSS namespaces

**Motivation :**  _(TL;DR - skip to next paragraph for thoughts on implementation)_
I wholeheartedly support the idea of scopes that don't leak to the outside while taking rules, but allow to change the appearance by rules from the outside.  
I would like to be wrong, but I fear that this feature has so little interest because of poor Internet health in terms of decentralization, where independent HTML authors are all but extinct and the use-cases debated by the consortium are dominated by 'web apps' for proprietary commercial use, with little sharing of free-form content and minimum trust between parties.  
For example, for the big web companies like Google, most important use case for web components is _"being able to have proprietary components that people are able to use on their websites, but they won't be able to tamper with"_, hence so much interest in shielding from the outside in their push for web components.  
While I agree that 'secure by default' must be always be applied, I feel that not leaving even an option (!) for openness to easily reuse, with unfettered modification, leaves out the needs of communities that thrive on trust, openness and invitation to use existent work and take it further. Many usages of hypertext are limited to 'thoughts exchange', where the security concerns of web applications are completely acceptable! So far, I always thought that these communities' interests were always well taken care of by all W3C standards (e.g. JavaScript being open and malleable, HTML being open and linkable and CSS's being pretty much always overrideable through cascading, RDF being infinitely extensible), but the recent removal of `scoped` CSS feels like the first exception to the rule. I really hope I am only being paranoid to think that it has something to do with the fact that all but one browser are run by commercial companies.  

-------  

**Thoughts on implementation:**

Regarding two comments
> @fantasai's https://github.com/w3c/csswg-drafts/issues/270#issuecomment-236974330
> As for my opinion on “namespaces”, I'm opposed to any solution that requires specialized CSS-specific markup...
> @Kinematics https://github.com/w3c/csswg-drafts/issues/270#issuecomment-290969197
> A secondary goal would be to avoid anything that touches the HTML markup, but instead keep the implementation entirely within CSS
and:

I would like to respectfully disagree.  
While it might be desired for some app architectures to have CSS concerns defined in 'CSS files only', I feel the community could benefit if there was a way to achieve outwards-leak prevention 'without touching the CSS' (or both could exist, I hope - no one would mind).  
This would allow a very simple reuse, without modification, of the content that [isn't being/hasn't been originally] authored with scoping in mind (and we can assume all of the current content hasn't, since the technology isn't there yet).  

Coincidentally, this exact subject is being discussed in [this comment](https://github.com/whatwg/dom/issues/510#issuecomment-363784918) on the 'declarative Shadow DOM through a tag' proposal which, I would argue, also suggests 'touching HTML' to achieve CSS concerns (granted, there are others, like id attribute scopes, but the CSS impact I'd argue is the most important).

As such, I would welcome being able to just [paste/dynamically load] a valid HTML content authored by anyone in the past into a specially crafted tag. To borrow the tag & attribute idea from the mentioned comment:

```HTML
<article>
... what the PoliticianXYZ published on his website:

<shadowroot mode='let-all-styles-in-but-none-out'>
<-- Some pasted historical HTML:-->
<style>
h1 {
    animation: blinker 1s;
}
</style>
I have never ...
</shadowroot>

... is simply contradicting to what he claimed in the past:
<shadowroot ...
```

and sleep easy that I haven't lost control over the appearance of my document.

-- 
GitHub Notification of comment by zlamma
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/270#issuecomment-364677643 using your GitHub account

Received on Saturday, 10 February 2018 18:15:46 UTC