Re: [whatwg] Document's base URI should use the document's *current* address
From an author's point of view, there's no such thing as the
document's original URI and, unless you're a nerd, you've never heard
of the base URI. There's just the document's URI, modified by
pushState.
From this point of view, I'd say it's less surprising that relative
URIs would break when you change directories (hey, you *asked* for it)
than that anchor refs would update the browser's address bar and
document.location relative to the old URI.
In my tests, Chrome and Firefox both immediately change
document.baseURL when you call pushState. Images (and I presume other
resources) are resolved relative to the new base.
I'm not sure why your earlier test with seemed to work in Chrome, Hixie. :-/
I think this ship may have sailed.
-Justin
button onclick='push()'Click me/button
function push() {
history.pushState('', '', '/' + Math.random() + '/file');
alert(document.baseURI);
}
Re: [whatwg] including output in form submissions
On Tue, Feb 21, 2012 at 10:48 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 13 Sep 2011, Michael Gratton wrote: HTML5 does not provide a means of submitting form content that is otherwise rendered as normal text, i.e. not as a form control. The use cases for this are the same as for the output element, but when it is also desirable for the result of a calculation to be sent to the server when the form is submitted. Currently, the only way to implement this is to maintain two copies of the value, one the child text of an output element (or something similar, for example a td or span) and once in the value of an input type=hidden element, using appropriate scripting to keep the two in sync. This is error prone and places an additional burden on the web page author. This can be remedied by allowing the value of output elements to be submitted. That is, include the output element in the submittable form-associated element category. I initially thought that this was precisely what the output element existed for - it was rather surprising when I tried using them but none of the values were appearing in the submission. You can work around this by just assigning the value to a hidden input when you assign it to the output control. But in general, I recommend against this. Anything that can be computed should be computed on the server to obtain the canonical value, otherwise you open yourself up to attackers sending you inconsistent data. This is based on the assumption of same origin web forms. If a request is being generated from a 3rd party web site to an open public web service, the 3rd party may choose to represent the input using methods or calculations unknown to the target web service and irrespective to the required request format. If a nefarious script has access to the DOM they are capable of doing anything, including changing input values on submit, or submitting whole new requests with whatever data they like. Updating output as form submittable element is included in a proposal to enhance http request processing under a w3c issue: http://www.w3.org/html/wg/tracker/issues/195 And proposal: (Note: changes pending, see issue thread) http://www.w3.org/wiki/User:Cjones/ISSUE-195 On Wed, 14 Sep 2011, Michael Gratton wrote: [As an aside, it just occured to me that it would also be helpful if output supported the type attribute, for most of the same values as input now does in HTML5, for much the same reason as it makes sense for input.] It makes sense for input because it lets the browser know what interface to give to the user to let the user change the value... How does that make sense for output? -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' The type attribute is a discriminator over an otherwise indistinguishable text value which enables machine processing which would otherwise not be possible or be more error prone. It has value for input, output and data as recommended in a alternative-proposal to w3c issue to add data element: http://www.w3.org/html/wg/tracker/issues/184 And proposal: http://www.w3.org/wiki/User:Cjones/ISSUE-184 Thanks, Cameron Jones
[whatwg] Review and Browser Vendor Interest in Form Enhancement
Hi, I've submitted a proposal to w3c issue 195 which stems from requests to provide support for additional HTTP methods on forms with specific reference to clients without scripting support. The proposal is based on extending the functionality of forms by exposing the abilities of XHR to declarative markup. I'm keen to highlight the issue to solicit review and feedback on the proposal, and to harvest some degree of the level of interest from browser vendors as to the desirability of implementing the proposal. The proposal itself includes the rationale and details pertaining to the changes. There has been some initial feedback on public-html however i am yet to update the proposal with the recommendations. These amount to: * Implement method attribute values as a blacklist instead of a whitelist * Exclude CONNECT and TRACK methods in addition to TRACE as blacklisted items for synchronicity with XHR specification * Remove _none payload attribute state and replace functionality with disabled attribute and state * Look at replacing _async_ form control field as a form submit element attribute for form, button input retargeting. Proposal: http://www.w3.org/wiki/User:Cjones/ISSUE-195 Issue 195: http://www.w3.org/html/wg/tracker/issues/195 Thanks, Cameron Jones
Re: [whatwg] Review and Browser Vendor Interest in Form Enhancement
Last time I asked around, there didn't seem to be much demand for these features so I didn't implement the previous version that was in the HTML spec. Adam On Wed, Feb 22, 2012 at 9:33 AM, Cameron Jones cmhjo...@gmail.com wrote: Hi, I've submitted a proposal to w3c issue 195 which stems from requests to provide support for additional HTTP methods on forms with specific reference to clients without scripting support. The proposal is based on extending the functionality of forms by exposing the abilities of XHR to declarative markup. I'm keen to highlight the issue to solicit review and feedback on the proposal, and to harvest some degree of the level of interest from browser vendors as to the desirability of implementing the proposal. The proposal itself includes the rationale and details pertaining to the changes. There has been some initial feedback on public-html however i am yet to update the proposal with the recommendations. These amount to: * Implement method attribute values as a blacklist instead of a whitelist * Exclude CONNECT and TRACK methods in addition to TRACE as blacklisted items for synchronicity with XHR specification * Remove _none payload attribute state and replace functionality with disabled attribute and state * Look at replacing _async_ form control field as a form submit element attribute for form, button input retargeting. Proposal: http://www.w3.org/wiki/User:Cjones/ISSUE-195 Issue 195: http://www.w3.org/html/wg/tracker/issues/195 Thanks, Cameron Jones
Re: [whatwg] including output in form submissions
2012-02-22 19:30, Cameron Jones wrote: Updatingoutput as form submittable element is included in a proposal to enhance http request processing under a w3c issue This sounds like a pointless attempt at enhancing a pointless element. Instead of output, authors can use, and have been able to use since rather early days, input if the data is to be submitted as part of form data, and any non-form-field element, like div, otherwise. (Well, in the very early days, it had to be input anyway, but that was long ago.) output is just for looking semantic for semantics' sake. There is nothing illogical in using input for data that is generated (not directly user-supplied) client-side. It's input to form handlers, client-side or server-side, anyway. And there's nothing particularly semantic (i.e., as relating to meaning) about saying that some content is the output of some calculation. If a value is 42, its being in output does not indicate its meaning in any way. output has _some_ effects: it confuses authors, if they wish to be serious about new specifications. So please drop output. Yucca
Re: [whatwg] Review and Browser Vendor Interest in Form Enhancement
On Wed, Feb 22, 2012 at 5:38 PM, Adam Barth w...@adambarth.com wrote: Last time I asked around, there didn't seem to be much demand for these features so I didn't implement the previous version that was in the HTML spec. Adam I've responded to repeated requests on public-html and public-html-comments for these features, specifically PUT and DELETE support. I've also noted repeated requests on hacker news and stack overflow. My experience is this is a feature which isn't going away and with greater numbers of ReSTful web services the demand and applicability will only grow. The previous omission of declarative authoring of request headers exhibited the lack of a complete solution which is what this proposal addresses in an integrated and compatible design. Thanks, Cam
Re: [whatwg] including output in form submissions
On Wed, Feb 22, 2012 at 6:01 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2012-02-22 19:30, Cameron Jones wrote: Updatingoutput as form submittable element is included in a proposal to enhance http request processing under a w3c issue This sounds like a pointless attempt at enhancing a pointless element. Instead of output, authors can use, and have been able to use since rather early days, input if the data is to be submitted as part of form data, and any non-form-field element, like div, otherwise. (Well, in the very early days, it had to be input anyway, but that was long ago.) output is just for looking semantic for semantics' sake. There is nothing illogical in using input for data that is generated (not directly user-supplied) client-side. It's input to form handlers, client-side or server-side, anyway. And there's nothing particularly semantic (i.e., as relating to meaning) about saying that some content is the output of some calculation. If a value is 42, its being in output does not indicate its meaning in any way. output has _some_ effects: it confuses authors, if they wish to be serious about new specifications. So please drop output. Yucca It does provide a greater degree of integration with the browser though. This results in a less scripting being required and allows for inline scripting to be more concise which aids readability and keeps things together. It's also possible for it to be styled using a different interface instead of elements targeted at capturing information. The 'disabled' state doesn't provide this for input Cam
Re: [whatwg] including output in form submissions
2012-02-22 20:13, Cameron Jones wrote: It [the output element] does provide a greater degree of integration with the browser though. Is this a requirement, or just assumed features of implementation? Which of the assumed benefits could not be achieved by adding a new value for the type attribute (input type=output), or a new parameter (input output), or otherwise retaining the use of input (which would degrade well)? This results in a less scripting being required and allows for inline scripting to be more concise which aids readability and keeps things together. This would need to be illustrated by real examples, and you would still have the question why this could not be achieved using libraries, without making pages break on old browsers. It's also possible for it to be styled using a different interface instead of elements targeted at capturing information. The 'disabled' state doesn't provide this for input If you wish to show results of calculation visibly _and_ pass them along with the form data, you can use _both_ a normal element like div, p, or span _and_ an input type=hidden. The resulting duplication is irrelevant; you have the result in a variable, or should have, and just put it into two places. Yucca
Re: [whatwg] including output in form submissions
On Wed, Feb 22, 2012 at 6:26 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2012-02-22 20:13, Cameron Jones wrote: It [the output element] does provide a greater degree of integration with the browser though. Is this a requirement, or just assumed features of implementation? Which of the assumed benefits could not be achieved by adding a new value for the type attribute (input type=output), or a new parameter (input output), or otherwise retaining the use of input (which would degrade well)? I'm referring to the for attribute on output which ties its value to the elements which went into the calculation. This would otherwise have to be done using event attributes. This results in a less scripting being required and allows for inline scripting to be more concise which aids readability and keeps things together. This would need to be illustrated by real examples, and you would still have the question why this could not be achieved using libraries, without making pages break on old browsers. See above for less scripting. Old browsers won't be broken by the output element, they will function ina degraded state though. It's just as applicable to fix them using libraries. It's also possible for it to be styled using a different interface instead of elements targeted at capturing information. The 'disabled' state doesn't provide this for input If you wish to show results of calculation visibly _and_ pass them along with the form data, you can use _both_ a normal element like div, p, or span _and_ an input type=hidden. The resulting duplication is irrelevant; you have the result in a variable, or should have, and just put it into two places. Yucca This is imposing more and more on scripting and is a far more removed from declarative markup which is easier to understand and less error prone. I think the output element is conceptually simple, especially for authors with little or no programming experience. This also doesn't address the ability to style these elements in a separate and distinguishable way from input. Cam
Re: [whatwg] Review and Browser Vendor Interest in Form Enhancement
Personally as a web developer this a feature of forms that I've missed when I'm building my REST apis and then have to put in some kind of hidden input for method overwrite. I know of other developers that also agree that this is a wanted feature. On Wed, Feb 22, 2012 at 5:38 PM, Adam Barth w...@adambarth.com wrote: Last time I asked around, there didn't seem to be much demand for these features so I didn't implement the previous version that was in the HTML spec. Adam On Wed, Feb 22, 2012 at 9:33 AM, Cameron Jones cmhjo...@gmail.com wrote: Hi, I've submitted a proposal to w3c issue 195 which stems from requests to provide support for additional HTTP methods on forms with specific reference to clients without scripting support. The proposal is based on extending the functionality of forms by exposing the abilities of XHR to declarative markup. I'm keen to highlight the issue to solicit review and feedback on the proposal, and to harvest some degree of the level of interest from browser vendors as to the desirability of implementing the proposal. The proposal itself includes the rationale and details pertaining to the changes. There has been some initial feedback on public-html however i am yet to update the proposal with the recommendations. These amount to: * Implement method attribute values as a blacklist instead of a whitelist * Exclude CONNECT and TRACK methods in addition to TRACE as blacklisted items for synchronicity with XHR specification * Remove _none payload attribute state and replace functionality with disabled attribute and state * Look at replacing _async_ form control field as a form submit element attribute for form, button input retargeting. Proposal: http://www.w3.org/wiki/User:Cjones/ISSUE-195 Issue 195: http://www.w3.org/html/wg/tracker/issues/195 Thanks, Cameron Jones
Re: [whatwg] including output in form submissions
2012-02-22 20:38, Cameron Jones wrote: I'm referring to the for attribute onoutput which ties its value to the elements which went into the calculation. This would otherwise have to be done using event attributes. I don't see how that is supposed to simplify things. It's supposed to designate dependencies, but you still need to do just the same coding as without it, won't you? Old browsers won't be broken by the output element, they will function ina degraded state though. Certain old browsers won't recognize the output element at all. If you wish to show results of calculation visibly _and_ pass them along with the form data, you can use _both_ a normal element likediv,p, or span _and_ aninput type=hidden. The resulting duplication is irrelevant; you have the result in a variable, or should have, and just put it into two places. Yucca This is imposing more and more on scripting No, it's nothing in addition to what is currently done. And if you calculate something in scripting, you need to write it somehow into an element. Writing it twice, when needed, is very trivial. and is a far more removed from declarative markup which is easier to understand and less error prone. I don't see how it would be less error prone. And I don't see anything declarative with output. It's declarative markup to say this is a first level heading (which we can say with h1) or this is a person's name (which we can't say in HTML), but it's not declarative to say this is something written / to be written by a client-side script. I think the output element is conceptually simple, especially for authors with little or no programming experience. So why the discussions about including output in form submission? This also doesn't address the ability to style these elements in a separate and distinguishable way from input. You don't need a new element (unsupported by old browsers) to do styling. You can use classes, or other attributes. And you don't need to use input. You can use span or whatever you like, and/or input type=hidden, which normally causes no rendering issues. Yucca
