10 ms·

This is the same complaining I always hear from people who don't want to learn how to use HTML and CSS. Yes, it is different than what you are used to. Yes, it

This is the same complaining I always hear from people who don't want to learn how to use HTML and CSS. Yes, it is different than what you are used to. Yes, it will take some time to learn and some of that will be uncomfortable. But that does not mean that that HTML and CSS are bad. I know this because I successfully build mobile sites that look and function fine and I assure you it works. 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.

malandrew 12y ago
If you're not using HTML/CSS for documents then yes it is bad. It's fundamentally the wrong abstraction. I began my career with HTML and CSS and after seeing alternatives, there is no doubt in my mind that trying to build apps on HTML/CSS is fundamentally wrong. 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.
- diminish 12y ago
  most of the development frameworks called native, are built on the precursor of html, namely 90s and earlier native app apis, on guis, and they arents perfect abstractions for apps neither. Current native zeitgeist gets its allure mostly from being closer to hardware and is the assembly to C. Otherwise all major mobile GUI APIs are naive attempts by busy developers to imitate, layouts, stylesheets,....
  - malandrew 12y ago
    "precursor of html" please elaborate. 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.
    - dragonwriter 12y ago
      > HTML is based on XML 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.
      - malandrew 12y ago
        Thanks for the history lesson. 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.
    - diminish 12y ago
      What I meant, was initially people were pixel-painting fixed screens and 2D/3D graphic programming evolved as one branch, and GUI app frameworks evolved as another (MacApp anyone?). If you look at earlier Mac/Windows/X app frameworks and iOS/Android app frameworks, you'll see that the latter is a more naive and easy solution to the same problem without the burden of multiple docs, windows and massive multitasking. I'm talking about windows, views, user interface controls, dialogs, textboxes, styling and finally inputs (events). HTML/CSS/JS is a string based natural solution to the same problem. 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.
dminor 12y ago
> After a little practice, it can even get easy. 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.
- skybrian 12y ago
  The question is whether you start over or make incremental improvements. Supporting a new layout doesn't seem like the kind of change that's worth starting over for. That said, I'm all for experimenting.
- just2n 12y ago
  We already have one. http://jsfiddle.net/gJP9k/ http://jsfiddle.net/gJP9k/
  - tothepixel 12y ago
    Except in IE.
    - magicalist 12y ago
      Flexbox is in IE11, and a slightly older version of the spec is in IE10 (with a "ms" prefix).
- protonfish 12y ago
  #vertalign {height: 50%; position: absolute; top: 25%; } 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.
  - joesb 12y ago
BorisMelnik 12y ago
>but forcing it to be something else purely for reasons of fashion is foolish. its not fashion, it is UX, usability, and standardization

malandrew 12y ago

If you're not using HTML/CSS for documents then yes it is bad. It's fundamentally the wrong abstraction. I began my career with HTML and CSS and after seeing alternatives, there is no doubt in my mind that trying to build apps on HTML/CSS is fundamentally wrong. 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.

diminish 12y ago
most of the development frameworks called native, are built on the precursor of html, namely 90s and earlier native app apis, on guis, and they arents perfect abstractions for apps neither. Current native zeitgeist gets its allure mostly from being closer to hardware and is the assembly to C. Otherwise all major mobile GUI APIs are naive attempts by busy developers to imitate, layouts, stylesheets,....
- malandrew 12y ago
  "precursor of html" please elaborate. 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.
  - dragonwriter 12y ago
    > HTML is based on XML 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.
    - malandrew 12y ago
      Thanks for the history lesson. 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.
  - diminish 12y ago
    What I meant, was initially people were pixel-painting fixed screens and 2D/3D graphic programming evolved as one branch, and GUI app frameworks evolved as another (MacApp anyone?). If you look at earlier Mac/Windows/X app frameworks and iOS/Android app frameworks, you'll see that the latter is a more naive and easy solution to the same problem without the burden of multiple docs, windows and massive multitasking. I'm talking about windows, views, user interface controls, dialogs, textboxes, styling and finally inputs (events). HTML/CSS/JS is a string based natural solution to the same problem. 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.

dminor 12y ago

> After a little practice, it can even get easy. 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.

skybrian 12y ago
The question is whether you start over or make incremental improvements. Supporting a new layout doesn't seem like the kind of change that's worth starting over for. That said, I'm all for experimenting.
just2n 12y ago
We already have one. http://jsfiddle.net/gJP9k/ http://jsfiddle.net/gJP9k/
- tothepixel 12y ago
  Except in IE.
  - magicalist 12y ago
    Flexbox is in IE11, and a slightly older version of the spec is in IE10 (with a "ms" prefix).
protonfish 12y ago
#vertalign {height: 50%; position: absolute; top: 25%; } 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.
- joesb 12y ago

BorisMelnik 12y ago

>but forcing it to be something else purely for reasons of fashion is foolish. its not fashion, it is UX, usability, and standardization