Hi. Is there somewhere still the old version of documentation which had examples of everything on one page? I didn't use it for a while and I can't find it anymore. I think the documentation was changed during the end of the year and I can't find in the new one these examples and some things at all. It was much better for understanding how to write specific examples and I need it for other people who don't know markdown at all and they need page with those examples, the current reference page is too difficult for them.
The documentation was restructured in the middle of last year. The reference now contains all previous (and more) examples: https://squidfunk.github.io/mkdocs-material/reference/abbreviations/
I think so. I am not sure how it was called before but for quick reference it was better at least for some people. It was pretty quick to just scroll there and find an example of what exactly what you want to do. I had it cloned but only for a limited time. The new reference is good detailed in some ways but for just quick examples for people who don't know markdown it is much harder.
After all thats what git is for 😉
Or search for
specimen.md in the git history, that was the name of the file.
@squidfunk: facelessuser
https://gitter.im/squidfunk/mkdocs-material?at=60b88a770ff6de262b441e6c
https://gitter.im/squidfunk/mkdocs-material?at=60bcfca419b46c60b170f300
^
Seeing these messages made me more confident in suggesting that I become the maintainer of MkDocs:
https://github.com/mkdocs/mkdocs/discussions/2442
But instead, the idea of a separate "issue-closing committee" took over, which I don't know if it's actually happening or what it will solve. What I see is that things seem to be fizzling out.
I'm ready to push things forward if given the opportunity. If you mean to express your support, please do so in that thread; it looks like I will need that.
https://gitter.im/squidfunk/mkdocs-material?at=60b88a770ff6de262b441e6c
https://gitter.im/squidfunk/mkdocs-material?at=60bcfca419b46c60b170f300
^
Seeing these messages made me more confident in suggesting that I become the maintainer of MkDocs:
https://github.com/mkdocs/mkdocs/discussions/2442
But instead, the idea of a separate "issue-closing committee" took over, which I don't know if it's actually happening or what it will solve. What I see is that things seem to be fizzling out.
I'm ready to push things forward if given the opportunity. If you mean to express your support, please do so in that thread; it looks like I will need that.
The current discussion seems to be about reducing open issues and gaining an understanding of what people feel is missing.
Honestly, it's very hard to catch Tom, so my aim with this was to lend my frontend knowledge to decide on frontend related issues whether they can be closed as out of scope or not. There're many issues with "needs design decision" and I thought I could maybe help provide some input to reach a decision.
right-- you can see those things as separate and not conflicting. sorry if I'm misconstruing that
Yeah, I think Tom is just feeling out right now to get a better understanding of what MkDocs "needs". He's been quite removed for some time.
I think having someone, or at least a committee that at least steers the vision of a project is still important.
and the alternative is 0 person so yeah...
not to be a populist or anything, but I am, in fact, offering an easy solution to that
Offering some time for a grooming session was my way of trying to move things forward.
that offer can be valuable in later stages, but alone I don't think it can move things
issues themselves don't bother me too much (in terms of their number), it's possible to find trends even without closing them. but there are indeed some easy ones to close. when some issues that are unclear are identified, then it's good to discuss
sharpening of focus always correlates with dedicated leadership, from what i've seen
It would be interesting to see what you would imagine for the project, i.e. what your vision is. You seem to be heavily invested, which is great, but the question is whether this aligns with the philosophy of MkDocs. I think if you would take some time and lay out your vision of the project and where you think it should head, a decision might be easier to find. That's just an idea.
Don't get me wrong. I think you could be a great fit, because you manage some larger documentations with dedicated needs, but as the creator of a project, I would want to make sure it keeps on living in a way that I imagined it to do.
That's at least what I would do, if I'd need to.
frankly, I don't think I'm willing to write out a vision document specifically so that people can judge me over it. I don't actually have even a general roadmap right now -- I think that comes with enough time spent observing the trends. which again I'm not willing to invest that much upfront, looking at this general very low level of trust.
squidfunk (Martin Donath): don't know about the first big error. from this article http://erickt.github.io/blog/2014/11/19/adventures-in-debugging-a-potential-osx-kernel-bug/ (Ctrl+F "cleanly") i'd say that this is just the server trying to send data when the browser already closed the connection. most people seem to say that showing this particular error in that situation is a bug in macos. it should be safe to catch and ignore, but maybe there's no opportunity to catch it, as the stack trace doesn't show any place where it's "our" code
@squidfunk: the 404 error comes from a site with an old MkDocs version still running in one of your browser windows. could also be causing the other error.
hey there, quick question: Is there a way to directly link to a specific "content tab" in a document? (https://squidfunk.github.io/mkdocs-material/reference/content-tabs/)