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

New attribute `report-load-failure` for elements containing external resources #3858

Open
Zhang-Junzhi opened this issue Jul 30, 2018 · 10 comments
Open

Comments

@Zhang-Junzhi
Copy link

@Zhang-Junzhi Zhang-Junzhi commented Jul 30, 2018

Load failure of external resources in a document would typically affects how the document functions or is displayed.

In case of various situations of load failure, developers are able to make the document react accordingly with scripting, for example, by adding an 'error' or 'load' event listener on those elements containing resources.

However, unfortunately, if the script used to depoly reactions is also an external resource, then the script file is also possible to fail its load itself; even worse, script can be disabled by an user agent or its extensions. So reacting load failure accordingly seems hopeless in these cases.

So I would like to propose to add a new attribute report-load-failure for elements containing external resources. If load failure occurs on an element with report-load-failure attribute, then a load-failure attribute is automatically added in the element, the content of the load-failure includes the specific reason of the load failure, for instance, the protocol of the resource and the returned status code(I haven't yet come up with a specific format of the content, I just propose the general idea).

With the above feature, we will be able to style the document as a fallback mechanism due to load failure. Take the following code for example(Assuming the content for an HTTP 408 repsonse is "http 408" for load-failure).

<!DOCTYPE html>
<title>...</title>
<script src="foo.js" report-load-failure></script>
...
html:has(script[load-failure~=http][load-failure~=408]) body::before
{
	content: "Failed to load some necessary script file on the page due to network timeout. Please try refresh the page";
}

html:has(script[load-failure]) body::before
{
	content: "Failed to load some necessary script file on the page for some reason. Please check if you disable script in your browser.";
}

So when the browser fails to load foo.js, a warning message will be shown to the user(At least when CSS is enabled and loaded).

I am looking forward to hearing from your opinions.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Jul 30, 2018

This seems very related to the work going on in https://github.com/w3c/reporting. I think you'll probably get people who are more familiar with the problem and solution space by taking the issue over there, although we can discuss it here as well.

I'd also suggest you read https://whatwg.org/faq#adding-new-features, especially step 1 :). If your goal is to react to load failures even without loading any script from the network to do so, I can think of other solutions that might work, e.g. inline script elements or onload/onerror content attributes.

@Malvoz

This comment has been minimized.

Copy link
Contributor

@Malvoz Malvoz commented Jul 30, 2018

CSSWG has a discussion on applying CSS for images that fail to load (see w3c/csswg-drafts#656), maybe you could bring up your use case there since it may end up a more generic property rather than specific to images.

@Zhang-Junzhi

This comment has been minimized.

Copy link
Author

@Zhang-Junzhi Zhang-Junzhi commented Jul 30, 2018

Thank you both for the replies!

I guess the browser or its extensions can also, in many ways, disable/block any scripts, including inline scripts, in that case, I still would like to see a fallback mechanism to give users with some friendly hints about the current load status.

I read https://whatwg.org/faq#adding-new-features, thank you, @domenic .

Interestingly, I didn't know CSSWG also has a similar plan for images. Thank you for your information, @Malvoz . Since they already have a plan, So I will try to bring up my use case there first.

@benjamingr

This comment has been minimized.

Copy link

@benjamingr benjamingr commented Aug 2, 2018

Would you mind clarifying why the existing onerror attribute is not sufficient for this?

@Zhang-Junzhi

This comment has been minimized.

Copy link
Author

@Zhang-Junzhi Zhang-Junzhi commented Aug 2, 2018

The browser or its extensions can somehow disable or block any scripts, including inline scripts. So I'd like to see a pure CSS mechanism to give users information about load failure without script code.

Also, I think automatically adding a load-failure attribute when an element with report-load-failure is a semantical content for a document. Currently, there's no way for the document itself to reflect the semantical fact that something has failed to load.

@benjamingr

This comment has been minimized.

Copy link

@benjamingr benjamingr commented Aug 2, 2018

@Zhang-Junzhi thanks for clarifying, wouldn't a meta property without requiring a CSS attribute make more sense?

img:load-failure {
  /* do something with the fact the image or script did not load */ 
}

html:has(script:load-failure) body::before {
  content: "Failed to load some necessary....";
}
@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Aug 2, 2018

Browsers and extensions can also block CSS or HTML attributes, so I don't think there's anything to be gained here...

@Zhang-Junzhi

This comment has been minimized.

Copy link
Author

@Zhang-Junzhi Zhang-Junzhi commented Aug 2, 2018

@benjamingr Thank you for your opinions.

You seemed to suggest adding a new pesudo-class selector in CSS side. In fact, as @Malvoz mentioned above, CSSWG currently has a discussion about representing resources that fail to load. It would be good to have either. But right now they seem to be talking about visual resources, I'm unsure whether CSSWG will eventually generalize that issue to all resources including non-visual resources, though I have brought up my idea there.

@Zhang-Junzhi

This comment has been minimized.

Copy link
Author

@Zhang-Junzhi Zhang-Junzhi commented Aug 2, 2018

Thanks for the reply. @domenic

A browser in theory can possibly block anything, but I think the propose does help when CSS is enabled while script somehow fails, even if not, that doesn't sound harmful either, to say the least.

Plus it reflects the load status of resources, which is semantical information.

@domenic

This comment has been minimized.

Copy link
Member

@domenic domenic commented Aug 13, 2018

I think your concept of what "semantics" means may be different from how the spec uses the term; this is also evident in other issues you filed. "Semantics" doesn't mean "any information at all" or "any change in behavior". It's about authoring intent, and the contract between authors and consumers of semantic information. See https://html.spec.whatwg.org/#semantics-2. So, it would not be appropriate to talk about the stateful information about resource loading as semantic. (Similarly, I don't believe bidi isolation is semantic information either, but we can continue that discussion in #3908, hopefully aided by experts in the area. I may be wrong.)

I'd again urge you to step back and perform step 1 of the process for adding new features. So far it seems like your use case is:

  • Styling elements differently depending on resource load failure or not
  • In browsers that block scripts / have extensions overriding the default script behavior
  • But not in browsers that block CSS / have extensions overriding the default styling behavior

Is that correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.