5 ms·

> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differentl

> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differently. Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.

hansvm 6y ago
Or in this day and age to even choose that a byte has 8 bits.
lkrubner 6y ago
Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.
- hombre_fatal 6y ago
  What are the obvious benefits? My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
  - lkrubner 6y ago
    This is my argument: "My experience is that people who tend to disparage web tech don't have much experience building clients in general" My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript. This is an old debate, but to repeat the highlights: The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends. The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together. The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here: http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html Earlier, in 2016, I wrote about the general problem, which offers some historical context "HTML is the failed GUI for TCP/IP" : http://www.smashcompany.com/technology/html-is-the-failed-gui-for-tcpip http://www.smashcompany.com/technology/html-is-the-failed-gu...
    - Mikhail_Edoshin 6y ago
      I fail to understand the argument. What's specifically wrong with a "markup language" that makes it unfit for GUI?
      - lkrubner 6y ago
        HyperCard, Dreamweaver, InDesign, Photoshop, Flash and Illustrator do not use a markup language internally. As with Web Assembly, it's important we have the right primitive that we can compile to. There are configuration languages that can make it easy for beginners to hand edit a frontend, and in my article I mention the configs that Ruby On Rails, Symfony (PHP), and Django (Python) offer to generate simple CRUD interfaces, and I mention that these configs could be much more powerful if they had the correct primitive to compile against, rather rendering to HTML/CSS. Aside from all that, I would raise the more urgent question for our industry, why did it seem like such an urgent task, all through the 1980s, 1990s, and early 00s, to create visual software that would make it easy for beginners to create software, and yet now this is no longer a priority? Is there some reason why we are moving away from the era when "Empower the masses to create software" seemed like an important goal for the industry?
        zelly 6y ago
        You can't version control whatever binary format InDesign uses. Markup languages benefit from precision, readability from an editor, easy integration with other tools.
- cookiengineer 6y ago
  Everybody talks about replacing CSS, yet nobody comes up with a feasible solution. Layouting is hard. Very hard. I mean, there's a reason why ooxml or docx are so similar to CSS, and why PDF is so broken that it's a candy store for exploits. Both object and functional oriented replacements always have led to a lot of redundancy compared to their compiled CSS equivalents. And usually you cannot model layouts as flexible as with CSS' different flow models. Everybody that says CSS can be replaced with something simple usually hasn't even thought of print stylesheets, media queries, or why the box model and flow model got so complicated. The spec authors had very good reasons to make changes to the CSS spec(s).
  - googlryas 6y ago
    Maybe instead of having stylesheets for print and media queries, different versions are just written for each? I've wondered this about a11y in HTML too. Instead of trying to torment the browser into understanding how a11y should work with a bunch of ARIA properties, what if a simple alternative was offered which was easier to understand for a11y but not for 'normal' users?
    - zeven7 6y ago
      Those suggestions would probably be better if everyone building a website had infinite man power. But in the real world adoption is going to suffer if you have to make a separate document for web, print, a11y, etc. Then someone will say "Why don't we have a unified markup language that we can use to produce each of these documents for us?" And then XSLT will be invented. And what a mess we've made.
      - googlryas 6y ago
        But if people are already putting in extra effort to get these features working in their unified markup language, then it isn't different (from the perspective of effort) to write separate versions. In fact, it might be easier, because at that point you're working in a language custom designed for the task at hand, not trying to shoe horn a spoken-word UI into a visual UI language.
- asldkjaslkdj 6y ago
  HTML and CSS have been evolving for over two decades (now maybe faster than ever) and have been battle tested by nearly 2 billion websites. It seems crazy to me to think that we should throw it all out and do something new. I suspect contributing to the improvement of the existing spec is a much more pragmatic endeavor.
- jameshart 6y ago
  > Driving on one side of the road offers no obvious benefits compared to driving on the other side If that were true, then why did Sweden go to the trouble to change in 1967? The fact that they did so, and that doing so was to improve interoperability with neighboring systems, might give you some clue why getting rid of CSS and HTML requires more than mere 'obvious benefits' to justify it.
  - lkrubner 6y ago
    You’re being deliberately obtuse. Driving on some side of the road offers no benefit, other than historical concerns arising from one’s neighbors decisions, and likewise with CSS. I’m sure you were aware of this and I’m not sure why you bothered to raise such a pedantic and worthless point.

