Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declarative Web Component Proposal Demos - March 2024 #84

Closed
Westbrook opened this issue Feb 26, 2024 · 3 comments
Closed

Declarative Web Component Proposal Demos - March 2024 #84

Westbrook opened this issue Feb 26, 2024 · 3 comments

Comments

@Westbrook
Copy link
Collaborator

@trusktr has gotten everyone started with gathering proposals for demonstration when we gather back for March breakout via #80. Here we'll work on scheduling for one or more sessions of this.

If you'd like to participate, please use this link to share your availability between March 11th and March 22nd for this session. It would be great to have a consensus meeting time by March 4th at the latest.

Beyond the list of demos being gathered above, be sure to check out the notes from February's breakout on the same topic available here.

@Westbrook
Copy link
Collaborator Author

Meeting info for Demo Day no. 1

WCCG: DEC Demo Day
Monday, March 18 · 1:00 – 2:00pm
Time zone: America/New_York
Google Meet joining info
Video call link: https://meet.google.com/jsk-ruew-sea

See you there.

We've got a lot of demos coming together, so we're gonna need a second session, please share your availability here for scheduling.

@Westbrook
Copy link
Collaborator Author

Demo Day no. 1 is a wrap!

If you missed the meeting, you can read the meeting notes to catch up.

Discussions
Let's keep the discussion going, each of the presented demos can be discussed directly, below:

Be sure to share your availability for the next round of demos here!

Meeting chat hidden within...

