64 Matching Annotations
  1. Last 7 days
    1. The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

      at the mercy of author

  2. May 2021
    1. ☠️ Duygu Uygun-Tunc ☠️. (2020, October 24). A bit cliché but ppl will always find it cooler to point out that a given proposal is not the only one/has shortcomings/is not the Truth itself etc. Than making or improving a proposal. I keep being reminded of this every single day, esp on twitter. [Tweet]. @uygun_tunc. https://twitter.com/uygun_tunc/status/1319923563248353281

  3. Mar 2021
  4. Feb 2021
  5. Dec 2020
  6. Nov 2020
    1. If the document is uncontroversial and agreement is reached quickly it might be committed directly with the "accepted" status. Likewise, if the proposal is rejected the status shall be "rejected". When a document is rejected a member of the core team should append a section describing the reasons for rejection.
    1. I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this: new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging. the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state") the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments. assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented. All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)
    1. Another possible syntax is {#slot bar}<Foo/>{/slot}, which would also allow a bunch of DOM nodes and components inside the slot, without them needing to be from a single component

      I like it

  7. Oct 2020
  8. Sep 2020
    1. Syntax-wise, I would like to be able to pass id, style and class DOM attributes as well as (ideally) svelte props to whatever the slot was replaced with, so prefixing everything with attr in the slot that should be passed sounds like a good idea. Examples: <slot attr:class=“test” attr:class:active={true} /> or <slot attr:style=“color: red” attr:id=“henlo” />
    1. Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the Yarn core team. The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.
  9. Aug 2020
  10. Jul 2020
  11. Jun 2020
    1. Sometimes, the line between 'bug' and 'feature' is a hard one to draw. Generally, a feature is anything that adds new behavior, while a bug is anything that causes incorrect behavior. Sometimes, the core team will have to make a judgment call.
  12. May 2020
  13. Apr 2020
  14. Feb 2020
    1. Make a proposal If you need to decide something as a team, make a concrete proposal instead of calling a meeting to get everyone's input. Having a proposal will be a much more effective use of everyone's time. Every meeting should be a review of a proposal.
  15. Nov 2019
    1. I often wish for this. I don't understand why this hasn't been added.

      Ugly workaround for now:

      # Note, even though we don't need or use arguments passed to this selector, you *must* pass in an
      # argument to prevent it from matching the :id selector and giving a "Unable to find id :parent (Capybara::ElementNotFound)" error.
      # Example: el.first(:parent, 1)
      # You may also need match: first if el matches multiple elements to avoid Capybara::Ambiguous
      Capybara.add_selector(:parent) do
        xpath { ".//.." }
      end
      
  16. Oct 2019
  17. Aug 2019
    1. Under the Sanders proposal, for example, cost control is secured by a global budget and by imposing Medicare payment rates. Blahous, a former Medicare trustee, estimates that under the Sanders proposal, provider payments would be cut by an estimated 40 percent by usingMedicare payment rates. Using Medicare payment rates throughout the entire American health care economy would hurt patients. Already, the Centers for Medicare and Medicaid Services projects that “nearly half of hospitals, approximately two-thirds of skilled nursing facilities (SNFs), and over 8 percent of home health agencies (HHAs) would have negative total facility margins.”

      The system does not keep a balance between suppliers and consumers. Make up the economy of health care disorders.

  18. Jul 2017
  19. Mar 2017
    1. With only an hour face-to-face meeting with my friend Claude Tregoat we set up connections for 500 students in a project which would become to be known as CLAVIER.

      Taking the risk to be open.

      Feeling of being uncomfortable when first confronted with explaining a potential project - that reminds me of conversations with Maritta and Leena.

  20. Jan 2017
    1. and when his approbation of Rosamond's engagement was asked for, he gave it with astonishing facility, passing at once to general remarks on the desirableness of matrimony for young men and maidens, and apparently deducing from the whole the appropriateness of a little more punch.

      Again, making light of marriage. Is George Elliot making fun of how quickly people get married and how expected that is?

    2. and speak less incompletely. Rosamond had to make her little confession, and he poured out words of gratitude and tenderness with impulsive lavishment.

      I feel like the narrator is down playing everything to accentuate its haste and rashness. Why? Is it simply to hook in the reader before going back to Featherstone in the next chapter? Or will their marriage be like Dorothea and Casaubon's too?