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

InputfieldPageListSelect: flash of native input field before PageListSelect is rendered #794

Open
gadgetto opened this issue Jan 21, 2019 · 7 comments

Comments

Projects
None yet
6 participants
@gadgetto
Copy link

commented Jan 21, 2019

Short description of the issue

When an InputfieldPageListSelect is rendered there is a short flash flash of the native input field before PageListSelect is rendered. (the slower the internet connection the longer the flash)

Expected behavior

The native input field should never be visible.

Actual behavior

The native input field is rendered and visible for a short time before it's hidden by JavaScript and replaced by PageList selector.

Optional: Screenshots/Links that demonstrate the issue

2019-01-21 09-48-03 2019-01-21 09_49_06

Optional: Suggestion for a possible fix

This can be simply fixed by hiding the html input element via CSS by default.

.InputfieldPageListSelect input {
    display: none !important;
}

Steps to reproduce the issue

Add an InputfieldPageListSelect to your page and reload.

Setup/Environment

SERVER DETAILS
ProcessWire: 3.0.124
PHP: 7.2.10
Webserver: Apache
MySQL: 5.7.23

MODULE DETAILS
ProcessGroupMailer: 0.0.1
ProcessMessageLister: 0.0.1
ProcessTracyAdminer: 1.0.6
ProcessWireUpgrade: 0.0.7
ProcessWireUpgradeCheck: 0.0.7
TracyDebugger: 4.16.19

@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2019

The InputfieldPageListSelect is a progressive enhancement on top of a page ID input. I usually try and code these Inputfields so that they operate in this manner where possible (progressive enhancement), so that if Javascript is disabled or something there is still some kind of input. It's not particularly important here since this one doesn't see much use outside the admin, but just as a general strategy for Inputfields I think it's better to retain this behavior, rather than to force hide it with CSS.

@gadgetto

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

You could probably only hide the field with CSS if JavaScript is detected?

@adrianbj

This comment has been minimized.

Copy link

commented Feb 5, 2019

It's not particularly important here since this one doesn't see much use outside the admin

I'm afraid I don't really agree with this sentiment. I believe the admin interface needs to look as professional as possible and PW has many FOUCs. One particular one that is currently annoying me on a complex project is the display of content from other tabs and conditional (showIf) fields that are hidden when the page edit interface loads - it's really jarring to see this stuff load and then disappear.

Sorry, but I think these sorts of details really do matter. I know they can be painful to fix, but there are lot of css/js gurus in the community who I am sure would love to tackle this :)

@teppokoivula

This comment has been minimized.

Copy link

commented Feb 5, 2019

One trick for minimising the FOUC effect is adding a "js" class to some element with vanilla JS as early as possible in the markup (such as right after <html>, or <head> if you have one), and hiding any JS-dependent content with CSS when that class is found:

<script>document.documentElement.className+=' js'</script>

Vanilla JS and "as early as possible" because this way it's executed as soon as possible.

While this won't completely remove the FOUC, it's the next best thing: it ensures that if JS is disabled (and in most cases if there's an error somewhere) the fallback can still kick in, yet it's also so fast that in most cases the flashing part is over really fast :)

@LostKobrakai

This comment has been minimized.

Copy link
Collaborator

commented Feb 5, 2019

While this won't completely remove the FOUC, it's the next best thing: it ensures that if JS is disabled (and in most cases if there's an error somewhere) the fallback can still kick in, yet it's also so fast that in most cases the flashing part is over really fast :)

If the js is in the head it should be executed before the body is rendered. That's the big issue with non defered js in the head and what we worked around with by moving the scripts to the end of the body in the first place.

@teppokoivula

This comment has been minimized.

Copy link

commented Feb 5, 2019

@LostKobrakai, you're right of course.

In this scenario the script gets executed first, assuming that it's the first thing on the page. The rest depends on which order things are laid out: if related CSS is placed at the end of the page, there's likely to be FOUC, but one can indeed prevent that completely by also placing critical parts of the CSS to the top of the page.

In other words what was an issue in the case you mentioned is now the preferred outcome :)

@LostKobrakai

This comment has been minimized.

Copy link
Collaborator

commented Feb 6, 2019

Yeah I mean with <script src="" defer></script there's imho no reason anymore to put any script or styles in the body. And for the rare occations where js should be executed before rendering the body just skip the defer.

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