I've been working on a web app with UI built using the Html Service. It's known that HtmlServices uses Caja Sanitization in pre-processing. As a result of this I see that id's of HTML elements are mangled, '-caja-guest-0___' is append to the original id.
I wonder 2 things:
1) What are best practices if I need to be able to get elements by their id's?
2) Can I rely that that suffix will always be '-caja-guest-0___'? Or is there a rule for it?
Thank a lot for all your responses.
You shouldn't rely on any specific things that Caja does because we are and will be making lots of improvements to Caja, which may change how things are implemented. I'd think of any Caja specific changes as private variables in a class you're using: don't rely on them to stay the same.
When working with element IDs, $("#elementId") should just work as expected in jQuery. I would recommend doing this.
I've tried using jQuery's "$" function to select elements by the ids assigned in original un-sanitized code and it worked as expected. I think that CAJA also applies the changes to your code so the IDs match
Yes, and document.getElementById should work fine as well. Rule of thumb; don't worry about Caja.
Related
What does data-component-bound="true" mean?
I've found this within a collapsed element but adjusting the value doesn't do anything. I've tried looking for the attribute "data-component-bound" on Stack Overflow and on Google but it points to a limited set of various jquery articles which are over my head and which take it for granted.
[edit post some answers]
Ahh, I see now that i should have been searching for "data-" to solve this. In so doing, I found this useful article which could help the next person: http://www.sitepoint.com/use-html5-data-attributes/
data- attributes are extensible: the author of the code can make up any data attribute they like. In this case, from a quick look, it seems it is used for the internal workings of websites to know when the 'component' (i.e. DOM element) is 'bound' to something - an event, an interaction, etc.
In general, data- attributes are used for that: data. They store any data, so are often used to substitute non-standard attributes that would otherwise flag up in a validator.
HTML data attributes allow you to set custom data for an element. The meaning of data-component-bound is determined by your code or some css or javascript framework that you might be using.
Search the codebase for 'component-bound' to see if it's being used. If you don't find anything, Google it to see if it's a popular attribute from some framework. If it's not, then you're safe to remove it.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_data_attributes
According to many recent HTML specs, when we are using custom attributes (meaning any attributes not defined in the spec), we should prefix them with data-. However, I see no reason to have to do this (unless you require perfectly valid HTML, obviously). Pretty much all current browsers correctly ignore custom attributes, meaning no conflicts except with identically-named attributes from others' code, and we can ignore even this with custom prefixes or something similar (as suggested on the AngularJS directive page). What, if any, other benefits are there? This question has been asked before, at least twice, but both are pretty old.
I forget where I read it, but some guide said custom HTML tags need dashes, and single-word tags aren't valid. First of all, why? Second, should we do this, and why (besides being valid)? Would there be any problem with underscores or camelCase, etc.? Also, conflicts with existing elements shouldn't be a problem, if, like with data attributes, you prefix or suffix them, etc. See the Angular directive page again.
I'm sure all these questions have been asked before, but I'm combining them into one. Is that a good idea (quick, someone ask on Meta)?
The data-* attributes have two advantages:
It is a convention meaning other programmers will understand quickly that it is a custom attribute.
You get a DOM Javascript API for free: HTMLElement.dataset. If you use jQuery, it leverages this to populates the keys and values you find with .data().
The reason for the - in custom element names is for two basic reasons:
It is a quick way for the HTML parser to know it is a custom element instead of a standard element.
You don't run into the issue of a new standard element being added with the same name which would cause conflict if you register a custom Javascript prototype for the DOM element.
Should you use your own custom element name? Right now it is so new that don't expect it to be fully supported. Let's say it does work. You have to balance the issue of the extra complexity with the benefit. If you can get away with a classname, then use a classname. But if you need a whole new element with a custom Javascript DOM prototype for the element, then you may have a valid usage of it.
I have some special tags on my blogsite which need to be as simple as possible so that my colleges who don't know anything about HTML can use it. For example
<question>...</question>
and
<answer>...</answer>
and then these are styled in CSS. It's far easier for HTML-idiots than to use the <div class="answer">...</div> format.
I've just found out IE8 is displaying it all wrong while Firefox and Chrome do it right. Is that expected or am I doing something wrong? Do you know of any hack to fix this since there are tons of blogsposts I'll have to manually change otherwise!!
You want to create <question>...</question> etc.
These are not HTML (not even HTML5), and you will struggle to get browsers to understand them reliably.
A quick tip that might help you:
You say you've got it working in all browsers except IE. If so, you might be able to hack IE to get it working as well, using a technique similar to the hacks like HTML5Shiv that are being used to get IE to work with the new HTML5 tags. These use Javascript to create a DOM element with the new tag name, after which IE suddenly starts to recognise that tag as being valid HTML.
It might just work. But be aware that it is a hack, and it only targets IE. And since you're using non-standard tags, you also have no way of knowing what will happen in the future in terms of it breaking browsers, even if they work now. (in fact, I would say the worse case scenario would be if one of the tags you've invented is added to the HTML standard at a later date, because then you'll start getting weird layout glitches as it gets added to the default stylesheet)
If you can get it working that way, then well done. But consider yourself warned that it's not good practice.
What you have actually asked for is not HTML, but XML markup. This is perfectly fine, but shouldn't be put directly into a web page in the way you're hoping.
There are a number of well-documented ways to get raw XML code into a browser.
One option is to use XSL to transform it into valid HTML. Another way would be to load it into a DOM object in Javascript and process it using a script. (this is where the 'X' comes in 'Ajax').
My guess is that a simple XSL transformation would do the trick for you. (In fact, it sounds like your use case might be simple enough that even just basic string replacement might suffice for the same end result). You can get your colleauges to create the code using <whatever> <tags> <they> <want>, and you write a script that parses it and converts it to regular HTML prior to merging it with the rest of the page.
In the long term, this would probably be a far better solution than the hack I've described above.
Hope that helps.
I don't know if this answer fits your needs but imho using custom html tags is basically NOT using HTML. Therefore the absence of compatibilty.
If you need to render data in HTML wouldn't be better using XML + XSLT?
You can find guides on w3schools
You can't add new elements like that. HTML has some fixed elements that browsers understand, but if you add your own, browser don't know what to do with them.
HTML5 has some new elements you can maybe find useful : http://www.w3schools.com/html5/html5_new_elements.asp but this won't work with older browser without some kind of javascript to fix things. For example http://remysharp.com/2009/01/07/html5-enabling-script/
However, if you really want to add new tags, it is possible to do so and then "modify" them via javascript to known tags (actually it's what the html5 enabling script of IE do), but it won't be possible to apply CSS easily to the new tags.
In short, I strongly advise against adding new tags. It's not that hard to understand something like <div class="answer">.
sounds like you want to write XML and convert to HTML using XSLT. This is an old tutorial (includes defining an DTD), but a further web search will garner more results that might suit
here you go fella:
http://net.tutsplus.com/tutorials/html-css-techniques/how-to-make-all-browsers-render-html5-mark-up-correctly-even-ie6/
You need to use createElement :)
So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?
I keep seeing things like <div ... g_editable="true" ... >.
I've searched for anything to help me understand its purpose, but all I get back is more markup and nothing explaining it.
Can somebody please explain it?
The g_editable="true" attribute is used by Google in their Gmail email composition (and likely other Google products as well). Instead of using a textarea tag they use a source-less iframe and all of the email contents are highlighted, typed in, made bold, adding line breaks etc are all handled by javascript so that it resembles a textarea, but with a lot more functionality.
The g_editable="true" attribute itself is likely to limit the scope that different functions and events have so that you can't just boldify text in your contacts list and that sort of thing. It's probably why they have it in an iframe as well.
It may just be a custom attribute defined by Google. It could be a hook for their JavaScript and/or CSS.
For best practice though, they should have prefixed it with data-.