4 ms·

Out of interest, what are the reasons you don't want to be able to 'render everything we've ever seen'?

ChuckMcM 13y ago
It is the complexity tradeoff. I built a really simple widget using an LCD which you can send "standard" HTML (as in the base DTD) over a serial line. Built using an Cortex M3, a SPI connected LCD, basically libft2, libpng, and a minimal drawing package. If you look at LED signs, this is one of those, but with a screen instead of LEDs and a more 'standard' layout engine. Three fonts, (serif, sans, fixed), three weights (normal, bold, italic), old skool HTML (no css, no script) and a simplified img tag. The most complex thing in the code is the table rendering code. Basically if you want to throw up a quick status display, it can do quite a bit. So I thought I would update it to HTML4, maybe a bit of ECMA script for animations. Did a couple of runs at it and found most existing code had a bunch of stuff in it so that it could render "commonly occurring, but non-standard" HTML pages. In order to fit in a limited memory foot print system I was ripping things out left and right but stuff has more side effects than Cymbalta. So I tabled the project. Starting from the premise of rendering "just the stuff we promise we can render" allows me to add stuff until I run out of memory and then stop.
coldtea 13y ago
Added complexity and baggage for his use case?
danudey 13y ago
I worked for a medical software company which had to deal with incoming digital images (DICOM) from all kinds of manufacturers (Siemens, GE, Philips, and tons of other smaller players). I once heard one of our lead developers say that 80% of the code we wrote was to work around problems in everyone else's implementations. The DICOM format has a bunch of predefined fields and supports custom fields that manufacturers can use, but a lot of manufacturers would, for no reason I could figure out, use fields incorrectly a surprising amount of the time. They would store one of the most basic pieces of information in the wrong field, and then store that data nowhere, or put it in a custom field, or store it in the wrong format, etc. Enough manufacturers doing 95% of things right and 5% of things wrong, making everyone else jump through hoops to handle their broken behaviour, and suddenly your code grows massively. Sure enough, we had to write an entire system for remapping fields from certain machines so that incoming data from broken implementations would be somehow magically coerced into being correct (either by simply copying data over to fields, or more advanced post-processing). The less time browsers spend wondering what to do with inherently, irredeemably broken HTML, the faster they can render content which actually does work properly. Unfortunately, that only works in controlled environments, like store kiosks, intranets, etc. Otherwise you end up choking on the 95% of the content which is only 5% broken.
- cpeterso 13y ago
  Your story is a perfect example of the dark side of Postel's law: "Be conservative in what you send, be liberal in what you accept." The people who care about writing software that Just Works™ end up maintaining software that is crushed under its own gravity. :)
  - nnethercote 13y ago
    I think the wisdom of Postel's law is questionable at best.
    - hyperpape 13y ago
      Apparently what we think of as Postel's law is a bastardization. http://erlang.org/pipermail/erlang-questions/2014-March/078195.html http://erlang.org/pipermail/erlang-questions/2014-March/0781....

It is the complexity tradeoff. I built a really simple widget using an LCD which you can send "standard" HTML (as in the base DTD) over a serial line. Built using an Cortex M3, a SPI connected LCD, basically libft2, libpng, and a minimal drawing package. If you look at LED signs, this is one of those, but with a screen instead of LEDs and a more 'standard' layout engine. Three fonts, (serif, sans, fixed), three weights (normal, bold, italic), old skool HTML (no css, no script) and a simplified img tag. The most complex thing in the code is the table rendering code. Basically if you want to throw up a quick status display, it can do quite a bit. So I thought I would update it to HTML4, maybe a bit of ECMA script for animations. Did a couple of runs at it and found most existing code had a bunch of stuff in it so that it could render "commonly occurring, but non-standard" HTML pages. In order to fit in a limited memory foot print system I was ripping things out left and right but stuff has more side effects than Cymbalta. So I tabled the project. Starting from the premise of rendering "just the stuff we promise we can render" allows me to add stuff until I run out of memory and then stop.

coldtea 13y ago

Added complexity and baggage for his use case?

danudey 13y ago

I worked for a medical software company which had to deal with incoming digital images (DICOM) from all kinds of manufacturers (Siemens, GE, Philips, and tons of other smaller players). I once heard one of our lead developers say that 80% of the code we wrote was to work around problems in everyone else's implementations. The DICOM format has a bunch of predefined fields and supports custom fields that manufacturers can use, but a lot of manufacturers would, for no reason I could figure out, use fields incorrectly a surprising amount of the time. They would store one of the most basic pieces of information in the wrong field, and then store that data nowhere, or put it in a custom field, or store it in the wrong format, etc. Enough manufacturers doing 95% of things right and 5% of things wrong, making everyone else jump through hoops to handle their broken behaviour, and suddenly your code grows massively. Sure enough, we had to write an entire system for remapping fields from certain machines so that incoming data from broken implementations would be somehow magically coerced into being correct (either by simply copying data over to fields, or more advanced post-processing). The less time browsers spend wondering what to do with inherently, irredeemably broken HTML, the faster they can render content which actually does work properly. Unfortunately, that only works in controlled environments, like store kiosks, intranets, etc. Otherwise you end up choking on the 95% of the content which is only 5% broken.

cpeterso 13y ago
Your story is a perfect example of the dark side of Postel's law: "Be conservative in what you send, be liberal in what you accept." The people who care about writing software that Just Works™ end up maintaining software that is crushed under its own gravity. :)
- nnethercote 13y ago
  I think the wisdom of Postel's law is questionable at best.
  - hyperpape 13y ago
    Apparently what we think of as Postel's law is a bastardization. http://erlang.org/pipermail/erlang-questions/2014-March/078195.html http://erlang.org/pipermail/erlang-questions/2014-March/0781....