New feature request - isolated web components without shadow DOM

[bob2517]

Shadow DOMs are all well and fine, but you can't use them in the old Edge, so they can't be used in wide production code use for websites yet. That makes the web component isolation stuff in Active CSS a bit pointless at the moment. Great for building browser components - not so great for building websites for non-techy people who might not have upgraded Edge manually (The old Edge doesn't update by itself), and in practical terms those people do exist.

How about having the same isolated functionality, but just assigned to a specified tree host element instead of a shadow DOM host? This would give equivalent functionality to the shadow DOM method in Active CSS, but it would work on Edge.

That would mean you could have events and variables in a defined scope but you could use the page CSS and make components without inherent styling.

This proposed behaviour would mean you could build re-usable menus, search boxes, etc. and they would tie into a website's CSS and as separate entities could be standalone. This way, you can have external CSS and have re-usable web components that you are more likely to leave alone, with associated CSS files that you could tweak on a per website basis.

[bob2517]

Just succeeded in getting the docs website Tic Tac Toe multiple shadow DOM components example converted to using multiple scoped components without a shadow DOM just by setting "scoped" as a parameter rather than "shadow" on the component - not seeing any errors. ActiveCSS DevTools monitoring the bubbling looks ok. Looking promising. Need to get a few more test cases written before check-in just to confirm there isn't going to be any school-boy error barfages.

[bob2517]

Testing is complete on this particular issue, but gonna add another feature in here before pushing live as it's going to be useful with components. Having pondered on the usefulness for components for a while, one would probably have a main component which could then could be made up of sub-components that would want access to the main component variables. How then to share the variables within the components with the least amount of fuss. A component would essentially be private, with "open" components underneath which would effectively fall under the scope as the top-level component. So do this: 1) "Scoped" is the wrong term to use. This should be renamed "private" wherever this occurs in the code, as it is more familiar to people, and means the same thing as scoped anyway. It will refer to private variables only and refer to the top-down hierarchy of components. 2) Events should be available for regular non-private/non-shadow DOM components - currently this feature is limited to scoped and shadow components. Events within components are faster than page events on a large site, so this implementations will speed up event handling for components and save on having to add class names, etc. if the components are small, as the events references will be isolated to the component. These internally in the core would be private events - not variables. Currently "scoped" refers to both private events and private variables combined. This needs splitting up internally so that if events are within the component then they are automatically private events. The term and parameter "private" in the component declaration will only ever refer to private Active CSS variables. This whole thing also applies to shadow DOM components. The variables in a shadow DOM component will only be private if "private" is a parameter in the component declaration. This is a change to current behaviour, but will allows us to have shadow components within a top-level private component that can share its variables around, and the end result is that it's going to be really clear what is going on, and it'll make more sense.

Here endeth the imminent fixes for 2.2.0.

---

3 - just a note here) If a private event is underneath a private event, it is effectively isolated in scope from anything above, or any other private component below. There needs to be a way to export variables out of private components and into any private component on the page without making things complicated. How to do this hasn't been nailed down yet, and probably won't be part of this issue, but it appears to be the only missing link left on this variable sharing issue. Scope labels won't work, as you could have multiple components with the same label, and so we might have to label by selector reference. Perhaps "export" as a general command followed by a list of vars to export with a parameter option of named "import areas" in the same export command; or the same general export command with an additional import command in the component to import into. Need to get a use case. It also adds a bit of complexity, but may be needed - this whole export/import thing has a tendency to be confusing, so it raises a complexity flag on the syntax. Hence this will implemented later on after more thought - need a proper use case too.

[bob2517]

Points 1 & 2 are done on this offline. Just need to update the docs, get a proper component tutorial done and then will publish.

Got slightly distracted by the intense Austrian Grand Prix...