You
1:02 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit#heading=h.z14o87sh4gji
Steve Orvell
1:10 PM
How is that better than just authoring the class?
Justin Fagnani
1:11 PM
how do you do imports, etc
Steve Orvell
1:12 PM
I like the attempt to add as little as possible to make something satisfying.
Michael Warren
1:13 PM
i think i'm with justin and steve and just one script with the class in it is the easiest? you can do imports and callbacks like normal etc
Justin Fagnani
1:13 PM
I think it'd be more minimal to define a class though - you wouldn't need all these lifecycle attributes
Steve Orvell
1:13 PM
Without declarative tempating, it's pretty unsatisfying imo.
moon
1:13 PM
I like the lifecycle method attributes.
Justin Fagnani
1:14 PM
and it'd be a normal module. The attributes seem to imply that there's a generated class behind the scenes and that the scripts aren't executes immediately like all other script tags
Michael Warren
1:14 PM
how would public component methods be defined?
like MyDCEModal.show()
Michael Warren
1:16 PM
if its just one script and the class, then thats basically HTML modules as we've been discussing right?
Brian Kardell
1:17 PM
that was my question
Brian Kardell
1:18 PM
well, you would want to not throw
Michael Warren
1:18 PM
if you did two definitions, how would you do two <script connectedCallback> and delineate which connectedCallback impl goes with which CE in the template?
Rob Eisenberg
1:19 PM
This is nice and terse, and simple. I like that. BUT I have the concern that the design is not flexible enough or forward compatible with handling the breadth of use cases. Examples are things like light dom rendering, controlling define and tag name, declaring non lifecycle methods, fields, properties. Scoped elements, etc.
Brian Kardell
1:19 PM
I agree with this statement
(keiths)
You
1:22 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
Steve Orvell
1:24 PM
I'm not a fant of non-interoperable slotting. It feels like a significant step backwards.
Michael Warren
1:26 PM
control logic in HTML would be :chefs-kiss:
Steve Orvell
1:27 PM
How popular is use of XSLT today? If it's not used much, it seems like a weird thing to build on top of.
Justin Fagnani
1:30 PM
It's not used much, nor maintained in browsers.
It'd be a huge lift to get implementors on board with this
Steve Orvell
1:31 PM
I didn't follow how you get scoping without scoping?
Keith
1:32 PM
Introducing a new element which allows for unused subresources or scripts is probably a no-go, as it's a XSS vector for old sanitisers/parsers. I think any proposal would likely have to hook off of <template>.
You
1:35 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
Steve Orvell
1:35 PM
I think this is the right amount of "stuff" to have in DCE for it to be pretty satisfying.
Rob Eisenberg
1:36 PM
https://gist.github.com/EisenbergEffect/8ec5eaf93283fb5651196e0fdf304555
Steve Orvell
1:37 PM
The gist has a lot of good ideas and is well written imo
moon
1:37 PM
Agreed.
Brian Kardell
1:39 PM
What would be really interesting to me is to know how many people have spent how much time on each of these and how much feedback they've already received along the way.
just intellectually that is interesting to me
Sasha Firsov
1:40 PM
mostly "conserns" about xslt :) no real valuable feedback
Keith
1:43 PM
This potentially suffers from the same issue as Sasha's demo: adding new tags which are otherwise intended to be inert may be a non-starter. Ideally they should use , or be designed such that they don't house sub-resources or scripts.
Sasha Firsov
1:44 PM
@keith, if the fully functional templating language is a requirement, your statement is "no starter"
Steve Orvell
1:45 PM
I realize this is geared towards a proposal, but I think this could be a valuable library to publish on its own. And if you do so, my feedback is that I'd rather have a fully client version than have to run a compiler.
Keith
1:45 PM
the requirement is that it must embed into existing HTML implementations. That isn't just browsers but also sanitizers, generators or parsers in the web today - which we do not necessarily have control over.
Owen Buckley
1:46 PM
could you zoom in please?
Sasha Firsov
1:46 PM
@keith, that is what custom-element is focusing now: validators and native implementation in same package
Keith
1:47 PM
You missed the other part of what I mentioned, sanitizers and generators.
Brian LeRoux
1:47 PM
fwiw i found xslt to be pretty stable for well over a decade and supported in all major evergreen browsers. its old, but that doesn't mean it isn't good.
Sasha Firsov
1:48 PM
XSLT is envolved a bit since. Tomorrow I am going to present custom-element to XML group. Taking their feedback on compatibility
Brian Kardell
1:49 PM
for example, I am even older than xslt :)
Brian LeRoux
1:49 PM
😅
Keith
1:49 PM
A website which takes user generated content today, needs to behave the same with user generated content tomorrow. If we present a new element which is not removed by existing sanitizers, and it is able to load subsresources where the implementation is such that it should not, then that is something that browser vendors and standards groups will be unlikely to embrace, in my opinion.
Steve Orvell
1:49 PM
An expression language is pretty scary but seems necessary. XSLT is at least an existence proof.
Justin Fagnani
1:49 PM
We need an expression language for template instantiation
Keith
1:49 PM
We had the same discussions around DSD which is one of the reasons why <template shadowrootmode=> was chosen over, say, <shadow-root>
Justin Fagnani
1:50 PM
The hard part is making it safe from gadget attacks
Brian LeRoux
1:50 PM
yeah totally agree this is a requirement
not to derail but have y'all looked at the old adobe mxml / flex stuff? it totally explored this space a long time ago
Sasha Firsov
1:51 PM
excluding JS would make DCE resiliant to attacks
Brian Kardell
1:51 PM
and xul/xaml?
Brian LeRoux
1:51 PM
yea!
Sasha Firsov
1:51 PM
xul is not a part of web stack as of now, xslt is
You
1:52 PM
https://www.when2meet.com/?24156364-pOaZk
Brian Kardell
1:52 PM
sasha I didn't say it was? that was a reply to brian?
Brian LeRoux
1:52 PM
oh for sure, i'm just saying some of these problems might be well solved by those old dialects
Rob Eisenberg
1:53 PM
I should say ther eis one other thing I tried to avoid, and that's micro syntaxes. So, I have a more long form for declaring attributes and elements because there are lots of details ther that you would want to declare: name, type, reflect, etc. And forcing that into a micro syntax can be more complicated than not. Better to add the micro syntax later once you feel good about the longer form and that it handles everything you need.
Keith
1:53 PM
I think you'll get a lot of pushback around mode-setting - so having elements only work within a specific mode, e.g. module format.
Brian LeRoux
1:54 PM
as much as I don't love it a mustache-y thing would probably be least surprising to frontend ppl
I too like the path you took Rob; good stuff
Justin Fagnani
1:56 PM
export default from a <script> tag is nice
Brian Kardell
1:56 PM
the class bit of this feels like it would mash better with jesse's
Sasha Firsov
1:56 PM
FYI {} is part if translation proposal.
Scott Jehl
1:56 PM
Same. (Brian)
(...LeRoux :) ) hah
Brian LeRoux
1:57 PM
Brians everywhere!
Brian Kardell
1:57 PM
we do still have to do briancon
Steve Orvell
1:58 PM
This also feels like a satisfying amount of "stuff" for a DCE to support.
Justin Fagnani
1:58 PM
We need to get this fixed, even to nicely implement some of these ideas in userland: whatwg/html#7367
Michael Warren
2:00 PM
great demos everyone!
Keith
2:00 PM
Fantastic demos all!

