Should I define my web components <template></template> in the head or the body of my html document? I know I can define it in either, but is there a best practice or any reason at all that I might want to place it in one over the other?
Remember that the content of <template> is not rendered. Technically it isn't even parsed.
If you are creating all of your web components within your page then placement of your <template> tag doesn't really matter, except that placing it after all of your content, in theory, will allow the page to render faster.
If you are using individual HTML files for each web component then place the <template> in each of those.
If you are using JS files for each web component then embed the template as a string or use something like gulp-component-assembler to bring you templates into the JS file.
Related
I'm creating a new website and I will have different pages on it. However, instead of creating new HTML files for each page and an anchor for each, I want all my pages contained in one HTML file. Is it possible in any way?
You can try Vue js or React js or many js frameworks ... which contain components.
Using HTML
You can control HTML page section how tabs working in HTML, take a look in Bootstrap Tabs, or you can hide/show sections using CSS or using JS, you may store HTML for each page in array of js and load that HTML to Body based on URL you create
Using Server Side Language
Also if you need single page application with multiple pages you need a Server Side language, where Database contains your website configurations and you can load based on the URL each page's layout or text like heading forms etc...
I'm developing a React/MaterialUI component that will be embedded in existing websites.
In order to minimise the work needed on the existing page to embed my component, I'm bundling my component into an app.js and the only change requested to the existing page is something like:
<div id="embedded-component"></div>
<script type="text/javascript" src="https://example.com/app.js"></script>
my component finds the div by ID and then mounts on that element.
Things are mostly working but I'm having issues with CSS conflicts between the CSS files on the original page (which I can't modify) and the elements of my application.
For example the original page uses text input elements with a border/padding/color that I don't want my component to "inherit".
I want my component to display the same way regardless of which page is embedded on.
Is there any strategy/tool to use in this case, so CSS classes on existing page do not affect the elements of my embedded component?
Trying to find a solution to this I've come across the Shadow DOM (e.g. https://medium.com/rate-engineering/winning-the-war-of-css-conflicts-through-the-shadow-dom-de6c797b5cba) but I'm not sure how widely supported this is in different browsers.
Is there any solution to this, that is widely supported by all major browsers?
I cannot use iframes and have full control of my js/css files but no control over the existing page other than the "mounting" div.
I am trying to figure out a solution for our AEM related pages. I need to change the class of the body tag in our base page based on the logic of a jsp included in a page jsps. I need this so I can style universal widget differently to deal with different height fixed headers.
So I can't really provide code examples as we are talking jsps, controllers and editable content widgets content writers can add to the page. So its hard as I am not sure how to proceed with this.
So let me try to explain what we have here. We have a jsp base page which has the html tags set, head tag set all the meta data, css and js libraries we use, and body tag sets. The base page would also contain included jsps that represent the site wide header and footer used across the site. We also would have optional sub navigations that can be added to the page for sub sections of the site and is activated based on the type of page template used. So this means a universal header plus a sub-navigation.
Then each page jsp extends the above described base page. These are the page jsps that act as different page templates for our CMS to use. Content authors can drag content, and html widgets on to the page.
We also have page templates that contain their own third level sub navigations that can be used either with the universal header alone or the universal header and the sub-navigation.
We also have a new scenario where there could be a 4th level navigation that can come in to play. This navigation would be a draggable widget in the cms.
So what I want to do is based on the page template and based on which combination of sub navigations are in play, class the body tag differently based on if the page is the universal header alone, or different classes for any of the sb navigation combinations. this is needed so as content authors drag widgets to the page or develop content I can offset content or change scroll offsets to get around different fixed header/navigation solutions
This sounds like a good case for client-side code. One option is to use JavaScript code that runs on DOM content loaded event ("ready" event if you are using jQuery) to alter the CSS class of the body tag. You could make it so each component has a particular, unique class. Then the JavaScript function could examine the page and find all the unique components and then assign the correct class to the body tag based on what it finds and the logic you write in that JavaScript function.
JSPs will be processed top to bottom on the server, so once the JSP containing the body tag has been processed you won't be able to change what was processed to the response in some subsequent JSP that is processed afterwards.
Also see
https://stackoverflow.com/a/9899701/230055
If I have html elements in JSP then what is order of execution?
You could make a call to a tag for writing out the body HTML tag and in the Java code for that tag you could examine the page node and see what other components have been included and then write out the body tag HTML accordingly if you want to do this on the server. But the key point is that you must do this before the body tag is written. Once the JSP has been processed and the body tag has been written to the response it is too late to change it in a subsequent JSP.
For example, in your JSP you would do something like this:
<myCustomTags:bodyOpeningTagBuilder />
<html>
<head>
</head>
<c:out value="${bodyOpeningTagFromBuilder}" />
...other JSPs
</body>
</html>
I have a scenario in which I want to test four different versions of a page, each with different javascript content loaded in the HTML head section.
I would like switching between the templates to behave as though the page has been re-loaded, clearing the state and re-running the JS in the head and body of the HTML file.
Can I do this with four different Meteor templates?
The way I'd do this is to append the JS to the head from within the template's onRendered method, like so:
Template.templateName.onRendered(function() {
$('head').append("insert your script here");
});
So I'd keep the default head free of any of these js files, and just add them in depending on what template the user is on. You can also manipulate the user experience from within the onRendered method as well, using things like $(window).scrollTop(0) to make it appear as though the page has refreshed.
I want to be able to use Meteor template helpers to dynamically specify the content of a <meta> tag. It seems like there is no way to do this.
If I put the <meta> tag in a free-floating <head> element (i.e. not in a template), both will be included correctly in the HTML, but I can't use template helpers.
If I move the <meta> to a template, and try to render the template within a free-floating <head> element, it complains.
And if I move the whole <head> element into a template, now I have a <head> block nested within the <body>, which is ugly, and I suspect invalid HTML (though Chrome seems to handle it gracefully).
Is there a solution?
It is not currently possible to this without post load insertion due to they way Meteor parses templates
Just to bump an old thread as this is now possible on initial page load, you can try out this package https://atmospherejs.com/pip87/initial-iron-meta not tested it outside my environment much but seems to work well. Was hacked apart from kadiras fast render to handle og tags etc getting inserted onto initial page load only so it, doesn't handle switching between pages at the moment only renders for the initial page load which was what I wanted for seo bots. Also needs iron router to work.
Data gets injected from the server side call to the route in the same way the iron routers fast-render package works
I wouldn't recommend this on its own as some bots like Google will penalise if the content isn't available so having ssr or spiderable for seo bots is defiantly advisable to offer a fully rendered page to the bot, this package was meant as more of a fallback for non ajax supporting bots and those only interested in head tags