On the other hand, if you're able to create those two relationships A B, you'll have a more flexible mechanism to find things again. If they're not, you're forced to rely on a search engine to find a link you already have in your machine, which is not logical (read: absurd). The result is that you try to search by keywords in the Awesome Bar, hoping the ones you can remember are in the URL. If you place the link in the A folder, when you'll be searching for that link you might associate it with the concept B and not A, because if you're current focus is (related to) B you tend to remember the B association more easily than the A association. Organize bookmarks with folders has never worked for me, as the URL content can be related to two different concepts, say A and B. This is probably not the right place to talk about it, but I just wanted to say my opinion. > at the beginning, then no one cared anymore. > been an half-done feature that lost traction along the way, everyone excited > We have never specified a "correct" behavior here, cause tags have always > could also be seen as an alternative to bookmarking. > through the tagging API one could just tag an unbookmarked url. > Tags currently are bound to bookmarks, but that's not really mandatory, (In reply to Marco Bonardo from comment #8) If there is some consensus on what the API should look like you're welcome to try! But since we're just figuring it out for now I'd recommend not taking this bug. I would like to work on this and take it to completion. > Truly, this bug will be challenging for me but this will be a good learning. One way to make sure that doesn't happen is to not offer the possibility to create tags via the WebExtension API. I think removing these if tags gets killed would not badly break any extension except those that fundamentally rely on tags for some reason. My idea was to include tags in the part that gets queried through the "query" parameter and add a new "tag" field to the search options, like "url" and "title". But I agree 100%, we should rather leave this stalled than shoehorn some solution that will not conform to future ideas but we would have to support in the future. It seems that the bookmarks API is not a part of the new working group for now.
> But I can't exclude tags could end up on the "wrong" side of a great or dead > Otherwise, we could just take our own decisions, after some discussions > browsers is interested in tagging support, and what are their ideas. > webextension API across browsers, maybe we could figure if any other
> Not extremely formal, just some consensus across people responsible for (In reply to Marco Bonardo from comment #10) And based on that the API will look very different, and it will bound tags to a certain behavior "forever".Īs things stand now, I'd not bound a specification around something we never settled down. So, if there would be some sort of specification around those, first of all it should define whether we tag urls or bookmarks. We have never specified a "correct" behavior here, cause tags have always been an half-done feature that lost traction along the way, everyone excited at the beginning, then no one cared anymore. So tags could also be seen as an alternative to bookmarking.
Tags currently are bound to bookmarks, but that's not really mandatory, through the tagging API one could just tag an unbookmarked url. The problem is how you want this API to look like. That sounds like some pretty complicated SQL query,ĪUTOCOMPLETE_MATCH can match on tags, if you pass the tags list as the 4th param (IIRC). > Bookmarks.jsm#913 to also look in the tag folder and get the corresponding > Or we change the query implementation in (In reply to Johann Hofmann from comment #5)