Deal with beforescriptexecute/afterscriptexecute

[annevk]

Gecko supports these.

WebKit has not moved on these https://bugs.webkit.org/show_bug.cgi?id=91463 (despite developers wanting it) and Chromium hasn't either https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bChX6leKqtg/Idut6cE4ORcJ. There appears to be some sort of support for this in the Chromium camp, if this was more of a local notification rather than a global one.

We have these options:

• Keep them, and add their corresponding on* attributes which Gecko already ships
• Replace them with something else (what?)
• Remove them

[annevk]

Note that #762 requires us dealing with this somehow.

[Hrxn]

If we only had some kind of overview about the pros and cons, I think that could be useful, to understand the reasoning behind different positions.

[domenic]

I would like to remove these, as they are one vendor only.

[annevk]

Yeah, @travisleithead @smaug---- @hober, are you all okay with removing these events? They are only implemented by Firefox and Chrome has refused to implement them in their current form. Given that they've been around for quite a while it seems time to declare this addition a failure.

[smaug----]

IIRC @sicking added the events.

I kind of like the events, and would rather keep them.
blink-dev doesn't seem to quite have valid arguments against these events, but sure, if no one else is going to implement them, after some telemetry period removing them is an option.

[smaug----]

I guess related to these is the question what we'll do with .currentScript.
The events and .currentScript all expose a state of a <script>.
Do we need some totally new API to work better with shadow DOM?

[annevk]

@smaug---- #1013 has ideas for a potential better API. Unfortunately it requires changes in JavaScript.

[domenic]

.currentScript is implemented everywhere, so we'd keep that. (Except not for modules as noted there.)

[smaug----]

and not for shadow scripts.

[chrcoluk]

So if I understand correctly, google can control the standards by simply choosing to not implement what it doesnt like in chrome?

It seems they refused to add it because they feel web site developers should have control in what appears in the end user's browser.

[domenic]

@chrcoluk almost. All implementers collaborate together on standards; Google is one of them. In this case, 3/4 rendering engines gave feedback that they'd rather not include this in the standard, so it was clear this was not going to be part of the interoperable web, and thus we removed it from the standard.

[Ms2ger]

https://bugzilla.mozilla.org/show_bug.cgi?id=1286822
servo/servo#12446

[mario98]

I can tell you why this was not included in the standard. With this functionality, the users were able to block, for example, annoying ads (AdDefend etc.), tracking and other crapware. However, website owners don't want the users to do this, because they don't care about privacy or the security of the users, therefore they try everything to prevent the user from defending themselves from crapware. And WHATWG, probably after getting some donations, fulfilled their desire and removed this from the standard. SAD!

[domenic]

Hi @mario98, welcome to the WHATWG community.

You've made some rather extraordinary claims, which go directly against the reasons presented above in this thread and discussed at length. Namely, that we spec what is implemented, and if there is no implementer interest, putting something in the standard does not accomplish anything.

Do you have any proof for these accusations of yours? Ideally your first act of participation in a community such as ours would be less hostile.

[mario98]

Well, it must be clear that Google, being part of the advertisement system itself, will of course oppose this standard. Therefore, if you rely on Google making your decision, this opens the door for Google dictating the rules for a web in favor of large corporations. You should rather be independent from Google and make your decisions yourself, depending on what's best for the users (not Google).

[domenic]

Unfortunately that would just lead to a world in which we create fiction, not web standards. We're interested in creating web standards that are implemented everywhere, not just documents that make us feel good by talking about what we ideally wish the world would be like.

[Hrxn]

But you work for Google, and that is not just an accusation. Not that it's inherently wrong or something..

I don't think it is too hard to understand where the possible conflict of interest is here in this case, I'm sure you can see that.

[domenic]

@Hrxn as a spec editor, it is my duty to reflect implementer consensus, not my employer's wishes. Do you have any evidence, beyond just accusations, that a conflict of interest is interfering with our duties as spec editors? Or do you think perhaps that the reasons given in this thread---that we simply don't spec things without implementer interest---might be more accurate?

[Hrxn]

And now take a good hard guess where this 'implementer's interest' is coming from, and what factors contribute to influence such decisions.

[Swyter]

