-
Notifications
You must be signed in to change notification settings - Fork 22
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
Conversation
5f238be
to
54e2817
Compare
@domenic PTAL. |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
54e2817
to
111da60
Compare
111da60
to
bce1764
Compare
There was a problem hiding this 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.
Preview | Diff