@Westbrook
Copy link
Collaborator Author

Demo Day no. 2 is a wrap!

If you missed the meeting, you can read the meeting notes to catch up.

Discussions
Keep the discussion going by sharing your questions, feedback, excitement about the demos shared today, via:

See you next time! 👋🏼

Meeting chat hidden within...

You
1:01 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
#80
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
#80
You
1:03 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
#80
Brian LeRoux
1:03 PM
rock paper scissors!
Michael Warren
1:07 PM
Proposal: #32
^ initial straw man
Owen Buckley
1:08 PM
here's the strawman Dave if that helps
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md
Dave Rupert
1:09 PM
rad thanks!
Owen Buckley
1:09 PM
I'm not sure if's the right analogy, but I suppose a familiar reference in today's web dev nomanclature would be SFCs (Single File Components)
Jesse Jurman
1:09 PM
the classic
Dave Rupert
1:12 PM
https://heartml-docs.onrender.com/
Keith
1:16 PM
Cool example of whendefined!
Michael Warren
1:18 PM
Single File Components (SFC) corresponds to HTML Modules...imo DCE and HTML Modules are separate, but pretty closely related. Seems like a fair amount of the DCE examples eventually go for HTML Modules (SFCs)
James G
1:20 PM
looks good!
Owen Buckley
1:24 PM
nice demo!
You
1:24 PM
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
Justin Fagnani
1:25 PM
https://docs.google.com/presentation/d/13mIqxQJVlQZxBrtYAsTP-WjhSbFcWO5p4a-NCDFBdhc/edit?usp=sharing
Jochen Kühner
1:26 PM
If we have time after this I could also do a Demo
James G
1:27 PM
we use jexpr a lot, thanks for making that! :D
Owen Buckley
1:39 PM
.toUpperCase
James G
1:39 PM
toUpperCase
Steve Orvell
1:42 PM
I have a 5 minute impromptu demo if there's any extra time...
Rob Eisenberg
1:43 PM
I've got that in html modules section of my proposal as well. Definitely need that.
Referring to providing a name on import.
Jesse Jurman
1:44 PM
More demos!
Michael Warren
1:44 PM
more demos!
James G
1:44 PM
more demos
Nikki Massaro
1:44 PM
demos
Owen Buckley
1:44 PM
demos
Michael Warren
1:44 PM
"democracy"
Jared White
1:44 PM
the people have spoken!
James G
1:44 PM
can't miss out on a steve demo
Brian LeRoux
1:49 PM
would it be fair to say this effort is largely to get an expression language into and smarts for conditionals and iterators (that doesn't require running clienside javascript code) ?
James G
1:51 PM
pretty much i think. some way of declaring logic in your templates rather than jumping over to a js file
You
1:52 PM
Great question.
Steve Orvell
1:57 PM
We tried a pretty high level approach with Polymer 10 years ago and got incredible push back from vendors (especially Apple). They wanted lower level pieces to build on...

Not saying that'd happen again per se, but it's a risk.
Rob Eisenberg
1:59 PM
We have a bunch of piecemeal stuff. It doesn't feel coherent.
Michael Warren
1:59 PM
fair enough heh
Nikki Massaro
1:59 PM
agree
Rob Eisenberg
1:59 PM
I think we need a phased approach, but we need it as part of a consistent longer term vision.
Brian LeRoux
1:59 PM
+1 for not making forms an afterthought!
Michael Warren
1:59 PM
i havent been around long enough be able to judge the two approaches very well. i just see what the CSS working group does with things like colors etc
Rob Eisenberg
1:59 PM
Not just "whackamole" standard development.
Dave Rupert
2:00 PM
+1 Piecemeal may very well be the right approach but it sort of extends Web Component's "not ready yet" problem.
Nikki Massaro
2:00 PM
^ this.
Steve Orvell
2:00 PM
we need a North Star and a path to it
Dave Rupert
2:00 PM
Great demos tho! Thanks y'all.

@Westbrook Westbrook unpinned this issue Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant