text:
How to redraw a chart?

My piechart uses data from the AJAX request, so the data comes after the chart is drawn. How can I redraw the chart based on the new data or make my piechart redraw automatically?

Until a better solution is presented, I was able to do this by going through the component as such:
<chart ref="chart" ...></chart>
and then
if(this.$refs.chart) {
    this.$refs.chart.chart.update();
}

If .update() doesn't help, try .resetChart()

I tried to call .resetChart() but it says method not found

if(this.$refs.chart) {
this.$refs.chart. resetChart();
}
it's should be work. note the resetChart method belong to the Vue component.

@MysteryAngle - that still doesn't quite work for me. I have data that sometimes changes more than once asynchronously (using axios http client talking to an API backend). What I observe is that the charts sometimes lag behind 1 update. In the success callback, I had code like what you suggested, and I found that sometimes this.$refs.chart was null/false. It seems like the chart itself has some asynchronous state that we have to manipulate via promises or something?
PS I've verified via the Vue debugger that all my data / computed values were correct while the chart was showing the "previous update" / version of the data. Unfortunately I can't post my exact code here.

Ah, reading this component's code was instructive...
The watchers for type and options only call resetChart() like this:
this.$nextTick(() => this.resetChart())
So the following seems to work for me now, no matter how many times I load new data asynchronously:
this.$nextTick(() => {
  if (this.$refs.chart) {
    this.$refs.chart.resetChart()
  }
})

So it looks like we need to wait for a DOM update before trying to redraw the charts, which sorta makes sense I guess.

This looks like it is not working for me. I can wait for the next DOM update but the this.$refs.chart still is null/undefined ? Any idea ?

@nanoupper hey. can you paste some code?

@MysteryAngle comment edited

@nanoupper yes. i can see that. but in template should like this:
<chart ref="chart" ...></chart>
do you declare the <chart> tag property ref set name to  chart?

thought it was already there. @MysteryAngle sorry for stealing your time. Thanks a lot !!

Hi,
I created a .vue file and in the template I've defined<chart ref="chart" ...></chart>. In the mounted function of my component I load chart data from ajax and I ran this.$refs.chart.resetChart().  Unfortunately, the chart is not redrawing with this.
Thanks for your help

Updated:
this.$nextTick(() => {
  if (this.$refs.chart) {
    this.$refs.chart.resetChart()
  }
})

this code will work fine when you update data.

Seems that only double click could update the chart, how to fix it?

@tonywangcn what mean of the double click？

      this.$nextTick(() => {
        if (this.$refs.chart) {
          console.log('tick tick ...')
          console.log(this.$refs.chart)
          this.$refs.chart.resetChart()
          console.log(this.$refs.chart)
        }
      })

With the first click, nothing happened with chart. Only updated after second click. But log prints in console each time.

OK，老王，我发现最近这个组建好像更新了一些东西，不过这句代码应该是没问题的，你可能需要检查一下数据。如果仍然有问题，咱们周一在看下。:)

<chart ref="chart" ....... v-if="isloaded">
data () {
isloaded: false
}
methods: {
do_something () {
this.$http.get()
this.isloaded = true
this.$nextTick(()
this.isloaded = false
}
}
虽然可以通过这种方式暂时解决，但又出现了其他报错：
[Vue warn]: Error in nextTick: "TypeError: Cannot set property '_chartjs' of null"

好像不能直接通过v-if来进行设定，生命周期或者上下文会存在一些问题。

嗯，但除此之外，还没找到更好的解决方案。
On Sat, Sep 9, 2017 at 1:32 AM Alex notifications@github.com wrote:

好像不能直接通过v-if来进行设定，生命周期或者上下文会存在一些问题。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vue-bulma/chartjs/issues/10#issuecomment-328166558,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC6kD5ZkUUHcC3p8ZNlXKzSE_eKbvSbvks5sgXoXgaJpZM4Mrc-t
.

--
Tony Wang
Warm Regards

我是这么做的，首先，chart的数据是由computed属性提供的，当我更新数据的时候，computed会重新计算，然后我在computed中调用了刷新的方法，如下：
computed: {
    ...

    seriesData () {
      let data = {
        labels: this.rep1Labels
      }
      data.datasets = this.series.map((e, i) => {
        return {
          data: e.points,
          label: e.label,
          borderColor: this.backgroundColor[i].replace(/1\)$/, '.5)'),
          pointBackgroundColor: this.backgroundColor[i],
          backgroundColor: this.backgroundColor[i].replace(/1\)$/, '.5)')
        }
      })
      if (this.$refs.chart) {
        this.$nextTick(() => {
          this.$refs.chart.resetChart()
        })
      }
      return data
    }
}

一开始nextTick这个是在组件内部调用的，但后来发现他去除了这个，所以我不得自己去加一个，不然的话会导致死循环。

多谢，这种解决方法不错
On Sun, Sep 10, 2017 at 5:04 PM Alex notifications@github.com wrote:

我是这么做的，首先，chart的数据是由computed属性提供的，当我更新数据的时候，computed会重新计算，然后我在computed中调用了刷新的方法，如下：
computed: {
...
seriesData () {
  let data = {
    labels: this.rep1Labels
  }
  data.datasets = this.series.map((e, i) => {
    return {
      data: e.points,
      label: e.label,
      borderColor: this.backgroundColor[i].replace(/1\)$/, '.5)'),
      pointBackgroundColor: this.backgroundColor[i],
      backgroundColor: this.backgroundColor[i].replace(/1\)$/, '.5)')
    }
  })
  if (this.$refs.chart) {
    this.$nextTick(() => {
      this.$refs.chart.resetChart()
    })
  }
  return data
}

}
一开始nextTick这个是在组件内部调用的，但后来发现他去除了这个，所以我不得自己去加一个，不然的话会导致死循环。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vue-bulma/chartjs/issues/10#issuecomment-328329525,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC6kD68Y6l9XgvWjHCoHjJ0XXEeCEVOmks5sg6YDgaJpZM4Mrc-t
.

--
Tony Wang
Warm Regards

authors: LensHunnel MajorAxe MysteryAngle RSamal chafreaky ereyes01 moonlik nanoupper tonywangcn

repo: vue-bulma/chartjs


text:
vue-style-loader dependency missing?

Hello,
I had this error running npm test on a vanilla webpack template install:
PhantomJS 2.1.1 (Linux 0.0.0) ERROR
  Error: Cannot find module "!!vue-style-loader!css-loader!vue-loader/lib/style-rewriter?id=data-v-1&scoped=true!vue-loader/lib/selector?type=styles&index=0!./Hello.vue"
  at /home/plrenaudin/projects/VueWebpack/test/unit/index.js:5690 <- webpack:///src/components/Hello.vue:4:0

I had to add the vue style loader manually
npm i --save-dev vue-style-loader

It ran successfully afterwards

what node and npm version are you using?

You're right, I'm using
$ npm --version
2.15.9

` ERROR  Failed to compile with 1 errors
This dependency was not found in node_modules:

!!vue-style-loader!css-loader!./../node_modules/vue-loader/lib/style-rewriter?id=data-v-53c6d8e7&scoped=true!sass-loader?indentedSyntax!./../node_modules/vue-loader/lib/selector?type=styles&index=0!./App.vue

Did you forget to run npm install --save for it?

Listening at http://localhost:8080`

$ npm -v 4.0.5
how to fix this? I  installed css-loader with --save-dev and installed vue-style-loader too but nothing

Please use the forum for usage questions and support, not old, closed bug issues.
forum.vuejs.org

source: gharchive/issue

authors: LinusBorg plrenaudin siempay

repo: vuejs-templates/webpack

license: mit

license_type: permissive

license_source: bigquery


text:
How to write a custom component which inherit props from an existing one?

What problem does this feature solve?
for example, in react, I can define a custom input component like this:
function MyInput(props: React.PropsWithChildren<React.HTMLProps<HTMLInputElement>> & {
  foo: string
}) {
  const [value, setValue] = useState('')
  const onChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => {
    console.log(props.foo)
    setValue(e.target.value)
  }, [])
  return <input {...props} value={value} onChange={onChange} />
}

What does the proposed API look like?
Vue.HTMLProps

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

by the way, I can use Omit<React.HTMLProps, 'value', 'placeholder'> to filter out props

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

by the way, I can use Omit<React.HTMLProps, 'value', 'placeholder'> to filter out props

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

So, what are you really asking? is it about the pass-through props? or about TS type?

So, what are you really asking? is it about the pass-through props? or about TS type?

So, what are you really asking? is it about the pass-through props? or about TS type?

with ts I can get both type definition(for auto completion) and props inherition

So, what are you really asking? is it about the pass-through props? or about TS type?

with ts I can get both type definition(for auto completion) and props inherition

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

FunctionalComponent is exactly what I need! but I receive compile error
TS2304: Cannot find name 'InputHTMLAttributes'.
should I import @types/react into a vue project?

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

FunctionalComponent is exactly what I need! but I receive compile error
TS2304: Cannot find name 'InputHTMLAttributes'.
should I import @types/react into a vue project?

import it from vue:
import { InputHTMLAttributes } from 'vue

import it from vue:
import { InputHTMLAttributes } from 'vue

import it from vue:
import { InputHTMLAttributes } from 'vue

it works! thank you

import it from vue:
import { InputHTMLAttributes } from 'vue

it works! thank you

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

使用 defineComponent 的时候怎么做呢？

authors: HcySunYang gjfei rainmanhhh

repo: vuejs/core

license: MIT

license_source: github-api


text:
onActivated not work well with async component

Version
^3.2.31
Reproduction link
stackblitz.com
Steps to reproduce

Open console
Home component logs that it was activated and mounted
Change tab to Post or Archive
Only mounted function is run
Change between tabs, both activated and mounted function are running now

What is expected?
The docs say:

onActivated is also called on mount, and onDeactivated on unmount.

What is actually happening?
onActivated is not called on the first time component is mounted. The function works well with normal/sync component

duplicate of #5651


text:
HMR not always working with useSlots and computed

Link to minimal reproduction
https://github.com/Floppy012/vue3-useslots-hmr
Steps to reproduce

Get a setup that has HMR

If you use the my reproduction project

