4 ms·
That isn't _its_ feature. It belongs in a web browser as much as it belongs in Adobe Acrobat (although you could consider that a VM for executing untrusted cod
by nilved 10y ago
That isn't _its_ feature. It belongs in a web browser as much as it belongs in Adobe Acrobat (although you could consider that a VM for executing untrusted code, too -- heoh!)
If you want a VM for executing untrusted code, use a VM for untrusted code, don't shoehorn it into HTML, or PDF, or whatever. That makes zero sense.
- acdha 10y agoYou appear to be conflating a relatively uncommon personal belief with the natural order of things. There is a small subset of people who believe electronic documents should be limited to what's possible with paper with the addition of links, but the vast majority of users and implementers want features which are only possible with interactivity. Once that's the case, you're talking untrusted code execution and it absolutely has to be integrated because much of the value comes from working with the document rather than just linking to a separate program. PDF is a special case since there's similarly a considerable value in having things like forms, equations, graphs/illustrations, etc. being interactive but since Adobe has a stranglehold on the format, it was characteristically poorly designed, badly implemented, effectively unsupported, and you had to pay to use it. I would not draw conclusions from this other than avoiding Adobe-encumbered ideas. The other side of this position is forgetting how important network effects are. People did try to implement purer alternatives but they were always hindered by the need to deploy them first. The low-friction web model is extremely popular with users and any question of replacements or alternatives needs to fit into the gradual upgrade model of the web unless you can get Microsoft and Apple to ship it in the OS.
- deleted 10y ago[deleted]