4 ms·

Past attempts at component models for the web have used CSS as the hook instead of a script call. For example, Mozilla's XBL and Microsoft's HTC. This way of do

by om2 10y ago

Past attempts at component models for the web have used CSS as the hook instead of a script call. For example, Mozilla's XBL and Microsoft's HTC. This way of doing it is a security hazard because it makes CSS into active code instead of just passive styling. Many sites had problems where they were willing to include CSS from a third-party source for user customization, and ended up with XSS security holes. If you do it carefully and get all the details right, you end up with something like Custom Elements and Shadow DOM, both of which are ultimately not that complicated.

c-smile 10y ago
> to include CSS from a third-party source for user customization, and ended up with XSS security holes. So custom components cannot be included from third party sources? If they can then this is exactly the same problem. And in general idea of including third-party CSS from source you cannot control is even worse. Same thing is about JS. That `behavior` thing can use 'same origin' rule as we have now for any other JS code. The behavior that defines name of a function (in any language) that can setup the element in various ways: e.g. it can be used with React, Angular, Vue, you name it.
- om2 10y ago
  > So custom components cannot be included from third party sources? If they can then this is exactly the same problem. They can, but you can separately decide whether to support components from arbitrary off-site sources (most sites wouldn't) vs accepting styling for arbitrary off-site sources. > That `behavior` thing can use 'same origin' rule as we have now for any other JS code. There is no same-origin restriction for JS included directly with the <script> tag. Most websites are not designed to expect the <stye> tag to be a backdoor <script> tag. If you mean to invent some novel security restrictions on JS running in the same frame, trust me, it will end up more complex than Custom Elements.

by om2 10y ago

c-smile 10y ago

> to include CSS from a third-party source for user customization, and ended up with XSS security holes. So custom components cannot be included from third party sources? If they can then this is exactly the same problem. And in general idea of including third-party CSS from source you cannot control is even worse. Same thing is about JS. That `behavior` thing can use 'same origin' rule as we have now for any other JS code. The behavior that defines name of a function (in any language) that can setup the element in various ways: e.g. it can be used with React, Angular, Vue, you name it.

om2 10y ago
> So custom components cannot be included from third party sources? If they can then this is exactly the same problem. They can, but you can separately decide whether to support components from arbitrary off-site sources (most sites wouldn't) vs accepting styling for arbitrary off-site sources. > That `behavior` thing can use 'same origin' rule as we have now for any other JS code. There is no same-origin restriction for JS included directly with the <script> tag. Most websites are not designed to expect the <stye> tag to be a backdoor <script> tag. If you mean to invent some novel security restrictions on JS running in the same frame, trust me, it will end up more complex than Custom Elements.