It's using Nuxt3 (this is where I encountered the behavior and it was the fastest to setup)
Run npm install and npm run dev
Open localhost:3000 and developer tools
Change content of any data-test-div multiple times (it sometimes works properly and sometimes it doesn't)
Observe (check also the console for the logs of vite hot update and a plain "update" which is printed when computed gets executed)

Use useSlots in computed
Change slot content
Sometimes works, sometimes dont

According to console logs the parent file gets reloaded
The compute function isn't re-executed

What is expected?
compute should be re-executed to get the new values
What is actually happening?
compute isn't re-executed causing the child element not to update properly
System Info
System:
    OS: Linux 5.4 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
    Memory: 10.77 GB / 31.29 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.14.2 - ~/.nvm/versions/node/v16.14.2/bin/node
    Yarn: 1.22.18 - ~/.nvm/versions/node/v16.14.2/bin/yarn
    npm: 8.5.0 - ~/.nvm/versions/node/v16.14.2/bin/npm
  Browsers:
    Brave Browser: 97.1.34.80
    Firefox: 100.0

Any additional comments?
When changing the text using a reactive variable it seems to work properly.

HMR only rerender template, not triggerEffects.


text:
vue template模板中不支持  es6的新语法"?."表达式

What problem does this feature solve?
现在只能这样子:
<el-button v-if="tableData && tableData.length > 0"
type="primary"
@click="handleNew">点击
What does the proposed API look like?
希望能成下面（tableData?.length > 0）:
<el-button v-if="tableData?.length > 0"
type="primary"
@click="handleNew">点击

Cannot reproduce.
Reproduction
Please provide a minimum reproduction if you insist.

authors: libbGit sxzz


text:
fix(reactivity): do not remove dep from depsMap when cleaning up deps of computed

This is a follow up of 960706eebf73f08ebc9d5dd853a05def05e2c153
I have not managed to isolate a simple test-case yet, but in our app, some input fields appear to loose reactivity after a while without this fix

Thanks for catching this - I was able to create a test case in 4592b57913b87324ea9d7b750096f71b2265ddd9

/ecosystem-ci run

source: gharchive/pull-request


text:
Slots type resolution is broken in 2.2.0

Vue - Official extension or vue-tsc version
2.2.0
VSCode version
Not using it
Vue version
3.5.13
TypeScript version
5.6.3
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-1260P
    Memory: 10.44 GB / 11.68 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 20.12.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 10.5.0 - /usr/local/bin/npm
    pnpm: 9.9.0 - ~/.local/share/pnpm/pnpm

package.json dependencies
{
  "dependencies": {
    "vue": "^3.5.13"
  },
  "devDependencies": {
    "@tsconfig/node22": "^22.0.0",
    "@types/node": "^22.9.3",
    "@vitejs/plugin-vue": "^5.2.1",
    "@vue/tsconfig": "^0.7.0",
    "npm-run-all2": "^7.0.1",
    "typescript": "~5.6.3",
    "vite": "^6.0.1",
    "vite-plugin-vue-devtools": "^7.6.5",
    "vue-tsc": "^2.1.10"
  }
}

Steps to reproduce
Try to use useSlots/check for slots in template
What is expected?
No error is thrown
What is actually happening?
This condition will always return true since this function is always defined. Did you mean to call it instead? error
Also, I wasn't able to reproduce it in hello world, but I also had "any" resolution for useSlots and $slots.

Also this is obviously not valid code but the error is weird

We always had slots type resolution error in OAPI with "this assigment will always return true" even though it's by documentation

But it seems like this time it got more broken than before

Link to minimal reproduction
https://github.com/daniluk4000/vue-volar-slots-bug
Any additional comments?
Only happening since 2.2.0. 2.1.10 produces correct errors (if we assume $slots check in OAPI should return this always true error)

Circular reference occurred, it would be better to use defineSlots.

Circular reference occurred, it would be better to use defineSlots.

use for what specificly?

I use defineSlots in HelloWorld.vue in my reproduction and it still throws error
If we use defineSlots instead of useSlots in HelloWorld.vue it will still throw error
AFAIK OAPI is still a supported syntax and this should work anyways + it got worse in 2.2.0

Does this work on you end?

Does this work on you end?

Yep, good as workaround, didn't think of that solution before. Still believe should work as in 2.1.10 (IMO) since this is not per-Vue doc and a bit counterintuitive since slots should always be optional.

This might be a core issue since its type is not processed here, please feel free to open an issue to the core repository.
About OAPI it was a mistake I made, will fix it :)

Thanks! I'll try to review core types, also noticed they didn't have possible-undefined for useSlots/$slots in CAPI, but thought was something vue-tsc -related

Does this work on you end?

Similar issue, on vue-tsc 2.2.0 and typescript 5.7.2 i get error TS2774: This condition will always return true since this function is always defined. Did you mean to call it instead? on this line:
<div v-if="$slots.after">
   <slot name="label" />
</div>

Adding the ? to the type definition in defineSlots fixes it, but it should be optional by default
defineSlots<{
   label?: () => any
}>()

Just for the info, started receiving same error in vue-tsc 2.2.0
Gives lint error:
const slots = useSlots()

Work-around that works:
const slots: SetupContext['slots'] = useSlots()

authors: KazariEX ayrtonandino daniluk4000 timbze

repo: vuejs/language-tools


text:
Unable to re-export imported interfaces

Version
3.0.0-rc.9
Node and OS info
Node 8.10.0, Yarn 1.7.0, macOS 10.13.6
Steps to reproduce
Reproduction: https://github.com/ffxsam/repro-reexport-warning
Export an interface from file A, import it into file B, then re-export it from file B.
What is expected?
It should work with no warnings or errors.
What is actually happening?
Warnings are thrown.

You are exporting Thing - this is using it in a non-type-annotation position and thus cause it to be kept in emitted code - and causes webpack to attempt to look it up.
This has nothing to do with Vue CLI.

@yyx990803 I've searched far & wide on how to import an interface and re-export is, and found nothing. I assumed it was a Vue CLI issue since VS Code shows no warnings, and there are no TypeScript errors or TSLint issues either.
What is the correct way to import/re-export interfaces and types?

If you export an interface but not use it, TypeScript cannot safely remove the interface from emitted code.
Exporting it from main.ts doesn't make sense because you are not shipping raw TS.

I found the case in which this breaks down. It's when you also export/import defaults.
I've updated the repo, give it a look. AFAIK, all this syntax is legitimate. I'm trying to figure out where things are falling apart.

You're right, once I didn't export from main.ts, it's fine.
But then I don't understand why this code (my actual code) fails:
 warning  in ./src/store/index.ts

"export 'AuthState' was not found in './modules/auth'

src/store/modules/auth/index.ts
export interface AuthState {
  email: string | null;
  firstName: string | null;
  lastName: string | null;
  loggingIn: boolean;
  loggingOut: boolean;
  orgId: number | null;
  orgName: string | null;
  refreshToken: string | null;
  token: string | null;
  userId: string | null;
  [key: string]: any;
}
// ...
export default module;

src/store/index.ts
import auth, { AuthState } from './modules/auth';
// ...
export { AuthState };
export default store;

src/views/TagList.vue
<script lang="ts">
import Vue from 'vue';
import { AuthState } from '@/store';
// ...

@yyx990803 There are some serious bugs in Vue + TypeScript. Here's another one:
https://stackoverflow.com/questions/51661909/how-to-get-unit-tests-in-vue-to-stop-going-up-the-import-hierarchy
There's a reproduction repo in there. Try it out, and you'll see that the thrown Jest error makes no sense. I created a plain JS project and used the exact same code (minus the TS annotations of course), and the test ran fine.
I have a feeling this is an edge case, related to this issue with re-importing types. It may not be the Vue CLI, but it is definitely Vue + TypeScript.

@ffxsam
See https://github.com/vuejs/vue-cli/issues/1895
Fixed in https://github.com/vuejs/vue-cli/commit/a352bdc4dae0032bcfd1f313097e73053e737d24
Shipped in rc.6.
Please update your tsconfig.json

@sodatea Thank you, that fixed it!

@sodatea Though, changing this setting introduced new errors:
ERROR in /Volumes/SuperData/Sites/onspot/onspot-v2-ui/src/store/modules/settings/maintenance.ts
1:8 Module '"/Volumes/SuperData/Sites/onspot/onspot-v2-ui/node_modules/moment/moment"' has no default export.
  > 1 | import moment from 'moment';

Synthetic imports was addressing this. Do I now have to do import * as moment everywhere in my codebase?

import * as moment from 'moment' also fails:
A namespace-style import cannot be called or constructed, and will cause a failure at runtime.

@ffxsam
That's weird.
Per the TypeScript documentation, turning on esModuleInterop will automatically enable allowSyntheticDefaultImports for type system compatibility.
But this issue does get fixed by re-enable this option…

@sodatea I just submitted a new issue: https://github.com/vuejs/vue-cli/issues/2062

It was a bug in the TS documentation: https://github.com/Microsoft/TypeScript-Handbook/commit/8e974c814d44381ed05a3b6203894e0f9e39d552
So allowSyntheticDefaultImports must remain true in the TS template tsconfig.json.

authors: ffxsam sodatea yyx990803

repo: vuejs/vue-cli


text:
增加生成资源hash配置，hash允许配置在url参数上面，而不是文件hash,减少冗余文件

What problem does this feature solve?
允许 hash配置在 文件的url参数上来进行破除缓存，类似  [name].js?[hash:8] ,然后打包后生成的文件都是一样的，然后上传到服务器不会造成大量的冗余文件，也解决了缓存问题。
现在打包后：
<script src="app.[hash].js"></script>
期望的结果：
<script src="app.js?[hash]"></script>
What does the proposed API look like?
urlHash: true

一般认为在文件名中加 hash 比在 query parameter 中加 hash 更合理。
如果真的有需要，请自行修改 webpack 的 filename 和 chunkFilename 配置。

怎么合理了？这就关了？

这个功能现在自己写配置就能做到；

为什么合理在网上能搜到很多文章，这里给一个 webpack 官方的说法：https://github.com/webpack/webpack/issues/2329#issuecomment-210433116

js好处理，css那里就有点绕了吧

http://www.infoq.com/cn/articles/front-end-engineering-and-performance-optimization-part1
中文文章也有。这篇文章对为什么不建议用 query、资源冗余的问题都有解答。

我也理解这样做的原因，但现在发布部署的时候会产生很多历史遗留文件，清理起来有点麻烦，所以才产生这个需求的

原文评论里有说

我们跟踪统计过实际的开发情况，一个重点业务模块，持续使用 fis 1年之后，当前静态资源源码总计5.36M，线上冗余的总量是41.4M，有了这样的实际数据，或许就不会那么担心了吧
退一步说，如果真的因为“看着舒服”需要清理线上冗余，可以写一个脚本，对相同文件的不同版本做最后访问时间排序，把历史版本删除即可

thank you

authors: agileago sodatea


text:
defineCustomElement does not support async component

What problem does this feature solve?
While the new defineCustomElement feature is really nice, it does not supports async components.
This feature is useful when you want to define multiple web components in one file without loading all of them (they will be loaded when the custom elements are used).
The following attempt mount the component but custom elements attributes are not passed to the Vue component.
customElements.define(
  'my-element',
  defineCustomElement(defineAsyncComponent(() => import('MyComponent.vue')))
)

