13 Matching Annotations
- Dec 2022
-
www.rfc-editor.org www.rfc-editor.org
-
This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.
-
- Sep 2022
-
datatracker.ietf.org datatracker.ietf.org
-
Consumers can use the status member to determine what the original status code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without HTTP information. Generic HTTP software will still use the HTTP status code.
-
-
github.com github.com
-
We do not want to change or remove additionalProperties. Providing a clear solution for the above use case will dramatically reduce or eliminate the misunderstandings around additionalProperties.
annotation meta: may need new tag: - don't want to change or remove existing feature [because...] - solving problem B will reduce misunderstandings around feature A
-
- Aug 2022
-
docs.gitlab.com docs.gitlab.com
-
Here are some problems with current issues usage and why we are looking into work items:
-
- Aug 2021
-
stackoverflow.com stackoverflow.com
-
Javascript required? In other words, one cannot do this on cross-site iframes (due to cross-site scripting restrictions), is that right? As @clankill3r is suggesting, this demonstrates the need for a pure CSS solution to this problem
-
- Sep 2020
-
github.com github.com
-
It would be tiresome - and bloated - to include a class pass-through for every component or assigning custom properties (from the RFC linked) for all potential properties on every component, just in case it's gonna be used in layouts that requires it. Wrapping them in a wrapper div is certainly an option, but potentially creates 100s or 1000s (long lists, several lists etc.) of new elements in the DOM slowing down low-end devices.
-
-
github.com github.com
-
This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.
-
-
github.com github.com
-
Your tooltip component will have to wrap your image with a span tag or something, it can’t just add events to its children. And if you are adding multiple actions to it you will have to wrap it multiple times.
<Concern1> <Concern2></Concern2> </Concern1>
vs.
<img use:concern1 use:concern2>
-
-
-
You can imagine the ensuing combinatorial explosion if we needed to add borders or box shadows or filters or what-have-you.
-
If this was tied into Svelte's flow with hooks this would not be necessary since it would know when it was being removed from the DOM.
-
You must: reference each element you are extending using refs or an id add code in your oncreate and ondestroy for each element you are extending, which could become quite a lot if you have a lot of elements needing extension (anchors, form inputs, etc.)
-
This is where hooks/behaviors are a good idea. They clean up your component code a lot. Also, it helps a ton since you don't get create/destroy events for elements that are inside {{#if}} and {{#each}}. That could become very burdensome to try and add/remove functionality with elements as they are added/removed within a component.
-
Drag and drop might be done better with hooks than components.
Tags
- library/framework could make this easier
- scalability
- why this feature is needed
- too hard/difficult/much work to expect end-developers to write from scratch (need library to do it for them)
- could be easier / more difficult than it needs to be
- framework taking care of responsibility so users can leverage it and not have to worry about that responsibility themselves
- combinatorial explosion
- difficult/hard
- use cases
Annotators
URL
-