The webcomponent dev roadblock

[20200618.1153-13] <athenian200> If he's asking what I think he's asking... he needs to know more about how the changes G4JC made work, right?
[20200618.1153-24] <athenian200> How our browser engine deals with Shadow DOM?
[20200618.1153-42] <NewTobinParadigm> i dunno
[20200618.1153-44] <NewTobinParadigm> maybe?
[20200618.1157-05] <athenian200> It feels like we're all talking past each other and starting from different assumptions... that is, me, G4JC, and MC.
[20200618.1200-23] <athenian200> I feel like if I had a descriptive document like that, or knew how to ask the right questions, I'd be able to implement it.
[20200618.1201-01] <athenian200> Looks like we may not have enough info to work with in general.
[20200618.1201-16] <athenian200> To be able to do original work without a lot of studying out what's already been done.
[20200618.1203-59] <athenian200> This is why you wanted G4JC to follow more of a plan and document his changes better, isn't it?
[20200618.1204-23] <athenian200> I'm starting to see the problem here... now all that is going to have to be done after the fact.

[18:13] <+MoonchildPM> athenian200: about what's being discussed that was relayed to me: I've reviewed g4jc's code changes at a code level but I never got any information about how this actually all fits together.
[18:13] <+MoonchildPM> I can't just jump in the deep end without knowing what I'm looking at or what specific cog ::host is in the "new" document machinery
[18:13] <@athenian200> Yeah, that's the same reason I'm having trouble.
[18:14] <+MoonchildPM> I did see very clearly that shadow DOM as a whole s very much a Blink implementation-first thing.
[18:14] <+MoonchildPM> But no details
[18:15] <@athenian200> So it seems like what we really need is a better understanding of how Shadow DOM was implemented and how to work with that implementation, right?
[18:15] <@athenian200> Not just the spec.
[18:16] <+MoonchildPM> The spec doesn't help understanding how it all fits together. the spec is just an endless list of interfaces and rules to implement them, not a document that lays out the actual structure
[18:18] <+MoonchildPM> And not knowing the structural changes made by g4jc at the macro level, I have no overview of what we have, what has changed, and how to work with the result.
[18:19] <@athenian200> Yeah, we need a top-down understanding of WHY the code changes were made and what structure resulted from them.
[18:19] <@athenian200> Not just knowledge of what the exact changes were.
[18:19] <+MoonchildPM> exactly
[18:19] <@athenian200> Yeah, I was stuck on that myself, but I assumed that was just because I'm new to this.
[18:19] <@athenian200> It looks like anyone would need to know that, though.
[18:19] <@athenian200> Even with experience.
[18:23] <+MoonchildPM> Unfortunately none of that seems to be documented by g4jc. It's certainly not part of the repo because changes were mega-lumped together
[18:24] <@athenian200> Whenever I was looking at this, I kept trying to mentally map out what each file in layout does, and compare it with other implementations or develop some theory about how it's all linked.
[18:24] <@athenian200> But I felt like that blind man trying to feel parts of the elephant and figure out what I'm touching.
[18:24] <+MoonchildPM> Good analogy