Async components are currently supported by web-component-wrapper for Vue 2.x (https://github.com/vuejs/vue-web-component-wrapper)
const CustomElement = wrap(Vue, () => import(`MyComponent.vue`))
window.customElements.define('my-element', CustomElement)

What does the proposed API look like?
The defineCustomElement function could receive a function returning a Promise to a Vue Component like this :
customElements.define(
  'my-element',
  defineCustomElement(() => import('MyComponent.vue'))
)

When the <my-element></my-element> element is inserted somewhere in the DOM, the MyComponent.vue file should be be downloaded by the browser (if not already) and mounted.

A note: when importing SFCs as custom elements, the tooling needs to process the SFC styles as inlined CSS strings for shadow DOM injection.
This use case makes me realize that the current way SFC toolings handle custom elements (which imports the SFC directly as the custom element constructor) is flawed, since it makes it impossible to define a custom element with defineAsyncComponent + SFC. So I'll have to rework the behavior in @vitejs/plugin-vue and vue-loader.

Awesome ! Thanks for the super fast fix @yyx990803 and congrats for the 3.2 release !

repo: vuejs/vue-next


text:
defineAsyncComponent: wait for async setup

What problem does this feature solve?
In a scenario where we need to :

lazy load a component (defineAsyncComponent)
with an async setup (to fetch initial data for example)

It could be handy to manage the loading state in one place.
e.g.

<template>

Welcome {{ username }}

</template>

// custom-elements.ts
import { defineCustomElement, defineAsyncComponent } from 'vue'
import LoadingIcon from '@/components/LoadingIcon.vue'

customElements.define('lazy-component', defineCustomElement(
  defineAsyncComponent({
    loader: () => import('@/components/LayComponent.ce.vue'),
    loadingComponent: LoadingIcon
  })
))

    <lazy-component></lazy-component>

In this scenario, the LoadingComponent will be rendered when :

The async component is being imported by the browser
The async setup function is being resolved

When both steps are done, the LazyComponent can be rendered.
What does the proposed API look like?
The current API don't need changes.
I guess the defineAsyncComponent function should check for async setup and resolve it before rendering the component.
Alternative approaches
It's currently possible to get a loading component during both steps (import / async setup) by :

Rendering the LoadingIcon in both defineAsyncComponent and LayComponent's Suspense but it duplicates the Loading part.
Creating a wrapper element like :

<template>
  <suspense>
    <template #default>
      <LazyComponent v-bind="$attrs" />
    </template>
    <template #fallback>
      <LoadingIcon />
    </template>
  </suspense>
</template>

but it introduces more boilerplate.

I would say you need to use Suspense like you show since it’s required for async setup

Thanks @posva for the fast feedback!
I was able to create a wrapper like that :

<template>

    {{ error }}

  <suspense v-else>
    <template #default>
      <slot />
    </template>
    <template #fallback>
      <LoadingIcon />
    </template>
  </suspense>
</template>

// custom-elements.ts
import { defineCustomElement, defineAsyncComponent } from 'vue'
import SuspenseWrapper from '@/components/SuspenseWrapper.vue'

// helper to define async component with loading icon during Suspense
function defAsyncSuspensible (asyncComp) {
  return defineCustomElement({
    render () {
      return h(SuspenseWrapper, {}, [
        h(defineAsyncComponent(asyncComp), this.$attrs)
      ])
    }
  })
}

// define a library of custom elements here
customElements.define(
  'lazy-component',
  defAsyncSuspensible(() => import('@/components/LazyComponent.vue'))
)

You're right, It may be more appropriate to handle it in user code than in defineAsyncComponent.
I'll close the issue.

authors: gnuletik posva


text:
not respect   tag

Version
2.5.3
Reproduction link
https://output.jsbin.com/yivetu/
Steps to reproduce
click the index href
What is expected?
Index url should be: https://www.example.com/
now it is: https://www.example.com/https:/www.example.com/news/index.html/
What is actually happening?
vue-router can't parse base url

This example is from the html spec about base tag https://html.spec.whatwg.org/multipage/semantics.html#the-base-element

In this example, a base element is used to set the document base URL:

<!DOCTYPE html>

        <title>This is an example for the <base> element</title>
        <base href="https://www.example.com/news/index.html">

Visit the archives.

The link in the above example would be a link to "https://www.example.com/news/archives.html".

If the archives's href start with /, the link would be a link to "https://www.example.com/archives" (whithout /news/) . And vue-router now doesn't support set base with: https://www.example.com/news/index.html.
some other maybe related discussions: https://github.com/ReactTraining/history/issues/94

need some help thanks!
Search Engine's page cache will inject <base> tag for every cached page, but when I add route rule: * for 404 match, when view page cache, it will always be 404

This seems to be a feature request, not a bug report.

If modify this, it maybe a breaking change https://github.com/vuejs/vue-router/blob/dev/src/history/base.js#L194, but work right!

At the moment, you can specify base: '/news/index.html' as a workaround. Maybe we should check for starting urls when reading the base tags and strip that off with something like /^https?:\/\/[^\/]+/

@posva thanks for your advice, in my case, I can't control the value of the base href, it was added by search engine, e.g:
vue-router page cache: https://webcache.googleusercontent.com/search?q=cache:PKjSDLmsED8J:https://github.com/vuejs/vue-router+&cd=1&hl=zh-CN&ct=clnk&lr=lang_en
in console:
console.log(document.baseURI); // output: https://github.com/vuejs/vue-router (baseURI same as base )

After searching a bit, this looks like there will be a problem with Google cache because the base tag is pointing to https://vue-hn.now.sh/top but it should be https://vue-hn.now.sh/. One fix for this is to ignore the base tag if it doesn't start with / but it may be breaking other things...

the most desirable thing is respect base tag and work well, I would like to submit a PR for this

authors: LinusBorg posva sabakugaara

repo: vuejs/vue-router


text:
Handling Loading State for async route components.

Version
3.0.1
Reproduction link
https://codesandbox.io/s/8xn8jn4xl9
Steps to reproduce
Click on Foo and check the network tab and console
What is expected?
Based on what is mentioned in the documentation
https://vuejs.org/v2/guide/components-dynamic-async.html#Handling-Loading-State
That this should work as well for async route components since 2.4.0
What is actually happening?
It is not working on async route components but working well on async components

It seems to be working on my end. You will have to provide more information about what not working means 😄

my bad 👍 what i mean is the route is successfully loaded but the Loading.vue component is not even mounted, I expected to see "I WAS HERE" in the console and it didnot happen. This is not the case when using the same syntax with async components not routes, I can see "I WAS HERE" in the console in that case, hope I explained the problem more, thank you

Have you seen https://github.com/vuejs/vue-router/pull/2140 ?

Thank you Posva this helps, but why this pull request is not merged ? will this be changed ? is it not advised to use this ?

We wanted to wait for a review
On Tue 23 Oct 2018 at 10:44, Abdalla Nayer notifications@github.com wrote:

Thank you Posva this helps, but why this pull request is not merged ? will
this be changed ? is it not advised to use this ?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-router/issues/2445#issuecomment-432154542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoicflLGgIbzLBy67ZYd905Ibw9LTZTks5untcEgaJpZM4Xzbxv
.

--
Eduardo San Martin Morote

Also need this feature, hoped it been merged

authors: abdallanayer posva ustbhuangyi


text:
[doc] a link is broken

zh-cn: docs/zh-cn/api/router-link.md
行：查看更多关于激活链接类名的例子 可运行.
en: router-link
line: Checkout more examples explaining active link class live.

Thanks! It's fixed now.

authors: esmeetu fnlctrl


text:
Filter scope

In attempting to create my first filter, I had to hunt around the internet to figure out how to make a filter that was available in more than 1 component (I wanted component and children). I'm thinking this is correct: filters are only available in the component they're added to and not their children, but global filters can be added using Vue.filter(...).
Let me know if you'd like me to make an attempt at adding this to the docs.

I think we already describe this behavior in the API for Vue.filter and the filters option. Let me know if I've misunderstood what you mean though.

The problem I had was that I searched for "filters" on the Vue site and ended up on this page which has no mention of where filters are available nor the global API.

This should be fixed soon. Since Filters aren't really an "Essential" feature, I'm thinking of consolidating all the info here into the API.

Filters have a dedicated page here, as well as a place in the API. Is this issue solved?

Yes, good catch. 🙂

authors: chrisvfritz darrylhein sdras


text:
Remove unwanted modal classes

Full modal adds additional classes to the modal-dialog which are not needed:

Thanks @SwenVanZanten, I will review this asap.

Accepted, thanks ;)

authors: SwenVanZanten miljan-aleksic

repo: vuikit/vuikit


text:
[Marina] document marina-provider 1.2.0

related to: https://github.com/vulpemventures/marina-provider/pull/1

It seems also isEnabled is missing

authors: louisinger tiero


text:
🛑 Ecoindex.fr website is down

In ac6a412, Ecoindex.fr website (https://www.ecoindex.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ecoindex.fr website is back up in b10b17d after 2 hours, 26 minutes.

repo: vvatelot/upptime


text:
Input methods do not seem to work

I could not get inputs to work on my side project. To avoid issues related to my writings I replicated with the issue by following the tutorial in the README. When trying to follow along with the tutorial I cannot get the input methods to work
❯ sbcl
This is SBCL 2.1.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload :sketch)
To load "sketch":
  Load 1 ASDF system:
    sketch
; Loading "sketch"
.............
(:SKETCH)
* (defpackage :tutorial (:use :cl :sketch)
)
#<PACKAGE "TUTORIAL">
* (in-package :tutorial)
#<PACKAGE "TUTORIAL">
* (defsketch input-test
   ((title "Hello, input")
    (rectangles nil))
 (loop for (x y) in rectangles
       do (rect x y 50 50)))
(defmethod on-click ((window input-test) x y)
  (with-slots (rectangles) window
    (push (list x y) rectangles)))#<STANDARD-CLASS TUTORIAL::INPUT-TEST>
