I started doing web development around 1999 or a bit earlier, NotePad.exe was my first text editor. By 2003 I was building websites in strict XHTML and CSS, and always avoided using presentation markup, OpenWeb.eu.org was one of my favorite resources, along with W3C specs.
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.
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.
> 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!
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.
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.
> 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":
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.
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).
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."
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.
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.
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.
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 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.
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.
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'.
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.
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 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.
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.
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.).
> 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 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.
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.
"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 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.
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.
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.
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.
[+] [-] tarikjn|8 years ago|reply
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.
[+] [-] adrusi|8 years ago|reply
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.
[+] [-] dspillett|8 years ago|reply
> 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!
[+] [-] sopooneo|8 years ago|reply
[+] [-] coldtea|8 years ago|reply
It being a broken technology, used for tasks it wasn't until recently even remotely suited for (layout) probably played a role to that.
[+] [-] reitanqild|8 years ago|reply
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.)
[+] [-] barrkel|8 years ago|reply
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.
[+] [-] lkrubner|8 years ago|reply
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.
[+] [-] frik|8 years ago|reply
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
[+] [-] tannhaeuser|8 years ago|reply
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."
[+] [-] tarikjn|8 years ago|reply
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.
[+] [-] inopinatus|8 years ago|reply
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.
[+] [-] olavk|8 years ago|reply
[+] [-] Fifer82|8 years ago|reply
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.
[+] [-] blauditore|8 years ago|reply
[+] [-] girishso|8 years ago|reply
".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.
[+] [-] otto_ortega|8 years ago|reply
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.
[+] [-] zackbloom|8 years ago|reply
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'.
[+] [-] pjmlp|8 years ago|reply
[+] [-] barrkel|8 years ago|reply
[+] [-] coldtea|8 years ago|reply
Because in other domains sanity prevailed.
[+] [-] spondyl|8 years ago|reply
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.
[+] [-] tyingq|8 years ago|reply
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.
[+] [-] limeblack|8 years ago|reply
[+] [-] kelvich|8 years ago|reply
[+] [-] smitherfield|8 years ago|reply
[+] [-] zbraniecki|8 years ago|reply
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.).
[+] [-] seanwilson|8 years ago|reply
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.
[+] [-] ue_|8 years ago|reply
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.
[+] [-] pcwalton|8 years ago|reply
[+] [-] minikomi|8 years ago|reply
[0] https://github.com/noprompt/garden
[+] [-] zeveb|8 years ago|reply
[+] [-] juki|8 years ago|reply
[1]: https://github.com/Shinmera/LASS
[+] [-] ajarmst|8 years ago|reply
[+] [-] k__|8 years ago|reply
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.
[+] [-] 13of40|8 years ago|reply
[+] [-] jccalhoun|8 years ago|reply
[+] [-] gattilorenz|8 years ago|reply
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
[+] [-] limeblack|8 years ago|reply
[+] [-] freshyill|8 years ago|reply
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.
[+] [-] lojack|8 years ago|reply
[+] [-] 65827|8 years ago|reply
[+] [-] adrianratnapala|8 years ago|reply
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.
[+] [-] Viper007Bond|8 years ago|reply
[+] [-] cwmma|8 years ago|reply
[+] [-] bhaak|8 years ago|reply
It's "pre-world-wide-web". The internet was already alive and quite busy in the 80s.
[+] [-] amelius|8 years ago|reply
[+] [-] xxs|8 years ago|reply
[+] [-] odammit|8 years ago|reply