On Mon, Apr 20, 2015 at 11:01 PM James M. Greene
wrote:
>> That behavior is really all I wanted, i.e. "don't let the browser
>> discard/ignore valid RTF clipboard data".
On Wed, May 6, 2015 at 8:18 PM, Daniel Cheng wrote:
> I don't think I would feel comfortable with allowing web pages to place
Hi public-webapps, or the sub-set of your that are interested in
clipboard and DnD stuff: we've started an interesting thread regarding
DataTransfer, custom types and security here
https://github.com/whatwg/html/issues/1244
and implementor input is especially welcome. Allow me to paste parts
of m
Hi Gary,
good work! Some questions that have come up in discussion with
developers at Mozilla:
1) The existing DataTransfer API is purposefully designed to be used
for both copy/paste and drag-and-drop. If we add navigator.clipboard
to add asyncness to clipboard-style usage of the API, what about
Relevant to this thread - I've just reported an issue on making the
DataTransfer API safer:
https://github.com/whatwg/html/issues/1244
Input there would be great. I'm planning to look at how to add this to
the spec, but I'm not sure what exactly it should say.
I would still like comments from imp
On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
wrote:
> According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> chunked transfer coding”. The logical interpretation of this is that
> whenever possible HTTP recipients should deliver the chunks to the
> application as they are r
On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm wrote:
> Once I get back to work, I will start to program a version 5.0 of my editor
> that handles the new eventtype correctly.
>
> Anyone still not having upgraded from version 4.35, the editor doesn't end
> up doing crazy/uncontrolled stuff when r
> Just using mutation observers, one can see the change that was made, but
> doesn't really know what the user's intentions were, right?
I guess so, haven't used them for anything. Perhaps the "after the
fact" nature was a design flaw in Mutation Observers.
> The browser meeting also came up with
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик)
wrote:
> Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will
> receive a 'beforeinput' event just before any DOM update (with an option to
> cancel it), and you'll also receive an 'input' event just after the DOM w
Hi Johannes,
thanks for commenting here. It was recently brought to my attention in
a GitHub issue that using the term "before* events" was misleading as
it sounds like I also mean beforeInput when the clipboard spec is only
about beforecopy, beforecut and beforepaste. I think you may also have
mis
> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem
I'm trying to handle this question on another E-mail thread so please
follow u
Hi,
some discussion of how browsers can try to safeguard security/privacy
while copying/pasting HTML got tangled into the "remove dangerous
formats from mandatory data types" thread [1]. I think it will be
easier to follow with a separate thread.
Context: we're talking copy from any normal public
On Mon, Feb 8, 2016 at 7:45 PM, Wez wrote:
> Hallvord,
>
> IIUC the issue is that while transcoding complex formats via formats that
> can be easily sanity-checked by the browser takes care of letting content
> set complex formats like JPEG, GIF while protecting local content, but it
> loses the a
BTW, we have a slightly related and interesting discussion regarding
custom data types going on here:
https://bugzilla.mozilla.org/show_bug.cgi?id=860857
I should try to sum up some of the arguments and proposals and present
them on this list but if anyone wants to chime in, I'd appreciate more
id
(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)
On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht wrote:
> But copying a fragment of HTML in the w
On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin wrote:
>
> Killing them doesn't sound like the right course of action. We would have to
> come up
> with another API so we can have an alternative to what before cut/copy/paste
> do.
True, it's a use case we should handle.
Options:
* automagical
upcoming context "I'm about to do a cut/paste/copy")
>
> On Tue, Feb 2, 2016 at 2:00 PM, Hallvord Reiar Michaelsen Steen <
> hst...@mozilla.com> wrote:
>
>> Hi,
>> there's some scepticism about implementing
>> onbeforecut/onbeforepaste/o
Hi,
there's some scepticism about implementing
onbeforecut/onbeforepaste/onbeforecopy in Gecko [1], IE's implementation
seems considerably more limited than I expected (maybe because of bugs?),
and it doesn't really seem like an elegant solution to the use case it is
meant to solve.
Would anybody
On Thu, Aug 6, 2015 at 11:00 AM, wrote:
> Hi,
> Sorry if I might be out of scope, I am quite new in this mailing list.
>
Welcome, and sorry that I'm late at responding.
> The clipboard is aimed to exchange any? data between any apps running on
> your computer. It is not a browser stuff, it is
On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht wrote:
> Hallvord,
>
> do you not want to split the writable types list in safe and non-safe ones
> and let browsers how they deal with unsafe ones?
>
No, absolutely not. If we leave such things up to the browser we end up
with implementations that
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng wrote:
> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gi
On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren wrote:
> According to Art
> https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
> maintained. It should redirect to https://xhr.spec.whatwg.org/
> therefore.
>
Well, I don't think he said exactly "it's not maintained" - he said
On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren wrote:
> On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
> wrote:
> > so I hit a bit of an issue: I've written some parts of the clipboard spec
> > with the assumption that it will be invoked from a
&
On Wed, Aug 5, 2015 at 2:34 AM, MOHAN ARUN wrote:
> Would implementors want to support (writing stuff to the clipboard)?
>
Yes, we really, really want to allow that - at least for simple cases.
There are plenty of complex questions - for example "what formats is it
safe to let JS place on the cl
Hi,
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
require some extra permission work which no UA but IE has attempted so far).
Meanwhile, the editi
On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:
> I'm just thinking out loud here, but this problem is similar to one
> already faced by email clients, especially those which are web-based...
>
> On Mon, 27 Jul 2015 15:03:40 -0400, Ha
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng wrote:
> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gi
Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our "what about clipboard data from various native
applications?" conundrum. The proposal is to let a page indicate what
native clipboard identifiers it is interested in handling:
registerClipboardF
On Thu, Jun 11, 2015 at 7:51 PM, Wez wrote:
> Hallvord,
>
> The proposal isn't to remove support for copying/pasting images, but to
> restrict web content from placing compressed image data in one of these
> formats on the clipboard directly - there's no issue with content pasting
> raw pixels fr
On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn
wrote:
> I don't think the clipboard should forbid inserting image data, there's so
> many ways to compromise desktop software. ex. pasting text/html into
> Mail.app might even do it. This API shouldn't be trying to prevent that.
>
Well, the only *
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng wrote:
> Currently, the Clipboard API [1] mandates support for a number of formats.
> Unfortunately, we do not believe it is possible to safely support writing a
> number of formats to the clipboard:
> - image/png
> - image/jpg, image/jpeg
> - image/gi
On Wed, Jun 10, 2015 at 1:23 AM, Ashley Gullen wrote:
> The browser could copy a terminal command to wipe the disk, and the user
> could run it. Or copy a URL to a web page that has a known security
> exploit, and then the user pastes it in to the address bar. Maybe we
> shouldn't allow copying a
Hi,
I've just reported https://github.com/w3c/clipboard-apis/issues/4 - pasting
text below:
Through onbefore* events, JS can ensure copy/cut/paste UI in the browsers
is enabled even if there is no selection or editable context. However,
unless we spec queryCommandEnabled() to fire onbefore* event
On Sun, Apr 26, 2015 at 4:32 PM, James M. Greene
wrote:
> They used `Document#queryCommandSupported` and
> `Document#queryCommandEnabled` for feature detection -- the latter
> requiring that there is an active, expanded Selection/Range in the Document
> in order to get a positive (`true`) indicat
We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.
Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as
> headers (name:value meta data
(Aside: I was testing the queryCommandEnabled()/onbefore* idea with this
script: https://gist.github.com/hallvors/59a90f2e3816cb57f044 )
On Tue, Apr 21, 2015 at 7:29 AM, James M. Greene
wrote:
> Patrick Kettner offered up another idea for this as well on a related
> Modernizr issue [1]:
>
> Give
On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard wrote:
> Hallvord: By the way, please add the editor of the HTML spec to the
> beginning of the list in your references. It's strange to list a bunch of
> author names, but not the person who actually writes the spec.
>
Is anything incorrect here?
On Wed, Feb 11, 2015 at 7:21 PM, James M. Greene
wrote:
> The current spec still leaves me a bit unclear about if implementors must
> include the ability to feature detect Clipboard API support, which I think
> is a critical requirement.
>
I agree it's a very important requirement. And it sucks
So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is
there anyone on the IE team present on the list who is able to comment on
this?
-Hallvord R
On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:
>
> > In addit
Hi Anne,
sorry to be late at responding - just going through some E-mail I didn't
have time to understand and respond to before..
On Tue, May 20, 2014 at 2:55 PM, Anne van Kesteren wrote:
> Because redirects are atomic, we cannot dispatch loadend events and
> such on the XMLHttpRequestUpload cla
> > In addition, from a security perspective, what stops a malicious website
> from embedding something like style="display:none"> in the markup?
>
> We disallow this on copy by stripping such references.
>
Hi Ben,
picking up this old thread..
So we need to add a "sanitize local references" step
I assume that mandating all engines have built-in RTF parsers/converters to
translate back and forth between RTF and HTML is going too far.. Apparently
IE did / does just that, but even so it seems like RTF is generally fading
away.
Would it be a possible compromise to let a script describe data a
On Sat, Apr 11, 2015 at 8:16 PM, Aryeh Gregor wrote:
> > element.onclick = function(){
> > document.execCommand('copy', false, 'foo');
> > }
>
> Is this really "copying"?
As in "an operation that places some data on the system clipboard", yes ;)
but I see your point of view.
> I think a n
On Fri, Apr 10, 2015 at 10:55 PM, Daniel Cheng wrote:
> 1) I was under the impression (and MDN supports this) that the value
> argument for execCommand() must be a DOMString. Has that changed?
>
No. We'd have to consider changing it if the second example looks like
something we want to support (
> Which MIME type did you use in the response? BOM sniffing in XML is
> non-normative IIRC. For other types, see below.
>
It's text/plain - seems I definitely need one test with an XML response
too.. and one with JSON.
>
> [[
> If charset is null, set charset to utf-8.
>
> Return the result of r
On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters wrote:
> On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen <
> hst...@mozilla.com> wrote:
>
>
>> Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
>> send "charset=UTF-16&q
Hi,
I've just added a test loading UTF-16 data with XHR, and it exposes an
implementation difference that should probably be discussed:
Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
send "charset=UTF-16" in the Content-Type header - should the browser
detect the encoding,
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene
wrote:
> We never really came to a decision on if RTF ("application/rtf") should be
> listed as a mandatory MIME type but the general consensus seemed to be
> leaning toward "yes":
>
> https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/
I don't know what these "map to" on platforms that do not use MIME types to
describe clipboard contents. Should this information be dug up and included?
> First request: can we add the three MathML media-types?
>
I know you've brought this up before, I haven't done anything about it and
it's par
Hi,
so I think the Clipboard API spec is shaping up nicely - but here's the
question: what's the most important stuff that's lacking, if anything?
http://dev.w3.org/2006/webapi/clipops/clipops.html
One area in particular that the spec sort of skips around, is platform
integration. For example, it
On Fri, Jul 12, 2013 at 1:22 AM, Daniel Cheng wrote:
> I've noticed that the way that drag-and-drop processing model is written,
> the default content that would be in the drag data store is available in
> the dragstart event.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren :
> On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
> wrote:
>> So creating a new tri-state property in the XHR spec should also simplify
>> integration with the Fetch spec.
>
> Agreed. The questio
> > OK then - Anne and others, what do you think about creating a new tri-state
> > xhr.credentialsPolicy property and discouraging usage of
> > xhr.withCredentials ?
>
> I think I'd prefer removing the constructor flag and leaving new
> features to the API for Fetch.
Sorry, I don't understan
> > Now, if you are still not convinced this is a good change my plan B is to
> > suggest a "credentialsPolicy" property so we'll find an agreement anyway.
> > :-) But maybe explaining that no quirky getter magic is required helps you
> > see the proposal in a new light?
>
> Whatever we're doi
I proposed that we
>> modify withCredentials to take three values: "samedomain" (default),
>> "always" and "never". For backwards compatibility with earlier versions of
>> the spec, setting withCredentials=true maps to "always" and
>> withCredentials=false maps to "samedomain".
But Jonas repli
I wrote:
> I would like to see some real code evidence that omitting Origin:
> and Referer: is necessary too. In theory sites might use them as
> "credentials" as you say, but in practise I don't see how that can
> work and be safe on the web.
>
> If we ship XHR with an "anonymous" flag removi
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
> Given that many services do (mistakenly or not) use Origin and/or Referer to
> make
> security choices, all these headers along with the cookie header ought to be
> considered &q
[Minor edit: fixed your true/false typo]
> * If we had a better way of controlling the option to deny sending credentials
> in a way that kept compatibility with legacy webpages (eg. a tristate flag
> like
> you suggest in [6]), I agree it would be better than to have two different
> flags
> w
Anne wrote:
> I don't really feel it's responsible to remove this feature at this
> point without anyone involved in the original discussion speaking up.
Hi all,
you were involved in a discussion [1] regarding UMP and CORS back in 2010. I
know, it's a while ago, and apparently you had already be
> >> Making a boolean a tri-state with a
> >> default depending on an external variable is also super confusing.
> >
> > To whom?
> It seems confusing to anyone who reads the value.
Good point.
> What would it return
> in the various situations? I.e. before and after .open() has been
> call
> > BTW - have you considered allowing setting withCredentials to "false" for
> > same-origin resources?
>
> I suspect that would break sites.
Possibly, but I find it unlikely - if it's set, it's most likely usually set to
"true", not "false", and it's also most likely rarely set for same-or
On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Anonymous mode still seems like useless complexity to me, so I'm still in
>> favour of dropping it.
>
> Right. I don't really get the feeling you're considering the arguments
> carefully
Den 17. mai 2013 kl. 11:53 skrev Anne van Kesteren :
> On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Anonymous mode still seems like useless complexity to me, so I'm still in
>> favour of dropping it.
>
> Right. I don't really
Den 16. mai 2013 kl. 18:45 skrev Anne van Kesteren :
> On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Say, for example, OpenID is a setup where the user might provide an
>> "untrusted" URL to a third-party web site ("Here's th
> I just noticed that the topic has been discussed in another thread early
> this week. Sorry for rushing around after all that. BTW, what was the
> conclusion?
The conclusion is this commit:
https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640
which seems reasonable to
>>> Does anyone have real, non-contrived use cases for the anonymous flag?
>> The basic idea was preventing confused deputy attacks by not exposing
>> any information that could be used as such. So no credentials and no
>> data about where the request originated from, forcing the architecture
>
> > Secondly, by reading the spec I'd expect the second open() call
> > to fire another event. The open() method, steps 15 and 16:
> >
> > 15 Change the state to OPENED.
> > 16 Fire an event named readystatechange.
> > Doesn't imply that if the state is already OPENED, no new event
> > is exp
Small question regarding these tests:
open-send-open.htm
open-sync-open-send.htm
Test topic: how many readystatechange events are sent if a script in one single
script thread does xhr.open(...);xhr.send();xhr.open(...)?
Test expectation: one single event, with readyState 1. Both Opera (Presto)
>>> Yes. It was added to address: http://www.w3.org/TR/UMP/
> We could revisit
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171
> I suppose. Apparently at least Jonas changed his mind since then.
I didn't know the UMP spec. Reading it, it seems to me that the fund
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren :
> On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
> wrote:
>> If create an anonymous XHR request, rig it to GET a same-origin resource and
>> set a custom header, it will trigger a preflight and the same-o
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight and the same-origin resource
will have to opt in to receiving that custom header? Expected?
var xhr=new XMLHttpRequest({anonymous:true})
xhr.open('GET', '/')
xhr.setReq
> > It seems strange the spec would require a case-sensitive value for
> > Content-Type in certain circumstances.
> There's only two things that seem to work well over a long period of
> time given multiple implementations and developers coding toward the
> dominant implementation (this describe
> >> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
> >> resource
> >> with XHR from a CORS-enabled server, the natural thing to do seems to try
> >> to pass
> >> in the user name and password in the XHR open() call. If the script author
> >> supplied
> >> user/pass and
>> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected
>> resource
>> with XHR from a CORS-enabled server, the natural thing to do seems to try to
>> pass
>> in the user name and password in the XHR open() call. If the script author
>> supplied
>> user/pass and the server sa
> I had a discussion with Hallvord on IRC about the exact semantics we
> want for HTTP authentication in the context of CORS (and in particular
> for XMLHttpRequest, though it would also affect e.g. crossorigin>).
So me and Anne have been going a bit back and forth on IRC, we agree on some
stu
Two of the tests in
http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm
fails in Firefox just because there is a space before the word "charset".
Aren't both "text/html;charset=windows-1252" and "text/html;
charset=windows-1252" valid MIME types? Should w
> I suspect that the MathML community would be eager to help define
> what needs to get stripped out of MathML to maintain security.
> However, speaking for myself, I do not know what kinds of things
> are considered dangerous. For example, MathML has markup that lets
> a math expression act as a
Hi Paul, thanks for your comments.
> Mathematical information
>
> This section says "MathML often needs to be transformed to be
> copied as plain text, for example to make sure "to the power of"
> is shown with the caret "^" sign in a formula plain-text input."
> Such a transformation should not
On 03/28/2013 10:36 AM, Hallvord Reiar Michaelsen Steen wrote:
> >> In particular, WebKit has been stripping script element from the
> >> pasted content but this may have some side effects on CSS rules.]
> > AFAIK (without re-testing right now), WebKit's implementatio
> The current clipboard API specification mentions security risks
> of copy & paste but doesn't seem to explicitly mention methods by
> which user agents deal with such security risks.
Hi Ryosuke,
I did remove the section on cleaning up content because it was not implemented
by anyone and see
Hi Art, slightly late response because I've been away.
CCing public-webapps on this reply, in case anyone knows more that should be
done.
> I would like to know your thoughts and plans for the Clipboard API spec.
> Here's a short summary as I see it ...
>
> * The last publication of Clipboard
> There are references to this URL in the "Clipboard API and events" draft:
> http://www.w3.org/TR/html5/dnd.html#the-datatransfer-interface
Thanks, seems it should be updated to refer to
http://www.w3.org/TR/html5/editing.html#the-datatransfer-interface
I'll get that done, but not today.
On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote:
> > I would propose to centralize this and make it an up-front dialog remembered
> > for a site such that:
>
> That kind of bulk approach does not work. Users don't understand
> what's going on.
To what extent are we sure users understand a
> What/where would be a good place to put the API for say queryKeyCap(code) ?
Given that the implementation will have a KeyboardEvent property specified on
the global object (i.e. window) I'd propose
window.KeyboardEvent.queryKeyCap(code)
which returns a string with the symbol shown on the
> I would think that listing Anne as Editor or Former Editor and
> listing Anne in an Acknowledgments paragraph should be entirely
> consistent with all existing W3C practice.
But it's not consistent with that existing W3C practice to get all the text for
a spec from a document edited outside the
>> Are you claiming that the W3C is in the business of plagiarizing?
>
> I'm saying that the W3C (and this working group in particular) is
> taking Anne's work, without his permission, and passing it off as its
> own.
Speaking as one of the W3C-editors of the spec: first I agree that crediting
> > "Let document be the document associated with the global object of the
> > XMLHttpRequest interface object."
>
> You'd also need to check the JavaScript global environment.
Thanks for responding. How?
> What I mean is that -variables are scoped to the algorithm they
> are used in. So yo
I'm taking a back-channel discussion on-list per Anne's suggestion. We are
trying to clarify some text in section 4.6.1, "The open() method" which is
meant to describe how an XMLHttpRequest instance is associated with a specific
document. (This association is important for origin checks, securi
I wrote:
>> Hence, what I think would be most usable in the real world would be
>> making event.key a mapping back to un-shifted character values of a
>> normal QUERTY (en-US) layout. Authors are asking for stable reference
>> values for identifying keys, and that's the most stable and widely
>>
It's not only about the context menu (which could be "scoped" to whatever
element was targeted by a right-click), it's also about the "Edit" menu or the
"inline" commands in Chrome's normal application menu. Enabling the menu
entries all the time breaks with existing UI conventions.
>
But
It should work just fine if you check the whole eventtarget chain (from the
target to the window object).
> But that means adding a capturing listener on the window would apply this
> affect
> to every single element on the page. If that's an acceptable result, then
> just
> add the menu ite
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
>
The most IMHO elegant solution is what we implemented in Opera: we simply keep
relevant menu entries enabled if there are event listeners registered for the
corresponding event. This sor
Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai :
> I agree that this use case is not very important and possibly one we
> shouldn't bother trying to solve. Hallvord's initial point, I think is that
> there's really no use case for the before* events. We should kill them.
Makes it easier to ship my
> > > > The point is that a browser can act as if every single server response
> > > > included "Vary: User-Agent". And perhaps should. Intermediary caches
> > > > _certainly_ should.
> >
> >
> >
> > Good suggestion.
>
>
> But my concern was even if browser acts as such, intermediary cache
> > The point is that a browser can act as if every single server response
> > included "Vary: User-Agent". And perhaps should. Intermediary caches
> > _certainly_ should.
Good suggestion.
Julian Aubourg wrote;
> > I'm still more concerned about potentially legitimate use cases of
> User-Agen
Having thought about this some more, I see that there is a fingerprinting
concern if we tie this closely into the available applications/OS capabilities.
Also I understand that the API would be relevant for drag and drop (thought I'm
not quite sure how it would work). Hence I think the method s
> Hallvord, it should be called media-types btw, or?
IMHO the term "MIME type" is more widely used and also less ambiguous than
"media type", so I'd definitely prefer using the former if I can get away with
it :)
--
Hallvord R. M. Steen
Core tester, Opera Software
> > * Resolve URLs and links - the page script won't know the base URI to
> > resolve against (on Windows this is in the CF_HTML format's meta data
> > and the page script doesn't get access to it)
>
> Well presumably all the URLs should be made absolute in the copy/drag
> code, not the paste/
97 matches
Mail list logo