*
#<STANDARD-METHOD TUTORIAL::ON-CLICK (INPUT-TEST T T) {1002AC7673}>
* (make-instance 'input-test)
#<INPUT-TEST {1002AC9153}>

The gray window appears but nothing happens when clicking. Adding a format to print something shows nothing.
When running the examples using
* (ql:quickload 'sketch-examples)
To load "sketch-examples":
  Load 1 ASDF system:
    sketch-examples
; Loading "sketch-examples"

(SKETCH-EXAMPLES)
* (make-instance 'sketch-examples:life)
#<SKETCH-EXAMPLES:LIFE {1002BE2EC3}>
*

I can flip the cells and make it run so at least on-text and 'on-click` seem to work on my system, so it seem to exclude things in the desktop stack.
I am also a bit confused by the discrepancy between quicklisp versions and project versions but that is probably because I have not wrapped my head around this part.

I can't check right now, but I think the quicklisp version is not in sync with the repo. So you could switch to the ultralisp distribution, or clone the repo into your quicklisp local-projects to guarantee that you have the latest version.

I did try before logging the ticket that without effect. I then got medieval on quicklisp and burned with fire all files and directories related to sketch, git cloned in local-project. Copied indigo to blue and exported that, just to be sure I was getting the right version and reran the tutorial (with blue this time) and that worked.
I tried my weekend project and that worked too.
Thanks for the quick reaction! Sorry for triggering an issue too soon, I am new to CL and a bit lost at the moment.

No worries, it's rather confusing and we should maybe clarify it in the docs somehow!

authors: Kevinpgalligan ptillemans

repo: vydd/sketch


text:
:help ale* not working

Information
VIM version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Dec  7 2017 16:07:42)
macOS version
Operating System: Mac 10.10.5, CentOS 6
:ALEInfo
Current Filetype:
Available Linters: []
Enabled Linters: []
Linter Variables:
Global Variables:
let g:ale_cache_executable_check_failures = v:null
let g:ale_change_sign_column_color = v:null
let g:ale_command_wrapper = v:null
let g:ale_completion_delay = v:null
let g:ale_completion_enabled = 0
let g:ale_completion_max_suggestions = v:null
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 0
let g:ale_fixers = {}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = v:null
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 1
let g:ale_lint_on_filetype_changed = 1
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'always'
let g:ale_lint_on_insert_leave = 0
let g:ale_linter_aliases = {}
let g:ale_linters = {}
let g:ale_linters_explicit = 0
let g:ale_list_window_size = v:null
let g:ale_list_vertical = v:null
let g:ale_loclist_msg_format = v:null
let g:ale_max_buffer_history_size = v:null
let g:ale_max_signs = v:null
let g:ale_maximum_file_size = v:null
let g:ale_open_list = v:null
let g:ale_pattern_options = {}
let g:ale_pattern_options_enabled = 0
let g:ale_set_balloons = 1
let g:ale_set_highlights = 1
let g:ale_set_loclist = 1
let g:ale_set_quickfix = 0
let g:ale_set_signs = 1
let g:ale_sign_column_always = v:null
let g:ale_sign_error = v:null
let g:ale_sign_info = v:null
let g:ale_sign_offset = v:null
let g:ale_sign_style_error = v:null
let g:ale_sign_style_warning = v:null
let g:ale_sign_warning = v:null
let g:ale_statusline_format = v:null
let g:ale_type_map = {}
let g:ale_use_global_executables = v:null
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
Command History:
What went wrong
The help isn't working. I can't get any ale help files working in VIM when I type :help ale-options or any other ale-*. I checked the vim general help by pushing F1, scrolled all the way down to 'LOCAL ADDITIONS', but I didn't see ale. I know ale is working because I can configure eslint, but the help isn't working.
On my CentOS box, I do see "ale.txt  For Vim version 8.0." in the LOCAL ADDITIONS section, but when I ctrl+] to jump to it, I see an error: "E149: Sorry, no help for ale.txt"
Reproducing the bug
Install ALE with pathogen.
 cd ~/.vim/bundle
 git clone https://github.com/w0rp/ale.git

Try to access the ALE help docs within VIM.
 :help ale-options  # doesn't work...

My fault:
https://stackoverflow.com/questions/6970334/vim-pathogen-not-loading-help-docs#9391768
I needed to run :Helptags.

I had the same issue but with standard vim package install.  I also wanted ':h ale' to load the TOC so I added symlink.  I ran these commands and it worked.
jbenninghoff@jb-mbpro 1: cd ~/.vim/pack/gitplugins/start/ale/doc
jbenninghoff@jb-mbpro 1: ln -s ale.txt ale
jbenninghoff@jb-mbpro 1: vim -u NONE -c "helptags ~/.vim/pack/gitplugins/start/ale/doc" -c q

I have a recommendation for this in the README. https://github.com/w0rp/ale#generating-vim-help-files


text:
tslint windows 10 neovim file path mistake fix

Environment
NVIM v0.2.2
ALEInfo
Current Filetype: typescript
Available Linters: ['eslint', 'tslint', 'tsserver', 'typecheck']
Enabled Linters: ['eslint', 'tslint', 'tsserver', 'typecheck']
Linter Variables:
let g:ale_typescript_tslint_config_path = ''
let g:ale_typescript_tslint_executable = 'tslint'
let g:ale_typescript_tslint_ignore_empty_files = 0
let g:ale_typescript_tslint_rules_dir = ''
let g:ale_typescript_tslint_use_global = 0
let g:ale_typescript_tsserver_config_path = ''
let g:ale_typescript_tsserver_executable = 'tsserver'
let g:ale_typescript_tsserver_use_global = 0
Global Variables:
let g:ale_cache_executable_check_failures = 0
let g:ale_change_sign_column_color = 0
let g:ale_command_wrapper = ''
let g:ale_completion_delay = 100
let g:ale_completion_enabled = 0
let g:ale_completion_max_suggestions = 50
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 0
let g:ale_fixers = {'typescript': ['tslint']}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = 0
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 0
let g:ale_lint_on_filetype_changed = 0
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'never'
let g:ale_lint_on_insert_leave = 0
let g:ale_linter_aliases = {}
let g:ale_linters = {}
let g:ale_linters_explicit = 0
let g:ale_list_window_size = 10
let g:ale_list_vertical = 0
let g:ale_loclist_msg_format = '%code: %%s'
let g:ale_max_buffer_history_size = 20
let g:ale_max_signs = -1
let g:ale_maximum_file_size = 0
let g:ale_open_list = 0
let g:ale_pattern_options = {}
let g:ale_pattern_options_enabled = 0
let g:ale_set_balloons = 0
let g:ale_set_highlights = 1
let g:ale_set_loclist = 0
let g:ale_set_quickfix = 1
let g:ale_set_signs = 0
let g:ale_sign_column_always = 0
let g:ale_sign_error = '>>'
let g:ale_sign_info = '--'
let g:ale_sign_offset = 1000000
let g:ale_sign_style_error = '>>'
let g:ale_sign_style_warning = '--'
let g:ale_sign_warning = '--'
let g:ale_statusline_format = ['%d error(s)', '%d warning(s)', 'OK']
let g:ale_type_map = {}
let g:ale_use_global_executables = v:null
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
Command History:
(executable check - failure) eslint
(executable check - success) d:\Work\learning-typescript\node_modules.bin\tslint
(finished - exit code 2) 'cmd /s/c "cd d:\Work\learning-typescript\source\app && d:\Work\learning-typescript\node_modules.bin\tslint --format json -c d:\Work\learning-typescript\tslint.json C:\Users\zhaoxu\AppData\Local\Temp\nvimgTWi9K\2\main.ts"'
<<>>
[{"endPosition":{"character":50,"line":9,"position":418},"failure":"Missing trailing comma","fix":{"innerStart":418,"innerLength":0,"innerText":","},"name":"C:/Users/zhaoxu/AppData/Local/Temp/nvimgTWi9K/2/main.ts","ruleName":"trailing-comma","ruleSeverity":"ERROR","startPosition":{"character":50,"line":9,"position":418}}]
<<>>
(started) 'cmd /s/c "d:\Work\learning-typescript\node_modules.bin\tsserver"'
(executable check - failure) typecheck
Quickfix
d:\Work\learning-typescript\source\app\C:Users\zhaoxu\AppData\Local\Temp\nvimgTWi9K\2\main.ts|10 col 51 error| trailing-comma: Missing trailing comma
Fixed
source\app\main.ts|10 col 51 error| trailing-comma: Missing trailing comma
(executable check - success) d:\Work\learning-typescript\node_modules.bin\tslint
(finished - exit code 2) 'cmd /s/c "cd d:\Work\learning-typescript\source\app && d:\Work\learning-typescript\node_modules.bin\tslint --format json -c d:\Work\learning-typescript\tslint.json d:\Work\learning-typescript\source\app\main.ts < C:\Users\zhaoxu\AppData\Local\Temp\nvimx3AuBD\2\main.ts"'
<<>>
[{"endPosition":{"character":50,"line":9,"position":418},"failure":"Missing trailing comma","fix":{"innerStart":418,"innerLength":0,"innerText":","},"name":"main.ts","ruleName":"trailing-comma","ruleSeverity":"ERROR","startPosition":{"character":50,"line":9,"position":418}}]
<<>>

This isn't a mistake, but there are some problems with what ALE does. See this issue for what is being done about this already: #925


text:
Thread support for nimcheck

Added a '--threads:on' switch to the nim check command so that it doesn't produce errors when using one of the various modules that require threads.

Cheers! :beers:


text:
Please add a license

I'd like to add this to awesome-zsh-plugins, but it doesn't have a license.
Please add a license - if you haven't already decided on one,  I recommend choosealicense.com.

@unixorn added a licence. Let me know if there are any other changes that are needed.


text:
Switch from URI to IRI terminology in WebID spec

Originally recorded/tracked in https://www.w3.org/2005/Incubator/webid/track/issues/71
Considerations (requirements, advisory..) to include in the WebID 1.0 spec.

Use in the context of the HTTP protocol and data
Normalization
Security

Other considerations:

Existing deployments and upgradeabillity

Pat, do you mean besides:

Considerations (requirements, advisory..) to include in the WebID 1.0 spec.

Use in the context of the HTTP protocol and data
Normalization
Security

Other considerations:

Existing deployments and upgradeabillity

?
You're welcome to create a PR addressing those and other considerations (that people have) so that we can move towards "closing this issue".
(And, no, I don't believe something like this is a simple matter of "search-and-replace", although life would indeed be a lot simpler if that's all we had to do :))

This is an ongoing cyclical discussion.
URL, URI, and IRI are roughly equivalent in most readers' minds. Yes, there are technical distinctions, but surprisingly many people who encounter IRI think it's a typo for URI. URL has managed to replace URI as the superclass of all identifiers, even though the L for location is obviously a subset of identifier (and URN has almost completely fallen to the wayside).
Note, for instance, What is Happening with "International URLs", dated 2015-08-25, which cites the then current URL spec.
The now current URL Living Standard — Last Updated 8 December 2023  says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

I'm in several WGs at the moment. All of them have followed the above guidance for human-focused documentation, though all have also recognized the historical and technical differences between URL, URI, and IRI.
I am more than hesitant to suggest that we should treat issues logged 10 years ago as if they were recent, and even more hesitant to accept a comment of similar age ("Comments on current editor's draft (Web 1.0, 3rd October 2012)") as if it were currently accurate, especially as it's being mis-cited above (it's not from nor even cited by @pchampin; it's from @Antoine-Zimmermann and dated 2023 Oct 2012 18:53:02 +0200).

Hiya @TallTed,

This is an ongoing cyclical discussion.

