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

Replace 'should treat as standard URL' terminology. (Fixes #111) #112

Merged
merged 1 commit into from
Sep 1, 2021

Conversation

wanderview
Copy link
Member

@wanderview wanderview commented Sep 1, 2021

@wanderview
Copy link
Member Author

@domenic PTAL.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "standard pathname" also problematic?

spec.bs Outdated
<p class="note allow-2119">We must eagerly compile the protocol component to determine if it matches any [=special schemes=]. If it does then we treat the URLPattern constructor string as a "standard URL". The determines if the pathname defaults to a "`/`" and also whether we should look for the username, password, hostname, and port components. Authority slashes may also cause us to look for these components as well. Otherwise we treat this as a "cannot be a base URL" and go straight to the pathname component.
1. If |parser|'s [=constructor string parser/should treat as a standard URL=] is true, then set |parser|'s [=constructor string parser/result=]["{{URLPatternInit/pathname}}"] to "`/`".
1. Run [=compute protocol matches a special scheme flag=] given |parser|.
<p class="note allow-2119">We must eagerly compile the protocol component to determine if it matches any [=special schemes=]. If it does then certain special rules apply. It determines if the pathname defaults to a "`/`" and also whether we should look for the username, password, hostname, and port components. Authority slashes may also cause us to look for these components as well. Otherwise we treat this as a "cannot be a base URL" and go straight to the pathname component.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to fix the allow-2119 while you're here. E.g. must -> need to, should -> will. Right now it's pretty confusing that you only "should" do those things, which implies an implementation might not do so.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the allow-2119 here.

I'm not sure what to replace "standard pathname" with. "Hierarchical pathname"? "Can-be-a-base-URL pathname"? "Pathname with slashes"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the URL spec just calls it "path" and "cannot-be-a-base-URL path".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of like "pathname with slashes", but "can-be-a-base-URL pathname" might be more in line with URL spec terminology.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with just "pathname" and "cannot-be-a-base-URL pathname" like the URL spec. WDYT?

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. "pathname" + "cannot-be-a-base-URL pathname" seems less clear than "can-be-a-base-URL pathname" + "cannot-be-a-base-URL pathname", but it's more symmetric with the URL Standard so yeah, we'd probably want to make any changes there first.

@wanderview wanderview merged commit b091743 into main Sep 1, 2021
@wanderview wanderview deleted the dev-should-treat branch September 1, 2021 19:03
crowlKats added a commit to crowlKats/rust-urlpattern that referenced this pull request Sep 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants