HTML- Hiding Divs before page is loaded? - hide

I have a HTML document where the body contains dozens of divs, all listed sequentially. (It's a layout of small screenshots.)
The appearance and layout of each div is handled by CSS.
I wish to selectively hide some divs, depending on some state values. A javascript function "hideSomeDivs()" has been create to do this. (The function iterates over all divs, setting each element's style.display property to "none" as required.)
The problem: calling hideSomeDivs() function from will be too late: the page is already loaded and the visual changes will not be displayed. The original layout is maintained.
Q. how/where can I call this function such that the affected divs will be hidden, and all layout adjusted accordingly? Thanks.
Further information:
apart from javascript interactivity, the page is static (i.e. there's no server-side processing available).
also, I'm trying to avoid any "pop" where elements are shown/hidden after the page is loaded and drawn to the window.
also, I need for the layout to be re-evaluated and re-drawn. e.g. if I hide divs 1 to 4, but show div 5, then div 5 should appear at the top of the page.

Think about it the other way round - hide all your divs by default, and then use the javascript to show them as needed.
Of course you could just eliminate the need for the javascript if you have a server side language (i.e. PHP, ASP.NET) that is constructing the page, then you can just set their hidden state correctly to begin with.

In your HTML code put in a style code that hides the div by default. This will be evaluated much earlier than the Javascript.

Do you possibly want to maybe call the "hideSomeDivs()" function on the onload event of the body element.

Related

How to use Growl with 'position: sticky' in Primefaces?

I am trying to change the p:growl position of primefaces through the .ui-growl class to use position: sticky. However, since the component is rendered at the end in body, the relative behavior of the position does not work as I would like.
Is there any way to use the sticky position for this component?
Or some way to get the component to render where it is declared?
PrimeFaces 5.1;
Mojarra 2.1;
Disclamer: I tried this with the PF 7.0 showcase, but I think the basics also work with the 5.1 version.
You effectively have 4 options. The latter three all need you to inspect the javascript source of the component (which is open, so you can ALWAYS inspect it before asking questions, the java source is irrelevant here) and for the first solution it helps to see how the component works, but inspecting with a browser developer tool is sufficient (that is how I did it).
Basic analysis with or without looking at the source
This is a variant on your "Or some way to get the component to render where it is declared?". Since on the client side, it is all plain html, css and javascript, you can manipulate with al tools available on the client-side.
You can see that the main part of the grow is html technically rendered where it is declared. Check the PrimeFaces showcase and you'll see
<span id="j_idt700:growl" class="ui-growl-pl" data-widget="widget_j_idt700_growl" data-summary="data-summary" data-detail="data-detail" data-severity="all,error" data-redisplay="true"></span>
right inside the form where it also is in the xhtml. The javascript of the component creates the client side dom things, amongst which is the container that you see right before the end of the body (from the showcase)
<div id="j_idt700:growl_container" class="ui-growl ui-widget" style="z-index: 1002;"></div>
This last piece is html is where the individual growls are added to when they need to be rendered and hence the part that makes the component in most normal cases behave correctly but needs to be done differently in your case.
Solution 1, pure client-side component agnostic solution
Effectively this is as simple as moving this piece of html in the dom, see How to move an element into another element?.
In the online showcase I put the following jquery code in the browser developer tool console
$("#j_idt700\\:growl_container").prependTo(".layout-content");
And added the following css
position: sticky;
top: 10px;
float: right; // this is needed in the showcase, might not always be needed
And it worked.
The jquery should be put somewhere in your page where it runs after the component javascript is executed, so best is to do it right before the end of the body.
Keep in mind that the j_idt700 prefix is the dynamic id of the form in the showcase (it does not have a fixed id here), but you can also use different selectors based on the classes or whatever)
Solution 2, changing the source 'locally'
In the javascript source, you can see where the container is technically rendered
render: function() {
//create container
this.jq = $('<div id="' + this.id + '_container" class="ui-growl ui-widget"></div>');
this.jq.appendTo($(document.body));
//render messages
this.show(this.cfg.msgs);
},
Changing the this.jq.appendTo($(document.body)); in some way to have it appended to the current html node ('this'?) will make it work too. Regarding the overriding, you have two options
How do I find and/or override JavaScript in Primefaces component based on widgetVar?
Override a method from a Primefaces specific widget
Solution 3 Changing the source server side
Effectively you do the first part of #2 but patch the source and create a new custom PrimeFaces version
Solution 4 Make this feature avaiable for others too
What can be done here is to create a new attribute on the component and patch the source in some places so it is configurable to have the component behave as it is now or as sticky (they changed the existing 'sticky' attribute to 'keepAlive' in 7.0.x so sticky is avalable again ;-)). Of course this should be submitted as a patch then...

In Chrome extensions, why use a background page with HTML?

I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.

Orchard CMS: Add a stylesheet to a page

Setup:
I am using Orchard CMS 1.6.
I have a site where I need to be able to set the background color of the whole page. Ie, I need to style the body tag.
I could use the LayoutSelector module and have distinct layouts. However, the only difference in each layout is that the background-color rule for the body tag is different. So it seems a very un-dry way of doing things.
I can't find any way to make Vandelay.Classy add a distinct id or class to the body tag (it adds, as I understand it) an id or a class to the outer tag of a content type. In my case, that isn't the body tag.
So that is no good, I really do need to customize the body tag.
How to do this?
Note:
I need 3 different background colors. I also have a two column layout and a three column layout. [I use (a modified version of) the layoutSelector module to achieve this.] So to have 3 different colors of background, and I used layouts to achieve this, I would need 6 different layouts: TOTAL overkill.
There must be a better way...
From any cshtml file, you should be able to access the Layout shape. From pretty much anywhere else, you can still get to the Layout shape through WorkContextAccessor. Once you have a reference to the Layout shape, you can do Layout.Classes.Add("the-class-you-want").

How to create a general-purpose VisualForce page that can appear on any layout?

VisualForce pages can have the format:
<apex:page standardController="Case" >
<div id="content"></div>
<script>
... javascript to render a UI into #content ...
</script>
</apex>
which means it can appear on the "Case" layout. If you want a generic VisaulForce page (appearing all alone on a tab, let's say) you can remove the standardController parameter:
<apex:page>
...
</apex>
Is there a way to specify that a single VisualForce page can appear anywhere? (In our case, it's a javascript utility which is not layout-dependent).
I'm new to SalesForce, and the closest I could come up with would be to dynamically populate the standardController field (if that is supported) but I feel there must be a better way. Any help is greatly appreciated!
Do you mean it's a piece of javascript you can include in other pages? If so you should be doing it as a component, or you could put the JS in a static resource and include that in your pages.
If it's actually a page, you can include it in a page layout as well, though it's a little clunky and goes in an iFrame so that would probably cause problems for you.

Web accessibility and h1-h6 headings - must all content be under these tags?

At the top of many pages in our web application we have error messages and notifications, 'Save' and other buttons, and then our h1 tag with the content title. When making a web application accessible, is it ever acceptable to have content above the top-level structure tag like we do here?
As a screen reader user I don't like content above the main heading. Normally I navigate by headings so would miss the error message. A better solution is to output an h1 heading above the error message, then leave the rest of your headings in tact giving you two h1 headings.
Yes (you can put stuff above them). The H simply means Heading. It's a question of what the heading relates to I guess.
My only caveat is, H2 shouldn't really be above H1, and H3 Shouldn't be above H2. But I don't think it's an actual rule.Websites have menus, warning, notifications. It's acceptable to put them above the rest of your content. I don't see how it would affect accessibility as long as your content is ordered logically. Look at the page CSS turned off. Does it look logical? That's the most important part of accessibility.
Although some people do go that extra mile and have the menu as the last item in the markup and use CSS to bring it back to the top. Personally, I find that solution counter productive. The menu is still important, it belongs at the top of the page.
Yes, just consider it is in that order that the user will get the information. So, if you just did an operation it sounds like a good idea to get any message related to it as the first thing. If it is a notification that appears on any page unrelated to what you are doing, I wouldn't put it above, as it might be a little weird.
Also you can use a text browser that doesn't use styles, it should look like a document with appropriate headers.
Heading tags are used to indicate the hierarchy of the content below it. You should only have one h1 tag and it should be the first content to appear on your page (this is usually the name of the site). Also, you shouldn't skip heading tags when drilling down through different tiers of content.
In your case, you can still use CSS to position items above the h1 tag as long as it is in the correct order in the html.
I assume the elements above the heading are used by JavaScript. In that case, it's preferable if they are created by JavaScript, not included in the source of the page.
To return to your original question, it is probably best that they be at the foot of the page. However, if they are hidden using the CSS "display: none;" or "visibility: hidden;" properties then they will not be seen by most (perhaps all?) screenreaders or by many other assistive technologies, and so should not be an issue. I've written a fairly detailed explanation of why accessibility technology ignores such elements.
Of course if somebody disables CSS things are going to look pretty messy. If there is content on the page that can be used even when CSS and/or JavaScript are disabled, then putting those elements at the bottom of the page will at least make things less cluttered.

Resources