Yep, exactly - and my strong fear is that it'll continue to cycle ad infinitum, unless we once-and-for-all resolve it by being completely unambiguous and explicit. That's precisely what the RDF Recommendation does, in section 3.2 IRIs. And doesn't that spec still remain the very foundation for everything we're discussing here...?
Surely all the arguments being made here (i.e., 'URI/IRI are confusing', 'most people conflate them anyway', 'there's only the one algorithm', etc.) should apply to RDF itself too, right? So logically, should the upcoming RDF 1.2 work adopt this 'let's just use URL' position too...?

URL, URI, and IRI are roughly equivalent in most readers' minds. Yes, there are technical distinctions, but surprisingly many people who encounter IRI think it's a typo for URI. URL has managed to replace URI as the superclass of all identifiers, even though the L for location is obviously a subset of identifier (and URN has almost completely fallen to the wayside).

Yep, there sure are "technical distinctions", and this work is a technical specification - so aren't those technical distinctions important (see this "Java doesn't support IRI?")?
Yes, it's unfortunate that people might wrongly conflate, or misunderstand, or mixup these terms, but I think it would be a big mistake to attempt to paper-over these distinctions by misusing the term URL in this specification when we all know we really, technically, mean IRI (again, as per the RDF spec).

Note, for instance, What is Happening with "International URLs", dated 2015-08-25, which cites the then current URL spec.
The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

Yep sure - but those WhatWG folks aren't building on the foundation of RDF (are they?). So I don't think they have any strong need to be consistent with RDF's foundations (i.e., IRIs).

I'm in several WGs at the moment. All of them have followed the above guidance for human-focused documentation, though all have also recognized the historical and technical differences between URL, URI, and IRI.

Ok, but are those WGs founded on (or strongly related to) RDF I wonder? If so, then if they ignore the clear, explicit example of RDF itself (i.e., it's IRIs - full-stop, no discussion), then aren't they simply adding to the confusion by using anything other than IRIs (since RDF mandates IRIs - full-stop, no discussion)...?
And isn't this WebID work intended to become a formal technical specification (and so it shouldn't be watered-down technically to appease looser, non-normative needs of 'human-focused documentation', should it)?

I am more than hesitant to suggest that we should treat issues logged 10 years ago as if they were recent, and even more hesitant to accept a comment of similar age ("Comments on current editor's draft (Web 1.0, 3rd October 2012)") as if it were currently accurate, especially as it's being mis-cited above (it's not from nor even cited by @pchampin; it's from @Antoine-Zimmermann and dated 23 Oct 2012 18:53:02 +0200).

Yeah sorry - I've editted/fixed the attribution above. But I don't understand why this suggestion 'being old' would be relevant. The sentence, "all current W3C specs in the Semantic Web activity now use IRI, you should replace URI with IRI everywhere, I think;" seems perfectly correct to me - i.e., it's perfectly applicable right now, today, not matter who says it, or when it was 'originally said'.
So in summary, I see the consistent use of IRI as the only way to prevent the annoying ongoing confusion over URL/URI/IRI, and to stop the cyclic discussion. In other words, this all goes away if all Semantic Web related technical specifications simply followed the example of the foundational RDF Recommendation itself. (Note, they don't have to repeat the Note in section 3.2 IRIs, just reference it).
If you insist on persisting with URL, then I feel you're only continuing the confusion and cyclic discussion (since it obviously misaligns with the extremely clear RDF spec (so you'll always have to explain/justify that misalignment)). And I don't think anybody is going to propose making this consistent the other-way-around - i.e., by changing the RDF Recommendation to use URL (although RDF 1.2 is in the works, so now's your chance to suggest it :smile: !)).
So flip to IRI and be consistent with RDF...
...or stick with URL and continually explain and justify the misalignment with RDF.

Hiya @jacoscaz

The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

Very much +1 on this. Furthermore, within the context of WebID, URL is actually what makes the most sense. WebIDs must dereference to profile documents and therefore must not only be identifiers (IRI / URI) but also locators (URL).

Yeah, the fact that WebID's are really IRLs(!) is indeed a wee bit niggly. But for me, it's still fine to consider them first-and-foremost identifiers. Yep, I do get your point, that they do have to be dereference-able to be 'true WebIDs', but I don't think that justifies breaking from RDF's mandate for IRIs (and I certainly don't want anyone to coin 'IRL' as a new acronym).
So yep, you make a valid point, but for me it's not strong enough to justify diverging from the RDF foundation of IRI.

Based on my personal experience, the "internationalized" characteristic of IRIs is pretty much assumed to apply to URLs, too,

Maybe I'll just point again to "Java doesn't support IRI?" :smile: !

once-and-for-all resolve it

Nothing is ever "once-and-for-all resolved" in the world of SDOs. It is only resolved for this edition of this spec.
Note that here you pointed me to --

RDF 1.1 Concepts and Abstract Syntax
W3C Recommendation 25 February 2014

-- and earlier you pointed me to even older things, and that's part of what got me spinning.
It is probably worth pointing also (if not instead) to that section in the latest Editor's Draft of RDF 1.2 Concepts, which mostly matches that from RDF 1.1. It is also worth noting that we (the RDF-star WG, which is working on all of RDF 1.2 and SPARQL 1.2, and it's a lot) had substantial discussion about this, much (but not all) of which is captured here.
I had forgotten that we did conclude that IRI was the right term for purposes of RDF, though not necessarily for purposes of Web browsing (which the WHATWG is far more focused on).
So anyway. Yeah, go ahead with IRI for WebID.

Yes, it's unfortunate that people might wrongly conflate, or misunderstand, or mixup these terms, but I think it would be a big mistake to attempt to paper-over these distinctions by misusing the term URL in this specification when we all know we really, technically, mean IRI (again, as per the RDF spec).

The way I see it, it's exactly the opposite. By using IRI we'd be papering over the distinction between identifiers and locators in a manner that's guaranteed to be technically confusing. Nobody can really mean IRI if they're describing what must be a locator.
I do agree that deviating from the RDF spec would be unfortunate but, and I acknowledge that there's a lot of subjectivity here, I think doing so would nonetheless deliver a technically clearer and more understandable spec.
Both IRI and URL require a compromise:

going with IRI we would compromise on making it clear that a WebID is a locator in favor of making it clear that the spec supports an extended set of characters
going with URL we would compromise on making it clear that the spec supports an extended set of characters in favor or making it clear that a WebID must dereference

Today, most technical people I work with don't even question whether URLs can be internationalized or not. They just assume that such is the case and get mildly annoyed when it isn't. On the contrary, all of the technical people I work with are very well aware of the difference between identifiers and locators. IMHO, by going with IRI we'd be making the wrong compromise.

A WebID which Identifies me does not Locate me. Clearly, a WebID is not a Locator, Uniform or otherwise. It is an Internationalized Resource Identifier (which class includes all Uniform Resource Identifiers; all URIs are IRIs) which identifies an Agent. Dereferencing that Identifier leads to a WebID Profile Document, possibly through a 303 or other redirect, the target of which may be (probably is) a Uniform Resource Locator.

A WebID which Identifies me does not Locate me

Agreed. But, for all practical intents and purposes, a WebID identifies the Agent while locating the Profile Document. This is not 100% sound from a theoretical point of view but reflects what happens in practice: if a WebID can be passed as the primary url argument/parameter of an HTTP client library in order to obtain a Profile Document, then that WebID is, by all practical definitions, a locator.
That said, I should clarify that, although I would prefer URL over IRI, I would personally have no significant issue with any of these. Yeah, I think one would be better than the other but there are other hills for me to die on. I'm mostly here because I'm very interested in learning about the perspectives of others.
I think we have +3 for IRI and +1 for URL, at the moment.

Tagging a few of the most active group participants to encourage the conversation - @woutermont @jonassmedegaard @melvincarvalho @kidehen @acoburn

I would find it super confusing if WebID were to use "URL-but-canonical-form-must-be-internationalized".
I much prefer that we continue to define the use of "IRI (or arguably only a subset of IRIs) that is used for locating".

We've been using URIs for over a decade and it's been fine.  URLs seem fine too.  Noting, as others have, that the original referenced issue is dated 2012.  AFIAK different specs say different things on this.  I really don know about IRIs and if they introduce new attack vectors.

Agreed. But, for all practical intents and purposes, a WebID identifies the Agent while locating the Profile Document.

That's confusing.
A WebID is an HTTP based identifier that unambiguously names an Agent.
HTTP IRIs and URIs (both Pointers) satisfy the condition expressed in the statement above. A URL (an Address) doesn't.
HTTP is what makes a WebID a "deceptively simple" Name.
A Name is a combination of denotation and connotation delivered by realm-specific indirection.
The connotation->denotation switch is crucial, and its happens via indirection.
Trying to ignore these facts simply makes matters confusing, as @TallTed has already explained in detail.

