I’m referring to the Shadow DOM issue raised in my post about Web Components.
Yes, but could you say more about why it would compromise the web? Or link to more info on why would be great, for maybe the less technical (me, at this point 
) Thanks!
I’m referring to the comment made there. That it makes it impossible to save HTML from a page.
1 Like
Ok thank you. I guess this is why nobody seems to like them.
I am no export on Web components, but is this really true? Why not? If it’s about JS generated DOM, yes you cannot just save the html file (same as in any React app for example), but you still can copy the whole generated DOM from browser dev tools
I don’t know, I’m sharing the chatter I’m picking up but don’t understand the details at this point.
@happybeing,
If you want, you can test on this page
https://scenaristeur.github.io/compagent-tuto/ which is full of lit-element webcomponents.
and in the webdev console, you can see all those shadowDOM
When you want to save it, you only got the html like
<!DOCTYPE html>
<!-- saved from url=(0046)https://scenaristeur.github.io/compagent-tuto/ -->
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, shrink-to-fit=no">
<meta name="description" content="">
<meta name="author" content="smag0">
<meta name="generator" content="LitElement">
<title>Agora</title>
<link rel="manifest" href="https://scenaristeur.github.io/manifest.json">
<link href="./Agora_files/bootstrap.min.css" rel="stylesheet">
<link href="./Agora_files/all.css" rel="stylesheet">
<script src="./Agora_files/jquery.slim.min.js"></script>
<meta name="theme-color" content="cyan">
<style>
.bd-placeholder-img {
font-size: 1.125rem;
text-anchor: middle;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
}
@media (min-width: 768px) {
.bd-placeholder-img-lg {
font-size: 3.5rem;
}
}
</style>
<!-- Custom styles for this template -->
<link href="./Agora_files/offcanvas.css" rel="stylesheet">
</head>
<body class="bg-light">
<app-element name="App"></app-element>
<script src="./Agora_files/solid-file-client.bundle.js"></script>
<script src="./Agora_files/app-element.js"></script>
<a href="https://smag0.solid.community/public/compagent/tuto/00basic/" target="_blank">Hosted on a Pod</a>
<a href="https://scenaristeur.github.io/compagent-tuto/" target="_blank">Hosted on gh-pages</a>
<a href="https://github.com/scenaristeur/compagent-tuto" target="_blank">Tuto</a>
<a href="https://scenaristeur.github.io/compagent-tuto/dev.html" target="_blank">Dev</a>
0.0001
<script src="./Agora_files/offcanvas.js"></script>
<script src="./Agora_files/notif-test.js"></script>
</body></html>
and all magic is done in the <app-element name="App"></app-element> imported by <script src="./Agora_files/app-element.js"></script>
all the dom is managed by this JS file.
But the same problem is , I suppose to all app that use webpack as it compiles all js files. It’s not specific to webcomponents.
We can also use webcomponents without Webpack
That’s what I would have expected. So you can save it from there.
It applies to all web apps that dynamically create the DOM using javascript, with or without webpack. But I do not see a problem actually, since the whole DOM is accessible.
1 Like
What I wanted to say is that without webpack, the js elements are human readable 
1 Like
I think the issue is for an end user wanting to save a copy of a web page to disc.
But best you check the issue raised by the complainant. It isn’t my issue - my point in sharing it was to raise awareness about Web Components rather than get into a discussion about any particular issue in this topic. I created https://forum.safedev.org/t/web-components-good-or-evil/2729?u=happybeing for that.
1 Like
I know the solid gods do not smile on my posting without producing code, but whatever.
Web components for solid seem like a slam dunk to me. So some glue that different components can use to work together to make apps seem necessary in order to help notoriously independent developers work on them each in their own way.
I want to write code to do it, but these days I’m just very slow and have missed a lot of things.
So far basically all I’ve got is an idea of ‘channels’. @pdecrat called them ‘spaces’: https://forum.solidproject.org/t/building-an-app-out-of-rdf/2345/15
These can be components themselves, and they are basically collections of one or more resources from one or more pods. They can be defined in a custom component with RDFa (I was trying to use json strings in attributes for that but I think RDFa is better).
Then these channels or spaces components can have id’s and other web components can work with or on or in them.
1 Like
I like the idea of grouping the data in the dashboard.
If I could suggest- from the user perspective- I would like to see exactly which organisations/other users have access to each peace of my data (not a group of data). Hope this more detailed view could come in the next step.
There are many good design pattern examples from how this is also already being handled regarding GDPR and things like Facebooks new “Off-Facebook Activity” tool, along with any iOS or Android permissions interface, etc .
Solid-legos could be done in stencil.js (thus avoiding google) and html forms could be added with
https://web.archive.org/web/20191209025244/http://www.lsrn.org/semweb/rdfpost.html
So that with about 7 components (solid-lego-web-id, solid-lego-pod, solid-lego-acl, solid-lego-channel, solid-lego-resource-browser, solid-lego-graph-display, solid-lego-form) people who choose to could be free of javascript and still use Solid.
2 Likes
Not saying this is a bad idea - I think it could be a nice to have, and certainly interesting to see how much could be done this way.
The problem with eliminating JavaScript is that you then push logic back onto servers, which are one the core vulnerabilities of the web.
One of the aims of Solid is to move logic away from the servers and into the client for this reason.
I see that pushing logic back to servers is a bad idea, but I don’t see (not that it isn’t, it’s just that I don’t see it) how this would do that versus using JavaScript without much html.
The form is just doing a patch like you would in js.
I think if you don’t have JavaScript in the browser it means putting the logic that it could handle in the server instead. RDF/POST enables simple exchange of RDF between page and server without JS, but if you want to do more than the server provides (e.g. LDP storage or run a SPARQL query) you will need logic to do those extras, either in JS in the browser or running on the server.
I think js would still have to be in the browser and used by the components, just not as something the user would write directly.
1 Like
By users I guess you mean users of the components, rather than app users - in which case I understand.
1 Like
This would mean I am either very limited or have to programm in kind of programming language build of components instead of plain javascript. I would always prefer the latter. But perhaps for beginners it can be a way to build simle apps.