Closed squidfunk closed 4 years ago
Thanks for your support. I‘m not sure what to do now – if I have to fork the theme anyway for Chrome support, the localsearch plugin is pointless because I‘ll be better off integrating all necessary modifications in the fork. I need to think about that ...
@wilhelmer we can look into a fallback for web workers after v5 is out. I think the only thing we need to do is to add some compatibility layer to the web worker code which detects whether the web worker runs in a separate thread or in the main thread and provide a compatibility layer for postMessage
. Should be pretty straight forward.
Or maybe a polyfill like nolanlawson/pseudo-worker?
@squidfunk Okay, I'll open an issue as soon as v5 is out. Do you have any idea when that will be? Preview 2 looks pretty stable to me already, apart from IE11 compatibility, but I don't know if you even planned to make it IE compatible (wouldn't mind if you didn't).
apart from IE11 compatibility
@wilhelmer I'll try to have a feature-complete and deployable RC by the end of January. From there on it'll probably be another 2-4 weeks until we hit a stable state.
@AlexWayfer haven't tested IE yet. CSS variables will not work in IE which Material v5 will introduce. We need to provide fallback (or compat) CSS which will show the theme in neutral or default colors. We'll do that post-RC.
As a side note: IE usage on the official Material for MkDocs site for the last year was at 0,26% which should be quite representative (50k unique users). IE usage among developers seems to be much less frequent that overall IE usage.
Would not bother with a fallback, imo
please enhance chinese search ; the search and toc is very userful
@ministp support for lunr-languages is still missing, that's correct. I added an item to the task list in the original post and will add it back before the RC.
018e38e9 adds back support for lunr-languages
. Note than the search language and okenization must now be configured through plugins.search.lang
and plugins.search.separator
, a described in the official docs
I started a migration guide for v5, documenting the changes that are necessary to the templates and partials if the user has overridden them in their build here. Those changes are crucial for the new (and more future-proof) application structure. I will also add another section on configuration changes and customization such as colors etc. In general the overall structure did not change much, especially custom CSS should continue to work in 99% of the cases.
I'm also hoping to finish the missing features within the next days, so we can put out a fully working RC. Sorry for the delay, quite hard to find some spare time at the moment.
For me, the build process changes were/are the biggest hurdle, might be worth mentioning as well!
@Stanzilla What specifically would be worth mentioning? Would you mind writing down the hurdles you experienced?
The move from webpack to the makefile, I have a few custom things in the webpack config and the new structure was a bit confusing to me, also probably less Windows friendly. I also sometimes have to npm clean before I can build because it does not see changes even though I did them
If you could isolate what files do not get rebuilt when changed we can fix the Makefile
If you could isolate what files do not get rebuilt when changed we can fix the Makefile
I just remembered, webpack config changes. If I do build, change something webpack.config.ts and then build again, it does nothing.
@Stanzilla should be fixed with 9b9527f8 – but I'm pretty sure that Webpack config changes are also not picked up on master
.
Small update: took the afternoon and finished the keyboard handlers (general and search-related) and copy-to-clipboard integration. Needs some cleanup (the main index.ts
is a mess), but should be functionally working. For the clipboard message we'll switch to a snackbar/toast design, deprecating the message next to the button. Furthermore the clipboard buttons now have a proper outline on focus which is better for accessibility. I'll cleanup the main index.ts
when the RC is out and all functionality has been implemented.
... and we're back to Webpack as of b486d0be. I ditched the whole Makefile-based approach. For a project the size of Material compatibility is an important issue and I ran into problems with asset versioning etc. where I would've had to build a lot of stuff from scratch. It just makes no sense. Sorry for any confusion this has caused with forks.
Yay!
Small facelifting of Admonitions in a018ed02:
Before:
After:
Making progress, most stuff is functional. I'll try hard to push out an RC in the middle of next week! The small facelift will also include a new logo:
Looks nice!
Fixed a lot of stuff today including some long standing errors. @facelessuser you're the only one I know of who is running the dev build in production. Could I ask you to update to the latest version to see if something breaks?
Bugs fixed in refactoring branch:
Bugs fixed which are still in current master
:
textContent
. This should hopefully solve the problem that some search engines index them and add them to the search summary – ca260e0fafa3a8b6e172368a0bcee6aa11b78fa0New features not in master
:
Yeah, I'll try it out and get back to you later today or tomorrow.
@squidfunk, seems to be working for me. Nothing obvious seems broken.
Thanks for your support. I‘m not sure what to do now – if I have to fork the theme anyway for Chrome support, the localsearch plugin is pointless because I‘ll be better off integrating all necessary modifications in the fork. I need to think about that ...
@wilhelmer I made some steps towards a solution for making localsearch work with v5 in fdffefd5. It's now possible to pass a Promise
resolving with the contents of search_index.json
which would allow for the technique we discussed before: inlining the search_index.json
into the template via a meta tag, retrieving it from there and passing it explicitly.
What remains is making the Worker
work locally. I tried pseudo-worker
and it would work if it didn't make an XHR request to retrieve and eval
the worker script. However, when I replace the Worker
with PseudoWorker
in a hosted non-local context, it works perfectly in the main thread.
Thus, inlining the search_index.json
and mimicking the API of Worker
are IMHO the only things necessary to make it work. We can probably tackle that after the final release of v5. To mimic the worker API, we would need to implement addEventListener
, postMessage
and importScripts
. We could probably do this by wrapping the Worker
constructor and implement the following logic:
Add a new script
to the end of document.body
which makes a copy of self
(which equals window
in the main thread), so we can restore it later. Furthermore, overwrite self
with our custom implementations of the three functions mentioned above. Basically, we only need to hook up the function passed to addEventListener
to postMessage
and we should be good to go.
Now add another new script
with the URL of the web worker. It will hook into our new self
pseudo worker and setup everything. We could probably just use the pseudo-worker
implementation. For all scripts passed to importScripts
, add another synchronously script
to the DOM to mimic the behavior.
Add another script
which restores self
to window
. Then, after evaluating all scripts, it's probably safe to remove them all.
Thanks for your effort! I created https://github.com/squidfunk/mkdocs-material/issues/1464 just while you typed this 😄
I hope we can continue the discussion there. I won't be able to do the coding myself, but my colleague will join in.
Just released Material 5.0.0b1. See #1465. Would be awesome to get some feedback, especially on the brand new search. Please report any problems, issues or incompatibilities in the linked issue.
Just released Material 5.0.0b2. See #1469. Again, would be great to get some feedback, and finally a new feature - instant loading!
Besides a brand new logo, v5 will include a new default (fav)icon to better reflect the core values of Material: Documentation for people
Much better than the other one. I love it!
@mnogue it's only the default icon, though 😊Changeable with a single line of code. The official docs will however include the new logo I posted earlier.
🎉Beta 3 just landed in #1483 and since we're feature complete, I'm closing this issue. I would encourage everybody to test the latest beta, as it's the last one before the final RC. There's still some cleaning up to do, but there's not much to change after beta 3. The more people test it, the earlier we can roll out a release candidate and finally get v5 out of the door!
Description
The last major releases of Material for MkDocs were mainly issued for compatibility reasons. While version 2 and 3 were related to backward incompatible changes of MkDocs (0.17.1 and 1.0 respectively), version 4 was released due to backward incompatible changes related to users with Chinese system languages (#911). The next iteration, version 5, is a substantial rewrite of the underlying JavaScript functionality to a TypeScript and RxJS-based architecture. This will yield the following major benefits:
All features that are provided by the theme (e.g. the sidebars, tabs, search, etc.) will be observable by 3rd party JavaScript. This allows for very easy extension and customization. This will address issues like #1102 where users want to extend the functionality of the theme without re-compiling or forking it. Also, disabling functionality should be easier.
Improving search performance. Search will be moved to a web worker and exhibit better caching and re-building behavior. This will mitigate problems were the UI freezes due to large search indexes which pre-building on the server-side only partly solves. Furthermore, search will be re-architected to fit into the plugin concept introduced by MkDocs 1.x.
Color customization will be re-implemented using CSS variables. Changing the color to your custom brand colors will be even simpler and the theme will become smaller (as the palette CSS file will not be necessary anymore). Support for CSS variables is pretty great by now, but there are some browsers that don't support it, respectively IE 11, Opera mini, QQ browser and Baidu browser. These browsers will receive a (probably neutral) fallback color. If you must support those browsers, you can still extend the theme and customize the build will custom CSS colors as already described in the customization guide.
There might also be some slight face lifting, but the main aspects of Material 5 is the introduction of a more modern architecture. The rewrite will also make the theme testable, so unit tests can and will be written to ensure functionality.
I will document my progress here and there will be a beta phase similar to before the release of 1.0.0 (#46). Some lists with things that need to be done will follow.
Evaluate
TODOs
5.0
General
Functionality
General
<details>
/<summary>
functionality<details>
after child-anchor jump<details>
before printingScroll-related
Sidebars
Search
Persist search index in local storagesee https://github.com/squidfunk/mkdocs-material/issues/1465#issuecomment-588286846Compress search indexsee https://github.com/squidfunk/mkdocs-material/issues/1465#issuecomment-588286846Accessibility
Repository
Issues
background-color
definition on root (#1418)5.x