So today I’ve been working on adding a new feature in one of my apps that makes use of an HTML Viewer. The feature I’d like to add involves having section headings on the page “stick” to the top of the viewer until that section scrolls off the page, then have the next heading stick to the top of the page - similar to how the List View on an iOS app can do tricks with its headers.
At any rate, after futzing around with a few terrible jQuery-based solutions, I learned that a new standard in CSS3 is the position:sticky property, that does exactly what I need. The only problem is that it is not widely supported on most browsers. BUT - it IS supported on WebKit.
A few minutes later I had the feature behaving perfectly on OS X builds, which use the native WebKit-based Safari engine. Cheers, glee, and glitter in the air as I celebrated.
Then I tried it on Windows, where the only thing that seems to want to be sticky is the soda I spilled on that laptop keyboard years ago.
After nearly an hour of head scratching and puzzling, I learn that no matter how you select the “WebKit” option for the renderer of an HTMLViewer, on Windows it DOES NOT USE WEBKIT!
Note CEF 1 is a single-process implementation based on the Chromium WebKit API. It is no longer actively developed or supported.
We use CEF 1 (since CEF 3 with separate rendering processes has issues)
It will be reverted for 2.1
My mistake as I’m looking at the current check ins and thats newer than what was in r2 by several days
Theres a thread on the beta list about why this will happen
Basically CEF3 you can use “single process mode” and its slow as hell and is really meant for debugging purposes.
Using it in its default mode relaunches the main app over & over as it spawns rendering threads.
This obviously has issues for us.
So CEF1 WILL BE in use once R2.1 is released
It wasn’t “several years ago” that they ditched WebKit for Blink, it was just last year sometime, but it wouldn’t help you anyway. Not all WebKits are created equal, and the version of WebKit used by Chromium the version that Xojo has embedded in the past and the version they will embed once again in r2.1 does not support the position:sticky attribute you want. You will have to find another solution.
You may also want to check out this discussion: https://forum.xojo.com/conversation/post/104138
You can force Win32 to use the most modern version of IE installed (otherwise, it tends to default to IE8). If IE10 or 11 is installed and handles the sticky option, that might be a way to do it?
IE 11 won’t work. The only browser that supports position:sticky is Safari. (I think Firefox is planning to, or perhaps already does starting with a very recent version, but that’s irrelevant in a Xojo context.)
@Walter Purvis is correct - Chrome started using Blink back in April of last year, not several years ago. I stand corrected. He’s also right that the version of WebKit included in CEF1 does not support position:sticky.
Looks like I’ll have to mess with some jQuery solution after all.
WebKit even as one “project” is still not “webkit everywhere”.
The web is a mess this way and always has been.
You’d tag things for IE 6, 7 , 8 , 9 , 10, 11 then Firefox or Mozilla and Safari and well you know all this.
The best we could do is something like use CEF3 on OS X, Windows, and Linux then you’d have ONE engine. But it may still have differences between Windows, Linux & OS X (hopefully not many but )
But it would not have “browser specific tags” like you do with IE, Safari, etc.
It would all be CEF3
[quote=110211:@Norman Palardy]The best we could do is something like use CEF3 on OS X, Windows, and Linux then you’d have ONE engine. But it may still have differences between Windows, Linux & OS X (hopefully not many but )
That would be excellent. I think Xojo has potential to be the best possible platform for hybrid apps (native + HTML5). Every other extant option for wrapping a native application around a browser shell is pathetically weak (with the partial exception of Qt/WebKit), so I believe many developers would find Xojo attractive. But it really needs to have the same exact embedded browser engine on all three platforms; otherwise there is too much work involved (and quite possibly unresolvable incompatibilities) and the story is not compelling. I’m developing an application with Qt at the moment, for this exact reason, but obviously I would much rather be doing it in Xojo.
I recommend it, with some strong caveats. First, it’s not Xojo, it’s a whole new framework to learn, and you have to use C++, which is 5x times less enjoyable to use than Xojo Basic. (Did I type 5x? I meant ?x.) Second, Qt is in the process of moving away from their current WebKit components, based on CEF1 Chromium/WebKit, to new components based on CEF3 Chromium/Blink, and those new components will have LESS features/power than the current ones. (It’s open source, so theoretically one could add needed features oneself, but see above, re: C++ ?x etc.) Which is really kind of a bummer short-term, though longer term I imagine all the old features will be restored.
But of course the BEST solution would be for Xojo to standardize on Blink so we can all use Xojo for everything.
As i can see, there is nothing new. I also evaluated the using of Xojo and needed to stop at this point because the lack of actual HTML5-Support (for a special JS-Framework that needs a newer version).
I tried to just download the CEF3 and drop in into the libs folder. But i guess, there is more to do.