Re: Download navigation UX

On 7/8/20 1:04 PM, Magnus Hagander wrote:
>
>
> On Wed, Jul 8, 2020 at 5:56 PM Dave Page <dpage(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)org>> wrote:
>
>
>
> On Wed, Jul 8, 2020 at 4:16 PM Magnus Hagander <magnus(at)hagander(dot)net
> <mailto:magnus(at)hagander(dot)net>> wrote:
>
> We *already* have the requirement to keep "certain DOM Ids"
> unique -- we use it for CSS. And I really don't see that as any
> bigger problem than keeping the filename of the JS file unique
> Do you have an example? I can't see any obvious ones. Ideally we
> should be using classes for CSS imho, rather than IDs anyway imho
> (and we really shouldn't be using IDs in a way that requires them to
> be unique across pages that may well be unknown to the casual hacker
> - that would be a real maintenance headache).
>
> Hmm. Looking at it it's fewer than I thought, because we have tons of
> CSS rules that aren't actually in use. But if you want a recent example,
> release-notes. And the navigation.

Some of this was done as part of the "great style conversion of 2018" to
try to keep things from breaking too much. The other major one is in our
documentation, to keep the documentation styles separate from the main
site styles.

> What would be the reason to use classes for things that are only
> supposed to appear once? I thought the entire point of classes vs ids in
> the rules are classes for things that there can be more than one of, id
> when it's a unique identifier.

The trend I've seen in web development is that classes are used to
invoke style, while IDs are used to invoice anchors, or to "namespace" a
set of styles.

I've seen this a lot in documentation.

In other words, pretty much anything involved with styling is using a
class. It is what it is.

> Having the separate files is certainly an extra download and
> slightly less cacheable (for a few bytes of code), but I
> think that's outweighed by the additional complexity and
> code that having a single file would require.
>
>
> It's really more the latency than anything else. I'm pretty
> strongly on the side of thinking the cost of that is higher than
> the small amount of complexity -- I really don't think it would
> be much. But no, I'm not strongly *enough* on that side to
> actually try to produce proper metrics to prove it :)
>
>
> The code complexity isn't that much I grant you. We'd have to wrap
> something like the following around each event listener setup:
>
> var elem = document.getElementById("elementID");
> if (elem) {
>     // setup listener 
>
> }
>
>
> Yeah, or the same for classnames if that makes you happier :)

From a maintenance perspective, I'd vote for "less files" and just
clearly comment what each JS block is doing in the one file. I think
it's fairly simple to gate the event listeners. And if it's a pattern
we're using a lot, we can write a helper function to do so ;)
> I don't really consider that very complex. We already inject jquery on
> all pages, so you could use that to simplify it even more. But I would
> suggest not doing that -- it would be nice to at some point be able to
> remove jquery as a dependency, so iet's not dig that hole deeper.

I'm ok with this. The other pattern I've seen in web development is more
things going native JavaScript (particularly because what's supported in
browsers is way more sophisticated now), sometimes coupled with
"transpilers" or the like, or using a framework.

> However the cognitive complexity for the maintainer/developer of
> ensuring IDs are unique across different pages is *much* higher.
>
> I still don't see how those are very high. What's the likelihood of
> using an id like "yumdownloads" (or similar) on a page that is unrelated
> to yum? I'd say that's pretty much zero.

Yeah, I think the probability of this being an issue is low.

Jonathan