Languages Which Almost Became CSS(blog.cloudflare.com)
blog.cloudflare.com
Languages Which Almost Became CSS
https://blog.cloudflare.com/the-languages-which-almost-became-css/?f
140 comments
Just composing proper XHTML was never enough to be very useful. The way that XHTML was promoted to web developers (my impression, I was only around for the tail end), was as merely a stricter version of HTML, and that's how IE implemented it, so that was the only practical way of using it.
XHTML on its own does hardly anything that HTML didn't do. It's easier to parse, but HTML was already parseable and anyone who was going to try to extract meaning from human-readable webpages could already do that. The real value of XHTML was that it could be generated from domain-specific XML using XSLT. So your data could be served as machine readable XML in a standard, versioned schema particular to the application or document publisher, and then converted into an XHTML webpage by the browser. IE didn't implement XSLT for too long, so nobody did this, but the idea behind it is a popular approach today. It's essentially the same as serving static HTML which then fetches its data by API queries using javascript. But this would have worked with javascript disabled, and would have made the human- and machine-readable data exist at the same URI, so that it would be clear to machines what data the human-readable presentation was representing.
Ideally content providers would also serve an XSLT transformation for producing RDF/XML from the domain-specific XML representation, so that generic web crawlers could understand the meaning of the data on the page, or the generated XHTML could contain RDFa markup. We still havent gotten to the point of re-engineering this functionality, and it may never happen, since the major web businesses' revenue model depends on maintaining exclusive control of their data, and the interoperability ideals of linked data are directly opposed to that.
XHTML on its own does hardly anything that HTML didn't do. It's easier to parse, but HTML was already parseable and anyone who was going to try to extract meaning from human-readable webpages could already do that. The real value of XHTML was that it could be generated from domain-specific XML using XSLT. So your data could be served as machine readable XML in a standard, versioned schema particular to the application or document publisher, and then converted into an XHTML webpage by the browser. IE didn't implement XSLT for too long, so nobody did this, but the idea behind it is a popular approach today. It's essentially the same as serving static HTML which then fetches its data by API queries using javascript. But this would have worked with javascript disabled, and would have made the human- and machine-readable data exist at the same URI, so that it would be clear to machines what data the human-readable presentation was representing.
Ideally content providers would also serve an XSLT transformation for producing RDF/XML from the domain-specific XML representation, so that generic web crawlers could understand the meaning of the data on the page, or the generated XHTML could contain RDFa markup. We still havent gotten to the point of re-engineering this functionality, and it may never happen, since the major web businesses' revenue model depends on maintaining exclusive control of their data, and the interoperability ideals of linked data are directly opposed to that.
> The real value of XHTML was that it could be generated from domain-specific XML using XSLT. So your data could be served as machine readable XML in a standard, versioned schema particular to the application or document publisher, and then converted into an XHTML webpage by the browser.
Ok, now I understand all the buzz around XHTML at the time I was a student, and why so many people kept talking about XSLT. I just never saw anybody pointing it before, and for something that interesting I have no idea how come people weren't talking about it everywhere.
Ok, now I understand all the buzz around XHTML at the time I was a student, and why so many people kept talking about XSLT. I just never saw anybody pointing it before, and for something that interesting I have no idea how come people weren't talking about it everywhere.
>HTML was already parseable and anyone who was going to try to extract meaning from human-readable webpages could already do that.
Extracting data from circa-2005 HTML was a nightmare. It's only better now because libraries like beautifulsoup have gotten so much better at guessing structure, and even today I have things that just plain come out wrong because the HTML structure of what I'm scraping is so bad.
Extracting data from circa-2005 HTML was a nightmare. It's only better now because libraries like beautifulsoup have gotten so much better at guessing structure, and even today I have things that just plain come out wrong because the HTML structure of what I'm scraping is so bad.
While I agree those were the goals, you don't need XHTML and XML for achieving these. The same is possible with SGML and/or other processors (and xslt can at least generate HTML, too). HTML and RDFa crawling on the web is a thing.
Saying as someone who coded a web app with browser-side XSLT and linked data ten years ago.
Saying as someone who coded a web app with browser-side XSLT and linked data ten years ago.
> I started doing web development around 1999 or a bit earlier
> which means you lose style separation
A key difference in that spread of time is that back then it was all about pages where now it is a mix of pages and applications. In an interactive application separating style from content becomes less important, sometimes adding detrimental complexity in the name of trying to be "pure".
It is still very relevant for actual pages that are about content, and there are many instances of content being lost in the mire of people treating what should be simple pages as if they are complex applications, but...
While content first, then basics, then add bells as optional extras, is still a worthwhile ideal and can save time & effort long term, it can consume more time short term and often people don't want to risk asking the world to wait for them!
> which means you lose style separation
A key difference in that spread of time is that back then it was all about pages where now it is a mix of pages and applications. In an interactive application separating style from content becomes less important, sometimes adding detrimental complexity in the name of trying to be "pure".
It is still very relevant for actual pages that are about content, and there are many instances of content being lost in the mire of people treating what should be simple pages as if they are complex applications, but...
While content first, then basics, then add bells as optional extras, is still a worthwhile ideal and can save time & effort long term, it can consume more time short term and often people don't want to risk asking the world to wait for them!
> here are many instances of content being lost in the mire of people treating what should be simple pages as if they are complex applications, but...
But.... I think this is the norm, and not the exception. Sure, there are certainly a lot more "web applications* out there today than there were in 1999/2003, but I would wager there are far more "web apps that should just be pages" than legit app use-cases.
But.... I think this is the norm, and not the exception. Sure, there are certainly a lot more "web applications* out there today than there were in 1999/2003, but I would wager there are far more "web apps that should just be pages" than legit app use-cases.
Every web page with a menu somewhere hacked out of nav and ul elements and some css would gain by including some application-oriented markup at their top level and restricting the text-oriented markup into the text area.
There's not a clear separation between "text" and "application" on the web. Nearly every site has both.
There's not a clear separation between "text" and "application" on the web. Nearly every site has both.
I disagree. You're right that there is of course no clear separation (the opposite also being true: most complex web applications will contain text content), but the differentiator is when the application side becomes large and complex enough to warrant a change in paradigm. Doing that for a little blog menu is overengineering.
Every page starting at the application paradigm, and explicitly changing when displaying text would fit almost all the cases better than application and text markups that don't talk between themselves.
I don't think that's true at all. It would appear that way if you're only considering the public, "user space" internet. I've done nothing but build web applications in the enterprise sector for the last several years, all of which could not be "just pages".
But for most human beings: the icing is the cake. We hurt ourselves by thinking that "content is king" outside our own beautiful wonderful nerdy circles.
Yeah but in certain circles, those non-icing-heavy websites might actually signal greater authenticity. I LOVE college professor websites that are full of great technical info, but look like they've not been designed at all.
Depends on the circle you're making the website for I guess.
The recent HN thread about reddit working on a redesign would be relevant in relation to that statement. What circle are reddit users? The site is a link aggregator with comments which many users will argue works well and has been successful because of its apparent lack of styling. Yet many other users complain that it isn't 'pretty' enough. But the point of the site, the links and comments are there either way.
One thing many designers and programmers alike struggle with are who their circle/users are and what they want. The problem, if it is a problem, with bootstrap is that it makes everything look the same. It's both smart and lazy from a web-dev's pov.
One thing many designers and programmers alike struggle with are who their circle/users are and what they want. The problem, if it is a problem, with bootstrap is that it makes everything look the same. It's both smart and lazy from a web-dev's pov.
Recently I opened a subreddit for a little known Korean mobile developer, just as a fan, and I was surprised that you get zero control over the HTML.
At first I was a bit annoyed and confused but then I actually liked it, the more I had to get creative with CSS because although you can reinterpret a subreddit in 1000 different ways, they all "feel" the same.
I mean, I basically just gave an elevator pitch for CSS but I suppose my point is that Reddit works well as it is. You might have to do a bit of thinking outside the box but some nice designs are possible.
If you need anything more than that, chances are your design is a bit too over the top and should be simplified.
At first I was a bit annoyed and confused but then I actually liked it, the more I had to get creative with CSS because although you can reinterpret a subreddit in 1000 different ways, they all "feel" the same.
I mean, I basically just gave an elevator pitch for CSS but I suppose my point is that Reddit works well as it is. You might have to do a bit of thinking outside the box but some nice designs are possible.
If you need anything more than that, chances are your design is a bit too over the top and should be simplified.
You get a tiny amount of control over the html with :before and :after content and removing elements with display:none and going crazy with complex selectors and absolute positioning
Or we disagree on the meaning of "content". If we talk about typical literature, sure we can agree the text is the content and typography and layout is presentation. But what about a game? Or visual art? What is the "icing" and what is the "cake"?
After 2 decades browsers are finally evolving to add the icing themselves:
https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
To my mind, Reader View removes most of the 'icing'.
Safari had this feature a few years back but appear to have removed it sometime about 3 years ago. It was great, but also removed all ads from the page, so it probably wasn't popular with online news sites.
This feature has been in Safari and Firefox for ages, and is still there. It’s awesome.
I use it regularly in Safari. I also have an HN-app on my iOS-devices giving me a similar "reader view" and removing fluff from the websites. I find it really pleasing when just reading articles (I've often caught myself going into devtools to remove navigation bars, sidebars, etc from websites when reading longer articles since they distract me).
ctrl + alt + r, btw ;)
>Most developers I knew in person didn't care about CSS or didn't 'get' it.
It being a broken technology, used for tasks it wasn't until recently even remotely suited for (layout) probably played a role to that.
It being a broken technology, used for tasks it wasn't until recently even remotely suited for (layout) probably played a role to that.
I was also a web standards man.
For me it was the realisation that I was more colorblind than I previously though and bootstrap meant nicer designs than anything I would be ablr to create myself.
So I fell back to bootstrap (unless I'm working with a dedicated html / css person - then I'll let them decide.)
For me it was the realisation that I was more colorblind than I previously though and bootstrap meant nicer designs than anything I would be ablr to create myself.
So I fell back to bootstrap (unless I'm working with a dedicated html / css person - then I'll let them decide.)
Styling will keep a company alive long before a focus on accessibility would kill it. Semantic markup is borderline pointless, except to rationalize design elements and keep them consistent.
I think you're thinking like an engineer rather than a customer. The customer is more important than the engineering, as long as the engineering supports what the customer is trying to do. Very few customers rely on semantic markup, thus it is not very important.
I think you're thinking like an engineer rather than a customer. The customer is more important than the engineering, as long as the engineering supports what the customer is trying to do. Very few customers rely on semantic markup, thus it is not very important.
The customer is more important than the engineering,
as long as the engineering supports what the customer
is trying to do
I don't think anybody has ever been under the belief that customers really were gonna do a "View Source" on a web page and just marvel at your clean HTML.
> Semantic markup is borderline pointless, except to rationalize design elements and keep them consistent.
Consider that from the beginning of the web, people could have composed pages entirely of image maps with hotspots to direct them (and some did).
Or as soon as JS arrived, they could have replaced hyperlinks with scripted behavior (as some did and many do now).
Where would Google have come from? Its foundation was largely in the semantics of hyperlinks.
Consider that from the beginning of the web, people could have composed pages entirely of image maps with hotspots to direct them (and some did).
Or as soon as JS arrived, they could have replaced hyperlinks with scripted behavior (as some did and many do now).
Where would Google have come from? Its foundation was largely in the semantics of hyperlinks.
Semantic markup is for computer to categorise and file. The easier google can figure out what your page is trying to do, more efficiently it can serve it into the right hands.
> it always feels like a large portion of people who do web dev don't 'get' the web
My history is surprisingly similar to yours, I started in 1999, I used Notepad as my first text editor, and by 2003 I got caught up in the movement towards making markup strict, which I felt was the mark of professionalism. However, by 2006 I had mostly rejected the notion of "strictness". There were several things that turned me against strictness. One of them was Mark Pilgrim's essay "XML on the Web Has Failed":
https://www.xml.com/pub/a/2004/07/21/dive.html
Another problem was brought up by Sam Ruby: his daughter sent him an image, which he wanted to share on MySpace, but he couldn't. And the reason he couldn't was because the image was in a SVG format which required strict XML, and MySpace was, of course, very far from anything "strict".
Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML.
We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network).
That we now have so many versions of languages that compile back to Javascript, which renders HTML, shows that there is a great hunger for something that moves beyond HTTP/HTML.
The quote that Mark Pilgrim used at the beginning of his article is worth repeating:
"There must have been a moment, at the beginning, where we could have said ... no. Somehow we missed it. Well, we'll know better next time." "Until then ..." -- Rosencrantz and Guildenstern are Dead
He may have meant that ironically (since Rosencrantz and Guildenstern are murdered) but I like to think that we will eventually get rid of HTTP/HTML and replace it with what developers actually want: a pure GUI for IP/TCP, a technology with a single mandate, with no burden of also offering semantics or structure or hierarchy.
My history is surprisingly similar to yours, I started in 1999, I used Notepad as my first text editor, and by 2003 I got caught up in the movement towards making markup strict, which I felt was the mark of professionalism. However, by 2006 I had mostly rejected the notion of "strictness". There were several things that turned me against strictness. One of them was Mark Pilgrim's essay "XML on the Web Has Failed":
https://www.xml.com/pub/a/2004/07/21/dive.html
Another problem was brought up by Sam Ruby: his daughter sent him an image, which he wanted to share on MySpace, but he couldn't. And the reason he couldn't was because the image was in a SVG format which required strict XML, and MySpace was, of course, very far from anything "strict".
Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML.
We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network).
That we now have so many versions of languages that compile back to Javascript, which renders HTML, shows that there is a great hunger for something that moves beyond HTTP/HTML.
The quote that Mark Pilgrim used at the beginning of his article is worth repeating:
"There must have been a moment, at the beginning, where we could have said ... no. Somehow we missed it. Well, we'll know better next time." "Until then ..." -- Rosencrantz and Guildenstern are Dead
He may have meant that ironically (since Rosencrantz and Guildenstern are murdered) but I like to think that we will eventually get rid of HTTP/HTML and replace it with what developers actually want: a pure GUI for IP/TCP, a technology with a single mandate, with no burden of also offering semantics or structure or hierarchy.
> a pure GUI for IP/TCP
What does that actually mean? There are all kinds of systems which use a TCP link to produce a display on one end, with all kinds of different design compromises, made for different reasons and use cases.
If people had, by some miracle, standardised the web as a graphical format back in the early 90s by dictating that screens had to be 4:3 format with a particular minimum resolution, what would have happened to smartphones?
What does that actually mean? There are all kinds of systems which use a TCP link to produce a display on one end, with all kinds of different design compromises, made for different reasons and use cases.
If people had, by some miracle, standardised the web as a graphical format back in the early 90s by dictating that screens had to be 4:3 format with a particular minimum resolution, what would have happened to smartphones?
That brought back memories of trying to use AOL in the wrong screen resolution.
"Cascading JSON Style Sheets" - I suppose it would need a snappier acronym. Serve pure JSON content endpoints, and like, a standard response header which points to the resources which can render them.
I like to think that we will eventually get rid of HTTP/HTML and replace it with what developers actually want: a pure GUI for IP/TCP, a technology with a single mandate, with no burden of also offering semantics or structure or hierarchy.
Isn't that what Flash, Silverlight, Java Applets and Canvas offer?
Isn't that what Flash, Silverlight, Java Applets and Canvas offer?
In the case of Flash, yes. But Java applets were designed to be embeddable applications. Much like with ActiveX. While it's true that sometimes those Java applets were just GUIs, but other times they went as far as using their own TCP/IP stack (eg for chat client)
Rosencrantz and Guildenstern are Dead is a play by Tom Stoppard https://en.wikipedia.org/wiki/Rosencrantz_and_Guildenstern_A...
The 'There must have been a moment..." quote is from the play. However it is a very ironic play, and it's been my experience that anyone who quotes it does so ironically.
The 'There must have been a moment..." quote is from the play. However it is a very ironic play, and it's been my experience that anyone who quotes it does so ironically.
HTML is ironically very nice as a standard, even if broken by design. Think about crawlers for instance, which would not be possible without HTML.
I used Arachnophilia (old native application, not the Java based one), Frontpage and Dreamweaver.
HTML 4 Transitional used to be very popular back in the 1999/2000. The XHTML movement was a weird hype, I tried it out but TinyMCE/WYSIWYG-editor spit out old HTML3 code at that time, so I tried XHTML 1 Transitional, but used .html extension as IE6 didn't support .xhtml. Anyway XHTML2 was a trainwreck, they were nuts to propose an completely incompatible syntax, a failed ideology and I switched back shortly after to HTML4 (2004). There was also a weird short hype around a new incompatibility Javascript version 4, short E4X. XML used to be everywhere, and some nuts tried to make XML part of JavaScript syntax - Mozilla and Adobe were into this crazy land. Thankfully it died, and there was never a JS4, but the JavaScript 5 strict was superb. CSS was okayish since IE5.5 and especially IE6 and MozillaSuite. Then there was the hype to not use tables but do everything with CSS divs. I quickly learned that a few tables and using CSS for everything else worked well in practice and gave one a responsive design long before it had a name. Loading data asynchronous used to be possible with XML on both IE56 and Firebird/earlyFirefox already in 2003, I found only two sites back then that had documentation for that obscure API back then, but it worked great - made a CD-ROM based elearning software written as one-page-app (HTML4, CSS and JS) with loading data from XML files and showing text, pictures and multimedia videos (Flash MX, before there was FLV format), that was two years before it became well know as AJAX (now XHR).
https://en.m.wikipedia.org/wiki/XHTML#XHTML_2.0
https://en.m.wikipedia.org/wiki/ECMAScript_for_XML
HTML 4 Transitional used to be very popular back in the 1999/2000. The XHTML movement was a weird hype, I tried it out but TinyMCE/WYSIWYG-editor spit out old HTML3 code at that time, so I tried XHTML 1 Transitional, but used .html extension as IE6 didn't support .xhtml. Anyway XHTML2 was a trainwreck, they were nuts to propose an completely incompatible syntax, a failed ideology and I switched back shortly after to HTML4 (2004). There was also a weird short hype around a new incompatibility Javascript version 4, short E4X. XML used to be everywhere, and some nuts tried to make XML part of JavaScript syntax - Mozilla and Adobe were into this crazy land. Thankfully it died, and there was never a JS4, but the JavaScript 5 strict was superb. CSS was okayish since IE5.5 and especially IE6 and MozillaSuite. Then there was the hype to not use tables but do everything with CSS divs. I quickly learned that a few tables and using CSS for everything else worked well in practice and gave one a responsive design long before it had a name. Loading data asynchronous used to be possible with XML on both IE56 and Firebird/earlyFirefox already in 2003, I found only two sites back then that had documentation for that obscure API back then, but it worked great - made a CD-ROM based elearning software written as one-page-app (HTML4, CSS and JS) with loading data from XML files and showing text, pictures and multimedia videos (Flash MX, before there was FLV format), that was two years before it became well know as AJAX (now XHR).
https://en.m.wikipedia.org/wiki/XHTML#XHTML_2.0
https://en.m.wikipedia.org/wiki/ECMAScript_for_XML
E4X was a standard for XML literals in JavaScript supported by Mozilla's JavaScript, including Rhino. It was hated or unknown at best because "XML sucks", so Moz removed it a couple years ago. Of course, today folks cheer at React's JSX, which is more or less the exact same thing, yet comes with the Facebook licence. Goes to show how much irrationality there is in the evolvement of web standards. It's also something to keep in mind when judging use of the newest ES7+ syntax sugar on a project.
>Goes to show how much irrationality there is in the evolvement of web standards.
Well, for one E4X was never adopted by other browsers that mattered, only Mozilla.
Second, it's main use was for working with XML, which the web is glad we got rid of.
Well, for one E4X was never adopted by other browsers that mattered, only Mozilla.
Second, it's main use was for working with XML, which the web is glad we got rid of.
JSX is really just syntactic sugar for function calls, I suppose you could use React components as data structures but that's not really the intended use case.
XHTML hyper here.
Had the browsers properly adopted XHTML and the accompanying standards, and today we could already enjoy something like XAML on the browser instead of having only Chrome supporting WebComponents with workarounds like ShadowDOM to preserve local changes.
Had the browsers properly adopted XHTML and the accompanying standards, and today we could already enjoy something like XAML on the browser instead of having only Chrome supporting WebComponents with workarounds like ShadowDOM to preserve local changes.
I also liked XHTML, but why do you see it as a transition path to something like XAML? Isn't it basically well-structured HTML?
I mean, I get that it's extensible thanks to XML, but that doesn't mean browsers would actually have an incentive to create and implement such extensions.
I mean, I get that it's extensible thanks to XML, but that doesn't mean browsers would actually have an incentive to create and implement such extensions.
The XAML like parts were the set of XHTML components standards.
https://www.w3.org/standards/xml/components
Basically Events, Modularization, Fragments, XForms, XQuery and possibly other parts that were still being worked on when the HTML 5 hype started.
And were we are, yet to have a Web UI designer that can match Blend, Qt Creator, Netbeans Matisse, Scene Builder, Glade, Delphi, C++ Builder,....
When I do web development I always feel like I am stuck with something not better than Notepad for GUI programming.
https://www.w3.org/standards/xml/components
Basically Events, Modularization, Fragments, XForms, XQuery and possibly other parts that were still being worked on when the HTML 5 hype started.
And were we are, yet to have a Web UI designer that can match Blend, Qt Creator, Netbeans Matisse, Scene Builder, Glade, Delphi, C++ Builder,....
When I do web development I always feel like I am stuck with something not better than Notepad for GUI programming.
Ok I have to disagree here. I believe the failure of XHTML was to cram everything into XML; I found XForms especially pointless. Now don't get me wrong, and as you know from my other posts here I'm as much of a markup geek as can be, but IMO markup is first and foremost for representing and authoring text. Just that browser content is mostly text, however, doesn't mean everything has to be markup. To the contrary, I believe XHTML (and XML in mainstream apps) fell out of favor because the spec authors tried to anchor each and everything on XML, rather than on something that makes sense for the task at hand (a phenomenon not unheard of for JSON and YAML as well). In XForms, for example, XML was used as a programming language which just never made sense. You know you're doing it wrong IMHO when you have to discuss whether you want to store your data in attributes or element content, a distinction that only makes sense for text data.
It's sad and surprising how much time and energy was wasted on XHTML. Back in february I met Steven Pemberton (XHTML spec lead back then, and of ABC/Python fame). He's just such an inspiring guy to talk to, but unfortunately, there was no time for recapitulating the XHTML situation.
It's sad and surprising how much time and energy was wasted on XHTML. Back in february I met Steven Pemberton (XHTML spec lead back then, and of ABC/Python fame). He's just such an inspiring guy to talk to, but unfortunately, there was no time for recapitulating the XHTML situation.
> And were we are, yet to have a Web UI designer that can match Blend, Qt Creator, Netbeans Matisse, Scene Builder, Glade, Delphi, C++ Builder,....
Huh, my experience was all those things are terrible (spent some time with Qt and researching Glade, also inherited a Delphi codebase full of spaghetti code at one point).
Visual UI tools are great for prototyping, awful for maintainable code. Anyone I know who's spent any time with them ends up wanting to go back to the code.
There certainly are good Web UI designers [1], it just seems no-one wants them. There are successful visual Web UI prototyping tools tho.
[1] http://macaw.co/
Huh, my experience was all those things are terrible (spent some time with Qt and researching Glade, also inherited a Delphi codebase full of spaghetti code at one point).
Visual UI tools are great for prototyping, awful for maintainable code. Anyone I know who's spent any time with them ends up wanting to go back to the code.
There certainly are good Web UI designers [1], it just seems no-one wants them. There are successful visual Web UI prototyping tools tho.
[1] http://macaw.co/
Those tools are wonderful and make my life on native frontend projects enjoyable, versus the pain having to deal with of Web design, which I happen to have experience since the early days (first coded web apps were C based cgis in 1997).
Trying to manually hack GUI generated code is an anti-pattern.
One has to leave the code generated by the tools to the tools, everything else should live in other code files.
Sadly I never heard of Macaw, specially on the enterprise circles I move on, in any case they seem to be gone now.
Trying to manually hack GUI generated code is an anti-pattern.
One has to leave the code generated by the tools to the tools, everything else should live in other code files.
Sadly I never heard of Macaw, specially on the enterprise circles I move on, in any case they seem to be gone now.
You don't need XML for that. HTML can be parsed using SGML precisely and elegantly [1] (if I may say so for a project of mine).
If you see value in XML, you really should look into XML's big sister SGML. It gives you downward compat with XML, tag inference, type-aware (injection-free) variable and macro expansion, custom Wiki syntaxes (markdown and others), an integrated stylesheet language without new ad-hoc syntax, full HTML 5 parsing with short forms for attributes etc., and more. You might actually like it.
[1]: http://sgmljs.net/blog/blog1701.html
If you see value in XML, you really should look into XML's big sister SGML. It gives you downward compat with XML, tag inference, type-aware (injection-free) variable and macro expansion, custom Wiki syntaxes (markdown and others), an integrated stylesheet language without new ad-hoc syntax, full HTML 5 parsing with short forms for attributes etc., and more. You might actually like it.
[1]: http://sgmljs.net/blog/blog1701.html
I was a big fan of Docbook, back when SGML was more well known, thanks for the heads up.
However this is meaningless if the browsers keep being a document engine, full of workarounds to translate a mix of document tags, coupled with some generic <div> and <span> into some kind of general purpose GUI layout engine.
Having to find the proper incantation of CSS3 transforms to portably trigger GUI acceleration is a good example of such hacks.
Even if it is yet another hack, webcomponents + shadowdom looked it would be the solution, even if a bit hackish, but it is Chrome only.
However this is meaningless if the browsers keep being a document engine, full of workarounds to translate a mix of document tags, coupled with some generic <div> and <span> into some kind of general purpose GUI layout engine.
Having to find the proper incantation of CSS3 transforms to portably trigger GUI acceleration is a good example of such hacks.
Even if it is yet another hack, webcomponents + shadowdom looked it would be the solution, even if a bit hackish, but it is Chrome only.
I loved Arachnophilia. Awesome little editor. Wasn't keen on Dreamweaver - I mean I guess it's ok if you're a designer but not really something I'd have ever recommend for developers. Frontpage though; you're brave admitting to using that!
My favourite of the failed web technologies was VRML. Back in the 90s I used to create epic 3D landscapes that would render inside the browser much like how some experiment with WebGL these days. But this was long before it was 3D accelerators were common inside PCs (they were still very expensive so most graphics cards software rendered 3D models). VRML I think was a victim of being too ahead of its time.
The web was exciting back then. Nobody really knew what you could or couldn't do with it. These days I feel we've lost something with all these bloated frontend frameworks which act like magic boxes in that an alarming number of frontend developers don't understand how their code executes. But I guess that's what happens when science or technology becomes business.
My favourite of the failed web technologies was VRML. Back in the 90s I used to create epic 3D landscapes that would render inside the browser much like how some experiment with WebGL these days. But this was long before it was 3D accelerators were common inside PCs (they were still very expensive so most graphics cards software rendered 3D models). VRML I think was a victim of being too ahead of its time.
The web was exciting back then. Nobody really knew what you could or couldn't do with it. These days I feel we've lost something with all these bloated frontend frameworks which act like magic boxes in that an alarming number of frontend developers don't understand how their code executes. But I guess that's what happens when science or technology becomes business.
> Frontpage though; you're brave admitting to using that!
FrontPage was a great educational tool, sure it produced crappy HTML, sure it was IE biased, but it made you learn, it was fast and came bundled in Office. Countless numbers of hobby web pages were build thanks to it.
FrontPage was a great educational tool, sure it produced crappy HTML, sure it was IE biased, but it made you learn, it was fast and came bundled in Office. Countless numbers of hobby web pages were build thanks to it.
>Wasn't keen on Dreamweaver - I mean I guess it's ok if you're a designer but not really something I'd have ever recommend for developers.
Mostly because of cargo cult -- as Dreamweaver produced very clean HTML output.
Mostly because of cargo cult -- as Dreamweaver produced very clean HTML output.
> Mostly because of cargo cult
That was my point. If you're familiar enough with HTML to use Arachnophilia (which, if anyone isn't familiar with that particular editor, was basically just the Notepad++ of it's day) then Dreamweaver would just seem excessive. Hence why I'd recommend it for designers rather than developers ;)
> as Dreamweaver produced very clean HTML output.
Cleaner than Frontpage and most of the other design tools out then, sure. But my experience of Dreamweaver around that era was that it's HTML output still needed a lot of manual refactoring in a text editor afterwards. While it was better than most GUIs it was still a long way off "very clean HTML output".
I'm sure things have improved significantly in the last 15/20 years though. But that was certainly the state of things back in the late 90s / early 00s.
As an aside note: I won a Source Code Planet (anyone remember them?) competition one month with an entry I made in Dreamweaver. It was a mockup of a Window 95 or 98 (I forget which) desktop with functioning start menu. I always felt naughty for winning based on something I built in a tool that auto-generates a lot of the code for you but then other projects I released were a lot more credible (eg DirectX games) but far less popular. I guess it just goes to show how little most people cared for code quality even back then.
That was my point. If you're familiar enough with HTML to use Arachnophilia (which, if anyone isn't familiar with that particular editor, was basically just the Notepad++ of it's day) then Dreamweaver would just seem excessive. Hence why I'd recommend it for designers rather than developers ;)
> as Dreamweaver produced very clean HTML output.
Cleaner than Frontpage and most of the other design tools out then, sure. But my experience of Dreamweaver around that era was that it's HTML output still needed a lot of manual refactoring in a text editor afterwards. While it was better than most GUIs it was still a long way off "very clean HTML output".
I'm sure things have improved significantly in the last 15/20 years though. But that was certainly the state of things back in the late 90s / early 00s.
As an aside note: I won a Source Code Planet (anyone remember them?) competition one month with an entry I made in Dreamweaver. It was a mockup of a Window 95 or 98 (I forget which) desktop with functioning start menu. I always felt naughty for winning based on something I built in a tool that auto-generates a lot of the code for you but then other projects I released were a lot more credible (eg DirectX games) but far less popular. I guess it just goes to show how little most people cared for code quality even back then.
I remember Planet Source Code, it was the Github of the late 1990s. Everything from VB, C++ and HTML samples were there. A one stop community platform. I remember I coded a Windows 98 shell replacement, a Frontpage WYSIWYG clone, an Paint clone, DirectX8 games in VB6. Then MSFT canceled VB7, me people moved elsewhere. Then Sourceforge took over. And later Google Code took over. Then Github took over.
Sourceforge is not dead, it's just sleeping.
Well, technically PSC (Planet Source Code) isn't dead either. There still new VB6/etc code gets uploaded even in 2017. https://www.planet-source-code.com/vb/scripts/BrowseCategory...
GitHub is the current thing, PSC/Sourceforge/GoogleCode are still technically (at least read-only) around.
GitHub is the current thing, PSC/Sourceforge/GoogleCode are still technically (at least read-only) around.
The LISPers here around will miss DSSSL for sure ...
Me, I can't get over the point that CSS introduced a whole new syntax for item/values when HTML/SGML attributes were exactly designed for presentational properties. The idea/dogma that content goes into HTML and presentation into CSS, with completely separate syntax, didn't make any more sense back then as it does now:
> "Well, you get to learn this language to write your document, and then you get to learn that language for actually making your document look like you want it to."
Me, I can't get over the point that CSS introduced a whole new syntax for item/values when HTML/SGML attributes were exactly designed for presentational properties. The idea/dogma that content goes into HTML and presentation into CSS, with completely separate syntax, didn't make any more sense back then as it does now:
> "Well, you get to learn this language to write your document, and then you get to learn that language for actually making your document look like you want it to."
I am not sure I understand your point, how do you expect to be able to apply a style across multiple elements in a HTML document using attributes of existing elements?
Nevertheless you'd have to define selectors or use classes, even XPATH had to come along for XML.
Then you would also have to define property names and value. And you pretty much invented CSS. To apply it by classification, it has to be declared independent from your document tree, then you might as well separate it.
Nevertheless you'd have to define selectors or use classes, even XPATH had to come along for XML.
Then you would also have to define property names and value. And you pretty much invented CSS. To apply it by classification, it has to be declared independent from your document tree, then you might as well separate it.
From the example of FOSI in the article, it looks like the SGML elements aren't directly contained within the elements they style but refer them them from attributes (gi="h1", gi="h2", etc.), which is actually more similar in functionality to having external CSS stylesheets than inline CSS (which is what I think you're referring to).
FWIW, SGML also has LINKTYPEs (in addition to DOCTYPEs) for declaring presentation properties using normal attribute declaration syntax. A LINKTYPE can contain a state automaton assigning link attribute values to content elements and for transitioning to other states, but, unlike CSS, doesn't use regular patterns. This system makes sense for print, where a standard task is to assign different horizontal margins on even and odd pages. Using SGML LINK, this can be implemented by declaring two states transitioning to one another over page elements. A regular expression pattern language like CSS, OTOH, can't express the necesssary logic, hence CSS has a large number of extra predicates.
Well, if CSS actually supported full regular expressions in selectors, even/odd wouldn't need custom predicates.
Yes, but only if grouping of subexpressions or non-terminals in grammar productions are allowed (they aren't in CSS).
To elaborate, the problem at hand is to assign different properties to the even and odd elements, resp., of a sequence using just the sequence, alternation, and Kleene star operators in two rules. For example, the rules for the first few items (as) are as follows:
To elaborate, the problem at hand is to assign different properties to the even and odd elements, resp., of a sequence using just the sequence, alternation, and Kleene star operators in two rules. For example, the rules for the first few items (as) are as follows:
even -> a a | a a a a | ..
odd -> a | a a a | ..
even -> ( a a )*
odd -> even aThat's a full logic language (like prolog) for selecting things. It's very easy to mess up a prolog program and destroy its performance, so it's not a good thing to have on a web standard.
Maybe something more functional instead of logic would be better.
Maybe something more functional instead of logic would be better.
For comparison, it's also quite easy to mess up the performance of a JavaScript program, and yet it's part of a web standard. My recommendation in cases of poor performance is to improve Prolog systems by features that yield better performance. Examples: better virtual machines, JIT indexing, tabling, constraints, goal reordering as in Mercury etc., all of which are now becoming part of modern Prolog systems.
Important advantages of logic programs over functional ones is that logic programs are typically shorter and more general, and ideally well suited for describing domain-specific knowledge (such as styles and layouts) declaratively. Prolog is already part of the semantic web to considerable extent, albeit disguised as RDF and complex query languages with a different syntax than Prolog. It could have been Prolog all along, and some members of the committees have suggested that in fact.
Important advantages of logic programs over functional ones is that logic programs are typically shorter and more general, and ideally well suited for describing domain-specific knowledge (such as styles and layouts) declaratively. Prolog is already part of the semantic web to considerable extent, albeit disguised as RDF and complex query languages with a different syntax than Prolog. It could have been Prolog all along, and some members of the committees have suggested that in fact.
Fun to hear from another Prolog fan here. Like you, I came back to Prolog from SPARQL/OWL2, and share your opinion. My upcoming SGML system (sgmljs.net) will also feature a full ISO Prolog engine for querying over document metadata (there's even a "tolog" Prolog profile for this, which at one point was considered to become an ISO standard [1]).
Do you know of Prolog systems for layout computation of CSS or other layout languages? I "know" Prince/PrinceXML (Mercury-based) and the begin of a formal specification for CSS as logic/attribute grammar [2] (from 2009).
[1]: http://www.ontopia.net/section.jsp?id=specifications
[2]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend...
Do you know of Prolog systems for layout computation of CSS or other layout languages? I "know" Prince/PrinceXML (Mercury-based) and the begin of a formal specification for CSS as logic/attribute grammar [2] (from 2009).
[1]: http://www.ontopia.net/section.jsp?id=specifications
[2]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend...
Awesome work and links! For dynamic layout generation with Prolog, I recommend you start with the PhD thesis of Joost Geurts:
https://pure.tue.nl/ws/files/2135764/200613391.pdf
Joost uses Prolog CLP(FD) constraints and other declarative language features for reasoning about multimedia data.
See also the following paper:
https://espace.library.uq.edu.au/view/UQ:7851
However, I must correct one misconception: I did not "come back from SPARQL/OWL2" to Prolog. Rather, when the whole RDF/SPARQL hype started, I could only hope that in due time, this will all stop again and turn back to Prolog, which now, years later, is slowly happening. Prolog FTW! It's a great language for formal specifications and declarative descriptions of all kinds of data, including layouts. I hope your project becomes a great success. ISO compliance is definitely a great benefit and will help adoption in large organizations considerably.
https://pure.tue.nl/ws/files/2135764/200613391.pdf
Joost uses Prolog CLP(FD) constraints and other declarative language features for reasoning about multimedia data.
See also the following paper:
https://espace.library.uq.edu.au/view/UQ:7851
However, I must correct one misconception: I did not "come back from SPARQL/OWL2" to Prolog. Rather, when the whole RDF/SPARQL hype started, I could only hope that in due time, this will all stop again and turn back to Prolog, which now, years later, is slowly happening. Prolog FTW! It's a great language for formal specifications and declarative descriptions of all kinds of data, including layouts. I hope your project becomes a great success. ISO compliance is definitely a great benefit and will help adoption in large organizations considerably.
I disagree that it's equally easy to mess languages of any other paradigm. One simply does not code a linear time algorithm into a super-exponential time program by mistake in javascript. At least, not often.
That said, the DOM is actually not that large. My comment may be an overreaction.
That said, the DOM is actually not that large. My comment may be an overreaction.
I was just trying to make the point that in core CSS basic even/odd selection isn't possible, hence the :nth-child()/:nth-of-type() CSS selectors were introduced. SGML LINK doesn't have this particular problem, as it just encodes an automaton using transitions. For example, you can say
<!link even
x #postlink odd [ background-color=gray ]>
<!link odd
x #postlink even [ background-color=white ]>
Yes I saw this and though you might be referring to this, but it's still roughly the same, by defining these attribute names and selectors, you are still defining a language, you don't save much to learn. There is not much else to the CSS language.
I think that tannhaeuser was just stating a preference that we use the same syntax for both the content (HTML) and the style markup (FOSI vs. CSS)
I sure do miss DSSSL, I taught myself Scheme especially to use it. But that's how I also recognized it would never be huge: learning curve too steep.
Nevertheless I don't think it's wrong to have a separate styling language. HTML already makes it easy to wobble off the tightrope we walk between content and layout.
Nevertheless I don't think it's wrong to have a separate styling language. HTML already makes it easy to wobble off the tightrope we walk between content and layout.
technically if we wrap each css rule in a set of parens it is already 99% clojure syntax (or whichever other lisps have curly braces for maps). i wish LISPy languages caught on, we'd never needed things like SASS/LESS.
You can express any kind of information with HTML/XML tags and attributes but that doesn't mean you should. CSS is a much nicer and more readable syntax for its purpose.
To be honest, I still find CSS a mess. I really dislike it. I feel like JS and HTML are pretty solid, then you have this CSS hacky shit with no decent docs and I just didn't get it.
Recently I wanted to use Material Components, and the whole BEM thing makes my eyes cry.
`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::before`
`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::after`
`mdc-toolbar__section mdc-toolbar__section--align-start`
I just am not going to work with that in my code and it screams to me something is wrong.
Recently I wanted to use Material Components, and the whole BEM thing makes my eyes cry.
`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::before`
`custom-on-dark .mdc-icon-toggle.mdc-ripple-upgraded::after`
`mdc-toolbar__section mdc-toolbar__section--align-start`
I just am not going to work with that in my code and it screams to me something is wrong.
I'm not a fan of BEM either. It terribly feels like over-engineering and ignores certain principles of CSS. Often, much better clarity could be achieved simply with better naming and structuring of elements.
>I'm not a fan of BEM either. It terribly feels like over-engineering and ignores certain principles of CSS.
It's actually under-engineering (a brute force, hacky solution), and it ignores those principles of CSS (cascading for one) on purpose because they have been historically found to be more harm than good.
It's actually under-engineering (a brute force, hacky solution), and it ignores those principles of CSS (cascading for one) on purpose because they have been historically found to be more harm than good.
Something about it reminds me of being new to programming.
var the_first_left_menu_item_animation_enter
var the_second_left_menu_item_animation_enter
What causes this problem? Does CSS not have any modular capability and that is why? Is it global by definition? Not really sure what I am trying to say.
var the_first_left_menu_item_animation_enter
var the_second_left_menu_item_animation_enter
What causes this problem? Does CSS not have any modular capability and that is why? Is it global by definition? Not really sure what I am trying to say.
>What causes this problem? Does CSS not have any modular capability and that is why? Is it global by definition?
It has crappy scoping and modularity rules.
It has crappy scoping and modularity rules.
> Often, much better clarity could be achieved simply with better naming and structuring of elements.
I'm always interested in seeing examples of good class naming and structure if you have some available.
BEM is more about specificity, modularity, and namespacing than it is about clarity (which many think it also achieves).
I'm always interested in seeing examples of good class naming and structure if you have some available.
BEM is more about specificity, modularity, and namespacing than it is about clarity (which many think it also achieves).
Well, I disagree with some assumptions it makes. For example, `.button--active` should help avoiding collisions with other elements using the same modifier `.active`. But I would argue that either there are shared styling rules between such "colliding" elements, or the modifier is named poorly (i.e. shouldn't be as generic as `active`.
I particularly liked the way tachyons does styling, in contrast to this. (http://tachyons.io/)
".ba" to add border all or ".bt" for border top... then just add ".b--dashed" for dashed border... ".georgia" will use Georgia font... ".red" will color it red.
Though class names they used can be more uniform IMO.
".ba" to add border all or ".bt" for border top... then just add ".b--dashed" for dashed border... ".georgia" will use Georgia font... ".red" will color it red.
Though class names they used can be more uniform IMO.
Why do you want to spend all your time editing your HTML, adding and removing classes in multiple places again and again, when you could just make one change in your CSS?
Whats the benefit of tachyons over just writing inline styles?
The author discusses it a bit here: https://github.com/tachyons-css/tachyons/issues/12
The key points from there, regarding your question specifically: 1) inline styles can't use media queries, while there are tachyon classes for different devices. 2) Ditto for pseudo classes. 3) The browser renders them faster.
But I think your actual question was something more along the lines of "isn't styling individual elements considered bad practice?" That has a bigger answer and is more philosophical. I, too, recoil at it, but I'm open to best practices changing or being considered differently in the context of web applications vs web pages.
For example, react and JSX changed my mind about mixing JS and markup and even styling to some extent.
The key points from there, regarding your question specifically: 1) inline styles can't use media queries, while there are tachyon classes for different devices. 2) Ditto for pseudo classes. 3) The browser renders them faster.
But I think your actual question was something more along the lines of "isn't styling individual elements considered bad practice?" That has a bigger answer and is more philosophical. I, too, recoil at it, but I'm open to best practices changing or being considered differently in the context of web applications vs web pages.
For example, react and JSX changed my mind about mixing JS and markup and even styling to some extent.
>I, too, recoil at it
But you're recommending this? This has advantages over inline styles, but doesn't avoid the main drawback of using them: difficulty to maintain and change.
But you're recommending this? This has advantages over inline styles, but doesn't avoid the main drawback of using them: difficulty to maintain and change.
From their examples:
<article class="mw7 center ph3 ph5-ns tc br2 pv5 bg-washed-green dark-green mb5">
<a class="f6 br-pill bg-dark-green no-underline washed-green ba b--dark-green grow pv2 ph3 dib mr3"href="#">Sign Up</a>
</article>
I love CSS, I wonder why it is not an universal standard used to define GUIs in other contexts like native mobile apps, or desktop apps.
Why did Android creators decided to define its own way to describe GUIs, when CSS existed and could be used for that purpose?
Every time I have tried to create a decent GUI for the desktop I get disappointed by the insane difficulty of the task, as with CSS you can make something look good in a few minutes.
Why did Android creators decided to define its own way to describe GUIs, when CSS existed and could be used for that purpose?
Every time I have tried to create a decent GUI for the desktop I get disappointed by the insane difficulty of the task, as with CSS you can make something look good in a few minutes.
Perhaps not surprisingly there's a just as large cohort of people who love how GUIs are defined in desktop and mobile applications and despise CSS. I've seen someone go so far as to redefine the entire browser rendering system, drawing every button and control onto one big HTML canvas element.
They're very different ways of building a UI, and it's hard to find people with a ton of experience in both to provide perspective, much less an answer as to which is 'better'.
They're very different ways of building a UI, and it's hard to find people with a ton of experience in both to provide perspective, much less an answer as to which is 'better'.
[deleted]
Because the way of native GUI programming is much more productive than the mess of trying to make piles of <div>, <span> and tags designed for text like <li> to do something meaningful.
Correct.
Of course if you are trying to lay out something document like (like those things we had back in the '90s called web pages), then HTML is much easier than native GUI programming.
Of course if you are trying to lay out something document like (like those things we had back in the '90s called web pages), then HTML is much easier than native GUI programming.
Agreed, which is why I never been a big fan of Web 2.0 wave.
For me, the correct path would have been the proper implementation of XHTML and related XML based languages.
By now we would be enjoying something like XAML on the browser, with proper tooling like Blend, instead of workarounds like React, Angular and WebComponents.
For me, the correct path would have been the proper implementation of XHTML and related XML based languages.
By now we would be enjoying something like XAML on the browser, with proper tooling like Blend, instead of workarounds like React, Angular and WebComponents.
My experience is exactly the opposite. Whether it's getting things vertically aligned, or consistent margins between composed UIs (so that you never need to adjust margins on a per-instantiated-component basis), or avoiding scrollbar nesting by using the full page for scrolling and then needing to absolutely position content so that app chrome correctly overlays it - CSS is painful all the time.
>I love CSS, I wonder why it is not an universal standard used to define GUIs in other contexts like native mobile apps, or desktop apps.
Because in other domains sanity prevailed.
Because in other domains sanity prevailed.
I'm no Android developer but I was recently doing some of Google's basic courses and I have to say, I'd take Android's positioning system anyday.
I think a mix of both would be best but just being able to specifically say put x "toLeftOf="@id/y" was very nice.
Mind you, I'm someone who plays "CSS Whack-a-mole" rather than actually truly understanding how it's positioning works.
I think a mix of both would be best but just being able to specifically say put x "toLeftOf="@id/y" was very nice.
Mind you, I'm someone who plays "CSS Whack-a-mole" rather than actually truly understanding how it's positioning works.
>I wonder why it is not an universal standard used to define GUIs in other contexts
CSS appeared after native apps already had layout/geometry managers that understood how to deal with grids, fixed layouts, changing display sizes, etc. Most of them I've used have some way of expressing layout semantics that CSS failed to do until very recently. And they were "responsive" to resizing out of the box, if you wanted them to be.
CSS appeared after native apps already had layout/geometry managers that understood how to deal with grids, fixed layouts, changing display sizes, etc. Most of them I've used have some way of expressing layout semantics that CSS failed to do until very recently. And they were "responsive" to resizing out of the box, if you wanted them to be.
I agree with this although I maybe just haven't hit android GUI understanding yet. At mininum let me convert HTML+CSS to and android compatibility view or something.
DSSSL is actually not that dead. Postgres documentation was built with use of DSSSL until 2017. https://github.com/postgres/postgres/blob/REL9_6_STABLE/doc/...
Sounds kinda dead then.
I strongly believe that we're currently in the early stage of the same cycle with localization formats.
The most popular ones, like gettext, xliff, .properties are very limited, while the most sophisticated one - MessageFormat - is stopping a few steps short of having all needed capabilities and is very hard to read/write by hand.
I'm very excited for the next 3-5 years where I believe we'll see more development in this field and hopefully we'll end up with a good equivalent of CSS for Web Localization.
Full disclosure: I work on a project that my team believes to be a good contender for that - Project Fluent ( http://projectfluent.io/ ) I also work within TC39 on ECMA402 on APIs that will make coming up with new localization APIs much easier (PluralRules API, language negotiation and selection etc.).
The most popular ones, like gettext, xliff, .properties are very limited, while the most sophisticated one - MessageFormat - is stopping a few steps short of having all needed capabilities and is very hard to read/write by hand.
I'm very excited for the next 3-5 years where I believe we'll see more development in this field and hopefully we'll end up with a good equivalent of CSS for Web Localization.
Full disclosure: I work on a project that my team believes to be a good contender for that - Project Fluent ( http://projectfluent.io/ ) I also work within TC39 on ECMA402 on APIs that will make coming up with new localization APIs much easier (PluralRules API, language negotiation and selection etc.).
> I strongly believe that we're currently in the early stage of the same cycle with localization formats.
I was looking into this recently and I'm amazed how many different but very similar formats there are. For example, Django uses gettext, JavaScript has several different JSON formats (e.g. i18next, polyglot) and Go has its own JSON/TOML/YAML format. Each format seems so similar I don't understand why they didn't use an existing one. Usually you want your translators to use a web interface to edit translations so different formats make this troublesome.
I was looking into this recently and I'm amazed how many different but very similar formats there are. For example, Django uses gettext, JavaScript has several different JSON formats (e.g. i18next, polyglot) and Go has its own JSON/TOML/YAML format. Each format seems so similar I don't understand why they didn't use an existing one. Usually you want your translators to use a web interface to edit translations so different formats make this troublesome.
I am very interested in the s-expression stylesheet format. I think it would be preferable for me at least to CSS, especially the code for alternating rows; I imagine that people write programs in this language might have well done away with the need for CSS preprocessors that we have today. This also makes me ask a question - why are there no Lisp-like CSS preprocessors?
I am reminded of the proposal to markup webpages with s-expressions rather than XML, though there are packages available (actually just macros) in CL that let you write websites this awy.
I am reminded of the proposal to markup webpages with s-expressions rather than XML, though there are packages available (actually just macros) in CL that let you write websites this awy.
Just think: were HTML replaced with SXML, JavaScript with Common Lisp & CSS with something like LASS, we might have pages which look like this:
(html
(head
(style (let ((bg #x0088ee)
(fg #x00ee88))
(body (background bg)
(foreground fg))
(body.inverted (foreground fg)
(background bg))))
(script (defun invert ()
(with-slots (class-list)
(get-element-by-tag document 'body)
(setf class-list
(if (find 'inverted class-list)
(remove 'inverted class-list)
(cons 'inverted class-list)))))))
(body
(button (@ (on-click (invert))) "Click me")
(p "This is some text.")))
Be careful what you wish for. The fact that CSS can be so easily declaratively analyzed is the reason why it can be made reasonably fast at all. CSS has some key restrictions—for instance, that attributes always inherit top-down and never bottom-up—that makes it amenable to parallelism (which is no longer a theoretical concern, as parallel CSS implementations are starting to ship). Adding a full programming language would have the potential to make styling much slower than it already is.
> as parallel CSS implementations are
Is someone else outside mozilla ready to ship a parallel CSS engine any time soon ?
Is someone else outside mozilla ready to ship a parallel CSS engine any time soon ?
Not that I'm aware of.
You might want to check out Garden [0], a meta-css library for clojure(script).
[0] https://github.com/noprompt/garden
[0] https://github.com/noprompt/garden
There is also LASS[1] for Common Lisp. You use it either as a library for generating CSS, or as a standalone preprocessor.
[1]: https://github.com/Shinmera/LASS
[1]: https://github.com/Shinmera/LASS
"Rather than using repeated selectors to handle the nesting, PWP used a parenthesis system which is evocative of the indentation systems used by languages like Stylus and SASS which are preferred by some developers to CSS today.." Heh. So, do nested parentheses remind you of any other languages?
I kinda dig the current CSS in JSX hype.
I think I never have been that fast building UIs.
I get the convenience of writing inline-styles like HTML attributes and not a style string and in the background it gets compiled to CSS classes, with deduplication and everything.
Since Flexbox and CSS-Grid, most CSS frameworks I used in the past also don't have much value for me anymore.
I think I never have been that fast building UIs.
I get the convenience of writing inline-styles like HTML attributes and not a style string and in the background it gets compiled to CSS classes, with deduplication and everything.
Since Flexbox and CSS-Grid, most CSS frameworks I used in the past also don't have much value for me anymore.
I'm sure there's an article out there about "languages that almost became html". Anyone have a link to it?
This is not quite what you want but The History of the Web is a newsletter that does stories on various topics. Here's the site with archives: http://thehistoryoftheweb.com/
> It also includes one of the best nonsensical infographics to ever exist on the web
While technically flowcharts could be defined infographics in the broad/original sense, I still don't see why this is so nonsensical. It is obviously targeted to someone who knows the subject and terminology involved, but apart from that it looks OK to me.
/nitpick
While technically flowcharts could be defined infographics in the broad/original sense, I still don't see why this is so nonsensical. It is obviously targeted to someone who knows the subject and terminology involved, but apart from that it looks OK to me.
/nitpick
Surprised it didn't talk about how the box models worked orginally. IE 5 did the box model differently including margin and padding in the width. Made CSS very difficult to use.
It was wrong, and required stupid workarounds, but it was better.
I hated those old IEs as much as anybody, but I admitted even back then that IE's broken box model was much saner. We had to do stupid things with widths and percentages just to make the browsers that worked correctly work.
The fact that everybody uses box-model: border-box now is pretty much an admission that the original box model was a bad idea.
I hated those old IEs as much as anybody, but I admitted even back then that IE's broken box model was much saner. We had to do stupid things with widths and percentages just to make the browsers that worked correctly work.
The fact that everybody uses box-model: border-box now is pretty much an admission that the original box model was a bad idea.
Agree with everything... except the idea that IE was wrong in this case. I hated Microsoft as much as anybody during the overlong era of IE6, but even back then, I had to admit that the W3C were the ones who got the box model wrong.
The funny thing is that I've never heard any rationale -- much less a convincing rationale -- for the choice in the spec.
The funny thing is that I've never heard any rationale -- much less a convincing rationale -- for the choice in the spec.
Well only wrong in that they weren't following the W3C box model spec. That single inconsistency was responsible for at least 50% of the extra work caused by IE.
Edit: I meant box-sizing.
You can switch to that model using "box-sizing: border-box", and thats the default for bootstrap and a lot of frameworks these days. I actually much prefer that to what ended up being the default, but maintaining a stylesheet that had to account for the two different models was a big pain.
Unfortunately the idea that you would just restyle the content a bit as needed and viola website is redesigned never really worked. At any point in history. I just wish you could get through a redesign without learning three new languages nowadays.
Yes in my experience, we got the worst of both worlds.
We have people with a religion of separating style from content, so they introduce the complexities necessary to do that. But because it is merely a religion, they don't actually do it in a way that makes it possible to actually change styling just through CSS.
We have people with a religion of separating style from content, so they introduce the complexities necessary to do that. But because it is merely a religion, they don't actually do it in a way that makes it possible to actually change styling just through CSS.
Yes, and what's particularly irrational is that CSS found it necessary to invent a new key/value syntax.
Then developers wanted to make sense of the mess by declaring "markup is for content, while CSS is for presentation". But the "separation of concerns" argument is merely an after-the-fact justification for the existence of the HTML/CSS separation. In the original markup language concept, attributes were specifically introduced to hold presentation attributes, while content was encoded as element content.
The content/presentation dichotomy doesn't hold water in a philosophical sense either. Many text pieces (such as poems, but also modern text forms) require special presentation. But what was particularly absurd is to invent a new syntax for key/values.
The content/presentation dichotomy doesn't hold water in a philosophical sense either. Many text pieces (such as poems, but also modern text forms) require special presentation. But what was particularly absurd is to invent a new syntax for key/values.
> We have people with a religion of separating style from content, so they introduce the complexities necessary to do that.
Yeah...I've seen lots of code review arguments where one developer refuses to alter the HTML to make the styling easier (e.g. order of elements, wrapping elements in certain ways) and then the CSS styling requires all sorts of complex tricks. If Google or screen readers won't see any difference, striving to separate styling from content like that is a waste of time in my opinion and you should make compromises. People complain about e.g. Bootstrap's "text-center" and column classes as well because they're not semantic but they can save time when used appropriately.
Yeah...I've seen lots of code review arguments where one developer refuses to alter the HTML to make the styling easier (e.g. order of elements, wrapping elements in certain ways) and then the CSS styling requires all sorts of complex tricks. If Google or screen readers won't see any difference, striving to separate styling from content like that is a waste of time in my opinion and you should make compromises. People complain about e.g. Bootstrap's "text-center" and column classes as well because they're not semantic but they can save time when used appropriately.
I agree. And if you view HTML as presentation there is absolutely nothing wrong with embedding styles. The CSS separation only makes sense if you consider HTML data, which some people might do but I think is misguided.
Honestly it is never so easy even in LaTeX. There is always some kind of adjustment that needs to be made, because real separation between style and content is really hard to achieve in general.
Check out tachyons and you'll never use anything else again:
http://tachyons.io/
http://tachyons.io/
If you want more information, somebody wrote a PhD thesis on this very topic http://wiumlie.no/2006/phd/
Minor nitpick: "As you may know, HTML as we know it was originally based on a pre-Internet language called SGML."
It's "pre-world-wide-web". The internet was already alive and quite busy in the 80s.
It's "pre-world-wide-web". The internet was already alive and quite busy in the 80s.
I wonder if any of the alternative languages, in contrast to CSS in the beginning, did provide a simple way to center content along the x and y axes.
If CHSS with its percentage ownership had become CSS desk flipping would have been invented way earlier.
Most developers I knew in person didn't care about CSS or didn't 'get' it. Things have come a long way since, in term of browser compatibility and tooling, but it always feels like a large portion of people who do web dev don't 'get' the web, for example, I am always surprised at the usage of frameworks such as Bootstrap in tech teams, you're basically redefining what you want your elements to look like using a combination of class names, which means you lose style separation and selectors. It's like a circle repeating itself.
People will always want to use the web to build their 'visual' or 'app' to look like they want to just as if they are designing a business card, but the web at its core is a web of knowledge, for it to be linked by other pages, browsed by bots, and is worth little without traffic or way to catalog that knowledge in the grand scheme of things. And that's why a bunch of people like me have always been pushing to have a semantic definition of the knowledge in your document, separate, and to be considered before its presentation.
Now we can make rich apps, and get pretty much pixel exact renders, but all the underlying philosophy remains: accessibility, context, semantics, and still should come before the styling in order of priority, and all the bells and whistles should ideally be implemented as an augmentation of the semantics.