Vivaldi Forum mod

[LonM]

It seems that the Vivaldi forum has two elements with an id of "main-nav". Not only is the off-spec with regards to HTML, it makes things very difficult to mod

[pafflick]

@LonM And what's wrong with using something like .menu-section-list #main-nav and #submenu #main-nav (except for the semantics)?

[LonM]

@pafflick according to The Specification,

the id attribute value must be unique amongst all the IDs

[pafflick]

@LonM I explicitly said "except for the semantics". If it works, then even if it's wrong, I think you can live with that?

[LonM]

@pafflick I missed the last part

Yeah, it works... but if we don't have semantics, then do we really have anything? Is life just a meaningless void full of duplicate DOM identifiers?

[pafflick]

@LonM said in Vivaldi Forum mod:

Is life just a meaningless void full of duplicate DOM identifiers

Perhaps it is... Adapt. Evolve. Survive. These are the three core principles of every HTML modder.

[TbGbe]

@pafflick said in Vivaldi Forum mod:

If it works, then even if it's wrong,

As a non-coder, isn't a coding which breaks the specification an indication of an HTML parser bug?

[LonM]

@TbGbe HTML5 is different from XHTML. XHTML was supposed to be a super-strict upgrade to HTML which wouldn't tolerate any errors. This never ended up panning out, and HTML5 took over instead. HTML5 is supposed to allow the document to render as a best effort.

So, parsers in browsers tend to be tolerant of errors, which is fine in principle, but they don't put an error message in the console, which is less useful as the only way a dev can see a problem is by using a validator and even then not all validators will run JS which won't catch errors created during runtime.

I think web development in general may have missed a trick by not going for strict validation.

[burbuja]

@LonM Hi, I think the forum pages do not exist in reallity, they are composed by php or someghing, so that similar bugs like multiple ids are difficult to find. I really loved the super strict xhtml 1.1

[LonM]

Does anyone familiar with the mod know what the purpose of the window.addEventListener('popstate') listener is in mods.js? It fires when the user presses the back button in their browser, but never fires when they navigate somewhere (i.e. the forum does a pushState).

Is there a way to do something programatically after a navigation is complete, or do we just have to rely on click listener as a sort of polling backstop?

[luetage]

@LonM Popstate is for history changes, forward and backward.

[luetage]

@LonM
@luetage said in Vivaldi Forum mod:

Also, related to this: If any of you have programming experience and would like to help with this. It would be great to find a solution to register history changes triggered by page navigation and infinite scroll. I looked a bit into it, but only managed to register history back/forward changes so far. The existing code can be found in mods.js. Implementing and registering further history changes could potentially make the code a bit more efficient and make everything work with infinite scroll.

I asked for help regarding this ages ago. I couldn't get navigation to work, because Vivaldi Forum uses AJAX to dynamically change the content of the page. This is hard to register with javascript and the few solutions I found on stackoverflow all didn't seem to work well. The click handling doesn't use much resources, but it isn't pretty.

[Rexfahrer]

@luetage On your request:

Please feel free to comment on anything which does not fit your expectations.

Edit: Well, they did not fit my own expectations. This is a new version, because I was unsatisfied with the transparent edges of the letters:

[luetage]

Good job, the images are looking good, especially the actual logos. But the original Vivaldi text seems to be a little bit more filigree, or thinner. Especially the V & A seem to have moved closer. It's also a deeper black now. Maybe both white and black could be a bit more toned down.

standard logo/black/white

As said they look fine though without direct comparison and I wouldn't say they look worse than the original, just different. We can as well keep them like that.

[Rexfahrer]

@luetage Voila: Corrected letter spacing and thickness, and gray instead of black and white:

And as a bonus : logo-white.png with white text which imho looks better then the grey text:

[luetage]

@Rexfahrer Perfect, thickness and spacing looks good, and yeah, let's go with the white one. Thank you very much. Some upvotes for Rexfahrer please

[LonM]

I have been testing adding a "Search category" button, which would act similar to the button at https://forum.vivaldi.net/category/113/feature-requests

Basically, it exists in the header and you can use it to directly search the category you're in (it will also select it's children, too). I hate clicking search only to find I then need to remember where I was and re-select the categories in that long list.

As for looking for page loads, you can detect when the forum goes into "ajax" mode, and luckily it appends a CSS class when it does this. An example of how to do this is at: mods.js:113-114

[luetage]

@LonM Observing the class change generally works, but it doesn't trigger on infinite scroll. What AJAX does too is create a history entry on navigation, therefore I wanted to listen for this initially. It also changes the hash, but I didn't get it to work. The hashchange would seem promising though. I believe we probably could get it to work with the webnavigation api, but I don't want to introduce a new permission to the extension…

As it stands the click at least updates infinite scroll when you trigger it, so I don't think it makes much sense changing to the mutation observer.

About the extra search, personally I don't like the second entry and I wonder how useful it really is. You would first have to navigate to the category you want to search and it could be argued it's equally fast to just pick the category in search instead of navigating.

[LonM]

@luetage Ah, I have the forum paginated, so hadn't considered infinite scroll.

My intent with the search this category wasn't to replace the big menu in search, it was more as a shortcut so that if you're already in a category and wanted to search it, you could do so without having to find and select the category again.

[luetage]

@LonM I understand that, but I think this singular case doesn't warrant a button in navigation which doubles the already existing button. Both are a link to the same site. We could exchange your functionality with the existing one, but then you would have to readjust the search when you don't want to search the category you're already in, or you would have to first visit the category you want to search. And what if I want to search a user instead?

The button introduced in the feature request category makes sense, because you will only see it, if you intend to post a feature request or look for a specific feature; and it's in the content.