I'm still in the review process of https://github.com/solid/specification/issues/347 ( by @woutermont , whom did a great job). If anyone wants to get a sense of the kind of things that needs to be detailed for a protocol, they may find the PR and discussion there useful. Some of the findings or solutions there (and elsewhere, e.g., rdf12-concepts) are important here as well, and we can probably minimise repetition. I'd like to see/do a diff between the PR and rdf12-concepts.
That's all orthogonal to getting a better sense of implementation experience, or even commitment to implement.
There are separate but related considerations in the WebID spec. At varying degrees, the WebID spec details the identifier, the protocol, and data. So, we need proper roundtripping ( see e.g., table in https://github.com/solid/specification/issues/347#issuecomment-1237167849 )
As I understand things at this time, it is not so much about URI vs IRI or URL or Whatever. Going with IRI or (WHATWG) URL doesn't resolve anything out of the box. The most important detail is the function that maps one to another so that there is implementations can interop. And, so, that's the core of resolving these issues and PRs. IMO.

@melvincarvalho I think it would help the conversation that you clarify if by "we" you mean all of us or some smaller group you are part of that simply haven't happened had any need for involving data at internationalized domains.

Feels like there's a strong consensus for using IRI - very good! Consensus is the key!

As I have been mentioned in this thread, I will give my opinion.
First, the remark I made back in 2012 is still valid and appropriate: the main Semantic Web standards all use IRI as the identification model: OWL 2, SPARQL 1.1, RDF 1.1, SHACL. Some standards that are based on RDF are more sloppy and inconsistent in how they use URI and IRI but for these standards, the notion of identification is not at the center of their models. For WebID, identification is very much the central focus of the specification. So, this is one point arguing for consistency and homogeneity across specifications.
Second, IRIs are for internationalised identification. Constraining characters to those used by the English language is rather arbitrary and pushes away many civilisations that want an understandable Web for them. Indeed, the W3C Group Draft Note on Internationalization Best Practices for Spec Developers has gone through many revisions but consistently said, since 2016: "Specifications that define resource identifiers MUST permit the use of non-ASCII characters." And below the sentence is written: "Model is defined in terms of IRIs; Protocol with URI."
Third, IRIs correspond better to what WebID is specifying than living standard URLs. URIs, IRIs, and even RFC URLs are not even living standard URLs. In the living standard, URLs are structs, not character strings. An RFC URL apparently corresponds to a serialized URL. An IRI apparently corresponds to a valid URL string.
As a side note, in my opinion, the URL living standard is creating confusion rather than solving it. It is horrible to read, very complicated and disconcerting. It reinvent its own terminology rather than building on top of the existing ones. It may be creating more problems than it is trying to solve. Also, on the point of being able to locate information, which is needed for WebID: some IRIs dereference to a location with information, and some don't. But URLs are not a solution in this regard: some URLs dereference to a location with information, and some don't.
So, I reiterate my claim that WebID should use IRIs as its base model for identification, not URIs nor URLs.

@csarven

As I understand things at this time, it is not so much about URI vs IRI or URL or Whatever. Going with IRI or (WHATWG) URL instead of URI doesn't resolve anything out of the box. The important detail is the function that maps one to another so that there implementations can interop, which is at the core of resolving these issues and PRs. IMO.

You're right. The change from URI to IRI is only a small conceptual fix so as to allow people for whom the Latin alphabet means nothing to use their own meaningful symbols. It adds another layer to the mapping from identifier to data, namely that Unicode must be translated to ASCII before resolving the mapping.

-1 to IRIs for me, for now
Not in this version, as we already have a lot to take on, and this would add a whole new world of complexity, serialization problems, equivalence problems, security problems.  Test suites will be that much harder.  There will be a whole range of edge cases and phishing attacks.
The scope is too broad, and I would prefer to focus on the main work item of a subset spec and a superset spec, which will be hard enough to get over the line.
Also there should be a survey by those advocating this of the social web, and how much of the social web are already using IRIs today, and interop with them.  If there's an overwhelming adoption that should help the case.  But still I think it should go into a WebID v next.
Also special characters belong in a foaf:name, not in a URI.

@melvincarvalho, your position makes complete sense, and I sympathise with these arguments.
However, saying that "special characters belong in foaf:name, not in a URI" is somewhat disingenuous since indeed, special characters do not belong to URIs by definition of the RFC. URIs are ASCII strings. But your claim, I think, should be read as "in a foaf:name, not in an identifier". Web standards disagree with you all over the place: RDF 1.1, OWL 2, SPARQL 1.1, SHACL all are based on IRIs with a wide range of Unicode strings. Even the WHATWG living standard URL allows a vast range of Unicode strings. And obviously, the W3C Internationalization Working Group and Interest Group disagree.

Hi all! Seems that I have missed a lot of back-and-forth here. Most of what has to be said is nicely summerized by @Antoine-Zimmermann in his comment. I'm going to add some in-depth points, but here's the TLDR:
On the one hand, IRI is the way to go for semantic specs (e.g. RDF et al.), and this poses no big problems: the URI<->IRI mapping takes care of HTTP-compatibility and upgradeability (backward compatibility), and well-defined normalization can take care of security issues and compatibility with WHATWG URL. On the other hand, WHATWG URL (sadly) has become the way to go for specs using browser-related dereferenceable identifiers (e.g. HTTP). These specs show a great deal of overlap, but their goals are actually orthogonal to each other. Therefore, nothing prevents us from specifying a WebID as both an IRI and a URL with the HTTP scheme.

Let's start with the most important destinction to keep in mind in this discussion:

URI and IRI are specs that define the syntax of these identifiers, i.e. their (extendable) formal language. They are elegant, versioned standards with concrete and workable grammars. The semantics of each identifier is left to the extending schemes. For example, HTTP defines URIs that stand for resources managed by the HTTP protocol.

WHATWG URL is ... none of that. It is a best-effort to align the historical deviations from URI/IRI by popular browser implementations, as a base for the WHATWG Fetch spec. It is convoluted, cumbersome to work with, has no declarative grammar, and follows a 'live' (versionless) evolution. Moreover, all decisions are made by a handful of people representing the oligopoly of major browsers, and external proposals are notoriously often denied. But this is not the issue. The spec is what it is, and it is followed by numerous libraries and applications. However, the reason why it can not and should not ever replace URI/IRI is that it is precisely NOT an extendable syntax with scheme-dependant semantics: regardless of how broad it proclaims to be, the only schemes WHATWG URL is really concerned with are those that are "fetchable", and the only semantics it is concerned with is the procedural one dictated by the WHATWG Fetch spec.

This difference is important in deciding whether to use URI, IRI and/or URL. For example, it would not make sense for RDF to use URLs, rather than IRIs, since RDF needs identifiers that can stand for anything, and does not (and should not) concern itself with their "fetchability", and thus neither with the convoluted procedures that come with that minority of URL schemes. I'm glad that @TallTed has also realised that:

[@TallTed:] [The RDF-star WG] had substantial discussion about this, [and] did conclude that IRI was the right term for purposes of RDF, though not necessarily for purposes of Web browsing (which the WHATWG is far more focused on).

I therefore fully agree with @pmcb55: conflating URI/IRI with URL disregards this fundamental different purpose between RDF and Fetch.
Keeping that distinction clearly in mind, though, it is also important to stress that this is not an "either/or" situation. If it is the core of a WebID to dereference to its corresponding Document, it should probably be a URL. If it is a characteristic of a WebID that it can also be used as a node in RDF, it should probably also be an IRI. These things do not contradict each other, and I personally think they are both important aspects of a WebID. Moreover, one does not needs complex terminology to define this (as @jonassmedegaard seems to fear): we can literally say that a WebID is both an IRI, and a URL, with the HTTP scheme.
Note that we do not necessarily need to say much more about this. We can add some stricter normalization (e.g. as I proposed for the Solid spec) for security, and we can stress that all IRIs dereferencing to the same Document denote the same Agent (which is otherwise not entirely clear in an RDF context). But apart from that, this is a lot of fuss for something that will hardly have an impact (except for allowing additional characters, of course): I honestly have not seen a single non-URL URI/IRI actually being used; has anyone?

Current definition: WebID uses HTTP URI; WebID Profile Document uses HTTP URL.
More specifically, WebIDs without a fragment identifier needs to be dereferenceable, an HTTP URL (as per 303 requirement).
Specification Orthogonality and Variability becomes relevant:
For specifications to build on the WebID specification, it is useful to not impose tight coupling of Identification with Interaction - I mean behaviour, and not splitting specifications as a way of resolving that concern. Implementations can then use WebID for identification without having to also implement the interaction. Certainly the latter paves the way to Linked Data, and not something that's necessarily isolated to RDF or wherever else a WebID identifier may appear or is used. WebID being an HTTP URI in and itself hints at a potentially dereferenceable resource.
So, the consideration to change from URI to IRI in the specification doesn't have much (or any?) impact on WebIDs with fragment identifiers, but rather impacts WebIDs without fragment identifiers and WebID Profile Documents.
I'd advise against merging the concepts for identification and interaction where IRI/URL need to be expressed, regardless of the potential adoption of IRI in the specification.

However, saying that "special characters belong in foaf:name, not in a URI" is somewhat disingenuous

Please retract this statement, I dont find this acceptable @Antoine-Zimmermann

Melvin, I am sincerely sorry for the inappropriate term. Alas, I had a misunderstanding of the meaning of the term and did not check its definition. I had no intention to mean that you have secret and deceitful motives. Perhaps the words that I was looking for were "somewhat injudicious". I hope this term "injudicious" is not too strongly negative for you and I meant to tone the phrase down by the use of "somewhat".
In all honesty, I regard your opinion as very valuable and I find it sane that you openly expressed your resentment towards this term. For this reason I deeply apologise.

/chair hat on
To all: let's try to give the benefit of doubt before asking for retractions or assuming the worst in people. Doing so is not conductive to a peaceful working environment. If a specific formulation stands out as too harsh, perhaps let's kindly point it out first, asking for clarification. I, myself, was totally unaware of the negative aspects of the word disingenuous, which I had only ever seen used as a synonym of unaware or uninformed. Clearly, I was uninformed about its other meanings! And, in a more general sense, I'm uninformed about most things in life, really.
Insofar as possible, let's assume good faith on everyone's part.

@jacoscaz I appreciate your intention to foster a positive dialogue in our recent exchange with @Antoine-Zimmermann . However, I must express my concern regarding your message's implications.
Using "disingenuous" in our discussions is serious, as it conveys dishonesty or a lack of integrity, which is why I sought a retraction from @Antoine-Zimmermann . While your message aimed to promote understanding, it seemed to undermine the gravity of such accusations, which are critical in a professional setting like W3C where respect and integrity are essential.
I urge you to recognize that professional decorum is vital for a respectful working environment. Equating terms like "disingenuous" with being uninformed can diminish their impact and the group's atmosphere.
I request a reconsideration of your statement to better reflect the balance between good faith communication and maintaining professional standards.
Thank you for considering this perspective. I remain committed to a constructive and respectful dialogue for the benefit of our work.

/chair hat on

it seemed to undermine the gravity of such accusations

I do not mean to sidetrack the conversation, so I'm only going to reply to this topic once. Antoine extended their apologies after recognizing that they were uninformed about the complete meaning of the word disingenuous, as they should have. I'm not saying this should not have happened. Also, I'm not saying that the accusation of being disingenuous is a shallow one. On the contrary, now that I myself have learnt more about the word, I recognize that it is quite grave.
What I am saying, though, is that there's different ways to react when one feels accused of something. Another way could have been Antoine, please clarify what you mean by disingenuous? It comes across as a strong accusation and feels like a personal attack, which accepts that a person might have made a mistake in good faith. English is not my first language and I'm 100% sure I have made much worse mistakes. I'm pretty sure I have made this one, too, as it's very easy as an Italian to pick up disingenuous without fully understanding its implications. Antoine likely speaks French as their first language - he might have made the same mistake.
To sum it up... When there's a reasonable chance of a misunderstanding, which is often the case, ask first. That's it.

/chair hat off
It always strikes me when a little bit of lateral thinking provides options that, in retrospect, should have been obvious.

I'd advise against merging the concepts for identification and interaction where IRI/URL need to be expressed, regardless of the potential adoption of IRI in the specification.

@csarven I think I understand what this means but could you make an example of what you would not merge and how you'd rephrase it?

we can literally say that a WebID is both an IRI, and a URL, with the HTTP scheme.

@woutermont so far, this would be my favorite option as it's the most explicit of them all and leaves little unaddressed.

But apart from that, this is a lot of fuss for something that will hardly have an impact (except for allowing additional characters, of course): I honestly have not seen a single non-URL URI/IRI actually being used; has anyone?

I agree. For me there's no blocker here, just preferences. I used to prefer URL but now I think my first option would be IRI+URL, then URL, then IRI. I'm also interested in Sarven's point.

I'm only going to reply to this topic once ...

@jacoscaz thank you for this wonderfully thoughtful response.  All the more considerate, given that English is not your first language.
First of all, most of the points you raise had already occurred out of band.  I had a wonderful conversation with Antione before you said anything on this thread.  It was amicable and professional, and indeed we were able to discuss several nuances on URIs vs IRIs, where I think we both learnt something.
On the term used I did ask it to be retracted from the public record, for reasons that I think are now understood.  I did not insist on an apology but Antoine graciously offered one, and immediately corrected the record.  That is over and above what I had asked from him, and I can say he was professional and gracious throughout.  Not only did we successfully deescalate the situation, but I think our working relationship was actually improved, as a result.
I do appreciate you offering your wisdom here.  But in truth you need not have intervened, as the situation was already resolved.  Antoine retracted the term and made replied with kind comment, which I then upvoted.  Thank you for caring about the community and taking time out of your day, that shows that you take pride in your work, and illustrates the care you have towards the community.
In this case, however, it was not necessary, but you didnt know as you were not privy to our private communications.  The community comes out stronger, for it, and becomes a more respectful and thoughtful place.
IMHO a textbook example of escalation management and conflict resolution.
I thought I would just clarify this.  Back to topic.

/chair hat on

Therefore, nothing prevents us from specifying a WebID as both an IRI and a URL with the HTTP scheme.

Any strong objections to this approach?

Hi @jacoscaz, all,
After reading through this thread, I agree with the intent of the above approach. But while I agree with the intent, it might not work as written in isolation (i.e., without the important context provided by @woutermont and others).
IRIs are, by definition, a superset of URIs with a wider character set (RFC 3987) than the US-ASCII in URLs, so the short statement creates a contradiction in trying to capture the discussion.
Suggestion: can we separate the normative and non-normative language, to still capture everything but without that contradiction?
Normative: A WebID is an IRI.
Non-normative: A WebID can be generally considered a WHATWG URL with a HTTP(S)/file:/ftp:/mailto:/[Browser-Supported] scheme, although implementers should prepare for the entire IRI space.

/chair hat on
Hello @RubenVerborgh ! Nice to see you around here!
/chair hat off
That seems reasonable. I'm unsure as to whether it would create confusion in those who are not aware of IRI vs. URI. vs. URL etc... but I think that some confusion in their case is inevitable. I like it!

My $0.02.
To access data one will need, at some point an address, meaning a location, meaning a URL. No way around it (unless you have a copy of the data already). URLs are a subset of URIs. So if the standard requires an URI/IRI (personally I am neutral on that), then the standard MUST say something about (at least the existence and necessity of) a resolution mechanism from a non-URL URI, which pretty much means a URN, to a URL. Using a URL as a URI, pretty much implies the lazy identical transformation as a resolution mechanism. But that should be more of the exception than the norm.

Non-normative: A WebID can be generally considered a WHATWG URL with a HTTP(S)/file:/ftp:/mailto:/[Browser-Supported] scheme, although implementers should prepare for the entire IRI space.

Note that one of the significant blocks to consensus on the 2014 ED was the requirement that WebID URIs be in the HTTP(S) scheme.
Since at least 2014, OpenLink Software has been using NetID to refer to a superclass of WebID, with NetID supporting URIs of many schemes. For more, see A Quick Note on WebID history, particularly these historical perspective links therefrom —

NetID and NetID-TLS Presentation (circa 2014)
NetID Entry in W3C RWW wiki
Tweets about NetID, starting in 2014

Bottom line here, the "Non-normative" snippet above describes a NetID, not a WebID, unless we do some more radical reworking of the existing spec of WebID.

/chair hat on
To all, let's keep this discussion focused on URI vs. IRI vs. URL . WebID is HTTP(S) only, for now, but we can discuss in a separate issue if anyone wants to do so.

If a WebID has been established to be an HTTP URI that names an Agent.... Isn't it logical to presume that IRI introduction simply implies:
A WebID is an HTTP IRI that names an Agent...
Have I overlooked something here?
SeeAlso:
CoPilot (i.e., ChatGPT lookup)

Non-normative: A WebID can be generally considered a WHATWG URL with a HTTP(S)/file:/ftp:/mailto:/[Browser-Supported] scheme, although implementers should prepare for the entire IRI space.

Hi @RubenVerborgh.  Nice to see you here & thanks for chiming in.
I think you've hit on a critical thing.  @timbl has repeatedly said that the file and http spaces (and ftp) are part of the web.  It's a subtle point, but one with immense power.  Regarding mailto: I see it as an important massively deployed scheme, but somewhat different in terms of ability to derference it.
There is lots of merit and utility to this broader world view, that is not communicated in WebID-* type specifications.

NetID Entry in W3C RWW wiki

Even though I co-authored this entry while chair of the RWW group NetID is not a web standard, it's IMHO an OpenLink initiative.
It also has a name clash with several other projects, are you sure it's not trademarked?
https://enid.foundation/en/

Have I overlooked something here?

Yes, if there's an intention to change or expand the well-established definition from it's original HTTP URI (and personally I dont think now is the time to do that), that opens the consideration WebID could be generally considered a WHATWG URL.

Yes, if there's an intention to change or expand the well-established definition from it's original HTTP URI (and personally I dont think now is the time to do that), that opens the consideration WebID could be generally considered a WHATWG URL.

There is no such intention.
It would be helpful if you could articulate how an HTTP IRI and an HTTI URI differ, in a manner that extends beyond what I articulated in my response.

NetID is not a web standard, it's IMHO an OpenLink initiative.

Who said it was?
@TallTed was clarifying the context around the use of "NetID" as the term we (OpenLink Software) employ in our products for Agent Naming, which encompasses more than just HTTP URIs.
Expanding Agent Naming to include identifiers beyond HTTP URIs necessitates the creation of lookup handlers for each protocol scheme.  That's the cost an implementer incurs when seeking to integrate other schemes into the World Wide Web.

@timbl has repeatedly said that the file and http spaces (and ftp) are part of the web.

Where and when did he say that? Note, there's a significant difference between "they can be part of the World Wide Web" or "integrated into the World Wide Web" and "they are part of the World Wide Web".

actually file: space is also the web

Timbl said this to us in 2017

if there's an intention to change or expand the well-established definition from it's original HTTP URI

There is no such intention.

It might help if you clarified this.
Are you saying there is no intention to change or expand the definition of WebID from its original HTTP URI?

/chair hat on
It's fairly important for the conversation to remain focused and not expand towards concerns that are orthogonal to the topic that this issue focuses on. Regardless of the scheme / protocol, this issue deals with the difference between IRI, URI, URL (in the W3C sense) and URL (in the WHATWG sense).
Whether a non-HTTP(S) IRI / URI / URL can be a WebID or not is a different topic, which I kindly ask everyone to address in a separate issue.

/chair hat on
Does anyone object, strongly or not, to @RubenVerborgh 's proposal in https://github.com/w3c/WebID/issues/10#issuecomment-1932441361 , which I quote below with a slight edit to limit the scope of this issue to the URI vs. IRI vs. URL debate?

Suggestion: can we separate the normative and non-normative language, to still capture everything but without that contradiction?
Normative: A WebID is an IRI.
Non-normative: A WebID can be generally considered a WHATWG URL with a HTTP(S) scheme, although implementers should prepare for the entire IRI space.

/chair hat on
Note that this could be easily addressed by using the normative and non-normative language proposed by @RubenVerborgh  and referring to https://www.w3.org/TR/rdf12-concepts/#section-IRIs for anything not covered here. We should try not to duplicate things that are already covered by more foundational specs.

authors: Antoine-Zimmermann RubenVerborgh TallTed csarven hzbarcea jacoscaz jonassmedegaard kidehen melvincarvalho pmcb55 woutermont


text:
group which produced the document

It would be nice to pull out the group which produced a given document; this is information which for W3C documents is given in the "Status of this document" with e.g. "This document was produced by the CSS Working Group as a Candidate Recommendation", which is recorded in tr.rdf if not the W3C API

The info should be added to the list of specs exported by browser-specs. Feature is being tracked there in https://github.com/w3c/browser-specs/issues/32
Reffy could just copy the info over once available in browser-specs.

Browser-specs started to include info about groups early July and that info gets includes in crawl reports. Closing this issue accordingly.

authors: gsnedders tidoust


text:
SyntaxError when starting creevey

After updating 0.0.30 -> 0.6.4 I've got the error at start.
storybook version - 5.3.17

[FAIL:28188] C:\billy\frontend-tasks\docs\node_modules@babel\runtime\helpers\esm\inheritsLoose.js:1
export default function _inheritsLoose(subClass, superClass) {
^^^^^^
SyntaxError: Unexpected token export
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module.load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at eval (webpack:///external%22@babel/runtime/helpers/esm/inheritsLoose%22?:1:18)
at Object.@babel/runtime/helpers/esm/inheritsLoose (C:\billy\frontend-tasks\docs\report\storybook\storybook.js:19860:1)
at webpack_require (C:\billy\frontend-tasks\docs\report\storybook\storybook.js:20:30)
[FAIL:28188] TypeError: Cannot set property 'innerHTML' of null
at showErrorDisplay (C:\billy\frontend-tasks\docs\node_modules@storybook\core\dist\client\preview\start.js:131:62)
at showException (C:\billy\frontend-tasks\docs\node_modules@storybook\core\dist\client\preview\start.js:162:3)
at StoryStore.renderUI (C:\billy\frontend-tasks\docs\node_modules@storybook\core\dist\client\preview\start.js:431:9)
at StoryStore.emit (C:\billy\frontend-tasks\docs\node_modules\eventemitter3\index.js:201:33)
at Timeout._onTimeout (C:\billy\frontend-tasks\docs\node_modules@storybook\client-api\dist\story_store.js:357:16)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)
at Timer.processTimers (timers.js:223:10)
error Command failed with exit code 4294967295.

Hi. Try to use creevey@next. I'll take a look why this happened

0.7 fixes the issue, thank you

authors: Raykeen wKich

repo: wKich/creevey


text:
限售股解禁接口-share_float  很多数据没有【公告日期】ann_date

业务描述：
后面的每天更新最新的数据时需要根据ann_date 来查询，如果ann_date字段没有数据就会造成公告日期的数据查询不到
谢谢作者～
会员账号：18521398694

这种情况可以用其他参数来过滤

好的

repo: waditu/tushare


text:
🛑 Wagestream UK Public Website is down

In fac8d9e, Wagestream UK Public Website (https://wagestream.com/en/) was down:

HTTP code: 429
Response time: 106 ms

Resolved: Wagestream UK Public Website is back up in a6a7aa6 after 7 minutes.

repo: wagestream/statuspage


text:
🛑 Wagestream ES Public Website is down

In b576ec9, Wagestream ES Public Website (https://wagestream.com/es/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wagestream ES Public Website is back up in 1250474.


text:
bug: Wagmi createClient error 500, when using lineaTestnet

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
when i remove lineaTestnet, then its working fine
import { lineaTestnet, arbitrumGoerli } from 'wagmi/chains';

 const { chains, provider, webSocketProvider } = configureChains(
    [lineaTestnet, arbitrumGoerli],
    [
      infuraProvider({ apiKey: process.env.NEXT_PUBLIC_INFURA_API_KEY }),
      publicProvider(),
    ],
  );

Expected Behavior
Should be able to connect linea testnet via infura

Steps To Reproduce
wagmi version: ^0.12.12
import { lineaTestnet, arbitrumGoerli } from 'wagmi/chains';

 const { chains, provider, webSocketProvider } = configureChains(
    [lineaTestnet, arbitrumGoerli],
    [
      infuraProvider({ apiKey: process.env.NEXT_PUBLIC_INFURA_API_KEY }),
      publicProvider(),
    ],
  );

    const connectors = connectorsForWallets([
    {
      groupName: 'Recommended',
      wallets: [
        injectedWallet({ chains }),
        rainbowWallet({
          chains,
          projectId: process.env.NEXT_PUBLIC_INFURA_PROJECT_ID,
        }),
        metaMaskWallet({
          chains,
          projectId: process.env.NEXT_PUBLIC_INFURA_PROJECT_ID,
        }),
        coinbaseWallet({ chains, appName: 'test' }),
        walletConnectWallet({
          chains,
          projectId: process.env.NEXT_PUBLIC_INFURA_PROJECT_ID,
        }),
      ],
    },
  ]);
  const wagmiClient = createClient({
    autoConnect: true,
    connectors,
    provider,
    webSocketProvider,
  });

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
tested to replace
     readonly infura: {
            readonly http: readonly ["https://consensys-zkevm-goerli-prealpha.infura.io/v3"];
            readonly webSocket: readonly ["wss://consensys-zkevm-goerli-prealpha.infura.io/ws/v3"];
        };
with

 rpcUrls: {
    infura: {
      http: ['https://linea-goerli.infura.io/v3'],
      webSocket: ['wss://linea-goerli.infura.io/v3'],
    },

but still getting same error,
I tested infura rpc url https://linea-goerli.infura.io/v3 is working to get ethBalance

https://github.com/wagmi-dev/wagmi/issues/2509

repo: wagmi-dev/references


text:
bug: TypeScript useContractWrite requires type casting param to UseContractWriteConfig

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
1.0.2
Current Behavior
Using documentation's recommendation for hook usePrepareContractWrite:
  const { config } = usePrepareContractWrite({
    address: '0xecb504d39723b0be0e3a9aa33d646642d1051ee1',
    abi: wagmigotchiABI,
    functionName: 'feed',
  })

Throws an error on all fields of the param:

Which seems to be fixed by type casting to UsePrepareContractWriteConfig:

This is also true with the useContractWrite hook and resolvable by type casting to UseContractWriteConfig.
Expected Behavior
The type should be inferred.
Steps To Reproduce
No response
Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)
No response
Anything else?
No response

@hexcowboy - I've been having a similar issue. I haven't been able to reproduce in a standalone app. I've been trying to figure out if it has something to do with another package or TS config. Would you mind posting your TS config and package.json?

I can't seem to reproduce here either: https://www.typescriptlang.org/play?target=8#code/JYWwDg9gTgLgBAbzgVwM4FMAKV1gIY4DCEAdjFHgMYwDqUwM6ANHOlJQOwBMAjAIIAhAJJwAvnABmUCCDgByAO54A5iGByAUBrRYc+IqXJVa9RgAoEGuNbh4ARsABcrdt37CmVm3gAmPnKioznIADAAecp42ksgk1MCkAHJ4IOjBqHgS6AAqFCSoWVAAYtIgkV7WBMpBcADaoREsDZFwPCQAup6iAJRAA
Can you please provide a minimal reproducible example (via a separate repo or https://new.wagmi.sh)? Will re-open when one is provided!

https://github.com/wagmi-dev/wagmi/issues/2328#issuecomment-1546920624

authors: gentle-noah hexcowboy jxom

repo: wagmi-dev/wagmi


text:
Image chooser is rendered with incorrect width when "Status" sidebar is open

Issue Summary
While the Status sidebar is open (the one on the right side of the Page Editor, which contains the Privacy settings), an Image Choosers inside a modal dialog is rendered at an incorrect width.
Steps to Reproduce

Run Bakerydemo and edit any page.
Open the Status sidebar on the right.
Open an Image Chooser.

The chooser will be smooshed into the left 2/3s of the modal dialog, forcing it to flow incorrectly.
This is happening because of the following CSS rule in core.css:
@media screen and (min-width: 56.25em) {
    .side-panel-open .tab-content {
        width:66.666667%
    }
}

I believe the issue is that the rule is too broad, and is accidentally applying to modal dialogs' contents in addition to the main page editor contents that it's supposed to be acting on.
Technical details
This happens in Bakerydemo when run through GitPod, which is running Wagtail 4.2.1. I'm running Chrome v111.

Hi,
Yeah, I was able to replicate the bug too. I'm running latest bakerydemo on GitPod too, Opera GX
NO STATUS SIDEBAR

WITH STATUS SIDEBAR

Like @coredumperror suggests, the issue seems to be within wagtail package itself, possibly in the components/Sidebar directory of client as it keeps sidebar toggled on even when any panel is opened on top of it and applies the media-breakpoint-up

repo: wagtail/wagtail


text:
Consider adding an opensearch for wagtail.wagtailsearch

I think it would be good addition! I know there's a few ready django apps for this purpose(like django-opensearch), but having such option in wagtail out of the box will be great!

We won’t get that in Wagtail itself for now, until OpenSearch is more widely used.
However, it’s easy to create a third-party app serving XML files following the OpenSearch specification and using the Wagtail search API inside its views.
So feel free to create such a third-party app and add it to https://github.com/springload/awesome-wagtail! :)

authors: BertrandBordage MechanisM


text:
Add README.ja.md

PR description | PR 描述
Hello!
I added Japanese language to README.

Thanks!

repo: wailsapp/awesome-wails


text:
🛑 cyconet.org is down

In c893097, cyconet.org (https://www.cyconet.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cyconet.org is back up in 9a4b50d after 4 hours, 46 minutes.

repo: waja/cyconet-upptime


text:
🛑 cyconet.org is down

In 017bcfd, cyconet.org (https://www.cyconet.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cyconet.org is back up in ff9f96e after 54 minutes.


text:
🛑 cyconet.org is down

In defb3ea, cyconet.org (https://www.cyconet.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cyconet.org is back up in 28946ce after 2 hours.


text:
🛑 Mail IMAP is down

In 54a06d8, Mail IMAP ($MAIL_HOST) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mail IMAP is back up in 563d489 after 11 minutes.


text:
Possible locale next/prev button custom text bug?

Example - https://codepen.io/TincanPipPip/pen/f42dc4a71fba9dd153c553b721847f38?editors=0010
I'm not sure if this is just because I'm using an SVG as the custom text, but when doing this, only the area around the svg is clickable, the svg element itself isn't so the next/prev month event isn't fired.
Cheers
Harry

Hi,
I guess svg has not been used for these buttons before.
You can add this css, then the whole button will be clickable.
button.lightpick__previous-action > svg,
button.lightpick__next-action > svg {
    pointer-events: none;
}

Hiya,
Yeah I went a different route (but that's a really good idea), isn't a deal breaker, just wondered if it was a bug or not
Cheers
Harry

authors: harrync wakirin

repo: wakirin/Lightpick


text:
Decouple/Replace SpongyCastle

Ideally SpongyCastle should be gone completely to allow multi-platform use cases in the future and work towards #1 . But I did not yet find a replacement library in Kotlin for it. I think it might be possible to extract and convert the needed functions from SpongyCastle - but this needs to be audited. So it also needs to be decoupled. This way users can stick to the well-tried SpongyCastle until the replacement gained trust.
acceptance criteria:

option to not use spongycastle anymore (replace with plain kotlin alternative - goal is to get rid of JVM dependency)
initializeCrypto() is gone there also ;-)

Update on my plan:

Remove all spongycastle dependencies (except for crypto module)
Fix errors by extracting everything into custom classes in the crypto module
Move all spongycastle specific extensions from the crypto module to a crypto_spongy module

This would allow that in the future you have another crpyto_ module that implements all the spongy stuff in pure kotlin

Sounds great! Looking forward to it.

@ligi should I also move all javax.crypto to that abstraction layer?

@rmeissner let me know if you want to do https://gitcoin.co/issue/walleth/kethereum/43 as well, happy to pay a tip :p

@ceresstation I am generally interested in the topic, not sure if I will be able to pick it up soon (next 2 weeks) I will let you know ;)

authors: ceresstation ligi rmeissner

repo: walleth/kethereum


text:
Make logging consistent:

We have "print", "wandb.termlog", click logging etc.

I think we've moved everything to wandb.termlog at this point.  Feel free to reopen if this is still an issue.

authors: lukas shawnlewis

repo: wandb/client


text:
[Feature] Export Table to CSV

It would be super nice if we could Export/Download the Table as csv (just like we can export the graphs).
My use case is I'm logging table-data to wandb across runs, and I would like to download the full concatanated table as a csv.

When a table is viewed within a run workspace there should be a "download" button in the upper right.  Are you able to see this?

No, all I see are these controls:

It would be really nice to have this feature, because it's not possible to replace it with anything else.
I can't log an artifact from multiple runs, nor can I join data from multiple runs from the GUI.

You probably missunderstood me, what I meant was the table from the "Tables" pane, where we log data manually:

Ahh I see.  Adding a CSV export to tables is definitely on the road map.  Until then you can export the data programmatically:
import wandb
import csv

api = wandb.Api()
art = api.artifact("USERNAME/PROJECT/run-RUN_ID-rewards:v0")
table = art.get("rewards")

with open("rewards.csv", "w", newline="") as f:
  writer = csv.writer(f)
  writer.writerow(table.columns)
  for row in table.data:
    writer.writerow(row)

What I meant is I want the data for all the runs (the resulting concatenated table).
The reason this is useful is because during a sweep I can have multiple workers log to the same table, at the same time, and after my sweep is done I can get a concatenated table.

@drozzy we have created an internal ticket for this feature. I'll notify you once this is possible.

authors: armanhar drozzy vanpelt


text:
Adds verbosity to the tox.ini pytest

Description
What does the PR do?
adds verbosity flag to pytest command
Before:

After:

Testing
How was this PR tested?
N/A
Checklist

Include reference to internal ticket "Fixes WB-NNNN" (and github issue "Fixes #NNNN" if applicable)

actually... it's great as is, but maybe make it configurable with -vv as the default? I sometimes find myself doing -vvvv when debugging.

actually... it's great as is, but maybe make it configurable with -vv as the default? I sometimes find myself doing -vvvv when debugging.

I don't think higher verbosity levels have any effect (according to the pytest docs):

actually... it's great as is, but maybe make it configurable with -vv as the default? I sometimes find myself doing -vvvv when debugging.

I don't think higher verbosity levels have any effect of pure pytest and I just wanted to have a more organized view... (according to the pytest docs):
what are the things you get with higher verbosity?

Anyways I updated the verbosity @dmitryduev let me know if that is what you meant?

authors: dmitryduev kptkin