Develop Reference

Weird elements in code that appears to be HTML

I'm currently modding a game and everything works fine when I use basic commands & attributes for formation etc. but there are some elements that I can't identify and modify as I would like.
Hopefuly someone can help me out, here's the code, elements in question follow
tr "game_spell_tooltip_EkkoQ" = "<titleLeft>Timewinder</titleLeft><titleRight>Level #Level# [#Hotkey#]</titleRight><subtitleLeft>#Cost# Mana</subtitleLeft><subtitleRight>#Cooldown# sec Cooldown</subtitleRight><mainText>Ekko throws a device that deals #Effect1Amount# <font color='#99FF99'>(+#CharAbilityPower#)</font> magic damage to enemies it passes through. It expands into a slowing field on the first champion hit, slowing everything inside by #Effect2Amount#%. It then returns to him after a delay, dealing #Effect3Amount# <font color='#99FF99'>(+#CharAbilityPower2#)</font> magic damage to all targets hit upon return.</mainText>"
The elements in question are <titleLeft>, <titleRight> and the same for the subtitle elements
I've tried to implement another title in the center, both <titleCenter>, <titleMiddle> and simply <title> won't work, it just doesn't show up
Any other modifications like <br> and basic formation attributes work perfectly fine, but those are in the maintext
An example of my experimental slaughtery here
tr "game_spell_tooltip_EkkoE" = "<titleLeft>Phase Dive</titleLeft><titleRight>Level #Level# [#Hotkey#]</titleRight><subtitleLeft>#Cost# Mana</subtitleLeft><subtitleMiddle><font color='#F5E5D4'; size='2'><i>Dash & Teleport</i></font></subtitleMiddle><subtitleRight>#Cooldown# sec Cooldown</subtitleRight><mainText><font color='#7C03FC'>Magic Damage: #Effect1Amount#</font> <font color='#99FF99'>(+#CharAbilityPower#)</font></mainText>"
The subtitleCenter doesn't work either.
Any ideas?
Best regards

They're probably custom web components.
As described by Rob Dodson on CSS Tricks:
Web Components are a collection of standards which are working their
way through the W3C and landing in browsers as we speak. In a
nutshell, they allow us to bundle markup and styles into custom HTML
elements. What's truly amazing about these new elements is that they
fully encapsulate all of their HTML and CSS. That means the styles
that you write always render as you intended, and your HTML is safe
from the prying eyes of external JavaScript.
You can find out more here: http://webcomponents.org/

Effeciency, hidden HTML or JavaScript DOM appending?

I am working on a simple Cordova app with about 4 page types and I am trying to think through which is the better way to handle the inner HTML templates.
Hidden HTML hard coded into the HTML files that is hidden and populated/revealed by my JS.
Using a JS template system and appending and removing from the DOM.
I feel that appending all that to the DOM for a page is inefficient when I could just update the sections that change. But perhaps an append is lightweight enough where I shouldn't worry about it.

There are a number of ways you can do it. In terms of load on the browser. That is hard to say. From your question it is hard to know what is in these pages, what are you displaying, is it live data, static html etc.
When you first plot out an app, if you are from the old class of building multiple page websites, it can be a little concerning as to how well your app/page will run with all those pages crammed in to one, and all that data plus code.
The answer is, amazingly well. If done properly in modern browsers, and for example Ipads the app will run to near native performance.
The options you have are
Map all the pages into one HTML document. Hide each page content using css display:none, flip them into view using css animation, fading or just display:block.
Use a javascript routing library to map urls to blocks of code that deal with each page, this makes mapping out your app much easier, and means that buttons can just link to your pages, like a real website. see http://projects.jga.me/routie/
Building all the page templates into one page can make it hard to code, as the page becomes enormous, consider breaking the inner content of each page into separate files, you can then give each page holder a url and use a small xhr request to load the page on-the fly, once loaded you can cache it into memory or even local-storage, depending on whether you remove it when it is closed or keep it hidden.
In my experience you can put an enormous number or nodes into one page and have very little speed drop, bear in mind if you use something like jquery and do a lot of $(".page > .page1 > .items li") your going to have a slow app.
Tips
Use element ID's everywhere document.getElementById(..) is 100's of times faster in a loop that $(...)
cache elements when you find them, if you need them later store them in a memory cache.
keep for loop inner code to a minimum.
use a decent click touch libary like http://hammerjs.github.io/ and delegate all the events of the body tag or at least on each page.
If you need to touch the server, load data, think dom first, device second server later. A good app is a responsive app, that responds to the user instantly.

