Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate any valid spec URL #84

Open
1 of 3 tasks
ddbeck opened this issue Mar 7, 2023 · 6 comments
Open
1 of 3 tasks

Validate any valid spec URL #84

ddbeck opened this issue Mar 7, 2023 · 6 comments

Comments

@ddbeck
Copy link
Collaborator

ddbeck commented Mar 7, 2023

via #78

What I want

  • To be able to link to any valid page (or fragment) within a specification known to web-specs
  • To not be able to link an invalid page (or fragment) within a specification known to web-specs
  • To not be able to link to a specification unknown to web-specs

How it works now

Right now, the tests allow linking only to the single URL known to web-specs. For example https://html.spec.whatwg.org/multipage/ is a valid spec URL, but https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements is not.

How it could work in the future

We could change the tests to allow any valid derivative URL (i.e., any URL where the scheme and domain are the same and the path starts with the path known to web-specs).

If we wanted to go further, we could periodically scrape spec URLs to fully enumerate all of the pages and anchors and validate against them (I don't think this would be too bad—there's not that many specs, but not exactly zero effort).

@foolip
Copy link
Collaborator

foolip commented Mar 25, 2024

@ddbeck do you think we need to do more than we're already doing for this?

@ddbeck
Copy link
Collaborator Author

ddbeck commented Mar 26, 2024

@foolip We don't need to do anything, but we should probably log the idea somewhere that we wanted to validate the URL fragments (see also: w3c/browser-specs#931). More nice-to-have than need-to-have (at least for now).

@foolip
Copy link
Collaborator

foolip commented Mar 26, 2024

Ah, so given that w3c/browser-specs#931 was done we could write some code now.

I think we'd also be well served by aligning exactly with the rules that BCD uses, and there are some minor differences. But how? A new package that both depend on feels like a bit much? Perhaps browser-specs and web-specs itself should have a validation function?

@ddbeck
Copy link
Collaborator Author

ddbeck commented Mar 27, 2024

Perhaps browser-specs and web-specs itself should have a validation function?

Maybe? I'm not sure how that interacts with web-ref, which knows about the fragments themselves.

But it seems to me that a reverse lookup would make the most sense, given the goals browser- and web-specs: you give it a complete URL and you get back the corresponding spec object. We'd just check for success or failure.

@tidoust
Copy link
Member

tidoust commented Mar 27, 2024

Perhaps browser-specs and web-specs itself should have a validation function?

Not sure if that's meant to cover fragments. If so, I don't think we'll include them in browser-specs directly. We can look into providing the information in a more directly usable way in Webref though. Webref effectively contains browser-specs, so it should be possible to get all the validation info you need relying on Webref rather than on browser-specs.

@foolip
Copy link
Collaborator

foolip commented Mar 27, 2024

Ah, right, it was fixed for pages, not fragment identifiers...

I've filed w3c/webref#1198 for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants