Re: Encoding Spec and Encoding for readAsText
On Sat, 18 Feb 2012 23:46:00 +0100, Arun Ranganathan aranganat...@mozilla.com wrote: OK, I agree that BOM considerations should override the Charset Parameter (if any) in Blob.type. I've made such a change. http://dev.w3.org/2006/webapi/FileAPI/ I think it would be better and clearer to simply reverse step 3 and 4. -- Anne van Kesteren http://annevankesteren.nl/
Re: [Clipboard] Processing model feedback (and other)
On Sat, 18 Feb 2012 16:45:07 +0100, Hallvord R. M. Steen hallv...@opera.com wrote: Firing an event surely should be specified elaborately elsewhere. I added another reference to DOM2-Events (though fire probably is used without being precisely spec'ed there..). Yes, you need to reference DOM4. Otherwise EventInit and such are undefined too. Oops, haven't fixed this yet. What is the best (most stable) URL for DOM Core / DOM 4 / whatever it's called nowadays? http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called DOM4. Why do you also reference DOM 2 Events? That's confusing and not needed. Seems pretty readable and precise to me as-is. Except there's no such thing as default action really... IMO this is well established terminology and easy to understand for script authors because of the preventDefault() method name.. I've changed the text slightly though. I don't really think the term is that clear personally and it's not in DOM4 at the moment. The whole notion that an event would have a default action is flawed. A particular action might have a default action preceded by an event that if canceled, cancels the default action, but I think it would be clearer to just say fire the event and if it was canceled do not do this next step. Which is how DOM4 is modeled. -- Anne van Kesteren http://annevankesteren.nl/
Re: (aside) MIME type
On Sun, Feb 19, 2012 at 4:55 AM, Julian Reschke julian.resc...@gmx.dewrote: The correct term IMHO is (Internet) Media Type, so disambiguation is possible. I don't believe it's helpful to maintain different sets of terminology. Use the official term, and when disambiguation is needed, it's trivial to do so. MIME type is what people in the real world call it. I don't believe it's useful to try to push terminology which is different from what things are actually known by, least of all when it leads to ambiguity. -- Glenn Maynard
Re: [Clipboard] Processing model feedback (and other)
Le 19 févr. 2012 à 10:46, Anne van Kesteren a écrit : On Sat, 18 Feb 2012 16:45:07 +0100, Hallvord R. M. Steen hallv...@opera.com wrote: Firing an event surely should be specified elaborately elsewhere. I added another reference to DOM2-Events (though fire probably is used without being precisely spec'ed there..). Yes, you need to reference DOM4. Otherwise EventInit and such are undefined too. Oops, haven't fixed this yet. What is the best (most stable) URL for DOM Core / DOM 4 / whatever it's called nowadays? http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called DOM4. That's a moving target, from reading the URL. Why do you also reference DOM 2 Events? That's confusing and not needed. Anne, please do not prevent this. I think Hallvord is trying to keep away from the hot debates and referencing one stable and one moving target, and he tries to be somewhat compatible with both at least at time of issuing. paul
Re: [Clipboard] Processing model feedback (and other)
Siterer Anne van Kesteren ann...@opera.com: Except there's no such thing as default action really... IMO this is well established terminology and easy to understand for script authors because of the preventDefault() method name.. I've changed the text slightly though. I don't really think the term is that clear personally and it's not in DOM4 at the moment. The whole notion that an event would have a default action is flawed. A particular action might have a default action preceded by an event that if canceled, cancels the default action, but I think it would be clearer to just say fire the event and if it was canceled do not do this next step. Which is how DOM4 is modeled. I think I see your point now from a technical point of view, but I think we're close to splitting hairs here. The term default action is simply a sort of language shortcut to say what happens when the event is not cancelled. It's well established (just like I'd argue MIME type is) and I see no real problems caused by its usage. /Hallvord
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
Siterer Paul Libbrecht p...@hoplahup.net:
Hm.. you mean a page should be able to say Hello web browser, I
just lve processing application/pdf data from the clipboard ?
I don't see the use case for that. If I'm misunderstanding you
please clarify :-)
It means that if pdf is in the clipboard the paste command can stop
being greyed out!
Aha. I keep forgetting the UI part of this, thanks for the reminder
and clarification ;-)
I think that the best way to address this is to spec the
before(cut|copy|paste) events, let them be real ClipboardEvents (no
idea what interface they use in IE and Chrome at the moment but I
think they are so rarely used we can rework them a little) and say
that clipboardData.types should be populated according to real
supported types on clipboard in the beforepaste event. Hence, a page
that can handle PDF data being pasted can listen for beforepaste and
check if event.clipboardData.types contains application/pdf.
(Just my preliminary thoughts, nothing about before* events is spec'ed
yet and actually I don't think they are an elegant solution. Perhaps a
clipboardchange event would be more elegant? Clipboard change listener
could do:
if(event.clipboardData.types.indexOf('application/pdf')))event.clipboarData.enableUI('paste');
Or something like that? We could also define
DataTransfer.enableUI('copy')) to be called at any time without any
event listener workarounds..)
Similarly, shouldn't something such as
if(event.clipboardData.isTypeSupported('foo/bar')) ...
be callable before the event is triggered?
That was my intention originally, but I'm also worried about
fingerprinting potential when letting scripts access new data about an
end user's config. Hence, I'm now intending to limit it to being
called inside event listeners like the other DataTransfer methods. I
also think that if the event is synthetic the method should not reveal
actual config details.
/Hallvord
Re: [Clipboard] Processing model feedback (and other)
On Sat, Feb 18, 2012 at 10:12 AM, Hallvord R. M. Steen hallv...@opera.comwrote: I've looked at rewriting it but I'm not sure how. Cancelling the default action has different outcomes for the different types of events. Some of the outcomes are also easier to understand if you think that the default action *is* no-op (rather than thinking skip handling the default action). You can use the wording I gave above (modified here slightly): 7. Fire an event using the *ClipboardEvent* interface, with its *type* attribute initialized to *e* and its *clipboardData* attribute initialized to *data transfer*, at *event target*. If the event's *canceled flag* is set then abort these steps. 8. If *e* is: *paste*: The bits about the focused node and the context is editable above should probably reference something specific in HTML. Quite possibly, but I'm not sure where to find it.. (I don't either. I'll leave these to people more familiar with those topics...) On Sun, Feb 19, 2012 at 4:05 PM, Paul Libbrecht p...@hoplahup.net wrote: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html and it's called DOM4. That's a moving target, from reading the URL. This is a well-understood topic: DOM2 is hazardously obsolete and new specs reference DOM4 for definitions of things like DOM Events. This isn't a hot debate; it's a finished one. If you'd like more explanation about this please start another thread--please don't derail this one. -- Glenn Maynard
Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard
On Sat, Feb 18, 2012 at 07:28, Hallvord R. M. Steen hallv...@opera.comwrote: On Fri, 17 Feb 2012 19:23:29 +0100, Daniel Cheng dch...@chromium.org wrote: Also, what does it mean to be supported? In new versions of Chrome, any kind of MIME type is supported in the sense that you can set data for any arbitrary type, and it can be understood by any browser that uses the same native conventions (I'd be happy to work with any other developers interested in making sure this works across different browsers on the same computer). That's interesting. How do you do that, on Windows in particular? Have you registered a clipboard format called MIME type of main clipboard part where you store type strings, or something? -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/ Chrome registers a clipboard format on Windows called Chromium Web Custom MIME Data Format (we do the same thing on Mac and Linux at the moment to keep the various implementations similar), and when we see an attempt to add data of a type which we don't have a native translation for, we just place the string in there. We currently have a bug open to figure out how to standardize the serialization, so we can stop using the Chromium-specific types. I'd like to extend it to binary data at some point too. With respect to enabling copy/cut/paste in context menu items, IE/WebKit have beforecut/beforepaste (both) and beforecopy (WebKit only?) events that fire before a context menu is displayed. I'm not sure how widely used they are though. That being said, it'd be nice to have something that works well for native context menus and custom editing controls created with HTML elements like the one at http://ckeditor.com/demo. Daniel
