13 Matching Annotations
  1. Jan 2024
    1. Another example are issue boards. They represent elegant use of a good infrastructure ­— it is all just a smart use of labels. It would be very complex feature without the use of labels.
    2. Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.
    3. We already have a very nice example of such tool and its great use: the Board, where labels are used to store metadata and the Board is built above this storage. Do the same with the relations -- simple metadata storage to build on.
  2. May 2021
    1. Every time filter-repo is run, files are created in the .git/filter-repo/ directory. These files overwritten unconditionally on every run.
    1. That image only contains 200 pixels horizontally, but the browser stretches it to 400px wide or even farther!Luckily, you’ll see there’s an easy “fix” there at the end: our old good friend the width attribute!<img src="example.gif", srcset="example.gif 200w" sizes="(min-width: 400px) 400px, 100vw" width="200" /* <=== TA-DA! */ class="logo">As long as you can specify the width attribute so it reflects the true maximum size of your largest image, you won’t run into this problem of having sizes make your image wider than it naturally should go.
  3. Mar 2021
  4. Dec 2020
  5. Oct 2020
    1. for (var member in myObject) delete myObject[member]; ...would seem to be pretty effective in cleaning the object in one line of code

      But checking hasOwnProperty is probably better/safer idea:

      for (var prop in obj) { if (obj.hasOwnProperty(prop)) { delete obj[prop]; } }
    1. I don't want Svelte to go out of its way to try to catch all these edge cases. It would require lots of fragile heuristics in the compiler. I want a solid compiler I can trust, not something magic but often out of service. I want it the simplest possible.
    1. Just like elements can have children... <div> <p>I'm a child of the div</p> </div>...so can components. Before a component can accept children, though, it needs to know where to put them. We do this with the <slot> element.