I have seen this topic and have read, for HTML5, it is not good to put CSS styles inside body tag (embedded; not in-line). I know it may cause FOUC, and that it won't be "valid" HTML.
I have big limitations working in a CMS in the ck editor, and I have very little choice but to embed a CSS style tag and rules or spend days inlining. The styles should be minimal, but still it is ridiculous. I am overriding already styled content.
None of the pages will validate whether I do this or not, and the flash is a lesser problem than what currently exists.
The question: Can someone explain exactly (besides the FOUC and not being valid) why is wrong to do this? Is it a problem for SEO?
Related
We are using this approach to rendering content:
<div id="full-article" v-html="content"></div>
this.content = api.response.data
In this approach, "content" is retrieved from an API, but because we also use Server-Side-Rendering (SSR), the final HTML is turned into this:
<div id="full-article">$real_html_content</div>
this.content = $real_html_content
This approach means that the content is repeated, once as rendered HTML, and once as a javascript variable. But in this scenario we are not using the javascript content variable. The fact that it's still included in the final HTML page means that the page size is twice as big as necessary. How can we prevent this? Is there some way of hiding/removing javascript content that has already been rendered by SSR?
Alternatively, maybe it would be better to deal with this content differently, perhaps insert it at a later stage and not involve Nuxt or SSR?
This is what you're looking for: https://github.com/maoberlehner/vue-lazy-hydration
Created by Markus Oberlehner who was seeking to avoid shipping to much JS to the frontend, especially when this was not needed.
You do have several options but this is how it can be used
<lazy-hydrate never>
<article-content :content="article.content"/>
</lazy-hydrate>
In this case, the hydration (injecting JS into static content) will never happen. There are other interesting options that can be used too!
Keep in mind that this was more of a proof of concept, hence why Markus still considers it as beta-ish. This project will probably die at some point because Vue3/Nuxt3 will be able to do this in an official way.
Still, even if I did not tried it yet, you can totally use it as of right now and enjoy a JS-light experience, it should work!
As the title implies, I need solid SEO and thus I need to have all the HTML loaded on my site on initial load. However, because the backend is written in PHP, and because it would be more work to write my Vue components with the server in mind, I don't want to use server-side rendering (SSR).
That leaves me with the option to send HTML over the wire, the "old school" way. What I am thinking of doing is writing each page's HTML like normal, but make one of the root html elements a Vue element in order to "upgrade" it. So the initial load downloads the finalized HTML, with all the data (tables, lists, etc already populated), but then after all the scripts are loaded, javascript can take over to make things easier and give a better UI experience. This poses a few questions, however:
Am I limited to a single component, the root? It'd be nice to still have many sub-components that would each have their own state. Perhaps inline templates can be used somehow?
Vue templates have their own templating system, like the mustache braces for displaying variables {{ myVar }}. Will I not be able to use them? The one way I can think of is to create a Vue template (that can be loaded from an external script) that is identical to the part of the HTML that it "takes over". The downside is that I'd have to maintain that component both in the original HTML and in the vue template.
Are there any good examples of what I'm trying to accomplish here?
Edit: I want to clarify that I'm aware I can put in various components here and there throughout the page. This still poses the question of how to make those components already start out rendered. Better yet would be to turn the whole page into Vue, much like an SPA.
I need solid SEO and thus I need to have all the HTML loaded on my site on initial load.
This is not entirely true. Google (80% of search traffic) easily parses SPAs now, so SSR purely for SEO isn't required anymore.
But to answer your question in general, you should check out Laracast's Vue.js series. They go in-depth on how to use PHP with Vue.js (including templating and variables).
I'd ask what it is you want to achieve with Javascript/Vue.js in your page. If everything is already rendered in PHP, does Vue provide a simple UX enhancement or takes over most of the page's heavy lifting (navigation, etc.)? If you have no reactive data and want Vue to simply be a controller for rendered components, then knock yourself out, although it might be approaching an 'overkill' scenario.
Have you looked into Prerender SPA Plugin ( https://github.com/chrisvfritz/prerender-spa-plugin )?
It is offered in the Vue documentation as a viable alternative to server side rendering ( https://v2.vuejs.org/v2/guide/ssr.html#SSR-vs-Prerendering )
Recently I've developed a multi-page application using Vue, here is how i tried to solve the SEO (Maybe this can help you ):
Htmls of header and footer (and other main common components) are packed to the page.html(eg: home.html, search.html).
Script and style are of header and footer imported in page.js(eg: home.js, search.js).
Add div.seo-zone to page.html's div#app, which includes the main SEO data(using some h1,h2,p,div and so on), and add
.seo-zone {
display: none;
}
in your css.
4. Make sure your app's root component's el is '#app'(each page's main content can be a Vue app).
Develop your app as usual.
After Vue rendered, the div.seo-zone will be replaced with your Vue components (although it can not be seen)
Protractor 1.7.0 has introduced a new feature: a new locator by.deepCss which helps to find elements within a shadow DOM.
Which use cases does it cover? When would you want to reach elements in the shadow DOM?
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
To answer your question, here's a related question: "what information does shadow dom provide that looking at raw html does not?"
The following snippet creates a shadom dom (view via chrome or firefox):
<input type="date">
If you click on the arrow, a pop up opens with all the dates, and you can select it.
Now imagine you are building a hotel reservation app and you made a custom shadow dom date picker, where it would black out (and not allow user to select) dates when rooms are unavailable.
Looking at the raw html, you see <input type="date">, and the value/dates that a user selected. However, how would you test that the black out UI is working as intended? For that you would need to examine the shadow dom, where the pop up resides.
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
Doesn't seem so in this website that shows an introduction to shadow DOM. It says that:
Shadow DOM separates content from presentation thereby eliminating naming conflicts and improving code expression.
Shadow DOM mainly helps with separating content to avoid naming conflicts and improving your code expression, making it neater and better (I assume). I am sorry to say that I don't actually use Selenium, so here is a website with plenty more information: http://webcomponents.org/polyfills/shadow-dom/
I hope this helps you!
I am new to HTML5 and am wondering which HTML5 tag should be used on a Call to Action div that sits in a column next to the main content on the home page.
Option 1:
<aside>
//call to action
</aside>
Option 2:
<article>
<section>
//call to action
</section>
</article>
The reason I ask is because I don't see either option as being a perfect fit. Perhaps I am missing something. Thanks!
My HTML for the Call to Action:
<section class="box">
<hgroup>
<h1 class="side">Call Now</h1>
<h2 class="side">To Schedule a Free Pick-Up!</h2>
<ul class="center">
<li>Cleaning</li>
<li>Repair</li>
<li>Appraisals</li>
</ul>
<h3 class="side no-bottom">(781) 729-2213</h3>
<h4 class="side no-top no-bottom">Ask for Bob!</h4>
</hgroup>
<img class="responsive" src="img/satisfaction-guarantee.png" alt="100% Satisfaction Guarantee">
<p class="side">We guarantee you will be thrilled with our services or your money back!</p>
</section>
This is a box on the right column of a three column layout. The content in the large middle column gives a summary of the company's services. If you wanted to use those services, you would have to schedule a pick-up, hence the call to action.
Does anyone object to this use of HTML5, or have a better way?
My take is that the best practices for the new HTML5 structural elements are still being worked out, and the forgiving nature of the new HTML5 economy means that you can establish the conventions that make the most sense for your application.
In my applications, I have separate considerations for markup that reflects the layout of the view (that is, the template that creates the overall consistency from page to page) versus the content itself (usually any function or query results that receive additional markup before being inserted into the various regions in the layout). The distinction matters because the layout element semantics (like header, footer, and aside) don't really help with differentiation of the content during search since that markup is usually repeated from page to page. I particularly favor using the semantic distinctions in HTML5 to describe the content the user is actually searching on. For example I generally use article to wrap the primary content and nav to wrap any associated list of links. Widget wrappers are usually tied to the page layout, so I'd go with the convention of the template for that guideline.
Whenever I have to decide on semantic vs generic names, my general heuristic is:
If there is a possible precedent already in the page template, follow that precedent;
If the element in question is new part of the page layout (vs a content query that is rendered into a region in the layout) and there is no guiding pattern in the template already, div is fine for associating that page layout behavior to;
If the content is created dynamically (that is, anything that gets instanced into the layout at request time--posts, navigation, most widgets), wrap it in a semantic wrapper that best describes what that item is (vs how you think it should appear)
Whenever authoring or generating content, use semantic HTML5 markup as appropriate within that content (hgroup to bracket hierarchical headings, section to organize chunks within the article, etc.). This is future-proof enrichment for search.
According to all this, div would be fine as a wrapper for your widget unless your page template already establishes a different widget wrapper. Also, your use of heading elements for creating large, bold appearance within the widget is using markup for appearance rather than for semantics. Since your particular usage is appearance-motivated, it would be better to use divs or spans with CSS classes that can let you specify sizes, spacing, and other adornments as needed for that non-specific text rather than having to override the browser defaults for the heading elements. I'd save the heading elements for the page heading, for widget headings, and for headings within the primary content region of the page. There can be SEO ranking issues for misuse of headings that are not part of the main content.
I hope these ideas help in your consideration of HTML5 markup usage.
So far as the semantics of the markup go, Don's advice makes sense. (As you said your CTA was visually beside the main content and secondary to that content, I would favor aside, but there's no single correct answer.)
However, you've tagged your question with "seo," so I take it you're interested in the SEO benefits of using the right markup. At this time, Google doesn't give special weight to having nice, semantic markup---they don't care about the difference between things like aside, section, and div. This may be partly because the meaning of these tags is still being defined (by the practice of Web devs), but they even seem to ignore tags that are clearly relevant search results (like nav, which will almost always be irrelevant to a page's description in the search results).
Instead, they heavily favor using microdata for marking up rich semantics. In the short term, marking your page up using the Schema.org WebPage microdata will likely provide greater benefit. You can mark your CTA as a relatedLink or significantLink, and keep it outside the mainContent of the page. If you're looking to optimize your page for search, this is a great way to do it---in my experience, Google very rarely shows text outside of your mainContent block in the search results description.
Proper markup depends on the actual content, which you have not provided.
That said, wrapping everything in a div is fine (although perhaps unnecessary) no matter what your content is as the <div> tag has no semantic value. Your two examples are probably not correct, unless your "call to action" is literally an entire article (which I doubt is the case).
The call to action might occur within an <aside>, but it's not likely that the call to action is the aside itself. Once again, that depends on the content (what it is) and context (where it is in relation to other content).
Typically "call to action" is a link somewhere, so the obvious answer to me is using an anchor, <a>.
It's just a link to another page. Use a div.
I'm trying to reduce the size of my CSS file. It is from a template which is very CSS & JS heavy. Even with CSSMin the CSS file size is 250kb.
Whilst I use alot of the CSS - I know I dont use it all. So I'm trying to work out which styles can be removed. I'm aware of Dust-Me selector - but that only takes a static look at the website. With HTML5 and CSS3 - websites are now very dynamic, and most of my CSS occurs from dynamic events, or 'responsive' events i.e. Bootstrap.
Question: Is there a tool which 'records' all my CSS use on a website for a perioid of time, so I can go and click/hover/move over each element and interact with my site. Then at the end let me know which styles were & were not used?
CSS Usage is a great extension for firefox. It tells which css are currently used in a page.
Link: https://addons.mozilla.org/en-us/firefox/addon/css-usage/
There are two tools that I think might help you out.
helium is a javascript tool that will discover any unused css rules.
csscss is a source code analyzer that will report any duplication. I'm biased because I wrote csscss precisely because I couldn't find anything that did this. But many people seem to find it useful.
250kb is really such a big figure for just CSS files.
The templates generally have all the CSS required for all the pages in a single file.
I would suggest:
Do not cut your CSS code, they might be needed some point of time.
Instead i would suggest, break your CSS file into number of small files for different page stylings,
such as a different CSS for login page, different CSS file for home page, etc.
Read your own CSS and HTML code vigorously to find out which significant part of CSS code is used in which HTML section.
Update:
You may try Removed Unused CSS - CSS optimizer.
I personally did not use it just hope it works for you.