9 ms·

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

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.

sopooneo 9y ago
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.
- exergy 9y ago
  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.
  - meric 9y ago
    Depends on the circle you're making the website for I guess.
    - kagamine 9y ago
      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.
      - spondyl 9y ago
        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.
        heeen 9y ago
        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
- flukus 9y ago
  After 2 decades browsers are finally evolving to add the icing themselves: https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
  - kagamine 9y ago
    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.
    - matthewmacleod 9y ago
      This feature has been in Safari and Firefox for ages, and is still there. It’s awesome.
    - hultner 9y ago
      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).
  - treerock 9y ago
    To my mind, Reader View removes most of the 'icing'.
  - cJ0th 9y ago
    ctrl + alt + r, btw ;)
- olavk 9y ago
  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"?
frik 9y ago
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/XHTML#XHTML_2.0 https://en.m.wikipedia.org/wiki/ECMAScript_for_XML https://en.m.wikipedia.org/wiki/ECMAScript_for_XML
- tannhaeuser 9y ago
  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.
  - coldtea 9y ago
    >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.
lkrubner 9y ago
> 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 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.
barrkel 9y ago
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.
- danielharrison 9y ago
  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.
- JohnBooty 9y ago
  The customer is more important than the engineering, as long as the engineering supports what the customer is trying to do That is, and always has been, pretty much the entire point of good engineering practices such as keeping one's markup as semantic as possible -- allowing us to deliver stuff more gooder and fastener to the customer. 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.
- wwweston 9y ago
  > 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.
coldtea 9y ago
>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.
- icedchai 9y ago
  Yep. CSS disgusts me. It was simpler doing layouts with tables.
  - olavk 9y ago
    Use display:table in CSS, it is exactly the same display model as tables, just disconnected from specific HTML elements.
dspillett 9y 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!
- lucideer 9y ago
  > 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.
  - marcosdumay 9y ago
    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.
    - lucideer 9y ago
      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.
reitanqild 9y ago
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.)
adrusi 9y ago
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.
- marcosdumay 9y ago
  > 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.
- Torgo 9y ago
  >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.

sopooneo 9y ago

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.

exergy 9y ago
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.
- meric 9y ago
  Depends on the circle you're making the website for I guess.
  - kagamine 9y ago
    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.
    - spondyl 9y ago
      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.
      - heeen 9y ago
        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
flukus 9y ago
After 2 decades browsers are finally evolving to add the icing themselves: https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
- kagamine 9y ago
  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.
  - matthewmacleod 9y ago
    This feature has been in Safari and Firefox for ages, and is still there. It’s awesome.
  - hultner 9y ago
    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).
- treerock 9y ago
  To my mind, Reader View removes most of the 'icing'.
- cJ0th 9y ago
  ctrl + alt + r, btw ;)
olavk 9y ago
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"?

frik 9y ago

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/XHTML#XHTML_2.0 https://en.m.wikipedia.org/wiki/ECMAScript_for_XML https://en.m.wikipedia.org/wiki/ECMAScript_for_XML

tannhaeuser 9y ago
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.
- coldtea 9y ago
  >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.

lkrubner 9y ago

> 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 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.

barrkel 9y ago

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.

danielharrison 9y ago
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.
JohnBooty 9y ago
The customer is more important than the engineering, as long as the engineering supports what the customer is trying to do That is, and always has been, pretty much the entire point of good engineering practices such as keeping one's markup as semantic as possible -- allowing us to deliver stuff more gooder and fastener to the customer. 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.
wwweston 9y ago
> 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.

coldtea 9y ago

>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.

icedchai 9y ago
Yep. CSS disgusts me. It was simpler doing layouts with tables.
- olavk 9y ago
  Use display:table in CSS, it is exactly the same display model as tables, just disconnected from specific HTML elements.

dspillett 9y 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!

lucideer 9y ago
> 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.
- marcosdumay 9y ago
  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.
  - lucideer 9y ago
    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.

reitanqild 9y ago

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.)

adrusi 9y ago

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.

marcosdumay 9y ago
> 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.
Torgo 9y ago
>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.