WHATWG HTML Standard VS EventSource

WHAT-WG HTML

There's a long-standing WHATWG feature request open for it here: https://github.com/whatwg/html/issues/2791

And several userland custom element implementation, like https://www.npmjs.com/package//html-include-element

One of the cool things that you can do with client-side includes and shadow DOM is render the included HTML into a shadow root that has s, so that the child content of the include element is slotted into a shell implemented by the included HTML.

This lets you do things like have the main page be the pre-page content and the included HTML be a heavily cached site-wide shell, and then another per-user include with personalized HTML - all cached appropriately.

The `allow` attribute on iframes is a relatively recent API addition from 2017

https://github.com/whatwg/html/pull/3287

I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.

I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791

And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element

Then HTML could support these elements being targets of links.

> Consider https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/

I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get

to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For

, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373

The library in question is much more than one line, and it's a polyfill, which is something that provides the capabilities of the standard library to older browsers.

It makes me deeply sad to see these sort of interactions in open source [1].

> Hmm, I think it's a worthwhile fix. Where did you see malware here?

> I think the author of this repo is free to decide what code he publishes. Say thanks to that it's for free

An incredible amount of people have dedicated sweat and tears and foreheads (from banging against the desk in frustration) to open source across the entire stack, from the contributers to OSs such as Linux to those working their arses off to create better frameworks, languages and runtimes, that we can all benefit from and use with a reasonable expectation of security, respect and privacy.

As a university student, I feel privileged to have been able to grow up in a world where so much work and knowledge is provided for free with no strings attached, regardless of demographic/location, I would not be where I am without it. A century ago this would not have been possible. To all of you who have tirelessly and selflessly worked on OSS for others, without expecting anything in return or imposing politics, ideologies, infringing on privacy, causing damage, collecting vast quantities of marketable personal information or monopolisation, I give you my heartfelt thanks for your efforts, you know who you are. You have created something that will have forever helped to improve our soceity and empower those that want to learn and create their own designs.

From my own personal experience, I want to give a shout-out to the smaller projects of Rust, Svelte and Elixir. I think it's incredible that the work and ideas of (often) a single person (Rich Harris, José Valim) can grow into larger extremely welcoming and helpful communities with many more motivated contributors that are proud of being parts of those projets and put in an extrodinary effort to try and do things _better_ than before. I'm sure there are plently of other worthy names I'm too young/ignorant to know.

Love it or hate it, Node.js has been very empowering for a large number of people to learn and publish their own full-stack applications, the JavaScript ecosystem has improved enormously since its beginnings, but has a tendancy to change slowly due to its size, unless a disruptive technology comes along such as TypeScript. Websites are a great way to introduce people to the joy of programming with its visual feedback, you can make a small penguin move across the screen, then move on to play tic tac toe. Even as a younger developer, I admit that the days of FTP, no-build-step pages with a sprinkle of JQuery were easier to understand and actually _safer_ for newcomers than introducing someone to a SPA stack (which can easily have thousands of transient dependencies) nowadays.

[1]: https://github.com/Yaffle/EventSource/issues/202

> Cool story.

Actually, "blacklists", "redlists" and many other "lists of undesirables" weren't cool at all. But every generation or so they unfortunately seem appealing again.

> the list that they're discussing has actually existed for 30 years

Where is this list? Who maintains it?

OC certainly didn't know about it: "We should probably start an open source sanction list of individuals who abuse trust to ship malware"

> When you commit a crime

"crime"? Please link me to the law you think they broke.

Here's the license: https://github.com/Yaffle/EventSource/blob/master/LICENSE.md

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED

So, how is this a "crime"?

> that knowledge never disappears in any country

Not true in any country except maybe North Korea or some other authoritarian state. In any society with checks and balances, verdicts can be appealed, judgements reversed, records expunged and rights restored. This "undo" feature is pretty critical to any legitimate system of justice, as is "innocent until proven guilty". I didn't see any details about the rights of the accused in anyone's blacklisting proposals.

> None of these address what happened in any way.

Yes, it does. MIT licensed software is provided "AS IS, WITHOUT WARRANTY". If you don't like it you can fork it. If you're afraid of a bad commit, vendor it, which is a best practice anyway, for this exact use case.

> Relatively easy for the rest of us to see.

Our entire legal branch of government exists because these lines are never easy. Judges judge things all the time, and not uniformly. If everything was easy to see, we wouldn't need judges or juries. The interpretation of language or of an act on a case by case basis is where things get tricky.

> The rest of us will act without you

At this point I have way more questions:

* Would you blacklist this contributor if they documented the Russian timezone popup as a feature in the package as the issue creator suggested (https://github.com/Yaffle/EventSource/issues/202#issuecommen...)?

* What "test" would you apply to code to determine if the developer should be blacklisted or not? Would this blacklist only pertain to malware? Wikipedia (https://en.wikipedia.org/wiki/Malware) defines a few different malware categories: "Many types of malware exist, including computer viruses, worms, Trojan horses, ransomware, spyware, adware, rogue software, wiper, and scareware." If the code doesn't fall into one of those categories (as is this case), under what circumstances might you still blacklist the developer?

* If a maintainer stops maintaining their current library and says all future maintenance will be done on a new library, and that new library contains this Russian timezone popup code, would they be blacklisted?

* Would it matter if the "bad code" was intentional or not? Or a joke or not? Or temporary or not? How would you determine the author's intent? Would they have a chance (or be obligated) to respond? Or would you only look at the impact of the code? If you look at the impact, how under what conditions would a "bug" get you blacklisted?

* Would you blacklist a developer for making a breaking change to a package? What if the breaking change was politically motivated?

* Who runs and maintains the list? Does this list have an appeals process? What are the rights of the accused?

* How will you disambiguate the list so as not to misconstrue "innocent" developers as blacklisted developers? Will you include their birth name? Social profiles? Emails? Addresses? How will you deal with name changes (someone gets married, or changes their name?), or new online handles?

* What age and definition of a minor will you use? And will minors be given different treatment or excused from the blacklist?

I could go on, but if you're serious about this idea, you'll probably want to communicate it in more detail because a "forever list of bad developers" sounds a lot like a "forever list of communists" or a "forever list of undesirables". If you're not going to make the same mistakes McCarthy (and others before him) did, then these details will be really important.

Obviously, websockets are superior and offer much more when compared to SSE. However according to me, sometimes the simplest solutions are just as good to get the job done. Besides, use of EventSource for SSE is abandoned and for that we can use polyfills such as https://github.com/Yaffle/EventSource

Use of EventSource is abandoned for SSE. It can be mocked by using fetch api. Have a look at this polyfill: https://github.com/Yaffle/EventSource