Now the Web world is divided in a bipartisan system, Mozilla and Chromium/WebKit. Microsoft Edge just lags a little behind everyone else, by picking what is popular.

This is shipping in Firefox right now. By passively marking as WontFix without explaining their reasons in the Chromium issue tracker a single company with sizeable market weight can silently steer standards, influencing issues that can tangentially affect its main source of income without almost anyone batting an eye.

One can understand the decision if there's a solid technical or conceptual issue, but a little of transparency in the process of the implementers would be nice, instead of: 'Uh. Okay, no interest, let's remove it.

Seeing that this is a trivial trigger that solves a specific shortcoming, specially when compared to hardcore innovation for all kinds of ancillary uses that browsers are receiving lately all this seems a bit fishy. Or not?

[domenic]

@Swyter it's legitimate to ask implementers why they remove something or do not implement it. However, that's best done on their bug trackers, not on this one.

[Swyter]

I understand. But the WHATWG should enforce this kind of transparency by default, specially when a possible conflict of interest arises, just to clear up any doubt. Isn't that reasonable?

[domenic]

We don't control implementers, so we can't really enforce anything in the way you're describing. It's indeed ideal if everyone explains all of their decisions all the time, but we don't have a system set up where the WHATWG can in some way punish people for not doing so.

[Swyter]

Food for thought.

[zcorpan]

For rationale to not implement these events in Blink, please read this thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/bChX6leKqtg/Idut6cE4ORcJ

[Hixie]

Hey now, if y'all are taking bribes for not including stuff, I want my cut too.

[mario98]

@Hixie: Confused. I think you are already paid by Google, or did I get something wrong about your CV? http://ian.hixie.ch/career/resume.html
Please stop pretending that you're independent.

The bitter irony is, however, that WHATWG was originally founded by Mozilla, but nowadays Mozilla is just referred to as "no implementer".

[annevk]

FWIW, I work for Mozilla and I support this resolution. These events (and currentScript) don't work well for script elements when it comes to shadow trees. We need a different approach as I mentioned in #943 (comment).

[rianby64]

@mario98 I can't understand your comments. If you have any idea that concerns how to deal with beforescriptexecute/afterscriptexecute, please, expose it.

[mario98]

@rianby64: Here is what I would do:

1. Realize that this standard is implemented by a founding member of WHATWG and a pioneer of web browsing, Mozilla.
2. Realize that there is huge developer interest. Even the most used addon of all time is interested in such a feature, because this would help them to make their addon more efficient. (However, they didn't implement it because they have to stick to the lowest common denominator across all browsers)
3. Realize that other applications, such as uBlock (~half a million users) and others already rely on this feature.
4. Realize that this is sort of a chicken egg problem. As long as not everyone has implemented this, we won't see much application. But once it's an accepted web standard (and the organization behind this web standard will not back down because of special interest), this will be implemented by other browser engines as well, then we will see this feature in action everywhere.
5. Come to the conclusion that this is a valuable standard which needs to be defended instead of abolished.
6. Tell Google that they have two options: Either implement this standard or not implement this standard, but this standard is not going to be removed.

Possible side effects:

• Websites whose business model is to sell out their users to large advertisement networks may be not amused.
• Ordinary people will be very amused.
• Those who are working for Google may not get an increase in their salary in the next few month.

[domenic]

I think we need to lock this thread, as it's going in circles and emailing at least 155 people for every reply. We've already stated that the WHATWG is not in the business of writing fiction that does not achieve multiple interoperable implementations, and yet some people seem to ignore that and think that we should put proprietary single-vendor fiction in the standard anyway.

(It doesn't make a difference whether that single vendor is Mozilla---that doesn't give their proprietary single-vendor extensions any more claim to being a standard. Similarly, it doesn't matter if popular extensions or developers are using the Mozilla-only proprietary extensions---that isn't a good reason to put something in a standard.)

If anyone has any concerns or evidence of corruption, bribes, or bias in the standards process, please feel free to reach out to the editors directly by email. We take such accusations very seriously and will work with you to the best of our abilities to get to the root of such situations. But given that nothing concrete has been shown, we should not be wasting 155+ peoples' time with simple innuendo and wishful thinking.

[Hixie]

@mario98 the problem with your conspiracy theory is that I'm the one who added it to the spec in the first place...