For example, when a process implies a conversion according to the contract/convention, but we know that this conversion may be not the expected result and the input may be based on semantic misconceptions. E.g., assemblers and contextually truncated values for operands: while there's no issue with the grammar or syntax or intrinsic semantics, a higher level misconception may be involved (e.g., regarding address modes), resulting in a correct but still non-functional output. So, "In this individual case, there may be or may be not an issue. Please, check. (Not resolvable on our end.)"
(Disclaimer: I know that this is a very much classic computing and that this is now mostly moved to the global TOS, but still, it's the classic example for a warning.)
I'd suggest a simple test: remix menu items and icons and test, if this has significant impact on usability. If not, the icons are just arbitrary decoration and ultimately add clutter.
Referring to the examples provided in the article, I'd suggest that the impact on the Safari app menu should be minimal (so these are non-functional icons), while the impact on the Move & Resize submenu would be devastating and should result in confusion (so these are essential).
If you can remix with minimal impact, don't do icons. (In the case of the app menu, these are apparently meant to add structure, which is already established by other means like menu separators, so you have now two – or, including indentation, three – systems of structure and visual hierarchy that are fighting each other.)
Moreover, if you put icons everywhere, you're forgoing the facility to convey state, like active state checkmarks, since these, instead of standing out and signalling change, would be just drowned in the decorative clutter. (So what's next? Add color and/or animation, like swirling checkmarks?) And this, BTW, is also why the icons in the Move & Resize menu are effective: they are conveying and illustrating state (in terms of a preview), while most of the other menu icons (mostly referring to activities) do not. So, as a rule of thumb: icons referring to state may be useful and even desirable, while icons referring to activities are probably better left out. (And, if you feel the need for something like bullet points to mark your most important menu items, there's probably a deeper problem with your menu structure.)
Hum, table cells provide the max-width and images a min-with, heights are absolute (with table cells spilling over, as with CCS "overflow-y: visible"), aligns and maybe HSPACE and VSPACE attributes do the rest. As long as images heights exceed the effective line-height and there's no visible text, this should render pixel perfect on any browser then in use. In this case, there's also an absolute width set for the entire table, adding further constraints. Table layouts can be elastic, with constraints or without, but this one should be pretty stable.
(Fun fact, the most amazing layout foot-guns, then: Effective font sizes and line-heights are subject to platform and configuration (e.g., Win vs Mac); Netscape does paragraph spacing at 1.2em, IE at 1em (if this matters, prefer `<br>` over paragraphs); frames dimensions in Netscape are always calculated as integer percentages of window dimensions, even if you provide absolute dimensions in pixels, while IE does what it says on the tin (a rare example), so they will be the same only by chance and effective rounding errors. And, of course, screen gamma is different on Win and Mac, so your colors will always be messed up – aim for a happy medium.)
Oh good times, the screen gamma issue got me many times back then, as I was the super odd kid on a Mac in the late 90's (father was in education). I'd pull my beautify crafted table-soup site up on a friends PC later and wonder why all the colors were all wacky!
Well, having a platform agnostic runtime, you could throw arbitrary code at, was potentially a great deal. It was one of the founding concepts for ARPANET, which never took off, since nobody wanted to run foreign code from the network on their machines. For a platform agnostic runtime, OO may have seemed to fit well, by encapsulating data, handlers and logic into interacting objects. (This is close to the original use case for OO as described by Alan Kay.)
Fun fact: Java was also renamed from formerly Oak.
It's kind of funny to see how the endorsements were talking about rich multimedia integration, when your output options with JavaScript 1.0 were: writing into a textarea, writing into a form input field, or setting the state of other form elements (like checkboxes or select elements) – that's your rich multimedia experience!
Of course, there was the infamous `document.write()`, when the document was loading and the document stream was still open, but this was more of a hack than an interaction model.
Some seems to be server-side (LiveWire), as well, which was a Netscape product long before Node.js, but I'm not sure if this was already available, then. (When was the Netscape Enterprise server launched?)
I'm also not too sure, if LiveConnect (the connection between JS and Java applets and vice versa) was already a thing, when JavaScript was announced. (I think, this came a little later.)
Edit: I've a Netscape JavaScript book from when this was still in beta. (My first reading on the subject.) It does mention applets on a single page and that you may address them per ID via LiveConnect in a single sentence. So this was already implemented, but it wasn't advertised prominently. The book is all about form based examples.
(The applications in this book were the same that were demoed as showcase applications by Netscape on their website – and probably represent a significant part of what these voices reacted to.)
My memory is that around '98 people were falling over themselves to figure out how to wire up "components" made of applets. I think that stopped being a thing when people figured out SpyGlass/IE didn't use the same techniques to wire applets as Netscape. So props to you Microsoft, you made my life irritating for multiple decades (don't get me started about 1990 when I was a beta tester for Microsoft C 5.0.)
I remember using Netscape Enterprise Server suite, but didn't realize it had a JS engine in it. I do remember Rhino from a little later (though the wikipedia says it emerged in the late 90s.) And I have relatively horrible memories of the Netscape guys integrating the Visigenic ORB in both the enterprise server and Navigator. I wonder if Rhino was what they stuffed into NES/iPlanet/Sun ONE.
I think, you're mistaking I.P. and creative effort. Certainly, there must be a reason for people reading, even searching for this stuff, beyond the mention of a well-protected trademark.
So, because of certain tech patents, patents and IP are bogus in general? What's the point, then?
(Meaning, if we're making generalisation from worst examples a virtue, there will be hardly an argument left. E.g., as there are buggy programs, LLMs are just yet another bug.)
reply