hansvm 6y ago

Or in this day and age to even choose that a byte has 8 bits.

lkrubner 6y ago

Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.

hombre_fatal 6y ago
What are the obvious benefits? My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
- lkrubner 6y ago
  This is my argument: "My experience is that people who tend to disparage web tech don't have much experience building clients in general" My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript. This is an old debate, but to repeat the highlights: The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends. The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together. The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here: http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html Earlier, in 2016, I wrote about the general problem, which offers some historical context "HTML is the failed GUI for TCP/IP" : http://www.smashcompany.com/technology/html-is-the-failed-gui-for-tcpip http://www.smashcompany.com/technology/html-is-the-failed-gu...
  - Mikhail_Edoshin 6y ago
    I fail to understand the argument. What's specifically wrong with a "markup language" that makes it unfit for GUI?
    - lkrubner 6y ago
      HyperCard, Dreamweaver, InDesign, Photoshop, Flash and Illustrator do not use a markup language internally. As with Web Assembly, it's important we have the right primitive that we can compile to. There are configuration languages that can make it easy for beginners to hand edit a frontend, and in my article I mention the configs that Ruby On Rails, Symfony (PHP), and Django (Python) offer to generate simple CRUD interfaces, and I mention that these configs could be much more powerful if they had the correct primitive to compile against, rather rendering to HTML/CSS. Aside from all that, I would raise the more urgent question for our industry, why did it seem like such an urgent task, all through the 1980s, 1990s, and early 00s, to create visual software that would make it easy for beginners to create software, and yet now this is no longer a priority? Is there some reason why we are moving away from the era when "Empower the masses to create software" seemed like an important goal for the industry?
      - zelly 6y ago
        You can't version control whatever binary format InDesign uses. Markup languages benefit from precision, readability from an editor, easy integration with other tools.
cookiengineer 6y ago
Everybody talks about replacing CSS, yet nobody comes up with a feasible solution. Layouting is hard. Very hard. I mean, there's a reason why ooxml or docx are so similar to CSS, and why PDF is so broken that it's a candy store for exploits. Both object and functional oriented replacements always have led to a lot of redundancy compared to their compiled CSS equivalents. And usually you cannot model layouts as flexible as with CSS' different flow models. Everybody that says CSS can be replaced with something simple usually hasn't even thought of print stylesheets, media queries, or why the box model and flow model got so complicated. The spec authors had very good reasons to make changes to the CSS spec(s).
- googlryas 6y ago
  Maybe instead of having stylesheets for print and media queries, different versions are just written for each? I've wondered this about a11y in HTML too. Instead of trying to torment the browser into understanding how a11y should work with a bunch of ARIA properties, what if a simple alternative was offered which was easier to understand for a11y but not for 'normal' users?
  - zeven7 6y ago
    Those suggestions would probably be better if everyone building a website had infinite man power. But in the real world adoption is going to suffer if you have to make a separate document for web, print, a11y, etc. Then someone will say "Why don't we have a unified markup language that we can use to produce each of these documents for us?" And then XSLT will be invented. And what a mess we've made.
    - googlryas 6y ago
      But if people are already putting in extra effort to get these features working in their unified markup language, then it isn't different (from the perspective of effort) to write separate versions. In fact, it might be easier, because at that point you're working in a language custom designed for the task at hand, not trying to shoe horn a spoken-word UI into a visual UI language.
asldkjaslkdj 6y ago
HTML and CSS have been evolving for over two decades (now maybe faster than ever) and have been battle tested by nearly 2 billion websites. It seems crazy to me to think that we should throw it all out and do something new. I suspect contributing to the improvement of the existing spec is a much more pragmatic endeavor.
jameshart 6y ago
> Driving on one side of the road offers no obvious benefits compared to driving on the other side If that were true, then why did Sweden go to the trouble to change in 1967? The fact that they did so, and that doing so was to improve interoperability with neighboring systems, might give you some clue why getting rid of CSS and HTML requires more than mere 'obvious benefits' to justify it.
- lkrubner 6y ago
  You’re being deliberately obtuse. Driving on some side of the road offers no benefit, other than historical concerns arising from one’s neighbors decisions, and likewise with CSS. I’m sure you were aware of this and I’m not sure why you bothered to raise such a pedantic and worthless point.