4 ms·

I think I'd rather just manipulate HTML with Javascript. At least then I only have one problem, which is HTML with inline styles. No separate CSS file to main

I think I'd rather just manipulate HTML with Javascript. At least then I only have one problem, which is HTML with inline styles. No separate CSS file to maintain or CSS rule precedence to worry about.

encoderer 11y ago
You forgot the performance problem....
- dan1234 11y ago
  And anyone who wants to browse with JavaScript disabled…
  - tokenizerrr 11y ago
    People who disable features of their browser on purpose will always be getting a degraded experience. No way around that.
    - robin_reala 11y ago
      People have JS disabled without their intent. Corporate security standards, broken JS in CDN served libraries, mobile proxy browsers, the list goes on…
      - TeMPOraL 11y ago
        With the rate CSS is accumulating kludges and the fact that, when together with HTML5, it has already crossed the Turing-completeness threshold, I wonder how long it will take before companies start requiring browsers to disable subsets of CSS...
  - SquareWheel 11y ago
    I stopped worrying about those users years ago. Don't even bother with <noscript> anymore. It's 2015 and all browsers support JS these days. If you disable browser features then you really shouldn't be surprised when functionality breaks. The same would happen if you disabled CSS or images.
    - wwweston 11y ago
      Funny you should invoke turning off CSS and images -- a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options, or had their own custom style sheets, or weren't using a visual user agent (or even, for that matter, directing the user agent manually). A failure of function availability from turning off images or CSS is a failure of developers, not a failure of the platform or user agent. You can find sites even in 2015 that either straight up work or degrade gracefully when being browsed by Lynx (a browser that I don't think has seen even a dot-release update since 1999) because they were put together by thoughtful professionals who understand the platform. If you're trying to deliver an application that absolutely requires client side computation or specific browser APIs, you can have a pass for choosing the have your site not work without JS. If your site really is just a series of documents (either static or dynamically computed), though, there really isn't much of an excuse.
      - SquareWheel 11y ago
        >a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options In cases like this, wouldn't it make more sense to have that information available in an API? Once you've removed all styling and interaction, it seems like something that would work better as simply sending raw data, and letting the client decide what to do with it. Schema.org is a good example of how this would work with the modern web. Markup relevant data (eg. product ratings, movie times) and let the clients render it as desired. You can still provide CSS/JS for modern browsers. Seems a lot more elegant to me than designing pages to gracefully fallback when JS/CSS is missing, as that would seriously restrict design.
        wwweston 11y ago
        When you say "simply send raw data, and let the client decide what to do with it," you're more or less describing the original vision behind delivering markup before we got obsessed with instructions of one stripe or another to control visual presentation. The crucial question is probably what's considered "raw" -- or perhaps to talk more in terms of web-related philosophy, which media type you'd expect most user agents to be able to handle by default... and despite the (reasonable) popularity of JSON, the answer is pretty much HTML with some kind of microformat information embedded via attributes. In other words, the schema.org approach is arguably pretty much what you're supposed to do in order to design pages to gracefully fall back. I'm not sure why you might think those two concepts are at odds. :)

encoderer 11y ago

You forgot the performance problem....

dan1234 11y ago
And anyone who wants to browse with JavaScript disabled…
- tokenizerrr 11y ago
  People who disable features of their browser on purpose will always be getting a degraded experience. No way around that.
  - robin_reala 11y ago
    People have JS disabled without their intent. Corporate security standards, broken JS in CDN served libraries, mobile proxy browsers, the list goes on…
    - TeMPOraL 11y ago
      With the rate CSS is accumulating kludges and the fact that, when together with HTML5, it has already crossed the Turing-completeness threshold, I wonder how long it will take before companies start requiring browsers to disable subsets of CSS...
- SquareWheel 11y ago
  I stopped worrying about those users years ago. Don't even bother with <noscript> anymore. It's 2015 and all browsers support JS these days. If you disable browser features then you really shouldn't be surprised when functionality breaks. The same would happen if you disabled CSS or images.
  - wwweston 11y ago
    Funny you should invoke turning off CSS and images -- a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options, or had their own custom style sheets, or weren't using a visual user agent (or even, for that matter, directing the user agent manually). A failure of function availability from turning off images or CSS is a failure of developers, not a failure of the platform or user agent. You can find sites even in 2015 that either straight up work or degrade gracefully when being browsed by Lynx (a browser that I don't think has seen even a dot-release update since 1999) because they were put together by thoughtful professionals who understand the platform. If you're trying to deliver an application that absolutely requires client side computation or specific browser APIs, you can have a pass for choosing the have your site not work without JS. If your site really is just a series of documents (either static or dynamically computed), though, there really isn't much of an excuse.
    - SquareWheel 11y ago
      >a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options In cases like this, wouldn't it make more sense to have that information available in an API? Once you've removed all styling and interaction, it seems like something that would work better as simply sending raw data, and letting the client decide what to do with it. Schema.org is a good example of how this would work with the modern web. Markup relevant data (eg. product ratings, movie times) and let the clients render it as desired. You can still provide CSS/JS for modern browsers. Seems a lot more elegant to me than designing pages to gracefully fallback when JS/CSS is missing, as that would seriously restrict design.
      - wwweston 11y ago
        When you say "simply send raw data, and let the client decide what to do with it," you're more or less describing the original vision behind delivering markup before we got obsessed with instructions of one stripe or another to control visual presentation. The crucial question is probably what's considered "raw" -- or perhaps to talk more in terms of web-related philosophy, which media type you'd expect most user agents to be able to handle by default... and despite the (reasonable) popularity of JSON, the answer is pretty much HTML with some kind of microformat information embedded via attributes. In other words, the schema.org approach is arguably pretty much what you're supposed to do in order to design pages to gracefully fall back. I'm not sure why you might think those two concepts are at odds. :)