This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, I have few questions: === In URL(url, base) constructor: https://url.spec.whatwg.org/#dom-url step 4. looks strange 4. Let result's get the base return base. Why this return something here (and probably leave this algorithm now)? "base" varaible is used earlier and take the result of parse base argument (step 1.). Step 5. invoke "set the input" which has in step 3. another get the base (not using above passing second argument). This URL() constructor alghoritm should better cover situation when we pass second argument. And what exactly should happend when I explicity pass "about:blank" ass second argument (or skip it), where can find step that handle this situation in "basic URL parser"? === Anne can you give example for URLUtils when asociated url is null? I try get if for HTMLAnchorElement and using empty string: https://html.spec.whatwg.org/multipage/semantics.html#the-a-element:attr-hyperlink-href-7 "When the element is created, and whenever the element's href content attribute is set, changed, or removed, the user agent must invoke the element's URLUtils interface's set the input algorithm with the value of the href content attribute, if any, or the empty string otherwise, as the given value." but get strange result in Firefox and not sure what is correct. Look: <a id="a1"></a> <a id="a2" href></a> <script> var a1 = document.getElementById("a1"); var a2 = document.getElementById("a2"); document.write(a1 + "<br>"); // empty string document.write(a1.searchParams.append + "<br><br>"); // function append() { [native code] } document.write(a2 + "<br>"); // actual documents url document.write(a2.searchParams.append + "<br>"); // function append() { [native code] } </script> By HTML this example should pass empty string to "set the input" algorithm, but I get different result for a1 and a2 anchor. In both case asociated query object exist, but probably shouldn't (should be null). I know that Firefox doesn't implement new URL parser yet, but what in theory should happend when we use empty string like above (or just change some existing URL by setting href to empty string), we should set asociated url to null or to new URL (with has default values for all components)? BTW, if asociated query object can be null or URLSearchParams then probably this IDL should be correct: attribute URLSearchParams searchParams; << change to attribute URLSearchParams? searchParams; and correct setting searchParams steps.
(In reply to Arkadiusz Michalski (Spirit) from comment #0) > step 4. looks strange > 4. Let result's get the base return base. > > Why this return something here (and probably leave this algorithm now)? This does not return anything. "get the base" is a function of URL objects and here is defined to return /base/. > Step 5. invoke "set the input" which has in step 3. another get the base > (not using above passing second argument). That actually is the get the base that was just defined. > This URL() constructor alghoritm should better cover situation when we pass > second argument. How is that not covered? > And what exactly should happend when I explicity pass "about:blank" ass > second argument (or skip it), where can find step that handle this situation > in "basic URL parser"? It doesn't really matter. about:blank just gives you a non-relative URL. > Anne can you give example for URLUtils when asociated url is null? When you parse an invalid URL. > By HTML this example should pass empty string to "set the input" This seems like a bug in HTML. An element without href should not be a link. > BTW, if asociated query object can be null or URLSearchParams then probably > this IDL should be correct: > > attribute URLSearchParams searchParams; << change to attribute > URLSearchParams? searchParams; > > and correct setting searchParams steps. I think query object is always set to a URLSearchParams object by the time it matters. If you think that should be phrased in a different way somehow please file a bug for that.
> This does not return anything. "get the base" is a function of URL objects > and here is defined to return /base/. Ohh, now clear and other questions in this area are negligible. > I think query object is always set to a URLSearchParams object by the time > it matters. If you think that should be phrased in a different way somehow > please file a bug for that. Probably not alwyas set when analise all alghoritms, but before open new bug I need one answear for this: "what happend when empty string will be pass to basic URL parser" without passing any optional arguments. - algo return new URL (with has initial values for all components), whats mean step 8.(state machine) not run (or run but jump to step 9.) and algo not return error or terminate. - algo return error or terminate in some state in step 8., but which state: "scheme start state" or "no scheme state"?
(In reply to Arkadiusz Michalski (Spirit) from comment #2) > - algo return error or terminate in some state in step 8., but which state: > "scheme start state" or "no scheme state"? Returns failure in no scheme state. However, https://github.com/whatwg/url/pull/4 regressed this. :-(
I'm not following how the pull request regressed this. Traceing my implementation, I get: # Running: [:scheme_start_state, :eof] [:no_scheme_state, :eof] F This is the desired result, no?
So in step 8. "If after a run..." means this condition is checked after all steps from some state are done or something else? I made 3 variant of interpreate this, what is correct (probably 1)? 1 variant: [scheme start state] "If after a run..." [scheme state] "If after a run..." and next state or 2 variant: "If after a run..." [scheme start state] "If after a run..." [scheme state] and next state or 3 variant: "If after a run..." [scheme start state] [scheme state] and next state If first variant is correct that I too don't see any regresion here but its important how we should interpretate "If after a run...".
Yeah seems fine per http://krijnhoetmer.nl/irc-logs/whatwg/20141014#l-696
Filed bug 27047 on HTML by the way. I guess we can close this?
Yes, you can close, if necessary I will reopen.