I know this has been posted a while ago, but for the sake of the users I am going to add my answer.
I completely agree with MartinWebb but my answer will shed some light on the results of his options. I am currently working on a similar project. Please note that this answer pertains to cordova (previously called phonegap) specifically. My app has about 5 pages with +-20 different components (input's, div's, h1's, p's, etc.). This is what i tried and the result of each:
jQuery was my first option, mainly because it is easy to use and reduces the amount of code required to accomplish a said goal. Result: First time I tried this approach I though I would spice it up with animations and transformations. The result of this was a very unresponsive app. I removed the animation and transformation, however due to the nature of my application I required multiple dynamically added components and jQuery just wasn't up for the task.
Css display:none and visible:hidden was my next option. I used javascript's dom to display certain div's. Result: This works if your not planning on switching many div shortly after one another eg. a simple menu. It quickly became apparent that this wasn't going to work. Also this does not eliminate my need for the dom. Remember document.getElementById('menu').style.display = "none"; is still part of the dom. This as a solution, for me, is poor. There is a reason that var menu= document.createElement('div'); is part of the language. Which brings me to my last option.
Building a page 90% on javascript's dom was my last option. Logically I could not see how 600 lines of code cold trump one .innerHTML or .style.display = "block"; but it did. Result: It was by far the most responsive of all the solutions.
I'm not saying that all webpages should be coded with dom appending, but as I stated previously, for a cordova app of a few pages (<6), with a few components a javascript dom appending approach would be best. It takes longer to code, but you will be rewarded with control and efficiency. I would suggest coding the backbone of your app in html and populating and controlling with javascript's dom.
Best of luck.

The first option, <div>s with display:none; would be more efficient by a small margin, but you can get the best of both worlds by compiling your JavaScript and templates together into a single file using something like browserify or require.js.

Raw AngularJs markup appearing in Google search results page

We just updated portions of our website with AngularJS - particularly the login page. When I look at the search results in Google, the cached page and the small snippet it displays automatically is the raw Angular markup. So, lots of {{model.username}}, {{model.errorMessage}}, etc.
I won't link the results since it's too embarrassing.
Any idea of how do get Google to actually store the page as rendered vs. the raw HTML?

It would be wonderful if you would convert your embarrassment into a community service for all of us by testing something, since you are seeing a condition few people admit to or want to reproduce themselves. :)
Google is known to be relatively (or very, depending on who you ask) good at ignoring hidden content. They implemented this way back when people used to keyword-stuff content by using blocks that were either set to "display: none" or had a tiny/unreadable/white-on-white font.
What you're seeing is a problem for more than just SEO, so I'm suggesting this because things like prerender.io are great but they only solve that one piece. What about users who simply have slow browsers? Well, it turns out Angular has a great solution for this called ngCloak. It hides things like template content fields (ngModel mappings and bindings, expressions, etc) until Angular is ready to fill them in itself.
It's very easy to implement this; you just need a small block of CSS (in an early-loaded file, or embedded directly into your HTML page):
[ng\:cloak], [ng-cloak], [data-ng-cloak], [x-ng-cloak], .ng-cloak, .x-ng-cloak {
display: none !important;
}
and then you apply the ngCloak directive to items that are affected, or to a high-level parent (like your ng-view DIV):
<div id="wrapper" ng-cloak>
<!-- Page content here -->
</div>
This works kind of like a no-js target, but specifically for AngularJS.
You'll still want something specific to give Google that is actually good material, but at least with the above you can filter out everything else.

