A few observations … and things I'd like to see fixed.



  • Topping the list would be the blasted mouse wheel... ctrl+mouse has been busted for zoom and keyboard only inhales upon the proverbial equine of short stature when you're not on a keyboard. Much less in this latest version I can't even seem to get the keyboard shortcuts to work for it. :/ In that same way, is there some way to TURN OFF the blasted "when the mouse wheel is over the tabs it switches tabs" garbage? It's annoying as hell when the tabs are in portrait. I've been playing with making my own changes, adding things like "close this tab and go to previous" and "close this tab and go to next" buttons and removing (well, hiding) the close button on the tabs, and reskinning things to just use native UTF-8 characters instead of the SVG for things like forward/back/etc, etc... [i](seriously, this would be SO much easier if you just used a webfont instead of SVG, probably be smaller too! SVG also sucks, there's a reason its creators -- Adobe and Microsoft -- dropped it like a hot potato a decade ago!)[/i]... but in the process I've been playing with the browser.html... and, well... you have this: [code] <meta charset="UTF-8"> <title>Vivaldi</title> <link rel="stylesheet" href="style/common.css">

    <div id="app">[/code] Even in HTML 5, there is no such thing as

    <div>-- DIV is NOT an "empty tag" by what the specification means. IF anything you should be logging a invalid tag every time there's a pageload.is not what the spec means by "empty" even though it is empty. The only tags that are valid for the /> close are area, base, br, col, embed, hr, img, input, link, and meta. Likewise you're using 5, just axe the XML closures altogether... But more confusing is your scripting load order -- putting them in HEAD delays their load even in a web app... If you load them in body the page (application) loads faster, and if like a good little doobie you were waiting for the dom to be built and only manipulating the DOM [i](basically not using innerHTML or document.write as the ECMA has been telling us for over a decade that idiocy like jQuery then pisses on from so on-high you'd think the Almighty just got back from a kegger)[/i] you could just load them flat... as once you are past any content markup in the HTML the scripts can start running immediately! I also think it would be nice if you standardized a "custom" directory for users to place their own style and scripts into, giving the option in the installer to copy over that directory and include the files, or perhaps a toggle as to whether to load them or not. (though dynamic script loading can be a PITA, no problem on the CSS front) This is what I'm running; maybe it's placebo, but it SEEMS to load faster. [code]<meta charset="utf-8"> <link rel="stylesheet" href="style/common.css"> <link rel="stylesheet" href="custom/custom.css"> <title>Vivaldi</title>[/code] Just a suggestion, it works as is, but that doesn't make it right. REAL shame your using that bloated "react.js" nonsense though. Makes trying to decipher much less work with the existing scripting a royal PITA. Particularly given some of the garbage it vomits up and has the cojones to call JavaScript... admittedly though I feel that way about most every "framework", "preprocessor" or other bits of bloated garbage that just result in using hundreds of k of scripting or CSS to do tens of K's job. But I was taught early on that if minification/obfuscation of your code actually gains you anything, there's something horrifyingly and terrifyingly wrong with your code. YMMV.</div>

    </div>



  • Oh, and silly question – you added that "app" div recently, and I'm wondering -- what are you doing with that DIV you couldn't just do on BODY? Just seems out of place.



  • 'Shadow, there is a 'user_files' subdirectory below the main vivaldi.exe installation directory that's used to hold the files for the <strong>< > Page Actions</strong> menu next to the Zoom slider:<br /><br /><em><drive>:<yourpath>\Application<version#>\resources\vivaldi\user_files</em><br /><br /><br /><br /><img src="http://i0.kym-cdn.com/photos/images/newsfeed/000/896/908/672.gif" />



  • @3Phase:

    'Shadow, there is a 'user_files' subdirectory below the main vivaldi.exe installation directory that has

    absolutely nothing to do with what I'm talking about. That's for stuff that changes specific pages.

    MY custom.css and custom.js change the UI… and I do't want them showing up in the panels as a "page action" -- since page actions cannot reskin the PROGRAM.

    Whole different thing.



  • Ah, but you left those caveats out of your manifest. :whistle:
    Attachments:



  • @3Phase:

    Ah, but you left those caveats out of your manifest. :whistle:

    Then why would they be in the main.html where they can't change the child webviews? :silly:



  • 'Shadow,

    I have no idea why! :D There are a lot of things that have changed as the browser has developed. Would you believe it used to take over a gigabyte to load and display only two Tabs and the Application and Data subdirectory structure has changed with different Snapshots? :ohmy:

    Think of an early production model with all the little streamers glued, screwed, welded or riveted all over the exterior for wind tunnel testing with the interior and some of the controls mocked up or missing.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.