I'm building an application, which is cross-platform (Linux, Win, OS X), and especially does graphics stuff via Cairo(mm), supported by a little bit of GTK+ scaffolding (i.e. DrawingArea). I now need some UI elements, which require a certain custom look. Ideally they should also be displayed as transparent overlay (i.e. different opacities for different parts of the UI).
As GTK+ is hard to customize (e.g. I want an edit-field with the suggestion-list above it), and me basically exactly knowing how I'd achieve this with HTML/CSS, the question popped up: Why not just let libwebkit handle the UI stuff?
I don't have much experience with WebKit, so what I need to know is:
Does my above reasoning make sense to anybody else?
CSS has opacity, can I interface WebKit in such way that it renders onto an RGBA-offscreen surface, with alpha-values inherited from the layout-processing of the CSS styles?
Even if 2. would not work, has anybody used libwebkit on an offscreen surface, which AFAIK requires redirection of keyboard and mouse interactions, probably via GTK+s provisions?
Is it possible to render web content over a clear background using WebKit?
is probably as good as it gets.
Related
Famo.us claims that it "talks directly to the GPU" to compute themselfs the css transforms. I assume they are talking about the 4x4 transform matrix.
When they say the "talk to the GPU" it means they are doing their maths in WebGL?
When they show 3D elements are they using WebGL in a canvas element?
Is their technology real THAT special or their claims are the result of an excellent marketing campaign?
Disclaimer: I do not work for Famo.us, I just share their vision in way software should be built.
The answer to all three questions is no. When they say talks to the GPU, they are not referring to the matrix calculations, they are referring to the matrix3d property of CSS that is GPU accelerated by the browser. By throwing out the box model of normal HTML and CSS, we can create a new model that follows the likes of traditional graphics development, which is based on a Cartesian coordinate system and all elements are absolutely positioned with 3d transforms.
There is no WebGL and no write to canvas. Every one of the (surface) elements on screen is just a div that is transformed. Every bit of text will still be highlightable and every button will still be clickable. It's all live. The rendering starts at the Context, which in most cases is the top level of the render tree. Nodes for other subviews are added as children. On each render cycle the context's render function is called, which in return looks down the tree and calls the render function of each subview recursively. Since the render engine is tightly integrated with requestAnimationFrame, all calculations can be determined then rendered at the time of screen refresh.
The technology can be considered special, because it throws away so many traditional paradigms in favor of a more modern approach to building web applications. That being said, it's really only Javascript. HTML was not built for web applications. HTML and CSS were built for static content pages and work as a crutch in trying to achieve applications similar to the ones we love and adore on mobile. Famo.us makes it possible to build applications with only JS, or a compile-to-JS language like CoffeeScript. You define Surfaces which correspond to divs on screen, and you apply properties for HTML attributes and CSS. You still have the option to apply CSS classes or inject HTML into surfaces.
In the end the choice is up to you. If you do not see the value, or are comfortable with the way you build web applications, then stick with it. Over the next few months you will see many more demos popping up as real users like myself create them. I can tell you already, it's amazingly promising.
Cheers
I want to add a slightly updated answer:
(I, too, don't work for Famo.us, but I did spend three weeks there working on projects)
While #johntraver has summed up pretty nicely what Famo.us does at the moment, it is important to understand that famo.us WILL support canvas and webGL.
Going deeper into the philosophy of famo.us, it throws away all the tools that HTML and CSS provide for layout and animation. ALL surfaces in famo.us are absolutely positioned at top:0, left:0 and EVERYTHING else is done purely with transforms, that are calculated by famous.
Animations are also done in javascript and don't use CSS transitions or Animations.
The more you think about it, Famo.us has almost no dependency on HTML or CSS, and that is exactly the plan. Famo.us treats HTML as just one of many possible renderers.
They are now working on adding WebGL rendering to famo.us. Essentially, what this will enable is a common API for layout and animation that will be able to render to WebGL AND HTML for the best of both worlds.
So, calculations will still be done in Javascript entirely, but the output may either be surfaces with transforms OR WebGL.
Hope that helps.
I'm trying to create a game that uses buttons (and text areas) that are semi-transparent (Alpha of about 60%). I can do almost everything I want in XHTML and CSS, except for these semi-transparent items. So I'm looking for the easiest way of creating semi-transparent images on my web pages.
Ideas so far:
Create PNGs with semi-transparent pixels. This is supposed to be possible, and there are well-defined interfaces for defining an Alpha channel using PHP and the GD package. Problem: I tried this, but the images were opaque in all the browsers I tried (Chrome, IE8, FF).
Do it in Flash. I know how to use Flash(*) from some work I did before I retired. Problem: Flash is priced for the professional developer, not the hobbyist.
(*) Well, Flash 8. But as I understand it, even with newer versions I can continue to create movie clips the old way, they just get translated into a bunch of AS. And it's supposedly possible to continue using AS2, although you can't mix AS2 and AS3.
Do it in Flex. Problem: interfaces best described as arcane. Even using suggestions from experienced Flex developers, trying to include code from another mxml file (other than as a class) was a PITA.
Use SVG. This looked promising. The SVG syntax is basically XML, the element tags are reasonably obvious, and the interaction of attributes only slightly arcane, and there are plenty of examples in the tutorial. But... about half of current browsers will not support using SVG in an <img> tag. You have to use <embed> That means you can't put it inside an <a> or <button>. Even using embed, I got what look like "broken image" icons in IE8.
As I'm writing this, I notice several items under "similar questions" that look promising. But when I look at them, they use attributes that are not mentioned in the CSS spec: opacity, filter:alpha, and rgba. When working in a complex language, I really prefer to have the complete language spec open in another window, or to have the equivalent dead-trees version (e.g., the O'Reilly salmon book Cascading Style Sheets, The Definitive Guide, which sits on a bookshelf next to my desk.
So I'm asking for recommendations. If the consensus is to use SVG, I'll post my code and see if people can tell me what I'm doing wrong.
The CSS "opacity" property is perfectly valid. It is part of CSS3, and is supported in all browsers (*).
http://caniuse.com/css-opacity
Or you can use semi-transparent PNGs, as Alvaro demonstrated. They should work just fine. Not sure what happened with your attempts, but you must have done something wrong.
Note for versions of IE <= 8, you need to use the "filter" property instead.
https://developer.mozilla.org/en-US/docs/Web/CSS/opacity
I don't know what problem you have with PNG's. Imo the best and easiest option by far. And they look as they should in all browsers from my own experience.
check this out: http://jsfiddle.net/BDLYG/
(and here a code I need to add)
If you have most users with the 'modern' browsers, I would say go with SVG. If you do, post here, and I'll be glad to help.
Many thanks for all the useful answers. I'm currently using a combination of CSS and PNGs (generated via PHP). I could have gotten along with just CSS, but I decided I wanted to change the opacity of the background when the user hovers over the button -- but keep the text opaque. It's easy to change the opacity of the whole thing, but (as far as I can tell) not of just the background.
I also experimented with SVG, and it also works fine, but it requires extra computation so I chose the simpler (for me) approach of CSS and PHP. I'm already comfortable with those two languages, just needed to be introduced to the newer stuff in CSS3 and the one extra function call needed to make alpha work in PNGs generated by the PHP GD package.
I'm looking for a good way to implement reusable buttons in CSS on my forms. The requirements:
- Separate image and text (text is in many languages)
- Rollover effects
- Plays nicely cross browser
- No javascript (if possible)
- Rounded corners
Whats the best way to do this? Years ago I was using the sliding doors technique, but this seems out of date now. Would you use CSS3 with a fallback for older browsers? Any particularly well thought of techniques out there?
Jquery UI buttons are AWESOME. They're fully tested, completely compliant, and really look great. With one line of code, you can have a fully styled button in no time flat. Here's the thing--they can be executed without Jquery (go figure)
First, the tut
So, the standard method is to build an element (a, button, input) with an id and set it as a button in Jquery like this:$('#element').button()
However, if you do it in the manner that the tutorial shows, you just have to add some classes to an element to get a similar effect. So, to make a button out of an a tag, it would just be
Button
In this example, there's no need to set the button with the jQuery button declaration...you're doing it by style only. With the flexibility to style so many different type of elements, it opens up a ton of doors.
You would have to have the Jquery UI css loaded, which offers the added benefit of ThemeRoller, which can style elements on the page with a simple change of a file. It's really a great way to "theme" a site that has to change branding in a hurry, which has made custom themed apps my company puts out extremely profitable.
I would use css sprites for this. You can find out about them here:
http://css-tricks.com/css-sprites/
It is basically a way to make one large image that has all states of buttons(normal, hover, selected). The benefit is it is one http request and you don't see a flicker the first time a hover occurs. If you use this route, the css background property will be the image. You can then use text-align and line-height to center the text that you want to place over the image.
This library, Nifty Corners Cubed uses Javascript but is a fairly clean way to round div tags links, etc. It is tough to find a reusable solution without using a sliding doors derived technique. Otherwise you stuck making none-resuable buttons that have to fit to your size.
You can also take a look at PIE http://css3pie.com/
A sprite is a great option and I do use them from time to time.
Personally I don't mind if my websites aren't identical in all browsers and I go the CSS class route. I keep in mind what is and isn't supported by various browsers and if there is an element that needs to be a certain way I will double check with W3Schools for compatibility.
The main benefit the keeps me using CSS/CSS3 classes is if something changes it is done quickly by text in a single file, if need be I can do a quick change from a 10 year old computer with a dial-up connection (if they still exist) and no imaging software.
Where the advantage of a sprite is they are supported across all browsers and they will look identical (more or less). SpriteMe is a bookmarklet that I have heard of to help with sprites if you decide to go down this path.
I see this as a what do you prefer matter... these questions are what I ask myself when making this type of decision:
How often will it change? Big or small changes? Will it be a complete redesign job if it changes? What do you already know? How much time are you willing to spend learning something that you may not know? What does your gut say for this project?
I hope this can help you.
I've been reading a lot of ways recently of how to avoid having to use Photoshop for things like gradients and shadows on buttons, when you can use CSS3 Box Shadow for such features. Now this is great, but obviously legacy browsers and most IE browsers don't yet implement CSS3 features, so my question is, why save yourself extra work in Photoshop when you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects? Isn't that just extra work?
you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects?
Often you don't really care whether the other browsers see the desired effects. If it's just a subtle background gradient effect, the site's going to work fine and still look reasonable with a flat background in downlevel browsers.
Compatibility was more of a problem when CSS 2 Positioning was at this stage: an unsupported positioning feature could lead to an unusable layout. But for essentially frivolous effects like backgrounds, borders and shadows, it's not critical if the effect goes missing.
There are a few reasons. From a developer/designers perspective, using CSS3 can be more flexible. An image is more or less just a static image. With CSS you can use script or CSS to animate or adjust the styling, and have advanced integration between the various technologies. This allows you to be able to do some things that are not possible or difficult just using images.
The page weight is also lower usually when using CSS, which allows the page to load faster, especially on slow connections or mobile devices. It also reduces HTTP requests (although you can use data uris too) which reduces latency and thus speeds up page loading.
Using CSS is often more maintainable and quicker, as you can adjust say a background colour or a shadow quickly just by changing the CSS, while with images you have to open up photoshop, edit the file, resave, etc. This is fantastic for quick tweaks.
There are also some people (myself included) that are much more comfortable in code than they are using graphics packages. For me it is easier to use CSS, but your milage may vary.
Also from the browser perspective we want to move the web platform forward and increase the capabilities. SVG is an example of another technology that doesn't work across all browser versions yet, but adds a lot of power. Although it may not be possible to deploy sites using certain CSS3 properties or SVG without fallbacks right now (depending on your audience or client) there will be a time in the future when old browsers are dead and what we are adding today works for all users. There was a time when most of CSS2.1 wasn't supported for example, while now you can rely on most of it if you don't need to design for IE6.
There are some parts of CSS3 that you can happily use without fallbacks, if you have a client that doesn't require all browsers to look the same. border-radius is an example, or giving a solid colour fallback to old browsers and applying transparency for newer browsers.
The world is moving forward, you can't ignore it. as long as old browser will show a button and new browser will show a more nice one, you are ok.
Otherwise, we were still be working on VT100... as why using "Windows" if most monitors doesn't support more than 4 color graphics and has 80X22 resolution....
If your bosses accepts the idea of having two versions of looks and feel and a warning. CSS3 is a good idea.
So, you use CSS3 features in your code and forget about the browsers that are not compatible -- they will see the "low-graphics version", you might want to issue a non-intrusive warning (like the one we get as alerts in StackOverflow), saying, "Your browser is not compatible with CSS3. To see this website in high graphics please upgrade your browser. Click the link here to update now."
But, depends on where you work. Big companies with lot of resources may like to stick with Photoshop and smaller once may like a light-weight CSS3 code that degrades silently in non-compatible browser.
Well you can always use ChromeFrame, to impose nice behavior on IE. Assuming that a lot of products will insist for it the near future (yeah we can argue against this), chances are that most IE users will have chromeFrame even before your application would insist for it. Once you take a decision on this, decision on using CSS3 properties or HTML5 elements is - well - hell yeah!!
Marvin
I’ve been stuck in the process of constructing a framework for a window to hold my web apps. With the help of JavaScript, the window will change its color, size, and position on the page. It is so much like GUI apps in Windows OS.
Borders must be custom, that is, they will change their color for that of the window, but will be shadowed a bit with opacity of about 50%.
The head must have the same color as the window do, but will have an image with some alpha channel value as a background. (That will polish up the head of the window.)
My problem consists in that my CSS for this challenge is sort of hard to manage via JS (dynamic part of the app). So, I am here to ask some help from CSS experts. If you know how to make CSS a snap, your help will be very much appreciated. As for now, I am frustrated to find no way to write a clean and simple code.
P.S. I am willing to support Internet Explorer 6, too.
Edited: Please, have a look at the visual representation of the problem: http://savepic.org/261861.jpg How would you manage to code CSS for that window so that it's easy enough to change the size and color of the window with the help of JavaScript?
How would you manage to code CSS for that window so that it's easy enough to change the size and color of the window with the help of JavaScript?
That "transparent borders" thing you mention is not entirely trivial, but definitely solvable. Now I'm still not entirely sure in what direction you are looking for help - how to structure CSS vs. JavaScript, or how to solve the specific problems you mention?
Either way, have you already looked at JQuery Dialog? It's a bit much for that single problem (having a window and resizing it) but it brings a full-blown API and templating system that has solved many cross-browser problems already.
If you don't want to utilize a framework, I would say don't worry too much about JavaScript accessibility. In essence, when you build clean CSS, you can access it well from JavaScript. A few thoughts on good CSS are in this question.