I've been doing some searching around and couldn't find this topic anywhere. My company wants to use an HTML doctype but wordpress outputs XHTML by default. I've seen plugins and I would use these but this site will probably outlive the development of said plugins. Plus it's something else to account for when updating or building new sites.
If I use an XHTML doctype how will HTML5 browsers render it? Will they be backwards-compatible with old doctypes?
Edit 1: It is actually recomended that in order to make the transition to HTML5 easier that you try to follow the XHTML structure when writing any HTML.
There will be additional options and types with XHTML in HTML5 but a lot of it is based on the structure in which you are writing your HTML. The X simply means that it is moving to more of an XML base.
To go along with Kayla's input, you will want to make sure that all tags are being closed:
<br/> Instead of: <br>
You will also want to make sure to put quotations around any parameters:
Instead of: <a href=value></a>
Browsers have been slowly adopting the XHTML structure. This might mean that HTML that is formatted without end tags/etc might look a little different in IE 6 than in newer brower versions. Hope that helps!
It is not recommended to use the XHTML 1.0 or 1.1 doctypes for your HTML5 pages, one because its unnecessary and two your markup won't validate when you use the newer tags. Here is a quick guide on using XML syntax in HTML5 a.k.a. XHTML5.
Update: As noted bellow checkout the W3C Specification.
I am not sure what you are asking. What do plugins have to do with DTD?
Yes, any browsers that supports HTML5 is backwards compatible with (X)HTML, you can mix and match all you want. And basically as long as you are writing tags like:
<div>Hi</div> or <p>There</p>
instead of
<DIV>Hi</DIV> or <P>There</P>
the rest is just semantics.
HTML5 began life specifically because browsers manufacturers wanted to make sure that changes they introduced were backward compatible with existing web pages, in contrast to the now defunct XHTML 2, which was shaping up to be non-backward compatible.
So yes, your XHTML doctype will work just fine in HTML5 browsers.
As far as I know all modern browsers that are adding HTML 5 support will continue to support HTML 4 and XHTML for the foreseeable future so you should be fine.
If you're using Wordpress though stick with XHTML. It'll be supported for a long time to come in all browsers and most Wordpress plugins are designed to output XHTML.
Related
We want to migrate our project from IBM WebSphere 6.1 to Tomcat 6, but in our JSP-JSF UI pages we have extensively used below IBM JSF tags.
ScriptCollector
PanelRowCaregory
PagerWeb
OutPutSelections
InputRowSelect
InputHelperDatePicker
InputHelperAssist
ConvertMask
And to replace above tags, we are trying to find the equivalent tags from Sun JSF or any other open source libraries, but we didn't find any equivalent tags.
I wanted to know whether any body has already worked on this kind of migration project, if yes can you please share the equivalent tags?
or if you solved it differently even that info also will be useful.
Thanks in Advance.
There's no standard JSF equivalent for the <hx:scriptCollector> (although the JSF 2.0 <h:head> comes close). The <hx:scriptCollector> is only required by those IBM-specific <hx:xxx> components. It's designed to collect all JavaScript files required by those <hx:xxx> components and then render the desired <script> tag(s) without potential duplicates when multiple components require the same JS files. It's not required by any standard JSF component.
In other words, just get rid of it without replacement.
As to other tags, just check the available standard components in tag documentation or Java EE tutorial. If none is available, just pick a component library like PrimeFaces or RichFaces. If you still can't figure out, ask an individual question for the particular tag.
In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
I want to understand the basic mechanism of <ui:remove>. As per my knowledge, <ui:remove> is basically used in conjunction when basic HTML stuff is part of your Facelets page. When you want, when rendering of the Facelets page happen, it should ignore this part of HTML code, we can use the <ui:remove> tag.
Still I am confused about practical implications of <ui:remove>. How often we need to use this Facelets tag? Additionally, the Facelets page is not compiled everytime when the page is hit.
It's useful to remove content which is required during design time, but not during run time, such as comments, some stubbed content (e.g. "lorem ipsum") which aids in filling up the page content to fit the layout in visual designers such as Dreamweaver, etc.
If you're not a page designer, but already retrieve designs as PSD/AI/etc, it's indeed useless to you.
See also:
Is there a way to run a JSF page without building the whole project?
Outcommented Facelets code still invokes EL expressions like #{bean.action()} and causes javax.el.PropertyNotFoundException on #{bean.action}
JSF display HTML comment
Is it possible to make the PrimeFaces's Editor component, right to left?
It seems not to support dir and style attributes... :(
in my experience controls in jsf framework like prime/open/etc.. don't support RTL using html #dir,
usually the interfaces of these controls are built using Javascript, so probably you should work at that level.
Can I suggest you to consider two other alternatives to jsf controls in this case?:
Using a javascript html editor (like elrte, maybe is easier to customize and it has also Arabic translation). http://elrte.org/
Using the Flex html editor (is Flash, if you can, and Flex support RTL for all controls)
F.
Just bumped into this thread by accident,
anyway I remember that i did the RTL with jquery like this:
<script type="text/javascript">
jQuery(document).ready(function($) {
$("j_idt33:inputtextlist").contents().find('html').attr('dir', 'rtl');
});
had to find the id with firebug , inputtextlist was the id i gave to the editor , and ypu can always use a smarter jquery selector (with suffix match)
I am a designer whose main marketing strategy is multi browser compatibility. I assure my clients that the site will work even in IE6 (!).
Of late i have been pondering over the question of moving to HTML 5. The reason behind my apprehension is that IE6 is still a major player in terms of market share and i don't want to lose it.
Is there any way of moving to HTML 5 and still promise multi browser compatibility?
Thank you.
Yes, by taking baby steps.
To start with, you can switch to the HTML5 doctype: <!DOCTYPE html>. This switches just about every browser out there into "standards" mode, the same as an HTML 4 strict doctype.
Then there's the new elements. Internet Explorer can't natively style them, but a handy little bit of javascript fixes that up: http://code.google.com/p/html5shiv/
If you or your tools aren't ready for that (e.g. some CMSs strip out HTML tags they don't understand), then in the interim you could use classes, e.g. instead of <article>, use <div class="article">.
As for the new form controls, they're backwards compatible too. So <input type="email"> will work exactly the same way as <input type="text"> in browsers that don't support it. If necessary you can use javascript to fill in the gaps. See http://diveintohtml5.ep.io/forms.html for more on that.
As for <video> and <audio>, you can fall back to <object> for older browsers - e.g. http://camendesign.com/code/video_for_everybody. Meanwhile <canvas> can be emulated in javascript, e.g. http://code.google.com/p/explorercanvas/.
"To HTML5" is a fairly broad statement. Even if you have the new HTML5 doctype set (the simple <!DOCTYPE html>) you don't have to go all out and use every aspect of HTML5, only what is appropriate to your project.
If you are keen to get on board with HTML5, I recommend reading "How to use HTML5 in your client work right now" for examples of how you can use certain aspects of HTML5 with few (if any) drawbacks.
Disclaimer: I am one of the curators of HTML5 Doctor.
From there it boils down to whether or not your project will benefit from the features of HTML5 and if you can afford to implement these features. For example, if all of your IE users also have JavaScript enabled you can use html5shiv to get IE to recognise the new elements, enabling you to use them and style them.
As for the new JS APIs and CSS properties that people often group with the term "HTML5", unless your site absolutely requires that you use the technology (perhaps something like geolocation), then it could simply be a matter of progressive enhancement. If webkit/firefox users get rounded corners from CSS3 and IE users don't, is that really such a big deal?
As a rule of thumb I would not develop a site purely in HTML 5 but would consider using it for certain, richer, parts of the site. Remember that it is still not recommended by W3C and IE barely supports it at all.
This blog has a good discussion on it: http://blogs.forrester.com/ronald_rogowski/10-05-10-what_should_customer_experience_professionals_do_about_html5
yes there are several ways.
but if you DONT need html5 elements like video tags, or html5 api's like browser databases, stay at XHTML,because it is still not recommended by W3C. There you can use simple fallbacks for ie6.
do you need html5 elements and apis?
As a last resort you could use Chrome Frame: http://code.google.com/chrome/chromeframe/
As for "a major player in terms of market share", that really depends on your audience. Even Microsoft is marketing its new IE versions rather aggressively. And I don't think there's shame in charging your IE 6 users an extra plugin installation fee. After all, their browser is 10 years old, which is about 100 Internet years, isn't it?