You say "hackery is required to attempt to imitate native mobile apps" and I agree with you. Can I ask why it is so important to copy the styling of native? That seems like a lot of effort for no good reason. Mobile web can be better than native if you let it, but forcing it to be something else purely for reasons of fashion is foolish.
HTML/CSS produces a flexible layout that is usable by many different sizes and types of devices (even audio interfaces) and that is a good thing. It takes effort to get it working for all of the possible ways it could be used, but it is possible. After a little practice, it can even get easy. The hard parts of HTML/CSS would still exist in any flexible layout solution. Making a rigid screen-painted layout solution avoids problem inherent in flexible layouts those, but it gives up so much.
Just googling for "vertical align text css" should be enough to tell you that different layout is needed. Why shouldn't there be a layout model that makes it easy to do the things people are trying to do?
The idea that we shouldn't even attempt to create a better one is silly.
.vertical-text { display: flex; flex-direction: column; justify-content: center; }
(add ´align-items: center´for horizontal center)
There you go. That CSS is useful for popup dialogs. Though most of the difficulties I see with vertical-alignment are due to poor design and implementation.
HTML and CSS get new features all the time so clearly nobody is saying they shouldn't improve. It's people saying that "HTML is inherently broken so there should be something else but they don't know what" that I am getting sick of.
If you want to align text vertically, you just do
font-size: 20px;
line-height: 40px;
vertical-align: middle;
That said, I'm all for experimenting.
I'm not saying that there aren't a lot of good ideas introduced by the web (documents, hyperlinks, semantic metadata, responsive layouts, accessibility, URIs, etc.). What I'm saying is that there are good parts and there are bad parts, just like with native. What we need is a marriage of the good parts of the web with the good parts of native.
We can do better. Much much much better.
"precursor of html"
HTML is based on XML, a language with two primitives, strings and children. Why would you ever use that as an interface if you want something to ever be performant?
What we need is a retain-mode scene graph, where some of the nodes on the scene graph can be HTML documents (with URIs).
Developers don't want a one-to-one relationship between the window object and documents. They instead want a one-to-many relationship. The <article> tag is proof of this.
Take Twitter for example. What is each tweet, but a 140-character document? The application for displaying an infinite list of tweets is not a document, but a multi-document viewer. The Facebook feed is the same thing.
If anything, this would prevent the shenanigans of blocking viewport resizing, because the user could choose an HTML document node on the scene graph and decide to make it full screen (the same way twitter allows you to click on a time stamp to get a permalink)
This retain-mode scene graph would need to support URIs so that you could always link to a subgraph of the scene graph and only view that part.
No, its not.
HTML is based on SGML (it was originally an SGML application profile, though as of HTML5 it is no longer.)
XML was invented after HMTL, was inspired by HTML, and is also an SGML application profile.
So, insofar as XML and HTML are related all, its closer to the reverse of the relationship you describe.
My point about strings and children still stand though. SGML is a document markup language. It was never designed for complex scene graph work, so I don't get how the OP I responded to came to the conclusion that HTML derived from anything that was originally used for things like applications and GUIs.
Finally, current native programming does not get its power from any advanced technique or technology but only due to its privileged position in an underpowered computing device with a smaller screens and newer touch input methods and hardware. This way, mobile GUI API designers didn't have most of the problems of large screen OS framework API designers had. When I look at their APIs, they are too simple, nothing fundamentally new.
So as mobile devices get better in general computing, a post html world may come back, with stringified description of UI elements.
Xerox Star User Interface http://www.youtube.com/watch?v=Cn4vC80Pv6Q http://www.youtube.com/watch?v=ODZBL80JPqw
Tektronix 4404 Smalltalk http://www.youtube.com/watch?v=8yxCJfayW-8
The Smalltalk-80 Programming System http://www.youtube.com/watch?v=JLPiMl8XUKU
The Final Demonstration of the Xerox 'Star' computer http://www.youtube.com/watch?v=_OwG_rQ_Hqw
Symbolics Hypertext Document http://www.youtube.com/watch?v=7DxYj32cvoE
Warren Teitelman work at Xerox PARC https://news.ycombinator.com/item?id=7579613
The Mesa/Cedar programming environment https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fbitsavers....
Steve Jobs internal demo of NeXTSTEP 3, http://www.youtube.com/watch?v=gveTy4EmNyk
Alan Kay on Xerox PARC work
http://www.youtube.com/watch?v=0oonXT-gYjU
its not fashion, it is UX, usability, and standardization
I really want a graphics system in the browser that can do the types of things being done here: https://news.ycombinator.com/item?id=7896773
i.e. Wayland for the Web with documents
If we jump on this now, maybe we won't be left in the dust when native makes the jump from 2D to 3D and interface devices like the Oculus Rift go mainstream. This is probably 5+ years away, but now is the time to start considering how these capabilities will be possible at the lowest levels. None of this precludes the entire 2D web we're familiar with since 2D is simply an elevation view of 3D. Baking 3D in from the start leaves room for people to explore the possibilities people are exploring on native instead of being hamstrung by naïve technological choices.
We're trying to explore what is possible here at famo.us [0]. Hopefully between what we're doing and what others are exploring, we'll come up with some interesting approaches that eventually made their way somehow to becoming a standard.
The w3c spends too much time trying to expose APIs for the jQuery level developers instead of seeing the web as an operating system and exposing operating system primitives from day one. All they need to do differently from how previous operating systems worked is consider how the semantic web, accessibility, and URIs fit into this computing model.
relevant: http://acko.net/blog/shadow-dom/
[0] http://famo.us/
Not sure what your getting at. The Wayland demo looks like it could be completely recreated with existing CSS3 3D transformations.
Here's a similar example in a browser using HTML and CSS3. These transforms can be used on anything you can fit in a DOM element: https://www.webkit.org/blog-files/3d-transforms/morphing-cub...
That guy went on to explore cuboids in addition to rectangles as a basic windowing primitive.
WebGL, as it stands, seems to lack a few useful primitives for such a task, most notably needing an equivalent to process separated iframes. That might be possible already, but if not I'm sure it will be cracked enormously faster than attempting to debate and implement tiny incremental improvements in the HTML spec.
My understanding is this is remarkably close to how the PS4 UI is actually implemented already.
The real pain points in the web of today speaking from a web developer perspective are CSS, JS and the DOM. It'd be nice to see the webkit browser makers get behind alternative style sheets, and alternative languages/APIs, because both CSS and the DOM have serious flaws and omissions which, while they are slowly being addressed, still cause a lot of pain.
It'd be great if language creators could write plugins or compilers to see their language of choice as a sandboxed language available on the web, and see those bundled with browsers, and it'd be great if browser developers took a serious look at alternatives to CSS for layout - something much simpler could work so much better, and maybe we need different styling languages for different purposes (for apps or for documents for example). HTML is pretty flexible and people could always define fallback CSS for browsers that didn't support the new stylesheet variants. There's no reason browsers can't support a few languages with improved DOMs and a few styling languages. Sadly, I suspect we'll just see browsers bumble along adding some modules on CSS and improvements to JS instead.
One of the big attractions for me about server-side development and HTML is that you can use whatever you like on the back end, as long as you feed the client HTML. It'd be lovely to see that sort of freedom to experiment extended to the front-end as well. If the web is to be an operating system, let it be an open one.
Really? Because I find it far more intuitive and flexible than working with xibs, for instance.
I really hope that we can sort out this mess some day.
I personally like apps are making the network more relevant than the Web. What matters are communication protocols.
And yet the web is a better platform for applications than anything else.
Zero installation, linkable states via URLs, universal back button support, accessibility hooks, multi-device, write-once-run-anywhere and an enormous variety of available programming languages.
All of that, AND it's built on top of truly open standards that aren't controlled by a single company and can't be killed by anyone (something VB6, Flash and BlackBerry developers should really appreciate).
Please lets not pretend the Web invented how to write portable code.
Browsers should be written to expose APIs needed by the same people that write native applications today, but do so using a more appropriate trust and sandboxing model than what operating systems do. The browsers should act as "user agents" advocating on behalf of the users while exposing as low level and powerful APIs as possible and then standardizing those ideas that are well baked.
edit: regarding low level primitives, this comment [0] in this thread by addyo (Addy Osmani) is relevant. This low-level work is crucial.
You have apps that the Internet. You also have the WWW. People developing apps can chose whether to also develop for the WWW. Hopefully this would stop people doing stupid horrible things on WWW (forcing fonts; preventing zoom; etc) because all that hateful stuff can be done in their app and doesn't belong on WWW.
If we're throwing away the cruft (which I fully support!), lets do things right. That means planning a (light) abstraction layer for a world where you can use the right tool for the job.
I'm actually starting to wonder if an approach like docker/lxc, but with web features ported to native land may not end up making more sense in the long term.
The idea would be to take all the features of the web that aren't document focused and make them available in userland in a linux container. For example, the linux container would have to ask for permission from the host operating system to get GPS access or Contacts API access. It would also support the ability to use URIs to manage the state of any chromeless "window" object.
It may be easier to take the web to sandboxed containers than bring all the operating systems concepts to the browsers. Basically this would be a LXC User Agent.
http://httplocal.com/ is working on local composition of web pipelines. Micro Xen (Bromium) forks a virtual machine with a fresh copy of the host operating system and browser for every URI.
What do you think of iOS8 extensions and Android intents? Or https://sandstorm.io ? The challenge is maintaining security and composition flexibility. Apple only opened up a few APIs.
http://en.wikipedia.org/wiki/Cassowary_(software) https://www.cs.washington.edu/research/constraints/web/ccss-...
If you haven't worked with web tools recently you should see how far they've come. With JS frameworks like Angular or Ember, and crazy fast build tools like Gulp, it's pretty nice developing for the web these days
> If you haven't worked with web tools recently you should
> see how far they've come.
Also, Flexbox makes this even easier, and is a great step forward.
Android uses Java, C and C++ for user space applications, hence native Android means all three languages using Android APIs.
You don't need to throw HTML and CSS out wholesale (it still has uses) and you don't need to implement an entire browser to get many of the features listed on that page (except maybe the audio stuff).
At famo.us [0], we're doing a lot of the things they say their final product will have but within the context of any modern web browser.
WebGL is great when what you're trying to do simply can't be done in a high-performance manner using standardized markup.
However, a generalist WebGL-powered UI framework would suffer the same drawbacks that Flash/Flex/Silverlight did: your content ceases being semantic. Of course, some sort of convoluted metadata system to preserve this could be devised, or simply run parallel to real markup that's not rendered, but those types of solutions are ugly at best.
In my opinion, if you're going so far as WebGL to achieve UI performance in a mobile context, you should probably just make a native mobile app instead. At the moment, WebGL support on mobile tends to be incomplete and suffers from poor performance on most devices anyways.
Mobile will always lag behind desktop in terms of browser performance and features, but browser optimization and mobile hardware is improving every day. Keep in mind that both desktop and mobile browsers already utilize GPU acceleration in some aspects of rendering normal content.
For all the talk of web apps as credible alternative to native ones, the fact is the current toolchain is unlikely to ever be good for anything more than paper-thin clients. Ecmascript 6 doesn't fix this, Ecmascript 7 won't fix it. HTML5 tags are a worthless collection of semantic sugar when we desperately need a solid component library instead of implementing everything from scratch.
I don't believe that interoperable and usable web apps are a mere pipe dream, on desktop or mobile; can you imagine a world in which the open web never took root, and we were all stuck on AOL, Compuserve, and Prodigy? That's the current app ecosystem in a nutshell, and it's deeply suboptimal for both users and developers.
Google would be better off throwing efforts into a new layout engine leveraging raw JS and WebGL, but with a sane API, than these continuous attempts to push HTML into places where it doesn't work. If they don't lead it I can see someone else doing it in such a way that their core money maker of web scraping and indexing ceases to work.