The Pixate Project: Bringing CSS to Native Apps
benzilla.galbraiths.org
benzilla.galbraiths.org
Personally I'm unenthused.
For one thing, the typical reason to write native apps these days is that it's a mobile app. Certainly on iOS you'd be better off staying on the reservation. There's only 2/3 resolutions to support anyway (plus two orientations for each). Android is of course more varied.
For desktop apps, you're getting increasingly specialized software (the rest going to Web apps) and your best bet is still to stick to the native libraries (Cocoa, WPF, etc).
[1]: http://weblogs.java.net/blog/enicholas/archive/2006/03/style...
Personally, I think the concept of declarative styling is brilliant but the implementation in CSS leaves a lot to be desired. It's far more error-prone than necessary.
CSS for layout on the other hand, I've always found to be a massive pain in the ass, full of counter-intuitive weird hacks. (For example: the 243342 approaches to centering elements relative to one another, often requiring hacky nested divs to ensure things work in IE.)
It's not entirely done but it's a good start for someone.
The video explains it more: http://www.ustream.tv/recorded/16073539/highlight/187549
This replaces the old `.gtkrc` system.
Those with recent Ubuntu desktops, try it out!
This might not be too suspicious except that no where do they address what happened in the first campaign and what has changed since. Why did they need $200,000 a month ago but now only need $25,000? What has changed?
As the Dragons Den catchphrase goes, "for that reason, I'm out"
[1] http://www.kickstarter.com/projects/2015210423/pixate-beauti...
[2] http://www.kickstarter.com/projects/pixate/beautiful-native-...
[3] http://thenextweb.com/insider/2012/08/26/is-pixate-astroturf...
Edit: added the links
Blossom lets you build native-quality web apps for mobile browsers without every touching the DOM or CSS -- it's 100% JavaScript.
(Full disclosure: I developed Blossom earlier this year.)
Edit: I realized I ran into something that does almost exactly what I wanted a couple weeks ago on github https://github.com/robertwijas/UISS
Qt has also QML, which gives developing "native" apps bit web feel.
I'd rather invent something new layout engine than using the lame CSS way. For example I want place an box A next the box B on its right at the distance of 50% of the height of the box C on the left.
"CSS3 is just a standard."
That's a very strange criticism. Would you prefer a proprietary black box to do your layout for you? "Do you have a full CSS3 implementation embeddable in programs"
Another strange one. You can embed webkit and gecko in a desktop app.On iOS the recommended way of getting formatted multi-line text is to use a UIWebView (webkit)
"I'd rather invent something new layout engine than using the lame CSS way"
I'm guessing you've never actually written a layout engine before. They're notoriously hard to get right. "For example I want place an box A next the box B
on its right at the distance of
50% of the height of the box C on the left"
You could either use a pre-processor (such as LESS) for the placement of Box A, or if its position is a dynamic property then you can set it using JS.How many times have you look into webkit or gecko source code to fix layout problems?
If you think a layout engine is complex enough that need to be open sourced, you are doing it wrong.
Layouts should be simple and intuitive. Not a cluster fuck of div's and hacks.
> You can embed webkit and gecko in a desktop app.
Which is basically an html5 app right?
> I'm guessing you've never actually written a layout engine before. They're notoriously hard to get right.
Yes I have never written anything like that, but I can tell you native app development (Visual Studio, XCode) layouts are much simpler and more powerful. The problem with HTML and CSS is that they are eigher document flow based or absolute position. It's hard to do relative or responsive layouts right. It's easier to do it right in native ways. There are much richer containers, control groups and docking options.
> a pre-processor (such as LESS) for the placement of Box A, or if its position is a dynamic property then you can set it using JS.
Oh wow, Javascript for layout, right.
How many times have you look into webkit or gecko
source code to fix layout problems?
That's not really the point. Let's use the Adobe Flex Framework as an example. If you bought into Flex 5 years ago then you're probably starting to feel a bit nervous. The reasons being: 1. Adobe are themselves signaling that
HTML is the future by releasing HTML5 tools (Edge)
2. Adobe have abandoned mobile Flash development
3. Developer mind-share is firmly in the HTML camp.
Now, if the full adobe/flash stack were open source and there were multiple companies working on it, it would be less of an issue as the technology you invested into would continue to be supported. The fact that you, personally are not working on the flash/flex core would be irrelevant, as is the case with HTML5 and the open web. If you think a layout engine is complex enough that
need to be open sourced, you are doing it wrong.
I'm at a loss trying to respond to this. If you think writing a layout engine from scratch is easy then you simply don't understand the problem very well. Even writing a good text layout engine is very hard to get right, and text layout is only a subset of the whole problem. Not only that, but layout is an orthogonal problem to the one you're trying to solve (unless you're writing a browser or word processor), so the time you sink into it is wasted. native app development (Visual Studio, XCode) layouts are much
simpler and more powerful
It's simpler because the complexity is abstracted away from you by the IDE/tools. The actual (hidden) application logic driving the layouts is just as complex if not more so. The problem with HTML and CSS is that they are either
document flow based or absolute position.
Absolutely agree with you here. The document paradigm has been abused horribly to allow for complex layout on the web, and its roots are painfully evident - it certainly wasn't meant for this type of work. It's easier to do it right in native ways. There are much richer containers,
control groups and docking options.
Agree here too. Having said that though there are great advances being made, the flexible box model being one of them. Oh wow, Javascript for layout, right.
That's sarcasm not a rebuttal :)Going back to the original point, I think that CSS for native layout may be an OK idea, CSS certainly has it share of strengths and weaknesses. One thing this approach has in its favor is a low barrier to entry for web developers which may help bridge the designer/developer divide.
It's been fun sparring with you :)
all the best, eli
I am not exaggerating, that is 99% the reason for his desire to abandon ship. He complains about CSS daily despite being one of the more knowledgeable people I know about CSS, save for the rare occasion he asks me a question.
Why should I react to this project by doing anything other than lighting a molotov cocktail?
I assume that you are correct in your implication that Core Graphics and Core Animation are overly complex.
However, that does not mean that the answer is CSS.
You should not need to hand-write code to lay out text on the screen or change a background color.
There is a reason that UI builders have been a standard part of desktop development frameworks/environments for many, many years.
CSS is the worst thing that ever happened to front end application development.
[1] If you look at the browser-based Javascript implementation of CoreGraphics (http://cappuccino.org/learn/documentation/group__coregraphic...), many of the CG functions are just straight-up bridges to the local functions.
If the CSS syntax is used as a way of declaratively describing styles in a single controlled environment (iOS) then that's not the same thing, and I would think that it should address a lot of the headaches that browser-based CSS currently has?
Plus it would (hopefully) allow the use of existing tools like LESS or SASS to provide even more control and re-use in creating the resources that go into building your iOS app.
1) Why in the hell would anyone want more CSS floating around their codespace? Note: This is partially addressed in "Doesn’t CSS Suck for Apps?"
2) If this becomes a thing, does that mean that everyone involved in the actual drafting of the CSS spec will finally get their shit together and treat it the way it deserves? Note: You too, browser vendors.
3) Does this mean native app developers can finally pay me for more than paper storyboards? Because then...
I studied iOS development for a few months, read a 600 page book on it, and tinkered around with it for a while and found myself begging for CSS. Native custom app interfaces seem backwards to me - the difficult of writing core graphics methods for every bevel, rounded corner, gradient etc has a lot of developers just using cut images for everything. Disclaimer, I'm way way more experienced with css than i am with core graphics - just my impressions.
But where CSS really falls apart is in layouts. What is just a simple equation in a native application ends up being a myriad of hacks to get things flowing right in CSS. Javascript comes with the missing pieces, but introduces its own set of problems if you try to rely on it.
> the difficult of writing core graphics methods for every bevel, rounded corner, gradient etc has a lot of developers just using cut images for everything.
On iOS, the QuartzCore framework provides declarative methods for those common style choices (rounded corners, gradients, etc.).
Not only that but it's usable today. Both webkit and gecko have very close implementations with only minor edge cases, none of which are insurmountable.
Not sure about iOS support for the new layout modes.
Browsers, in fact, already use the shadow DOM to render many of their custom forms. It's just not available programmatically yet.
Layouts aren't completely horrifying if you use a good, responsive grid, although within that grid framework itself there are likely some hacks. But as mentioned -- new CSS layout types are coming!
Really?
CSS is fine until you want to build something specific. The amount of hacks required for even the simplest thing is amazing.
Want that UL to have it's LIs in a grid? Use float. Float was supposed to make text wrap around images, but we use it for the side effect of making block elements behave like inline. It also messes up the height of the UL, since it doesn't really contain any text to be wrapped around. You can fix it most of the time, but it's a hassle, and prone to break.
Want a UL to be on one line and centered? There's a hack for that! And it's completely unintuitive black magic.
Even the simple things like lining up elements with a fixed margin between each other and to the containing element was a great hassle up until just recently when we could finally begin relying on CSS 3 features.
It's a big stupid mess with missing features and features misused.
The basic idea was OK, with the selectors and rules. The execution as was 10 years ago, and to a large degree still is, was horrible.