Re: [whatwg] Iframe dimensions
Am 16.11.2010 00:32 schrieb Ian Hickson: On Wed, 11 Aug 2010, Markus Ernst wrote: Am 11.08.2010 00:24 schrieb Ian Hickson: On Mon, 5 Jul 2010, Markus Ernst wrote: [...] Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is under construction.) As a workaround to the height problem, I applied a script that adjusts the iframe height to the available height in the browser window. But of course the user experience would be more consistent if the page could behave like a single page, with only one scrollbar at the right of the browser window. If you control both pages and can't use seamless, you can use postMessage() to negotiate a size. On the long term, I expect we'll make seamless work with CORS somehow. I'm waiting until we properly understand how CORS is used in the wild before adding it all over the place in HTML. A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.:meta name=allow-seamless-embedding name=domain.tld, otherdomain.tld I think that this would be ok from a security POV, and much easier than using CORS. On Wed, 11 Aug 2010, Adam Barth wrote: That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? On Wed, 11 Aug 2010, Anne van Kesteren wrote: What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) I'd like to echo Anne's comments. If CORS is hard, then we should change that; if it's not, then we should use it (once we know it's solid). I tried to understand the CORS spec, but with no real knowledge about networking basics this is quite hard. Anyway it is not necessary for authors to understand the spec, as there will be how-tos available of course. From my humble author's POV, CORS is easy enough for tasks like the one I mentioned, if: - it is applicable at the server side with common scripting languages such as PHP - it is applicable at the client side without scripting
Re: [whatwg] Improve select required
2010-11-16 04:16 EEST: Ian Hickson: On Thu, 12 Aug 2010, Mikko Rantalainen wrote: A possible use case where this feature could be useful already (and cannot be fulfilled with @required): 1) An user is trying to register a new user account on some system and uses foo as the nick name. 2) The registration form is otherwise successful, but the system returns with an error message saying that nick foo was already taken. In such case, the actual input field could be specified as: input type=text value=foo disallow=foo That is, the field will be prefilled with foo but the field also contains extra information that the value foo will not be accepted in any case. The prefilled foo may have some value for the use and as a result, it does make more sense to prefil with foo instead of presenting an empty field with @required. Sure, but there it's not just foo that's disallowed, it's any registered username, and the better UI still would be to use a script to dynamically check the values as the user types them (with setCustomValidity()). I agree. A script that dynamically checks the server for up to date information allows for better UI. However, I'd like to have as good an UI as possible even in case scripting is disabled. As I said earlier (repeated below), this can be implemented with @pattern so @disallow is not required (no pun intented). My point was that if we have something in addition to @pattern, I'd rather have @disallow with a value than the @required without a sensible value. The same behavior can already be implemented with @pattern but I believe that @disallow would be easier to understand to most authors. If @disallow were introduced, the @required should be removed completely because it doesn't provide any functionality not provided by @disallow. I think disallowed= would be a lot more confusing for most authors. I don't have any evidence so I won't argue about that. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Constraint validation feedback (various threads)
On Thu, 12 Aug 2010, Aryeh Gregor wrote: On Wed, Aug 11, 2010 at 6:03 PM, Ian Hickson i...@hixie.ch wrote: The script setting the value doesn't set the dirty flag. The only way this could be a problem is if the user edits the control and _then_ the script sets the value to an overlong value. value On getting, it must return the current value of the element. On setting, it must set the element's value to the new value, set the element's dirty value flag to true, and then invoke the value sanitization algorithm, if the element's type attribute's current state defines one. http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis That seems to say that setting via .value will set the dirty flag (although setting via .setAttribute() will not). Am I mistaken? Hm, yes, you are correct. I've lost track of the context for this; does the above imply that there is a change we need to make? Aryeh was worried about page using maxlength to block users input then setting the value to something else before submitting. Given that maxlength has nothing to do with form validation and now can block the form submission, it might break some websites. There is a LinkedIn form broken because of that: there are two fields with a non-HTML5 placeholder (ie. it's the value) which is set with .value=something but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
On Tue, 16 Nov 2010 16:04:08 +0100, Mounir Lamouri mounir.lamo...@gmail.com wrote: There is a LinkedIn form broken because of that: there are two fields with a non-HTML5 placeholder (ie. it's the value) which is set with .value=something but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. Actually, that specific problem was addressed long ago based on feedback from us: Constraint validation: If an element has a maximum allowed value length, and its dirty value flag is true, and the code-point length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long. The dirty value flag is only true when the user has edited the control. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Constraint validation feedback (various threads)
On 11/16/2010 04:35 PM, Anne van Kesteren wrote: On Tue, 16 Nov 2010 16:04:08 +0100, Mounir Lamouri mounir.lamo...@gmail.com wrote: There is a LinkedIn form broken because of that: there are two fields with a non-HTML5 placeholder (ie. it's the value) which is set with .value=something but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. Actually, that specific problem was addressed long ago based on feedback from us: Constraint validation: If an element has a maximum allowed value length, and its dirty value flag is true, and the code-point length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long. The dirty value flag is only true when the user has edited the control. Actually, not: value On getting, it must return the current value of the element. On setting, it must set the element's value to the new value, set the element's dirty value flag to true, and then invoke the value sanitization algorithm, if the element's type attribute's current state defines one. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-value -- Mounir
Re: [whatwg] Constraint validation feedback (various threads)
On Mon, Nov 15, 2010 at 9:05 PM, Ian Hickson i...@hixie.ch wrote: Hm, yes, you are correct. I've lost track of the context for this; does the above imply that there is a change we need to make? maxlength should either not block submission at all, or only block submission when the user (not a script) was the last one to edit it. Currently it blocks submission even when a script set the value, consistent with other new validation constraints but inconsistent with legacy behavior. The two solutions are mostly equivalent given how browsers implement maxlength UI in practice, but differ in edge cases like data:text/html,!doctype htmlform input maxlength=1 onfocus=this.value = 'abc' input type=submit /form If you focus the form and hit backspace once, legacy behavior is to permit submission of the form, but HTML5 behavior is to prohibit it. It might be okay to keep HTML5 behavior in this case, but I don't see the point. I think the easiest change is to replace [[ Constraint validation: If an element has a maximum allowed value length, and its dirty value flag is true, and the code-point length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long. User agents may prevent the user from causing the element's value to be set to a value whose code-point length is greater than the element's maximum allowed value length. ]] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-maxlength with something like [[ If an element has a maximum allowed value length, and the code-point length of the element's value is greater than or equal to the element's maximum allowed length, user agents must prevent the user from increasing the code-point length of the element's value. Note: For historical reasons, maxlength does not impose any constraints on an element. Thus if an element's value is longer than its maxlength, such as if a script set it, the form it's in can still be submitted, and no error event is fired. ]] and remove the suffering from being too long state. This matches current behavior, but doesn't differ much from the current spec in practice, because it means the element can never be in an invalid state to begin with unless you do it yourself in JavaScript or set a too-long value attribute (and the latter is invalid markup).
Re: [whatwg] Iframe dimensions
On Tue, Nov 16, 2010 at 12:02 AM, Markus Ernst derer...@gmx.ch wrote: From my humble author's POV, CORS is easy enough for tasks like the one I mentioned, if: - it is applicable at the server side with common scripting languages such as PHP It is, very easily. For pages that are already server-side scripts, it's typically just one or two extra lines of code in the script, to set the appropriate headers to be sent with the page. For non-script pages, like videos, you can either pipe them through an easy script that appends the headers, or use .htaccess (or similar for your particular server technology) to add the headers automatically. - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ ~TJ
Re: [whatwg] Iframe dimensions
On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? -Boris
Re: [whatwg] Iframe dimensions
On Tue, Nov 16, 2010 at 10:06 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? Ah, if that's what Markus was getting at, then yes. CORS requires *zero* work on the client side, since it's completely done in the server-browser interaction. The entirety of the client's interaction in the process is the initial request for a resource. ~TJ
Re: [whatwg] Iframe dimensions
Am 16.11.2010 19:12 schrieb Tab Atkins Jr.: On Tue, Nov 16, 2010 at 10:06 AM, Boris Zbarskybzbar...@mit.edu wrote: On 11/16/10 12:56 PM, Tab Atkins Jr. wrote: - it is applicable at the client side without scripting This is not possible, for the simple reason that the whole point of CORS is to protect server resources. If you could deal with CORS purely on the client side, you'd be allowing the page author to determine if they themself are allowed to access a file on another server. That's a pretty obvious inversion of responsibility. ^_^ Well, more precisely there is nothing that needs to be done on the client side for CORS, right? Ah, if that's what Markus was getting at, then yes. CORS requires *zero* work on the client side, since it's completely done in the server-browser interaction. The entirety of the client's interaction in the process is the initial request for a resource. That is great news. Adding a header via a server-side script is indeed easy enough. (As I did not find any HTML attributes or whatever in the CORS spec, I was afraid that the use of XHR would be necessary to call a cross-origin page in an Iframe - which looked like a huge overhead and also an accessibility issue to me.)
Re: [whatwg] Drag-and-drop feedback
On 11/1/2010 6:03 PM, Ian Hickson wrote:
On Mon, 22 Feb 2010, Ian Hickson wrote:
On Thu, 4 Feb 2010, Ian Hickson wrote:
On Sat, 23 Jan 2010, Eduard Pascual wrote:
Would it be possible to provide a list of drag items (to call them
somehow) instead of, or in addition to, the current info provided by
the DataTransfer object?
That's a pretty good idea. I think we should probably do this when we
add more types to the DataTransfer object.
Some engineers at Google discussed this a bit and came up with the
following proposal:
dataTransfer.items = DataTransferItems
DataTransferItems.length
.getItem(n) = DataTransferItem
.add(stringData, type)
.add(blobData)
.add(fileData)
.add(dataTransferItem)
.clear()
DataTransferItem.kind = 'string', 'file', 'blob', ...
.type = MIME type
.binary = boolean
.getTextData(function callback (data)) - throws if binary
is true
.getBlob() - returns File or Blob
When we add promises later, this can easily be extended to support that
as well (basically, just by adding a new add() method for the promise
case).
I've added a simple version of this (no Blob support, and no way to add a
dataTransferItem, but otherwise more or less the same).
How close are we to adding promises?
.add(fileEntry,callOnTransfer);
This would allow the script to write to the contents of a file entry
upon request, instead of doing it ahead of time.
callOnTransfer = function( dataTransferPromiseEvent ) {
var dest = dataTransferPromiseEvent.fileEntry;
/// file writer API
dataTransferPromiseEvent.flush();
)
}
The fileEntry would be written ahead of time, either as a blank file,
or it'd be an already existing file.
DataTransfer.addFile(fileData);
It's now DataTransfer.items.add(fileData);
When interacting with non-DOM apps or pages, some platforms can't easily
convert arbitrary MIME types to native data transfer types for
copy/paste or DnD. For this reason, I think the spec should explicitly
list MIME types for which UAs should handle the conversion to native
data transfer types. A couple that come to mind: text/plain,
text/uri-list, text/rtf, application/rtf, text/html, text/xml,
image/png, and image/svg+xml. UAs can make a best-effort attempt to
convert the other types, but it won't be guaranteed that they will be
there for interaction with non-DOM applications.
I'm not sure what this means exactly. Could you elaborate?
I don't think these need to be converted by a UA -- the application which
receives the data does that conversion on its own.
This list of transfer types reminds me of all the redundancy that can
take place in a data transfer.
A sufficiently large XML content file may be transferred in ~4 different
file formats
for compatibility with the destination.
This is a good use case for promise-based data callbacks.
On Mon, 28 Jun 2010, Daniel Cheng wrote:
It's pretty common for there to be non-text data in a drag-and-drop
operation or copy-and-paste operation. DataTransfer doesn't allow for that
currently, since it only sets and returns DOMStrings.
It'd be nice if we could extend setData/getData to allow for Blobs. Some
random thoughts:
1. Add a bool parameter to setData/getData. If false, treat the data as a
DOMString; if true, treat the data as a Blob.
2. Add an encoding parameter to setData/getData. Encoding can be a string
value naming a text encoding like UTF-8 or ISO-8859-1, or it can be the
string value binary. If encoding names a text encoding, the UA will
transcode the requested data into/from a DOMString. Otherwise, if the
encoding value is binary, the UA will treat data as a Blob.
3. Create new DataTransfer functions instead of overloading them, e.g.
setDataBlob, getDataBlob.
I'm not sure which one is the preferred approach. It seems like it'd be nice
to have native support for whatever text encodings the browser understands,
but it seems complicated and I'm not sure it's necessary. Thoughts?
The new DataTransferItems feature could let you do this using
dataTransfer.items.add(blob), if we added that. Right now you can add just
text strings and File objects. We could also one day support arbitrary JS
objects (with the structured clone stuff) the same way, too.
Also, if I wanted to go ahead and implement a prototype in WebKit, should I
prefix it with a UA-specific string, e.g. webkitSetDataBlob?
Yes.
This relates to my comments later in this e-mail -- About allowing
.add(fileEntry,callback)
as a means for a promise-based download.
* I am worried about the effectAllowed attribute. Needless to say that
the number of value is exponencially proportional to the number of
possible values for the dropEffect attribute. Wouldn't it be better to
have a linear number of booleans ?
Yes, but it's about 10 years too
Re: [whatwg] Drag-and-drop feedback
On Tue, Nov 16, 2010 at 14:48, Charles Pritchard ch...@jumis.com wrote: When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. I'm not sure what this means exactly. Could you elaborate? I don't think these need to be converted by a UA -- the application which receives the data does that conversion on its own. This list of transfer types reminds me of all the redundancy that can take place in a data transfer. A sufficiently large XML content file may be transferred in ~4 different file formats for compatibility with the destination. This is a good use case for promise-based data callbacks. Automatic conversion is already implemented for some types (text, URL, and maybe HTML). It's just not explicitly mentioned in the spec. I'm not sure how a policy of no conversion would work; the clipboard mechanism/encoding varies greatly from platform to platform. With no automatic conversion, a page trying to read text from a drop would have to first sniff the operating system, choose the appropriate strategy for reading text, and then transcode the result to a DOMString. Daniel