SEO for angular is a really big question/issue depending on your perspective. I would start by reading http://www.ng-newsletter.com/posts/serious-angular-seo.html and http://www.yearofmoo.com/2012/11/angularjs-and-seo.html to get you started.
To sum up your primary options:
change your routing system to use the hashbang (#!). Then sites like google and facebook will convert the hashbang to _escaped_fragment_ before querying your page. This gives your server an opportunity to return different html.
use a service like http://prerender.io which will pre render and cache rendered versions of your site for you, which will be provided to google in place of your site.
There are still issues with things like sharing to reddit and stumbleupon for example, as they are lazy and don't want to develop to cater to angular based sites. So for certain circumstances you will have to get creative.
Update: One thing we have done on a recent project is look at the various user agents to determine if crawling systems are asking for page information. This way we can serve what ever we like.

How to make controlls for epub using HTML 5,JavaScript and CSS?

Ok so we have to implement an online e-reader using HTML5, JS and CSS. So far I have a pretty good understanding of those 3 technologies. What basically needs to happen is that a user picks a book from a gallery of links which takes him to a page to read the book.
Apparently the the epub file should be loaded into memory on the clients computer, unpacked and then displayed on the webpage. Up untill this point I don't have too many problems, what really racks my brain is what comes next.
So all the chapters are divided into seperate xhtml pages aswell as the cover, title page, table of contents which makes creating navigatable dynamic links to them not too hard. But, we also have to provide controls to change the font, colour and navigate between pages.
How do I implement this?
Does the JS to do this come in the page that loads the epub files and if so, how do I write JS that changes properties of a page loaded in the page the JS is in?
I can't think of another way to do this except to put a small JS widget on every single chapter, but then the problem of "turning pages" still exists as I do not know where one page starts and the other ends as this isn't specified in the xhtml files.
I'm sorry if I'm unclear or did not provide enough information, although I have worked with JS, HTML5 and CSS alot the whole epub thing is pretty new to me.
Any help would be appreciated.

I would check out one of the few open source projects dedicated to epubs on the web to get you started. You seem to be asking many questions so rather than answer specifically, I recommend you look at how some others have tackled the problems.
First you should check out Readium: http://readium.org/ They have many of the functions you've described (changing the font, picking a book from a library, etc.)
Next I would look at my personal project https://github.com/fchasen/epub.js
We do things a little differently but again it be a good place to look at how we've handled some challenges so you can come back with more specific questions.

How to implement an Enterprise-grade JavaScript "framework" for web designers?

I have been tasked with improving the current mess that is our JavaScript "strategy"; we're an online shopping company and my boss has given me time to do this properly. He is very keen on keepin this modular and increase the reusability of the components.
Our HTML is being rendered with JSP and we have lots of custom tags writing out, for example, information about products without the web designers needing to worry about it.
Now, we want to do similar things with JavaScript. The web designers should be given a set of custom tags, like, say,
<foo:draggable>
... some HTML here ...
</foo:draggable>
that will wrap the HTML in a <div> with a drag bar at the top and a close button.
My idea is to mark the div with a unique namespaced CSS class name, like foo_draggable, and then put all my functions in a single JS file. That JS file then sees if there are elements with the CSS class foo_draggable in the DOM and if it finds any it will attach the required event handlers.
However, I am worried about scaling problems, and wondering whether it is a good idea to have lots of selector queries running when they quite often aren't going to be used.
The first alternative would be to initiate each draggable item explicitly but that would mean putting <script> tags all over the place. The second approach would be to not put all UI function in one file but rather just download the ones I need, but that would mean lots more HTTP requests and slower page load speed.
Has anyone got experience with this?

What about having two classnames?
<div class='foo fooDragable'></div>
<div class='foo fooSortable'></div>
You add the class 'foo' to all your elements that require javascript modification.
Your javascript has to check the dom only once for foo.
var $foo = $('.foo');
Afterwards you can search within this array which should be way smaller than the complete dom.
var $dragAble = $foo.filter('.fooDragable');

Have you considered or taken a look to JSF? I know it's a major change if you aren't using JSF yet. But there are lot of ready-to-use JSF component libaries with an ajaxical sauce, for example RichFaces, IceFaces, PrimeFaces, etc. It's almost a waste of time to create components/tags for it yourself.
Alternatively you can replace all Javascripts to use the great jQuery JS framework.

Depending on how many separate components you have, the extra overhead of running the selectors might not be a big deal. You can initialize all the components just the once, when the page is loaded. Anything that's not present on the page simply won't get initialized, and will incur no further overhead. In most JavaScript frameworks, selecting by classname (or tag name) is pretty fast. It's only the complex selectors, which aren't natively supported by the browser, that are slow.
If you have a few commonly used components, and then a set of less commonly used ones, it may be worth splitting those up. Keep the commonly used components in a single JavaScript file (minified, served with compression and aggressive caching), and load that in every page, regardless of whether it's needed or not. Caching will ensure it's only downloaded once, and it'll only be one small HTTP request. For the less common components, keep them in separate files (ideally, one per component), and add a script tag on pages that use them.
I'm not entirely familiar with how JSP works, but it might be possible to do this automatically - if a tag is included in the document, add a script tag for foo_widget.js in the document header, or something like that.