I am developing a portlet for Liferay (v6.0.5, runs on JBoss). I would like to use HTML5 (canvas to be more specific) in this portlet. How can I find, if the theme I am currently using on the portal does support HTML5?
I know that themes with HTML5 support exist and I have to choose the right one? Or am I wrong and all themes automatically support HTML5?
Thanks for tips!
All the Liferay themes automatically support html5, its the browsers you should be worried about.
There is nothing special to make a theme HTML5 since its just a matter of doctype change (<!DOCTYPE html>) to make the browser know that you are rendering HTML5 stuff. So you can check the doctype in portal-normal.vm and other template files to see if the theme is HTML5.
But for scripting support I doubt if alloy-ui (Liferay's default library) provides any additional HTML5 specific modules for manipulating canvas, file-api etc.
Related
As I'm a bit out of tune with web programming I tried to look up what is currently being used in order to display static video files on a web page.
After google showed me either the video tag for PC or some programs for android,... I'm wondering what are really now the current methods to display such videos? Is it JUST the video tag nowadays? Or are there also other methods that are "modern"?
The latest versions of the most popular browsers already support the video tag, so it should be as modern as you expect. The problem here is rather the video format. Each browser supports different formats for different types of operating systems, so this is one thing you should pay attention for. This website should give you a quick view of the current situation.
One more thing I can point you to is the support for older browsers. You should check if user's browser support the video tag and your video's encoding. In case it doesn't -- simply add a fallback to some older technology, such as flash or something else.
I have these webapplications build in old style HTML, including [framesets] to speed up the GUI of the administration.
Its not accessable by SEO etc. so thats not the issue here, it was all based on speed and minimizing reload at the time.
Now we would like to transform these applications and have begun to investigate HTML5 for the purpose.
Ofcause there is AJAX and db-storage etc. to speed up the interface with the new standards, but our question is really:
is IFRAMES and FRAMESETS going to be removed from the HTML5 standard or will it be "allowed" but "less appriciated" ?
Does anyone know whats going to happend?
The frameset and frame elements are obsolete in HTML5.
See http://www.w3.org/TR/html5/obsolete.html#non-conforming-features
The iframe element is valid.
Note that HTML5 still requires browsers to support frames and framesets as per Oded's link, but they are not valid for authors to use on web pages.
Yes, framesets will work, they are part of the current HTML5 spec.
So is iFrame.
As for your question on will they be deprecated or removed all together?
Frames and framesets should not be used in HTML5 as they have been obsoleted.
Since Flash is losing ground I would like to know if there are ways to protect html5 videos with DRM (H264, .ogg and WebM).
On the W3C FAQ on HTML5 it states:
Is there support for digital rights management (DRM) in HTML5 video?
HTML5 doesn't provide direct support, nor any barrier, to using DRM in video. It currently expects this to be handled by the particular codec/implementation. There are implementations which allow for DRM in HTML5 video.
Is dealing with DRM in scope for HTML5?
If enough stakeholders want to standardise some aspect of handling DRM in HTML5 itself as part of the inclusion of video and audio media, then it makes sense for W3C to help standardise an approach which meets the needs of the market. However like all W3C work, relevant stakeholders need to be and show they are committed to developing it rather than expecting it to happen on its own.
Which means it's currently not supported, but there has been a discussion about it on the W3C bug tracker here.
Update:
People interested in this subject might want to consult the working draft of the new encrypted media extension standard.
Updated: EME is currently supported in major browsers.
It does now.
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Here is an example.
http://www.html5rocks.com/en/tutorials/eme/basics/
This is the best page that I could find on current browser support.
http://www.jwplayer.com/html5/mediasource/
At the time of writing this, EME is supported in
IE11 in Win8.1
Chrome (Desktop and mobile)
Safari 8 in OSX Yosemite
Probably not, even though there's an EME DRM plug-in interface.
Some browsers now support another type of a plug-in called EME (Encrypted Media Extension CDM) for vendor-specific DRM implementations such as Microsoft PlayReady, Google WideVine, Apple FairPlay, etc.
However, the only part of it that is a public standard is a JS API that launches a vendor-specific EME plug-in.
The actual DRM API required to make use of it is vendor-specific, secret and proprietary. To have working DRM across browsers you will have to sign separate contracts with Adobe, Microsoft, Google and Apple (which may be difficult if you're not Netflix).
Consider abandoning idea of DRM, as it's more likely to backfire than protect the content.
This is an updated answer, comments don't make sense any more
Already in chrome.
Here is a running example using it.
Widewine provides video DRM for HTML5 and h.264. Recently, another company Haihaisoft said they released HTML5 DRM for MP4 and WebM video: . It doesn't need Flash anymore. You might try it online. HTML5 Demo in Xvast browser DRM-X 4.0 in the news
You could implement some kind of encryption scheme with public/private key - I recently heard about http://www.widevine.com/ who seem to be doing something like that for html5 and h.264 . But I am not aware of anyone having applied to web video in general.
Sure you can stop someone from downloading the file simply by not giving them permission to download anything from certain folders on your server. Maybe there is something I am missing here. Seems like that would be a relatively easy solution.
I want to get ready for HTML 5 and start playing around with it. Do I need to install it or something before using it? How does it work? I'm currently on shared hosting.
HTML5 isn't a server-side technology. All you need to get started is a browser that supports HTML5.
See these pages for HTML5 support in different layout engines:
http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)
You don't "install" HTML5 - did you install XHTML 1.1, or HTML 4.x? (no is the answer I'm looking for). Certain browsers support HTML 5 and some don't.
HTML 5 Browser Support/Engines: Comparison of layout engines (HTML5)
HTML 5 Working Draft:HTML 5 Working Draft
You don't need to install anything. Just a texteditor and a webserver is enough. You only need to hope that the webpage visitors uses a webbrowser which supports HTML5 fully. Right now, there aren't many of them out.
It is the fifth revision of the HTML standard. HTML5 is also a potential candidate for cross-platform mobile applications.On 18 January 2011, the W3C introduced a logo to represent the use of or interest in HTML5.
<!DOCTYPE html> is the doctype of HTML 5, add it on the top of your document.
Even if you didn't add the doctype, HTML 5 tags still work (if supported).
No.
Like all HTML it has nothing to do with hosting (unlike PHP etc).
Just create your own page with HTML5 elements and upload it to your hosting. Then you can view the page in you browser, if the browser supports HTML5 of course.
In a web-based system I maintain at work that recently went live, it makes an Object element to embed a second web page within the main web page. (Effectively the main web page contains the menu and header, and the main application pages are in the object)
For example
<object id="contentarea" standby="loading data, please wait..."
title="loading data, please wait..." width="100%" height="53%"
type="text/html" data="MainPage.aspx"></object>
Older versions of this application use an IFRAME to do this though. I have found that by using the object tag the embedded web page behaves differently to when it was previously hosted in an IFRAME. In IE, for example, the tool tips don't seen to work (I will post a separate question about this!), and it looks like the embedded page cannot access the parent page in script, although it can if it was an IFRAME.
I am told the reason for favouring the object tag over the IFRAME is that the IFRAME is being deprecated and so cannot be relied on for future versions of browsers. Is this true though? Is it preferable to use the Object tag over the Iframe to embed web pages? Or is it likely that the IFRAME will be well-supported into the future (long after I am old and grey, and past the useful life of the application I maintain)?
The IFRAME element is part of the upcoming HTML5 standard. Also, HTML5 is developed by the major browser vendors out there (Mozilla, Opera, Safari, IE), that basically makes a guarantee that we will have an IFRAME element in the foreseeable future. Some of them have support for some HTML5 elements already, like AUDIO and VIDEO and some new JavaScript APIs.
It's also true that the OBJECT element is in the draft, but that's because IFRAME and OBJECT will have different purposes. IFRAMES are mainly designed for sandboxing web applications.
So, my advise is to use IFRAME instead of OBJECT.
If you are embedding a HTML page, here is one noticeable difference between iframe and object:
with iframe updating src will change the browser history (adding a new entry)
with object updating data will not change the browser history
Also it seems like drag&drop does not work if the page is embedded in the object tag, but works in the iframe tag. I noticed it personally using react-draggable, and I can see someone had the same issue (https://stackoverflow.com/questions/31807848/replacing-iframe-with-object-tag-drag-and-drop-not-working)
IFRAMEs are not part of the XHTML 1.0 Strict DTD. They are totally valid in in HTML 4 and XHTML 1.0 Transitional, I believe. For these reasons alone, IFRAME will continue to be supported for a long time.
A lot of bookmarklets and analytics code still use IFRAMEs.
Although the W3C specs may indicate that the IFRAME tag is being deprecated, (in XHTML at least anyway), browser developers do not necessarily follow exactly what those specs say (IE6 anyone?)
As use of IFRAMEs is so prevalent at the moment, and the W3C can't seem to decide if they are part of the future or not (HTML 4.01 vs XHTML), I am pretty sure they are the safer implementation to use for almost every browser.