I working on a web app. Is it good to use own html tags than divs? I mean using own tags instead of classes. This will make it easier to bind up dynamic content by splitting up common classes with id.
Example
<div id="message">
My Message
</div>
Replace with this
<message>
My message
</message>
I don't understand why you want this, because now HTML5 supports a lot of semantic tags like <audio>, <address>, etc. Usually, you can achive block-effect (i.e. combining or grouping related content in a block) by <div class="myblock"></div> for special purposes. Anyway, as you've asked, then for your information—you can use custom tags in HTML. Also you can style those using CSS and can use selectors to perform operation on those using JavaScript.
Note: Prior IE9 versions don't support custom tags. Hence you should create your tags like this using JavaScript:
<script type="text/javascript">
document.createElement('mytag');
</script>
The main practical reason for not doing this is that IE 8 and older do not let you style your custom tags. As Vishal mentions, there’s a workaround to this, but it does not work when JavaScript is disabled. And as he points out, you can use the class attribute—you should use id only for uniquely identifying a single element.
You can also use class attributes for elements other than div. You can first select an element so that its default (non-CSS) rendering is the best possible (among available alternatives), then add a class attribute.
In CSS, you would then normally use a class selector without tag name, e.g. .message (if you use class=message).
Related
I would like to have a translation in my messages_en.properties containing a link, which opens in a new tab. Is there a way to do this?
I already tried to add
<a target="_blank" href="http://example.com">Example</a>
and
<a href="#" onclick='window.open("http://example.com");return false;'>Example</a>
without success.
Thanks in advance
Most likely your HTML isn't working because of kcSanitize in the template file. Wherever HTML messages are allowed, Keycloak's FreeMarker templates will also wrap the text with this method which:
Allows sanitizing of html that uses Freemarker ?no_esc. This way, html
can be allowed but it is still cleaned up for safety. Tags and
attributes deemed unsafe will be stripped out.
The no_esc allows HTML to render (by not being escaped) but the kcSanitize strips unsafe tags and attributes first. In my testing, I found that "target" and "onclick" are stripped out.
One way that works but that I wouldn't recommend for safety is removing the kcSanitize() around where your message displays in the corresponding .ftl file.
Another idea is adding an id or class to the element in your .properties file and using custom Javascript to set the target="_blank" attribute.
I have seen bunch of HTML email templates example and all of them use <table> element for layout. Is there any specific reason for using <table>? I tried making one without it and it works for me. Should I be worried that it might break for someone else with different browser?
The main reason tables are still used nowadays is to support Outlook 2007/2010/2013. Those versions use Microsoft Word engine to render HTML, and it's quite a mess. It has a limited support for CSS (no float or position for example), and some CSS properties are only supported on some specific HTML elements. For example, padding is supported on a , but not on a . And even when you could theorically use padding on more semantical elements (like tags), or use margin on elements instead, Word's rendering engine is still massively bugged and can have unpredictable behavior with such HTML and CSS code. Thus, developers find it easier to just use instead.
But here's the thing : if you don't feel like you need to support Outlook 2007/2010/2013, then you can absolutely ditch tables and use better code instead. And even if you need to support it, simple one-column layouts can be done without tables. The reason your template works in Outlook 2011 is that this version (for Mac only) uses WebKit rendering engine (just like in Safari or Apple Mail).
Referring to this old post(why-is-it-still-recommended-to-use-tables-for-email-structure) and some of my own experiments:
We can definitely use HTML tags and not just <table> tag. It gets rendered well in modern browsers. I have personally experimented with Chrome ( which most probably means it works on all chromium based browsers ) and Safari.
Another thing I noticed is, the email clients stripped the template and removed all tags except the main content. In other words, it only rendered what's inside the <body> tag and removed other tags like <html>, <head> including the <body> tag itself. So I don't use those tags in my template at all.
I'm trying to figure out exactly what css is included by the standard call to currentDesign.writeCssIncludes(pagecontext); found in headlibs.jsp. The documentation states simply that it is
Convenience method that writes the CSS include strings to the response.
Looking at what it seems to do, it will include /etc/designs/currentdesign.css which is built off the design components css, and /etc/designs/currentdesign/static.css, which is just a static file. But is this all that is will include?
In particular, what I'd like to do is include a clientLib-processed css file as part of my design. One way to do this is to manually build out the css include:
<link rel="stylesheet" href="<%= currentDesign.getPath() %>/myclientlib.css" />
But I'd prefer to let that get generated automatically, so that my designers have flexibility to structure the css files differently for different designs (i.e., for the "base" design they are fine with just a static.css file, but for the "fancy" design they want to use LESS css and break up the files more granularly). And it would be helpful to put design-specific css info with the components they affect, rather then needing to separate those.
You can use the <cq:includeClientLib> tag, combined with themes and/or categories, to mix and match bits of CSS.
But you may find it somewhat limiting; for instance, you can't specify a media attribute. If you need to do this, or your designers don't structure their CSS in a way that fits the themes/categories model, your fallback is the technique you've identified in your question, using <link> directly.
Update
An excellent question about themes! I have only seen them used in passing.
You can define a theme by just adding a new folder/node under /etc/designs/yourproject/clientlibs/themes, as a sibling to default.
You can pull in the clientlibs for a theme with the <cq:includeClientLibs> tag, perhaps under the control of some conditional logic. For instance, in one of my projects I have a theme called authoring which I only want to apply to the author instance; I pull it in with this code in headlibs.jsp:
<c:if test="${ (global['wcmmode'] eq 'EDIT') || (global['wcmmode'] eq 'PREVIEW') }">
<cq:includeClientLib theme="apps.myproject.authoring" />
</c:if>
I have not seen any documentation that would apply theme automatically to a particular subtree of the content tree, or based on the presence of a tag.
There is that cryptic statement "The theme name is extracted from the request." in the Adobe docs, which is backed up by this statement in the Sling docs, "ThemeResolverFilter Provides the Theme for the request. The theme is provided as a request attribute." So perhaps tacking &theme=apps.yourproject.foo onto a query string would apply that theme.
The list of CSS files is based on the property 'cq:designPath' of the page.
The Facebook comments count can be done in three different ways: (without directly using JS)
<fb:comments-count href="http://example.com" />
<iframe src="http://www.facebook.com/plugins/comments.php?href=example.com" />
<div class="fb-comments-count" data-href="http://example.com">0</div>
The issue, however, is that doing something like this messes things up:
<p><div class="fb-comments-count" data-href="http://example.com">0</div> comments</p>
...because a <div> is firstly, not valid inside a <p> tag and secondly, looks wrong (though this could be fixed with CSS).
Basically, my question is: is there a way to do the above without using a <div> (a <span> for example), bearing in mind that I want to use the HTML5 method and (if possible!) want to avoid using javascript?
Clarification: I would like to avoid writing extra JS in the page simply because the MVC view currently looks nice and clean and I would prefer to keep it that way. Obviously, I'm still including the Facebook Connect library.
So, one solution would be to use a DIV instead of a P as the outer element.
I often face a problem when I need to encapsulate some far apart fields in one form, and the fields in between them in other forms. Or encapsulating first two rows of a table in form and other two in other forms and so on. But of-course this is not allowed in standard practice. My question is why such tags like form (and other non displaying tags) have to be treated as "displaying" tags, and they also are restricted to be used at some places. Is there any genuine reason.
PS: what I was thinking about form in particular, that I define as many forms as I want at a single place, and give their references (eg ids or names) to the corresponding fields. That way form tag does not have to interfere somehow with the location of fields?
Asking "why" questions of HTML behaviour is not normally a useful activity. Very often the answer is "because one of the browsers originally did it that way and we're stuck with it for backward-compatibility reasons".
Note also what #DanMan says about the displayability of <form>.
However, your description of declaring forms in one place and then having the controls associate with the forms by id, is very similar to what has been done with the HTML5 form attribute. The only difference is that the controls reference the forms, rather than the forms referencing the controls. All we need to do now is wait for implementations in the browsers.
How is a <form> a non-displaying element? You can apply all kinds of CSS on it, and they will show up. It's just that they usually have no default browser styles. It's a rookie mistake to wrap elements in <div>s and styling those, when the only thing inside them is a single element.
<div class="myform"><form>...</form></div>
<form><div class="myform">...</div></form>
Both equally superfluous. Just style the original element directly.
<form class="myform">...</form>
Now, before you jump on my back: I'm not saying you're doing that. Just a general advice.
About restricted usage: that's probably to make it easier for implementors (browser creators) and for backwards compatibility.